20분 만에 스테이징 장애 원인을 찾아낸 주니어 개발자와, 몇 시간을 써도 답을 못 찾은 시니어 세 명. 같은 AI 도구, 같은 코드베이스, 같은 에러 로그를 두고 왜 이런 결과 차이가 났을까? dev.to에 올라온 한 편의 인시던트 회고가 이 질문에 정직하게 답한다. 그리고 그 답은 도구의 성능 차이가 아니라, AI와 협업하는 멘탈 모델의 차이에서 비롯된다.
"어디를 봐"가 아니라 "뭘 찾아"
문제의 장면을 복원해 보자. Alembic 마이그레이션 리비전이 코드베이스 어디에도 존재하지 않는다는 에러가 스테이징에 떴다. 시니어 엔지니어 A는 Claude에게 "최근 48시간 동안 FetchCredential 호출 감사 로그를 확인해줘"라고 지시했다. B는 "잘못된 브랜치 체크아웃 흔적을 서버에서 찾아봐"라고 했다. C는 git 히스토리에서 리비전을 추적하게 했다—Claude는 이후 커밋의 파일 이름 변경이 원인이라는 그럴듯하지만 틀린 결론을 자신 있게 내놨고, 팀은 그 방향으로 시간을 낭비했다.
반면 주니어 개발자는 이렇게 말했다. "스테이징이 망가졌어. 가서 봐줘." 그게 전부였다. 도메인 지식이 없으니 어디를 봐야 할지 지정할 수가 없었다. AI는 스스로 탐색 경로를 선택했고, 막힌 지점마다 "더 스마트한 방법이 있을까?"라는 단 한 문장의 요청을 받았다. 그 한 문장이 탐색 축을 완전히 바꿨다. 접근 로그에서 데이터베이스 아티팩트로. 마이그레이션 소스 코드에서 NOW() 타임스탬프를 읽어낸 Claude는 DB에 기록된 실행 시각과 git 커밋 시각의 55초 차이로 범인을 특정했다.
도메인 지식이 오히려 탐색 공간을 좁힌다
이 인시던트가 드러내는 핵심 역설은 이것이다. 전문성이 오히려 AI 협업의 발목을 잡을 수 있다. Harvard/BCG의 'Jagged Frontier' 연구가 경고한 것처럼, AI가 그럴듯하게 틀린 답을 내놓을 때 그것을 믿어버리는 건 오히려 숙련된 사용자다. 가설이 강할수록 AI에게 던지는 질문도 구체화되고, 구체화된 질문은 탐색 공간을 특정 방향으로 잠가버린다. 잘못된 방향으로.
물론 이 이야기를 "모르는 게 낫다"는 식으로 읽으면 안 된다. 글쓴이 스스로도 솔직하게 인정한다—시니어들의 체계적 소거 작업이 없었다면 주니어의 탐색 범위도 줄어들지 않았을 거라고. 교훈은 '무지의 우월함'이 아니라 가설을 고정하는 타이밍의 문제다. 강한 가설 없이 AI에게 목표만 건네고, 막혔을 때 탐색 방향 자체를 의심하게 만드는 질문을 던지는 것—그게 이 멘탈 모델의 핵심이다.
워크플로우에서 AI를 '실행자'로만 쓰는 함정
dev.to의 또 다른 글 "Beyond the Hype"는 개발 사이클 전반에 AI를 통합하는 전략을 단계별로 정리한다. 기획·설계부터 구현, 디버깅, 코드 리뷰까지 AI가 각 단계에서 어떤 역할을 할 수 있는지 실용적으로 보여준다. 여기서도 핵심 원칙은 동일하다. 컨텍스트를 충분히 주되, 방법은 AI가 고르게 하라. 함수 이름 하나를 잘 지어도 Copilot의 코드 생성 품질이 달라지는 이유가 바로 이것이다—AI의 탐색 공간을 열어두되, 목표는 명확하게.
오픈소스 유지보수가 드러낸 AI 협업의 그림자
AI 협업의 빛만 보면 균형이 깨진다. 오픈소스 패키지 여러 개를 유지보수하며 AI를 적극 활용한 개발자의 회고(dev.to, "Maintaining Open Source in the AI Era")는 불편한 질문을 던진다. AI가 생성한 테스트는 존재하는 코드를 커버하지만, 존재해야 할 코드를 드러내지 못한다. 수동으로 테스트를 작성할 때 개발자는 "이 코드가 어떻게 쓰일까"를 강제로 사고하게 된다. AI는 그 사고 과정을 건너뛴다. 커버리지 숫자는 훌륭해 보이지만, 그 숫자가 '사고의 깊이'를 보장하지는 않는다.
오픈소스 PR을 리뷰할 때 "이 변경을 인간이 진짜 고민했을까, AI가 생성하고 사람이 승인만 했을까"라는 의심이 생긴다는 그의 고백은, 단순한 개인의 감상이 아니다. 오픈소스의 신뢰 기반이었던 '누군가의 제한된 시간과 관심의 투자'라는 신호가 희석되는 현상을 정확하게 짚어낸다. AI가 패키지 하나를 이틀 만에 만들 수 있게 되면, 그 패키지가 진지하게 설계되었는지 판단할 새로운 신호가 필요해진다.
지금 당장 바꿀 수 있는 한 가지
세 가지 소스가 공통적으로 가리키는 지점은 결국 하나다. AI에게 방법이 아니라 목표를 건네라. 막혔을 때 더 좁은 질문이 아니라 더 열린 질문을 던져라. "A, B, C는 확인했어. 이 시스템에 어떤 다른 증거가 남아있을까?"가 "X 로그에서 Y를 찾아줘"보다 훨씬 강력한 프롬프트인 경우가 많다.
프론트엔드 개발에서도 이 원칙은 그대로 적용된다. 컴포넌트 버그를 AI와 디버깅할 때 "이 이벤트 핸들러 확인해줘"가 아니라 "이 인터랙션이 예상대로 동작하지 않아, 원인을 찾아줘"라고 건네는 것. 렌더링 이슈를 추적할 때 특정 훅을 지목하기 전에 전체 데이터 흐름을 먼저 설명하는 것. 그게 AI를 단순한 실행자가 아니라 진짜 탐색 파트너로 만드는 방식이다.
AI 협업의 다음 과제: 탐색과 검증을 동시에
앞으로의 과제는 이 두 가지를 동시에 잡는 것이다. 탐색 공간을 열어두는 유연함과, AI의 그럴듯한 오답에 흔들리지 않는 검증 루틴. '빠른 프로토타이핑 → 사용자 검증 → 고도화'의 흐름에서 AI가 진짜 가속 엔진이 되려면, 도구를 어떻게 쓰느냐보다 어떤 질문을 던지느냐가 먼저 설계되어야 한다. 그 설계는 아직 대부분의 팀에게 미완성 상태다.