<div id="readability-page-1" class="page"><article itemscope="" itemtype="http://schema.org/BlogPosting">
 

 <div itemprop="articleBody">
 “코드리뷰는 너무 오래 걸린다”는 말을 들을 때마다 그래도 해야 한다고 했다. 테스트코드도 중요하다고 했다. 기본기 이야기를 많이 했다.

그런데 막상 AI가 등장하고 나서, 테스트코드는 예상보다 빠르게 해소됐다. AI가 테스트를 꽤 잘 작성해준다. 하지만 코드리뷰는 오히려 더 어려워졌다. AI가 짠 코드가 많아지면서 리뷰해야 할 양은 늘었고, 코드를 충분히 이해하지 못한 채 올라오는 PR도 생겼다. 병목이 심해졌다.

지난주에 <a href="https://news.hada.io/weekly/202617">GeekNews 위클리</a>를 읽다가 Kernighan의 법칙을 인용한 문장이 눈에 박혔다. 디버깅은 코딩보다 두 배 어렵다. AI가 코딩을 빠르게 대신하고 있다면, 검증의 난이도는 상대적으로 더 높아진다는 이야기다.

맞는 말인데, 읽으면서 드는 생각은 조금 달랐다. 검증이 어려워진 것보다, 빠르게 만들 수 있게 되자 확인하는 단계를 건너뛰게 됐다는 것이다.

AI 리뷰 도구가 높은 점수를 준 PR이 있었다. 나는 바빴고, 작업자는 “잘 동작한다”고 했다. 그게 전부였다. 한 달쯤 후에 다른 기능을 작업하다가 그 PR의 선택이 약간 걸림돌이 됐다. 치명적인 건 아니었지만, 점수 말고 다른 질문을 한 번이라도 했더라면 피할 수 있는 부분이었다.

뭘 물어봤어야 했을까. 왜 이렇게 짰는지. 일정 압박 때문은 아닌지. 더 나은 방법을 알면서도 포기한 건 아닌지. AI는 코드가 테스트를 통과하는지, 컨벤션에 맞는지는 판단할 수 있다. 하지만 그 선택 뒤에 있는 맥락은 알 수 없다.

코드 수준만의 이야기도 아니다. 구현이 빨라지다 보니 “정말 필요한 기능인가”를 충분히 묻지 않고 개발이 늘어나기 시작했다. 만들 수 있으니까 만들게 된다. 어설픈 검증으로 쌓인 기능들은 결국 고객을 피로하게 만든다.

빠르게 할 수 있게 되자, 확인하는 단계가 비싸 보이기 시작했다.

마틴 파울러가 세 가지 부채를 이야기했다. 기술 부채는 코드의 문제고, 인지 부채는 팀의 공유된 이해가 사라지는 문제고, 의도 부채는 왜 이 시스템이 이렇게 만들어졌는지 기록이 없는 문제다. AI가 빠르게 코드를 만들수록 인지 부채와 의도 부채가 더 빠르게 쌓인다.

반응은 양 극단으로 갈리는 것 같다.

어떤 회사들은 아예 AI가 리뷰하고 AI가 approve까지 한다고 들었다. 실행력이 더 중요한 곳에서는 이쪽으로 가게 될 것 같다. 반대로 AWS는 한때 코드리뷰를 생략하는 방향으로 갔다가 다시 시니어가 반드시 코드리뷰를 해야 하는 구조로 바뀌었다고 한다. 안정성이 더 중요한 회사에서는 사고 하나로 신뢰를 꾸준히 잃어가기 때문이다.

어느 쪽이 맞는지는 모르겠다. 다만 두 선택 모두 의식적인 결정이라는 점에서는 같다. 그 중간 어딘가에서 아무 생각 없이 흘러가는 게 가장 위험할 것 같다.

Addy Osmani가 70% 문제라는 표현을 썼다. AI가 70%를 만들고 나머지 30%의 품질을 판단하는 건 사람이라는 이야기다.

그 30%가 새로 생긴 일처럼 느껴졌다. 그런데 생각해보니 아니었다. 왜 이렇게 구현했는지 물어보는 것. 이 선택이 다음에 어떤 영향을 줄지 짚어보는 것. 코드가 동작한다는 것과 잘 만들었다는 것의 차이를 구분하는 것. 이 기능이 지금 만들어져야 하는가를 묻는 것. 이건 AI가 등장하기 전에도 시니어가 해오던 일이었다.

바뀐 건 그 30%에 가격표가 새로 붙었다는 것이다. AI가 70%를 담당하면서 이 확인들의 비용이 상대적으로 더 비싸졌다. 건너뛰기도 더 쉬워졌다.

기본기가 뭔지 잘 모르겠다는 생각이 든다. 늘 중요하다고 했는데, 막상 AI 시대가 오니 어떤 건 해소됐고 어떤 건 더 어려워졌다. 다만 그 30%의 자리, 건너뛰기 쉬운 것들을 건너뛰지 않는 자리는 기본기의 일부인 것 같다.

그래서 나는 앞으로 이런 질문을 하려고 한다.

코드 수준에서: 왜 이런 코드를 짜게 됐는가. 일정의 압박 때문은 아니었는가. 관성적으로 존재하는 아키텍처를 그냥 고른 건 아닌가. 타협하진 않았는가.

기능 수준에서: 이 기능이 지금 정말 필요한가. 어설픈 완성도로 전달됐을 때 고객이 얻는 게 있는가.

이 질문들은 AI 점수가 아무리 높아도 대신 해줄 수 없다. 그걸 발견하는 데 꽤 오래 걸렸다.

 </div>
