AI 시대의 SE·프로그래머를 위한 AI 벽치기(Wall-hitting) 실전 입문 제4회: AI에게 통째로 맡기지 않는 코드 리뷰·디버깅

연재: AI 시대의 SE·프로그래머를 위한 AI 벽치기(Wall-hitting) 실전 입문

전 5회 | 제4회 / 5
이 연재는 AI를 '답을 내는 기계'가 아니라, '전제를 파고들고, 선택지를 늘리며, 판단을 검증하는 파트너'로 사용하기 위한 실전 시리즈입니다.

AI는 코드를 작성할 수 있습니다.

하지만 AI의 코드를 그대로 믿으면, 작동하지 않는 코드나 위험한 수정 사항을 도입하게 될 수 있습니다.

"에러를 붙여넣었더니 수정 코드가 나와서 적용했다. 그런데 다른 버그가 생겼다."

"AI의 리뷰에서 '문제없습니다'라는 말을 들었지만, 사실 보안 취약점(Security Hole)이 있었다."

이런 경험을 한 적이 없으신가요?

지난 회차에서는 설계 단계에서의 벽치기를 다루었습니다. 이번에는 구현·리뷰·디버깅 상황에서 AI를 안전하게 사용하는 벽치기 절차를 정리합니다.

AI에게 디버깅을 '통째로 맡기면' 실패하는 이유
에러 상담·코드 리뷰·테스트 관점 벽치기 템플릿
AI가 틀리기 쉬운 포인트
벽치기 실례 ("API 응답이 빈 값(Empty)이 되는 버그"를 주제로)
AI의 답변을 검증하는 절차

먼저 결론부터 말씀드립니다.

구현 중의 AI 벽치기는 코드 생성보다 아래의 용도로 사용할 때 더 안정적입니다.

용도	효과
재현 조건 정리	문제의 범위가 명확해짐
...

즉, AI는 '수정 코드를 받아내는 상대'가 아니라, '원인과 대책의 선택지를 늘려주는 상대'로 사용해야 합니다.

이 에러를 고쳐주세요.
TypeError: 'NoneType' object is not subscriptable

AI는 수정 코드를 반환하지만, 다음과 같은 문제가 있습니다.

문맥(Context) 없이 전달하기 때문에 AI는 추측으로 수정한다 - 추측이 틀리면 다른 버그를 심어 넣는다 - 근본 원인이 아니라 증상만 없애는 수정이 되기 쉽다 - 테스트 없이 "수정 완료"라고 판단해 버린다

에러가 발생했을 때, 갑자기 수정 코드를 요구하는 것이 아니라 원인 가설을 정리하게 만드는 유형입니다.

다음 에러에 대해, 갑자기 수정 코드를 내놓지 말고
원인 가설을 정리해 주세요.
하고 싶은 것:
...

자신의 코드를 리뷰하게 하는 유형입니다. 포인트는 "리뷰 관점"과 "제약 사항"을 명시하는 것입니다.

다음 코드를 리뷰해 주세요.
리뷰 관점:
- 버그 가능성
...

@app.get("/tasks")
def get_tasks(db: Session = Depends(get_db)):
    tasks = db.query(Task).all()
    return [{"id": t.id, "title": t.title, "status": t.status} for t in tasks]

"사양을 마음대로 바꾸지 말 것", "불분명한 점은 질문으로 던질 것"이라는 두 가지 제약이 중요합니다. 이것이 없으면 AI가 사양을 독자적으로 해석하여 큰 변경을 제안할 수 있습니다.

