수많은 웹서비스가 만들어져 있고, 지금도 만들어지고 있다. 웹 서비스는 어떤 과정을 거쳐 만들어질까? 전반적인 웹 서비스 개발 과정을 들여다보자.
웹 서비스를 만드려는 목적에 부합하는 요구사항들이 있을텐데 그 요구사항들을 바탕으로 사용자 스토리를 작성한다. 이 때 사용자 스토리는 As-I-So 형식에 따라 어떤 role에게 해당 기능이 어떤 가치를 줄 수 있는지를 중심으로 작성한다. 이 때 가치는 '고객 재방문율을 높일 수 있다' 등의 비즈니스적인 가치일 수도 있다.
전체적인 설계를 한다. 거시적으로 어떻게 구성할지(프론트, 백엔드, 디비 혹은 프론트, BFF, 백엔드, 디비 등 다양한 구조가 있을 수 있다.)를 결정하고, 각 부분에 적용할 기술(예를 들어 프론트는 리액트, 백엔드는 스프링 부트 디비는 PostgreSQL등)을 선택한다. 그리고, 각 부분에 대한 설계도 진행한다. (몇 개의 레이어로 나눌 지 등등)
각각의 사용자 스토리에 대한 구체적인 시나리오를 작성한다. given-when-then에 따라 작성할 수 있다. 이를 바탕으로 인수 테스트를 작성하게 된다.
화면을 어떻게 나타낼지, 디자인을 어떻게 할 지 정한다.
만약 프론트엔드와 백엔드가 분리된 구조를 택하고 있다면 프론트엔드의 URL을 정하고, 리소스를 식별해서 API스펙을 정한다. API스펙에는 어떤 메서드로 어느 경로에 요청을 했을 때, 요청에 body, header는 어떻게 보내야 하고, 응답은 어떻게 줄 것인지가 드러나야 한다.
디자인 시스템 통일감을 주기 위해 UI컴포넌트를 디자인하고, 사용할 색상, 폰트 등을 정한다.
프론트 엔드 인수 테스트를 통과시키면서 요구사항을 하나씩 충족해나가고, 디자인을 입힌다.
백엔드 API를 설계에 따라 만들고, 인수 테스트를 통과시키기 위한 백도어 API도 만든다.
배포 서비스를 사람들이 이용할 수 있도록 배포한다.
개발하는 과정을 조금 더 자세히 들여다보면, e2e테스트를 작성하고, 프론트엔드에서 먼저 API와 연동해야 하는 부분은 하드코딩으로 코드를 짜고, 테스트에서 모킹을 통해 검증을 하는 방식으로 화면을 구성하고, 백엔드에서 API를 테스트코드와 함께 만들고, 프론트엔드에서 하드코딩된 부분을 API를 이용하게 수정해서 e2e테스트가 하나씩 통과되는 방식으로 점진적으로 기능을 만들어 나가게 된다. 그리고 만약 수동 테스트를 하다가 버그를 만나면 그 부분에 대한 e2e테스트를 작성하고, 통과하게끔 프론트엔드와 백엔드 코드를 수정한다.
이번 주 강의에서는 요구사항 수집부터 시작해서 기획, URI설계, 프론트엔드, 백엔드, e2e테스트까지 모두 다루는 대하 드라마가 펼쳐졌다. 비록 강의에서 다룬 프로젝트가 매우 작은 프로젝트일지라도 처음부터 끝까지 경험해보기가 쉽지 않은데, 이번 강의 덕분에 전반적인 개발 프로세스를 습득하는데 많은 도움이 되었다.
지금은 프로그래밍 하나만으로도 벅차지만, 문서화도 잘 하고, 전체적인 설계, 기획에도 의견을 내는 개발자분을 보고 개발만 잘하는 개발자보다는 회색 영역을 채울 수 있는 개발자가 되고 싶다는 생각을 했다. 나는 특히 문서화를 아직 잘 못하는데, 다른 사람과 협업을 하려면, 그리고 내용을 까먹을 미래의 나를 위해서라도 문서화를 잘 하는 것이 필수라는 생각이 들었다. 이번 강의를 토대로 개발 외의 부분들도 잘 챙겨서 더 멋진 서비스를 만드는 데 기여할 수 있는 사람이 되고 싶다. 이번 주는 문서화에 특히 신경 써서 작업 전에 스스로 문서화를 해보고, 진행하면서 부족한 부분을 메꿔나가고, 마지막에 한 번 검토하면서 다른 사람이 읽었을 때도 한 번에 이해가 잘 가게끔 다듬어보자.