배경

클라이언트 측 OAuth 처리로 인한 토큰 노출 위험, 동일 사용자가 여러 채널(이메일/카카오/네이버/애플)로 가입하여 상담·보관함 데이터가 분산되는 문제, 해외 사용자 미지원, 탈퇴 직후 재가입 어뷰징 우려가 동시에 존재했습니다. 단순 신규 기능이 아니라 이미 운영 중인 사용자 베이스를 무중단으로 새 시스템에 옮겨야 하는 마이그레이션 작업이었습니다.

가설

본인인증 기반 동일인 식별 + OAuth 서버 측 이관 + 신·구 시스템 호환 레이어를 함께 가져가면, 사용자 가입/로그인 실패 없이 무중단으로 전환할 수 있다.

진행 과정

1. OAuth 인증을 클라이언트 측에서 서버 측으로 전면 이관, JWT를 URL에 노출하지 않고 단기 캐시 + 단방향 hash 기반 안전한 리다이렉트 플로우 설계
2. 본인인증 기반 동일인 자동 식별 + 다중 계정 통합 모듈 신설 — 상담·보관함·소셜 계정 등 도메인 데이터 마이그레이션 포함
3. 순환 의존성 해결을 위한 Facade 패턴 도입으로 인증·회원 모듈 경계 정리
4. 분산 락으로 동시 인증 요청 충돌 방어, 트랜잭션 원자성 보장
5. 탈퇴 후 일정 기간 동일 본인인증 기반 재가입 차단 정책 구현
6. 신·구 시스템 점진 전환 호환성 레이어 (fallback + auto-migration) 설계 — 양 시스템 혼용 기간 동안 V1 가입 사용자가 V5 로그인 실패하지 않도록 자동 마이그레이션
7. 해외 사용자 대응 (국가 코드 기반 분기, 국제 전화번호 표준화)

결과

인증 보안 위험 제거, 다중 계정 사용자 데이터 일관성 회복, 무중단 전환 기간 동안 사용자 가입 실패율 0건 유지, 해외 사용자 가입 가능. 호환성 레이어로 인해 신규 시스템 출시 일정이 앱 스토어 심사 일정에 종속되지 않게 됨.

배경

기존 NestJS 모노레포는 도메인이 늘면서 모듈 의존성 추적이 어려워지고 있었고, 의존성 위반이 코드 리뷰에서만 잡혔습니다. JVM/Spring 생태계와 DDD/Hexagonal 아키텍처 도입 가능성을 실제 도메인을 옮겨가며 검증할 필요가 있었습니다.

가설

Hexagonal 멀티모듈 + ArchUnit 기반 자동 검증을 결합하면, 시간이 지나도 의존성이 깨지지 않는 코드베이스를 유지할 수 있다. 또한 외부 시스템(검색·메시징·푸시)을 도메인이 모르게 추상화하면, 시스템 교체 비용이 낮아진다.

진행 과정

1. Spring Boot 3 + Java 21 멀티 모듈 헥사고날 아키텍처 설계 (Inbound / Core / Outbound / Base / Client)
2. 17개 도메인 API를 Hexagonal/DDD 패턴으로 이관 (User, Consulting, Product, Health, Community, Auth, Pharmacist, QnA, Notice, Home, Search, Raffle, GroupPurchase, Address, Push, Management, Campaign)
3. CQRS 유사 패턴: Entity 기반 Reader와 DTO 기반 Query 서비스를 분리 (12개 도메인), QueryDSL 활용
4. Outbox 패턴 + 이벤트 라우터로 도메인 이벤트의 트랜잭션 원자성 보장 및 비동기 디스패치 (17개 핸들러 적용). EventRouter 리팩토링 (213줄 → 56줄)
5. OpenSearch 통합 (한국어 형태소 분석기, Blue/Green 인덱스, k-NN Vector Search + OpenAI Embedding 시맨틱 검색), Kafka 인프라 (idempotent producer, acks=all), Push 알림 추상화 (외부 벤더 라우팅, 배치 발송)
6. NestJS 원본 대비 도메인 동일성 검증 프로세스 자동화 (API 통신 규약 호환성, 4가지 기준 비교)
7. ArchUnit으로 레이어 의존성 자동 검증 — 외부 모듈이 다른 도메인 코어에 직접 의존하면 빌드 실패

