대규모 프로젝트에서 스펙파일 구조 설계

작성한 질문수 3

0

안녕하세요. 굉장히 중요한 질문을 해주셔서 정말 감사합니다.

강의를 제대로 보신 분들만 할 수 있는 질문이라 생각합니다.

대규모 프로젝트로 간다면 그때부터 스펙 관리는 꽤 복잡한 부분이 있습니다.

예를 들어보면, 대형 프로젝트가 모노레포로 관리된다고 했을 때는 각 모노레포에 소속된 패키지 별로 스펙 분리를 1차원적으로 할 수 있을 겁니다.

이 경우에는 specs/client, specs/server 이런식으로 분할할 수도 있고, 또는 도메인에 대한 관리를 둘 수도 있을 겁니다. 이를테면, specs/payments, specs/registration.

그렇다면 해당 스펙 디렉터리에 어떤 요소가 들어갈지는 각 달라지게 됩니다. 만약 payment 기능을 개발하는데 client, server로 두 개의 스펙 문서를 만들어 2개로 각각을 관리하게 된다면, 이 두 개의 문서는 서로 다른 분야를 개발하지만 공통된 root 스펙이 필요하게 됩니다. 이를테면 payment에 사용되는 스키마가 되겠죠. 그렇다면 이 경우에는 payment를 담당하는 root 스펙과 더불어 그것을 client, server에 각각 참조할 수 있도록 하는 형태로 스펙 문서를 배치하는 것이 유리합니다.

반면 도메인별로, feature 별로 관리를 하게 된다면 payments/ 디렉터리 안에 root에 대한 스펙(payments/root.spec.md), 각 요소 또는 기능에 대한 스펙(payments/client.spec.md) 등으로 넣을 수도 있지만 실제로는 client에 모든 스펙 요소를 다 넣는 것이 안되서 상세 규칙을 따로 빼야할 경우가 생길 겁니다. 그렇다면 스펙의 구조는

• root.spec.md가 가장 뿌리

• client.spec.md는 payments의 client측 개발을 위해 참조하는 인덱싱 목록 형태의 스펙 문서

• paymemts/rules/ 안에는 세부 규칙 요소 배치

• payments/details/ 안에는 세부 스펙 배치

와 같은 형태로 구현할 수 있습니다. 또한 이 과정에서 점진적 참조(skills에서 다룬 것처럼)를 하여 client.spec.md 파일 안에 링크를 넣는 형태로 구현하시면 상황에 따른 참조를 하실 수 있습니다.

스펙 관리는 이처럼 소속된 패키지 단위, 기능 단위 정도로 관리될 수 있으니 현재 대규모 프로젝트의 구조나 기존 개발이 진행될 때의 방향성과 어느정도 맞추는게 좋습니다. 가령 조직이 패키지 단위 개발을 한다면 패키지 단위 스펙 정책이 유효하다고 보이며, 반면 기능 묶음 단위라면 기능 단위로 스펙을 구조화하시는 것을 추천드리겠습니다.