개요

회사에서 열심히 개발 중입니다. 그러나 지금 스스로 무엇을 개발하는지에 따라서 개발 전략을 적절히 선택해야 합니다.

개발을 하다가 문득 한발짝 물러나 세종대왕의 영혼에 빙의되어 나를 지긋이 바라봐야 합니다. 21세기 대한민국에서 너는 지금 뭘 하고 있느냐? 아… 저는 OOO 라는 제품을 만들고 있구요, 그런데 지금 테스트를 짜다가 뭔가 멋진 테스팅 라이브러리를 발견해서 이것저것 시험하며 신기술에 감탄하고 있었습니다.

!!!

그렇습니다. 깨닫고야 말았습니다. 중요한 건 프로젝트를 성공적으로 만드는 것! 고객을 만족시키는 것! “주어진 시간은 한정적이다. 그 안에 최대한 가성비 있게 진행해야 하는 것이다.” 라고 또 마음의 소리가 들려옵니다.

내 맘대로 개발전략

개발 전략이 아래와 같이 세 가지가 있다고 가정합시다. 그리고 동일한 자원을 투여했을 때의 성과를 단순히 숫자로 표기하겠습니다.

• 마구잡이: 초단기 프로젝트 전용입니다. 프로토타입 수준으로 고객의 실제 반응을 보기 위한 MVP 모델을 구현하는 데 집중합니다. 프로토타입인 만큼 제대로 동작하는 것처럼 보이게끔만 한 것도 많을 겁니다. 한 달에 하나를 만들어낼 수 있다면 이론상 1년에 12개의 프로덕트를 검증해낼 수 있을 겁니다. 만약 프로젝트를 계속하겠다고 결정한다면 코드 전체를 덜어내고 처음부터 짜는 게 더 나을 겁니다.
• 적당히 하기: 중단기 프로젝트 전용입니다. 실제로 잘 동작하는 프로덕트를 만들되, 대규모 처리라든지 비용에 대한 생각을 좀 덜합니다. 실제로 고객들에게 반응이 있는지 확인하기 위해서 3,000 만큼의 대규모 트래픽 처리와 같은 건 다른 솔루션을 이용하거나 크게 신경쓰지 않습니다. 실제로 동작하지만 막 벌린다는 느낌이랄까요? 확장성을 크게 고려하지 않지만 빈번한 로직 교체를 염두해두면서 개발합니다.
• 장기: 이미 어느정도 타당성이 검증된 프로젝트. 의뢰인과 프로그래머가 비교적 명확히 구분될 수 있는 프로젝트입니다. 많은 이야기를 하고 많은 방법들을 검증하고 일정을 잘 잡고 등등… “실용주의 프로그래머”와 같은 책에 나오는 전략을 채택하기 어렵지 않습니다.

지금 소개하는 세 종류의 개발 전략은 스타트업에서 2년 정도 일한 제 마음속의 기준임을 확실하게 선언합니다. 정말 주관적이란 뜻입니다. 객관성을 극대화한 연구같은 게 아니므로 그냥 에세이처럼 받아주시길 바랍니다.

마구잡이는 초단기에서 가장 큰 성과를 냅니다. 적당히 하기는 6개월 정도의 기간에서 최대한의 성과를 내고, 최적의 전략을 선택한다면 장기적으로 가장 큰 성과를 냅니다. 흠. 마구잡이 개발을 MVP 모델 검증을 위한 프로토타입 수준의 개발이라고 소개했는데, 사실 프로토타입은 조금 더 짧은 시간에 내놓을 수 있으면 좋을 거 같기도 합니다. 1~2주만에!

적당히 하자

여하튼 이 글에서 제가 집중하고 싶은 부분은 “적당히 하기”입니다. 6개월의 시간에 최대한의 성과를 내야 합니다. 그렇게 하려면 어떻게 해야 할까요?

코드를 이상하게 짜는 것과 잘 짜는 것 사이에 시간과 노력의 차이가 거의 없을 때, 당연히 잘 짜놓는다면 좋을 거예요. 습관을 들이는 데 좀 시간이 걸릴 수도 있지만, 그래도 가장 가성비가 높은 행위이지 않을까 싶습니다.

생각나는 대로 두서없이 작성해봅니다.

• 코드 작성이 마구잡이가 되어서는 안됩니다. 변수명 잘 짓기, DRY 원칙 지키기 (한쪽을 수정하면 다른 쪽도 수정해야 하는 상황 피하기), 일관성 있는 코드 스타일 등등…
• 코드 단계에서 챙길 수 있는 성능(반응성)은 미리 챙깁니다. Promise 를 순차적으로 기다리지는 맙시다…
• 목에 칼이 들어오기 전까진, 남들이 하지 말라고 하는 패턴은 하지 맙시다. 예를 들어 CSS에서 !important 쓰기… 정 어쩔 수 없다면, // TODO: ~때문에 어쩔 수 없이 쓰지만 수정 필요!!! 라고 주석을 달아놓는 수밖에요.

