AI를 디버깅에 사용하는 잘못된 방법 (그리고 실제로 효과적인 멘탈 모델)
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line, formatting, and any code blocks exactly as they are while translating the rest into Korean.
스테이징 인시던트 – AI‑지원 조사
TL;DR – 3명의 시니어 엔지니어가 막다른 길을 몇 시간씩 뒤쫓았다. 나는 Claude에 단 하나의 개방형 프롬프트만 주고 약 20분 만에 미스터리를 해결했다. 돌파구는 AI가 “check X”와 같은 구체적인 명령으로 제한하지 않고 스스로 조사 방식을 바꾸게 한 데서 나왔다.
증상
Slack 메시지
Staging is broken. We're investigating.
스테이징 데이터베이스에서 마이그레이션 도구를 실행했을 때 다음과 같은 오류가 발생했다:
alembic current
ERROR: Can't locate revision identified by 'ba29cdc8739d'
FAILED: Can't locate revision identified by 'ba29cdc8739d'배경: Alembic은 파이썬 데이터베이스 마이그레이션 프레임워크이다. 각 마이그레이션 파일은 고유한 리비전 ID를 가진다. 스테이징 DB는 코드베이스에 더 이상 존재하지 않는 리비전에 머물러 있었는데, 이는 병합되지 않은 브랜치에서 온 마이그레이션이었다.
시니어 팀이 한 일
| 엔지니어 | Claude에 보낸 프롬프트 | 결과 |
|---|---|---|
| A | “GetSecretValue 호출을 위해 CloudTrail을 확인해 — 누가 최근 DB 비밀번호를 가져갔는가?” | 특이사항 없음; 애플리케이션 컨테이너만 비밀에 접근했다. |
| B | “스테이징 서버에서 잘못된 브랜치 체크아웃 흔적을 찾아라.” | 흔적 없음. |
| C | “git 히스토리를 통해 누락된 리비전을 추적해라.” | Claude는 해당 리비전이 이후 커밋에서 이름이 바뀌었다고 보고했고, 그 때문에 문제가 발생했다고 주장했다. 이 주장은 그럴듯했지만 잘못된 것이었다 — 이름 변경은 문제가 시작된 후에 일어났으며, 귀중한 시간을 낭비하게 만들었다. |
교훈 – AI가 자신감 있게 틀린 답을 제시하면 조사자는 그 생각에 고착될 수 있다(하버드/BCG가 설명한 “Jagged Frontier” 효과).
몇 시간 후 팀은 이렇게 말할 수 있었다:
“무엇이 깨졌는지는 알겠지만, 누가 했는지, 언제 했는지는 파악하지 못한다.”
나의 (11개월 된) 접근법
나는 CloudTrail, ECS 등에 대한 지식이 제한적이다. 프롬프트는 의도적으로 최소화했다:
프롬프트 – “Staging이 깨졌어, 조사해줄래? 최신 릴리즈 브랜치를 가져와서 확인해.”
구체적인 지시나 “CloudTrail 확인” 같은 명령은 없었다. Claude는:
- 누락된 리비전이 어떤 메인 브랜치에도 존재하지 않음을 확인했다.
- 해당 리비전을 단일 피처 브랜치와 한 명의 개발자 커밋으로 추적했다.
- 시니어 팀과 같은 벽에 부딪혔다(SSH 실패, 만료된 SSO 토큰, 관련 RDS 로그 없음).
그 뒤 나는 단 하나의 후속 질문을 던졌다:
프롬프트 – “더 똑똑하게 찾을 방법이 있을까?”
Claude는 전술을 바꾸었다.
돌파구
Claude는 마이그레이션 소스 코드를 살펴보면서 INSERT에 NOW()가 created_at 컬럼에 사용된 것을 발견했다. 이는 DB에 저장된 타임스탬프가 마이그레이션이 실행된 정확한 순간이라는 뜻이다.
SELECT rule_type, created_at
FROM firewall_rules
WHERE rule_type IN ('PolicyTypeA', 'PolicyTypeB');결과:
| rule_type | created_at |
|---|---|
| PolicyTypeA | 2026-03-31 22:40:25.477889+00 |
| PolicyTypeB | 2026-03-31 22:40:25.477889+00 |
이 타임스탬프(3월 31일 15:40 PDT)는 피처 브랜치의 git 커밋과 일치했다:
2026-03-31 15:41:20 -0700 — fix: rename migrations and split enum ALTER from seed INSERT마이그레이션은 해당 커밋 55초 후에 실행되었다.
# 그 브랜치에서 누가 커밋했는가?
git log origin/develop..origin/feature/the-branch --format="%an" | sort -u한 명의 저자만 나타났다.
CloudTrail에 아무것도 보이지 않은 이유: 개발자는 DB 비밀번호를 로컬(.env)에 캐시해 두었을 가능성이 높아, 새로운 GetSecretValue API 호출이 발생하지 않았다.
SSH 로그가 비어 있는 이유: 마이그레이션은 스테이징 서버가 아니라 로컬 머신에서 직접 DB에 대해 실행되었다.
데이터베이스 자체가 답을 가지고 있었지만, 아무도 쿼리하지 않았다.
사고 모델 전환
| 인간 지시 | AI 행동 | 결과 |
|---|---|---|
“지난 48 시간 동안 GetSecretValue 호출을 CloudTrail에서 확인해라.” | 체크 수행 → “결과 없음.” | 조사가 … (이하 내용은 원문과 동일하게 유지) |
Source: …
stigation stalls; human must re‑direct. | | “Staging is broken, go look at it.” | Investigates, hits dead ends. | Human asks “Is there a smarter way?” | | “Is there a smarter way?” | AI re‑evaluates the problem, changes approach (from logs → DB artifacts). | Breakthrough. |
핵심 인사이트 – 인간은 목표를 설정하고, AI는 조사 경로를 선택합니다. 경로가 잘못되면 인간이 새로운 방향을 제시해야 합니다. 인간이 AI를 특정하고 익숙한 기법(예: “CloudTrail 확인”)에 고정시키면 조사가 막힐 수 있습니다.
주요 시사점
- 열린 질문을 하면 AI가 대체 증거원을 탐색할 수 있습니다.
- 구체적이고 좁은 질문은 AI(및 팀)를 막다른 길에 가두어 버릴 수 있습니다.
- 데이터베이스(또는 시스템) 자체에 포렌식 단서(타임스탬프, 로그, 감사 컬럼)들이 많이 숨겨져 있어 쉽게 놓치기 쉽습니다.
- 제가 사용한 패턴은 공식적인 프레임워크가 아니라 단일 사건에서 얻은 관찰입니다. 일반화되지 않을 수도 있지만, AI‑보조 디버깅에 유용한 사고 모델을 보여줍니다.
TL;DR
- 시니어 엔지니어들은 AI의 조사 단계를 지시했기 때문에 잘못된 실마리를 몇 시간 동안 쫓았습니다.
- 주니어 엔지니어는 Claude에게 고수준 목표와 “더 똑똑한 방법?”이라는 한 문장을 제시했습니다.
- Claude는 데이터베이스 수준 증거(마이그레이션 타임스탬프)로 전환해 몇 분 만에 원인을 찾아냈습니다.
AI를 사고 대응에 활용할 때는 어떻게 검색할지를 AI에게 맡기고, 방향을 바꿔야 할 때만 개입하세요.
디버깅 과정에 대한 회고
시니어 엔지니어들의 작업은 가치가 있었습니다. 그들은 잘못된 브랜치 배포, 무단 접근, CI 파이프라인 문제 등을 체계적으로 배제했습니다. 그 과정 덕분에 검색 범위가 좁혀졌고, 무엇이 원인이 아닌지를 알 수 있었습니다.
“모른다”는 항상 장점은 아닙니다. 이번 사례에서는 도메인을 몰라서 과도하게 구체화하지 못했지만, 사고 대응이나 수정 작업, 사후 분석 단계에서 무지는 위험 요소가 됩니다.
핵심 교훈은: 강력한 가설이 없을 때는 AI의 탐색 범위를 넓게 유지하는 것이 약한 가설에 얽매이는 것보다 낫다는 점입니다.
AI는 여전히 기술적인 작업을 수행했습니다. Claude는 타임스탬프를 연관시키고, 마이그레이션 소스 코드를 읽고, git 명령을 실행했습니다. 이는 정확하고 분석적인 작업입니다. “열린 질문” 접근법은 제가 AI가 어떤 구체적인 작업을 할지 방해하지 않았다는 의미입니다.
실전 팁: AI와 함께 디버깅이 막혔을 때
현재 접근법이 통하지 않을 경우, 포기하기 전에 다음을 시도해 보세요:
AI에게 어디를 찾아야 할지 말하는 것을 멈추세요.
“X 로그를 확인해라” 대신 → 시도: “A, B, C를 확인했지만 아무것도 찾지 못했습니다. 시스템에 어떤 다른 증거가 있을까요?”구체적인 명령에서 문제 정의로 전환하세요.
“이 함수를 grep해라” 대신 → 시도: “이 엔드포인트가 고장났습니다. 조사해 주세요.”
항상 성공하는 것은 아니지만, 한 문장만 투자하면 새로운 관점을 열 수 있습니다—왜냐하면 그 관점은 스스로 생각해낼 수 없었기 때문입니다.
내 경우의 돌파구: 한 문장 – “더 똑똑한 방법이 있을까?”
이것은 철학이 아니라 실용적인 질문입니다.
결과
스테이징 사고는 해결되었습니다. 증거가 공유되었고, 개발자는 자신의 머신이 원인임을 확인했습니다.
포렌식 팁
마이그레이션에서 INSERT에 NOW()를 사용한다면, created_at 타임스탬프가 범죄 현장 타임스탬프가 됩니다. 이를 git 로그와 비교하면 55초 차이의 결정적 증거를 찾을 수 있습니다.