행복한 아빠

후배개발자들에게 하고 싶은 말 본문

하고싶은말

후배개발자들에게 하고 싶은 말

행복한아빠 2009. 12. 17. 20:43
평소에 이런 생각들을 정리해서 알려주고 싶은 기회가 있습니다. 기회가 되어 한번 정리해 봅니다. 앞으로도 꾸준히 이런 생각들을 정리할 기회가 있으면 좋겠습니다.

일을 잘 한다는 것이 단지 기술을 많이 알고 설계/구현을 잘하는 것만은 아닐 것입니다.
인간적인 관계, 사회적인 역학관계등도 잘 이해하고 그 상황을 잘 이해하고 일을 진행하는 것이 더 중요할 지도 모릅니다. 오늘은 순수한 개발자 입장에서 제가 그동안 생각했던 것을 간단히 정리해 보려고 합니다.

연필을 사용하세요.
우리는 누군가 결정해 놓은 것을 그대로 컴퓨터 언어로 옮기는 단순한 코더가 아닙니다.
주어진 상황에서 문제를 풀고 논리적으로 때로는 창의력을 발휘하여 문제를 푸는 고도의 정신노동을 하는 프로그래머입니다. 따라서 자신의 생각을 표현하고 잘 정리할 수 있는 도구가 필요합니다.

우리가 사용하는 여러 도구로 모델링 도구나 Mind Map과 같은 생각을 정리하는 도구가 있습니다. 이러한 도구도 나름 훌륭하지만 자칫 잘못하면 우리의 상상력을 제한하는 굴레가 될 수 있습니다.

작업초기에는 많은 가능성과 문제를 풀 수 있는 대안들을 많이 만드는 것이 중요합니다. 즉 생각에 많은 유연성이 필요하다는 이야기죠. 작업 초기에는 유연한 도구를 선택하세요. 사고하는 방법도 유연해 질 수 있습니다.

저는 초기작업 시 연필과 지우개 그리고 노트를 준비합니다. 꽤 낡은 방법 같지만 다음과 같은 점에서 많은 장점이 있습니다.
- 모델링 도구로 그릴 수 없는 생각들이 있습니다. 모델링이 아니라 그림, 수식, 그 어떤 것도 제약없이 표현이 가능합니다.
- 지우기가 쉽습니다. 좋지 않은 아이디어일 경우 빨리 버리는 것도 좋은 방법입니다. 연필로 대충 그린 아이디어는 지우기도 쉽고 버리기도 쉽습니다. 열심히 그린 UML 다이어그램이나 ERD를 휴지통에 넣기 쉽습니까?
- 다른 사람과 협업이 쉽습니다. 그냥 노트만 들고 가면 됩니다. 때로는 파트너가 바로 내 노트에 자기 생각을 덧붙이겠지요.
- A4가 아니라 노트에 정리한다면 나중에 그 아이디어를 다시 검토하기 좋습니다.

그외에도 여러가지 좋은 점이 있습니다만 개개인의 차이가 클 것 같습니다. 잊지 말아야 할 것은 아이디어를 어느정도 정리했다면 반드시 그 팀이 사용하는 도구로 정리하세요. 지우기가 쉬운 만큼 정리하지 않으면 잊어버리기도 쉽습니다.

결과를 먼저 그려보세요.
무슨 일을 할 때 목표를 정한다는 것은 굉장히 중요한 일입니다.
우리가 하는 일도 그와 다르지 않습니다. 우리가 하는 일에 목표를 정한다는 것은 만들어야 할 프로그램을 미리 예상하고 구체적으로 그려보는 것입니다.
개발자의 작업에서 목표를 잡고 우리가 만든 결과를 먼저 그려보는 작업은 여러 단계에 걸쳐 진행됩니다.

