소프트웨어 전문지 기자에서 다시 개발자로 돌아온 지 어느새 6개월째다. 6년간 일했던 개발자 세계에 이제는 다시 적응했다고 말할 수 있다. 내가 짠 코드가 제품에 들어갔고, 제품을 사용하는 고객이 있으니 개발자로서 참 뿌듯한 일이다.

다양한 경험을 추구한다. 새로운 분야는 물론, 경험한 분야를 지속하는 것에도 관심을 둔다. 이 글은 어느새 채널예스에 작성하는 일곱 번째 칼럼이다. 기자에서 개발자로 돌아왔지만, 어렵게 얻은 생산 능력을 놓고 싶지 않아 글쓰기를 지속하고 있다.

하지만 다양한 경험을 추구하는 것이 마냥 행복하지만은 않다. 얻은 것을 손에 쥐는 것이 꼭 올바른 선택이라 생각하지도 않는다. 모든 선택에는 기회비용이 있고, 감당해야 할 고통도 따른다. 모든 선택은 내 상상처럼 그저 행복하지만은 않기 때문이다.

신입 개발자 시절, 나는 월요일이 두려웠다. 월요일 아침에 출근하면, 금요일에 짜던 코드가 생각이 나지 않았다. 나는 월요일마다 지난 금요일의 나를 만나는 주문을 외웠다. 익숙지 않던 프로그래밍 세계는 내 현실 세계와 너무도 달랐다. 내가 만든 세계(코드)임에도 그랬다.

1년여 만에 다시 개발자로 돌아온 지난 5월에는 프로그래밍 세계로의 여행이 정말 쉽지 않았다. 그동안 기술도 많이 발전했고, 심지어 내가 경험을 쌓은 안드로이드 개발이 아닌 웹 프론트엔드, 백엔드 기술을 사용해야 했다. 익숙지 않아 서툴고, 감을 잃게 된 프로그래밍 세계에 다시 적응하기까지 많은 언덕을 넘어야 했다. 이 글에서는 1년여 만에 다시 돌아온 프로그래밍 세계와 현실 세계에 관해 나눠본다.

프로그래밍 세계에 빠진 채 현실을 사는 사람

기자 시절, 나는 주로 소프트웨어 개발자를 만나 이야기를 들었다. 커리어 대부분을 안드로이드 개발자로 살았기에 내가 이해할 수 있는 기술 범위는 매우 좁았다. 프로그래밍 언어도 자바(Java)와 파이썬(Python) 외에는 거의 읽을 수 없었다. 개발자 이야기에 귀 기울일 수 있었던 것은 내가 경험하지 못한 기술에 관한 존중이었다.

소프트웨어 개발은 발전이 빠른 분야다. 시스템을 설계하고, 비즈니스 로직을 풀어내는 것은 경험과 도메인의 힘을 빌릴 수 있지만, 기술적인 부분은 빠르게 학습하는 능력이 필요하다. 이 세계에서는 러닝 커브(Learning Curve, 학습 곡선)라고 한다. 러닝 커브는 이 세계에서 굉장한 능력치다. 빠르게 습득해 실전에 활용할 수 있는 것만으로 충분히 훌륭한 인재가 될 수 있다. 그 때문에 내가 경험하지 못한 기술을 다루는 사람은 충분히 존중할 가치가 있다. 내가 하지 못하는 방법으로 세상에 기여를 하고 있기 때문이다.

하지만 이를 이용하는 사람들이 있다. 내가 먼저 겪었다는 이유만으로 상대를 무시하고, 속이는 사람들이다. 한 번은 신기술 분야에서 취재하는데, 안드로이드 앱에 관해 과장하는 개발자를 만났다. 우연히 내가 그나마 이해하는 안드로이드 분야라 조금 깊이 물어봤다. 그 개발자는 말해줘도 모른다며, 아무튼 대단한 기술이라고 허풍을 떨었다. 프로그래밍 세계에 빠진 채 현실을 살면, 이런 문제에 빠질 수 있다. 자신이 마주한 세계 외 다른 세계는 중요치 않다고 생각하는 것이다. 개발자 중에는 이런 외골수가 종종 있다.

비슷한 사례로는 신입 개발자 시절 한 상사의 이야기가 떠오른다. 당시 주말에 출근해 일하고 있는데, 상사가 옆자리로 부르더니 당시 하고 있던 업무를 자랑했다. 하지만 그가 만들던 기능은 당시 프로젝트에 쓰일 기능이 아니었다. 내가 이 기능은 지금 사용될 기능이 아닌데 왜 만들고 있느냐 묻자, 언젠가 쓰일 거라며 자랑스러워했다. 바쁜 프로젝트 기간에 언젠가 쓰일 기능 개발이라니, 현실을 놓치고 있는 사례다.

