5. 지속 가능한 개발

변화하는 환경에 맞는 개발 방법을 사용해야 합니다.

제가 처음 운전자였을 때 안 가본 곳을 갈 때는 지도를 보고, 메모를 했어야 했습니다. 어디서 어떤 도로를 타고, 몇 번째 사거리에서 어떤 회전을 한다 등과 같은 메모였습니다. 운전과 길이 모두 익숙치 않았기 때문 차선 변경을 위해서는 미리 준비를 했어야 했습니다. 심지어 시간을 꼭 지켜야 하는 경우는 미리 차로 한번 가보는 연습을 하기도 했습니다.

제 아들이 고교를 졸업하고 면허를 따고 얼마 안 되어 운전을 했을 때는 제 초보 운전자 시절과 많이 달랐습니다. 차에 타면 T맵부터 켭니다. 목적지를 입력하고는 그냥 안내대로 운전을 합니다. 뻔히 아는 길을 T맵이 좀 돌아가게 안내를 하더라도 그냥 그렇게 운전을 합니다.

조금 더 효율적이려면 T맵이 안내를 시작할 때 전체적인 경로를 보고 필요한 경우 운전자가 약간 수정을 하는 것이 좋을 것입니다. 하지만 그저 그 장소로 가는 것이 목적이라면 그냥 따라도 되겠죠.

이처럼 운전이 지도가 있을 때와 내비게이션이 있을 때 다른 것처럼 개발도 환경이 변하면서 많이 달라졌습니다. 제가 경험한 개발 환경을 토대로 설명드리겠습니다.

1. 클라이언트/서버 시대

처음 개발자로서 경력을 시작했을 때 유닉스 서버에 텔넷으로 접속해서 vi로 코딩을 했습니다. GUI 클라이언트는 윈도우즈 PC에서 개발했지만 서버 로직은 서버에 접속해서 텍스트 편집기로 개발을 하고, 빌드, 배포를 했었습니다.

이때는 세밀한 지도가 필요했습니다. 내비게이션, 스마트폰이 없던 때 어떤 장소를 찾아가기 위해 지도가 필요했던 것처럼 서버에서 텍스트 편집기로 코딩을 하려면 길을 헤매지 않기 위해 지도가 필요했던 것처럼 잘 설계된 사전 설계 문서가 필요했습니다.

사전 설계된 문서는 많은 예측에 기반했었습니다. 동작하는 코드 없이 추측을 해서 설계를 했습니다. 개발을 하고 후에 설계 결함이 발생했을 때, 고치기 어려워서(매몰비용 오류 sunk cost falacy) 설계대로 개발을 하기도 했었습니다(그래서 20%의 코드만 사용된 것 같습니다).

경쟁 상황은 매우 낮았던 것 같습니다. 전공하지 않으면 제대로 된 개발자로 일하기 어려웠고, 서비스도 대개는 특정 기업을 위한 것이 많아서 타업체와의 경쟁은 입찰 때 정도가 전부였던 것 같습니다. 그래서 일부 오류가 있더라도 심하지 않으면 사용하는 시대였던 것 같습니다.

지금 돌이켜 보면 개발 환경은 안 좋았지만 참 편안한 세상이었던 것 같습니다. 개발자가 많지 않으니 그리 경쟁이 세지 않았으니까요. 아니 안 좋은 세상이었는지도 모르겠습니다. 개발에 대한 수요도 그만큼 적었으니까요.

2. 인터넷 시대

그러다 인터넷 브라우저가 활성화되면서 여러 측면에서 경쟁이 가속화되었습니다. 95년 정도만 해도 html을 비전공자가 쉽게 만들 수는 없었습니다. 하지만 브라우저가 활성화되면서 초등학생도 만들 수 있게 변화되었습니다.

이때는 서버에 접속해서 텍스트 편집기로 개발하지 않고, 자신의 노트북에서 IDE를 이용해서 개발을 하고, 실행시켜 볼 수 있었습니다.

이때의 경쟁 상황은 이전보다는 강해졌지만 지나고 보니 그리 높지는 않았던 것 같습니다. 이때 저는 스타트업과 Daum에서 개발을 했는데, 특히 Daum에서 개발을 할 때는 경쟁자는 Naver 외에는 없는 것 같습니다. 전 국민을 상대로 높은 트래픽을 수용할 수 있는 서비스를 제공하려면 IDC가 필요했는데, 대국민 서비스를 할 수 있는 IDC를 가진 회사는 Daum, Naver 정도였던 것 같습니다.

