AI가 작성한 코드를 리뷰하는 기술: 동작·로직·가독성 관점

이전 시리즈에서 "AI의 출력을 평가하는 심미안이 엔지니어의 핵심 기술(Core Skill)"이라는 이야기를 나누었습니다.

그렇다면 구체적으로 무엇을 어떻게 봐야 할까요?

이 시리즈에서는 "AI가 작성한 코드의 리뷰 관점"을 3회에 걸쳐 체계화합니다.

AI는 코드를 "빠르고 대량으로" 생성할 수 있습니다.

하지만 "올바르고 안전하며 오래 사용할 수 있는 코드"인지 여부는

인간이 판단할 수밖에 없습니다.

그것을 할 수 있는 엔지니어가 AI 시대에 가치를 발휘할 수 있습니다.

AI가 작성한 코드에는 인간이 작성한 코드와 조금 다른 "함정(Pitfall)"이 있습니다.

인간이 작성한 코드	AI가 작성한 코드
작성한 사람에게 의도를 물을 수 있음	"왜 이렇게 작성했는지" 나중에 물어볼 수 없음
...	...

그렇기에 "리뷰하는 인간의 눈"이 중요해집니다.

AI를 사용하면 사용할수록 리뷰 기술이 요구되는 시대가 되었습니다.

코드 리뷰는 크게 5가지 관점으로 나눌 수 있습니다.

관점	내용
1	✅ 동작의 정확성: 기대한 대로 동작하는가·에지 케이스(Edge case)가 고려되었는가
...	...

이번에는

동작·로직·가독성의 3가지를 자세히 살펴보겠습니다.

퍼포먼스(Performance)·보안(Security)은 제2회에서 해설하겠습니다.

당연하게 들리겠지만, AI의 코드는 "언뜻 보면 동작할 것 같아도" 실제로는 동작하지 않는 케이스가 의외로 많습니다.

체크 항목	확인 방법
실제로 동작시켜 보았는가	로컬 환경에서 실행한다
...	...

에지 케이스(Edge case)란?

"보통이 아닌·극단적인 상황"을 말합니다.

예: 빈 데이터·0·매우 큰 수·특수 문자 등.

🎯

AI는 해피 패스(Happy path, 정상계)의 천재, 에지 케이스의 범인입니다.

해피 패스(Happy path, 정상계)란 "모든 것이 정상적으로 잘 진행되는 케이스"를 말합니다.

AI는 "보통 사용될 때"의 코드는 높은 정밀도로 작성할 수 있지만,

"예상치 못한 일이 일어났을 때"의 처리를 간과하기 쉽습니다.

실제로 어떻게 다른지 코드로 살펴보겠습니다.

❌ AI가 저지르기 쉬운 코드 (에지 케이스 미고려)

function getFirstItem(list: string[]) {
return list[0].toUpperCase(); // list가 비어있거나 null이면 크래시(Crash) 발생!
}

✅ 인간이 리뷰하여 수정한 코드