### 유형 ③: 테스트 관점 생성형
테스트 케이스를 생각하기 전에, 테스트 관점을 AI에게 뽑아내게 하는 유형입니다.
```text
다음 사양에 대해 테스트 관점을 제시해 주세요.
사양:
- GET /tasks 는 태스크 목록을 반환한다
...

AI를 리뷰나 디버깅에 사용할 때, 다음과 같은 실수가 일어나기 쉽습니다. 사전에 알고 있으면 대책을 세울 수 있습니다.

패턴	예	대책
존재하지 않는 API 사용	폐기된 메서드를 제안	공식 문서(Official Documentation)로 확인한다
...	`except: pass`로 에러를 뭉개버리는 제안	보안·안전성 관점에서 리뷰
테스트 없이 완료 처리	"이것으로 동작할 것입니다"라고 끝냄	로컬에서 반드시 실행 확인한다

방금 전의 에러 상담 유형을 실제로 사용해 보겠습니다.

🤖 AI (디버깅 상담역):

원인 가설 (가능성이 높은 순서):

수정안:

가설 1의 경우:
get_db의 세션 스코프를 확인. yield 이후에 db.close()

있는지 확인.

가설 4의 경우: 환경 변수 DATABASE_URL의 값을 로그로 출력하여 확인.

재발 방지를 위한 테스트 관점:

DB에 테스트 데이터를 넣은 상태에서 GET /tasks를 호출하는 테스트를 추가
응답 건수를 검증하는 어설션 (Assertion)을 넣을 것
「다른 DB를 보고 있다」는 맹점이었다: 스스로는 깨닫기 어려운 가설을 AI가 제시함
수정 전에 확인 명령어가 나열되었다: 갑자기 코드를 고치는 것이 아니라, 먼저 상태를 확인하는 절차가 정리됨
테스트 관점이 구체화되었다: 막연하게 「테스트를 작성한다」가 아니라, 무엇을 검증해야 하는지 명확해짐

AI의 답변은 다음 절차로 검증하십시오.

공식 문서에서 확인하기: AI가 제안한 API나 메서드가 사용 중인 버전에서 실제로 존재하는지 확인한다.
로컬에서 실행하기: 수정 코드는 운영 환경이 아닌 로컬 개발 환경에서 먼저 실행한다.
테스트 작성하기: 수정 후 기대한 대로 동작하는지 테스트로 확인한다.
차이점(Diff) 확인하기: AI가 제시한 수정 사항과 자신의 원본 코드 사이의 차이를 한 줄씩 확인한다.
부작용(Side Effect) 확인하기: 수정이 다른 기능에 영향을 주지 않는지 확인한다.
AI의 수정 코드를 그대로 커밋하지 말 것: AI의 수정 코드는 「제안」이지 「동작 보증」이 아니다. 반드시 로컬에서 실행하고 테스트를 통과한 후 커밋한다.
기밀 코드를 전달하지 말 것: 리뷰 요청 시 코드를 전달할 경우, 인증 토큰·API 키·고객 데이터가 포함되어 있지 않은지 확인한다. 필요에 따라 더미(Dummy) 값으로 교체한다.
AI가 「문제없습니다」라고 말해도 안심하지 말 것: AI는 구문적으로 올바른 코드에 대해 「문제없음」이라고 답하기 쉽다. 로직 버그·비즈니스 규칙 위반·보안 취약점(Security Hole)은 놓치는 경우가 있다.

구현 중 AI 벽치기(Wall-hitting)를 수행하기 전에 다음을 확인해 보세요.

환경 정보(OS, 언어, 라이브러리, 버전)를 작성했는가
기대 결과와 실제 결과를 작성했는가
최근에 변경한 사항을 작성했는가
갑자기 수정 코드를 요구하지 않고, 원인 가설을 먼저 내놓게 했는가
AI의 수정을 로컬에서 실행하여 확인했는가
테스트 관점을 확인했는가
기밀 정보를 코드에서 제거했는가

AI에게 코드를 통째로 맡기는 것이 아니라, 원인 가설·리뷰 관점·테스트 관점을 늘려가는 상대로 활용하면 구현 중의 벽치기가 안정됩니다.

이번 기사에서 소개한 내용을 되돌아봅니다.

AI에게 에러를 통째로 맡기면 다른 버그가 들어온다 — 원인 가설을 먼저 내놓게 할 것
3가지 유형(에러 상담형·코드 리뷰 요청형·테스트 관점 생성형)으로 벽치기가 안정됨
AI가 틀리기 쉬운 패턴을 알고 있으면 대처할 수 있음
AI의 답변은 반드시 검증할 것 — 로컬 실행·테스트·공식 문서 확인

다음 회차에서는, AI와의 벽치기 로그를 지식화(Knowledge)하여 포트폴리오로 만드는 방법을 다룹니다.

지금까지 4회에 걸쳐 다룬 벽치기 결과를 어떻게 「흘려보내고 끝내는 것」이 아니라 「재사용 가능한 자산」으로 바꿀지를 정리합니다. 벽치기 로그를 Markdown화하여 RAG·MCP·Qiita 기사·포트폴리오에 연결하는 방법을 소개합니다.

이 기사에서는 AI의 답변을 그대로 정답으로 취급하는 것을 권장하지 않습니다.

실무 이용 시에는 기밀 정보를 넣지 말 것, 출력을 검증할 것, 필요에 따라 인간이 판단할 것을 전제로 합니다.

AI와의 벽치기는 「질문」이 아니라 「사고 프로세스 설계」이다
모호한 아이디어를 요구사항으로 바꾸는 AI 벽치기 템플릿
구현 전에 AI와 설계 리뷰를 하기 위한 벽치기 절차
AI에게 통째로 맡기지 않는 코드 리뷰·디버깅 벽치기 기술 ← 이번 회차
AI와의 벽치기 로그를 지식화하여 포트폴리오로 바꾸기

AI 시대의 SE·프로그래머를 위한 AI 벽치기(Wall-hitting) 실전 입문 제4회: AI에게 통째로 맡기지 않는 코드 리뷰·디버깅

요약

핵심 포인트

댓글