[IBM Life (3)] 왜 ‘좋은 코드’를 이야기할까?

* 스타트업 전문 매체 벤처스퀘어에 발행된 IBM 인턴기 제 2화입니다. 게재본은 여기서 보실 수 있습니다. 이 포스트의 내용은 글쓴이 개인의 의견일 뿐이며, IBM의 공식 입장과는 상관이 없음을 밝힙니다.

퀴즈: 출장 명령서 쓰기

문제 하나 내겠습니다. 지금 여기 출장 명령서가 두 장이 있습니다. 말 그대로 출장을 간 사람이 해야 할 일들을 기술해 놓은 문서죠. 둘은 의미상 똑같습니다만, 쓰여 있는 방식은 완전히 다릅니다. 편의상 1, 2라고 하겠습니다. 1과 2 중 어느 쪽이 더 바람직할까요?

1.

지금부터 실리콘밸리 출장을 다녀오세요. x일 y시에는 A사와, z일 w시에는 B사와 미팅이 있습니다. 간 김에 그곳에서 요즘 뜨고 있는 iPad App에는 어떤 게 있는지도 좀 봐주시구요. 출장 결과는 메일로 갑, 을, 병, 정씨에게 보내주시고, 소제목은 12pt로, 아래 내용은 10pt로 작성하시면 됩니다. 요즘은 안드로이드 플랫폼도 중요해지고 있으니까 그 쪽에 대해서도 알아보는 것 잊지 마시구요. 물론 정해진 미팅 처리하는 게 우선이니 이건 남는 시간에 해주시는 게 좋을 것 같습니다. A사 임원들은 ...한 것 정말 싫어하니까 주의하시구요. 보고서 형식은 미팅 대상 - 안건 - 협의사항 - 추후 해야 할 일 순서입니다. 내친 김에 최근 수요가 높은 인력이나 스킬에 어떤 것이 있는지도 좀 알아봐주세요. 특히 B사 사람들은 점심을 먹을 때도 난상 토론을 하는 습관이 있으니 미리 가서 함께 피자라도 먹으면서 이야기하면 많은 것을 알 수 있을 겁니다. 남는 시간에 현지에서 잘 팔리고 있는 gadget등에 대해서도 좀 알아봐주세요.

2.

1. 출장지로 이동한 뒤 별도 문서로 주어진 미팅 스케줄을 최우선으로 처리할 것.

2. 남는 시간에는 최신 트렌드를 파악할 것.

   • 현지에서 잘 팔리고 있는 gadget.

   • 인기가 있는 애플리케이션이나 서비스. (iOS / Android)

   • 수요가 높은 인력이나 스킬.

3. 보고서 작성 방법은 x번 매뉴얼에 있음. 협력사와의 업무 처리 요령 및 주의사항은 y번 문서를 참조할 것.

정답은 2입니다. 의미야 똑같은데 왜 한 쪽은 바람직하고 다른 한 쪽은 안 그렇다고 하는 것일까요? 여기엔 이유가 있습니다.

'좋은 명령서'

첫째, 2는 유연(flexible)합니다. 기본적으로 출장지에서 해야 할 일은 잘 변하지 않습니다. 협력사와 처리해야 할 일을 우선 완료하고 남는 시간에는 트렌드를 파악하는 것이죠. 하지만 만나야 할 대상 그리고 남는 시간에 알아봐야 할 최신 트렌드는 매번 바뀝니다. 즉, 2는 변하는 부분과 변하지 않는 부분이 잘 나뉘어져 있습니다. 1은 출장을 보낼 때마다 해당 부분들을 일일이 고쳐줘야 하지만 2는 그럴 필요가 없습니다. 출장 스케줄 그리고 추가적으로 알아봐야 할 트렌드에 대해 적은 쪽지 하나 끼워 주면 됩니다. 쪽지만 바꾸면 수십 명한테 서로 다른 출장 명령을 내릴 수 있습니다.

