국예성Yeseong Kook

문제

채널마다 같은 물건을 다르게 부릅니다. 우리 "인형"이 채널에서는 "봉제인형/완구"입니다. 문자열 유사도로는 "인형"과 "완구"의 점수가 0이라 후보에 오르지 않았고, 가져온 상품은 사람이 카테고리를 일일이 지정해야 했습니다.

질문별 판단

1. 어떤 모델을 쓸까

   목록에서 번호를 고르는 일이라 소형 모델(temperature 0)로 충분하다고 판단했습니다.

   실측골든셋 62건: 1차 분기 recall 100%, recall@5 92%

2. 환각을 어떻게 막을까

   카테고리 코드 대신 번호만 주고받고, 요청에 있던 번호만 통과시킵니다.

   실측없는 카테고리를 만들 수 없는 구조

3. 호출 비용은

   트리를 내려가며 분기 선택 수를 3, 2, 1로 줄였습니다. 고정 3개면 최대 채널에서 5회, 비용이 3배였습니다.

   실측19개 채널 leaf 76,608개 전수 측정, 최대 4회

4. 얼마나 기다릴까

   호출당 지연이 프롬프트 크기와 거의 무관하게 약 700ms라, 예산을 3초에서 5초로 조정했습니다.

   실측빈 호출 645ms, 5,000토큰 729ms. 폴백 62건 중 37건 → 3건

5. 언제 자동 확정할까

   95점 이상만 자동 확정합니다.

   실측144건 실측: 95점 이상 79건 오답 0, 85~90점대 4건 중 1건 오답

결과

• 운영 환경에 적용했습니다. 기능 플래그로 재배포 없이 켜고 끄며, 꺼진 상태의 응답이 도입 전과 바이트 단위로 같음을 23개 케이스로 확인했습니다.
• AI 실패 시 기존 유사도 추천으로 자동 폴백합니다.
• 캐시 히트 시 LLM 호출 0회로 응답이 4.2~5.5초에서 0.5~0.6초가 됩니다. 트리 내용 해시(blake2b)로 캐시를 무효화해 불필요한 재호출을 없앴습니다.

문제

상품 수집은 채널 API를 수백 번 부르는 긴 작업입니다. 컨테이너 여러 대가 같은 작업을 집어가거나, 배포 중에 처리하던 작업이 사라지는 문제가 있었습니다.

질문별 판단

1. 큐 인프라를 따로 둘까

   Redis 없이 PostgreSQL만 씁니다. SELECT … FOR UPDATE SKIP LOCKED로 한 건씩 선점하고, LISTEN/NOTIFY로 등록 즉시 감지합니다. 60초 폴링은 안전망입니다.

2. 작업자가 죽으면

   30초 heartbeat와 reaper가 멈춘 작업을 회수합니다.

3. 배포 중에는

   ECS Task Scale-In Protection으로 처리 중인 태스크를 종료 대상에서 빼고, 종료 시 최대 25초 drain 후 대기열로 되돌립니다.

4. 재처리하면 중복되지 않나

   batch 단위 삭제 후 삽입으로 멱등성을 보장합니다.

결과

• 누적 36,307건 수집(단일 배치 최대 4,866건), 잡 성공률 95%, 처리율 99.2%.
• 최근 30일 API 요청 167,762건 중 5xx 0건.

문제

약 8.6만 줄 규모 백엔드를 여러 명이 함께 개발하는데, 코드 품질과 보안을 보는 기준이 사람마다 달랐습니다. master로 가는 코드를 거르는 장치는 포맷터와 린터뿐이라, 버그나 보안 약점은 리뷰어의 눈에만 기대고 있었습니다. 누가 작성하든, AI 코딩 도구로 작성하든 같은 기준으로 검사받고, 보안 점검을 개인 역량이 아니라 배포 흐름의 한 단계로 만들고 싶었습니다.

질문별 판단

1. 어디서 검사할까

   3단계로 나눴습니다. IDE 즉시 안내 → commit 시 ruff·bandit(수 초) → master push 시 품질 게이트(약 80초). 앞의 두 단계는 개인의 빠른 피드백, 마지막은 팀 공통 기준입니다.

   실측그 외 브랜치는 0초로 통과

