나는 개발자가 아니지만, 설명 없이 고치게 두지는 않았다

1월 28일, 프론트엔드 개발자에게서 AI 처리 오류가 전달됐다.

우리가 만들던 서비스는 PDF에 담긴 정보를 읽어 필요한 형태로 바꾸는 작업을 한다. 프론트엔드는 별도의 개발자가 맡고 있었고, 나는 AI를 이용해 백엔드를 구현하고 있었다. 나는 개발자가 아니다. 그렇다고 백엔드에서 무슨 일이 벌어지는지 이해하지 않은 채 진행하고 싶지도 않았다.

개발자가 보내온 것은 화면에서 보이는 오류와 서버 기록이었다. 긴 주소 끝에 404 Not Found가 붙어 있었고, 그 주소에는 templates/[object Object]라는 이상한 문자열이 들어 있었다.

나는 그 기록을 Codex에 전달하면서 현재 백엔드 코드를 확인하고 근본적인 문제를 찾아달라고 했다. 다만 확인이 끝났다고 곧바로 수정하는 것은 원하지 않았다.

“코드는 고치지 말고 일단 나에게 상세한 설명을 해주기 바랍니다. 그다음 나의 지시사항을 기다립니다.”

내가 알아야 할 것은 단순히 어느 줄이 틀렸느냐가 아니었다. 왜 오류가 생겼는지, 프론트엔드 개발자가 보내온 기록과 실제 백엔드 코드가 어떻게 연결되는지였다.

AI의 설명에 따르면, 서버는 AI가 사용할 템플릿의 이름을 전달해야 하는 자리에 다른 형태의 값을 넣고 있었다. 쉽게 말하면 목적지 이름을 제대로 적었는데, 주소를 만드는 단계에서 그 이름 대신 엉뚱한 문구가 들어간 셈이었다. 그래서 서버가 존재하지 않는 주소를 찾아갔고, 결과는 404 오류로 돌아왔다.

그 설명만 듣고 끝내지는 않았다.

프론트엔드 개발자가 다시 보내온 기록에는 요청이 어느 단계까지 진행됐는지가 표시돼 있었다. 템플릿 이름은 처음부터 여러 단계를 지나는 동안 정상적인 문자열로 남아 있었다. 그런데 AI를 호출하는 순간 실패했다.

나는 그 기록을 다시 보여주며 물었다.

“당신이 얘기한 것이 맞는 것 같나요? 다시 한번 확인하기 바랍니다.”

AI는 앞서 설명한 문제와 기록이 맞아떨어진다고 답했다. 다만 최종 판단에는 실제 오류 메시지가 더 필요하다고 했다. 그래서 개발자에게서 받은 오류 전문까지 다시 전달했다. 거기에도 같은 비정상적인 주소가 남아 있었다.

그제야 수정 방법을 물었다. 하지만 이번에도 먼저 요청한 것은 코드가 아니었다.

“그럼 수정을 어떻게 해야 하는지 계획을 제시해주기 바랍니다. 그 이후 다음 지시사항을 기다립니다. 그리고 그렇게 수정되면 어떻게 되는 것인지도 설명을 잘 해줘야 합니다.”

AI가 내놓은 계획은 비교적 분명했다. 템플릿의 이름을 전달하는 위치를 바꾸고, 기존 입력 자료의 형태는 유지한다. 그렇게 바꾼 다음에는 잘못된 주소가 사라지는지 확인한다는 내용이었다.

나는 그 계획을 보고 직접 코드를 수정했다. 그리고 AI에게 다시 검수를 요청했다.

처음에는 AI가 수정된 코드를 보여달라고 했다. 나는 이미 프로젝트 파일을 볼 수 있는 권한이 있지 않느냐고 되물었다. 그 뒤 AI는 파일을 확인했고, 변경 내용이 앞서 설명한 방향과 일치한다고 답했다.

여기까지가 한 번의 작업이었다.

그런데 수정한 함수를 배포하고 나니 다른 문제가 나왔다. 이번에는 처리 시간이 지나치게 길어졌다는 신호와 함께 브라우저에 접근 차단 메시지가 표시됐다. 한 가지 오류를 고쳤다고 서비스 전체가 정상 동작하는 것은 아니었다.

나는 다시 원인부터 파악해 달라고 했다. 화면에 나온 접근 차단 메시지가 진짜 원인인지, 아니면 서버가 제시간에 응답하지 못해 뒤따라 나타난 현상인지 구분해야 했다. AI는 서버 응답 지연 가능성을 설명했고, 나는 그 판단이 맞는지 다시 질문했다. 수정 방법을 묻는 순간에도 코드를 먼저 고치지 말고 설명부터 해달라고 했다.

이 과정에서 내가 맡은 역할이 조금 더 분명해졌다.

프론트엔드 개발자는 자신이 겪은 오류를 전달한다. AI는 백엔드 코드를 살펴보고 원인과 대안을 제시한다. 그리고 나는 그 사이에서 문제를 이해하고, 어떤 수정이 필요한지 결정한 뒤, 실제 변경이 계획과 일치하는지 확인한다.

내가 코드의 모든 문법을 알고 있다는 뜻은 아니다. 대신 무엇을 고치려는지 모르는 상태로 다음 단계에 넘어가지 않으려고 했다.

AI는 빠르게 수정안을 만들 수 있다. 오류 메시지만 보여줘도 곧바로 코드를 바꿀 수 있다고 답한다. 그러나 설명을 생략하고 수정부터 반복하면, 문제가 해결됐을 때도 왜 해결됐는지 모르고, 새로운 오류가 나타났을 때는 어디서부터 다시 확인해야 할지 막막해진다.

이번 작업에서 내가 반복한 요청은 복잡하지 않았다.

지금은 고치지 말 것. 먼저 원인을 설명할 것. 수정 계획과 예상되는 변화를 알려줄 것. 내가 수정한 다음에는 그 계획대로 되었는지 검수할 것.

개발 지식이 부족한 상황에서 내가 작업을 관리하는 방법이었다.

그리고 오류는 한 번에 끝나지 않았다. 주소를 잘못 만드는 문제를 바로잡은 다음에는 처리 시간과 응답 문제를 다시 살펴봐야 했다. 지금은 그다음 원인을 확인하고 어떤 범위로 수정할지 결정할 차례다.

내가 원하는 것은 AI가 대신 다 고쳐주는 장면이 아니다. 무엇을 바꾸는지 이해한 상태에서, 내가 다음 일을 결정할 수 있는 작업 방식이다.

그날의 성장 노트

남은 생각 · 처음 오류를 수정한 뒤에도 새로운 문제가 나타났다. 화면에 보이는 메시지와 실제 원인이 같은지, 서버와 프론트엔드 가운데 어느 쪽을 먼저 확인해야 하는지 계속 구분할 필요가 있다.

그때의 기준 · 오류가 나도 바로 수정하지 않는다. 먼저 원인과 근거를 확인하고, 수정 계획과 예상되는 변화를 설명받는다. 실제 변경 후에는 계획과 일치하는지 검수한다.