김태민 · Kyle Kim

멀티테넌트 SaaS를 스키마 설계부터 무중단 배포·운영까지 혼자 책임집니다. 지금은 BARO에서 프로덕션 트래픽을 받는 SaaS 3종을 만들고 굴리고 있습니다.

목차  ·  01 About  ·  02 AI Leverage  ·  03 Selected Work  ·  04 Engineering Principles  ·  05 Earlier Work  ·  06 Stack  ·  07 Contact

한 사람이 기획 · 스키마 · 백엔드 · 프론트엔드 · 인프라 · 배포 · 운영을 끊기지 않고 가져갑니다.

중간에 넘기지 않기 때문에, 장애의 원인이 쿼리 플랜에 있든 nginx 설정에 있든 같은 사람이 추적해서 고칩니다. 인수인계 비용이 0인 대신, 모든 결정의 책임도 한 사람에게 남습니다.

그래서 판단이 틀렸을 때 빠르게 드러나는 구조를 먼저 만듭니다. 아키텍처 규칙은 문서가 아니라 빌드에, 스키마 변경은 마이그레이션 한 경로로, 배포는 되돌릴 수 있게.

다뤄본 도메인은 중고차 리스, 이커머스, 세무회계, 채용, 광고입니다. 매번 그 업계의 실제 업무 흐름을 먼저 이해한 뒤에 기능을 정의했습니다.

LLM은 기본적으로 비결정적이고, 조용히 틀리고, 요금이 붙는 외부 의존성입니다. 그래서 저는 LLM 호출을 하나의 함수가 아니라 4계층으로 분해해서 다룹니다.

프롬프트 (버전 관리)  →  가드 (입력 검증 · 토큰/비용 상한)
                      →  파싱 (JSON 스키마 강제 · 실패 시 폐기)
                      →  재시도 (지수 백오프 · N회 초과 시 사람에게 에스컬레이션)

이렇게 분리하면 LLM이 실패해도 시스템은 실패하지 않습니다. 파싱에서 떨어진 응답은 DB에 닿지 않고, 재시도 상한을 넘긴 작업은 큐에 남아 사람에게 넘어갑니다.

문제   마케팅 인사이트 콘텐츠를 담당자가 매번 직접 수집 · 선별 · 요약 · 발행했습니다. 반복적이고, 사람마다 톤이 다르고, 무엇보다 다른 일을 밀어냈습니다.

설계   수집부터 발행까지를 5단계 게이트로 쪼개고, 각 게이트를 통과하지 못한 건은 다음 단계로 넘어가지 못하게 했습니다.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#EEF0FE','primaryTextColor':'#1E1B4B','primaryBorderColor':'#6366F1','lineColor':'#6366F1','secondaryColor':'#FEE2E2','tertiaryColor':'#F1F5F9','fontSize':'13px'}}}%%
flowchart LR
    A["G1 수집<br/>소스 검증"] --> B["G2 중복 판정<br/>해시 대조"]
    B --> C["G3 LLM 재작성<br/>스키마 강제 JSON"]
    C --> D["G4 룰 기반 품질검사<br/>길이·금칙어·링크"]
    D --> E["G5 사람 최종 승인"]
    E --> P["발행"]

    C -.->|"파싱 실패"| R["재시도 · 상한 초과 시 폐기"]
    D -.->|"룰 위반"| R

결과   사람이 개입하는 구간이 전 과정 → 최종 승인 1회로 줄었습니다. LLM이 만들어낸 문장이 룰 검사 없이 그대로 발행되는 경로는 구조적으로 존재하지 않습니다.

원본 광고 집행 데이터를 LLM이 요약이 아니라 구조화합니다. 자유 서술이 아니라 고정 스키마(브랜드 · 채널 · 증감률 · 특이사항)로만 응답하게 강제하고, 스키마를 벗어난 응답은 파싱 단계에서 버립니다.

결과는 알림톡 발송까지 자동으로 이어지며, "AI가 이렇게 판단했다"가 아니라 "이 숫자가 이렇게 움직였다"만 전달하도록 출력 범위를 좁혔습니다.

스마트 태스크 배정, 리스크 · QA 루프, 기획 제안 기능입니다. AI는 제안 상태(pending)로만 쓰기 권한을 가지며, 실제 상태 전이는 사용자의 수락을 거칩니다.

