위로미 v3

AI 마음건강 상담 키오스크 '위로미'의 FastAPI 백엔드를 전면 재설계한 버전입니다. 마음검사·마음우체통·마음전화·모바일·관리자 다섯 기능이 한 백엔드에 얽혀 있어, 기능이 서로의 변경에 흔들리지 않도록 도메인을 다시 갈랐습니다. NEXV 첫 인턴 프로젝트입니다.

들어가며 — 기능 하나를 고치면 다른 기능이 흔들렸습니다

안녕하세요. NEXV에서 첫 인턴 프로젝트로 AI 마음건강 상담 키오스크 '위로미'의 FastAPI 백엔드를 맡은 임현우입니다. 위로미는 마음검사·마음우체통·마음전화·모바일·관리자, 이렇게 다섯 기능을 하나의 서비스로 묶은 제품이었습니다.

제가 합류했을 때 이 다섯 기능은 한 백엔드 안에 그대로 얽혀 있었는데요. 마음우체통 로직을 손보면 마음전화 흐름이 같이 출렁였고, 관리자 화면을 위해 데이터 모양을 조금 바꾸면 사용자용 상담 응답이 영향을 받았습니다. 어디까지가 누구 책임인지 코드만 봐서는 선이 보이지 않았거든요. 한 군데를 고치면 멀쩡하던 다른 곳이 흔들리는, 전형적인 변경 전파의 고통이었습니다.

키오스크 시작 화면 — 마음검사·마음우체통·마음전화 세 갈래로 상담 진입을 안내합니다. 사용자 눈에는 깔끔한 세 갈래지만, 그 뒤 백엔드에서는 다섯 기능이 한 덩어리로 묶여 있었습니다.

왜 다시 갈라야 했나 — 여기는 사람의 마음과 의료 정보가 오가는 곳이거든요

사실 모놀리식 자체가 죄는 아닙니다. 규모가 작고 한 사람이 다 보는 서비스라면 한 덩어리가 오히려 편할 때도 있거든요. 그런데 위로미는 조달청 혁신제품으로 실제 기관에 납품되는 제품이었고, 다루는 데이터가 평범하지 않았습니다.

위로미는 이용자의 마음 상태를 묻고, 고민을 듣고, 그 내용을 바탕으로 상담을 이어 갑니다. 의료 성격의 개인정보(PII)가 오간다는 뜻이고, 상담 중에 위험 신호가 잡히면 놓쳐선 안 되는 서비스라는 뜻이었습니다. 기능이 서로 얽혀 있으면 이 데이터가 어디서 만들어지고 어디서 지워지는지, 위험 신호를 누가 책임지고 감지하는지가 흐릿해집니다. 사람의 안전과 프라이버시가 걸린 자리에서 그 흐릿함은 그냥 둘 수 없었습니다.

그래서 목표를 이렇게 잡았습니다. 다섯 기능이 서로의 변경에 덜 흔들리도록 책임 경계를 코드로 분명히 긋고, 안전과 관련된 요구사항은 어딘가에 숨지 않게 도메인 규칙으로 드러내자.

AI가 고민을 되묻고 답변에 공감하며 상담을 이어 가는 대화 기록 — 이 대화 한 줄 한 줄이 의료 성격의 개인정보입니다.

어떻게 풀었나 — 얽힌 덩어리를 도메인 단위로 다시 그었습니다

가장 먼저 한 일은 경계 긋기였습니다. 한 덩어리였던 백엔드를 기능이 아니라 도메인 단위로 다시 보고, 라우터/서비스/DAO의 4단 레이어드 구조로 재편했습니다. 그렇게 11개 도메인 라우터로 책임을 갈랐습니다.

1
라우터 (요청 경계)
도메인별로 라우터를 분리해 마음검사·마음우체통·마음전화·모바일·관리자가 각자 입구를 갖게 했습니다. 한 도메인을 바꿔도 다른 도메인의 입구는 건드리지 않습니다.
2
서비스 (도메인 규칙)
비즈니스 로직과 도메인 규칙을 이 층에 모았습니다. 고위험군 스크리닝 알람, 의료 PII 처리 같은 안전 규칙을 여기서 명시적으로 다뤘습니다.
3
DAO (데이터 접근)
MariaDB·RDS 접근을 DAO로 격리해, 데이터 모양이 바뀌어도 그 여파가 상위 층으로 새어 나가지 않게 막았습니다.

이렇게 층을 나누고 나니, 이 기능을 고치려면 어디를 봐야 하느냐는 질문에 코드 구조 자체가 답을 주기 시작했습니다. 기능이 늘어도 새 도메인 라우터를 더하는 식으로 확장하면 되니, 다섯 기능이 한 덩어리로 출렁이던 문제가 도메인 단위로 갈렸습니다.

