AI 대화 50줄을 그대로 보고하지 마세요: 팀을 움직이는 5문장 보고법

오후 2시 17분, 결제 화면에서 간헐적인 오류가 발생했습니다.

주니어 개발자 민수는 AI와 30분 동안 로그를 분석했습니다. 가능한 원인도 네 개나 찾았고, 관련 코드와 지표도 꼼꼼히 모았습니다. 그는 팀 채널에 AI 대화 내용을 거의 그대로 붙여 넣었습니다.

긴 메시지를 읽은 팀 리더가 답했습니다.

그래서 지금 실제로 확인된 건 무엇이고, 내가 결정해야 할 건 무엇인가요?

민수는 많은 정보를 전달했지만 팀이 다음 행동을 선택하는 데 필요한 구조는 전달하지 못했습니다.

AI를 쓰면 조사 기록은 빠르게 길어집니다. 로그 요약, 원인 후보, 코드 설명, 수정안이 몇 분 만에 쌓입니다. 문제는 정보가 부족해서가 아니라 사실·추측·판단 요청이 한 덩어리로 섞이는 것입니다.

시니어나 팀 리더에게 필요한 것은 AI가 얼마나 많이 분석했는지가 아닙니다. 지금 무엇이 사실이고, 무엇이 아직 가설이며, 어떤 결정을 내려야 하는지입니다.

이때 사용할 수 있는 가장 짧은 형식이 관찰 → 가설 → 증거 → 위험 → 요청의 다섯 문장입니다.

1문장. 관찰: 해석하지 말고 실제로 일어난 일을 적기

관찰은 원인이 아니라 확인된 현상입니다.

• 나쁜 문장: 데이터베이스가 느려서 결제가 실패하고 있습니다.
• 좋은 문장: 오늘 14:00~14:15 사이 결제 요청의 8.2%가 5초를 넘겼고, 그중 31건이 타임아웃으로 종료됐습니다.

첫 문장에 원인을 섞으면 이후 대화가 그 가정에 끌려갑니다. 시간 범위, 영향받은 기능, 사용자 범위, 오류 수처럼 다시 확인할 수 있는 사실만 적습니다.

관찰을 쓸 때는 다음 질문을 확인합니다.

1. 언제부터 언제까지인가?
2. 어떤 사용자 행동에서 발생했는가?
3. 정상 상태와 무엇이 다른가?
4. 수치나 원문 로그로 다시 확인할 수 있는가?

2문장. 가설: 가장 가능성 높은 원인을 하나만 말하기

가설은 결론이 아니라 현재 증거로 가장 먼저 확인할 설명입니다.

결제 API 자체보다, 배포 뒤 증가한 주문 조회 쿼리가 커넥션 풀을 오래 점유하는 것이 1순위 원인으로 보입니다.

“원인은 데이터베이스입니다”처럼 단정하지 않습니다. 보입니다, 가능성이 높습니다, 먼저 확인하겠습니다 같은 표현은 자신감 부족이 아니라 불확실성의 정확한 표시입니다.

원인 후보가 여러 개라면 보고문에 전부 늘어놓기 전에 우선순위를 정합니다. 같은 수준의 증거를 가진 가설이 둘 이상이라면 그것 자체가 중요한 위험입니다.

3문장. 증거: 가설을 지지하는 것과 반박하는 것을 함께 적기

증거는 “AI도 그렇게 말했습니다”가 아닙니다. 로그, 테스트, 지표, 코드, 변경 이력처럼 다른 사람이 다시 확인할 수 있어야 합니다.

애플리케이션 CPU는 평소 수준이지만 DB 활성 연결이 40개 한도에 도달했고, 타임아웃 직전 로그에서 새 주문 조회 쿼리가 평균 4.8초 걸렸습니다. 다만 복제 환경에서는 아직 같은 지연을 재현하지 못했습니다.

마지막 문장이 중요합니다. 내 가설에 유리한 자료만 고르면 보고가 아니라 설득이 됩니다. 반박 증거나 재현 실패를 함께 적어야 리더가 확신의 크기를 제대로 판단할 수 있습니다.

4문장. 위험: 틀렸을 때의 영향과 아직 모르는 것을 밝히기

위험은 막연한 불안 목록이 아닙니다. 현재 판단이 틀렸을 때 생길 피해와 확인하지 못한 범위를 연결합니다.

쿼리만 원인이라고 보고 즉시 롤백하면 같은 스키마를 사용하는 배송 작업이 중단될 수 있으며, 현재 해외 결제 트래픽에 미친 영향은 확인하지 못했습니다.

다음 항목을 짧게 확인합니다.

• 고객·매출·데이터에 미치는 영향
• 보안이나 권한 문제로 확대될 가능성
• 지금 제안한 행동의 부작용
• 롤백 가능 여부와 복구 시간
• 관측하지 못한 사용자·환경·시간대

위험 문장이 있어야 팀은 “빨리 고칠 것인가”뿐 아니라 “어디까지 확인하고 움직일 것인가”를 결정할 수 있습니다.

5문장. 요청: 상대방이 결정할 수 있는 선택지를 제시하기

“확인 부탁드립니다”는 요청처럼 보이지만 상대가 무엇을 해야 하는지 모호합니다.