- 분석
우리가 만들 프로그램을 가상하여 미리 사용하는 시나리오를 적습니다. 이 부분을 생략하면 다음 작업부터는 목표없이 일을 진행하는 꼴이 됩니다. 우리가 많이 사용하는 유스케이스 분석이 이 활동일 것이고 극단적인 방법으로 있지도 않은 프로그램의 메뉴얼을 먼저 작성하고 다음 작업을 진행하는 방법도 있습니다.
- 설계
프로그램의 최종 모습을 여기서 결정합니다. 물론 다음 단계를 거쳐 그 결정을 변경할 수도 있지만 이 단계에서 프로그램의 구체적인 작동 메커니즘을 미리 결정합니다. 그렇게 결정된 설계가 돌아갈 것인지 아닌지는 중요하지 않습니다. 설계가 없는 구현, 즉 목표 없이 하는 코딩 작업은 막코딩이 되기 쉽습니다.
- 구현
이 단계의 목표설정은 단위테스트 작성이 될 것입니다.
프로그램 구현을 하기전에 먼저 목표를 잡습니다. 즉 프로그램이 돌아간다고 가정하고 단위 테스트를 작성합니다. 처음에는 단위테스트가 모두 실패하겠지요. 단위테스트 성공을 위해 프로그램 구현을 완성하면 구현 단계의 목표를 달성하게 됩니다.
선배들이 단위테스트를 먼저 작성하라고 그렇게 강조하는 이유가 다 있습니다. 구현을 끝내고 단위테스트를 작성하는 것은 일을 다 해놓고 그 결과로 목표를 잡는거와 다름이 없습니다.
또 한가지 구현하느라 지치기 전에 단위테스트를 충실히 작성하세요.

작은 것이 아름답다.
이 말은 Unix의 사상을 좋아하는 사람은 누구나 아는 말일 것입니다.
우리는 우리를 필요로 하는 사람들의 문제를 풀어 주는 일이 주된 작업입니다. 우리가 푸는 문제들 대부분이 그렇게 간단하지 않습니다.
아키텍트, 설계자, 프로그래머의 가장 큰 능력은 "복잡한 문제를 얼마나 단순하게 만들수 있는가"입니다. 복잡한 문제를 (그냥 그대로) 복잡하게 만드는 것은 어느 정도 시간이 지나면 누구나 할 수 있는 일입니다.
그러나 동일한 결과를 복잡한 방법을 통해 내는 것과 잘 정리된 단순한 방법으로 내는 사람의 차이가 실력의 차이입니다. 아키텍처 분야에서 하는 이야기 중 복잡한 것을 단순하게 만드는 것은 나누고 정복하는 것입니다.
복잡한 것을 어떻게 작게 나눌까 항상 고민하십시오. 그리고 그렇게 작게 나눈 것들을 이용하여 문제를 풀 수 있는 방법을 고민하세요.

어린 왕자의 작가로 많이 알려진 비행기 설계자 생떽쥐베리의 말을 인용해 봅니다.
완벽한 설계는 무언가 더 추가할 것이 없는 것이 아니라 무언가를 더 뺄 것이 없는 것이다.

언어가 사고를 제한한다.
우리는 꿈에서 한국말을 사용합니다. 그리고 생각을 하더라도 한국말을 이용하여 생각합니다. 물론 영어권에 사는 사람들은 영어로 꿈을 꾸고 영어로 사고를 하겠지요.
문화의 특성 때문에 각 나라에서 사용하는 언어가 표현할 수 있는 정도는 매우 다양합니다. 예를 들면 에스키모가 표현하는 "눈(雪)"은 수십가지가 됩니다. 우리가 눈에 대해 상상할 수 있는 것과 에스키모인이 눈에 대해 상상할 수 있는 것은 그 차이가 크겠지요.

우리가 사용하는 컴퓨터 언어, 도구도 마찬가지입니다. 컴퓨터 언어나 도구는 나름대로의 목적을 가지고 태어났습니다. 따라서 특정 언어나 도구가 할 수 있는 일은 제한이 되겠지요.
우리가 사용하는 Java만 고집한다면 우리가 할 수 있는 일과 우리가 문제를 풀 때 상상할 수 있는 것은 제한이 될 것입니다. 언어 뿐만 아니라 우리가 신봉하는 객체지향, 컴포넌트, 서비스지향에만 너무 얽매이면 쉽게 풀 수 있는 문제도 복잡하게 될 것입니다. 어느 때는 DBMS 보다는 File 시스템이 Java 보다는 shell script가 문제를 단순하게 합니다.

자기의 주요 언어나 도구에 대해 스페셜리스트가 되는 것은 필수 사항입니다. 그러나 좀 더 나은 개발자, 설계자, 아키텍트가 되기 위해서 더 많은 언어와 도구도 문제를 풀기 위한 대상에 올려 놓으세요. 물론 그것들에 대해 어느정도 알고 있어야겠지요. (공부합시다.)


3 Comments
댓글쓰기 폼