AI 코딩 실력, 총점보다 낮은 항목을 보세요: 10분 자가진단표

AI로 코드를 빨리 만드는 사람은 많아졌다. 그런데 “AI를 잘 쓰고 있나요?”라고 물으면 답하기가 어렵다. 프롬프트를 많이 안다고 실력이 높은 것도 아니고, 생성된 코드가 한 번에 실행됐다고 안전한 것도 아니다.

그래서 이번에는 속도나 사용 횟수가 아니라 혼자 설명하고 검증할 수 있는 능력을 기준으로 현재 위치를 점검해보자.

목표는 높은 총점을 받는 것이 아니다. 가장 낮은 항목을 구체적으로 발견하고, 30일 뒤 달라졌다는 증거를 남기는 것이다.

1점과 5점의 차이는 ‘AI 사용량’이 아니다

각 항목을 1점부터 5점까지 매긴다.

점수기준

1점	해본 적이 없거나 무엇부터 해야 할지 모른다
2점	예시를 따라 하면 일부 수행할 수 있다
3점	AI나 동료의 도움을 받으면 끝낼 수 있다
4점	대부분 혼자 수행하고 결과를 검토할 수 있다
5점	AI 없이도 원리를 설명하고 검증 기준을 세울 수 있다

여기서 5점은 AI를 쓰지 않는다는 뜻이 아니다. AI를 사용하더라도 판단권을 내가 가지고 있다는 뜻이다. 어떤 작업을 맡길지, 결과가 맞는지, 실패하면 어디까지 되돌릴지를 설명할 수 있어야 한다.

자신에게 후하게 점수를 주거나 지나치게 박하게 줄 필요도 없다. 최근 한 달 동안 실제로 했던 행동을 떠올리고 점수를 매긴다.

여덟 가지 항목으로 현재 위치를 진단한다

아래 표를 복사해 시작 점수를 적어보자. 머릿속의 자신감이 아니라 최근 작업에서 남은 증거를 기준으로 판단한다.

진단 항목시작 점수30일 후남길 증거

문제를 1~2시간 작업으로 나눈다			작업 목록, 이슈
낯선 코드의 진입점과 흐름을 찾는다			코드 지도, 호출 흐름
오류에서 가능한 원인과 반증 조건을 세운다			디버깅 가설 기록
정상·경계·실패 테스트를 설계한다			테스트 코드와 결과
Git diff에서 범위 밖 변경을 찾는다			리뷰 메모, 수정 커밋
AI가 만든 코드를 내 말로 설명한다			설계 설명, 주석 없는 요약
프롬프트에 완료 조건과 금지 범위를 적는다			작업 계약 프롬프트
에이전트의 읽기·쓰기 권한을 구분한다			권한 정책, 승인 기록

총점은 40점이지만 숫자 하나로 자신을 평가하지 않는다. 28점인 두 사람도 약점은 전혀 다를 수 있다. 한 사람은 테스트가 약하고, 다른 사람은 문제를 작게 나누지 못할 수 있다.

중요한 것은 가장 낮은 두 항목이다. 그곳이 AI를 쓸수록 더 빨리 드러나는 병목이다.

항목별로 무엇을 보면 되는가

1. 문제를 1~2시간 작업으로 나눈다

“로그인 기능 만들어줘”를 그대로 AI에게 넘기는가, 아니면 입력 검증·세션 생성·오류 처리·테스트처럼 확인 가능한 단위로 나누는가를 본다. 좋은 작업은 끝났는지 눈으로 확인할 수 있다.

2. 낯선 코드의 진입점과 흐름을 찾는다

파일을 무작정 많이 읽는 것이 아니라 요청이 들어오는 곳, 핵심 규칙이 있는 곳, 데이터가 저장되는 곳을 연결할 수 있는지 확인한다. 코드 지도 한 장을 남길 수 있다면 증거가 된다.

3. 원인과 반증 조건을 세운다

오류를 보자마자 첫 번째 추측으로 코드를 고치는 대신 가능한 원인 세 개와 각각을 기각할 가장 싼 실험을 적을 수 있는가? 로그 한 줄, 테스트 하나, 입력 비교처럼 작은 실험이 핵심이다.

4. 정상·경계·실패 테스트를 설계한다

정상 입력만 확인하지 않고 빈 값, 최대·최소 경계, 중복 요청, 권한 없음, 외부 서비스 실패를 떠올릴 수 있는지 본다. AI가 작성한 테스트의 빠진 조건을 발견할 수 있어야 한다.

