'프로그래머'에 해당되는 글 3건

  1. 2009.01.14 아키텍트 이야기
  2. 2007.06.25 구글과 프로젝트 관리~~
  3. 2007.05.16 프로그래머?!?

아키텍트 이야기

|



아키텍트 이야기 - 8점
야마모토 케이지 지음, 이지연 옮김, 이용원 외 감수/인사이트

일반적으로 건축공학을 전공하고 나면 설계사가 되어 건축물의 구조와 설계를 담당하는 역할을 많이 합니다.
맞나요? 물론 실제 시공을 하거나 감독을 하거나 감리와 같은 업무를 하는 분들도 있겠죠.
하지만 제가 보기에는 구조 설계가 일반적인 건축공학의 역할이라고 보여집니다.

그런데 컴퓨터공학을 전공하고나면 일단 프로그래머가 되어야 한다고 합니다.
코딩 자체도 중요하지만 실제로는 프로그램의 전체 구조와 설계를 하는 업무가 더 중요한데도 말이죠..

그래서인지 요즘 컴퓨터 분야에서 아키텍트(Architect)라는 말이 많이 나옵니다.
처음 들었을 때는 프로그램의 DB와 프레임워크를 설계하는 일로만 생각했는데요.

"아키텍트 이야기"란 책을 읽어보면서 그 역할에 대해 한번 더 생각해 보게 되었네요..

책에서는 아키텍트를 개발자의 다음 단계라고 이야기 하고 있습니다.
10년 후에도 기술자로 활약하기 위해 아키텍트가 되어야 한다는 것이죠.

이 부분에 대해서는 좀 다르게 생각하는 면이 있습니다.
아키텍트라는 역할이 책에서 이야기하는 것처럼 복합적인 지식을 요구하지만 그것이 최고의 프로그래머만이  할 수 있는 것은 아니라는 것이죠.
진정한 아키텍트가 되려면 컴퓨터 분야에 대해 폭넓은 지식을 쌓아야 하기 때문에 처음 시작 단계부터 트레이닝을 한다면 지금부터도 될 수 있지 않을까요?
(물론 책에서는 개발하고 10년 후에 아키텍트를 할 수 있다는 이야기는 아니었습니다. ^^ 아키텍트가 되면 좀더 오래 개발과 관련된 업무를 할 수 있다는 뉘앙스였죠..)

아키텍트의 업무에 대해서 예를 들어가면서 자세히 설명하고 있습니다.
주요 사항을 정리해 보면 다음과 같습니다.

  • 요구사항 정의에 참여
  • 아키텍처 설계
  • 프레임워크 준비
  • 문제 해결
  • 테스트 지원
  • 개발 이외의 업무 지원
거의 프로젝트 관리자(PM)의 역할과 비슷해 보이기는 하는데요.
일단 기술적인 부분 즉, 설계와 프레임워크가 핵심이라고 보면 될 것 같습니다.

아키텍처를 설계하거나 프레임워크를 준비하기 위해서는 개발과 관련된 기술에 대해서 폭넓고 깊이있게 이해해야 합니다. 또한 과거의 기술에만 얽매이지 않고 새로운 기술들도 꾸준히 파악하고 있어야 효율적인 시스템을 설계할 수 있을 겁니다. 즉, 공부를 게을리해서는 안된다는 것이죠.

또한 요구분석, 문제 해결을 위해서는 의사소통에 대한 능력도 필요하다고 합니다.
대부분의 개발자들의 특성이 자신의 의견을 표현을 잘 하지 못하는 점이 있습니다.
개발자는 개발 언어로 설명하려 하고, 고객이나 사용자는 개발 언어를 이해하지 못하기 때문인듯 합니다.

개발 관련된 이야기들이 나오기도 하지만 전체적으로 어렵지 않게 읽어볼 수 있는 내용인 듯 합니다.
특히 프로그래머로서 또는 아키텍트로서 나아가고자 하는 대학생들이 미리 읽어보면 좋을 듯 하네요~

오랜만에 서평을 올리네요.. 요새 바쁘다는 핑계로 책을 못봤네요.. -.-




Trackback 0 And Comment 0

구글과 프로젝트 관리~~

