최근 SNS에서 "AI에게 코드를 작성하게 한 뒤, 인간이 제대로 리뷰해야 하는가"라는 이야기를 자주 접합니다.

이전의 저라면, 상당히 강하게 "봐야 한다"라고 생각했을 것입니다. 하지만 최근에는, 이제 인간이 차이점(diff)을 전부 읽는다는 전제가 무너지고 있다는 느낌이 듭니다.

물론, 리뷰가 불필요하다는 의미는 아닙니다. 오히려 AI에 의한 코드 리뷰(Code Review)는 필수라고 생각합니다. 다만, 인간이 해야 할 일은 생성된 코드를 한 줄씩 읽는 것이 아니라, 리뷰하는 에이전트(Agent)와 검증용 하네스(Harness)를 제대로 만드는 것으로 옮겨가고 있는 것이 아닌가, 하는 감각입니다.

생각해 보면, AI가 나오기 전부터 우리는 모든 코드를 읽고 있었던 것은 아닙니다.

curl의 소스 코드를 읽고 사용했나요? jQuery의 내부를 전부 이해하고 있었나요? React나 Next.js의 구현을 읽고 프로덕트에 도입했나요?

아마, 대부분 읽지 않았을 것입니다. 신뢰하는 OSS(Open Source Software)는 내부를 전부 읽지 않고 사용해 왔습니다.

물론, OSS와 AI 생성 코드는 같지 않습니다. OSS에는 이용 실적, 메인테이너(Maintainer), 이슈(Issue), 리뷰 이력(Review History)이 있습니다. 반면, 자신의 프로젝트에서 AI가 만든 코드에는 그러한 외부적인 신뢰가 아직 옅습니다. 그래서 "신뢰할 수 없는 코드는 인간이 봐야 한다"라는 의견은 상당히 옳다고 생각합니다.

다만, 그 전제도 조금씩 변하고 있습니다. 지금의 AI는 인간이 급하게 작성하는 코드보다, 더 깔끔한 구조로 내놓는 경우가 늘었습니다. 적어도 제 주변에서는 "우선 인간이 전부 읽지 않으면 위험하다"라는 감각이 상당히 옅어지고 있습니다.

오히려, 인간의 리뷰가 무겁게 필요해질 때는 AI의 문제라기보다 업무를 나누는 방식이 너무 크기 때문인 경우가 많다는 느낌이 듭니다.

무엇이든 한 번에 만들게 한다. 사양(Specification)도 모호한 채로 넓은 범위를 한꺼번에 변경하게 한다. 테스트나 타입(Type), lint의 기반도 약하다. 그런 상태에서 "AI의 코드는 무섭다"라고 말하고 있다면, 무서운 것은 AI라기보다 맡기는 방식의 입도(Granularity)입니다.

제대로 영역을 나눈다. 작은 단위로 만들게 한다. AI 리뷰용 에이전트를 별도로 세운다. 테스트, 타입, 정적 분석(Static Analysis), 실행 확인을 하네스(Harness)에 포함시킨다.

인간이 봐야 할 것은 생성된 코드 그 자체보다, 이러한 메커니즘(Mechanism) 쪽이라고 생각합니다.

"인간이 코드를 읽을 수 있어야 한다"라는 이야기는 여전히 맞습니다. 하지만 "AI가 작성한 코드를 인간이 매번 전부 읽어야 한다"는 것은, 이제 슬슬 다른 이야기가 되어가고 있는 느낌입니다.

앞으로 중요해지는 것은 코드를 읽는 능력 그 자체보다, AI에게 읽히는 설계, 실패를 감지하는 메커니즘, 맡기는 입도를 결정하는 능력이라고 생각합니다.