비전공자 AI 코딩 첫 프로젝트, 문법보다 결과물 기준을 먼저 정하세요

AI 코딩을 처음 켜면 가장 먼저 막히는 지점은 문법이 아닙니다. "무엇을 만들면 시작했다고 볼 수 있는가"가 흐릿해서 막힙니다. React, Next.js, 배포, 데이터베이스를 한꺼번에 배우려 하면 AI에게도 요청이 커지고, 결과가 나와도 무엇을 확인해야 할지 모릅니다. 첫 프로젝트의 목표는 멋진 서비스를 끝내는 것이 아니라 내 브라우저에서 작동하는 작은 결과물을 만드는 것입니다.

developers.openai.com의 Codex CLI 문서는 Codex가 선택한 디렉터리에서 코드를 읽고, 바꾸고, 실행할 수 있는 로컬 코딩 에이전트라고 설명합니다. 그래서 초보자가 먼저 정해야 할 것은 도구 이름이 아니라 작업 범위입니다. 오늘은 "할 일 목록"처럼 작게 보이는 앱으로 시작합니다. 입력하고, 목록에 보이고, 삭제하고, 새로고침 뒤에도 남는지 확인하면 첫 주에 필요한 흐름을 대부분 만져볼 수 있습니다.

Tap to zoom

첫 결과물은 브라우저에서 눈으로 확인되는 화면이어야 합니다

첫 프로젝트를 "웹 서비스 만들기"라고 잡으면 너무 큽니다. 회원가입, 로그인, 서버, 데이터베이스, 디자인, 배포가 모두 붙습니다. 초보자에게 필요한 첫 결과물은 그보다 작습니다. 브라우저를 열었을 때 한 화면이 보이고, 내가 입력한 값이 화면에 반영되면 됩니다.

할 일 목록은 첫 프로젝트로 쓰기 쉽습니다. 이유는 기능이 작고 확인 기준이 분명하기 때문입니다.

이 정도면 충분합니다. 캘린더, 알림, 우선순위, 로그인, 팀 공유는 뺍니다. 첫 프로젝트에서는 기능을 늘리는 능력보다 작게 정하고 끝까지 확인하는 능력이 더 중요합니다.

비슷하게 AI에게 오류를 맡길 때도 범위를 작게 줘야 합니다. 막힌 화면이 나오면 AI가 만든 코드가 안 돌아갈 때 쓰는 30초 오류 프롬프트처럼 증상과 로그를 좁혀 주는 편이 좋습니다. 첫 프로젝트도 같습니다. "할 일 앱 만들어줘"보다 "입력한 문장을 배열에 추가해서 화면에 보이게 해줘"가 확인하기 쉽습니다.

오늘 뺄 기능을 먼저 적으면 AI 수정 루프가 줄어듭니다

초보자가 첫 프로젝트에서 가장 많이 잃는 시간은 새 기능을 붙이다가 원래 작동하던 화면까지 흔들리는 시간입니다. 그래서 만들 것 옆에 "오늘 뺄 것"을 같이 씁니다.

만들 것: 할 일 목록
오늘 뺄 것: 회원가입, 로그인, 마감일, 우선순위, 카테고리, 필터, 서버 저장
완성 기준: 내 브라우저에서 추가, 삭제, 새로고침 유지가 된다

이 문장을 AI에게 그대로 주면 요청 범위가 작아집니다. AI가 좋은 코드를 만들 가능성도 올라가지만, 더 중요한 효과는 사용자가 검증하기 쉬워진다는 점입니다. 화면이 안 바뀌면 추가 기능을 더 요구하기 전에 저장된 파일, 실행 중인 개발 서버, 브라우저 주소를 확인할 수 있습니다. 이 흐름은 AI가 고쳤는데 화면이 그대로일 때 7분 검증 루틴과도 이어집니다.

developer.mozilla.org의 Web Storage API 문서는 브라우저가 키와 값 형태의 데이터를 저장할 수 있다고 설명합니다. localStorage는 같은 출처의 문서에서 접근하고, 브라우저 세션이 끝난 뒤에도 데이터가 남을 수 있습니다. 첫 프로젝트에서는 이 정도 저장만으로 충분합니다. 다만 이것은 연습용 저장소입니다. 계정 연동, 여러 기기 동기화, 민감한 정보 저장까지 맡기면 안 됩니다.

AI에게는 한 화면과 한 기능씩 요청합니다

처음부터 완성 앱을 요청하면 결과가 커집니다. 파일이 많이 바뀌고, 오류가 나도 어디서 시작됐는지 찾기 어렵습니다. 첫 프로젝트에서는 다음 순서로 나눕니다.