3. 모바일 시대

그러다 iphone이 출시되었습니다. 한국에는 2009년에 들어온 것 같습니다. 이때부터는 무한경쟁의 시대가 되었습니다. 대규모의 IDC를 가지고 있지 않은 개인 사업자들도 모바일 앱을 만들어서 경쟁에 참여할 수 있었습니다.

이제 대기업도 보다 더 애자일하게 개발할 필요가 생겼다. 그러면서 "지속 가능한 서비스"에서 언급한 문제들이 발생했었던 것 같습니다. 작은 덩치로 재빠르게 움직이는 스타트업에 대응하기 위해서는 빨리 만드는 것이 중요해졌기 때문입니다. 반면 저처럼 신규 개발을 하는 만큼 기존 서비스를 운영하고 개선하는 업무를 많이 하는 사람들에게는 품질도 여전히 중요하게 되어 속도와 품질 사이의 갈등이 깊어졌었습니다.

이때 저는 XP(eXtreme Programming)에 흠뻑 빠졌던 것 같습니다. TDD로 개발을 하려고 노력을 했었고, 나중에 Mocking(Mock Roles, not Objects - jMock)을 통해 지속적으로 협력 인터페이스를 찾아서 외부(controller, service 등)에서 안(domain)으로 들어오면서 개발을 하는 Outside-in TDD 방식을 많이 사용했었습니다.

Daum, Kakao를 고치고, SKPlanet/11번가를 거치면서 이러한 갈등 속에서 이리저리 노력을 했었던 것 같습니다. 그러다 작년 6월 케이타운포유(https://www.ktown4u.co.kr/)에 합류하면서 고민의 가속화되었다. 작은 회사이고, 개발 인력도 적다 보니 속도와 품질 모두가 중요했습니다. 

저는 초기에 품질을 강조했습니다. 그러면서 고민이 들었습니다. 속도 아니 어떤 것이 정말 좋은 품질일까에 대한 고민이었습니다. 지금 내가 잘하기 위한 역량이 80점이라고 할 때, 내가 지금 90점, 100점을 받기 위해 시간을 쓰는 것이 맞을 것인가에 대한 고민이었습니다. 여러 번 생각할수록 지금은 80점을 빨리 받고, 후에 학습, 연습, 경험 등을 통해 내 역량과 도메인 지식이 많아졌을 때 90점, 100점을 받기 위해 노력하는 것이 맞다는 생각이 들었습니다.

어떤 책을 읽고 시간이 지난 후에 다시 읽어보면 안 보이던 구절이 보입니다. 그간 쌓인 지식과 경험으로 역량이 높아져서라고 생각합니다. 지금 100% 이해 안 되는 구절이 있다면 후에 다시 읽어보는 것이 좋은 방법이라고 생각합니다. 품질도 마찬가지라고 생각합니다. 지금 100%를 못 맞추더라도 주어진 일정과 리소스 내에서 내가 할 수 있는 최선을 다하고 앞으로 지속적으로 개선하는 게 맞다고 생각합니다.

지금은 동작하는 뼈대(Walking Skeleton), 수직 슬라이스(Vertical Slice)(https://github.com/msbaek/presenting-tdd 에서 3. Outside-in TDD with Vertical Slice 슬라이드 참고) 방식으로 개발하는 방법을 많이 공유하고, 그렇게 개발을 하고 있습니다. 수직 슬라이스 방식으로 구현하면 쿼리(읽기) 기능의 경우 Controller에 거의 모든 기능을 구현해서 빠르게 구현할 수 있습니다. 커맨드(변경) 기능의 경우도 최소한의 코드로 빠르게 구현을 시작합니다. 배포 후에 새로운 기능을 추가하거나 변경이 필요할 때 리팩터링을 통해 설계를 개선합니다. 리팩터링은 동작하는 코드 없이 종이나 화이트보드에 추측/가정/예측 등을 통해 진행했던 사전설계 방식과 달리 동작하는 코드를 가지고 설계를 할 수 있어서 빠른 피드백과 안정감을 줍니다.

다만 동작, 배포된 후에 필요한 경우 리팩터링을 통해 설계를 개선할 수 있는 역량이 있어야 합니다. 그렇지 않다면 설계는 빠르게 부패할 것이기 때문이다. 이런 경우라면 어쩌면 사전설계를 하는 것이 더 좋은 방법이라고 생각합니다.