결과

17개 도메인 빌드 성공으로 마이그레이션 가능성 검증, 헥사고날 패턴으로 외부 시스템 교체 용이성 입증, 신규 시스템과 기존 NestJS 엔드포인트 호환성 확인.

배경

SNS(인스타그램 카드뉴스, X 트윗, 공동구매 캘린더, 멀티링크 페이지) 콘텐츠 수동 제작 비용이 과다했고, 한편으로는 약사 큐레이션 데이터를 활용한 콘텐츠 자동화의 잠재력이 명확히 있었습니다. 사내에 LLM 파이프라인 사례가 없는 상태에서 0 → 1 신규 구축이 필요했습니다.

가설

LangGraph 기반 노드형 파이프라인 + LLM 품질 평가 루프 + 채널별 전략 분리를 결합하면, 사람이 디자인-카피-검수에 거치는 단계를 자동화하면서도 사람 검수 시점의 품질 기대선을 유지할 수 있다.

진행 과정

1. 5개 채널 파이프라인 단독 설계 — 인스타 카드뉴스, X 약사/공식, 공구 (5포맷 비교 / 제품 소개 / 캘린더 / 1080×1920 릴스 / 멀티링크 페이지)
2. 5포맷 동시 생성 + 품질 평가 루프: 4축 가중 평균(설득력/신뢰/인사이트/콘텐츠 톤)으로 자동 평가, 미통과 포맷만 피드백 주입 후 재생성, 통과 포맷은 그대로 유지
3. 컴플라이언스(의료법) 워딩 규칙을 시스템 프롬프트와 후처리 양쪽에 적용 — 의료/상담 관련 단어 대체 표현 가이드
4. 클라이언트 사이드 시간 필터링 기법 — 멀티링크 페이지는 HTML에 전체 공구 데이터를 인라인하고, 클라이언트 JS가 시간 비교로 현재 오픈 중인 공구만 렌더링 → 서버 재배포 없이 시간 경과만으로 자동 갱신
5. S3 + CDN 자동 배포, Slack 알림(콘텐츠 ZIP 다운로드 버튼), GitHub Pages 비교 리포트 등 운영 도구 일체 구축
6. 멀티 채널 운영을 위한 데이터 거버넌스 — 채널별 독립 이력 관리, 시도 번호별 결과 보존, LLM 환각 ID 필터링

결과

매주 수동으로 진행하던 콘텐츠 업데이트 작업이 자동화됨. 다수 포맷 동시 생성으로 A/B 테스트가 가속됐고, 콘텐츠 운영 인력 비용이 절감됐습니다.

배경

단일 에러 모니터링 도구(Sentry)만으로는 분산 트레이싱·메트릭 수집 한계가 명확했습니다. DB 쿼리·로그·에러를 단일 traceId로 묶어 보지 못해, 운영 중 발생한 장애가 어느 요청 흐름에서 시작됐는지 추적하는 데 시간이 길어지고 있었습니다.

가설

OpenTelemetry 표준 + 기존 Sentry와의 traceId 공유 + 자동 인스트루멘테이션을 결합하면, 도메인 코드를 거의 손대지 않고도 모든 요청·DB 쿼리·로그에 traceId를 자동으로 붙일 수 있다.

진행 과정

1. OpenTelemetry SDK를 사내 공통 라이브러리로 추상화, 환경 변수 한 줄로 활성/비활성 토글 가능
2. Sentry의 traceId 전파자(Propagator)와 OTel SDK를 통합하여 traceId 단일화 — 에러 ↔ 트레이스 ↔ 메트릭 상관 분석 가능
3. ORM(Prisma)과 로그 라이브러리(Winston)에 자동 인스트루멘테이션 적용 → DB 쿼리·로그에 traceId 자동 주입
4. AWS ECS 환경에 사이드카(Sidecar) 배포 구성을 운영 환경 한정으로 점진 적용 (안전 우선)
5. 로컬 개발용 모니터링 스택(OTel Collector + Prometheus + Grafana)을 컨테이너로 패키징하여 팀원이 즉시 사용 가능하도록 제공
6. Grafana 대시보드 25개 패널 프로비저닝 (RPS, 에러율, P50/P95/P99 응답시간, Node.js 런타임 메트릭, Prisma DB 메트릭)