음성 상담 중 대화 종료 여부를 예/아니오로 묻는 분기 화면 — 마음전화 도메인의 흐름입니다. 이런 분기 로직이 다른 도메인과 섞이지 않도록 라우터 경계를 그었습니다.

왜 안전 요구사항을 굳이 도메인 규칙으로 끌어올렸나

재설계에서 제가 가장 신경 쓴 건 안전 요구사항을 코드 어딘가에 묻어 두지 않는 것이었습니다. 고위험군 스크리닝 알람이나 의료 PII 소프트 삭제 같은 규칙은 잘 보이지 않는 곳에 끼워 두면, 다음 사람이 그 기능을 모르고 흐름을 바꿀 위험이 있거든요.

그래서 이런 규칙들을 서비스 층의 도메인 규칙으로 끌어올려, 해당 도메인을 다루는 사람이라면 반드시 마주치게 했습니다. PII는 곧바로 물리 삭제하지 않고 소프트 삭제로 다뤄 복구 가능성과 추적성을 남기되, 그 처리 책임이 어느 도메인에 있는지 분명히 했습니다. 안전은 나중에 챙기는 부가 기능이 아니라 그 도메인의 정의에 포함된 규칙이어야 한다고 봤습니다.

선택지	장점	치러야 한 비용
모놀리식을 그대로 둔다	당장 손댈 일이 없다	다섯 기능이 계속 서로 흔들리고, 안전 규칙이 묻힌 채로 남는다
도메인별 4단 레이어드로 재설계 (선택)	기능이 서로의 변경에 덜 흔들리고, 책임 추적과 확장이 쉬워진다	초기 재편 비용이 든다 — 한동안 같은 동작을 구조만 바꿔 다시 만들어야 했습니다

재설계의 핵심 트레이드오프 — 한계를 먼저 인정하고 선택했습니다.

재편 비용은 적지 않았습니다. 눈에 보이는 새 기능을 만드는 게 아니라 잘 돌던 걸 구조만 바꿔 다시 세우는 작업이라, 진척이 더디게 느껴지는 구간도 있었거든요. 그래도 사람의 안전이 걸린 제품에서 책임 경계가 흐린 채로 기능을 더 쌓는 쪽이 훨씬 위험하다고 판단했습니다.

결과 — 안전 규칙이 코드 구조에서 드러나게 됐습니다

재설계를 마친 백엔드는 한 덩어리였던 다섯 기능을 11개 도메인 라우터로 갈라 냈고, 그 위에서 라우터/서비스/DAO의 책임이 또렷이 나뉘었습니다. 제가 맡은 이 재설계 범위에서 납품 결함은 나오지 않았습니다.

지표	값
도메인 라우터 재설계	11개
납품 결함	0건
납품 형태	조달청 혁신제품 (B2G) 백엔드

재설계 범위의 정량 결과 (본인 기여 기준).

관리자 대시보드 — 이용자 추이와 고민 키워드 워드클라우드로 상담 현황을 집계합니다. 사용자 도메인과 분리된 관리자 도메인 라우터가 이 화면을 받칩니다.

배운 것 · 남은 과제 — '무결성 먼저'가 매일의 코드 결정이 되더라고요

이 프로젝트에서 가장 크게 남은 건 태도였습니다. 돈이나 사람의 건강이 걸린 곳에서는 화려한 기능보다 정확함이 먼저라는 것. 처음엔 '무결성 먼저'가 다소 추상적인 원칙처럼 들렸는데, 막상 위로미를 만지다 보니 그게 매일의 코드 결정으로 내려왔습니다. PII를 어떻게 지울지, 위험 신호의 책임을 어느 도메인에 둘지를 고를 때마다 그 원칙이 기준이 됐거든요.

물론 모놀리식을 도메인으로 가르는 일은 한 번에 끝나지 않습니다. 경계를 그었다고 모든 책임이 완벽히 떨어진 건 아니고, 기능이 더 늘면 도메인을 다시 들여다봐야 하는 순간이 올 겁니다. 안전 규칙도 한 번 명시했다고 끝이 아니라, 운영하면서 검증을 계속 쌓아 가야 하는 영역이라고 봅니다.

첫 인턴 프로젝트에서 사용자가 보는 화면 뒤의 데이터 흐름을, 어디서 만들어지고 어디서 지워지는지까지 책임지고 설계해 본 경험은 제게 백엔드의 무게를 가르쳐 줬습니다. 저는 이 경험을 지나, 앞으로도 화려함보다 무결성을 먼저 묻는 백엔드 개발자로 일하려 합니다. 아직 다듬을 곳은 남았지만, 남은 과제까지 책임지는 게 다음 제 몫이라고 생각합니다.