[잡담] 요즘 내 보고서를 제일 먼저 읽는 건 팀장이 아니다

얼마 전에 문득 든 생각이다. 내가 쓴 문서를 사람보다 AI가 먼저 읽는 경우가 이미 꽤 많지 않나.

예전에는 이랬다. 보고서를 쓰고 올리면 팀장이 읽는다. 그 사람의 경험과 취향이 곧 기준이었고, 빨간 펜이 어디에 그어질지도 대충 예상이 됐다. 몇 번 겪어보면 “이 사람은 숫자 근거를 먼저 본다” 같은 게 감으로 잡혔다.

지금은 어떨까. AI를 잘 쓰는 팀장이라면 그 보고서를 그대로 GPT나 클로드에 넣고 “요약하고 비평해줘”부터 시킬 것이다. 나쁜 일이 아니다. 나라도 그렇게 할 것 같다. 문서 열 개가 쌓여 있는데 하나하나 정독할 시간은 없고, 일단 요약과 지적 사항을 받아두면 훨씬 빠르게 훑을 수 있으니까. 거기에 자기 판단을 얹어서 피드백을 주면 그건 꽤 괜찮은 사용법이다. 물론 바쁘거나 성의가 없으면 받은 걸 거의 그대로 전달할 수도 있겠지만.

보고서를 제일 먼저 읽는 사람이 바뀌었다

내 글을 사람보다 먼저 읽는 게 모델인 경우가 점점 늘고 있다.

크고 작게 다 거친다

이게 보고서만의 이야기는 아니다. 채용 서류도, 코드 리뷰도, 제안서도, 심지어 논문 리뷰도 어딘가에서 한 번은 이 경로를 지난다. 사람이 최종 판단을 하더라도 그 앞에 모델이 한 겹 끼어 있는 구조가 점점 흔해지고 있다.

여기서 좀 이상한 상황이 생긴다. 내 결과물을 평가하는 1차 독자가 사람이 아닌데, 정작 나는 그 1차 독자가 뭘 어떻게 볼지 한 번도 확인해보지 않고 제출한다는 것이다.

그러면 순서를 바꾸면 된다

어차피 누군가 돌려볼 거라면, 내가 먼저 돌려보면 된다. 별거 아닌 이야기 같은데 습관으로 만들어두면 차이가 꽤 크다.

한동안 이걸 의식적으로 해보면서 알게 된 게 하나 있다. 뭘 물어보느냐에 따라 돌아오는 게 완전히 다르다. “이 글 어때?”라고 물으면 백이면 백 칭찬이 돌아온다. 모델은 기본적으로 상대를 기분 좋게 만들려는 방향으로 답하기 때문이다. 그래서 질문을 다르게 던져야 한다.

평가해줘라고 하면 칭찬만 돌아온다

무엇을 물었느냐가 무엇이 돌아오는지를 정한다.

내가 자주 쓰는 건 네 가지다.

요약시키기. 가장 싸고 가장 확실하다. “세 줄로 요약해봐”라고 시켰을 때 내가 의도한 대로 나오지 않으면, 모델이 이해를 못 한 게 아니라 내 글이 잘못 쓰인 것이다. 특히 결론이 엉뚱하게 요약되면 구조에 문제가 있다는 신호다.

반박시키기. “이 주장을 무너뜨려봐”, “반대 입장에서 가장 강한 반론을 써봐” 같은 식이다. 평가를 부탁하면 칭찬이 오지만 공격을 부탁하면 약한 지점이 온다. 개인적으로 가장 효과가 좋았던 질문 형태다.

빠진 것 찾기. “이 글에 없는데 있어야 할 내용은 뭔가?” 있는 걸 고치는 건 혼자서도 하는데, 없는 걸 알아채는 건 혼자서는 어렵다. 빈칸은 눈에 안 보이니까.

기준 주고 채점시키기. 막연히 평가해달라고 하는 대신 체크리스트를 준다. “숫자 근거가 있는가, 대안을 제시했는가, 리스크를 언급했는가” 같은 식으로. 이렇게 하면 결과가 훨씬 일관되고, 여러 문서를 같은 잣대로 볼 수 있다.

한 모델만 믿지 않기

여기서 한 걸음 더 나가면 교차검증이다. 이것도 별로 복잡한 얘기는 아니다. A 모델에서 받은 비평을 B 모델에 다시 넣고 “이 비평이 타당한가, 과한 지적은 없나”를 묻는 것이다.

남이 돌리기 전에 내가 먼저 돌린다

두 모델이 함께 짚은 지적은 대체로 진짜다.

