개발자에게 의사소통은 두 번째로 중요하다

개발자에게 의사소통은 필수다.

 

개발자에게 가장 중요한 것은 일단 개발 실력이다. 다른 모든 것을 잘해도 개발을 못한다면 일단 개발자라고 말할 자격이 없다.

개발자라는 사람이, 주식을 너무 잘해서 주식으로 돈을 벌고, 강의를 너무 잘해서 강사로 유명하다면...

애당초 개발자라고 말할 이유가 없다. 증권맨이거나 유명강사라고 하겠지.

그렇다면 해당 요소를 제외한다면, 실질적으로 [개발자]에게 있어서 가장 중요한 것은 무엇일까?

나는 의사소통이라고 생각한다.

철학적인 의미나 이상적인 개발자의 모습을 말하는 것이 아니다.

실질적으로 의사소통이 안되면 개발이 너무 힘들고 실질적으로 내가 무엇을 했는지 남에게 인지시킬 방법이 없다는 것을 서서히 느끼고 있기 때문이다.

 

 

1. 외부인과 의사소통

 

혼자서 기반을 다지고 완성품까지 제작해서 그 결과를 보여준다면 의사소통이 필요없다.

제품으로 말을 하면 되니까 내가 어떤 능력이 있는지 납득시키기 아주 쉽다.

하지만 규모가 크고 작고를 떠나서, 특정 회사의 프로그램을 개발한다는 것은 혼자서 무언가를 다 하는 것이 불가능하다.

현실적으로 소유권 문제가 있고, 개발을 하고 소유권을 넘긴 뒤에 해당 프로그램을 유지보수 하는 방법도 알려야 하기 때문이다.

 

결과적으로 개발자는 현실적인 소유권 혹은 금전적인 문제 때문에 협업을 해야만 한다.

일을 하는 것이 돈을 버는 것이 핵심 이유인 이상, 당연한 이야기다.

 

그렇다면 제품으로 무언가를 남에게 어필하기 어렵다.

내가 만든 것을 다른 사람이 소유하므로 그 사람들이 자신의 제품이라고 홍보하기 때문이다.

내가 그것을 만들었소 하는 것을 그 사람들이나 기업이 홍보하지 않는다.

그 프로그램의 개발자가 그 자체로 브랜드라면 (예를 들어, 자바의 아버지가 만든 프로그램이다!) 홍보를 하겠지만,

어딘가에서 쪼금 한다는 개발자가 만들었다! 라고 홍보하는 일 따윈 없다.

그럴 이유가 전혀 없으니 당연한 일이다.

 

그렇다면 내가 그것을 만들었다고 어필하기 위해서는 내가 직접 자신을 홍보하는 과정이 필요하다.

그냥 가서 만들었다 이러는 것은 학생 때나 통한다.

사회인이라면 그것을 만들었다는 증거가 있어야 한다.

산출물이라든지, 실질적으로 개발자가 아니라면 알 수 없는 정보를 알고 있다든지 하는 방식으로 말이다.

아니면 개인 홈페이지나 블로그에 개발일지를 남기는 것도 방법이다.

이런 것이 직접적으로 대화하는 것은 아니지만 하나의 의사소통 방법이라고 본다.

 

 

2. 관리자와 의사소통

 

외부인에게 나의 이력을 어필하는 것보다 실질적으로는 관리자에게 어필하려는 의사소통을 더 많이 사용한다.

 

10명의 개발자가 어떤 프로그램을 개발한다고 해보자.

각 개발자에게는 자신에게 맞는 할당량이 존재할 것이다.

그렇다면 그것을 다 했는지, 진행 중이라면 진척도는 얼마나 되는지 알릴 방법이 필요하다.

말로 무언가를 하는 것도 좋지만, 현실적으로는 산출물이 그 대안이 된다.

수없이 작성하는 다양한 문서는 모두 비-개발자에게 개발과정을 이해시키기 위한 과정이라고 보면 된다.

 

그것 말고도 관리자에게 하는 산출물도 있다.

테스트케이스가 바로 그것이다.

 

코드를 작성했는데, 그것이 원하는 기능대로 정확히 돌아간다고 가정해보자.

하지만 그것이 완벽하다는 것을 아는 사람은 코드를 짠 나밖에 없다.

남이 그 코드를 한줄한줄 들여다보면서 예외는 없는지 고민하지 않는다.

그들을 납득시키기 위한 방법은 테스트케이스다.

 

