개발자에서 아키텍쳐가 되는 길

출처:개발자에서 아키텍트로 가는 길..

----------------------------------------------------------------

안녕하세요

봄비가 내리니 마음이 차분해지네요

어제 다녀온  [개발자에서 아키텍트로 가는 길]이라는세미나 후기를 써 보았습니다. ^^
 
아키텍트 되어보세요 라는건 절대 아니고

한번 읽어보시면 어떨까 하여 전송드립니다.

예전보다 참석한 개발자 수가 확 줄었더라구요

운영자도 커뮤니티 활동하는 개발자 수가 줄었다면서 모바일분야로 닷넷 인력이 이동되었기 때문이라고 했습니다.

2개의 세션이 진행되었습니다.

1세션 : 엔터프라이즈혹은 아키텍트 7년 (안영희)

2세션 : 모든 소프트웨어아키텍트가 알아야 할 것(이충현)

내용요약을 해보면

소프트웨어 아키텍트는 많은 것을 해야 하며

고객의 비지니스 요구를 잘 이해한다.

열심히 배우고 연구하며 노력해라

무엇을?

우선은 다양한 코딩을 하고, 다양한 개발 경험을 해라.

단, 단순개발이 아니라, 원리파악 및 고객의 비즈니스를파악하여 문제해결력을 키워여 한다.

입니다.

노력하는 방법에 대한 광범위한 애기인데

지금 무엇을 해야 할까 생각해보게 하는 시간이었습니다.

그럼 오늘도 즐거운 하루 보내십시오.
 
1세션 : 엔터프라이즈혹은 아키텍트 7년

강사가 애기한 바는

개발자에서 민폐끼치지 않는

                구현가능한 그림을 그리는

                고객이 다시 찾는

                아키텍트로가는 길이라고 했습니다.

Architect Type 에는 3가지가 있으며 (Enterprise ArchiTect , solution ArchiTect, Application ArchiTect)

여기서 가 말하는 것은 Application ArchiTect 입니다.

아키텍트 정의를 살펴보면 (by 위키피디아)

1. 선택의 폭을 줄여준다: 개발표준, 개발/정의/선택

2. Reorganizing potential resue

    시스템을 둘러싼 환경인지/이해, 컴포넌트 설계

    조직 내 다른 어플리케이션에 대한 지식 습득

3. 직무

    설계 : H/W 환경설계, 코드 설계방안

    대화 : 비즈니스요구 이해 (단순하게 보면 기능, 깊숙히 보면 조직의 관점)

             고객의 아키텍처 비전을 향상 (advance their own architectral vision)

4. S/W 아키텍처 유형 : 신기술 적용, DB 중심 등 사람마다 스타일이 있음.

5. 기술외 산업트랜드를 알아야 한다.

입니다.

아키텍트가 되려면... 9가지를 애기했는데

1) 출발점을 찾아라

    --> 자신을 관찰해서 아키텍트로 가는 계기를마련해 보라고 햇습니다.

2) 당당하게 실패를 인정하라.

    모른다고 생각하고 처음부터 해보면 원리를 파악하게 된다.

    초창기에는 로그인페이지만 짜는데 6개월이 걸렸다고 하네요.

    대량의 사용자가 붙으면 로그인부터 다운되었다고 합니다.

    그걸 개선하면서 많은 것을 배웠다고 합니다.

3) 믿으라 그리고 끊임없이노력하라.

    좋은 책을 읽고 노력하랍니다. 추천: 실용주의 프로그래머

4) 놀라운 소스코드를 경험하라. --> 코드를다양하게 경험하래요

    스프링 프레임워크를 예로 들음.

    복잡도를 줄이는 프로그래밍 모델이 실현된 것으로 닷넷에도포팅되어 있고 클라우드 솔루션까지 진출하게 됨. EJB에도 도입됨.

5) 협업, 인정하라--> 협업이 잘되는 CREW의 필요

    기술이 좋은 개발자들만 모여도 협업을 하려면 시간이필요하다.

    협업을 위한 의사소통이 필요함.

    애자일 방법(솔직하게털어놓기)은 우리나라 정서에는 맞지 않음 --> 죄를고백하는 방향으로 감

    프로젝트 시에 코멘트처리, 테스트 시나리오에 따른 테스트 프로그램 개발등을놓고 잘 될때까지 애기하고, 밥먹구, 페어코딩하면서 도제방식으로배웠고,

    코멘트 처리잘되려면10일 이상, 개발테스트 프로그램개발 정착화는 4개월정도걸렸다고 하니, 많은 노력이 필요하다는 것을 실감하였습니다.

