[후배들에게]
#2 설계하는 프로그래머
들어가는 글: 오늘은 '설계'에 대해서 알아봅니다.
1. 프로그래머는 만드는 사람이다
직업으로서 프로그래머는 만드는 사람입니다. 프로그램을 만들고 소프트웨어를 만듭니다(두 개는 같은 말이죠) 만들기 위해서는 어떤 설계도가 필요합니다. 건축을 생각하면 가장 손쉬울 것 같습니다.
하지만 지금까지의 경험을 되돌아보면 SW를 만들때 설계도가 항상 부족했던 것 같습니다.
대표적인 이유는 아래와 같습니다.
1) 요구사항의 미확정
2) 요소 기술의 미확정
3) 구현 가능성의 미확정
...
무엇보다도
4) 비즈니스의 미확정
우리는 만드는 사람입니다. 하지만 그것의 근거가 되는 문서 혹은 요구사항은 사전에 고정되지 않습니다. 비즈니스가 변화무쌍한 것 처럼 우리가 만들어야 하는 대상도 시간에 따라 원래의 목적과는 다르레 진화합니다. 왜냐? 모르니까요. 그들도 몰라서 그러는 겁니다.
2. 설계를 할 수 있어야 한다
프로그래머의 경력을 쌓아가면서 키워야 하는 소프트한 기술을 두가지로 꼽는다면,
1) 설계 능력
2) 의사소통 능력입니다.
구체적인 기술에 관한 내용은 연식이 쌓이고 좋은 동료들을 만나면 금방 배울 수 있습니다. 단 도메인이라고 불리는 산업에 관한 지식은 단기간에 쌓을 수는 없지만 이 또한 시간을 들이고 좋은 동료들을 만나면 비교적 빠른 시간에 만회할 수 있는 것도 사실입니다. 좋은 '동료'들은 무엇보다도 중요합니다. 그들이 나의 스승이죠.
오늘은 먼저 '설계'에 대해서 알아보도록 하겠습니다.
설계란 무엇인가?
목표하는 대상을 완성하기 위해 구성하는 구성요소를 배치하고 그 구성요소들의 관계를 정의하는 것입니다. 쉽게 말해서 회사를 세운다고하면 회사에는 영업부서(돈버는 부서) , 기획개발부서(제품을 만드는 부서), 총무부서(기타행정)로 나눌 수 있는 것 처럼 원하는 SW을 어떻게 구조화할 것인가를 결정하는 것입니다.
당연히 경험이 필요하죠.
많이 알면 좋은 설계를 할 수 있습니다.
하지만 더 중요한 것은 스스로 많이 해봐야 좋은 설계를 할 수 있습니다.
설계는 프로그래머의 품격입니다.
경력이 10년쯤 쌓였는데 새로 맡은 프로젝트를 본인의 사고방식으로 설계할 수 없다면 곤란한 일입니다.
당장 코딩을 하고 이슈를 수정하는 것이 중요하겠지만 (긴급하지만 중요하지 않은 일)
미래를 본다면 나의 사고방식대로 전체를 설계해보는 습관을 들이세요.
A4 용지를 꺼내놓고 볼펜을 들고 네모 , 선 , 동그라미 등으로 한눈에 전체의 구성요소와 어느 것을 핵심요소로 선정할 지..그리고 risky한지 전망해보세요. 저는 그것이 설계라고 생각합니다.
3. 설계는 개취다
설계는 자기만의 생각을 추상화한 것이기 때문에 개인적인 취향이 많이 개입됩니다. 따라서 설계자가 누구냐에 따라 같은 SW의 구조가 180도 달라지게 됩니다. 프로그래머 후배들에게는 '완벽한 설계'라는 환상이 있을 텐데 완벽한 설계는 존재하지 않습니다.
따라서 자기만의 생각이 매우중요합니다. 그것이 판단의 기준이되기 때문입니다.
후배 프로그래머 여러분,
아마도 여러분의 설계(안)는 실제 프로젝트에서 많이 반영되지 않을 수 있습니다. 하지만 내가 맡은 기능에 한정하지 말고 좀더 큰 그림에서 '나라면 어떻게 설계할까?'를 고민해보는 것은 좋은 경험이 됩니다.
그래야 힘이 생깁니다. 흰 종이를 펴고 나름의 상상력 & 분석력을 발휘해보세요.
스카우터를 켜고 내 설계의 장점과 현 설계의 단점이 무엇인지를 분석해보는 것도 좋고
나라면 이렇게 했을텐데 라고 주장을 펼쳐도 좋습니다. 단, 본인이 옳다고 우길 필요는 없습니다. 아직 갈길이 머니까요.
다음엔 의사소통에 대해서 좀더 알아보도록 하겠습니다.
2016.04.16 오전8시 @Home
