Skip to main content

B2B AI 심리케어 서비스 Bloom 회고

· 7 min read
te
te
Sofrware Engineer

KT Cloud TECHUP 사이버 보안 과정의 실무 프로젝트로, B2B AI 심리케어 서비스 Bloom을 개발했습니다.

프로젝트 개요​

팀 구성:

  • 7팀, 기획·디자인·AI·백엔드·인프라/보안으로 구성된 다직군 팀
  • 각 도메인 전문가들과 함께 실제 제품 수준의 서비스를 기획하고 개발했습니다.

프로젝트 기간:

역할:

총 15인으로 구성된 다직군 팀의 리드를 맡았습니다.

  • 엔지니어링 그룹 (백엔드 / 인프라·보안)
  • Spring API Gateway 개발 및 JWT 인증 아키텍처 설계
  • CI/CD 파이프라인 개발 및 유지보수
  • 데이터 프라이버시 및 보안 아키텍처 설계

Bloom — B2B AI 심리케어 서비스​

소개​

Bloom은 회사 안에서 마음이 힘든 구성원이 도움을 받을 곳이 없다는 문제에서 출발했습니다.

많은 기업이 일회성 리더십 특강이나 사내 심리 상담 프로그램을 운영하지만,
특강은 일회성이고 심리 상담은 진입 장벽이 높습니다.
'나 지금 힘들어요'라고 공식적으로 신고하는 느낌 때문에, 정작 필요한 사람이 이용하지 않습니다.

직장인 70명 설문에서 97%가 프라이버시 우려로 사내 EAP를 기피한다는 결과가 이를 뒷받침합니다.

이 문제를 해결하기 위해 저희는 두 가지 핵심 기능을 개발했습니다:

  • 그린룸(Greenroom): CBT(인지행동치료) 기반 초개인화 AI 팟캐스트 상담 서비스
  • 마인드 온톨로지(Mind Ontology): 익명화된 데이터를 시각화하여 조직 심리를 진단하는 B2B 관리자 솔루션

타겟 시장은 국내 약 5,000억 원 규모의 EAP 시장과 연간 1.5~1.7조 원, 연평균 20% 성장 중인 개인 심리관리 시장입니다.

기여​

백엔드 엔지니어로서 기여한 주요 내용은 다음과 같습니다:

  • Spring API Gateway 설계 및 개발 — JWT 인증 검증 및 내부 헤더 재주입 구조
  • CI/CD 파이프라인 설계 및 개발 — 변경 감지 기반 서비스별 선택적 빌드·배포
  • 보안 아키텍처 설계 — 개인 식별 정보 비식별화 프로세스 및 데이터 격리 구조
  • Auth Service 설계 참여 — JWT 토큰 관리, 약관 동의 플로우

시스템 설계 및 동작 원리​

백엔드는 클라이언트·애플리케이션·인프라 계층으로 분리된 MSA 구조입니다.

모든 외부 요청은 Spring Gateway를 통해서만 내부 서비스로 전달되며,
인증·라우팅·공통 필터링을 한 곳에서 처리합니다.

내부 서비스는 크게 세 가지로 구성됩니다:

Auth Service

  • 인증, 토큰 관리, 알림 설정, 조직 초대를 담당합니다.
  • AI 서비스 요청에는 반드시 유효한 사용자 컨텍스트가 필요하기 때문에, 로그인 시 약관 동의와 초기 설정 동기화를 먼저 완료하도록 구성했습니다.

Greenroom Service

  • AI 에이전트와 가장 긴밀하게 통신하는 핵심 서비스입니다.
  • 사용자의 상담 데이터를 AI 서버로 전달하고, 분석 결과를 수신해 저장·관리합니다.
  • AI 응답은 Kafka를 통해 비동기 처리하여, AI 응답 지연이 다른 서비스에 영향을 주지 않도록 격리했습니다.

Notification Service

  • AI 분석 완료 등 주요 이벤트가 발생하면 알림을 발송합니다.
  • 스케줄러가 큐에 적재하고 Consumer가 병렬 처리하며, 실패 건은 DLQ(Dead Letter Queue) 로 분리해 재처리할 수 있도록 했습니다.

AI 파이프라인​

Bloom의 AI 시스템은 12개 에이전트로 구성된 5단계(TIER) 파이프라인으로 작동합니다.

