AI 코딩 실력, 7일 안에 확인하는 법: 최종 미니 프로젝트 설계법

AI와 함께 코딩하면 결과물은 놀랄 만큼 빨리 나옵니다. 그런데 결과물이 빨리 나온 것과 내 실력이 늘어난 것은 같은 말이 아닙니다. 실력은 “무엇을 만들었는가”보다 어떤 문제를 골랐고, 어디까지를 범위로 정했으며, 무엇으로 완료를 증명했는가에서 드러납니다.

그래서 이번 편에서는 거창한 새 서비스를 시작하지 않습니다. 현재 배우는 언어나 프레임워크로 3~7일 안에 끝낼 수 있는 기능 하나를 고르고, AI를 활용하되 판단과 검증은 내가 책임지는 최종 미니 프로젝트를 설계해 보겠습니다.

새 서비스보다 ‘기능 하나’가 좋은 이유

짧은 프로젝트에서 가장 흔한 실패는 욕심입니다. 로그인, 결제, 알림, 관리자 화면까지 한꺼번에 만들려다 보면 프로젝트의 절반은 환경 설정과 화면 연결에 쓰이고, 정작 중요한 문제 정의와 테스트는 뒤로 밀립니다.

반대로 이미 있는 미니 프로젝트에 검색, 정렬, 입력 검증, 알림 중 하나를 추가하면 범위가 선명해집니다. 기존 동작을 이해해야 하고, 새 기능의 경계를 설명해야 하며, 변경 전후를 테스트로 비교할 수 있습니다. 작은 기능이 오히려 개발자의 사고 과정을 더 잘 보여주는 이유입니다.

피해야 할 과제권장하는 과제

쇼핑몰 전체 만들기	상품 목록에 가격 범위 필터 추가
새 SNS 서비스 만들기	기존 게시물 목록에 정렬 옵션 추가
일정 관리 앱 전체 만들기	일정 입력값 검증과 오류 안내 개선
알림 시스템 전부 만들기	특정 이벤트 한 종류에 알림 추가

시작 전에 프로젝트 브리프부터 쓴다

코드를 열기 전에 아래 다섯 가지를 한 장에 적어 보세요. 이 문서는 AI에게 주는 프롬프트이면서, 범위가 흔들릴 때 돌아올 기준점이 됩니다.

1. 사용자 문제: 사용자가 지금 무엇 때문에 불편한가?
2. 성공 조건: 어떤 상태가 되면 문제가 해결됐다고 말할 수 있는가?
3. 비목표: 이번 프로젝트에서 의도적으로 하지 않을 것은 무엇인가?
4. 작업 분해: 일을 1~2시간 단위로 어떻게 나눌 것인가?
5. 완료 산출물: 코드, 테스트, README, 회고 중 무엇을 남길 것인가?

예를 들어 “할 일 앱에 검색 기능 추가”라면 사용자 문제는 “완료된 항목이 많아 원하는 일을 찾기 어렵다”입니다. 성공 조건은 “검색어가 제목에 포함된 항목만 즉시 보이고, 빈 검색어에서는 전체 목록이 보인다”처럼 관찰 가능한 문장으로 씁니다.

비목표에는 태그 검색, 서버 전문 검색, 검색 기록 저장을 넣을 수 있습니다. 비목표를 적는 순간 프로젝트는 작아지고, 완료 가능성은 커집니다.

AI 사용 모드를 작업마다 바꾼다

AI를 처음부터 끝까지 자동 조종사로 두면 결과는 빨리 나오지만 무엇을 배웠는지 확인하기 어렵습니다. 작업 성격에 따라 역할을 바꾸는 편이 좋습니다.

작업내가 먼저 할 일AI에게 맡길 역할

문제 정의	사용자 문제와 성공 조건 초안 작성	빠진 경계 조건을 질문하게 하기
코드 읽기	관련 파일과 데이터 흐름 찾기	내가 만든 지도를 검토하게 하기
구현	변경 범위와 인터페이스 결정	제한된 범위의 구현 후보 만들기
테스트	정상·경계·실패 사례 정의	누락된 회귀 위험 찾기
리뷰	diff를 읽고 선택 근거 설명	반례와 대안을 제시하게 하기

중요한 것은 AI의 제안을 모두 채택하지 않는 것입니다. 선택하지 않은 제안과 그 이유도 기록해야 합니다. “이 구조는 지금 범위에 비해 복잡하다”, “새 의존성을 추가하므로 제외했다” 같은 판단이야말로 개발자의 실력을 보여줍니다.

3~7일 실행 계획

기간은 짧지만 매일 산출물이 남도록 설계합니다. 프로젝트 규모에 따라 이틀을 합치거나 하루를 나눠도 괜찮습니다.

