이번 주에는 시스템 설계 문서 작성에 대해 공부하게 되었다. 이번 한 주를 시작하면서 건강상의 이유로 병원도 자주 가고 컨디션 관리가 잘 안 되어서 많은 어려움이 있었다. 하지만 그만큼 이번 주의 주제에서 필요한 것들만큼은 꼭 가져가자는 느낌으로 보낸 한 주였다.
이번 주의 메인 주제는 개발 요구사항 문서, 시퀀스 다이어그램, 클래스 다이어그램, ERD 문서 4가지였다.
이번 주를 진행하면서 일전에 다니던 회사의 문서 체계에 대해 생각해보게 되었다. 기존에는 Notion에 개발 관련 요구사항을 작성하고, 해당 요구사항이 릴리즈에 반영되었는지, 그리고 각각의 API 문서만 존재하던 상황이었다.
https://truthful-gallium-f2b.notion.site/2f6fdb9bd2ee80198e18dad2e5573652
이번 발제에서 내가 가장 크게 느낀 것은 시퀀스 다이어그램이었다. 항상 회의 때마다 다른 부서 분들에게 서비스 플로우를 이해시키기 위하여, 화이트보드에 그림을 그리며 목청을 높이던 때가 생각났다.
시퀀스 다이어그램의 존재를 알았다면 시간을 내어 작성해봤을 것 같다(하지만 그 당시 시간 여건이 됐을지는 모르겠다). 시퀀스 다이어그램은 전체 서비스 플로우의 흐름을 한눈에 그려, 같은 개발 직군에게는 도메인 로직에 대한 설명을, 비개발 직군에게는 프로그램의 구조가 어떻게 흘러가는지 쉽게 설명해줄 수 있는 도구이다.
Mermaid 방식으로 ERD 및 다른 다이어그램도 작성해보았는데, 처음에는 조금 어려웠지만 적응될수록 너무 편리하다고 느꼈다.
이번 주에 생각해본 방향
코드의 변화에 맞춰 설계 문서도 동시에 관리하는 법
개발이 진행될수록 코드의 버전에 맞춰 설계 문서가 바뀌지 못하면 오히려 동료들에게 혼동을 줄 수 있는 리스크가 존재한다. 그러므로 일전에 회사 직무기술서에 기재했던 AI 자동 문서 부분을 코드 부분에 적용시켜 반영하는 방향으로 진행하되, 이번에는 human-check 과정을 최소화할 수 있는 방안을 고려해볼 예정이다.
그리고 저번 주에 멘토님이 남겨주신 피드백 덕분에 도메인 부분과 DTO에서 예외 분리를 적절하게 선택하는 방향을 알게 되었다. 루퍼스를 하면 할수록 내가 일전에 전혀 생각하지 못한 개발의 관점을 보게 되어서 참 만족스럽다.
마무리하면서,
이번 주는 개인적으로 아쉬운 한 주였다. 그렇지만 컨디션 관리의 중요성을 다시 한번 느끼게 되었고, 다음 한 주는 더 많은 의지를 가지고 성장하는 한 주가 될 수 있을 것 같다.