그 외에 적당한 수준에서 실리를 취하려고 합니다.

• 엣지 케이스에 대한 민감도를 -1 합니다. 보통은 일반적인 요구사항이 더 우선순위가 높으니까요. 비교적 흔한(?) 엣지 케이스에 시간과 노력이 많이 들어간다고 하면, 설계가 잘못되었다는 뜻이므로 빠르게 한발짝 물러나서 설계를 고칩니다. (테스트하기 어려운 코드는 잘못된 설계일 가능성이 높다는 이야기와 비슷한 맥락입니다.)
• 이미 사람들이 많이 사용하는, 어느정도 검증된 기술을 도입합니다. 검증되지 않는 기술을 스스로 검증하기란 시간과 자원이 많이 들어갑니다…

꺼뮤니께이션

의사소통도 특히 미리미리 잘 되어야 합니다.

• 요구사항을 명확히 하고, 모든 개발자가 같은 북극성을 바라보고 개발해야 합니다. 요구사항이 모호하다면 먼저 요구사항을 명확히 하는 데 노력합니다. 다른 북극성을 바라보고 개발했다가 그걸 맞추는 작업에 대한 시간과 노력이 더 큽니다. 대한 이력, 대화 내용을 내부 위키 같은 걸로 관리하면 좋겠지요.
• 좀 이상한 문제라는 촉이 올 때 일단 전체 공유를 하고 정확한 원인과 해결방안을 찾아나갑니다. 좀 이상한 문제란, 지금까지 본 적 없는 에러라든지 일반적인 패턴에서 벗어난 현상을 뜻합니다. 프로젝트의 경험이 조금 쌓인 상태여야 맞닥뜨린 에러가 일반적인 에러인지 이상한 에러인지 구분할 수 있을 겁니다. 공유를 먼저 한다면 그 장점은 다음과 같아요.
  • 그 문제를 먼저 맞닥뜨린 다른 팀원의 지혜를 바로 import 할 수 있습니다.
  • 내가 이상하다고 생각했던 문제가 다른 팀원에겐 흔하고 일반적인 문제라 해결책을 바로 내놓아줄 수 있습니다.
• 위와 비슷한 내용입니다. 상황상 어쩔 수 없는 번거로운 작업이나 쉽게 해결되지 않은 채 방치되고 있는 문제점도 잦은 소통으로 모두가 잘 인지하고 있어야 합니다. 같은 문제를 이미 해결한 사람이 있는데, 굳이 다른 사람이 해결할 필요는 없겠죠!

함께 자라기라는 책에서 팀으로 일하는 게 개인으로 일하는 것보다 생산성이 훨씬 좋아진다는 이야기를 봤습니다. 그 이유가 위에서 제기한 이야기의 흐름과 크게 다르지 않아요. “한 사람이 문제 해결법을 발견하면 그게 곧 모든 팀원의 문제 해결법이 될 수 있다.”

어떤 업무의 성공 확률이 80%라고 치고 5명이 일한다고 합시다. 소통이 없는 개개인으로 일한다면 모두가 완벽하게 일을 처리해야 결과적으로 프로젝트가 성공이니 성공 확률이 AND 로 계산됩니다. 즉 0.8^5 하여 32.768% 정도 밖에 안됩니다.

반면 소통이 잘되는 하나의 팀으로 일한다면 실패할 확률이 AND 로 계산되어, 즉 0.2^5가 되어 0.032%, 즉 성공 확률이 99.9%가 넘습니다! 대박~

마치며

그렇습니다. 위에서 제기한 전략은 끊임없이 실천해야 하는 것들입니다.

그러나 모호한 것들도 많습니다. 내가 지금 키보드를 열심히 두들기면서 한글자 한글자 태어나는 코드가 과연 “마구잡이”인 코드인가, “적당”한 코드인가, 혹은 “최적”의 코드인가? 이를 판단하는 것부터 어려운 일이 많습니다. 해보지 않으면 모를 때도 많습니다. 제가 최근에 겪은 걸 이야기 드리자면은 소규모 데이터 마이그레이션(링크 추가 예정. 글 작성중임) 같은 것이 그렇습니다.

여하튼 자주자주 세종대왕의 영혼에 빙의하며 내가 잘 하고 있는 건가 계속 감시해줍시다.

즐코딩 ㅎㅎ.