결과

에러 진단 시간 단축, ORM 슬로우 쿼리 가시화, 운영 환경 안정성 개선. 한 번 깔린 인프라 위에 추후 메트릭/트레이스를 추가하는 데 코드 수정이 거의 필요 없어짐.

배경

사용자 참여가 일방향 소비(보관함, 상담)에 그치고 있었고, 친한약사의 차별화 포인트(약사 큐레이션 + 데이터 기반 영양제 분석)를 사용자에게 직접 보여줄 기능이 빈약했습니다. 두 영역(상호작용 + 데이터 인사이트)을 동시에 채워야 했습니다.

가설

댓글·좋아요·신고를 정규화된 도메인으로 새로 짜고 비회원 조회를 열면 SEO 유입 + 사용자 활성화를 동시에 잡을 수 있고, 영양 성분 함량을 일일 섭취 기준으로 환산하면 단순 통계가 아닌 개인화된 비교 기준(상위 N%, 일일 권장 대비)을 제시할 수 있다.

진행 과정

커뮤니티 도메인

1. 댓글 / 답글 / 좋아요 / 신고 도메인 신설 — DDL 정규화, check constraint, enum 기반 신고 사유
2. 커서 기반 페이지네이션 — offset 방식 한계 회피
3. 비회원 조회 가능 + 비동기 이벤트 속도 개선 — SEO 유입 대응
4. 사용자 랭킹 — 가장 많이 좋아요/댓글 단 유저 조회
5. CRM 연동 — 답글 생성 이벤트로 외부 CRM 알림

건강 기능

1. 영양 성분 함량 분석 — 이벤트 기반 트리거, 1회 섭취 × 일일 횟수 환산, 단위 변환 케이스(mg/μg)
2. 건강 활동 집계 배치 — 보관함·상담 활동 일일 집계, 상위 percentile 응답
3. 건강 고민 큐레이션 — 사용자 건강 고민에 맞는 영양제 함량 분석 케이스 매핑
4. 콘텐츠 메타데이터를 외부 SaaS(Airtable)로 이관 — 비개발자(콘텐츠 운영팀) 직접 운영

결과

사용자 상호작용 도메인 구축, 비회원 SEO 유입 채널 확보, 차별화 가능한 데이터 기반 기능 출시, 콘텐츠 운영의 개발자 종속 제거.

배경

Flutter native로 작성된 한 줄 상담 작성/완료 페이지의 디자인을 바꿀 때마다 앱 스토어 배포가 필요했습니다. 디자인 iteration 주기가 출시 사이클에 묶여 있었습니다.

가설

자주 바뀌는 페이지(작성·완료)만 WebView로 빼고 native UX 디테일(swipe back, 미저장 콘텐츠 보호)은 native ↔ web 약속된 인터페이스로 처리하면, native 동등성을 잃지 않고도 디자인 자유도를 확보할 수 있다.

진행 과정

1. 한 줄 상담 작성·완료 페이지를 React 웹뷰로 전환, 수정 모드는 Flutter 유지 (점진 전환)
2. swipe back / 브라우저 뒤로가기 인터셉트 패턴 설계 — 미저장 콘텐츠 보호 모달을 웹에서 노출하고 native가 그 결정에 따르는 구조
3. 딥링크 라우팅 정합성 개선 (앱 ↔ 웹 경로 매핑)
4. 알림 모달 파라미터 등 동적 진입점 지원

결과

디자인 iteration이 앱 배포에서 분리되어 출시 주기 단축, 웹/앱 UX 일관성 확보.

배경

모놀리식 NestJS 백엔드가 비대해져, 일부 도메인 변경에도 전체 빌드/배포가 필요했고, 공통 유틸이 도메인 디렉토리마다 흩어져 있었습니다.

가설

워크스페이스 기반 모노레포 + 공통 라이브러리 분리 + 앱 단위 독립 배포로 전환하면, 변경의 격리와 빌드 시간 단축을 동시에 얻을 수 있다.

