작은 사내 도구, 기존 시스템에 붙일까 독립시킬까 — 판단 기준 정리

사내에 이미 운영 중인 시스템(Django + MariaDB)이 있고, 새로 처리해야 할 작은 업무(이메일 발송 + 수신거부 관리)가 생겼을 때 "기존 프로젝트에 기능을 얹을지, 완전히 새 프로젝트로 뗄지" 고민한 과정을 정리한다.

처음 계획: 완전 독립 프로젝트

• 별도 서브도메인, 별도 DB, 별도 Flask 앱
• 이유: 기존 시스템은 특정 부서 전용 도구라, 성격이 다른 기능(전사 마케팅 발송)을 얹으면 어색함

중간에 바뀐 생각: 기존 시스템에 흡수

• 로그인 인증, DB, 배포 인프라가 이미 갖춰져 있어서 재사용하면 개발 비용이 줄어듦
• "코드/인프라는 통합하되 화면은 분리"하면 이질감 없이 붙일 수 있다고 판단
• Django의 다중 DB 라우팅 기능(DATABASE_ROUTERS)까지 검토

결국 다시 독립으로 돌아온 이유

논의를 진행하다 보니 다음 질문들이 계속 걸렸다:

1. 이 기능이 정말 이 시스템의 일부가 맞는가? 기존 시스템은 특정 업무 전용 도구인데, 새 기능은 전사 범위였다. "SW 전용 시스템에 회사 전체 기능을 얹는다"는 구조 자체가 계층이 거꾸로였다.
2. 이 기능이 임시(다리) 성격인가, 영구 정착할 것인가? 사내에 이미 더 큰 그림의 신규 플랫폼이 별도로 구축되고 있었고, 지금 만드는 기능은 그 플랫폼이 완성되면 흡수되어 사라질 가능성이 높았다.
3. 어차피 임시라면, 통합에 드는 복잡성(다중 DB 라우팅, 권한 그룹 분리, 화면 분리)을 감수할 가치가 있는가?

3번 질문에 답하면서 결론이 명확해졌다 — 임시로 확정된 것이라면 최대한 단순하게 가는 게 맞다. 통합에 들이는 설계 비용은 나중에 흡수/폐기될 때 아무 의미가 없기 때문이다.

최종 판단 기준 (정리)

같은 고민이 반복될 걸 대비해 판단 기준을 남겨둔다.

질문 통합 쪽으로 기우는 답 독립 쪽으로 기우는 답

이 기능이 기존 시스템과 같은 사용자층/업무 범주인가?	예	아니오 (다른 부서/전사 범위)
영구적으로 이 시스템의 일부가 될 것인가?	예	아니오 (임시 다리, 추후 다른 시스템에 흡수 예정)
통합 시 필요한 추가 설계(다중 DB, 권한 분리 등)가 단순한가?	예	아니오 (라우터, 그룹 분리 등 복잡도 증가)
인수인계/유지보수 관점에서 어느 쪽이 설명하기 쉬운가?	통합	독립

특히 마지막 질문이 실무적으로 크게 작용했다. 퇴사/인수인계를 앞둔 상황에서는 "이 도구가 왜 여기 있는지"를 다음 사람이 짧게 이해할 수 있는 구조가 기술적 우아함보다 중요했다.

곁가지 판단: 언어/프레임워크 선택

기존 시스템이 Django였지만, 다음 이유로 새 프로젝트는 Flask로 결정했다:

• 스코프가 작다 (화면 5개 내외) — Django의 강점(Admin 자동화, 복잡한 앱 간 관계)을 살릴 데가 없음
• 처음 써보는 프레임워크라 학습 목적도 있었음
• 동료가 별도로 Node.js/NestJS 기반 신규 플랫폼을 구축 중이라, "그쪽으로 언젠가 흡수될 것"을 고려하면 지금 Python 새 프레임워크에 깊이 투자하는 것보다 가볍게 가는 게 맞다고 판단

요약

작은 부속 기능을 만들 때는 "기술적으로 통합 가능한가"보다 "이게 영구적인 물건인가, 임시 다리인가"를 먼저 정하는 게 설계 방향을 훨씬 빨리 잡아준다. 임시라면 통합의 복잡성을 감수할 필요가 없고, 오히려 독립시켜서 나중에 통째로 옮기거나 버리기 쉽게 만드는 게 낫다.

다만 "임시"가 "허술해도 된다"는 뜻은 아니었다. 실제로 만들면서 캠페인 발송 전 테스트 승인 절차, 발송 이력 기록, 장애 격리 같은 최소한의 안전장치는 필요하다는 게 드러났고 — 이 부분은 다음 글들에서 다룬다. 대신 그 이상의 기능 확장(개별 재발송, CSV 내보내기 등)은 의도적으로 손대지 않았다. 정식 시스템과의 통합/분리 여부는 여전히 미정이라, 지금 만드는 게 나중에 그대로 흡수되거나 버려질 걸 감안하면 "필요한 안전장치는 갖추되, 그 이상은 욕심내지 않는다"가 이 프로젝트 전체를 관통한 기준이었다.

이 시리즈의 다른 글

이 판단을 바탕으로 실제 구현한 과정은 이어지는 글들에서 다룬다.

1. (이 글) 독립시킬지 통합할지 판단한 과정
2. 프로젝트 개요와 구조
3. 이메일 캠페인 DB 설계 노트
4. Flask 첫 프로젝트에서 마주친 삽질들
5. 캠페인 상태 머신: 테스트 없이 실제 메일이 나가지 않도록 만들기
6. HTML 이메일 렌더링 트러블슈팅
7. 서로 다른 두 고객 데이터소스를 하나의 구독자 목록으로 통합하기
8. 발송 이력과 장애 격리
9. Docker + Synology NAS 배포