AI 코딩의 계획 모드는 끝났나: 승인 버튼과 코드 이해 사이

핵심 요약

• 계획서는 구현 방향을 설명하지만, 실제 코드가 그 방향대로 동작한다는 증거는 아닙니다.
• 읽기 좋은 계획서에도 권한이나 예외 상황처럼 중요한 조건이 빠질 수 있습니다.
• 코드를 이해했는지는 모든 줄을 읽었느냐보다 중요한 동작과 실패 조건을 설명할 수 있느냐로 판단해야 합니다.
• 계획 모드는 구현 후 무엇을 확인할지까지 정할 때 더 쓸모가 있습니다.

AI에게 코드를 맡기고 사람은 계획서를 읽은 뒤 승인한다고 해보겠습니다. 직접 코드를 쓰는 수고는 줄겠지만, 승인 버튼을 누른 사람이 결과를 얼마나 이해했는지는 별개의 문제입니다. “계획 모드는 끝났나”를 따지려면 먼저 계획서를 읽으면서 무엇을 확인하는지부터 짚어봐야 합니다.

계획서에 동의했다는 건 어디까지 이해했다는 뜻일까요

여기서 말하는 계획 모드는 AI가 코드를 수정하기 전에 작업 순서와 접근 방법을 제시하는 절차입니다. 집을 고치기 전에 어디를 어떻게 공사할지 맞춰보는 과정과 비슷합니다.

이 과정은 꽤 유용합니다. 사용자는 “로그인 화면만 바꿔달라는 뜻이었는데 인증 구조까지 손대려는군요”처럼 요청과 어긋난 부분을 일찍 알아챌 수 있습니다. AI가 무엇을 확인하지 않은 채 작업을 진행하려는지도 살펴볼 수 있습니다.

다만 계획서에서 확인한 것은 구현 의도입니다. 실제 코드가 어떤 데이터를 읽고 어떤 조건에서 실패하는지는 구현한 코드를 봐야 알 수 있습니다.

“오류 처리를 추가하겠습니다”라는 문장에는 쉽게 동의할 수 있습니다. 하지만 어떤 오류를 잡고 사용자에게 무엇을 보여줄지까지 합의한 것은 아닙니다. 실패한 작업을 다시 실행해도 되는지도 따져봐야 합니다. 짧고 읽기 좋은 문장에서는 이런 세부 조건을 놓치기 쉽습니다.

계획서가 잘 읽힌다는 이유로 코드까지 이해했다고 생각하면, 의도와 실제 동작 사이에 이런 차이가 있을 수 있다는 점을 놓칩니다.

‘검색 결과를 5분간 저장’한다는 계획의 빈칸

팀 문서를 검색하는 서비스에 캐시를 추가한다고 해보겠습니다. 캐시는 같은 계산이나 조회를 반복하지 않도록 결과를 잠시 저장하는 장치입니다.

AI가 다음과 같은 계획을 내놓습니다.

같은 검색어의 결과를 5분간 저장해 응답 속도를 개선하겠습니다.

무엇을 하려는지는 쉽게 이해할 수 있습니다. 그런데 이 설명에는 누가 검색했는가라는 중요한 질문이 빠져 있습니다.

팀마다 볼 수 있는 문서가 다르다면 검색어가 같아도 결과는 달라야 합니다. 저장된 결과를 구분하는 이름표인 ‘캐시 키’에 검색어만 넣으면 다른 팀의 결과를 재사용할 위험이 있습니다. 같은 팀 안에서도 사용자별로 열람 권한이 다르다면 팀만 구분해서는 부족할 수 있습니다.

권한이 바뀔 때도 생각해야 합니다. 방금 열람 권한을 잃은 사용자에게 이전 검색 결과를 계속 보여준다면, 저장 기간이 짧다는 것만으로는 문제가 해결되지 않습니다.

이 계획을 이해하려면 “캐시를 넣으면 빨라진다”는 설명에 고개를 끄덕이는 것만으로는 부족합니다. 누구의 검색 결과를 누구에게 다시 보여줘도 되는지까지 설명할 수 있어야 합니다.

승인할 때 던질 질문을 바꿔야 합니다

계획서를 더 길게 쓰면 이런 문제가 해결될까요? 조건을 자세히 적으면 도움이 됩니다. 하지만 문서가 길다고 해서 빠진 조건이나 구현 실수를 찾아낼 수 있는 것은 아닙니다.

검토할 때는 설명을 더 많이 읽는 것만으로 부족합니다. 계획에 적힌 각 항목을 보고, 제대로 구현했는지 확인 가능한 질문으로 바꿔야 합니다.

앞의 검색 기능이라면 이렇게 물을 수 있습니다.

• 서로 다른 팀의 사용자가 같은 검색어를 입력해도 각자 허용된 문서만 받는가?
• 사용자의 열람 권한이 바뀌면 저장된 결과는 어떻게 처리되는가?
• 캐시가 작동하지 않을 때도 검색 기능은 정상적으로 동작하는가?

구현 전에는 이 질문들로 요구사항을 정할 수 있습니다. 구현 후에는 같은 질문을 기준으로 코드를 검토하고 테스트할 수 있습니다. 계획에서 약속한 내용을 완성된 코드가 지키는지 확인하는 것입니다.

AI에게 테스트 작성도 맡길 수 있습니다. 다만 처음부터 권한 조건을 놓쳤다면 테스트에서도 같은 조건을 빠뜨릴 수 있습니다. 테스트를 통과했다는 보고를 받더라도 어떤 상황을 검사했는지 함께 살펴봐야 합니다.

모든 코드를 읽어야만 이해한 걸까요

사람이 AI가 만든 코드를 전부 한 줄씩 읽어야 한다면 일을 맡겨서 얻는 이점은 줄어들 수 있습니다. 그렇다고 계획서만 읽고 책임 있게 판단하기도 어렵습니다.

현실적으로는 중요한 동작을 설명할 수 있는지가 기준이 됩니다. 무엇이 바뀌었고 어떤 조건에서 잘못될 수 있는지 알아야 합니다. 문제가 생겼을 때 어떻게 되돌릴지도 설명할 수 있어야 합니다. 설명하다 막히는 부분이 있다면 해당 코드와 검증 결과를 더 들여다봐야 합니다.

얼마나 자세히 검토할지는 변경 내용에 따라 달라집니다. 버튼 문구를 고치는 작업과 사용자 권한을 바꾸는 작업에 같은 분량의 계획서가 필요하지는 않습니다. 영향이 큰 변경일수록 조건을 구체적으로 적고, 그 조건을 충족했는지 확인한 근거도 갖춰야 합니다.

계획 모드가 유용한지는 승인 버튼이 있느냐보다 사람이 중요한 판단을 내리는 데 얼마나 도움이 되느냐에 달려 있습니다. 계획을 읽고 구현 결과까지 확인할 수 있다면 여전히 쓸모 있는 절차입니다. AI의 계획서를 승인할 때는 “말이 되는 설명인가”와 함께 “이 코드가 잘못됐을 때 무엇으로 알아챌 수 있을까”에도 답할 수 있어야 합니다.