마지막으로 내가 경험한 충격적이었던 사례 중 하나를 소개하고 싶다. 프로젝트를 진행하던 중 우리 서비스를 함께 운영할 사람이 새로 뽑혔다. 애플리케이션 하나에 한 팀은 새로운 기능 추가를, 한 팀은 유지 운영을 하게 됐다. 다시 생각해도 끔찍한 프로세스다.

당시 나는 새로운 기능 추가를 하고 있었고, 유지 운영을 하는 문제의 개발자를 만났다. 며칠 뒤 그 개발자가 지금 모든 기능이 되지 않는다고 말했다. 나는 그 부분을 건들지 않았기 때문에 굉장히 의아했다. 알고 보니 당시 우리가 사용하는 IDE(Integrated Development Environment, 통합 개발 환경)를 베타(Beta) 버전으로 업그레이드해 버린 것이었다. 베타 버전은 아직 모든 버그가 수정되지 않은 불안정한 버전이다. IDE는 개발 도구로 버전이 변경되면 기능이 작동하지 않을 우려가 있다. 특히 내가 사용하던 환경은 그랬다.

그 개발자는 자신은 신기술을 사용하고 싶다며 그 버전을 사용해야 한다고 주장했다. 현재 기능이 작동하지 않는데도 그는 신기술을 적용해야 한다고 말했다. 결국, 프로젝트 코드를 따로 관리하기로 했다. 그가 유지보수를 하는 코드와 우리가 새로운 기능을 개발하는 코드가 달랐다. 그는 우리 코드를 받아서 수작업으로 코드를 합쳤다. 여전히 이해되지 않는 프로그래밍 세계에 빠진 채 현실을 사는 사람이다.

『유지보수하기 어렵게 코딩하는 방법』

『유지보수하기 어렵게 코딩하는 방법』  의 저자 로에디 그린(Roedy Green)은 내가 소개한 사례보다 더 많은 충격적인 이야기를 들려준다. 아니, 내가 경험한 이야기를 정말 사소한 '버그' 정도로 만든다. 책에 적힌 몇 가지 재미난, 아니 창의적인 괴롭힘을 소개한다.

개발자를 괴롭히는 창의적인 방법

『유지보수하기 어렵게 코딩하는 방법』  에는 개발자를 괴롭히는 수많은 방법을 소개한다. '이렇게 창의적일 수 있나!?' 하며, 눈이 번뜩 띈 몇 가지 방법을 소개하고 싶다. 이해를 돕기 위해 개발에 서툰 ‘초보 개발자’를 가상으로 만들어 이야기를 만들어본다. ‘초보 개발자’는 정말 순박한 개발자다.

1. 추상화하라

소프트웨어 기획은 늘 변경되기 마련이다. 공지사항 게시판(Notice)을 만든 뒤 자유게시판을 추가한다고 하자. 개발자는 공지사항 게시판을 복사해서 자유게시판(Free)을 만든다. ‘초보 개발자’는 게시판 화면을 같은 소스에서 분기문으로 처리한다.

‘초보 개발자’는 공지사항과 자유게시판을 구분할 수 있는 여러 가지 방법을 가지고 있다. ‘초보 개발자’는 공지사항인지, 아닌지 구분하기로 했다.

if(boardType == it){
   // 공지사항 게시판
}else {
   // 자유게시판
}

▲ 공지사항을 그것(it)으로 표현하기로 했다. 게시판 타입이 그것이면, 그것이 아니면 자유게시판이다.

‘초보 개발자’는 위 코드로 개발에 성공했다. 그리고 다음 날 새로운 게시판 개발 요청을 받았다. 질문 게시판을 만들라는 것이다. ‘초보 개발자’의 고통이 시작된다.

"가능한 한 it, everything, data, handle, stuff, do, routine, perform, 숫자 등과 같은 추상적인 단어를 변수명이나 함수명에 많이 사용하자.

(좋은 예, routineX48, PerformDataFunction, DoIt, HandleStuff, do_args_method)

▲『유지보수하기 어렵게 코딩하는 방법』 중

2. 이유는 빼고 ‘어떻게’에 대해서만 문서화하라

‘초보 개발자’는 주간 회의에서 팀장님에게 혼이 났다. 주석을 달지 않아 혼이 난 것이다. 주석을 달아야 한다고 수 차례 되뇌며 자리로 돌아갔다. 자리에 앉자마자 옆 팀 ‘중수 개발자’가 다가와 업무를 던지고 간다.

중수 개발자 : ‘초보 개발자’씨, 어제 만든 자유게시판에 댓글 기능 추가해주세요.

초보 개발자 : 네!

‘초보 개발자’는 팀장님의 이야기를 잊지 않았다. 냉큼 게시판 파일을 찾아서 주석을 달아둔다.

// TODO 댓글 추가해야 함!!