|



구글에 대한 이야기는 너무 많이 블로거들 사이에 오르내리고 있는 것 같습니다.

처음에는 주로 에드센스 이야기로 시작하더니..
이제는 구글 내부의 UI, 프로젝트 관리 등으로 확대되어 가는 분위입니다.

과연 우리가 하고 있는 프로젝트 업무와 어떻게 다른지 ~~
최근 올라오는 글을 몇개 읽어 봤습니다.

이전에 구글스토리라는 책을 읽어보기도 했지만.. 블로그를 통해 들어보는 구글 이야기도 나쁘지는 않더군요..

팔글의 이삼구님의 다음 글을 읽어보세요~

구글의 이해되지 않는 인재와 프로젝트 관리
구글의 이해되지 않는 인재와 프로젝트 관리 2

일반적으로 프로젝트 관리라 하면..
PM의 역할이 절대적이라고 보는 경향이 많은데, 구글은 그렇지 않다고 하는 이야기 입니다.
즉, PM의 목표는 개발자가  원활하게 일을 진행하기 위한 도우미이고,
모든 협업에 참가하는 개발자들 사이에서 지시보다는 부탁에 의해 이루어진다는 것입니다.

또한, 구글에서는 개발과 수익을 직접 연관시키지 않고 개발에 임할 수 있다고 하네요~
다시말하면, 개발자는 새로운 것을 개발만 하면 된다는 것이죠~~

이를 위해서 필요한 것이 바로
1. 확고한 수익의 존재와
2. 서로가 믿을 수 있는 신뢰감이라고 이야기 하고 있습니다.

프로젝트 관리에 대한 글을 쓰고 있으면서 다음에 다뤄보려고 하는 부분이 바로 이 사람에 대한 관리였는데요~
좀 참고해 봐야 할 것 같습니다. ^^

어쨌든 애드센스, 에드워즈라는 확고한 수익~
또는 그 이전에 좋은 개발이 수익을 올릴 수 있다는 구글의 자신감이 ~
이런 결과를 가져오지 않았을까 하는 생각도 드네요...

골룸님의 구글 UI 특징 글을 보면..
데니스 황의 비둘기 에피소드도 그런 문화의 한 단면이라고 볼 수도 있을 것 같네요..
 
마지막 글은 떡이떡이님의 구글 수 kb라도 줄이기 위하 치열하게 고민 입니다.

프로그래머라면.. 자신이 만드는 것이 대한 자부심을 가질 수 있도록
최선을 다해야겠죠..
그리고 나서 결과를 지켜보는 것은 성공여부에 관계없이 흐뭇하지 않을까 합니다.
(실패하면.. 배는 좀 고프겠지만... -.-)



Trackback 0 And Comment 0

프로그래머?!?

|



  마틴파울러는 이렇게 말했습니다.
컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다.

워드 커닝햄은 다음과 같이 이야기했습니다.

저는 작지만 유용한 프로그램들을 매일 작성할 것을 추천합니다. 누군가가 똑같거나 혹은 더 나은 걸 이미 만들었다는 데에 절대 신경쓰지 마세요. 유용성과 복잡성 간의 균형 감각을 얻기 위해서는 당신 자신이 만든 프로그램의 유용성을 직접 느껴봐야만 합니다.

둘 다 매우 감동적인 이야기입니다. 정말 부럽기도 하구요~~
그러나 IT 개발자의 현실은 그렇게 여유롭지만은 못한 것 같습니다.

몇주전 블로고스피어에 올라왔던 아메바님의 그림일기를 보면 아주 적나라하죠.. ^^

사용자 삽입 이미지


이런 현실을 벗어나 즐겁게 일하면서 사람이 이해할 수 있는 코드를 만드는 방법을 함께 고민해 보도록 하겠습니다.

그래서 모두 불쌍한 개발자가 아닌 생명력이 있는 프로그램을 만드는 창조자가 되시기 바라겠습니다. ^^

# 참고할 만한 글:
김창준님의 “프로그래머의 위기지학
신영진님의 “Why Programming is Fun
미니님의 “Refactoring - 마틴파울러






Trackback 0 And Comment 0
prev | 1 | next