진행 과정

1. 모놀리식 NestJS 코드를 모노레포 워크스페이스 구조로 전환, 앱 단위 독립 배포 가능 구조 설계
2. 공통 인프라(텔레메트리, AWS 통합, 유틸)를 공유 라이브러리로 분리
3. CI/CD 파이프라인 정비 — 자체 호스팅 러너, 캐시 최적화, 환경 변수 관리, ECR 단계 정비

결과

빌드/배포 단위 분리로 운영 효율성 개선, 공통 코드 재사용성 향상, 앱별 독립 배포 가능.

배경

기존 강사-학생 매칭은 조건이 복잡해지면서 조회 속도가 느려졌고, 선생님 도메인과 매칭 도메인이 한 데이터 소스에 묶여 있어 도메인 분리도 필요했습니다. 신규 서비스 런칭(설탭 3.0) 시점에 매칭 알고리즘 고도화 + 어드민 기능까지 동시에 요구되었습니다.

가설

매칭에 필요한 데이터를 선생님 도메인에서 별도 데이터 파이프라인으로 추출하고, MongoDB의 복합 인덱싱 + Aggregation을 활용하면 검색 속도 개선과 도메인 분리를 동시에 달성할 수 있다.

진행 과정

1. 14가지 매칭 조건(전공, 경력, 성격, 수업 가능 시간 등)을 적용한 추천 알고리즘 설계
2. MongoDB 복합 인덱싱 + Aggregation 기반 검색 (Mongo Search) 활용
3. CDC(Change Data Capture) 기반 데이터 파이프라인 구축 — 타 도메인(프로필, 일정, 리뷰)의 데이터를 매칭 도메인에 비동기 반영
4. 관리자용 어드민 페이지 — 매칭 결과 검토, 수동 수정, 강사 배정
5. Redis Key Expiration Event를 통한 내부 스케줄링 구현
6. Outbox Pattern으로 비동기 메시지 신뢰성 확보

결과

기존 시스템 대비 약 70% 검색 속도 향상, 매칭 도메인 독립 배포 가능, 관리자 매칭 개입 자동화.

배경

기존 교재 업로드는 script 기반이라 휴먼 에러가 빈번하고, 등록 결과를 명시적으로 확인할 수 없었습니다. 발행 시점도 관리자가 통제할 수 없었고, 메타데이터 부재로 검색·데이터 분석이 불가능했습니다. 약 6백만 건의 교재 데이터 + 9백만 건의 사용자 필기 데이터를 운영 중인 시스템에서 무중단으로 마이그레이션해야 했습니다.

가설

교재 데이터(전처리 필요)와 필기 데이터(실시간 생성·수정·유실 불가)는 제약이 다르므로, Kafka CDC + Dual Write + 점진적 read 비율 전환을 결합하면 데이터 유실 없이 cutover 할 수 있다. DFS / Dynamic Programming 알고리즘으로 데이터 중복 제거와 관계 재구성을 최적화할 수 있다.

진행 과정

1. 신규 서비스와 기존 서비스에 dual write 적용
2. old DB binlog에 CDC 연결, Kafka Streams에서 검증 로직 구현
3. read 비율 점진 조정으로 cutover 진행
4. 교재 데이터 DFS / Dynamic Programming 기반 중복 제거 + 관계 재구성
5. 새 데이터 구조 전처리 + 메타데이터 부여 (검색·분석 지원)
6. 어드민 시스템 구축 — 등록 결과 명시적 확인, 발행 시점 통제

결과

6M + 9M 데이터를 무중단으로 신규 시스템 이관, 운영 휴먼 에러 제거, 검색·분석 가능 메타데이터 확보.

배경

기존 단순 이미지 기반 컨텐츠로는 양질의 교육 경험을 제공하기 어려웠습니다. 이미지 + 영상 + 해설 등 복합 컨텐츠를 위한 자료 구조 설계와, 등록을 위한 어드민·유저 서비스 구축이 필요했습니다.

가설

Graph 구조 데이터를 그대로 조회하면 비효율적이지만, Closure Table을 별도로 구축하면 조회 성능을 대폭 개선할 수 있다. 또한 읽기 중심 워크로드는 별도 캐시 레이어로 latency를 최소화할 수 있다.