좋은 요청은 필요한 판단, 권한, 정보와 시간을 구체적으로 적습니다.

읽기 전용 복제본에서 실행 계획을 15분 더 확인한 뒤, 문제가 재현되면 최근 배포의 주문 조회 변경만 되돌리는 안을 승인해 주세요.

요청에는 가능하면 네 가지가 들어갑니다.

1. 누구의 결정이 필요한가?
2. 무엇을 승인하거나 제공해야 하는가?
3. 언제까지 필요한가?
4. 승인 전에는 어디까지 안전하게 진행할 수 있는가?

요청이 없는 보고는 문제를 상대에게 넘기는 메시지가 되기 쉽습니다. 요청까지 써야 보고가 다음 행동으로 이어집니다.

긴 AI 분석을 다섯 문장으로 바꾸면

민수의 50줄짜리 분석은 다음처럼 바뀔 수 있습니다.

역할다섯 문장 보고

관찰	오늘 14:00~14:15 결제 요청의 8.2%가 5초를 넘겼고 31건이 타임아웃으로 끝났습니다.
가설	배포 뒤 추가된 주문 조회 쿼리가 DB 연결을 오래 점유하는 것이 1순위 원인으로 보입니다.
증거	앱 CPU는 정상이지만 DB 연결 40개가 모두 사용됐고 해당 쿼리 평균 시간이 4.8초였습니다. 다만 복제 환경에서는 아직 재현하지 못했습니다.
위험	즉시 전체 롤백하면 배송 작업도 중단될 수 있고 해외 결제 영향은 아직 확인하지 못했습니다.
요청	복제본에서 15분 더 확인한 뒤 재현되면 주문 조회 변경만 롤백하도록 승인해 주세요.

이 형식은 모든 세부사항을 버리라는 뜻이 아닙니다. 다섯 문장은 의사결정용 요약이고, 원본 로그·그래프·테스트 결과는 링크나 부록으로 붙입니다.

보고가 약해지는 네 가지 패턴

1. AI 대화 기록을 그대로 전달한다

생각의 과정과 결론이 섞여 핵심을 다시 찾아야 합니다. AI 대화는 조사 노트로 남기고 보고문은 사람이 다시 작성합니다.

2. 가설을 관찰처럼 단정한다

“DB가 원인입니다”보다 “DB 연결 한도 도달이 관찰됐고 새 쿼리가 원인일 가능성이 높습니다”가 정확합니다.

3. 성공한 증거만 적는다

재현 실패, 반례, 확인하지 못한 범위가 빠지면 확신이 실제보다 커 보입니다.

4. 마지막이 ‘어떻게 할까요?’로 끝난다

조사한 사람이 안전한 다음 행동과 선택지를 제안해야 결정권자가 빠르게 판단할 수 있습니다.

AI에게 보고 초안을 맡길 때 쓰는 프롬프트

아래에는 로그, 코드 메모, AI와 나눈 조사 기록이 섞여 있다. 새로운 사실을 만들지 말고 팀 리더가 판단할 수 있는 다섯 문장으로 압축해 줘.

1. 관찰: 시간·영향 범위·수치가 있는 확인된 사실
2. 가설: 가장 가능성 높은 원인 하나와 확신 수준
3. 증거: 지지 증거와 반박 증거 또는 재현 실패
4. 위험: 판단이 틀렸을 때의 영향과 아직 모르는 범위
5. 요청: 필요한 판단·권한·정보·기한
   사실과 추측을 섞지 말고, 근거가 없는 내용은 ‘미확인’으로 표시해 줘. 마지막에는 원문에서 각 문장을 뒷받침한 위치를 적어 줘.

AI가 만든 보고문도 그대로 보내지 않습니다. 수치와 시간 범위를 원본에서 확인하고, 가설을 사실처럼 바꾸지 않았는지, 요청이 실제 권한 구조와 맞는지 검토합니다.

오늘 바로 해 보는 10분 연습

최근 팀에 공유했던 긴 메시지 하나를 고릅니다.

1. 실제로 확인된 문장에만 밑줄을 긋습니다.
2. 가장 가능성 높은 원인을 한 문장으로 줄입니다.
3. 가설을 지지하는 증거와 반박하는 증거를 하나씩 찾습니다.
4. 판단이 틀렸을 때 가장 큰 피해를 적습니다.
5. 상대방이 지금 내려야 할 결정을 요청 문장으로 씁니다.

완성된 다섯 문장을 소리 내어 읽어 보세요. 한 문장 안에 관찰과 가설이 섞이거나, 요청을 읽고도 다음 행동이 떠오르지 않는다면 다시 나눕니다.

좋은 보고는 아는 것을 과시하는 문서가 아닙니다. 확인된 사실과 불확실성을 정직하게 분리하고, 팀이 더 안전하고 빠르게 결정하도록 만드는 인터페이스입니다.

다음 글에서는 새 패키지와 AI 생성 코드가 들어왔을 때 출처·라이선스·대체 가능성을 개발 요구사항으로 확인하는 방법을 다루겠습니다.

이번 글의 한 문장
긴 AI 분석은 관찰·가설·증거·위험·요청의 다섯 문장으로 압축할 때 비로소 팀의 다음 행동으로 이어진다.