TODO 리스트에 질렸다면? 칸반보드 만들기! - 스칼라 백엔드 서버 개발 2편
1편 배우고 싶은 기술 선정
2편 서비스 설계
3편 내가 토이프로젝트를 실패한 이유
스칼라로 백엔드 개발하기 시리즈의 2편입니다. 이전 1편에서는 개발을 통해 학습하고 싶었던 라이브러리 (기술 스택)을 생각해보았고 이번 글에서는 실제로 무엇을 개발할지 그리고 어떻게 개발할지 계획을 짜봅니다.
TODO보다 칸반
토이 프로젝트로 할 것이 없어 추천을 받을 때 꼭 나오는 예시 중 하나가 바로 TODO 리스트 만들기 입니다. 저 또한 과거 Play Framework + React로 간단한 TODO 리스트 만들기에 도전했던 적이 있습니다. 이번 스칼라로 백엔드 개발하기에서도 TODO 리스트 만들기를 할까 생각했습니다만, 사실 간단한 TODO 리스트 만들기는 예시도 많고 프로그래머들에게 너무 익숙하여 재미가 떨어졌다는 생각이 들었습니다. 그래서 어떤 프로젝트를 할까 고민하던 중 마침 회사에서 공부하던 애자일 실천 방법 중 칸반이 눈에 들어왔습니다. 단순한 TODO 리스트와는 거리가 있지만 비슷한 맥락을 가지고 있고, 잘 구현된 예시들(노션의 기본 템플릿, 지라 등)이 있어서 기획에 너무 많은 시간을 쓰지 않으면서 코딩 연습에 집중하기 좋을 것 같아 선택하였습니다.
시작하기 전 간단하게 칸반에 대해 설명하면 칸반은 팀 단위에서 일어나는 작업을 효율적으로 “시각화"하여 관리할 수 있게 도와주는 시스템입니다. 다음 그림을 보면 이해하기 편하실 것 같습니다. 큰 보드에 작업 진행 순서별로 영역을 나누고 팀 내 존재하는 작업들을 자신들이 속하는 단계에 할당하고 있습니다. 팀원들은 칸반 보드를 통해 전체 작업들의 진행 상황을 빠르게 파악할 수 있고, 팀장은 업무의 진행 속도를 정량적으로 (완료한 작업 갯수) 측정하여 다음 계획을 세울 수 있습니다. 좀 더 자세한 설명은 Jira와 Confluence를 제작한 Atlassian 사의 What is kanban board 글을 참고하시면 좋습니다. 애자일 관련해서도 좋은 글들이 많아 참고하시면 좋습니다.
애자일에 대해 초보인 저로서는 잘 모르지만 칸반에 대해서는 책 한 권이 나올 정도로 좋은 글들과 논의들이 많습니다. 하지만 이 프로젝트에서는 칸반의 모든 것을 담기보다는 TODO 리스트에서 조금 더 발전된 형태로서 한 팀이 사용할 수 있는 작업 관리 툴 정도로 범위를 잡으려 합니다. 만약 노션을 사용해보신 적이 있다면 기본으로 제공하는 Borad View 정도를 상상하시면 좋을 것 같습니다. (물론 이것도 기능이 꽤 많습니다.)
유저 스토리, 유즈 케이스
새로운 프로젝트를 시작할 때 또는 새로운 기능을 추가할 때 어떻게 시작해야 할까요? 저는 기획의 전문가가 아니지만 짧은 경험에 기반해 위 질문에 대답을 한다면 유저 스토리 또는 유즈 케이스에서 시작한다고 말할 것입니다. 이 글은 애자일에 대한 글이 아니기 때문에 유저 스토리를 정의했을 때 장점 등에 대해서 자세한 설명은 하지 않겠습니다. 다만 실무를 통해 알게 된 유저 스토리의 소소한 장점은 기획이 명확하지 않은 순간에 (보통 기획이 명확한 순간이 훨씬 더 적습니다) 시작할 수 있는 단서가 되어준다는 것입니다. 또한 구체적인 유저 스토리는 당장 필요하지 않은 과한 기능 개발, 최적화를 막을 수 있다는 장점도 있습니다.
칸반을 사용하는 유저(팀원, 팀장)를 상상했을 때 다음 세 가지 정도 유저 스토리가 생각납니다.
- 팀원은 팀에서 진행할 새로운 일을 추가하기 위해 백로그에 작업을 등록할 수 있다.
- 팀원은 작업의 진행도를 공유하기 위해 작업의 진척도에 따라 작업을 다른 상태로 이동시킬 수 있다.
- 팀장은 전체 업무 진행도를 확인하기 위해 일정 기간 동안 완료된 작업의 수를 확인할 수 있다.
이 정도 준비가 완벽한지는 모르겠지만 시작하기엔 충분해보입니다. 사실 완벽하게 시작해야 할 필요도 없다고 생각합니다. 유저 스토리를 만들고 최대한 작은 단위로 결과를 테스트해보면서 새로운 지식을 발견할 수 있다면 그것으로 충분한 시작의 단위라고 생각하기 때문입니다.
그리고 TDD
Test Driven Development는 칸반 자체와는 큰 관련은 없지만 프로젝트를 진행함에 있어 “어떻게” 개발을 진행할지에 해당한다고 생각하여 따로 적었습니다.
TDD는 간단히 말해 개발에 앞서 (실패하는) 테스트를 먼저 작성하는 개발 방법론입니다. 물론 단순히 테스트를 먼저 작성하는 것이 TDD의 전부는 절대 아닙니다. 기획자나 개발자가 프로젝트를 시작할 때 흔히 하는 착각 중 하나는 프로젝트 초기에 완벽한 기획이 가능할 것이라고 생각하는 것입니다. 하지만 아무리 천재적인 도메인 전문가와 천재적인 개발자가 만나더라도 (심지어 그 두 가지 역할을 혼자서 할지라도) 개발을 시작하기 전에 완벽한 기획을 한다는 것은 불가능에 가깝습니다. (그 이유에 대해서 나중에 글로 쓸 수 있는 기회가 있다면 좋겠네요.) 따라서 이 사실을 인정했을 때 우리가 취할 수 있는 방법은 짧은 반복 주기 안에서 시도를 통해 시스템과 그 용도에 대한 학습을 하고 거기서 배운 바를 다시 시스템에 적용하는 것입니다. 이러한 피드백 고리를 형성함으로써 초기에 높은 불확실성을 차근차근 줄여나가고 큰 시스템을 점진적으로 개발할 수 있습니다.
추상적인 위의 설명을 조금 더 구체적인 예로 풀어보겠습니다. 테스트는 다른 관점으로 보면 우리가 개발한 시스템을 직접 사용하는 작은 유즈케이스 (또는 사용 시나리오) 라고 생각할 수 있습니다. 따라서 테스트를 먼저 만들기 위해서는 “명확"하게 우리 시스템을 “어떻게” 사용하는지 알아야만 합니다. 그 과정에서 우리는 불확실한 시스템의 용도에 대한 학습이 일어나게 됩니다. 또한 실패하는 테스트를 먼저 만들기 때문에 그 다음 작성한 코드가 기능에 기여했다는 것을 “확신"할 수 있습니다. (테스트를 나중에 만들면 내가 의도한 코드가 아닌 다른 엉뚱한 코드 때문에 테스트가 우연히 통과할 수도 있다는 것을 말합니다.) 게다가 여기까지 학습한 정보를 바탕으로 코드를 더 좋은 방향으로 리팩토링을 할 때 역시 테스트는 큰 도움이 됩니다. 코드의 수정이 기존 기능에 잘못된 영향을 끼치지 않는다는 것을 보증해주기 때문입니다. 이처럼 TDD는 방법은 비교적 간단하지만 자연스럽게 개발자를 피드백 고리 안에 진입하게 함으로써 점진적인 개발을 가능하는 멋진 도구입니다.
마치며…
토이 프로젝트에서 가장 어려운 것 중 하나가 바로 주제 선정이라고 생각합니다. 회사에서 시키는 일이 아닌 자기가 하고 싶은 것을 할 수 있다는 자유가 주어졌지만 막상 주제를 선정하려고 하면 잘 떠오르지 않는 것이 사실입니다. 저 역시 토이 프로젝트를 자주 잘 해내는 개발자는 아니어서 항상 어려움을 겪었습니다. 다만 작은 깨달음은 주제를 정하기 어려울 때는 이미 흔한 주제들(TODO 리스트 등)을 이용하는 것이 좋고, 자기만의 주제를 선정하고 싶다면 평소에 하는 작업에서 자동화 할 만한 것들을 자동화하는 프로젝트를 만들어 보는 것이 좋은 것 같습니다. 저는 TODO 리스트보다는 약간 더 복잡한 칸반을 관리하는 프로젝트를 진행하기로 계획을 해보았습니다. 개인적인 목표를 하나 정도 추가한다면 기간이 너무 늘어지지 않고 처음부터 끝까지 완주하는 것입니다. 항상 꾸준하게 하는 것이 중요하다는 것을 머리로는 알았는데 이번 기회가 그걸 실천하는 좋은 경험이 되었으면 합니다.