진행 과정

1. 복합 컨텐츠(이미지/영상/해설) 자료 구조 설계
2. Closure Table 별도 생성으로 Graph 구조 조회 최적화
3. 별도 캐시 레이어 도입 — 읽기 중심 워크로드 대응
4. Circuit Breaker 적용 — 온프레미스 Redis 다운 시 반복 재시도로 인한 latency 폭증 방지
5. 어드민 + 유저 서비스 구축

결과

Graph 구조 조회 대비 약 40배 조회 속도 향상, 복합 컨텐츠 등록·조회 시스템 출시, Redis 장애 시 시스템 안정성 확보.

배경

모놀리식 레거시 시스템의 운용이 점점 복잡해지고, 서비스가 커지면서 도메인별 책임 분리가 필요했습니다. 단순히 코드를 쪼개는 것을 넘어, 팀 전체의 운영 표준을 만드는 작업이 필요했습니다.

가설

Hexagonal + DDD 아키텍처 템플릿을 NestJS / Spring Boot 양쪽에 제공하고, 공통 라이브러리·CI/CD 파이프라인을 코드화하여 배포하면, 팀 차원에서 일관된 운영 표준을 만들 수 있다. NestJS의 부족한 기능(Transaction)은 ALS 기반 Custom Decorator로 보완 가능하다.

진행 과정

1. Hexagonal + DDD 아키텍처 템플릿 구현 — NestJS / Spring Boot 양쪽 제공
2. 공통 라이브러리 패키지 (Error Filter, Log Filter, Security 등) 템플릿과 함께 제공
3. 도메인별 Datadog Sidecar 배치 — 도메인 간 흐름 추적, 에러 신속 대응
4. GitHub Action CI/CD 파이프라인 코드화 — 팀 전체 일관 배포
5. NestJS 미지원 Transaction을 위한 ALS(Async Local Storage) 기반 Custom Transaction Decorator 제공
6. API Gateway + Apollo Federation v2 — 클라이언트-서버 종속성 제거, 단일 엔드포인트 + cross-domain 통신. Subgraph는 도메인(=팀) 단위로 분리하여 각 팀이 자기 스키마를 독립 배포
7. DataLoader 패턴 컨벤션화 — 모든 resolver가 DataLoader를 거치도록 강제하여 N+1 쿼리 폭주 방지, 요청 단위 batch + cache
8. Custom Directive 표준화 — @auth, @rateLimit 같은 cross-cutting concern을 스키마 레벨에서 선언적으로 처리하여 도메인 코드 오염 방지
9. 서버 간 통신 규격화

결과

팀 전체 운영 표준화, 도메인별 독립 배포·모니터링, 클라이언트 단일 엔드포인트.

배경

기존 인프라 관리는 휴먼 에러 발생 확률이 높았습니다. AWS에 출처를 알 수 없는 리소스가 만 개 단위로 누적되어 있었고, 기존 리소스를 신뢰하지 못한 개발자들이 계속 새 리소스를 생성해 일부는 limit에 도달했습니다.

가설

IaC(Terraform)으로 모든 리소스를 코드화하고 공통 모듈을 별도 두면, 새 리소스 무분별한 생성을 구조적으로 차단할 수 있다.

진행 과정

1. Terraform으로 모든 백엔드 리소스 코드화 — 일관된 형태로 서빙
2. 공통 모듈 분리 — 공통적으로 사용 가능한 부분은 새 리소스 생성 지양
3. 기존 리소스의 출처·소유권 정리

결과

AWS 리소스 limit 문제 해결, 인프라 관리 일관성 확보, 휴먼 에러 감소.

배경

신규 공유 모빌리티 서비스 ‘시티플라이’를 기획 초기 단계부터 런칭까지 백엔드 책임자로 참여했습니다. 기존 ‘머케인 메이트’ 플랫폼의 유저 데이터를 연동하여 기존 회원이 신규 서비스에서도 연속적으로 사용할 수 있어야 했습니다.

가설