2. 어떤 조건으로 막을까

   기존 코드에 쌓여 있던 이슈는 push를 막지 않고, SonarQube 대시보드에서 현황을 보며 따로 정리합니다. push를 막는 건 이번에 새로 바뀐 코드에서 생긴 블로커·버그·취약점, 세 가지뿐입니다. 기존 이슈까지 막으면 손대지도 않은 파일 때문에 아무도 push할 수 없고, 코드 스멜까지 막으면 개발자가 게이트를 우회하게 됩니다. 새 코드의 범위는 커밋 단위로 잘라, 한 번 막혔던 결과가 다음 검사에 남지 않게 했습니다.

   실측기존 이슈 822건을 분석해 보니, 심각도 HIGH로 분류된 것도 98.5%는 실제 결함이 아닌 코드 스멜(복잡도·중복 같은 유지보수 지적)이었습니다. 그래서 심각도가 아니라 종류(블로커·버그·취약점)로 막습니다.

3. 막히면 어떻게 고칠까

   게이트가 막으면 SonarQube 결과를 받아 어디서, 왜, 어떻게 고치나를 터미널에 바로 출력합니다. AI 코딩 도구로 작업하면 이 출력이 그대로 AI의 입력이 되어, AI가 문제 지점을 찾아 바로 고치거나 개발자에게 설명하고 확인받은 뒤 수정합니다.

4. 서버 비용은

   새 서버를 띄우지 않고 이미 운영 중이던 EC2에 컨테이너로 올렸습니다. 분석 중 메모리를 실측해 컨테이너 상한을 정해, 기존 용도에 영향 없이 추가 인프라 비용을 0으로 맞췄습니다.

   실측유휴 1.93GiB, 분석 피크 2.16GiB → 컨테이너 상한 2.6GB

작업 흐름

결과

• 운영 중입니다. 기존 이슈는 대시보드로 추적하고 새 코드만 막는 규칙이라, 개발 흐름을 멈추지 않고 바로 적용했습니다.
• 모든 개발자가 같은 품질·보안 기준으로 검사받습니다. 보안 점검이 개인 역량이 아니라 배포 흐름의 한 단계가 됐습니다.
• AI 코딩 도구로 작업해도 흐름상 반드시 게이트를 거치고, 막히면 AI가 게이트 출력을 보고 원인을 찾아 고칩니다. 잠재 오류를 운영 배포 전에 걸러냅니다.
• 추가 인프라 비용 0.

문제

판매자는 같은 상품을 채널마다 다시 등록합니다. 카테고리 체계, 필수 속성, API 인증 방식이 채널마다 달라서 상품 100개를 5개 채널에 올리면 500번의 수작업이 됩니다.

질문별 판단

1. 채널이 늘어나면

   상품 마스터 한 벌 + 채널 어댑터 N개로 N×M을 1:N으로 바꿨습니다. 새 채널은 어댑터만 구현합니다.

   실측어댑터 19종 구현, 13개 채널 실운영

2. 인프라는

   AWS를 단독 설계·운영합니다. CloudFront OAC로 S3 직접 접근을 막고, VPC Gateway Endpoint로 ECS와 S3 통신을 내부망으로 보냅니다.

3. 배포는

   GitHub Actions로 컨테이너 사전 검증 → ECR push → ECS 배포까지 자동화하고, Health Check에 실패하면 이전 버전으로 자동 롤백합니다.

4. 실패를 어떻게 알릴까

   응답 형식을 하나로 통일하고 에러를 E100~E700 7개 그룹으로 분류했습니다. 대량 작업은 행 단위로 성공·실패를 돌려줘, 한 건 실패로 전체가 롤백되지 않습니다.

결과

• 2026.09.21 일반 사용자 대상으로 정식 오픈했습니다.
• 채널 어댑터 19종을 구현해 13개 채널을 실운영 중입니다. 새 채널은 어댑터 하나만 구현하면 붙습니다.
• 최근 30일 API 요청 167,762건 중 5xx 서버 오류 0건 (2026-09 기준).
• AWS 인프라와 배포 파이프라인을 혼자 설계·구축·운영합니다.