이런 이유 때문에 기능개발 + 테스트케이스는 별개의 작업이 아니다.

그냥 하나의 작업으로 인식하는 것이 옳다.

단, SI는 이런 것을 무시하는 경우가 상당히, 아니 거의 대부분인 것 같다는 느낌이 들긴 한다.

테스트케이스는 일단 작성하는 데도 시간이 반드시 걸리므로 조금이라도 일정을 빼고 싶다는 마음이겠지.

일정을 조금이라도 뺀다 = 공수가 적게 든다 = 돈이 적게 든다 = 남는 돈은 내 주머니로...!

 

 

3. 동료개발자와 의사소통

 

의사소통이 중요한 핵심이유는 사실 이게 아닐까?

개발자 간 의사소통은 내가 개발자가 아니었을 때 했던 생각보다, 너무나, 매우매우매우매우 중요했다...!!!!!!!

 

이유는 간단하다.

프로그램 개발할 때는 내부적으로 규칙을 정한다.

해당 규칙은 수시로 변경된다.

수시로 변경되는 모든 규칙을 가독성 있게 작성한 문서 따위는 존재하지 않는다.

가장 정확한 현재 개발 포맷은 동료 개발자가 알고 있다.

 

즉, 포맷이 변경된 것도 모르고 엉뚱한 것을 개발하는 짓을 하지 않으려면 반드시 동료 개발자와 말을 해야만 한다.

변수 명명규칙을 카멜 케이스에서 스네이크 케이스로 변경하기로 결정했다고 가정해보자.

이걸 몰랐다면 나중 가서 산출물을 제시할 때 된통 깨지기 마련이다.

 

나는 그걸 들은 바가 없다!

라고 말해봤자 돌아오는 대답은 뻔하다.

다른 개발자는 이미 그렇게 했다. 왜 몰랐냐?

 

여기서 이미 외통수다.

말을 더 이어봤자 나오는 말은 '의사소통에 문제가 있는 것이 아니냐?' 라는 의심어린 답변 뿐이다.

이런 것이 초반 한두 번이면 상관없다. 오고나서 적응하는 기간에는 아무도 이런 것에 의문을 가지지 않는다.

하지만 시간이 지나도 이런 사소한 실수가 발생하면 능력 자체를 의심받는다.

 

개발을 어마무시하게 잘한다면 상관없겠지만...

어마무시? 조건 자체가 일단 까다롭다. 대체불가능한, 혹은 대체하기 어려운 개발자가 된다는 것이니 말이다.

애당초 그 정도의 개발자라면 의사소통이 문제가 될리가 없다.

자신이 주도해서 개발하거나 그런 개발자는 핵심 영역에 위치할테니 당연히 정보가 들어갈테니까 말이다.

 

하지만 평균에서 위아래로 오가는, 대체가능한 개발자라면 지금 당장은 문제 없어도 지속적으로 같이 할 수 있을까?

아마 어려움이 많을 것으로 예상된다.

게다가 실력이 평이해서 지금 당장은 문제가 안되더라도 나이가 애매해지는 시점이 다가온다면 문제가 닥칠 수도 있다.

지금은 덜한다고 하지만, 예전에는 40대 중반을 넘어가면 이런 개발자는 개발자로서 삶을 이어가는 것이 살짝 애매해지는 경향이 심했다고 한다.

그래서 전직 개발자 현직 관리자로 넘어가거나 은퇴를 염두하거나 그랬다는 이야기가 들린다.

 

 

4. 사람과 의사소통

 

결과적으로 앞선 세 개의 예시 모두 사람과 의사소통하는 방법에 대한 이야기다.

말로 하는 의사소통은 그것의 극히 일부에 지나지 않는다.

 

• 산출물 (규격화된 개발문서)
• 테스트케이스
• 동료와 대화

 

이런 것들은 모두 의사소통의 일부라고 보는 것이 정확하다고 본다.

문서 자체가 말을 글로 옮긴 것이며,

테스트케이스는 내가 무언가를 했다는 것을 눈으로 보여주며,

동료와 대화는 문서와 테스트케이스에 담기지 않은 따끈따끈한 정보를 얻을 수 있는 방법이다.

 

개발자에게 의사소통은 필수다.

처음에 적었던 것과 동일한 단어지만, 쓰면서도 느끼는 것인데 처음과 끝에 느끼는 감정과 의미가 달라진다.

이렇게 생각을 정리하는 것도 정말 중요한 일이구나 새삼 느낀다.