MQTT 통신을 AWS SNS + SQS(fan out) 방식으로 추상화하면 도메인 간 결합성을 제거하면서 fault tolerance를 확보할 수 있다. GeoJSON 기반 권역 설정으로 권역별 관리자 제어를 동적으로 분리할 수 있다.

진행 과정

1. MQTT 통신 → AWS SNS + SQS(fan out) MQ 구현 — 도메인 간 결합성 제거 + fault tolerance 확보
2. 스쿠터 원격 조작 (잠금/해제 등)
3. 정산 내역 확인 및 조정 기능
4. GeoJSON 데이터 기반 권역 설정 + 관리 권한 분리 — 권역별 관리자 제어 권한 할당
5. 기존 플랫폼 유저 데이터 연동 — 유저 변환 모듈 개발
6. 관리자 백오피스 구축

결과

신규 공유 모빌리티 서비스 무중단 런칭, 도메인 간 fault tolerance 확보, 권역별 운영 자율성 보장.

배경

도로교통법 개정으로 면허증 검증 요건이 강화되었습니다. 기존 휴먼 리소스로 확인하던 프로세스는 휴먼 에러와 시간 소요가 컸고, 면허 종류·발급일·갱신 여부 등 복수 항목의 자동 검증으로 확장이 필요했습니다.

가설

AWS Textract + Tesseract-OCR 조합으로 면허증 텍스트를 추출하고, 패턴 매칭·정규표현식으로 검증 로직을 구성하면 휴먼 에러 없이 자동 검증할 수 있다.

진행 과정

1. 면허증 사진 기반 OCR 도입 (AWS Textract + Tesseract-OCR)
2. 면허증 주요 텍스트(이름, 면허 번호, 발급일 등) 추출
3. 패턴 매칭 + 정규표현식 검증 로직 구성 — 허위 입력 방지 + 자동 데이터 정합성 검증

결과

사용자 인증 시간 평균 약 90% 단축, 휴먼 에러 제거, 도로교통법 개정 요건 자동 대응.

배경

IoT 서비스 초기에는 국내 통신사 MQTT 모듈이 불안정해서, 기기가 위수지역(지정 운행 지역)을 벗어나거나 통신 음영 지역에 진입하면 위치를 파악하지 못하는 케이스가 빈번했습니다. 분실·도난 방지가 비즈니스 핵심 리스크였습니다.

가설

상태 이상 이벤트(이탈, 통신 불량 등)를 실시간 감지하고 수거 요청으로 자동 연계하면 분실률을 낮출 수 있다. 마지막 주행 경로를 시각화하면 가맹점주의 수거 작업이 효율화된다.

진행 과정

1. 실시간 모니터링 시스템 설계 — 상태 이상 이벤트 감지 (위수지역 이탈, 통신 불량)
2. 수거 요청 자동 연계 시스템
3. 관리자 / 가맹점주용 웹 어드민 — 수거 대상 기기의 마지막 주행 경로 시각화
4. 현장 운영팀·가맹점주 피드백 기반 UI/UX 반복 개선

결과

수거 요청 처리 시간 약 40% 단축, 분실·고장 기기 수거율 약 25% 향상.

배경

공유 모빌리티 기기에서 전송하는 메시지 처리를 위한 인프라가 필요했고, 기존 배포 방식은 휴먼 에러가 발생할 확률이 높아 자동화가 시급했습니다.

가설

MQTT → AWS SNS + SQS(fan out) MQ로 도메인 결합성을 제거하고 fault tolerance를 확보하며, AWS CodePipeline + GitHub Actions 기반 CI/CD로 배포 자동화 + 테스트 효율을 동시에 개선할 수 있다.

진행 과정

1. MQTT 통신을 AWS SNS + SQS(fan out) MQ로 구현 — 도메인 간 결합성 제거 + fault tolerance 확보
2. AWS CodePipeline + GitHub Actions CI/CD 파이프라인 도입 — 배포 자동화 + 테스트 효율
3. 인프라 모니터링·로그 통합

결과

인프라 개선 이후 장애 발생률 감소 + 기능 배포 주기 단축, 운영 효율성·안정성 동시 향상.

배경

