AI에게 구현을 맡긴 뒤에도 남는 일

AI가 작업을 마쳤다고 한다. 코드를 수정했고 테스트도 통과했다고 한다. 무엇을 바꿨는지 설명까지 붙어 있으니 이제 PR을 올려도 될 것 같다.

그런데 변경 내용을 읽다 보면 잠깐 멈추는 곳이 있다. 이 파일은 왜 바꿨을까. 이 함수까지 새로 필요했을까. 설명을 읽을 때는 이해한 것 같았는데 막상 누군가에게 설명하려고 하면 코드를 다시 열게 된다.

Terrible Software의 「The Brain Sandwich」는 이런 상황에서 떠올려볼 만한 작업 방식을 소개한다. 먼저 사람이 문제를 이해하고 그다음 AI에게 구현을 맡기고 마지막에 사람이 다시 결과를 살펴본다. 사람의 생각 사이에 AI의 작업이 들어가는 셈이다.

단순한 제안이다. 다만 구현이 빠르게 끝날수록 마지막에 내가 해야 할 일을 가볍게 여기기 쉬울 것 같다. 결과가 나왔으니 확인도 금방 끝날 거라고 기대하게 되기 때문이다.

가령 설정 화면에서 조회에 실패했을 때 다시 시도할 수 있게 해달라는 요청을 받았다고 하자. 설명을 위한 가상 예시다.

AI에게 그대로 요청하면 재시도 버튼을 추가할 수도 있고 실패한 요청을 자동으로 반복하게 만들 수도 있다. 여러 화면에서 쓸 수 있도록 공통 요청 코드를 바꿀 수도 있다. 모두 ‘다시 시도할 수 있게 해달라’는 말에서 나올 수 있는 구현이다.

하지만 이 화면에 필요한 것이 무엇인지는 조금 더 살펴봐야 한다. 이미 요청을 자동으로 재시도하고 있을 수도 있다. 인증이 만료됐을 때는 다시 요청하는 대신 로그인 화면으로 보내야 할 수도 있다. 사용자가 겪는 문제가 실패한 뒤 아무것도 할 수 없다는 것이라면, 기존 조회를 다시 실행하는 버튼 하나로 충분할 수 있다.

이 정도를 알고 맡기면 요청도 달라진다.

“설정 조회가 최종적으로 실패하면 재시도 버튼을 보여주자. 버튼을 누르면 기존 조회를 다시 실행하고, 자동 재시도와 인증 오류 처리는 그대로 두자.”

구현 방법을 전부 정한 것은 아니다. 그래도 결과를 받았을 때 무엇을 봐야 하는지는 알 수 있다. 공통 요청 코드까지 바뀌었다면 그 이유를 물어볼 수 있고 자동 재시도가 추가됐다면 원래 필요했던 동작인지 다시 생각해볼 수 있다.

나는 이 기준을 먼저 갖는 것이 도움이 된다고 생각한다. 완성된 코드를 처음 보고 나서 판단하려면, 이미 만들어진 구조를 따라 이해하게 되기 쉽다. 설명이 그럴듯하면 원래 그 정도 작업이 필요했던 것처럼 느껴질 수도 있다. 내가 해결하려던 문제가 무엇이었는지 짧게라도 적어두면 돌아가서 비교할 곳이 생긴다.

구현이 끝난 뒤에는 그 설명대로 동작하는지 확인해야 한다.

재시도 버튼이 보이는 것까지는 쉽게 확인할 수 있다. 그런데 버튼을 누르면 요청이 실제로 다시 나가는지, 이번에는 성공했을 때 오류 화면이 사라지는지도 봐야 한다. AI가 테스트를 통과했다고 알려줬다면 어떤 테스트였는지도 읽어봐야 한다. 클릭했을 때 함수가 호출되는 것만 확인했을 수도 있기 때문이다.

여기서 생각보다 시간이 걸린다. AI는 몇 분 만에 작업을 끝냈는데 코드를 읽고 동작을 확인하다 보면 그보다 오래 걸릴 수 있다. 이럴 때는 검토에 시간을 너무 쓰고 있는 것처럼 느껴질 법하다.

하지만 내가 건너뛴 확인을 동료가 대신하게 될 수도 있다.

PR을 받은 사람이 왜 공통 코드까지 바뀌었는지 추적하고 기존 동작을 찾아보고 작성자가 어디까지 확인했는지 다시 물어야 한다면 작업은 아직 많이 남아 있다. 내 화면에서 빨리 끝났다는 이유만으로 팀의 일도 줄었다고 보기는 어렵다.

물론 작성자가 모든 문제를 찾아낸 뒤에야 리뷰를 요청할 수 있다는 뜻은 아니다. 놓친 부분을 함께 찾기 위해 리뷰를 받는다. 다만 내가 어떤 이유로 이 변경을 가져왔고 어디까지 확인했는지는 설명할 수 있어야 동료도 그다음 질문을 할 수 있다.

그래서 PR 설명을 직접 써보는 일이 도움이 될 것 같다. AI가 정리한 내용을 참고하더라도 내가 확인한 범위에 맞게 고쳐보는 것이다.

“조회 실패 후 사용자가 다시 시도할 방법이 없어 버튼을 추가했다. 기존 조회 함수를 다시 실행하도록 했고, 재조회에 성공하면 정상 화면으로 돌아오는 것을 확인했다.”

실제로 확인했다면 이렇게 적을 수 있다. 확인하지 않았다면 그 부분은 아직 남은 일이다. 설명을 쓰다가 막히면 어디를 더 읽고 실행해봐야 할지도 알 수 있다.

처음부터 코드를 모두 이해한 뒤에야 AI를 써야 한다고 생각하지는 않는다. 낯선 코드에서 어디부터 읽어야 할지 물을 수도 있고 호출 흐름이나 가능한 원인을 정리해달라고 할 수도 있다. 도움을 받아 이해하는 과정도 충분히 의미가 있다. 다만 설명을 듣고 이해한 것 같더라도 실제 코드와 동작이 그 설명에 맞는지 확인하고 싶다.

직접 작성한 코드가 줄어들어도 내가 맡은 변경은 남는다. 동료가 이유를 물었을 때 함께 코드를 보며 설명할 수 있고 아직 모르는 부분은 무엇인지 말할 수 있었으면 한다.

AI가 작업을 끝냈다는 메시지는 그 확인을 시작할 때로 받아들이면 좋겠다.