• AI 코딩 에이전트(AI Coding Agent)를 사용하기 시작한 사람
• "원인을 조사해줘"라고 던졌을 때, 조금 수상한 답변이 돌아온 적이 있는 사람
• 로그 조사를 AI에게 도움받고 싶은 사람

이 이야기는 AI 코딩 에이전트에게 결함 조사나 로그 조사를 도와달라고 요청하는 사람을 상정하고 있습니다. 조사 범위나 출력 형식을 잘 전달하고 싶은 개발 담당자를 위한 내용입니다.

최근 AI 코딩 에이전트에게 조사를 도와달라고 하는 상황이 늘어나고 있습니다. 코드를 가로질러 읽거나, 로그에서 수상한 부분을 정리하는 데 편리합니다. 반면, 무엇을 봐도 되는지 전달하지 않은 채 의뢰하면 기대와 다른 방향으로 진행될 수도 있습니다.

예를 들어, 예약이 반영되지 않는다, 알림이 오지 않는다, 관리 화면의 숫자가 맞지 않는다와 같은 상담을 받았다고 가정해 봅시다. 급하다 보면 저도 모르게 "원인을 조사해줘"라고 던지고 싶어지죠. 하지만 AI 입장에서는 어떤 로그를 봐도 되는지, 어디까지 코드를 건드려도 되는지 알 수 없는 상태입니다.

업무 조사에서는 건드려도 되는 범위, 봐도 되는 로그, 수정해도 되는지 여부를 처음에 맞춰둘 필요가 있습니다. 이는 사람에게 부탁할 때나 AI에게 부탁할 때나 마찬가지입니다. 이 기사에서는 AI에게 통째로 맡기지 않고, 조사의 초안을 작성하게 만들기 위한 의뢰문을 생각해 봅니다.

결함 조사에서는 로그를 찾고, 관련 있어 보이는 코드를 읽고, 시계열을 정리하고, 추가로 확인할 사항을 나열하는 등의 작업이 있습니다.

익숙한 사람이라면 자연스럽게 할 수 있지만, 익숙하지 않을 때는 "어디서부터 보면 좋을까" 단계에서 멈추기 쉽습니다. AI 코딩 에이전트는 이러한 조사의 입구를 함께 정리해 주는 파트너로서 사용할 수 있습니다.

단, AI는 사정을 멋대로 알고 있는 것이 아닙니다. 대충 "원인을 조사해줘"라고만 전달하면, 봐도 되는 범위도, 해도 되는 작업도, 내놓아야 할 상세도(Granularity)도 모르는 채 움직이게 됩니다.

선배에게 조사를 부탁할 때도 "대상 사용자는 이 사람입니다", "이 시간대입니다", "아직 수정은 하지 말아 주세요"라고 전달하죠. AI에게도 마찬가지로 전제 조건과 제약 사항을 전달해야 합니다.

이 기사에서는 AI에게 정답을 통째로 맡기는 방법이 아니라, 조사 메모의 초안을 작성하게 만들기 위한 요청 방법을 생각합니다.

AI 툴은 다양하지만, 이 기사에서는 Codex의 Prompting 등 코딩 에이전트 전반에 사용할 수 있는 사고방식으로서 작성합니다. 특정 툴의 마법 주문이 아니라, 선배나 동료에게 조사를 부탁할 때와 마찬가지로 전제를 맞추는 것이 중요합니다.

예약 동기화가 반영되지 않는 것 같다. 원인을 조사해줘.

이것만으로는 AI가 무엇을 봐도 되는지 알 수 없습니다.

로그를 봐도 되는지, 코드를 건드려도 되는지, 추측만으로 답해도 되는지도 모호합니다.

가상의 문의 조사를 도와주세요.
현상:
- 사용자로부터 "예약 동기화가 반영되지 않는다"라는 문의가 있었습니다.
...

프롬프트에는 다음 항목을 넣으면 조사가 진행되기 쉬워집니다.

항목	예
현상	무엇이 일어나고 있는가
...

AI가 그럴듯한 원인을 말하더라도 바로 믿지 않는 것이 좋습니다.

특히 다음을 확인합니다.

• 로그에 실제로 적혀 있는 사실인가
• 코드상의 근거가 있는가
• 추측을 단정 짓고 있지는 않은가
• 재현 조건이 설명되어 있는가
• 다음에 인간이 확인할 수 있는 형태인가

AI는 조사의 파트너로서는 편리하지만, 최종 판단은 인간이 로그나 코드로 확인(Back-up)해야 합니다.

AI가 만든 조사 메모는 편리하지만, 그대로 결론으로 취급하는 것은 위험합니다.

특히 문의 대응 중에 깔끔한 문장이 나오면 조금 안심하게 되죠. 하지만 업무에서는 "그럴듯한 설명"보다 "로그로 확인된 사실"과 "아직 추측인 것"을 나누는 것이 훨씬 중요합니다.

AI가 작성한 것을 볼 때는 다음 관점에서 확인합니다.

관점	확인 내용
사실	로그나 코드에 정말 적혀 있는가
...

이는 코드 리뷰(Code Review)와 조금 닮았습니다.

코드 리뷰에서는 "작동할 것 같다"뿐만 아니라, 의도한 사양을 충족하는지, 불필요한 부작용(Side Effect)이 없는지를 봅니다. AI의 조사 메모도 마찬가지로, 문장이 자연스러운지보다 근거로 돌아갈 수 있는지를 봅니다.

AI의 조사 메모에서 무서운 것은 문장으로서 자연스러운데 근거가 희박한 경우입니다.

원인은 외부 API의 타임아웃(Timeout)입니다.

이것만으로는 어떤 로그를 보고 그렇게 말하는 것인지 알 수 없습니다. 실제로는 타임아웃 로그가 1건 나왔을 뿐이고, 사용자 영향의 원인이라고는 아직 말할 수 없을지도 모릅니다.

리뷰할 때는 다음과 같이 수정할 수 있는지 확인하는 것이 안전합니다.

사실:
- requestId=req_001 에서 EXTERNAL_API_TIMEOUT 발생
아직 알 수 없는 것:
...

"원인입니다"가 아니라, "원인일 가능성이 있습니다", "다음에 이곳을 확인하겠습니다"라고 작성할 수 있는지가 중요합니다.

AI에게 조사를 도와달라고 할 때는, 처음부터 공유하기 쉬운 형태로 출력하도록 하는 것을 추천합니다.

사실:
- requestId=req_001 에서 외부 API 타임아웃 (EXTERNAL_API_TIMEOUT) 발생
추측:
...

이런 형태라면, 사람이 로그를 다시 검토할 때나 팀에 공유할 때도 다루기 쉽습니다.

AI 코딩 에이전트 (AI Coding Agent)에게 조사를 요청할 때는, "무엇을 해주길 바라는지"뿐만 아니라 "무엇을 해서는 안 되는지"도 함께 적어야 안정적입니다.

로그 조사에서는 사실과 추측을 분리하여 출력하게 하고, 사람이 근거를 확인한 뒤에 사용한다. 이것만으로도 AI를 훨씬 안전하게 사용할 수 있게 됩니다.