• 1일차: 문제 정의, 비목표, 완료 조건을 확정하고 관련 코드의 흐름을 그린다.
• 2일차: 정상·경계·실패 사례를 정하고 최소 하나의 실패 테스트를 만든다.
• 3일차: 기능의 가장 작은 수직 조각을 구현한다.
• 4일차: 경계 조건과 오류 처리를 추가하고 회귀 테스트를 돌린다.
• 5일차: Git diff를 읽으며 불필요한 변경을 제거한다.
• 6일차: README에 사용법, 설계 선택, 남은 위험을 적는다.
• 7일차: AI 없이 핵심 흐름을 설명하거나 다시 구현하고 회고한다.

완료를 증명하는 다섯 가지

화면이 잘 보인다는 말만으로는 충분하지 않습니다. 다음 다섯 가지를 하나의 증거 묶음으로 제출해 보세요.

1. 나의 첫 생각: AI에게 묻기 전 작성한 문제 정의와 첫 가설
2. 선택의 흔적: 실제 프롬프트와 채택하지 않은 AI 제안
3. 테스트 변화: 실패 테스트와 수정 후 통과 결과
4. 변경 설명: 핵심 Git diff와 사용법을 담은 README
5. 설명 가능성: AI 없이 다시 구현하거나 설명할 수 있는 부분에 대한 회고

이 자료들은 포트폴리오에도 강합니다. 완성 화면만 보여주는 포트폴리오는 누가, 어떻게, 왜 만들었는지 알기 어렵습니다. 반면 문제 정의부터 실패와 판단까지 연결된 기록은 지원자가 실제로 코드를 읽고 책임질 수 있음을 보여줍니다.

정상·경계·실패 테스트를 하나씩

테스트는 많이 쓰는 것이 목표가 아닙니다. 요구사항의 경계를 표현하는 것이 목표입니다. 검색 기능을 예로 들면 다음처럼 시작할 수 있습니다.

• 정상: 검색어와 일치하는 항목만 보인다.
• 경계: 검색어가 비어 있으면 전체 목록이 보인다.
• 실패: 데이터 로딩에 실패하면 빈 화면 대신 오류 상태를 보여준다.

여기에 기존 정렬이나 완료 처리 기능이 깨지지 않는지 회귀 테스트를 하나 더하면 좋습니다. 새 기능의 성공뿐 아니라 기존 기능의 안전까지 증명하기 때문입니다.

5점짜리 프로젝트는 무엇이 다른가

완성 후에는 결과물의 크기보다 과정의 선명도를 평가합니다.

평가 영역보통 수준좋은 수준

문제 정의	기능 이름과 대략적 범위가 있다	사용자 문제·비목표·완료 조건이 선명하다
코드 이해	주요 흐름을 설명한다	상태·경계·실패까지 설명한다
테스트	정상 사례와 일부 경계가 있다	요구사항과 회귀 위험을 함께 증명한다
AI 활용	일부 제안을 검증한다	역할을 나누고 제안·검증·판단을 기록한다
변경 관리	작은 커밋과 설명이 있다	diff·대안·롤백·남은 위험이 연결된다

30일 뒤, 점수보다 증거를 다시 본다

프로젝트가 끝났다고 진단도 끝난 것은 아닙니다. 30일 뒤 같은 질문을 다시 던져 보세요.

• AI 없이 먼저 세울 수 있는 가설이 늘었는가?
• 생성된 코드를 읽고 설명하는 시간이 줄었는가?
• 테스트가 단순 확인이 아니라 요구사항 표현이 됐는가?
• 프롬프트에 범위, 완료 조건, 중단 조건이 자연스럽게 들어가는가?
• 결과 화면뿐 아니라 판단과 검증 과정을 보여줄 수 있는가?

점수를 올리고 싶다면 반드시 옆에 증거를 붙이세요. 증거가 없다면 점수도 올리지 않는 것이 좋습니다. 이 냉정한 습관이 “AI로 뭔가를 많이 만들어 본 자신감”과 “실제로 설명하고 고칠 수 있는 실력”을 구분합니다.

오늘 바로 시작하는 가장 작은 행동

지금 가지고 있는 프로젝트를 열고 검색, 정렬, 입력 검증, 알림 중 하나를 고르세요. 그리고 코드부터 쓰지 말고 아래 네 문장을 먼저 채워 보세요.

사용자는 ______ 때문에 불편하다.
이번 기능은 ______ 상태가 되면 완료다.
이번에는 ______까지 하지 않는다.
완료는 ______ 테스트와 ______ 기록으로 증명한다.

AI 시대의 개발 실력은 생성 속도만으로 측정되지 않습니다. 작은 문제를 정확히 고르고, 범위를 지키고, 실패를 확인하고, 끝났다는 증거를 남기는 능력. 그 능력을 가장 빠르게 확인하는 방법이 바로 3~7일짜리 최종 미니 프로젝트입니다.