디버깅에서 가장 시간이 많이 드는 건 코드 수정이 아니라 “컨텍스트 수집” 단계입니다. AI 코딩 도구의 진짜 가치는 코드 생성보다 컨텍스트 수집에 있다고 보고, 이를 인프라 레벨로 끌어올리는 실험을 직접 해보고 싶었습니다.

가설

AI 에이전트에게 충분한 도구(코드 검색, 에러 상세, 로그, DB 읽기, 배포 이력)와 안전한 실행 환경만 주면, 사람의 디버깅 첫 30분을 자동화할 수 있다.

진행 과정

1. Sentry → Webhook → 인메모리 큐 → CLI 자율 실행 → 결과 파싱 → GitHub Issue + Slack 발행 파이프라인 설계
2. MCP(Model Context Protocol) 서버 4종 자체 구현 — Sentry / CloudWatch Logs / DB(읽기 전용 트랜잭션 강제) / 배포 이력
3. HMAC 기반 타이밍 세이프 웹훅 검증, 인메모리 큐(동시 실행 제한, 프로젝트별 쿨다운)
4. LLM CLI를 헤드리스 + 예산 상한 + 비세션 모드로 실행, 출력은 Zod 스키마로 강제 검증
5. 출력 발행 채널(GitHub Issue / Slack)은 독립 실패 처리 — 한쪽 장애가 다른 쪽을 차단하지 않음
6. 단위 + 통합 테스트 60건 작성, 아키텍처/보안 리뷰 통과

결과

60건 테스트 통과 + 아키텍처/보안 리뷰 완료 상태로 구동 가능. AI 도구를 단순 사용자가 아닌 운영 가능한 시스템 컴포넌트로 통합하는 패턴을 직접 검증.

배경

Claude Code 같은 LLM 도구는 세션이 끝나면 의사결정·트러블슈팅 맥락을 잃습니다. AI 시대의 새로운 병목은 “코드 생성 속도”가 아니라 “맥락 복원 비용” 이라고 봤습니다.

가설

자동 기록 트리거 + 표준화된 메타데이터 + MCP 도구화를 결합하면, LLM이 사용자 지시 없이 자율적으로 장기 기억을 관리할 수 있다.

진행 과정

1. 자동 기록 트리거 5종 정의 — 기술 의사결정 / 트러블슈팅 / 아키텍처 변경 / 학습 / 프로젝트 횡단(cross-cutting)
2. 자동 참조 규칙 — 세션 시작 시 인덱스 + 프로젝트 메인 페이지 자동 로드
3. 표준화된 frontmatter (type / project / date / tags) 강제 — 검색 가능성 보장
4. Obsidian 호환 wikilink + 그래프 가독성 규칙
5. Cross-cutting 자동 분류 — 여러 프로젝트에 걸치는 패턴 별도 디렉토리 승격
6. MCP 서버 구현 — LLM이 위키 read/write를 1급 도구로 사용 가능

결과

다른 프로젝트로 넘어가도 즉시 맥락 복원, 동일 패턴 재발견 비용 제거, 시간이 지날수록 자산이 누적되는 복리 효과 인프라 확보.

배경

단일 LLM 호출로는 풀기 어려운 작업을 여러 역할 에이전트가 협업하는 형태로 풀 수 있을지 사내에 도입 가능성을 직접 코드로 검증할 필요가 있었습니다.

가설

역할 기반 시스템 프롬프트(Architect / Executor / Critic 등)를 가진 에이전트들을 수렴(convergence) 엔진으로 묶고, 병리(pathology) 감지(같은 피드백 반복, 진동)를 추가하면, 무한 루프 없이 안정적으로 결과에 도달할 수 있다.

진행 과정

1. 역할 기반 BaseAgent 설계 (Claude Agent SDK 기반)
2. Ouroboros 수렴 엔진 + 병리 감지 (oscillation, repetitive feedback)
3. Slack WorkspaceManager — 동적 채널 생성 + 에이전트 메시지 라우팅
4. Express HTTP API + Docker Compose + E2E 통합 테스트
5. Socratic Interview phase — 모호성 분석을 오케스트레이션 앞에 배치

결과

멀티 에이전트 협업의 실용 가능성과 한계를 직접 검증, 사내 개발 도구 도입 논의의 근거 자료 확보.