function getFirstItem(list: string[] | null | undefined): string | null {
// list 자체가 존재하지 않거나, 빈 배열이라면 null을 반환
if (!list || list.length === 0) return null;
...

이 코드의 개선 포인트:

string[] | null | undefined
: 호출 측에서 null이나 undefined를 전달하더라도 안전함

?. (옵셔널 체이닝 (Optional chaining))
: 요소가 존재하지 않을 경우 크래시 없이 undefined를 반환

?? null (Null 병합 연산자 (Nullish coalescing operator))
: undefined와 null을 통일하여 null로 반환

에지 케이스 예시	확인해야 할 것
빈 데이터가 들어왔을 때	에러가 발생하는가? 빈 리스트를 반환하는가?
...	...

에러 핸들링(Error handling)이란?

"무언가 제대로 되지 않았을 때"의 대처 방법을 말합니다.

예: 데이터베이스에 접속할 수 없음·파일을 찾을 수 없음 등.

AI는 에러 핸들링을 생략하는 경우가 있습니다.

확인 포인트	좋은 예	나쁜 예
에러가 발생했을 때	이해하기 쉬운 메시지를 반환함	아무것도 반환하지 않고 멈춤
...	...	...

코드가 동작하고 있더라도, 로직(Logic, 처리 방식)이 틀려 있는 경우가 있습니다.

로직(Logic)이란?

코드 안의 "생각 방식·처리 흐름"을 말합니다.

예: "사용자가 관리자라면 모든 데이터를 보여준다"라는 판단 부분.

AI는 "그럴듯한 로직"을 자신만만하게 작성합니다. 하지만 요구사항과 미묘하게 어긋나 있을 때가 있습니다.

흔한 로직의 어긋남	구체적인 예
조건이 반대로 되어 있음	"로그인 상태라면 차단한다"가 "로그인하지 않았다면 차단한다"로 되어 있음
...	...

타입(Type)이란?

"이 변수에는 숫자만 들어간다" "이 함수는 문자열을 반환한다"라는

데이터의 종류를 사전에 결정해 두는 메커니즘입니다.

TypeScript 등의 언어에서는 타입을 정의함으로써 실수를 방지할 수 있습니다.

AI는 타입 정의를 "일단 동작하게" 작성하는 경우가 있으며, 이는 나중에 문제가 되는 케이스가 있습니다.

AI가 저지르기 쉬운 타입 문제	구체적인 예시	무엇이 문제인가
any를 남용함	function process(data: any)	타입 체크가 작동하지 않아 실수를 놓치게 됨
unknown을 쓰지 않고 any로 회피함	const result: any = fetchData()	unknown을 사용하면 타입 체크를 강제할 수 있음에도 안전성을 버리고 있음
타입이 실제 데이터와 일치하지 않음	string이어야 하는데 number로 되어 있음	실행 시점에 에러가 발생함
null 또는 undefined를 고려하지 않음	user.name.toUpperCase()	user가 존재하지 않을 때 크래시(Crash) 발생
반환값(Return value)의 타입이 부정확함	실제로는 null을 반환하는데 타입 정의는 string뿐임	호출하는 쪽에서 에러가 발생함

any와 unknown의 차이:

any: 타입 체크를 완전히 무효화합니다. 무엇이든 허용하기 때문에 위험합니다.
unknown: "타입을 알 수 없음"을 명시합니다. 사용하기 전에 타입 체크를 강제할 수 있어 안전합니다.

AI가 any를 사용하고 있다면, unknown으로 바꿀 수 없는지 검토하세요.

❌ AI가 저지르기 쉬운 코드 (any로 회피함)

function formatUser(user: any) {
return user.name.toUpperCase();
}

✅ 사람이 리뷰하여 수정한 코드 (unknown + 타입 가드(Type Guard)로 안전하게)

type User = {
name: string;
email: string;
...

체크 포인트:

any가 사용되었다면 "왜?"라고 생각하세요.

외부 데이터에는 unknown을 사용하고, 타입을 검증한 후에 처리하는 것이 안전합니다.

AI에게 코드를 작성하게 할 때, 요건(만들고자 하는 것의 조건)을 정확하게 전달하지 않으면, 올바른 것처럼 보이지만 실제로는 틀린 코드가 만들어질 수 있습니다.

리뷰할 때는 반드시 "이 코드는 요건을 충족하는가?"를 확인하세요.

체크 방법:

"만약 〇〇라면 어떻게 될까?"라고 소리 내어 생각하기.

요건서나 사양서가 있다면 하나씩 대조하기.

코드는 작성된 후에도 계속 읽히고 수정됩니다.

유지보수성 (maintainability)이란?

"나중에 수정하거나 개선하기 쉬운가"라는 성질을 말합니다.

유지보수성이 낮은 코드는 수정할 때 다른 버그를 만들어내기 쉽습니다.

AI가 작성한 코드는 "동작하는 것"을 우선하기 때문에 가독성이 희생될 수 있습니다.

매직 넘버 (magic number)란?

코드 안에 갑자기 등장하는 "의미를 알 수 없는 숫자"를 말합니다.

나중에 읽었을 때 "이 숫자가 뭐였더라?"라고 생각하게 된다면 그것이 매직 넘버입니다.

AI는 코드 안에 의미를 알 수 없는 숫자를 그대로 적어 넣는 경우가 자주 있습니다.

❌ AI가 저지르기 쉬운 코드 (매직 넘버를 그대로 사용)

if (user.role === 1) {
// 관리자 처리
}
...

✅ 사람이 리뷰하여 수정한 코드

const ROLE_ADMIN = 1;
const STATUS_PUBLISHED = 3;
if (user.role === ROLE_ADMIN) {
...

"이 숫자가 뭐였지?"라고 생각된다면 주의해야 합니다.

AI에게 "숫자를 상수로 정의해줘"라고 지시하거나, 리뷰 시에 직접 의미 있는 이름으로 교체하세요.

변수명과 함수명은 "코드의 가독성"과 직결됩니다.

나쁜 명명(Naming) 예시	문제점	개선 예시
d	어떤 데이터인지 알 수 없음	user_data
flag	어떤 플래그인지 알 수 없음	is_logged_in
process()	무엇을 처리하는지 알 수 없음	send_welcome_email()
data2	data1과의 차이를 알 수 없음	filtered_products

명명 체크:

함수명·변수명을 읽고 "무엇을 하는 것인지"를

즉시 알 수 있다면 합격. 알 수 없다면 개선이 필요합니다.

하나의 함수가 너무 길면 무엇을 하고 있는지 파악하기 어려워집니다.

기준	사고 방식
20~30행 이내	한 화면에서 전체가 보임
...

docstring (docstring)이란?

함수나 클래스의 설명을 작성하기 위한 특별한 형식의 주석입니다.

"어떤 기능을 하는 함수인지", "어떤 값을 받는지", "무엇을 반환하는지"를 기록합니다.

AI는 주석을 생략하는 경우가 있습니다. 나중에 읽을 사람(미래의 자신 포함)을 위해 확인합시다.

확인 포인트	내용
이 함수가 무엇을 하는지 적혀 있는가	docstring 또는 서두의 주석
...

실제로 리뷰할 때 사용할 수 있는 체크리스트입니다.

• 로컬에서 실제로 실행하여 확인했다

• 빈 데이터, 0, 특수 문자 등 극단적인 케이스(edge case)로 테스트했다

• 에러가 발생했을 때 적절한 메시지가 반환된다

• 데이터를 찾을 수 없을 때 크래시(crash)가 발생하지 않는다

• 요구사항·사양서와 대조했다

• 조건의 방향("이상", "초과" 등)이 올바르다

• "만약 〇〇라면?"이라고 소리 내어 생각했다

• 변수명·함수명을 읽고 의미를 알 수 있다

• 하나의 함수가 너무 길지 않다 (기준: 30행 이내)

• 복잡한 처리에 주석이 달려 있다

• docstring으로 함수의 목적·인자(argument)·반환값(return value)이 설명되어 있다

AI 코드 리뷰의 첫걸음은 "의심하는 습관"을 갖는 것입니다. "작동하니까 괜찮아"가 아니라

"정말로 올바르게 작동하는가?"라고 계속해서 질문하는 것이

리뷰 기술의 출발점입니다.

관점	한마디로 말하면
✅ 동작의 정확성	실제로 실행해 보았는가·극단적인 케이스도 테스트했는가?
...

다음 회차에는 퍼포먼스(performance)와 보안(security)의 관점을 해설합니다!

"느린 코드", "위험한 코드"를 어떻게 찾아내는지 초보자도 알기 쉽게 해설하겠습니다🌟

💬 질문이나 감상이 있다면 댓글창에 편하게 남겨주세요!

👍 도움이 되었다면 '좋아요'와 '저장'을 부탁드립니다!

🎓 여기까지 읽어주셔서 정말 감사합니다!

• 【제1회】 동작·로직·가독성의 관점 (이 기사)
• 【제2회】 퍼포먼스·보안의 관점 (곧 공개 예정)
• 【제3회】 설계·아키텍처(architecture)의 관점 (곧 공개 예정)