이게 왜 의미가 있냐면, 같은 모델을 여러 번 돌리는 건 생각만큼 도움이 안 되기 때문이다. 모델마다 일정한 버릇이 있어서 몇 번을 돌려도 같은 방향으로 치우친다. 계열이 다른 모델을 쓰면 다른 걸 잡아낸다.

실제로 해보면 재밌는 게, 두 모델이 서로 다른 지적을 하는 경우가 꽤 많다. 그리고 둘 다 짚은 지적은 대체로 진짜 문제다. 반대로 한쪽만 지적한 건 그 모델의 취향인 경우가 섞여 있다. 그래서 요즘은 A가 지적한 걸 B에게 검토시키고, 살아남은 것만 고친다.

도구를 좀 찾아봤다

매번 창을 여러 개 띄우고 복붙하는 게 귀찮아서 좀 찾아봤는데, 오픈소스로 쓸 만한 게 몇 개 있었다.

promptfoo: 같은 입력을 여러 모델에 한 번에 돌려서 결과를 나란히 놓고 보여준다. 원래는 프롬프트 테스트용으로 만들어진 도구인데, YAML에 모델 목록과 통과 기준을 적어두고 돌리면 매트릭스로 결과가 나온다. 같은 문서를 정기적으로 여러 모델에 검토시킬 일이 있다면 이게 제일 편하다.

LibreChat: MIT 라이선스 셀프호스팅 챗 UI다. 여러 제공자를 한 화면에서 쓰고 대화 중간에 모델을 갈아탈 수 있어서, 같은 질문을 GPT와 클로드에 번갈아 던지는 식의 작업이 편하다. 비슷한 걸로 Open WebUI도 있다.

karpathy/llm-council: 이건 좀 재밌다. 카파시가 만든 작은 웹앱인데, 질문을 여러 모델에 동시에 보내고 → 모델들이 서로의 답을 익명으로 비평하고 순위를 매기고 → 마지막에 의장 역할을 맡은 모델이 종합해서 최종 답을 낸다. 위에서 말한 교차검증을 자동화한 물건이라고 보면 된다. 익명으로 서로 평가하게 한다는 부분이 특히 좋은데, 모델이 자기 계열 출력을 편드는 성향을 어느 정도 눌러주기 때문이다.

개인적인 견해

이 방식이 만능은 아니라서 몇 가지 짚어두고 싶다.

첫째, 아는 만큼만 물을 수 있다. 좋은 질문을 던지려면 뭐가 중요한지를 이미 알고 있어야 하고, 돌아온 피드백이 맞는 말인지도 판단할 수 있어야 한다. 도메인을 모르면 그럴듯한 지적에 그대로 끌려간다. 결국 이해가 있어야 도구도 쓸모가 있다는 얘긴데, 이건 좀 재미없는 결론이지만 사실인 것 같다.

둘째, 채점하는 모델도 편향이 있다. 먼저 보여준 걸 더 좋아하고, 긴 글에 후한 점수를 주고, 자기와 같은 계열이 쓴 글을 편든다. 이건 지난 글에서 정리했는데, 여러 번 돌려 평균 낸다고 사라지는 종류가 아니라 한쪽으로 쏠린 버릇이다. 교차검증을 권하는 이유도 여기에 있다.

셋째, 이게 제일 신경 쓰이는 부분인데, AI 통과가 목표가 되면 곤란하다. 모델이 좋아하는 글의 특징이 분명히 있다. 구조가 명확하고, 소제목이 잘 달려 있고, 숫자가 적당히 있는 글. 그런데 그걸 맞추는 데 최적화하기 시작하면 읽는 사람에게는 밋밋한 글이 나온다. 지표를 목표로 삼는 순간 지표가 망가진다는 오래된 이야기가 여기서도 반복된다. AI 검증은 실수를 걸러내는 용도지 잘 썼는지를 판정하는 용도는 아니라고 생각한다.

그리고 이 모든 게 아마 과도기의 풍경일 것이다. 몇 년 뒤에는 이런 검증이 문서 도구에 기본으로 들어가 있어서 이렇게 따로 이야기할 필요도 없어질 것 같다. 다만 지금은 이걸 습관으로 만든 사람과 아닌 사람의 결과물 차이가 눈에 띄게 벌어지는 시기라서, 한동안은 의식적으로 해볼 만하다고 생각한다.

함께 보면 좋은 글:

본 글은 2026년 7월 29일 기준으로 작성했다. 언급한 도구들의 기능은 이후 바뀔 수 있다.