2010년의 카카오에서 있었던 일 1편

개발자의 덕목

‘카카오에서 있었던 일’이라는 주제로 몇 개의 글을 쓰고자 한다. 이 글은 그 중 첫 번째 글이다. 나는 카카오톡 프로젝트를 꽤 초기에 참여했지만 주역은 아니었고 돕는 개발자였다. 카카오톡 초기 개발자들에 대한 이야기가 어디에도 없는거 같아 옆에서 그들을 바라본 입장에서 글을 써보기로 했다. 기억에 의존해서 작성하는 글이라 정확하지 않을 수 있지만 고쳐나가겠다.

2010년 4월에 카카오에 입사했었는데, 지금 생각하면 그때 나는 정말 많이 부족했었다. 아마도 발전 가능성을 보고 채용해주었던 것 같다. 그때 카카오톡은 아이폰 버전만 있었고, 국내에 아이폰이 출시된지 5개월이 안되었었고, 갤럭시S는 출시 전이었다.

2010년 여름 전에 사수였던 루니(정상영님)와 카카오톡 아이폰 개발을 하고 있었다. 주요 과제는 2010년 3월에 런칭되었던 카카오톡의 디자인을 변경하는 것과 이후 발전을 위해 리팩토링하는 것이었다.

루니는 로컬 디비 설계를 변경하고, 데이터를 다루는 코드를 Core Data로 변경하고, Core Data에 최적화된 코드 세트들로 UITableView, UISearchBar 등을 다시 작성하고, 데이터의 변화에 따라 뷰를 변경하는 등 효과적으로 앱의 상태를 관리하자고 제시했다. API 통신은 자체적으로 구현한 라이브러리로 적용하고 싶어했고, 최대한 iOS SDK 그대로를 사용하고 싶어했다.

루니는 가장 어렵고 중요한 부분인 로컬 디비 설계와 마이그레이션, 그리고 채팅탭과 메시징을 전부 다시 작성했다. 나는 그것을 제외한 친구 목록, 연락처 동기화, 친구 차단, 프로필 변경, 대화 내용 백업 등을 다시 작성했고, 밥이 새로 디자인해준 이미지들을 적용했다.

잘 동작하는 루니의 코드를 루니가 이미 충분히 검증한 스택으로 변경하는 일이었고, 아이폰 SDK가 워낙 잘 만들어져 있었기 때문에, 내 몫은 그리 어려운 것이 아니었다. (그때 난 정말 어려웠지만…)

당시 나는 코딩을 정말 못했다. 그냥 생각없이 돌아가게만 막 ‘키보드 타이핑’을 했었다. 어느날 내가 커밋한 코드를 루니가 보고서는 내게 따끔한 충고를 했다.

이 기능을 구현할 때 이 메서드를 쓰는게 가장 적합하다고 생각해? 대충하지 말고 가장 어울리는 메서드가 뭔지 고민해서 적용하라구!

3개월 짜리 프로젝트를 1달 반 동안 급하게 개발하고 테스트 및 버그 수정을 1달 반 동안 하는 개발자들이 많은데, 난 그렇게하지 않아. 3개월 동안 천천히 집중해서 개발하고 버그 없는 제품을 만들어서 결과적으로 ‘테스트 기간’이 필요 없게 만들지. 고민안하고 대충 빨리 만들어서 ‘디버깅 기간’을 따로 써야한다면 결과적으로 빠른게 아니야. 난 개발자의 최고 덕목이 이해력이나 센스나 빨리 만드는 능력이 아니라 꼼꼼함이라고 생각해.

코딩을 할 때 가장 적합하고 잘 맞는 메서드와 기법을 사용하려고 애쓰란 말야.

넌 iOS SDK 코드 읽어봤어? 난 다 읽어봤어. 얼마나 아름다운지 알아?

이런 충고를 처음 듣고 너무나 맞는 말이라고 생각했지만, 프로젝트를 진행하는 동안에는 그냥 충고 정도로 생각했었다. 얼마 되지 않아 2010년 여름에 리팩토링 된 카카오톡이 완성됐다. 루니의 말처럼 별도의 ‘테스트 기간’없이 카카오톡 아이폰 앱은 업데이트가 되었고, 사용자들은 문제 없이 메시지를 주고 받았다. 거의 전체 코드가 다시 작성되었음에도 불구하고 말이다. 그것을 눈으로 보고나니 앞선 충고가 정말 깊이 들어왔고, 맘속에 큰 동요가 있었다. 동시에 좌절도 있었다.

“와.. 저 사람.. 그리고 저 사람들 다 너무 멋있다. 난 뭐냐 정말..”

루니는 iOS SDK 구조와 동작, 그리고 컨셉에 대한 정확한 이해를 토대로 코드를 작성했다. 라이브러리를 가져다쓰기보다는 충분히 검증된 기본 SDK의 조합을 통해 문제를 해결하려고 했다. 남의 코드를 어떻게 믿냐고 했다. 당시엔 아이폰 개발 시장은 초기 단계였고, 라이브러리들이 검증되었다고 보기도 어려웠던 것도 사실이다. 책도 별로 없었고 검색해도 많은 아티클이 나오지 않았다. 그런 상황에서도 루니는 정말 좋은 코드를 작성했다. 간결하고 군더더기 없고 안전한 코드로 여러 문제들을 관리했다.

그 때의 루니의 충고는 아직도 내게 중요하고 큰 기준으로 남아있다. 그 후 혼자서 아이폰 개발을 할 때 iOS SDK를 천천히 읽어보게 되었고, 아름답다는 말이 어떤 말이었는지도 느끼게 되었었다. 라이브러리나 프레임워크 등을 가져다 써보기전에 반드시 선행되어야하는 것은, 내가 다루어야 하는 것들에 대해 정확히 이해하는 것이다.

지금 같이 일하는 친구들과도 종종 루니가 이런 말을 했었다며 얘기한다. 이게 가장 적합한 메서드였냐고. 혹시 루니 귀가 가려울까. 크크.

함수형을 하고나서도 비슷하다. 가장 어울리는 함수인지. 가장 간결한 해결책인지. 가장 효과적으로 동작하는지. 믿을 수 있는지. 안전한지.

무엇을 사용하는지가 개발자의 수준을 가르지 않는다. 사용자에게 전달되는 가치가 없다면 그 코드의 생산성은 제로이며, 일정 내에 잘 동작하는 제품을 만드는 것이 동료와 조직을 진정으로 위하는 길이다. 꼼꼼함. 늘 기억하는 단어다. 루니에게 계속 고마움을 가지고 있다.