</article></div>

Epilogue

“코드리뷰는 너무 오래 걸린다”는 말을 들을 때마다 그래도 해야 한다고 했다. 테스트코드도 중요하다고 했다. 기본기 이야기를 많이 했다.
그런데 막상 AI가 등장하고 나서, 테스트코드는 예상보다 빠르게 해소됐다. AI가 테스트를 꽤 잘 작성해준다. 하지만 코드리뷰는 오히려 더 어려워졌다. AI가 짠 코드가 많아지면서 리뷰해야 할 양은 늘었고, 코드를 충분히 이해하지 못한 채 올라오는 PR도 생겼다. 병목이 심해졌다.
지난주에 GeekNews 위클리를 읽다가 Kernighan의 법칙을 인용한 문장이 눈에 박혔다. 디버깅은 코딩보다 두 배 어렵다. AI가 코딩을 빠르게 대신하고 있다면, 검증의 난이도는 상대적으로 더 높아진다는 이야기다.
맞는 말인데, 읽으면서 드는 생각은 조금 달랐다. 검증이 어려워진 것보다, 빠르게 만들 수 있게 되자 확인하는 단계를 건너뛰게 됐다는 것이다.
AI 리뷰 도구가 높은 점수를 준 PR이 있었다. 나는 바빴고, 작업자는 “잘 동작한다”고 했다. 그게 전부였다. 한 달쯤 후에 다른 기능을 작업하다가 그 PR의 선택이 약간 걸림돌이 됐다. 치명적인 건 아니었지만, 점수 말고 다른 질문을 한 번이라도 했더라면 피할 수 있는 부분이었다.
뭘 물어봤어야 했을까. 왜 이렇게 짰는지. 일정 압박 때문은 아닌지. 더 나은 방법을 알면서도 포기한 건 아닌지. AI는 코드가 테스트를 통과하는지, 컨벤션에 맞는지는 판단할 수 있다. 하지만 그 선택 뒤에 있는 맥락은 알 수 없다.
코드 수준만의 이야기도 아니다. 구현이 빨라지다 보니 “정말 필요한 기능인가”를 충분히 묻지 않고 개발이 늘어나기 시작했다. 만들 수 있으니까 만들게 된다. 어설픈 검증으로 쌓인 기능들은 결국 고객을 피로하게 만든다.
빠르게 할 수 있게 되자, 확인하는 단계가 비싸 보이기 시작했다.
마틴 파울러가 세 가지 부채를 이야기했다. 기술 부채는 코드의 문제고, 인지 부채는 팀의 공유된 이해가 사라지는 문제고, 의도 부채는 왜 이 시스템이 이렇게 만들어졌는지 기록이 없는 문제다. AI가 빠르게 코드를 만들수록 인지 부채와 의도 부채가 더 빠르게 쌓인다.
반응은 양 극단으로 갈리는 것 같다.
어떤 회사들은 아예 AI가 리뷰하고 AI가 approve까지 한다고 들었다. 실행력이 더 중요한 곳에서는 이쪽으로 가게 될 것 같다. 반대로 AWS는 한때 코드리뷰를 생략하는 방향으로 갔다가 다시 시니어가 반드시 코드리뷰를 해야 하는 구조로 바뀌었다고 한다. 안정성이 더 중요한 회사에서는 사고 하나로 신뢰를 꾸준히 잃어가기 때문이다.
어느 쪽이 맞는지는 모르겠다. 다만 두 선택 모두 의식적인 결정이라는 점에서는 같다. 그 중간 어딘가에서 아무 생각 없이 흘러가는 게 가장 위험할 것 같다.
Addy Osmani가 70% 문제라는 표현을 썼다. AI가 70%를 만들고 나머지 30%의 품질을 판단하는 건 사람이라는 이야기다.
그 30%가 새로 생긴 일처럼 느껴졌다. 그런데 생각해보니 아니었다. 왜 이렇게 구현했는지 물어보는 것. 이 선택이 다음에 어떤 영향을 줄지 짚어보는 것. 코드가 동작한다는 것과 잘 만들었다는 것의 차이를 구분하는 것. 이 기능이 지금 만들어져야 하는가를 묻는 것. 이건 AI가 등장하기 전에도 시니어가 해오던 일이었다.
바뀐 건 그 30%에 가격표가 새로 붙었다는 것이다. AI가 70%를 담당하면서 이 확인들의 비용이 상대적으로 더 비싸졌다. 건너뛰기도 더 쉬워졌다.
기본기가 뭔지 잘 모르겠다는 생각이 든다. 늘 중요하다고 했는데, 막상 AI 시대가 오니 어떤 건 해소됐고 어떤 건 더 어려워졌다. 다만 그 30%의 자리, 건너뛰기 쉬운 것들을 건너뛰지 않는 자리는 기본기의 일부인 것 같다.
그래서 나는 앞으로 이런 질문을 하려고 한다.
코드 수준에서: 왜 이런 코드를 짜게 됐는가. 일정의 압박 때문은 아니었는가. 관성적으로 존재하는 아키텍처를 그냥 고른 건 아닌가. 타협하진 않았는가.
기능 수준에서: 이 기능이 지금 정말 필요한가. 어설픈 완성도로 전달됐을 때 고객이 얻는 게 있는가.
이 질문들은 AI 점수가 아무리 높아도 대신 해줄 수 없다. 그걸 발견하는 데 꽤 오래 걸렸다.

코드 짜는 비용이 0에 가까워질수록 비싸지는 것들

댓글