TIER 0 : Intent Classifier — 사용자 의도 분류
TIER 1 : Safety · Emotion · Content · Reasoning — 병렬 실행
TIER 2 : Script Generator · Image Generator — 대본 및 이미지 동시 생성
TIER 3 : Batch Validator — 5단계 자기검증, 임계값 미달 시 최대 2회 재시도
TIER 4 : Personalizer — 개인 맞춤 조정

특히 Safety 에이전트는 CRISIS를 감지하는 즉시 전체 실행을 취소하고 안전 안내 문구를 출력합니다.
안전을 사후 처리가 아닌 구조로 설계한 점이 인상 깊었습니다.

LLM은 역할별로 분리 배치했습니다:

  • 고추론 구간(Safety·Reasoning·Personalizer): 대형 모델 (AWS Bedrock)
  • 고속 분류 구간(Emotion·Content·Script·Validator): 경량 모델

비용과 지연을 동시에 최적화하는 설계로, AI팀의 노력이 특히 돋보였습니다.

RAG는 Pinecone(에피소드·지식) 과 Neo4j(GoT 그래프) 의 이중 레이어 구조를 사용하며,
최종적으로 검증 정확도 0.863, 12개 에이전트 파이프라인 완성이라는 성과를 달성했습니다.

보안 아키텍처​

Bloom은 심리 상담 데이터라는 극도로 민감한 정보를 다루기 때문에,
보안과 프라이버시를 서비스의 전제 조건으로 설계 단계부터 내재화했습니다.

데이터 소유권 및 격리​

  • 사용자 동의 없는 정보 제공 원천 차단
  • 동의 시에도 익명 키워드 수준으로만 최소 제공
  • 사측으로부터의 민감 데이터 유출 프로세스 물리적 분리

AI 입출력 보안​

프롬프트 인젝션과 PII(개인 식별 정보) 유출을 방지하기 위해 Input·Output 이중 Sanitizer를 모든 에이전트의 공용 인프라로 설계 단계부터 내재화했습니다.

이전 프로젝트에서 s2n으로 XSS·SQL Injection·CSRF 같은 공격을 탐지하는 도구를 만들었고,
c2z에서 CVE를 직접 재현하는 경험을 했습니다.
이 과정에서 쌓은 공격자 관점이 Bloom의 보안 설계에 실질적으로 도움이 됐습니다.

CI/CD 파이프라인​

변경 감지 기반 선택적 빌드​

MSA 구조상 서비스가 여러 개로 분리되어 있어, 작은 수정에도 전체를 빌드하면 시간이 오래 걸립니다.
이를 해결하기 위해 paths-filter를 활용한 변경 감지 기반 CI를 적용했습니다.

# 변경된 서비스 폴더만 감지
- uses: dorny/paths-filter@v2
  with:
    filters: |
      auth:
        - 'auth-service/**'
      greenroom:
        - 'greenroom-service/**'
      notification:
        - 'notification-service/**'

변경이 발생한 서비스만 골라 해당 이미지만 빌드하도록 구성했습니다.

서비스별 독립 배포​

모든 서비스를 하나의 공통 서버에 함께 배포하는 방식이 아니라,
서비스별 배포 단위를 분리하여 각 서비스가 자신의 대상 EC2에 독립적으로 배포되도록 구성했습니다.

이를 통해 배포 범위를 최소화하고, 다른 서비스에 미치는 영향을 줄였습니다.

중간 발표 이후 인프라팀과 개발팀 간 책임 범위를 명확히 나누는 과정을 거쳤는데,
그 결과 CI/CD 파이프라인은 백엔드 개발자가 담당하게 되었습니다.
처음에는 경계가 모호했지만, 이 과정을 통해 팀 내 역할 분리와 소통의 중요성을 다시 배웠습니다.

트러블 슈팅 및 기술적 도전​

Gateway JWT 위변조 문제​

초기에는 클라이언트가 사용자 헤더를 직접 전달하던 구조였습니다.
이 방식은 위변조 위험과 각 서비스마다 검증 로직이 중복된다는 문제가 있었습니다.

이를 해결하기 위해 Gateway에서 JWT를 검증한 뒤 신뢰된 내부 헤더를 재주입하는 방식으로 개선했습니다.

클라이언트 → Gateway (JWT 검증) → 내부 헤더 재주입 → 내부 서비스
                                    ↑
                              X-User-Id, X-User-Role 등

