Big Design Up Front(BDUF) vs. Continuous Design
소프트웨어에 완벽한 설계란... 있나?
생각을 정리하기에 좋았다. 글의 내용 보다도, 주제 자체만으로 때마침 나에게 필요했을 때쯤.
Viva Republica
취미로 시작한 지 4개월 쯤 된 토이 프로젝트가 있다. 나는 타고난 천성이 완벽주의인지라 디테일에 집착하는 편인데, 작은 스타트업에서 항상 디테일에만 집중할 수는 없지 않은가. 늘 억누르고만 있다 백수가 되었으니, 이번만큼은 돈 벌어다 줄 서비스도 아니고 함께할 팀도 없겠다, ‘원 없이 품질에만 집착해보자’ 라는 생각에 프로젝트를 시작했다. 아마도 이런 프로젝트는 처음이자 마지막이겠지. 또 한 번 경력 휴식기를 갖지 않는 이상.
저장소는 monorepo 구조로, 제작할 서비스의 코어 패키지에 집중한 후, 코어 패키지를 이용해 간단한 라이브 데모를 구현하는 순서로 접근했다. 물론 코어를 100% 완성할 생각은 아니었지만, 거듭된 리팩토링을 반복하다 보니 무려 한 달에 걸쳐 완성된 끔찍한 PR이 올라왔다.
choegyumin아무리 품질 지향이라 한들, 아직 코어를 사용하는 곳도 없으면서 미리 리팩토링을 거듭하는 실수를 저질렀다. 뚜렷한 목표도, 방향도 없으니 (흔히 잘못 해석된 의미의) 장인 정신으로 설계를 번복해버렸고, 결국 3개월 동안 결과물에 큰 변화가 없어 좌절을 겪었다.
Big Design Up Front(좌)와 Continuous Design(우)의 그래프. 다행히 지금의 나는 커브를 타기 시작했다.
물론 코어 패키지 하나만 놓고 본다면, 적어도 처음 한번은 BDUF가 나쁜 방법이 아닐지도. 이는 사용자가 개발자이기 때문인데, 그동안 개발하면서 breaking changes가 밥 먹듯 이뤄지는 패키지를 본 적이 있나? 물론 정식 배포 전의 실험적 패키지 빼고.
하지만 내가 느끼기에 이번 PR은 너무 가버렸다. 코어를 외부에 배포할 것도 아니고, 사용자도 오로지 나 자신이었으며, 프로젝트의 목적이 그저 취미에 불과했는데. 나 자신의 동기부여를 위해서라도 이 방식은 적절치 않았다고 생각한다. (이후로는 아주 대충이라도 스프린트를 관리하고 있다. 하지만 나는 P란 말이지?)
서비스를 만드는 회사는 대체로 agile(또는 agile hangover에 빠진 mini-waterfall)하게 움직일 것이다. 기업은 동아리가 아니고, 팀은 성과를 내기 위해 모인 조직으로 결과를 보여주어야 한다. 결과가 있어야 그 다음도 있을 것이고. 팀원들이 서로 다른 생각을 가지는 것은 매우 당연한 일지만, 잊지 말아야 할 점은 같은 목표를 바라보는 것이며, 팀워크 없이 모든 이가 본인이 추구하는 대로만 행동한다면 그 기업과 팀은 살아남을 수 없다. 완벽주의인 나조차도 회사에서는 기질을 억누르는 것 또한, 우리는 프로페셔널답게 행동해야 하기 때문.
물론 설계는 반드시 필요하고, 품질 또한 등한시하라는 게 아니다. 이번 기능 구현으로 줄 수 있는 임팩트는 무엇인지, 일정 내에 가능한지, 불가능하다면 범위를 줄일 수 있는지, 쌓여 있는 기술 부채는 얼마나 있는지, 지금 해결하지 않는다면 생산성에 얼마나 악영향을 끼칠지, 그럼 언제 해결 가능한지 등. 이 모든 것을 고려해서 무엇이 우선이자 최선인지 결정해야 한다는 뜻이다. 무조건 어느 하나에 치우쳐서는 안 된다.
오해가 생길까 봐 굳이 얘기하자면, 속도를 핑계로 일반적인 실행 관례조차 무시하는 팀이 종종 있다. 이것은 합리적인 선택이 아니라, 장기적으로 제품을 망치는 지름길이다. (오래전의 어떤 팀에서 lint 돌리다가 혼났던 적이 있다. 유닛 테스팅도 걸렸다면 어땠을까)
이쯤 하면 마치 내가 소프트웨어 장인이라도 되는 줄 알겠는데, 그런 실력인지는 잘… 적어도 마음가짐 정도는 옳다고 생각한다. 그리고 사실을 고백하자면, 나도 과거에는 회사에서 품질에만 집착하던 시절이 있었다.
아무튼 BDUF가 무조건 나쁘고, Continuous Design이 항상 옳은 것은 아니다. 그저 적절한 상황에 적절한 도구이자 방법만이 있을 뿐. 방법론이 모든 걸 해결해주리란 믿음은 버려야 한다. 이번엔 무엇이 옳다기보다, 그저 마음 가는 대로 해보았을 뿐인데, 무엇이든 극단적이면 오히려 독이 된다는 걸 다시 한번 깨닫는다.
정리
- 소프트웨어에서 완벽한 설계란 (거의) 없다.
- 리팩토링도 전략적으로 해야 한다. TDD Refactoring, Comprehension(Exploratory) Refactoring, Litter-Pickup Refactoring 등. 특히 Litter-Pickup Refactoring은 동료들이 틈틈이 해주면 너무 고맙다.
글의 템플릿이 있어야 한다고 느꼈다. 이번엔 일기 — 정리 순.
가벼운 기록이 목적이었는데, 이전 글은 내용이 구분 없이 섞여 길기만 했다.
이번엔 적절해 보이면서도 더 줄여야겠다는 생각이 든다.
