프로젝트를 시작하는 단계에서 동작하는 골격(walking skeleton)을 만드는 것은 프로젝트의 프로세스를 연습하고 지속적으로 개선해 가는 과정에서 상당히 중요하다고 생각한다. 현장 프로젝트에서 동작하는 골격을 만든 후에 프로젝트를 진행하는 경우를 많이 경험하지 못해 다들 어떻게 진행하는지 궁금해서 질문 남겨본다.
"테스트 주도 개발로 배우는 객체 지향 설계와 실천(인사이트)" 책을 보면 동작하는 골격을 다음과 같이 정의하고 있다.
'동작하는 골격'이란 전 구간을 대상으로 자동 빌드, 배포, 테스트를 할 수 있는 실제 기능을 가장 얇게 구현한 조각을 말한다. [...] 전 구간, 즉 '끝에서 끝까지'라는 표현에서 '끝'이 시스템뿐 아니라 프로세스를 가리킨다는 사실을 깨닫는 것도 중요하다.
Kickstart your next project with a Walking Skeleton 글에서는 다음과 같은 글을 볼 수 있다.
As part of building it you should write your deployment and build scripts, setup the project, including its tests, and make sure all the automations are in place — such as CI integration, monitoring and exception handling. The focus is the infrastructure, not the features.
즉, '동작하는 골격'을 만드는 것의 초점은 기능 구현이 아니라 infrastructure를 구축하는데 있다는 것이다.
Creating a Walking Skeleton 문서를 보면 동작하는 골격을 만드는 과정에 포함할 내용을 다음과 같이 정리하고 있다.
- Build
- Unit & Integration Tests
- Deploy
- Acceptance Tests
- Static Analysis
- Code Coverage
대부분의 프로젝트는 이 같은 infrastructure에 해당하는 환경을 구축하는 과정이 프로젝트를 진행하는 과정 속에 진행하는데 이 내용들은 프로젝트를 시작하기 전에 프로젝트 전체를 관통하는 기능을 하나 선정한 후 이 과정을 먼저 진행하라는 것이다. 이런 과정이 불확실성을 일찍 드러내도록 함으로써 문제를 빨리 해결할 수 있다는 것이다.
저의 질문은 다음과 같습니다.
- 보통 프로젝트를 시작하는 단계에서 어느 수준까지 준비한 상태에서 프로젝트를 진행하나요?
- 혹시 "테스트 주도 개발로 배우는 객체 지향 설계와 실천(인사이트)" 책과 위 자료들에서 이야기하는 '동작하는 골격'을 만든 후 프로젝트를 진행한 경험이 있으면 어떠했는지 공유해 줄 수 있을까요?
0개의 의견 from FB
3개의 의견 from SLiPP
안녕하세요 좋은 주제인것 같아 먼저 답글을 달아봅니다.
저의 경우에는 새로운 언어를 학습하고 프로젝트에 활용하기 위한 습관으로 위와 같은 과정을 같습니다.
개인적인 경험으로는 TDD를 통해 새로운 언어를 접근하면 아래와 같은 장점이 있었습니다
무엇보다 이 과정에서 테스트 코드를 통해 프로젝트를 효율적으로 관리하기 위한 고민을 시작하면 쉽게 다양한 문제에 노출되 새로운 환경에서 본문에서 말씀하신 Walking Skeleton에 필요한 요소들을 주도적으로 찾아갈 수 있었습니다.
주제에 어긋나지만 독립적으로 동작하는 애플리케이션보다는 재 사용을 위한 라이브러리를 개발하기 위한 프로젝트를 구성하고 저장소에 배포까지하는 것으로 목표를 설정하면 더욱 많은 문제에 노출될 수 있었습니다.
예를 들어 Python이라면 PyPI, Java라면 Maven 저장소에 자신이 개발한 라이브러리를 배포하는 과정입니다. 공개적인 저장소에 배포가 되니 새로운 환경에서 빌드를 자동화는 과정을 찾게 되고 정적 분석이나 커버러지에 더욱 신경을 쓰게 만들어 줍니다.
@정민혁 경험 공유 감사합니다.
주제에 어긋난 것이 아니라 이것이 핵심이지 않나라는 생각이 듭니다. 동작하는 애플리케이션을 최대한 빠른 시점에 배포까지 해봄으로써 많은 문제에 빨리 노출하게 하는 것에 의미가 있을 것 같아요. 다양한 문제에 빨리 노출함으로써 미리 해결책을 찾고, 준비할 수 있는 기회를 줄 수 있다는 생각이 듭니다.
저는 예전 2012년 N사 모바일 뉴스 프로젝트 할 때 GOOS 책의 END-TO-END를 적용을 해보았습니다. 다시 말해 위에 나온 모든 것과 함께 골격 주도 개발을 해보았습니다. 다만 배포는 당시 사내 시스템의 한계로 자동화까지는 못 했습니다. 초기에 배포를 먼저 구축하고 시작하는 것으로 대체했습니다.
당시 세팅 마치고 스스로 감동했습니다. 이걸 실천하다니 난 진짜 짱이다 ㅋㅋㅋ (ㅈㅅ) 아무튼 개발을 시작해보니 품질을 제어한다는 느낌이 많이 들었습니다. 다만 빠른 피드백 효과로 표현하는 예상치 못한 어떤 요인을 발굴하는 가치는 별로 못 느꼈습니다. 당시 기술적으로 웹개발에 숙련되어 그랬던 것 같아요.
테스트 집합은 큰 도움이 되었어요. 오픈 직전 전체 서비스에 큰 영향을 미치는 핵심 도메인 모델의 변화가 있었습니다. 그러나, 저희는 END-TO-END 하에 보유한 수백의 테스트가 있었어요. 이 변화는 UX 쪽 작은 버그 몇 개로 끝났습니다. 글 쓰면서 기억을 더듬어보니 END-TO-END 관점에서 아래와 같은 테스트도 있었네요.
그렇지만 그 후 위와 같은 접근은 단 한 차례도 해본 적 없습니다. L사 혹은 K사로 이직하며 예전 N사에서 했던 개발 방법론 상당수를 다 버렸기 때문이에요. 제품 중심의 시선을 가져보니 가설 검증에 필요한 최소 구현을 빼고는 관심이 많이 없어졌습니다. 이후 복구 가능한 정도의 기술 부채를 유지하는 정도가 좋은 선이라 생각했어요.
스타트업 하는 지금도 본문의 방식과 많이 다른 개발을 해요. 통합/단위 테스트 수준 TDD와 CI만 실천합니다. 본문의 접근이 이상적이라 생각하는 개발자는 이런 저를 보며 후퇴한 혹은 변절한 개발자라 생각할지 모르겠네요. 저는 반대로 제가 눈부시게 발전한 증거라 생각하지만요.
P.S 저는 동작하는 뼈대 아이디어도 TDD의 OUT-IN, IN-OUT 맥락으로 해석할 수 있다는 생각이 듭니다. OUT VS IN 각 반대의 접근방식이 가진 장단점이 고스란히 있지 않을까 싶네요. 예로 경험이 충분하지 않으면 실천하기 어려울 것 같아요.
의견을 남기기 위해서는 SLiPP 계정이 필요합니다.
안심하세요! 회원가입/로그인 후에도 작성하시던 내용은 안전하게 보존됩니다.
SLiPP 계정으로 로그인하세요.
또는, SNS 계정으로 로그인하세요.