6) 멘토를 잘 만나라.

    결국 멘토였음. ㅠㅠ

7) 정교화 : 끝까지 할 것

    의미는 있으되, 현장은기간, 능력이 한정되어 있으므로, 조율해야 한다. (즉, 현실성을 무시하지 마라)

8) 기본자세

    책임감: 일분배, 조율, 준수

    포기하지 않는 정신

    모르는 것 인정 후1개씩 배워나감

    모르는 것을 빨리 배우는 방법을 배워라.

    내가 저 위치일 때 뭐가 필요할까 고려해라.

9) 다양한 프로젝트를 경험하라.

    일을 하면서 배우게 된다.

2세션 : 모든 소프트웨어아키텍트가 알아야 할 것

소프트웨어 아키텍트가 알아야 할 97가지(4/14출간) 라는 책의 번역자가 세미나를 진행하였습니다.

아키텍트로서 알아야 할 것은

    기술, 비지니스전략, 협상, 정치적인 이슈, 정량화, 개발환경, 리더쉽    

    개발프로세스, 멘토링/교육, 소통, 인터페이스설계, 창의성/근면성

등 입니다. (헥헥 머리가 띵하고 숨이 차네요 ^^;;)

정말 알아야 할 것이 많습니다.

보통 아키텍트에 대하여 아는 것중에서 오해하는 것 8가지를 살펴보면

1) 프로젝트 하는 시스템의 성능만 고려하면 된다 --> 다른시스템에 영향주는지도 고려해야 한다.

2) 공통의 문제는 해결하고 책임져야 한다. -> 명확하게선을 그러야 함.

3) 개발자는 통제해야 한다. -> 통제는 아니다. 개발자를 불신을 하기 때문에 그런 것이다.

4) 프레임워크 결정되면 아키텍쳐가 결정된 것이다. -->잘못된 정설

5) 아키텍트는 비지니스에 관심없다. -> 비즈니스중심적이 되어야 한다.

6) 최신 기술을 적용해야 한다. --> 고객이요구시에 하고, 아키텍트의 기술과시 욕구라면 안된다.

   개인의 이력만 생각하지 말아라.합리, 논리적으로 생각해라.

    솔루션, 패키지도입시 조심하라. 도입으로 인하여 architect 가 변화될수 있다. --> 사용영역, 책임소재를 명확히 해라.

    예를 들어 금융권에서rule 기반 package 도입 으로인한 부작용이 있었다.

7) 비즈니스의 문제이지 아키텍처의 문제가 아니다. -> 업무를담아내야 한다.

8) 아키텍트의 결정은 절대적이다. -> 절대적이지않으며, 역할이지 수직적 관계가 아니다.

아키텍쳐는

시스템은 1개의 아키텍처, 1개의 목표를 갖는다.

서술되어져 있어야 한다. (타당성 필요) 특정 솔루션도입에 대한 설명이 기술되어져 있어야 한다.

시스템의 논리/비지니스적인 배경이 있어야 한다.

관심사를 다루는 뷰포인트 명세화, 준수하는 뷰가 있어야 한다. 예: 성능, H/W 관점

복잡성 해결의 어려움. 그러므로 기술언어, 제품선택의 이유, 설명이 가능해야 한다.

본질적인 문제해결능력이 있어야 한다.

간결성 : 불확실성 제거 (Less is more)을제거하라.

개발자에게 더 많은 자유를 허용하라.

디자인 패턴 적용, S/W 적용등 연습이 필요하다.

등등을 언급하였습니다.

이렇게 두가지 세션을 마치고 나니..

사람들이 얼어 있었습니다. ㅎㅎㅎ

모두들 서태지와 이지아의 이혼 때문일꺼야 라고 생각하기로 했습니다. ㅋㅋㅋ

결론적으로, 개발자로서의 역할을 잘 수행하면서,

좀 더 나은 해결책을 찾아내고

목표에 맞는 시스템으로 만들어가는 것이 아키텍쳐의 역할이라 생각됩니다.

여기까지 읽어주셔서 감사합니다.

즐거운 하루 보내십시오.