둘째, 2는 의도가 명확히 보입니다. 출장지에서 무엇을 해야 할지(what)에 집중하고, 보고서를 어떻게 써야 하는지 혹은 사람을 어떻게 만나야 하는지(how) 등에 대한 내용은 다른 곳으로 떼어 놓았기 때문(separation of concerns)입니다. 1의 경우 전체적인 내용을 파악하기 어렵기 때문에, 어지간히 익숙한 사람이 아니면 고치기 어렵습니다. 그러고도 십중팔구 실수를 하기 마련이지요. 하지만 2는 그럴 일이 없습니다. 한 번에 전체적인 구조가 싹 보이거든요.

셋째, 2는 고치기가 쉽습니다. 서로 연관된 내용은 잘 응집되어 있는 반면(high coherence) 서로 상관없는 내용들은 덜 결합되어 있기(low coupling) 때문입니다. 이런 명령서가 30장쯤 있다고 생각해 보죠. 만약 써야 하는 보고서 형식이 조금 바뀐다면 어떻게 될까요? 1의 경우 30장을 붙들고 하나하나 다 고쳐야 합니다. 그만큼 실수가 날 확률도 높아지죠. 하지만 2의 경우는 그렇지 않습니다. 그냥 별도로 있는 보고서 작성 방식 매뉴얼만 고치면 됩니다. 보고서를 어떻게 써야 할지, 미팅 상대에 따른 주의 사항 등이 분리되어 있기 때문에 이것이 가능합니다.

넷째, 2는 여러 명이 동시에 손댈 수가 있습니다. 예를 들어 5명이 동시에 이 명령서를 고치고 있다고 생각해 보죠. 1의 경우 한 명이 뭔가를 고치면 나머지 네 명이 도대체 어디가 바뀐 것인지 일일이 확인해봐야 합니다. 시간도 오래 걸리고 손발이 안 맞아서 문서가 엉망이 될 가능성도 높죠. 하지만 2는 금방 보입니다: "어, x번 항목 바뀌었네." "2번 아래 하나 추가됐는데?" 변경점이 명확히 드러나도록, 집단 작업에 적절한 형식(coding convention)에 맞게 작성되어 있기 때문입니다.

전체적으로 말하면, 2는 1보다 더 유연하고, 집단 작업에 적합하며, 변화에 대처하기 쉽습니다.

'프로그램'='명령서'

스타트업을 하시는 분들의 대부분은 소프트웨어를 만들고 계실 겁니다. 그런데 소프트웨어의 정의를 알고 계신 분 혹시 계신가요? 소프트웨어란 컴퓨터가 알아듣고 주어진 일을 할 수 있도록 일정한 체계를 갖추어 작성한 명령서입니다. 즉, 위에서 말한 출장 명령서와 본질적으로 완전히 동일한 물건인 겁니다. 아니, 정확히 말하자면, 소프트웨어 쪽의 사정이 훨씬 나쁩니다. 현실의 출장 명령서는 잘 바뀌지도 않고 사람이 수행하기 때문에 잘못된 내용이 있어도 금방 눈치챕니다. 하지만 소프트웨어는 자주 바뀌고, 결정적으로 융통성이라고는 약에 쓸래도 없는 멍청이(=컴퓨터)가 수행합니다.

