IT개발자에게 필요한 4가지 습관

사람이 언어를 배우는데에 있어 꼭 필요한 4가지가 있다.

읽기, 듣기, 쓰기, 말하기.

초등학교부터 대학교때까지 쉬지 않고 갈고 닦는 이 네가지 연습은 언어 이외에도 살아가는데에 큰 영향을 미치게 되는데.. 나에겐 그 중 한곳이 바로 일터이다. 한동한 뜸했던 개발자 이야기의 주제로 이 4가지 요소와 밀접한 관련이 있는 "IT개발자에게 필요한 4가지 습관"을 적어본다.

코드 정독하기
편지나 글을 쓸때와 마찬가지로 개발자는 자신이 쓴 코드를 두세번 정독하는 습관이 필요하다. 논리적인 계산을 많이 필요로 하는 프로그래밍은 막상 코드를 써내려갈때 찾지 못했던 오류가 제3자의 입장에서 다시한번 읽어내려가며 이해하도록 노력할때 발견되는 경우가 종종 있다. 물론 코드를 쓰는 입장에선 한번 더 읽기보단 자신을 믿고 일단 작동을 해본 후 오류를 찾고 싶은 귀차니즘이 발동할때가 많겠지만, 논리적으로 문제가 있는 경우에는 왠만한 테스팅을 거치지 않고서는 오류를 찾아내기가 힘든 부분이 많다. 자신이 읽기 귀찮다면 팀원과 서로의 코드를 바꿔가면 읽어보는 것도 도움이 될 수 있다. 수학문제와 마찬가지로 자신이 쓴 풀이부분은 다시봐도 틀린 곳을 찾기가 힘들기 때문이다.
코드를 정독하는 것은 굳이 오류를 찾아내는 것 이외에도 개발자로서 코드에 대한 이해력을 높여줄 뿐만 아니라 좋은 코딩을 하기 위한 밑거름이 되기도 한다.

귀기울여 듣기
우선 기업에 속한 개발자는 대부분 코드를 쓰기전 수많은 요구사항을 수집, 정리하게 된다. 고객이나 요청자쪽에서 원하는 바를 제대로 이해하기 위해서는 그들의 말을 귀기울여 듣는 습관이 필요하다. IT기업이라면 그나마 낫겠지만 전혀 다른 업종의 IT부서에 속했다면 요청자가 사용하는 단어와 비즈니스의 흐름을 파악하는 일은 쉬운 일이 아니다. 조금이라도 많이 묻고 그들이 하는 대화를 집중해서 듣는 것이 중요하다.
요청자뿐만 아니라 함께 일하는 동료개발자와의 대화에서도 마찬가지이다. 작업을 분담할때나 함께 코드 작성시 서로를 제대로 이해하지 못해서 실수를 하거나 시간을 버리는 경우도 종종 있다. 어떤 직장이든 마찬가지겠지만, 단순히 듣는 것이 아닌 '경청'하는 자세가 개발자에게 꼭 필요하다.

종이에 그려보기
개발자에게 있어서 '쓰기'단계는 종이나 연습장에 자신이 구상하는 프로그래밍 로직의 순서나 객체들, 그리고 그 상관관계를 그리는 것이다. UML, Use Case Senario, Flow Chart와 같이 전문적인 문서를 만들어야 할 경우도 있겠지만, 코딩시에 자신이 쉽게 알아볼 수 있는 간단한 그림을 그린다면 효율성을 높여주고 실수를 줄이는데에 상당히 유용하다.
요청자나 다른 개발자와 대화할때도 마찬가지. IT개발의 특성상 글이나 말보다 그림을 그려가며 상대방을 이해시키기 쉬운 경우가 많다. 머리속으로 생각했을때는 쉬울 것 같지만 손으로 이것저것 그려본 경험이 없는 개발자라면 그림으로 표현해 내는 것도 상당히 어려운 일이 될 수 있다. 키보드에 손을 대기전에 연필을 잡는 습관을 들여보는 것도 좋을 것이다.

말로 설명하기
자신이 아는 것을 상대방에게 말로 설명해 이해시킬 수 있을때 비로소 그것에 대해 잘 아는 사람이라고 한다. 만약 자신이 개발한 코드를 말로 설명하기 힘들다면 그것은 코드자체가 필요이상으로 복잡하게 쓰여진 것이라 의심해 볼 수 있다. 그림으로 그리는 것과 마찬가지로 자신의 코드를 남에게 자주 설명하는 습관을 갖는다면 그 능력도 쉽게 발전시킬 수 있을 것이다.
개발자에 대한 가장 많은 선입견 중 하나는 '말주변'이 없다는 것이다. 물론 여기서 말하는 말주변이란 기술적인 것만을 포함하지는 않는다. 개발자가 개발에 관여하는 고객 및 비즈니스쪽 사람들과 능수능란하게 대화할 수 있을때 기술적으로 뛰어나기만한 개발자보다 인정받을 수 있는 것은 당연한 것이다.

아직 초보개발자인 나에게는 위에 말한 모든 것이 앞으로 풀어야할 숙제이다. 누군가 나에게 평생 개발자로만 살고 싶냐고 물어본다면 단호하게 '아니요'라고 말할 것이다. 좋은 개발자가 되는 일은 그 다음 원하는 일을 위해 꼭 필요한 것이기에 발전가능성을 인지하고 계속 노력할뿐이다. 지금하는 일도 잘하지 못한다면 물론 다음일도 마찬가지가 아닐까.