뒤로
임종혁
·
제품 개발 시 NOT TO DO 리스트 for 초기 팀
목표를 세웠다면 하지 말아야 할 것을 안 하는 것만큼 어려운 것이 없습니다.
이런 결정을 잘 하고자 할 때, 공식이 없는 길을 걸어가는 도전―e.g. 스타트업―에 뛰어든 분들 일수록 과거의 사례들이 오히려 독이 되는 경우가 많은 것 같습니다.
모든 영역에서 필요한 사고겠지만 저도 그동안 개발을 하며 쌓인, '하지 말아야 할 것을 수도 없이 해버린' 실패 경험에서 뽑아본 NOT TO DO 목록을 아래에 공유해봅니다.
테스트 코드를 작성하지 말 것.
패키지 폴더명이나 구조에 시간을 쓰지 말 것.
좋은 아키텍쳐 선정에 시간을 쓰지 말 것.
익숙하진 않지만 좋을 것 같은 신기술을 선택하지 말 것.
확장성을 고려하지 말 것.
장기적인 기술 로드맵을 그리지 말 것.
실제 고객이 경험하고 필요성을 얘기하는 것과 관련된 개발의 우선순위를 높일 것.
견고하게 만들지 말 것.
문서를 쓰지 말 것.
하나하나가 한 편의 글이 될만큼 많은 실패가 있었던 것 같습니다.
또 다른 NOT TO DO가 무엇이 있을까요?
15
댓글
로그인 후 댓글을 남길 수 있습니다.
오 저는 문서는 적어야 한다고 생각해요! 물론 개발과 관련된 documentation까지 필요한 지는 모르겠지만, 최소한 기능이나 서비스의 의도는 정리된 문서가 있어야 헷갈리지 않을까 싶네요!
저도 공감합니다! 초기 스타트업에 보다 중요하다고 생각하는 부분을 위해 그 외의 부분은 의도적으로 배제해야 한다고 생각하는데 항상 초기 팀에서 많이 논의 되는 부분들인 것 같습니다 기술 부채와 스피드 사이의 균형. 어떤 것들은 어느 시점 이후 오히려 팀 속도를 늦추게하는 원인이 될 수 있으니까요 저희는 다른 것들은 몰라도 스프린트에서 개발 일정을 타이트하게 잡고 맞추는것 하나만큼은 반드시 지키고자 합니다
1, 2, 3, 5, 8, 9 는 MUST DO 아이템인데요. 이 항목들은 정말 중요한데 어려운 것들이지 간과해서는 안될 Programming 의 ABC 들로 보입니다. 이 부분을 대충하고 넘어갈 거면 처음부터 만들지 말고 이게 잘되어 있는 opensource CMS나 미들웨어 같은 걸 도입해서 시작하는게 더 나을 것 같습니다. 일례로 초반에 시간을 절약하기 위해 unit test 를 skip 하는 경우가 있는데, 그렇다면 개발중, 개발과정의 test를 일일이 손으로 하게 되고 그게 더 큰 시간을 소비할 걸요? 개발이 진행될 수록 효과적인 regression test 까지는 얘기할 필요도 없고. 제품 개발과 동시에 unit test를 같이 만들면 수동 테스트를 자동화 할 수 있으므로 훨씬 시간이 절약됩니다 . test를 만드는게 시간이 많이 드는 작업이라고 여겨지면 본인의 test framework가 제대로 없는 상태일테니 좋은 test frarmework나 미들웨어를 기반으로 만드는 게 낫겠습니다.