다음 날 ‘초보 개발자’는 공지사항 게시판에 댓글 기능을 추가했다.

프로그램이 무엇을 하는지에 대한 세부 사항 그리고 프로그램이 무엇을 달성하지 않는 것인지에 대해 문서화하라. 버그가 생기면 수정을 담당하는 프로그래머는 해당 코드가 무엇을 수행해야 하는지 알 수 없게 된다.
▲『유지보수하기 어렵게 코딩하는 방법』 중

3. 쉽게 찾지 못하게 숨겨라

‘초보 개발자’는 빨간색 아반떼를 구매했다. 생애 첫차를 산 ‘초보 개발자’는 빨간색 아반떼가 세상에서 제일 예쁘다고 생각했다. ‘초보 개발자’는 노란색 하면 BMW가, 파란색 하면 벤츠가 떠올랐다. 물론 BMW보다, 벤츠보다, 빨간색 아반떼가 좋았다. 빨간색 아반떼는 ‘초보 개발자’에게 있어 최고다.

‘초보 개발자’에게 다음 업무가 생겼다. 게시판에 회원 등급을 보이게 하는 것이다. 순차적으로 빨간색, 파란색, 노란색으로 ‘초보 개발자’는 확신에 찬 표정으로 코드를 짰다.

if(200 > member.postCount >= 100) {
   member.color = Avante;

} else if(100 > member.postCount >= 50) {
   member.color = Benz;

} else {
   member.color = BMW;
}
▲누구나 쉽게 알아볼 수 있는 코드

누구나 쉽게 알아볼 수 있는 코드가 완성됐다.

16진수 값 $0204FB를 할당할 상수 변수명으로 blue 대신 LancelotsFavouriteColour와 같은 이름을 사용하라. 화면에는 완전한 파랑색이 나타나겠지만, 유지보수 프로그래머는 0204FB값을 판독(아마 그래픽 도구를 이용해서)해야 의미를 파악할 수 있을 것이다. 몬티 파이썬의 성배(Monty Python and the Holy Grail)라는 1975년 영국 영화를 좋아하는 광팬이라면 랜슬롯(Lancelot)이 좋아하는 색이 파랑색이라는 사실쯤은 금방 알아차릴 수도 있을 것이다. 몬티 파이썬의 성배 영화 전체 내용을 기억하지 못하는 유지보수 프로그래머가 있다면 프로그래머로서 자질이 없는 분이라고 생각할 수밖에 없다.
▲『유지보수하기 어렵게 코딩하는 방법』 중

‘초보 개발자’는 순박한 개발자다. 결코 위 코드에 악의는 없다.

프로그래밍은 현실에서 할 수 있다

나는 개발자로 4년을 일한 뒤 창업했다. <도밍고 컴퍼니> 대표였던 나는 뉴스 큐레이션 서비스 <도밍고 뉴스>를 만들어 대한민국 미디어 시장에 한 획을 긋는 큰 포부가 있었다. 물론 망했다.

당시 나는 개발하지 못하는 대표자를 많이 봤다. 개발자인 나는 그들과 비교했을 때 더 낫다고 생각했다. 이유는 그들이 개발자를 구하러 다닐 시간이 내가 개발하는 시간보다 더 오래 걸린다고 생각했기 때문이다. 사실 나도 순박하다.

첫 커리어 4년을 개발자들과 가장 많이 보냈다. 주변 대부분이 개발자였고, 내 앞으로 커리어도 개발자였다. 개발자로 사는 것에 관심이 있었고, 개발자로 사는 게 당연했다. 개발자 세상에 살았다.

스티브 잡스와 빌 게이츠, 마크 저커버그가 '코딩 교육'의 필요성을 외쳤다. 나는 이미 코딩 교육을 받아 개발자가 됐으니, 나야말로 준비된 글로벌 인재가 아닌가? 스타트업 시장은 늘 개발자가 부족하다고 했다. 새로운 것을 경험하고 싶었고, 이왕 스타트업에 갈 거면 내 아이디어로 제품을 만들어보고 싶었다. 난 순박한 글로벌 인재가 아니던가?

자본주의 시장에서 고객이 원하는 소프트웨어 제품을 만들어 판매하는 것은 굉장히 섹시한 비즈니스다. 수십 명이 모여 몇 달 고생하면, 수백만, 수천만 고객의 시간을 아껴줄 수 있다. 이 과정에서 실제 소프트웨어 제품을 만드는 것은 개발자다.

하지만 개발자는 분명히 알아야 한다. 제품은 결코 혼자 만들지 않으며, 제품은 고객을 위한 것이다. 개발자의 코드는 혼자 만들지 않으며, 코드는 고객을 위한 것이다. 프로그래밍 세계에 빠질 사람이 많이 필요한 시대다. 하지만 기억하자. 프로그래밍은 현실에서 할 수 있다.