개발자와 변호사, 우리 원래 같은 민족이었어?
Code로 이어지는 무시무시한(!) 평행이론
코딩
잠시 본업을 떠나 진행하고 있던 모바일 앱 프로젝트. 이런 저런 이유로 코알못인 내가 두 달 정도 실제 소스 코드를 개발자와 같이 만져야 하는 상황에 놓였다. Ruby on Rails와 React Native로 만들어지고 있던 전체 프로젝트 중 프론트 엔드의 일부를 담당하게 되었다. 어색하기만 한 맥북을 세팅하고, 안드로이드 스튜디오와 엑스코드를 설치했다. 초딩 이후 보지 않았던 터미널 화면에서 디렉토리를 만들고 명령어를 입력해서 이런 저런 설치를 했다. Aㅏ.. 오랜만에 느껴보는 Apple II 플러스의 아련한 기억.
*Apple II Plus: 애플이 1977년 발매한 최초의 개인용 컴퓨터 Apple II의 업그레이드 버전. 미국에서는 1979년 출시. 한국에 주로 보급된 애플2는 이 버전의 호환 기종이라고 한다.
응답하라 80년대. 추억이 돋는다.어쨌든 속성으로 자바스크립트 기초 강의를 1순환하고, React Native 공식 문서를 더듬더듬 읽으면서 개발자님이 만들어 놓은 코드 구조를 파악하고 내가 해야 하는 부분과 절대 만져서는 안되는 부분을 하나하나 나눈다. 그리고 내가 해야 하는 부분을 하나하나 실습(이라 쓰고 삽질이라...)을 해 보기도 한다. 그런데,
이거 어디서 많이 하던 건데?
왠지 너무 익숙한 스멜은 뭐지? 어떤 일을 할 것인지 경우의 수를 빠뜨리지 않고 정리해서 논리적 구조에 따라 목차를 만들고, 문서와 첨부문서를 만들고, 포매팅을 다듬고 문서끼리 잘 연결되어 있는지 상호참조는 잘 되어 있는지 점검한다...
계약서 쓰는 거잖아! 이렇게도 닮아 있다니.
그렇게 두 달 동안의 프로젝트를 무사히 마친 후, 우연히 모 게임회사에서 기획자로 일하고 있는 후배와 만나서 이 이야기를 했는데.
우리 개발자도 계약서 검토하더니 똑같은 얘기 하던데요? ㅎㅎ 코딩이랑 되게 비슷하다고.
오, 나만의 생각이 아니었구나.
조금 정리해 보면, 개발자가 코딩하는 것은 변호사가 계약서 쓰는 것과 되게 비슷한 점이 많았다.
1. 변수를 정의하고 함수로 결과를 리턴한다
기본적으로, 코딩이 변수를 정의하고 함수를 통해 결과를 리턴하는 것의 연속으로 이루어진다면, 계약서도 같다. "이 계약에서 '천재지변'이란 지진이 나거나 태풍이 오는 것을 말함" 이런 식으로 용어를 정의하고, 그 용어를 이용해서 "만약 천재지변이 발생하면 나는 너에게 물건을 안 보내도 너는 나에게 물건 값 백만원을 줘야 함" 이런 식의 함수(!)를 수십 수백개씩 연결해 놓은 것이라고 볼 수 있다. '천재지변'에 홍수는 정의하지 않았으니 홍수라는 이벤트에서 func(천재지변)을 호출해도 나는 상대방에게 물건을 꼭 보내야 한다.
2. 온갖 알 수 없는 디펜던시로 엮여 있다
아마도 자바스크립트 라이브러리 기반인 리액트 메이티브라서 더 심하기는 했겠지만, 처음 맥 세팅을 할 때, 그리고 코드를 보면서 가장 처음 느꼈던 두려움은 어디선가 불러오는 수많은 참조 - dependency - 들이었다. 이건 또 뭐고 저건 또 뭐지...
아마도 어떻게 엮여 있는지는 아무도 모를...깨알 같은 글씨로 수십 장, 수백 장이 넘어가는 계약서와 첨부 문서 속에 빠져 허우적대던 그 느낌이었다. 이 용어의 의미를 찾으려면 몇 조로 가야 하고 또 저 용어는 첨부 문서로 가야 하고, 또 아예 무슨 법에 따른 내용이라고 하면 그 법을 - 그나마 한국법이면 다행 - 찾아서 정확히 무슨 소린지 알아 놔야 한다.
그렇게 참조한 원본 문서나 법이 바뀌면, 계약서에 쓴 내용은 무용지물이 될 때가 있다. 코드도 마찬가지라니. 디펜던시 버전이 바뀌면 얽혀서 뻑나기도 하고, 왜 그렇게 무서운 시뻘건 에러는 많이 나던지 ㅠㅠ
3. 깔끔하고 간결한 코드를 서로 칭찬하지만 고객님은 아무 관심이 없다
개발자님들끼리 논리적으로 깔끔하고 잘 정리된 코드, 친절한 주석이 달린 코드를 칭찬하는 것을 보면서. 밤새면서 계약서의 논리적 정합성과 상호참조를 정리하던, 팀원들과 서로 소송 서면을 몇 번씩 읽으면서 앞 뒤에 모순은 없는지 검토하던 나의 모습이 떠올랐다.
하지만, 아.. 그런거 고객님은 관심 없는데 정말. 중복 코드가 많아도 잘 돌아가기만 하면 되고 계약서는 오타 작열해도 돈 주고 받는데 문제만 없으면 되고, 소송은 모순이 있건 말건 이기기만 하면 된다. 물론(!) 유지보수나 인수인계할 때는 꼭 필요하다. 첨부 문서나 증거 자료 제대로 정리되어 있지 않은 거래나 사건을 인수인계 받았을 때 얼마나 뜨악했던가. 아마도 개발자님들도 마찬가지겠지..
4. 고객님은 "이거 하나만 바꿔 주세요"라고 하지만 나는 억장이 무너진다
수십장 짜리 계약서를 몇 주 걸려 완성해 놨는데, 거래의 방향성이 '조금' 바뀌었다(...) 정해진 계약 체결은 다음 주. 재판이 내일인데 결정적인 증거가 나왔다 (사실은 고객님이 숨겨놨다가 어쩔 수 없이 꺼내 놓았다). 수만줄짜리 코드를 리팩토링까지 해서 잘 정리해 놨는데, 기획이 '약간' 바뀌었다(...) 오픈 베타 출시일은 다음 주.
문제는 고객님은 진짜 된다고 생각한다는 것중간에 뭐 하나 바꾸는 것보다는 차라리 처음부터 새로 쓰는 게 낫다. 지금까지 다 우리가 모른다고 생각하고 써 놓은 문서인데, 이제 와서 "사실은 알고 있었어요. 그 부분만 바꿔 주세요." ㅠㅠ 그 기능 절대 안 넣는다고 해서 구조 짜고 다 코딩해 놓았는데, "구석에 살짝 넣으면 안될까요?" (... 다 뒤집어 엎고 싶다)
5. Github을 쓴다
물론 변호사가 Github 그 자체를 쓰는 건 아니다. 대신 MS Word의 '변경기능추적(track change)' 기능을 쓴다. 이거 쓰는 사람은 사실 변호사 말고 아직 못 봤다. 쓰는 이유는 똑같다. 그 프로젝트의 담당 시니어(마스터)가 다른 주니어들의 문서를 합치면서 누가 뭐 바꿨나 하나하나 검토하기 위한 것. 내가 맡은 브랜치 코드를 Github을 이용해서 원래 개발자님의 마스터 코드에 붙이는 기능을 실행하면서 든 생각은,
'오호 이거 MS워드보다 좋은데? 왜 변호사는 이런거 없지?'
Github은 진짜 편리했다. 게다가 무료라니.
이렇게 비슷한 덕분인지 두 달 동안의 협업 프로젝트를 무사히 마치고, 이제 개발자들을 조금 이해할 수 있겠다는 안도의 한숨을 쉬고 있었는데, 우연히 눈에 들어온 아래 단어에 등골이 서늘해졌다.
함무라비 법전 = Code of Hammurabi
CODE?!?
그, 그래서 비슷했던 거냐...
너는 3등 나는 5등^^;; (우편번호가 1등)
