주요글: 도커 시작하기
반응형

오래된 휴대폰에서 사진을 정리하다가 아래 그림이 나왔다. 2년 반 정도 전에 다니던 회사에서 모바일 게임 개발팀과 개발 범위에 대해 논의하는 회의를 하면서 그린 그림이다.



그 당시 회의를 진행하면서 서로들 다른 소리를 하길래 (실은 몇 명이 잘 못 알아듣길래) 회의 진척을 위해 화이트보드에 그림을 그렸다. 이 그림을 그린 뒤로 서로 오해 없이 대화를 진행한 기억이 난다.


이 그림은 별 것 아니지만, 이 그림이 그려지기 전까지 서로 다른 모습을 상상하며 대화를 했었다. 통신하는 방식도 주요 컴포넌트의 구성도 비슷한 듯 다르게 상상했기 때문에, 대화도 "아,, 그게 아니라....." 이런 식으로 진행되곤 했다. 지식을 시각적으로 표현하고 나서야 비로서 상호 간의 차이를 맞추고 정확하게 의사 소통 할 수 있었다.


올바르게 동작하는 소프트웨어를 만들어야 하는 프로그래머라면, 다른 프로그래머에게 소프트웨어에 대한 지식을 공유할 수 있는 역량이 필수적이다. 이는 아키텍처, 상위 수준 설계, 심지어 코드 수준까지 모두 해당된다. 지식을 서로 제대로 공유하지 못한다면, 해메는 시간이 그 만큼 길어진다.


소프트웨어에 대한 지식을 공유하는 역량을 키울 수 있는 가장 효과적이면서 가장 쉬운 방법은 그림으로 지식을 표현하는 것이라고 생각한다. 게다가 소프트웨어를 다어그램으로 표현하는 표준인 UML도 있다. 아직 다이어그램으로 소프트웨어를 표현하는데 익숙하지 않다면, 기존에 자신이 만든 코드/소프트웨어/시스템 등을 모두 다이어그램으로 표현하는 연습을 해 보자. 그러다보면 소프트웨어를 정확하게 표현하는 역량이 향상될 것이다.


+ Recent posts