AI 기능을 붙일 때 가장 먼저 정한 것은 모델이 아니라 AI가 건드릴 수 있는 데이터의 범위였습니다.

8개월 동안 15개 제품, 1,600+ 커밋. 이 속도는 AI 없이는 불가능했고, AI만으로도 불가능했습니다.

그래서 저는 검증을 사람에서 빌드로 옮겼습니다. 이게 제 AI 활용의 핵심입니다.

작업 루프는 이렇게 돕니다.

마스터플랜 문서(단일 기준선)  →  AI에 컨텍스트로 공급  →  스펙 기반 생성
                                                      →  ArchUnit · gitleaks · Testcontainers 검증
                                                      →  통과한 것만 사람 리뷰

문서와 코드가 어긋나면 문서를 기준으로 삼습니다. 코드를 고치거나, 근거를 단 개정 PR로 문서를 바꾸거나 — 둘 중 하나만 허용합니다.

한 줄로 요약하면

AI는 코드를 빠르게 만들어줄 뿐, 옳게 만들어주지는 않습니다. 그래서 저는 "옳음"의 판정을 리뷰어의 주의력에서 빌드 파이프라인으로 옮기는 일에 시간을 씁니다. 속도는 AI가, 안전망은 제가 만듭니다.

하나의 빌드가 접속 도메인에 따라 서로 다른 고객사의 테마 · 정책 · 데이터로 동작합니다. 방문자가 차량 시세를 조회하고 상담을 남기면, 그 리드가 공정 분배 로직을 거쳐 딜러에게 자동 배정됩니다.

가장 어려웠던 문제 — 교차 테넌트 접근

멀티테넌시에서 가장 위험한 실패는 장애가 아니라 A사 고객이 B사 데이터를 보는 것입니다. 이건 조용히 발생하고, 발생한 뒤에는 되돌릴 수 없습니다.

그래서 테넌트 판별을 애플리케이션 로직이 아니라 요청 진입점에 두고, 인증 경로에서는 한 번 더 교차검증합니다.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#EEF0FE','primaryTextColor':'#1E1B4B','primaryBorderColor':'#6366F1','lineColor':'#6366F1','fontSize':'13px'}}}%%
flowchart LR
    R["요청 Host"] --> T["TenantInterceptor"]
    T --> D{"도메인 매칭"}
    D -->|"미등록"| X["404"]
    D -->|"테넌트 확정"| CTX["TenantContext"]
    CTX --> G{"인증 경로?"}
    G -->|"공개"| OK["요청 처리"]
    G -->|"인증"| J["JWT tenantId 교차검증"]
    J -->|"불일치"| B["403 차단"]
    J -->|"일치"| OK

    style X fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D
    style B fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D
    style OK fill:#DCFCE7,stroke:#16A34A,color:#14532D

공개 웹사이트 4종, 운영 백오피스, 인증 인프라를 한 저장소에서 운영합니다. 방문자는 포트폴리오와 마케팅 인사이트를 보고 문의 · 결제까지 진행하고, 임직원은 SSO로 로그인해 콘텐츠 · 고객사 · 권한 · 결제를 한곳에서 관리합니다.

결정한 것 — 인증을 애플리케이션에서 떼어낸 이유

앱이 5개인데 인증 로직이 5벌이면, 권한 정책 한 줄을 바꿀 때 다섯 군데를 고쳐야 합니다. 그래서 통합로그인 BFF를 별도 서비스로 분리하고, Keycloak 26을 신원 소스로, RBAC(resource:action)를 DB에 두었습니다.

대가는 런타임이 둘로 늘어난 것(EC2 Docker Compose + ECS Fargate)이고, 얻은 것은 권한 정책 변경이 배포 없이 반영된다는 점입니다.

자동차 리스 · 렌트 리드를 모바일 랜딩으로 모아 → 규칙대로 배분하고 → 계약 결과를 되받아 학습하는 플랫폼입니다.

이 프로젝트에서 제 역할은 기능을 많이 만드는 게 아니라, 레거시에서 반복되던 결함이 다시는 사람의 주의력에 의존하지 않도록 골격을 세우는 것이었습니다.

구조   단일 배포 단위 위의 모듈러 모놀리스 11모듈. 모듈 간에는 상대의 api 인터페이스만 참조하고, 엔티티 공유와 크로스 JOIN은 금지합니다.

