일본 개발 현장에서 달라진 것: 구현은 단 1시간, 검토는 반나절

저는 아직 기능 명세서를 읽고 있는데, AI는 벌써 코드를 내놓습니다.

요즘 일본의 대기업 고객사 현장과 사내 프로젝트에서 겪는 일입니다. 화면과 API의 동작·조건을 적어 둔 기능 명세서를 넘기면, 구현에 단위 테스트 코드까지 한 시간 안팎에 나옵니다. 예전에는 명세 내용을 읽고 파악하는 데만 반나절쯤 걸렸습니다. 제가 이해하는 속도보다 코드가 나오는 속도가 빨라진 겁니다.

덕분에 잔업이 없어졌습니다. 솔직히 좋습니다. 동시에 제가 시간을 들여 익힌 구현 능력이 앞으로도 지금처럼 평가받을까 하는 걱정이 듭니다.

그런데 구현이 빨라졌다고 검토까지 한 시간 안에 끝나는 것은 아닙니다. 초안을 읽고 수정하는 데는 반나절 이상이 걸리곤 했습니다. 구현은 빨라졌는데 왜 검토에는 반나절이 필요했을까요? 줄어든 구현 시간 동안 저는 어디에 시간을 쓰게 됐을까요? 

이 글에서는 AI의 작업물을 검토하면서 알게 된, 검토에 시간이 오래 걸린 이유와, 그 경험을 거치며 달라진 저의 작업 방식을 공유해보겠습니다.

AI로 인해 검토에 반나절 걸리게 된 이유

제 검토가 길었던 데에는 두 가지 이유가 있었습니다. 코드가 나오는 속도를 제가 요구사항을 이해하는 속도가 따라가지 못했습니다. 그리고 완성돼 보이는 코드에도 실제 조회 권한이나 이번 작업의 범위가 빠져 있었습니다. 코드의 동작만 확인해서는 끝나지 않았고, 구현의 바탕이 된 명세 내용까지 다시 살펴야 했습니다.

1. 코드가 나오는 속도보다 이해 속도가 느렸다

현재 사용하는 도구는 비주얼 스튜디오 코드(Visual Studio Code, 이하 VS Code)의 깃허브 코파일럿(GitHub Copilot)입니다. 한 줄씩 제안을 받는 자동완성보다, 프로젝트의 문서와 코드를 읽고 작업하는 에이전트 모드를 사용합니다. 일반적인 코딩에는 GPT-5.6 Sol을, 복잡한 배치 작업에는 클로드 오퍼스 5(Claude Opus 5)를 사용해 왔습니다.

예전에는 기능 명세서를 읽고 화면에 보여 줄 값과 조회 조건, 기존 처리와 연결되는 지점을 파악한 뒤 직접 구현했습니다. 예전 같으면 요구사항 파악부터 구현까지 며칠을 잡았을 작업입니다. 이제는 기능 명세서가 정리돼 있으면 구현과 단위 테스트 코드의 초안을 먼저 받아 볼 수 있습니다.

단위 테스트 코드까지 붙은 결과를 받으면 할 일이 많이 끝난 것처럼 보입니다. 하지만 제가 명세 내용을 충분히 파악하지 못한 상태라면, 테스트의 기대 결과가 맞는지도 판단하기 어렵습니다. 코드가 빨리 나왔다는 이유로 제 이해 속도까지 빨라진 것은 아니었습니다.

제 작업에서는 초안을 확인하고 수정하는 데 반나절 이상이 걸리곤 했습니다. 제목의 한 시간과 반나절은 따로 측정한 평균이 아니라 작업하면서 느낀 대략적인 시간입니다. 요구사항이 정리된 작업의 구현·단위 테스트 코드 초안과 사람의 검토 시간을 나눠 표현했습니다.

2. AI는 권한이 없는데 할 수 있다고 가정했다

명세 내용을 이해하는 데 시간이 걸린다는 것만이 문제는 아니었습니다. AI가 만든 코드에 현장에서 사용할 수 없는 전제가 들어간 경우도 있었습니다. 개발하던 기능 중에는 상사의 메일 주소를 조회해 알림을 보내는 기능이 있었습니다. 그런데 제가 사용할 수 있는 조회 권한은 제 계정 정보를 확인하는 범위로 제한돼 있었습니다. 다른 사람인 상사의 정보를 같은 방식으로 조회할 수 없다는 제약이 있었습니다.

이 조건에서는 발송 코드를 만드는 것보다 먼저, 상사의 주소를 어떤 허용된 방법으로 얻을지 정해야 했습니다. 그런데 AI는 필요한 정보를 조회할 수 있다는 가정으로 구현을 이어 가거나, 하드코딩으로 처리를 진행하려 했습니다. 코드를 완성하는 과정에서 실제로 사용할 수 있는 권한과 정보의 범위가 빠진 것입니다.

