매끈한 답변을 읽고 나면 이해한 것 같은 기분이 든다. 선택지가 정리되어 있고 장단점도 균형 잡혀 있다. 그대로 보내도 대화가 이어질 것 같다. 그런데 상대가 왜 그 선택을 하느냐고 물으면 다시 답변 창으로 돌아가야 한다. 문장을 전달한 사람과 판단한 사람이 갈라지는 순간이다.
Adam이 쓴 Don’t Be a Proxy Between Me and Your AI는 이런 기술 대화의 문제를 다룬다. 2026년 10월 22일에 올라온 의견 글이며, 저자의 개인적 불만과 경험을 모든 팀의 현실로 일반화할 수는 없다. 다만 답변을 보내는 사람이 어떤 판단을 더했는지 묻는 질문은 남는다. 이를 가상의 코드 검토 대화에 옮겨보려 한다.
말투보다 빠진 근거를 찾기
가상의 변경은 파일 업로드 크기 제한을 조정하는 작업이다. 동료가 제한을 늘려도 되는지 묻자, AI가 사용자 편의와 서버 부담을 설명하고 제한을 높이는 방향을 권했다고 하자. 답변 자체가 자연스러워도 현재 서버 설정과 실제 사용량을 확인했다는 뜻은 아니다. 일반적인 설명과 지금 이 변경에 대한 근거 사이에 빈칸이 있다.
그 빈칸을 채우기 전에 동의한다고 보내면 다음 질문이 어려워진다. 왜 그 크기인가. 기존 클라이언트에서도 같은 제한을 사용하는가. 요청이 중간에 끊기면 임시 파일은 어떻게 되는가. 답변에 이런 단어가 들어 있었다는 사실과, 현재 코드에서 확인했다는 사실은 다르다. 검토하는 사람의 역할은 그 차이를 알아보고 표시하는 데 있다.
처음 답변은 짧아도 된다. 현재 API의 크기 검사는 확인했지만 앞단의 요청 제한은 아직 보지 못했다, 그래서 지금은 확대에 동의하기 어렵다고 쓸 수 있다. 여기에는 화려한 장단점 목록이 없다. 대신 어디까지 알고 무엇 때문에 결정을 미뤘는지 보인다. 상대는 같은 설명을 다시 듣는 대신 필요한 확인을 이어갈 수 있다.
물론 이 예시는 실제 서비스의 검토 결과가 아니다. 어떤 팀의 설정을 읽거나 실제 업로드를 수행하지 않았다. 설명을 위해 만든 대화다. 실제 답변에 옮길 때에는 확인한 파일과 시각, 실행한 검사 범위를 실제 근거로 채워야 한다. 가상의 확인 문장을 복사해서 이미 조사한 것처럼 보내면 같은 문제가 반복된다.
확인한 것과 모르는 것을 붙여 쓰기
답변 초안을 읽으며 두 가지 표시를 해볼 수 있다. 내가 직접 근거를 찾은 문장과 아직 확인하지 않은 문장이다. 문서에서 읽은 주장이라면 문서의 범위도 붙인다. 현재 코드의 동작인지, 예전 설계의 의도인지, 도구가 일반적으로 제안한 방법인지 구분하면 된다. 모두 같은 강도로 확신할 필요는 없다.
모른다는 문장을 넣는 것이 대화를 약하게 만들지는 않는다. 앞단 설정을 확인하지 못했다고 말하면 누가 그 부분을 볼지 정할 수 있다. 반대로 아무 빈칸도 없는 답변은 논의를 끝낸 것처럼 보이지만, 나중에 문제가 생기면 무엇을 전제로 결정했는지 찾기 어렵다. 모르는 범위가 보이는 답변이 더 많은 일을 할 수 있다.
AI를 썼다는 사실도 문장 다듬기와 판단의 근거를 나눠 설명할 수 있다. 표현을 정리하는 데 도움을 받았고, 결론은 어떤 현재 제약 때문에 골랐다고 적는 방식이다. AI의 의견과 반드시 반대해야 자기 판단이 되는 것은 아니다. 동의했더라도 왜 지금 상황에 맞는지 설명할 근거가 있으면 된다.
언어가 익숙하지 않거나 생각을 정리하는 데 시간이 필요한 사람에게 도움 도구는 유용할 수 있다. 그 사용 자체를 성실함의 반대로 놓을 이유는 없다. 중요한 것은 전달한 답변의 의미를 이해하고, 질문이 돌아왔을 때 확인한 범위 안에서 대화할 수 있는지다. 문법의 자연스러움과 판단의 책임을 같은 기준으로 재단하지 않는 편이 좋다.
보내기 전에 작은 결정을 남기기
가상의 업로드 제한 검토라면 최종 답변에 결정과 다음 확인을 함께 넣어볼 수 있다. 지금은 기존 제한을 유지한다. 앞단 제한과 임시 파일 정리를 확인한 뒤 확대 범위를 다시 정한다. 확인 담당과 검토 시점을 실제로 합의했다면 그 정보도 적는다. 정해지지 않은 담당이나 시간을 그럴듯하게 만들어 넣지는 않는다.
대화가 길어졌을 때에는 마지막 문장만 남기지 않는 것이 좋다. 어떤 조건 때문에 선택이 바뀌었는지 짧게 기록하면 다음 사람이 같은 질문을 반복하지 않을 수 있다. 처음에는 사용자 편의를 생각했지만 기존 설정과 충돌해 보류했다는 식이다. 이때도 실제로 확인된 충돌과 아직 예상하는 위험을 구분해야 한다.
답변을 준비할 시간이 없다면 당장 결론을 내리지 않는 선택도 있다. 지금은 검토할 수 없으니 언제 돌아올 수 있는지 알려주거나, 다른 담당이 먼저 확인할 범위를 제안할 수 있다. 대화에 참여했다는 표시를 남기려고 검토하지 않은 결론을 보내는 것보다, 가능한 기여의 크기를 솔직하게 말하는 편이 다음 행동을 정하기 쉽다.
이 방법이 팀의 성과를 높였다는 수치는 여기 없다. 대신 답변 하나를 읽는 사람이 무엇을 믿어도 되는지는 정할 수 있다. 보낸 사람이 직접 확인한 것, 아직 모르는 것, 현재 내린 결정, 다음에 볼 조건이 그 범위다. 기술 토론에서 사람의 몫이 어디에 남아 있는지 조금 더 분명하게 만드는 문장들이다.
AI가 초안을 잘 정리해줄수록 보내기 전의 질문은 작아져도 날카로워질 수 있다. 이 답변에서 내가 근거를 대며 책임질 수 있는 한 문장은 무엇인가. 없다면 아직 답변을 고치는 일이 남아 있다. 문장을 더 자연스럽게 만드는 대신 그 한 문장을 찾는 데 시간을 써보면, 다음 질문을 받았을 때의 대화가 달라질지도 모른다.
관련 글은 IT업계에 관한 생각에서 이어 읽을 수 있습니다.
공개 원문을 참고해 AI의 도움으로 구성·작성한 글입니다. 본문의 가상 예시는 실제 수행 결과와 구분했으며, 표지는 Google Gemini로 만든 개념 일러스트입니다.
