현재 회사의 아키텍처
현재 회사의 API 서버는 FastAPI로 구현되어 있으며, AI 요청은 비동기 방식으로 처리하고 있다.
하지만 동시 요청이 늘어날 경우 Celery와 Redis 구조로도 한계가 있을 것으로 판단했다.
특히 회사의 비전이 B2C에서 B2B까지 확장되는 상황이므로, 더 커지기 전에 서버를 나누는 방향으로 구조 전환을 결정했다.
이번 전환에서 중요한 점은 빠른 개발 속도와 QA 병행이었다. 이를 위해 최대한 단순하고 직관적인 폴더 구조를 잡았다.
폴더 구조의 목적과 이유
폴더 구조를 설계하면서 가장 중요하게 생각한 점은 생산성과 명확성이다.
- 생산성: 새로운 기능을 빠르게 추가하고, 유지보수가 용이해야 한다.
- 명확성: 팀원들이 코드의 역할과 위치를 바로 이해할 수 있어야 한다.
폴더 구조
📁 config: 설정 관련 파일 (보안, CORS, DB 등)
📁 controller: API 요청 처리
📁 dto
- 📂 request : 요청 DTO
- 📂 response : 응답 DTO
- 📂 mapper : DTO ↔ Entity 변환
📁 exception: 예외 처리
📁 filter: 필터 및 인터셉터
📁 gateway: 외부 API 연동 및 게이트웨이
📁 model
- 📂 entity : DB 테이블과 매핑되는 클래스
- 📂 vo : 값 객체 또는 불변 객체
- 📂 enums : 상태값 및 타입 정의
📁 repository: 데이터베이스 접근
📁 service: 비즈니스 로직
📁 utils: 공통 유틸리티 클래스
📄 LemonApiServerSpringApplication.java: 메인 실행 클래스
결론
물론 이게 최선의 구조는 아닐 수 있다. DDD, 클린 아키텍처, 헥사고날 아키텍처와 같은 패턴이 존재하지만 상황에 맞게 구조를 잡는 것이 더 중요하다고 생각한다.
처음부터 API 서버와 AI 서버를 나누었다면 더 깔끔했을 수 있겠지만, 당시에는 MVP가 명확하지 않았다. 중간 점검을 통해 아키텍처를 조금 더 일찍 트래킹했으면 좋았을 것 같다는 아쉬움이 남는다.
다만 지금의 구조는 생산성과 명확성에 집중했고, 빠르게 대응하면서도 확장 가능한 첫걸음이 되리라 믿는다.
앞으로 상황에 맞게 조금씩 리팩토링 해봐야겠다.