5. Git diff에서 범위 밖 변경을 찾는다

코드가 예뻐졌다는 인상보다 요청하지 않은 파일, 의존성, 설정, 삭제된 예외 처리를 찾는 능력이다. 변경 목적과 관계없는 줄을 되돌린 기록도 좋은 증거다.

6. AI 코드를 내 말로 설명한다

“AI가 그렇게 만들었다”가 아니라 데이터가 어디서 들어와 어떤 조건을 거쳐 무엇을 반환하는지 설명할 수 있는가? 설명이 막히는 줄은 아직 내가 소유하지 못한 코드다.

7. 완료 조건과 금지 범위를 적는다

무엇을 만들지뿐 아니라 테스트 명령, 허용할 파일, 바꾸면 안 되는 API, 네트워크 사용 금지 등을 요청에 포함하는지 본다. 좋은 프롬프트는 부탁이 아니라 작업 계약에 가깝다.

8. 에이전트의 읽기·쓰기 권한을 구분한다

코드 읽기, 파일 수정, 외부 전송, 배포를 같은 수준으로 허용하지 않는가? 영향이 커질수록 사람의 승인을 요구하도록 경계를 정할 수 있어야 한다.

가장 낮은 점수를 ‘실제 상황’과 연결한다

“테스트가 약하다”처럼 추상적으로 적으면 30일 뒤에도 무엇이 달라졌는지 알기 어렵다. 최근 막혔던 상황과 연결하면 연습 과제가 선명해진다.

예를 들어 이렇게 적을 수 있다.

경계값 테스트 설계: 2점. 할인 금액이 주문 총액보다 클 때 음수가 되는 사례를 놓쳤고, 운영 오류 뒤에야 조건을 추가했다.

그다음 30일 뒤 남길 증거를 정한다.

• 정상·경계·실패 사례가 포함된 테스트 파일
• 테스트를 먼저 실패시킨 실행 화면
• AI가 놓친 조건을 찾아 수정한 diff
• 왜 이 조건이 필요한지 내 말로 쓴 리뷰 메모

점수보다 증거가 중요하다. 점수가 2점에서 4점으로 올랐다고 적는 것보다, 이전에는 없던 테스트와 설명을 보여주는 편이 훨씬 설득력 있다.

30일 목표는 한 번에 하나만 고른다

낮은 항목을 모두 고치려 하면 매일 체크만 하다가 끝난다. 가장 낮은 항목 하나를 고르고, 작은 프로젝트 하나에 반복 적용한다.

좋은 목표는 다음처럼 쓸 수 있다.

30일 동안 작은 주문 계산 프로젝트를 만들며, 모든 기능에 정상·경계·실패 테스트를 먼저 세 개씩 작성한다. 매주 금요일에는 AI가 놓친 조건과 내가 추가한 근거를 한 문단으로 정리한다.

이 문장에는 기간, 프로젝트, 반복 행동, 증거가 모두 들어 있다.

반대로 “AI 코딩 실력을 높이겠다”는 완료 여부를 판단하기 어렵다. “매일 두 시간 공부하겠다”도 시간을 썼다는 사실만 보여줄 뿐 무엇을 할 수 있게 됐는지는 말하지 못한다.

10분 자가진단 순서

1. 여덟 항목에 1~5점을 매긴다.
2. 가장 낮은 항목 두 개에 표시한다.
3. 각 항목 때문에 최근 막혔던 실제 상황을 한 줄로 적는다.
4. 이번 달에 집중할 항목 하나를 선택한다.
5. 30일 뒤 보여줄 코드·테스트·문서 증거를 정한다.
6. 한 달 동안 반복할 가장 작은 프로젝트를 한 문장으로 정의한다.

마지막으로 스스로에게 묻는다.

• AI 없이도 이 작업의 원리를 설명할 수 있는가?
• AI가 틀렸을 때 어디가 틀렸는지 찾을 수 있는가?
• 다음에는 같은 작업의 어느 부분을 혼자 할 수 있는가?

AI 시대의 실력은 답을 빨리 받는 능력만이 아니다. 답을 작은 작업으로 바꾸고, 실패를 예상하고, 결과를 검증해 내 것으로 만드는 능력이다.

오늘 총점이 낮아도 괜찮다. 가장 낮은 한 칸을 찾았다면 이미 다음 연습이 정해졌다.

다음 글에서는 이 진단 결과를 실제 연습으로 바꾸는 여섯 장의 실습 시트를 소개한다.