사실 한 번에 완성되서 더이상 고칠 필요가 없는 프로그램은 굳이 1, 2번의 차이가 존재하지 않습니다. 하지만 절대 다수의 소프트웨어는 일부를 구현하고, 이를 반복해서 수정하는 방식으로 구현됩니다. 그렇기 때문에 코드가 1번과 같은 방향으로 가고 있는 것은 설령 당장 주어진 구현 사항들이 완벽히 구현하고 있다고 하더라도 바람직하지 않습니다.¹ 조만간 파국이 닥칠 게 분명하기 때문이지요. 그렇기 때문에 어느 정도 책임감이 있는 프로그래머들은 코드를 가능하면 2번처럼 유지하려고 노력합니다. 데드라인을 맞추기 위해 급히 작업을 하다 보면 1번 쪽으로 가기 마련이지만, 일단 데드라인에 맞춰 완성품을 넘기고 나면 코드를 수선해서 2번처럼 만들어 놓지요. 이 작업은 겉에서 보이는 기능이 전혀 변하지 않게 하는 한도 내에서 진행되기 때문에, 비개발자 분들은 개발자가 뭘 한 건지도 모릅니다. 사실, 이게 문제의 근원이지만요.

동상이몽

당연한 얘기지만, 사람들은 서로 다릅니다. 그렇기 때문에 서로 이해하기 어려운 부분이 있을 수밖에 없습니다. 함께 일하고 있는 개발자와 비개발자도 예외가 아닙니다. 하지만 제 경험에, 비개발자가 개발자를 가장 이해 못하는 부분은 바로 이것이더군요: '좋은 코드가 어떤 코드이고, 왜 필요한가?'

별 것 아닌 것처럼 보일지도 모릅니다. 그런데 여기서 의외로 많은 커뮤니케이션 문제와 갈등이 발생합니다. 개발자는 코드를 2번처럼 유지하는 것이 매우 중요하다는 것을 알고 있기 때문에, 어떻게든 어느 정도의 시간과 노력을 투자하려고 합니다. 하지만 비개발자 눈에는 이건 필요도 없고, 왜 하는지도 모르는 일입니다. 겉으로 보기엔 바뀌는 게 전혀 없기 때문에, 개발자가 코드 붙들고 덕후짓을 하고 있는 것처럼 보이기도 합니다. 시간만한 자원도 없는데, 이걸 어디에 써야 할지를 놓고 동상이몽이 벌어지는 겁니다.

그리고 이걸 놓고 본격적으로 옥신각신하기 시작하는 순간, 사고는 터집니다. 개발자 입장에서는 자기 책임을 다하기 위한 노력이 무시당한 것이거든요. 웃는 얼굴에 침을 맞고도 기분 좋은 사람은 없습니다. 개발자의 능력이 좋다면 사태는 더 심각해집니다. 끼리 끼리 논다고, 이 사람의 친구 역시 잘 나가는 개발자거든요. 그 친구가 어느 새 다가와서 속삭이기 시작합니다: "너를 무시하는 사람들하고 일하는 건 그만둬. 스타트업 같은 건 집어치우고 대우 좋은 우리 회사로 오렴." 우스워 보이시나요? 저는 핵심 개발자가 빠져나가면서 반쯤 와해된 팀을 몇 개나 봤습니다. 남은 분들하고 이야기를 해 보니 왜 그런 일이 벌어졌는지 대강 보이더군요.

커뮤니케이션의 조건

제가 개발자라고 해서 무조건 개발자 편을 들려는 것은 아닙니다. 개발자 말이 다 맞으니 무조건 들으라는 것도 아닙니다. 하지만 이 말만은 하고 싶었습니다. 개발은 단순히 눈에 보이는 결과물만 만드는 작업이 아니라는 겁니다. 밖에서는 보이지 않는 부분, 그게 있는지도 모르는 부분에 상당히 많은 시간과 노력이 투자됩니다. 이 점만 염두에 둬도 개발자와의 커뮤니케이션에서 발생하는 갈등의 상당 부분은 예방 가능하다는 게 제 생각입니다.

저는 협업의 기본은 커뮤니케이션이라고 생각합니다. 커뮤니케이션의 기본은 이해겠지요. 제 글이 코드를 볼 줄 모르는 비개발자 분들이 개발자를 이해하는 데 조금이나마 도움이 될 수 있다면 더 바랄 게 없겠습니다.

* 사진 설명: 다양한 대문자 C 서체.