AI 코딩 시대, 코드 리뷰보다 설계와 테스트를 먼저 봐야 할까요

AI 코딩 시대, 코드 리뷰보다 설계와 테스트를 먼저 봐야 할까요

AI 뉴스 썸네일

AI 코딩 도구가 하루에 수천 줄을 만들면, 사람이 모든 줄을 같은 깊이로 검토하기는 어려워요. Redis 창시자 살바토레 산필리포는 개발자가 코드 자체보다 설계와 동작 원리, 테스트에 더 많은 시간을 써야 한다고 주장했어요. 1

핵심 요약

구분	핵심	실무에서 볼 점
검토 대상	생성된 코드 전체보다 소프트웨어의 설계와 정신 모델을 먼저 확인해요	구현이 요구사항과 데이터 구조를 제대로 반영하는지 설명할 수 있어야 해요
품질 관리	코드 스타일 검토에 쓰던 시간을 QA와 비교 테스트에 더 배분해요	정상 경로뿐 아니라 경계 조건과 동시성 문제를 테스트로 고정해야 해요
문서	데이터 구조와 구현 기법을 DESIGN.md처럼 사람이 읽을 수 있는 문서에 남겨요	다음 개발자가 코드를 열기 전에 설계 의도부터 파악할 수 있어요
학습	경험이 적은 개발자에게 같은 방식이 맞는지는 아직 답이 없어요	작은 인터프리터나 데이터베이스를 직접 만들며 정신 모델을 익히는 과정은 여전히 필요해요

1. 생성 속도가 빨라질수록 무엇을 검토할지 다시 정해야 해요

산필리포의 출발점은 시간이에요. 하루 8시간 안에 5,000줄을 읽으면 새로운 기능을 구상하거나 성능을 개선하고 QA를 할 시간이 줄어요. 그래서 줄 단위 검토를 기본값으로 두기보다, 먼저 원하는 설계와 각 부분의 동작 원리를 확인하자는 제안이에요. 2

LLM은 함수 하나를 완성하는 일에는 강하지만 여러 구성 요소가 얽힌 설계를 놓칠 수 있어요. 개발자는 "이 코드를 읽었는가"보다 "왜 이 데이터 구조를 골랐고, 실패 조건은 무엇이며, 다른 구현과 결과가 같은가"를 물어야 해요. 답변이 모호하면 구현을 더 생성하기 전에 설계를 다시 잡는 편이 안전해요.

728x90

DESIGN.md는 코드의 사용 설명서가 아니라 판단 기록이에요

산필리포는 Redis의 각 데이터 구조에 핵심 아이디어와 구현 기법, 전체 설계를 사람이 읽는 문장으로 남기는 방식을 제안했어요. 다음 개발자는 파일을 바로 고치기보다 설계 문서를 읽고 시스템의 정신 모델부터 익힐 수 있어요. 그다음 변경 요청이 기존 설계와 맞는지 비교할 수 있어요.

문서에는 구성 요소 이름만 나열하기보다 선택의 이유를 적어야 쓸모가 있어요. 예를 들어 정렬 집합의 메모리를 줄였다면, 바뀐 표현 방식과 조회 비용의 변화, 유지해야 할 불변 조건을 함께 남겨야 해요. 테스트는 이 조건이 실제 구현에서도 지켜지는지 확인해요.

QA를 늘려도 코드 이해가 사라지지는 않아요

원문은 DwarfStar에서 LLM 추론 구현을 자동화한 경험을 사례로 들어요. 산필리포는 모델에 구현을 맡겼지만, 추론 방식과 성능 목표를 이해하고 다른 시스템과 결과를 비교했다고 설명해요. 이 과정에서 컨텍스트 길이에 따라 출력 품질이 떨어지는 오류나 불필요한 연산 같은 문제를 확인했다고 해요. 2

이 사례를 "코드를 읽지 않아도 된다"라는 규칙으로 받아들이면 위험해요. 설계 설명과 테스트만으로 원인을 좁히기 어려운 장애도 있어요. 보안 경계, 메모리 안전성, 동시성 제어처럼 작은 구현 차이가 큰 사고로 이어지는 영역에서는 줄 단위 검토가 여전히 필요해요. 바뀌는 것은 검토의 폐지가 아니라 검토 깊이를 정하는 순서예요.

경험이 적은 개발자에게는 별도 학습 경로가 필요해요

숙련된 개발자는 코드가 없어도 설계 설명에서 빠진 조건을 알아차릴 수 있어요. 경험이 적으면 그 판단에 필요한 정신 모델부터 부족할 수 있어요. 산필리포도 이 문제에는 확실한 답이 없다고 밝혔어요.

작은 인터프리터, 해시 테이블, 데이터베이스를 직접 구현하는 연습은 이런 간격을 줄여 줘요. 생성된 대규모 코드를 수동으로 훑는 것보다 입력과 상태, 자료구조, 실패 조건을 직접 다뤄 볼 수 있기 때문이에요. 팀에서는 설계 리뷰에 주니어 개발자를 참여시키고, 테스트가 어떤 위험을 막는지 설명하는 과정도 함께 두는 편이 좋아요.

왜 중요한가요

AI 코딩 도구를 많이 쓸수록 코드 생산량은 빠르게 늘어요. 반면 리뷰 시간은 그대로예요. 모든 변경에 같은 검토 방식을 적용하면 중요한 설계 오류와 경계 조건을 볼 시간이 부족해질 수 있어요. 2

실무에서는 위험도에 따라 검토 단계를 나눌 수 있어요. 먼저 요구사항과 설계 문서, 데이터 흐름을 확인해요. 다음으로 테스트와 기준 구현 비교를 통과시켜요. 인증, 결제, 데이터 손실, 동시성처럼 위험이 큰 부분은 사람이 코드까지 깊게 읽어요. 단순한 화면 연결이나 반복 코드에는 자동 검사와 표본 검토를 적용할 수 있어요.

이 방식이 통하려면 생성 도구가 아니라 팀이 설계의 주도권을 가져야 해요. 구현 선택을 설명하지 못하거나 테스트가 실패 조건을 다루지 못하면 완료로 보지 않는 기준이 필요해요. 코드양이 늘수록 좋은 문서와 강한 테스트가 검토 시간을 아껴 주는 기반이 돼요.

참고 자료

1. 코드가 아니라 아이디어를 통제하라 — GeekNews
2. Control the ideas, not the code — antirez