여기서 확인할 것은 메일 주소를 넣는 부분이었습니다. 이 값은 어디서 가져오는지, 현재 계정으로 조회할 수 있는지, 고정해서 써도 되는지를 확인해야 했습니다. 주소가 코드 안에 들어 있으면 발송 처리까지는 이어질 수 있습니다. 하지만 그 주소를 어떻게 확보할지 정해지지 않은 상태는 그대로 남습니다.

이 부분은 현재도 다른 방법을 찾고 있습니다. 메일을 보내는 구현 자체는 빨라도, 필요한 정보를 얻는 방법이 정해지지 않으면 이 기능을 완성했다고 할 수 없습니다. 제게는 이 미해결 조건을 코드에서 다시 찾아내는 일이 남았습니다.

3. 나중에 할 기능까지 이번 작업에 포함했다

기능을 만들 수 있는지와 함께, 지금 만들어야 하는지도 확인해야 했습니다. 나중에 진행하려고 코드를 일부 준비해 뒀는데 AI가 그 부분까지 구현하는 식입니다. 저장소 안에서는 미완성인 코드가 보이지만, 제게는 지금 완성할 대상이 아니었습니다.

이런 변경은 기능이 더 생겼다는 이유로 받아들이기 어렵습니다. 이번 작업에서 구현해야 하는 것과 나중에 할 것을 구분해야 하기 때문입니다. 요청하지 않은 변경은 되돌려야 할 때도 있었습니다. AI가 많은 파일을 수정했는지보다, 그 수정이 이번에 필요한 것이었는지를 확인해야 했습니다.

프로젝트를 읽고 여러 파일의 작업을 이어 가는 에이전트 기능은 분명 편리합니다. 다만 저장소에서 확인할 수 있는 내용에는 이번 요청에 필요한 자료와 나중을 위해 준비해 둔 내용이 함께 들어 있습니다. AI가 읽을 수 있는 것과 제가 이번에 맡긴 일은 같지 않을 수 있었습니다.

4. 명세가 틀리면 구현과 테스트가 함께 틀릴 수 있었다

권한과 작업 범위를 확인해도, 그 기준으로 삼은 기능 명세서가 맞는지는 별도로 살펴야 했습니다. AI가 만든 결과를 검토하다 보면 기능 명세서 쪽에 이상한 부분이 있는 경우도 있었습니다. 명세 내용을 충실히 구현했더라도 실제 업무와 맞지 않으면 결과를 그대로 사용할 수 없습니다. 어디를 고쳐야 할지 정하려면 코드와 명세 내용 중 어느 쪽에 문제가 있는지부터 확인해야 했습니다.

단위 테스트 코드가 함께 만들어졌다는 사실도 이 판단을 대신해 주지는 않습니다. 구현과 테스트가 같은 명세 내용을 바탕으로 작성됐다면, 잘못된 조건을 둘 다 받아들일 수 있습니다. 이런 가능성을 생각하면 테스트가 통과했는지뿐 아니라 기대 결과를 무엇에서 가져왔는지도 살펴야 합니다.

명세가 불완전할 때는 기존 코드를 거꾸로 읽어 빠진 동작을 확인하기도 했습니다. 이때에도 코드에 있다는 이유만으로 모두 올바른 요구사항이라고 볼 수는 없었습니다. 이상한 조건이 보이면 업무와 요구사항을 아는 사람과 상의했습니다. AI에 코드를 다시 만들라고 요청하기 전에, 제가 전달한 명세 내용부터 확인해야 했습니다.

줄어든 구현 시간을 쓰는 곳

앞서 살펴본 조건들을 확인하느라 검토에 반나절 이상이 걸려도, 예전처럼 잔업을 하지는 않습니다. 직접 코드를 작성하는 시간이 줄어 정해진 업무 시간 안에서 확인하고 수정할 여유가 생겼기 때문입니다. 검토를 거치며 제가 더 신경 쓰게 된 것은 AI에 줄 자료와 작업 범위, 그리고 사람이 직접 진행할 단계였습니다.

1. AI가 읽을 문서를 정리한다

지금 맡고 있는 문서 전환은 별도로 한 달 공수를 받아 진행하는 업무입니다. 명세를 기준으로 구현과 테스트가 함께 만들어지는 만큼, AI가 참고할 자료의 내용과 형식도 확인하고 있습니다.

문서 정리에는 제미나이 3.8 플래시(Gemini 3.8 Flash)를 사용합니다. 현재 참여 중인 일본의 대기업 고객사에서는 2026년 10월부터 기존 다섯 개 프로젝트의 엑셀 기능 명세서와 데이터베이스 명세를 마크다운(Markdown)으로 바꾸는 일을 진행하고 있습니다. AI가 문서를 읽고 파이썬(Python) 변환 프로그램을 만들어 처리하는 방식입니다. 제가 접한 일본 현장에서도 AI가 참고할 자료를 정비하는 모습을 보고 있습니다.

