13년치 회사 기억을 먹은 AI: Knowledge DB 구축기

TL;DR

• AI에게 이거 분석해 달라고 던지면 hallucination이 나옵니다. 반면 이게 우리 회사에서 세 번째 발생한 이슈고 지난번엔 이렇게 해결했다고 맥락을 주면 정답이 나옵니다.

• 13년 업력의 Slack, Jira, Notion, Datadog, 코드베이스를 하나의 Knowledge DB로 통합했습니다. 이름은 GOM(곰타운) 입니다.

• 인프라팀의 모든 AI 에이전트(Claude Code, Gemini, Codex)는 작업 시작 시 무조건 GOM부터 조회합니다. 이것이 생산성의 비밀입니다.

• 신규 입사자가 1~2주 만에 AI로 온보딩 문서를 직접 고도화하고, 다음 입사자를 온보딩하는 선순환이 실제로 일어나고 있습니다.

데이터에 너무 정직해서 문제였다

캐시/세션 메모리 이슈 시 nginx 봇 패턴 초기 병행 분석
— ElastiCache 메모리 급증 시 키 분석과 동시에 nginx 로그에서
  봇/크롤러 트래픽 비율을 시간대별로 비교

💡 쿼리곰이 틀린 게 아닙니다. 오히려 데이터에 너무 정직해서 문제였습니다. 도메인 특성에 맞는 guardrail과 맥락이 있어야 의미 있는 분석이 나옵니다.

1. AI의 진짜 병목은 기억이다

• 이 도메인, 작년에도 같은 이슈가 있지 않았나? → 모릅니다.

• 이 WAF 룰은 왜 이렇게 설정했지? → 모릅니다.

• 이 배치 서버는 누가 어떤 목적으로 만들었지? → 모릅니다.

2. GOM — 13년치 기억을 가진 Knowledge DB

• gom slack search — 전사 Slack 히스토리

• gom jira search — IMOPS/ISMS 티켓 전체

• gom notion search — Notion 페이지/DB 검색

• gom dbx sql — Databricks SQL 실행

• gom code search — 코드베이스 함수/상수 검색

• gom code graph — 호출 관계 그래프 탐색

• gom code impact — 변경 영향도 분석

• gom learn search — 과거 교정된 규칙 확인

🐻 GOM(곰타운)의 구축 과정과 기술 아키텍처는 Data Engineer 김지호 님이 별도 기술 블로그로 상세히 다룰 예정입니다.

핵심: 물어보는 게 아니라 기억하는 것

Tool Priority Chain (도구 우선순위 체계)

1순위: GOM CLI + 세션 DB 병행
  - 항상 1순위. gom slack/jira/notion search로 히스토리 파악
  - Notion 세션 DB에서 과거 유사 작업/장애 선례를 동시 조회
2순위: API 직접 호출 (Python requests / curl / CLI)
3순위: MCP 서버 도구
최후: Chrome 브라우저 자동화

1. 먼저 gom slack search DDoS로 과거 DDoS 대응 히스토리 확인

2. 먼저 Notion 세션 DB에서 과거 DDoS 세션 페이지를 조회해 판정 기준·대응 템플릿·회고 교훈 확인

3. 그 다음 Datadog API로 현재 트래픽 분석

4. 그 다음 WAF 로그에서 패턴 매칭

3. 실전: GOM이 바꾼 인프라 운영의 하루

Case 1: 보안 취약점 점검 — 전에도 나온 적 있나요

# 1. 과거 동일 취약점 히스토리 조회
gom jira search XSS 게시판 검색
# → IMOPS에서 XSS 관련 티켓 12건 발견
# → 동일 패턴: 게시판 keyword 파라미터 Reflected XSS, 3번째 보고

# 2. 과거 대응 방식 확인
gom slack search XSS 게시판 WAF 차단
# → 2024년: WAF 룰로 차단, 2025년: 코드 수정으로 근본 해결

# 3. 현재 WAF 룰 상태 확인
gom code search XSS filter board
# → 코드베이스에서 관련 필터 로직 확인

Case 2: 이벤트 서버 증축 — 30대가 적정한 근거는

