단일 Repository에서 세 개의 서비스를 어떻게 관리할 것인가

SSAFY 프로젝트에서 AI, Backend, Frontend를 한 repo에 담으며 고민한 것들

SSAFY 프로젝트를 시작하면서 우리 팀은 AI, Backend, Frontend 세 개의 서비스를 동시에 개발해야 했다. 원래라면 각각을 독립된 레포지토리로 관리하는 게 맞겠지만, SSAFY에서는 단일 레포지토리, 단일 인스턴스로 운영해야 한다는 제약이 있었다.

그냥 폴더만 나눠서 넣으면 되는 거 아닐까라고 생각했지만, 막상 고민을 시작하니 생각보다 복잡한 문제들이 보이기 시작했다. 로컬에서 개발할 때는 편해야 하고, 나중에 배포할 때도 간단해야 하고, CI/CD 붙일 때도 문제없어야 하고... 심지어 나중에 환경 분리(dev/prod)나 성능 개선도 고려해야 한다.

그래서 어떻게 구조를 짜야 할까?에 대한 고민에 빠지게 되었다

 

고민했던 방법들

A. 서비스별로 Docker Compose를 각각 만들기

 

 

ai/docker-compose.yml
backend/docker-compose.yml
frontend/docker-compose.yml
root-compose.yml (선택사항)

 

이 구조가 각 서비스를 완전히 독립적으로 개발하고 팀별로 협업하기 좋을 것 같았다.

좋은 점

• 개발할 때 정말 편하다. 내가 담당한 서비스만 띄우면 되니까
• 서비스 구조가 명확하게 분리된다
• 팀별로 작업하기 쉽다

문제점

• 실제로 운영하거나 배포할 때 여러 개의 compose를 동시에 관리해야 해서 복잡하다
• network 설정이나 환경변수, 이미지 이름 같은 게 충돌날 수 있다
• CI/CD 파이프라인 짜기가 복잡하고, 롤백도 어렵다
• nginx 같은 proxy를 여러 곳에서 중복으로 설정해야 할 수 있다

 

결론: 탈락

---

B. 폴더는 나누되 Docker Compose는 하나만 + Profile로 제어

 

 

ai/
backend/
frontend/
docker-compose.yml (하나만)

운영할 때는 하나의 orchestration으로 관리하고, 개발할 때는 profile로 필요한 서비스만 띄우자는 아이디어였다.

좋은 점

• 운영하고 배포하기가 정말 간단하다
• CI/CD 파이프라인을 하나만 만들면 된다
• 나중에 스케일링할 때도 유리하다
• Compose에서 Kubernetes로 전환할 때도 자연스럽다

문제점

• 개발할 때 매번 --profile 옵션을 붙여야 해서 조금 불편하다
• 개발 루프의 유연성이 조금 떨어진다

결론: 후보군에 올림

---

C. 서비스별 Compose + Root Compose를 Makefile로 통제

A와 B의 장점을 섞어보자는 생각이었다. 개발할 때는 편하게, 운영할 때는 단순하게.

좋은 점

• 개발할 때는 make backend, make ai 이런 식으로 편하게 실행할 수 있다
• 운영할 때는 단일 orchestrator를 유지할 수 있다
• 여러 서비스를 한 번에 빌드하는 것도 쉽게 제어할 수 있다

문제점

• Makefile을 관리하는 비용이 추가로 든다
• Makefile이 점점 복잡해지면 기술 부채가 될 수 있다

결론: 후보군에 올림

---

D. 아예 Repository를 여러 개로 분리

완전히 독립적으로 구성해서 확장성을 최대화하자는 아이디어였다.

좋은 점

• 팀별로 완전한 자율성을 가질 수 있다
• 배포 단위가 명확하다

문제점

• 지금 단계에서는 오버엔지니어링이다
• 팀 간 컨텍스트 공유가 어렵다
• 관리 비용이 너무 많이 든다
• 그리고 애초에 SSAFY 제약사항이 단일 repo였다

결론: 탈락

---

지금도 많이 고민중이다. 

마음은 C쪽으로 기울고 있어서, C로 선택할꺼같다.

그밖에도 밑에 사항들을 고려해야할 것 같다

 

앞으로 고려할 것들

• Staging 환경을 도입할 수도 있다
• Terraform 같은 걸로 인프라를 선언적으로 관리할지 고민 중이다
• Observability (로그, 메트릭, 트레이싱) 관련해서 추가 작업이 필요할 수 있다
  • 만약 이 부분이 들어간다면 observability/ 또는 monitoring/ 폴더를 따로 만들어서 관리할 생각이다
• 생각보다 많은 컨테이너가 들어갈 예정이라 k3s 도입도 고려 중이다. 그렇게 되면 구조가 전반적으로 또 바뀔 수도...