현장에서는 엑셀 매크로로 PDF를 만드는 지침이 내려왔지만, 프로젝트마다 문서의 구성과 양식이 달랐습니다. 자료에 따라 양식이 맞지 않거나 필요한 내용이 빠진 경우도 있습니다. 이럴 때는 변환 프로그램을 다시 돌리는 것으로 끝나지 않고, 기존 코드와 문서를 함께 놓고 빠진 요구사항을 찾아야 합니다.

변환 결과를 볼 때는 문서에서 빠진 동작이 기존 코드에 남아 있는지, 문서와 현재 구현이 다른지를 함께 확인합니다. 파일 형식을 옮겼다는 것만으로 자료 정리가 끝나지는 않습니다. 누락된 내용을 무엇을 근거로 보완할지 판단하는 시간이 필요합니다. 문서 정리에서도 코드 검토 때와 마찬가지로, 명세 내용과 현재 구현을 대조해야 했습니다.

2. 배포는 에이전트에서 분리해 사람이 단계별로 진행한다

입력할 문서를 정리하는 것과 별개로, AI에 맡길 단계도 구분하게 됐습니다. 배포에서도 저장소의 설정과 현장 절차가 어긋나는 일이 있었기 때문입니다. 다른 구성원들도 미리 구현해 넣어 둔 지속적 통합·배포(CI/CD) 관련 코드와 설정이 저장소에 있었습니다. 그런데 이번 현장에서는 정해진 수동 배포 절차를 따라야 했습니다. AI 에이전트는 그 설정을 읽고 CI/CD 방식으로 배포하려는 흐름을 반복해서 보였습니다.

AI가 읽은 설정과 현장에서 따라야 할 절차가 달랐습니다. 배포는 잘못 진행하면 장애로 이어질 수 있는 작업이라, AI가 저장소를 읽고 실행 방식을 고르게 둘 수 없었습니다. 저는 배포 단계에서 에이전트를 사용하지 않기로 했습니다.

CI/CD 코드를 수정하는 대신 파워셸(PowerShell) 스크립트를 만들어, 사람이 단계별로 진행하는 방식으로 배포했습니다. 반복 작업은 스크립트로 처리하고, 다음 단계로 넘어가는 것은 사람이 판단하도록 한 겁니다. 구현을 맡겼던 도구를 배포까지 계속 사용할 필요는 없었습니다.

3. 다음 요청에는 하지 않을 일도 적을 계획이다

배포를 에이전트에 맡기지 않기로 한 경험은 다음 구현 요청을 어떻게 적을지로 이어졌습니다. 제가 당연히 알고 있는 조회 제약이나 작업 순서를 AI도 알고 있으리라고 넘기기 어려웠습니다. 필요한 자료를 주는 것과 함께, 이번에 하지 않을 작업도 분명히 적어 둘 필요를 느꼈습니다.

다음 요청에는 현재의 조회 제약과 아직 방법이 정해지지 않은 부분도 함께 적으려 합니다. 필요한 값을 가져올 수 없다면 임의로 채우지 말고, 방법을 먼저 확인하도록 요청할 계획입니다. 준비해 둔 후속 기능은 이번에 구현하지 않는다고 명시하고, 배포는 구현 요청과 분리하려 합니다.

이런 내용을 지시 파일에 정리하는 것은 앞으로 할 일입니다. 지금은 배포를 에이전트에 맡기지 않는 대응부터 적용했습니다.

마치며

처음에는 코드가 얼마나 빨리 나오는지에 눈이 갔습니다. 지금은 그 초안에서 확인할 조건을 찾고, 다음 작업에 쓸 문서를 정리하며, 어느 단계까지 AI에 맡길지 결정하는 데 시간을 씁니다.

구현 능력의 가치가 낮아진다는 걱정은 남아 있습니다. 지금 일이 편해졌다는 이유만으로 그 고민까지 없어지지는 않았죠. 

그럼에도 제가 하는 일이 달라졌다는 사실은 명확하게 체감할 수 있었습니다. 저는 이제 AI가 빠르게 만든 결과에서, 실제로 사용할 수 없는 가정과 이번에 해서는 안 되는 변경을 찾아내는 일을 합니다.

그럼에도 잔업이 사라졌습니다. 기능 명세서를 주면 코드가 나오는 속도는 빨라졌지만, 그 코드가 현장의 업무를 제대로 끝내는지를 확인하는 것은 여전히 제 몫입니다. 그걸 확인하는 데만 반나절이 걸린다고 해도 이전보다는 여유가 생겼다는 것이 지금 제가 체감하는 변화입니다.  

여러분은 어떠신가요? AI로 인해 달라진 내 일 이야기를 들려주세요! 

이 글은 AI의 도움을 받아 작성했습니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.