1. 빈 화면에 제목과 입력창, 추가 버튼만 만든다.
2. 버튼을 누르면 입력값이 목록에 보이게 한다.
3. 각 항목 옆에 삭제 버튼을 붙인다.
4. 목록을 localStorage에 저장하고 새로고침 뒤에도 불러온다.
5. 입력값이 비어 있으면 추가하지 않게 한다.

각 단계가 끝날 때마다 브라우저에서 직접 확인합니다. 확인하지 않은 채 다음 기능을 붙이면 나중에 원인을 찾기 어렵습니다. 한 단계가 작동한 화면을 본 뒤 다음 요청으로 넘어갑니다.

AI에게 줄 첫 요청은 이렇게 쓰면 됩니다.

초보자용 첫 프로젝트로 할 일 목록 웹앱을 만들고 싶습니다.

오늘 만들 범위:
- 한 화면에 제목, 입력창, 추가 버튼, 할 일 목록을 보여주세요.
- 입력한 문장을 추가 버튼으로 목록에 넣어주세요.
- 아직 로그인, 서버, 필터, 마감일 기능은 만들지 마세요.

완성 기준:
- 브라우저에서 입력한 할 일이 목록에 보입니다.
- 새 파일을 많이 만들기보다 지금 구조에서 가장 작은 변경으로 시작합니다.
- 변경한 파일과 실행 방법을 마지막에 알려주세요.

developer.mozilla.org의 form 문서는 폼이 정보를 제출하기 위한 상호작용 컨트롤을 담는 문서 영역이라고 설명합니다. 초보자는 이 정의를 외울 필요는 없습니다. 다만 입력창과 버튼을 같이 다룰 때 "값을 받고, 제출하고, 화면을 갱신한다"는 흐름을 익히면 됩니다. 문법은 결과물을 확인하는 과정에서 필요한 만큼 붙이면 됩니다.

Tap to zoom

완성 기준은 기능 이름보다 사용 행동으로 씁니다

"할 일 목록 완성"은 모호합니다. 대신 사용자가 하는 행동으로 적습니다.

이 다섯 줄이 첫 프로젝트의 테스트입니다. 자동 테스트 코드를 몰라도 됩니다. 브라우저에서 직접 누르고 결과를 적으면 됩니다. 문제가 생기면 AI에게 "안 돼요"라고만 말하지 말고, 어떤 행동에서 어떤 결과가 나왔는지 붙입니다.

할 일 목록 첫 프로젝트를 확인했습니다.

통과:
- 입력창에 글자가 들어갑니다.
- 추가 버튼을 누르면 목록에 보입니다.

실패:
- 새로고침하면 목록이 사라집니다.

요청:
- 서버나 로그인은 추가하지 말고 localStorage 저장만 붙여주세요.
- 변경할 파일과 확인 순서를 먼저 말한 뒤 수정해주세요.

이렇게 쓰면 AI가 기능을 크게 바꾸기보다 실패한 한 지점을 고치기 쉽습니다. AI가 파일을 너무 많이 바꾸기 시작하면 AI가 파일을 너무 많이 고칠 때 수정 범위를 막는 프롬프트처럼 변경 범위를 다시 묶어야 합니다.

첫 주에는 공부 목록보다 결과물 로그를 남깁니다

첫 주의 목표는 "HTML을 끝냈다"가 아닙니다. "내가 입력한 값이 화면에 보였다", "삭제 버튼이 작동했다", "새로고침해도 남았다"처럼 결과물 로그를 남기는 것입니다. 이 로그가 다음 공부 순서를 정합니다.

오늘 만든 것:
막힌 지점:
AI에게 준 요청:
브라우저에서 확인한 행동:
다음에 줄일 기능:

이 기록이 있으면 다음 프로젝트를 고를 때도 덜 흔들립니다. 할 일 목록이 작동했다면 다음은 메모장, 지출 기록, 운동 기록처럼 같은 구조를 가진 작은 앱으로 넘어가면 됩니다. 반대로 입력과 삭제도 불안정하다면 프레임워크를 바꾸기보다 같은 프로젝트에서 검증 루틴을 반복하는 편이 낫습니다.

오늘 할 일은 하나입니다. 큰 서비스를 상상하기 전에 만들 것, 오늘 뺄 것, 완성 기준을 세 줄로 적습니다. 그다음 AI에게 한 화면만 요청하고, 브라우저에서 직접 눌러 확인합니다. 첫 프로젝트는 커야 의미 있는 것이 아닙니다. 작게 끝나야 다음 프로젝트로 이어집니다.

참고 출처

• OpenAI Developers, Codex CLI
• OpenAI Developers, Codex CLI features
• MDN Web Docs, Web Storage API
• MDN Web Docs, Window localStorage
• MDN Web Docs, form element