1차 쿼리곰 분석 → 과거 RPS 기록, 이벤트/프로모션/블프 피크 데이터
→ Claude 교차검증
→ 보수적으로 30대 증축. 쿼리곰 굿

Case 3: AWS TAM이 DevOps-Agent를 제안했을 때

💬 저희는 온콜·장애 대응을 이미 자체 AI 시스템으로 해결하고 있습니다. Claude Code + GOM CLI + Multi-Agent + guardrail 정책으로, 장애 발생 시 자동으로 과거 선례를 조회하고 도메인 특화 runbook을 실행합니다.

Case 4: KISA 침해사고 대응 — 사이트 분석부터 신고서까지

# 사이트 히스토리 조회
gom slack search 피싱 사이트.kr
gom jira search 피싱 사이트.kr

# 코드베이스에서 파일 업로드 로직 확인
gom code search xxx.imweb.me upload file type

# Databricks에서 실제 데이터 조회
gom dbx sql SELECT * FROM site_info WHERE site_code = Sxxxxxxxxxxxxxxxx

4. guardrail 없는 AI는 준비 안 된 미팅이다

• 맥락 없이 이거 분석해 달라고 하면 → AI가 일반론 생성 → 아니 그게 아니라는 핑퐁 반복 → hallucination 폭발

• guardrail + GOM으로 맥락 주입 → 과거 선례 조회 → 도메인 정책 확인 → 맥락 위에서 분석 → 첫 응답이 바로 정답

# 실제 guardrail 예시
DD 로그 0건 시 5단계 필수 검증 (절대 포기 금지)
— 0건 = 데이터 없음이 아니라 쿼리 오류 가능성
  (1) 시간대 재확인: KST→UTC 변환을 datetime 객체로 계산
  (2) 필드명 변형 3종 시도
  (3) 시간 범위 3배 확장 재시도
  (4) 총량 쿼리: 필터 없이 전체 건수 먼저 확인
  (5) CW 우회: aws wafv2 get-sampled-requests
  금지: 0건에서 아키텍처 결론 도출

5. 수치로 보는 활용도

6. 신규 입사자가 다음 입사자를 온보딩하는 세계

🔄 더 놀라운 건 4/6에 입사한 분이 4/13에 입사한 분을 온보딩하고 있다는 점입니다. 단 1주일 만에.

🐻 이 온보딩 선순환의 구체적인 경험담은 곧 신규 입사자 본인이 직접 기술 블로그로 공유할 예정입니다.

7. 나 같은 사람 다섯이 동시에 일하는 느낌

• 나(Master): 전체 상황 판단, 의사결정

• Claude(Agent 1): WAF 로그 분석 + GOM으로 과거 DDoS 선례 조회

• Gemini(Agent 2): nginx 봇 패턴 분석 + 트래픽 시계열 정리

• Codex(Agent 3): WAF 룰 코드 리뷰 + 정규식 정밀 검증

왜 엔지니어의 밀도가 중요한가

Deploy Lifecycle Policy (Test → Gradual Rollout → Monitor)

1단계: 테스트 (배포 전 필수)
2단계: 점진적 적용 — Pilot 1개 → 검증 → 확대
3단계: 배포 후 모니터링 — 최소 15분, 에러율/응답시간 확인

💡 엔지니어의 수준과 밀도가 높을수록, AI는 위험한 무기가 아니라 정밀한 도구가 됩니다.

8. 함정: GOM한테 물어보면 되지의 위험

외부 분석 결과(다른 세션/AI/쿼리곰) 수용 시
→ 원본 데이터로 1차 검증
→ 결론만 채택 금지, 근거 데이터를 직접 조회해 교차 검증 후 채택

9. GOM + Claude Code + Multi-Agent = 조직의 두뇌

1. GOM 이 13년치 기억을 제공합니다 (맥락)

2. guardrail 이 도메인 특화 정책을 강제합니다 (안전장치)

3. Multi-Agent 가 분석을 병렬로 수행합니다 (속도)

4. Session DB 가 모든 작업을 기록합니다 (학습)

5. Engineer 가 최종 의사결정을 내립니다 (판단)

10. 다음은?

AI의 가치는 모델의 성능이 아니라, 조직이 축적한 맥락의 깊이에 비례합니다.