비동기는 도메인 이벤트로 — ApplicationEventPublisher → outbox → SQS. 진행은 날짜가 아니라 게이트 G0~G5로 관리합니다. 게이트를 통과하지 못하면 다음 단계로 넘어가지 않습니다.

쿠팡 셀러가 흩어져 보던 광고 · 매출 · 키워드 데이터를 한 화면으로 모았습니다.

크롬 확장 프로그램이 상품별 판매 추이를 자동 수집하고, 대시보드가 그 데이터를 마진 · 광고 효율(ROAS) · 키워드 순위로 풀어냅니다.

수작업 취합을 자동화해, 셀러가 데이터 정리가 아니라 판단에 쓸 시간을 남기는 게 목표였습니다.

_{Vue 3  ·  Spring Boot 3.2  ·  Redis  ·  AWS  ·  Chrome Extension}

인사팀 채용 자동화 프로그램  ·  _{Python · Selenium · Desktop} 브라우저에서 손으로 반복하던 채용 업무를 데스크톱 프로그램으로 자동화했습니다. 담당자 자체 측정 기준 반복 처리 시간 약 60% 감소.

SNS 매체 계정 통합 관리 플랫폼 계정마다 따로 로그인하던 구조를 단일 콘솔로 통합해 120개 계정을 한곳에서 관리합니다. 계정 수에 비례해 늘어나던 운영 비용을 구조적으로 끊어낸 작업입니다.

OnClass — 전자책 이커머스  ·  _{Java · Spring · Vue.js · MySQL} 전자책 상품의 등록 · 판매 · 결제까지 다루는 커머스 플랫폼.

세무회계 현 — 홈페이지 + CRM 콘솔  _{2026.06 – 2026.07 · 외주 · 단독}

공개 문의가 들어오면 이메일 / 전화 기준으로 고객 레코드에 자동 연결되고, 그 고객이 상담 · 세무기한 · 내부업무 · 후속조치 일정으로 이어집니다.

• 백엔드 도메인 11종 — 고객 · 문의 · 세무건 · 업무 · 일정 · 문서 · 동의 · 활동로그 · 사이트 콘텐츠
• Flyway + ddl-auto=validate로 엔티티와 실제 스키마의 불일치를 기동 시점에 차단
• H2 + Testcontainers 이중 테스트 — 빠른 피드백과 실제 마이그레이션 검증을 분리
• 브랜드 시스템 직접 설계 — 딥네이비 톤, 로고 라인드로우 애니메이션, prefers-reduced-motion 대응

_{React  ·  TypeScript  ·  GSAP  ·  Spring Boot 3.5  ·  MySQL 8.4  ·  Playwright}

PlanFlow — 워크스페이스 우선 협업 플랫폼  _{2026.02 – 2026.07 · OpenAI × 조코딩 해커톤 · 1인 수행 · 커밋 275}

프로젝트 · 일정 · 문서 · GitHub · 채팅을 워크스페이스 단위로 격리해 다룹니다. 기획부터 개발 · 제출까지 혼자 완주했습니다.

• 스프린트 / 에픽 · 보드 · 캘린더 · QA 항목 · 워크플로 제안
• STOMP / SockJS 기반 실시간 그룹 채팅 · DM · 프레즌스 · 알림 인박스
• GitHub App 연동 — 저장소 연결, 커밋 / PR 동기화, 태스크 ↔ PR 링크
• AI 어시스트 — 스마트 태스크 배정, 리스크 / QA 루프 (사례 3)
• 팀 자격증명 — reveal 플로우와 감사 기록을 갖춘 공유 시크릿 관리
• Polar 구독 결제 · 웹훅, S3 파일 스토리지, PDF / Office 텍스트 추출

_{Spring Boot 4  ·  Java 17  ·  MySQL 8  ·  Redis  ·  React 19  ·  Vite 7  ·  STOMP / SockJS  ·  OAuth2 + JWT}

OneStack — IT 전문가 매칭 & 협업 플랫폼  _{사이드 팀 프로젝트 · 팀장}

IT 전문가와 프로젝트를 매칭하고, 실시간 채팅 · 화상회의로 협업하는 커뮤니티 플랫폼입니다. 요구사항 정의, 아키텍처 설계, 핵심 기능 개발, 배포까지 리딩했습니다.

_{Java  ·  Spring Boot  ·  WebSocket  ·  AWS  ·  Docker}

아래는 "써봤다" 목록이 아니라, 어느 깊이까지 책임져봤는지를 구분한 목록입니다.