각 서비스는 이 헤더를 신뢰하고 핵심 비즈니스 로직에만 집중할 수 있게 됐습니다.
보안성을 높이면서 코드 중복도 줄인 의미 있는 개선이었습니다.

Greenroom 비동기 중복 처리​

AI 응답이 비동기로 처리되다 보니, 해결 상태가 중복으로 처리되는 문제가 발생했습니다.

Kafka Consumer가 동일한 메시지를 두 번 처리하는 케이스였는데,
서비스 계층에서 resolved 상태를 재검증(idempotency check) 하여 차단하는 방식으로 해결했습니다.

분산 시스템에서 메시지 중복은 언제나 발생할 수 있다는 점, 그리고 이를 방어하는 방법을 몸으로 익혔습니다.

AWS Bedrock 쓰로틀링​

AI 팀에서 AWS Bedrock API 호출 시 쓰로틀링이 발생하는 문제를 마주쳤습니다.

  • Exponential Backoff: 재시도 간격을 점진적으로 늘려 API 회복 여유를 확보
  • Circuit Breaker: 연속 실패 시 해당 구간을 즉시 격리하여 장애가 전체 파이프라인으로 번지지 않도록 처리

이 패턴들은 클라우드 서비스를 다룰 때 필수적인 방어 수단임을 다시 확인했습니다.

회고​

사이버 보안 과정에서 실무 개발까지​

s2n과 c2z를 거치며 보안 스캐너, CVE 재현 환경 같은 방어·분석 도구를 개발했습니다.
Bloom은 처음으로 실제 사용자를 위한 서비스를 개발한 프로젝트였습니다.

기능을 구현하면서도 공격자 관점을 잃지 않으려 했습니다.
JWT 위변조, 프롬프트 인젝션, PII 유출 등의 위협을 구조적으로 차단하는 설계가 자연스럽게 나온 것도,
이전 보안 과정에서 쌓인 감각 덕분이라고 생각합니다.

보안은 기능이 완성된 후 덧붙이는 것이 아니라, 설계 단계부터 내재화해야 한다는 것을
이번에 직접 실천할 수 있었습니다.

다직군 협업​

이전 프로젝트들은 팀원 모두가 개발자였습니다.
Bloom은 기획자, 디자이너, AI 엔지니어, 백엔드 개발자, 인프라 엔지니어가 함께하는 다직군 팀이었습니다.

서로의 언어가 달랐습니다.
기획자가 말하는 '사용자 경험'과 개발자가 구현하는 '플로우'가 같은 말인지 확인하는 것만으로도 회의 시간이 늘었습니다.
처음에는 이것이 비효율처럼 느껴졌지만,
이 과정 없이 만들어진 기능은 결국 다시 돌아오더라는 것을 프로젝트 후반에 알았습니다.

MSA의 복잡성과 설계의 중요성​

s2n은 단일 파이썬 라이브러리, c2z는 Kubernetes 위에 올린 컨테이너들이었습니다.
Bloom은 처음으로 MSA(마이크로서비스 아키텍처) 를 실전에서 다뤘습니다.

서비스 간 통신, 비동기 처리, 분산 인증 — 하나씩 해결할 때는 간단해 보이지만,
이것들이 동시에 맞물리면 생각하지 못한 곳에서 문제가 터집니다.
Gateway에서 JWT를 재주입하는 방식도, Kafka에서 idempotency를 보장하는 방식도,
처음부터 설계 문서에 있었던 것이 아니라 실제 문제를 마주한 뒤 찾아낸 해답이었습니다.

설계는 코드를 짜기 전에 하는 것이지만, 진짜 설계는 코드를 짜면서 완성된다는 것을 배웠습니다.

KT Cloud TECHUP을 마치며​

사이버 보안 입문(s2n) → CVE 재현 인프라(c2z) → AI 서비스 백엔드(Bloom).
약 6개월의 과정이 자연스럽게 이어졌습니다.

각 프로젝트마다 다른 팀원, 다른 기술 스택, 다른 문제를 마주했습니다.
그때마다 처음 보는 것들 앞에서 막막함을 느꼈지만, 돌아보면 그 막막함이 가장 많은 것을 가르쳐줬습니다.

함께해준 팀원들, 그리고 과정을 통해 만난 모든 분들께 감사합니다.

긴 글 읽어주셔서 감사합니다!