23기 AI 온보딩 1주차, 6일 커리큘럼을 한 바퀴 돌고 배운 것

ALT

산과 나무를 배경으로 한 한국 포스터

📝 한줄 요약

개발자가 이해하는 문서로 개발자와 소통을 원활하게 하고 싶어 실제 MVP까지 직접 만들어보고자 참여한 AI 온보딩 스터디.

23기 AI 온보딩 스터디 1주차 6일 커리큘럼을 한 바퀴 돌며, 코딩을 모르는 비개발자가 학습메이트 세팅부터 MVP 첫 화면까지 실제로 만든 여정 정리.

Before: 다른 사람들의 개인 URL을 보며 “저건 어떻게 만드나” 부러워만 하던 상태
After: 내 사이트가 URL로 살아 있고, 실제 로펌 프로젝트의 PRD와 MVP 첫 화면까지 손에 잡히는 상태

👥 이런 분께 추천

• 23기 AI 온보딩 스터디를 따라가면서 “각 일차가 실제로 뭘 남기나” 궁금하신 분

• 비개발자인데 GitHub, Vercel, PRD, MVP 같은 단어에 주눅 드는 분

• 다음 기수에 참여하기 전에 “무엇을 준비해야 하나” 감을 잡고 싶은 분

🙋 내 스펙 & 환경

진행 방법

1일차. 학습메이트 만들기

내 옆에서 매번 같은 기준으로 일해 줄 AI 학습메이트가 필요했다. 이름을 모리라고 붙이고, 나를 제이리로 부르도록 정했다.

성격과 규칙은 4개 파일에 나눠 담았다.

• SOUL.md: 모리의 톤과 사고 방식

• USER.md: 내가 누구고 어떻게 대해줬으면 하는지

• AGENTS.md: 프로젝트 전체가 지켜야 할 약속

• CLAUDE.md: 위 세 문서로 들어가는 입구

이렇게 규칙을 문서에 적어두면, 매번 처음부터 설명하지 않아도 모리가 같은 기준으로 일한다.

ALT

컴퓨터에 있는 파일 목록의 스크린샷

💡 비개발자 팁: 규칙은 나중에 여러 문서로 흩어지기 쉽다.
처음에 파일 위치와 역할을 명확히 나눠두면, 새 규칙이 생겼을 때 어디에 넣을지 헤매지 않는다.

2일차. 4주 로드맵과 랜딩 페이지

주제를 뾰족하게 잡는 시간이었다. 나는 미국 로펌에서 초과근무 결재를 스프레드시트로 관리하는 상황을 자동화하고 싶었다. 최종 목표는 시스템을 내가 다 만드는 게 아니라, 개발자가 정확히 알아듣는 기초 자료(PRD, 유저 스토리, 와이어프레임, 작동 데모)로 전달하는 법을 배우는 것.

되고 싶은 모습을 한 줄로 적어봤다.

통역이 필요 없는 기획자

이걸 4주 틀(1주 기획 → 2주 상세계획 → 3주 제작 → 4주 회고·발표)에 앉혀 로드맵을 완성했고, 랜딩 페이지에 소개글로 붙였다.

ALT

한국어 웹사이트의 스크린샷

3일차. 내 사이트를 인터넷에 올리기 (배포)

이번 주에서 제일 놀란 지점이 여기였다.

다들 어떻게 나만의 링크를 만들어 공유하나 늘 궁금했다. 개인 URL로 자기 사이트를 공유하는 사람들을 보면서 “저건 진짜 어려운 거 아닌가” 지레짐작하고 있었다. 그런데 실제로 해보니 세 단계였다.

1. GitHub에 가입하고 저장소를 만들고 코드를 올림

2. Vercel에 GitHub 계정으로 로그인

3. 저장소를 고르고 클릭 한 번

끝. 프레임워크는 자동으로 감지된다. 로컬에서 수정하고 git push만 하면 사이트가 자동 업데이트된다.

ALT

항목 목록을 보여주는 화면의 스크린샷

다들 어떻게 나만의 링크를 만드는지 정말 궁금했는데 15분만에 vercel 연동으로 해결되었다.

4일차. 되돌릴 수 있는 안심 (커밋과 버전관리)

지금까지는 파일을 건드릴 때 “잘못 건드리면 어쩌지” 하며 조심스러웠는데, 이 날 처음으로 “실수해도 되겠네” 하는 안정감이 생겼다.

랜딩 페이지의 첫 문장을 일부러 망가뜨려 봤다. 그다음 git diff로 변경 부분을 확인하고, git restore 파일명으로 마지막 커밋 상태로 되돌렸다. 완벽하게 원래대로 돌아왔다.

커밋과 푸시의 차이도 이 날 명확해졌다.

“매번 푸시를 말해야 하나”라는 실질적 질문이 생겼고, AGENTS.md에 “학습일지 작성 후 자동으로 커밋·푸시”를 규칙으로 넣었다.

ALT

여러 줄의 코드를 보여주는 컴퓨터 화면의 스크린샷

5일차. 내 프로젝트 PRD 만들기

이번 주에서 가장 힘을 준 곳.

커리큘럼은 하루지만 나는 이틀을 붙잡고 있었다.

가이드가 워낙 잘 되어 있어서 스터디 과정 자체에서 무너진 순간은 없었다. 대신 내가 시간을 오래 쓴 지점은 PRD 작성 전 질문지 만들기였다.

기획이 정말 중요하다는 걸 알고 있어서, 변수를 최대한 고려한 질문지를 만들고 싶었다.

진행 순서:

1. AS-IS 분석: 현재 스프레드시트를 해부. NOTE (비고) 란에 여러 정보 7종이 뒤엉켜 있었다. 그리고 초과근무수당 지급의 근거가 볼드체(서식)으로만 되어 있었다. 서식은 데이터가 아니라서 다른 곳으로 옮기는 순간 근거가 통째로 사라진다.

2. AI가 45개 질문 초안 뽑기: 확인 안 된 변수를 모두 질문으로 만들었다.

3. 핵심 23개로 축약: 실제 유저에게 확인할 질문을 압축했다.

4. PRD 작성: 로드맵에서 정한 “뭘·왜·누구를 위해”는 그대로 가져오고, 빠진 것만 모리가 하나씩 물어봐 채웠다. 화면 3개(신청·승인·주간집계), 자동 계산 규칙, 감사 추적 규칙, 유저 스토리 6개와 인수조건까지 담겼다.

ALT

한국어 페이지 스크린샷

💡 인사이트

[2주차 핵심강의] 박정기 님 강의에서 “코드 짜기 전 55분을 문제정의에 써라”는 이야기와 “기술부채와 인지부채” 개념이 크게 남았다. 빨리 결과를 보는 대신 이해력까지 떨어뜨릴 수 있다는 것. PRD에 이틀을 쓴 게 낭비가 아니라 강의에서 이야기한 55분이라고 생각해 공을 많이 들였다.

6일차. 세부계획 세우고 MVP 첫 조각 만들기

PRD가 있으니 남은 건 실제로 화면을 그리는 일. 초보한테 가장 편한 도구를 찾아봤다. Lovable + Supabase 조합으로 결정. v0.dev, Bolt.new와 비교했을 때 Lovable이 Supabase를 자동 연결해줘서 초보에게 유리했다.

4주를 21일치 하루 걸음으로 잘라 위키에 저장한 뒤, 튜토리얼의 Day 1을 그대로 실행했다.

튜토리얼에서 진짜 인상적이었던 것

튜토리얼 안에 AI한테 던질 프롬프트가 통째로 들어 있었다.

그런데 그 프롬프트가 그냥 “만들어달라”가 아니라 뼈대만 요청하도록 미리 좁혀져 있었다.

예를 들어 이런 식.

아래 사이드바 구조로 앱 뼈대만 만들어라.
Attendance 페이지는 실제로 만들고, 그 안에 서브탭 3개
(Submit / Approvals / Weekly Summary)를 배치.

나머지 6개 메뉴는 지금은 만들지 말고,
Coming soon 껍데기 화면으로만 두어라.

디자인은 첨부한 참고 이미지(기존 로펌 시스템)의
상단 네비 스타일을 따라라.

“Attendance만 진짜로 만들고 나머지 6개는 Coming soon 껍데기로 두라”고 범위를 명시했기 때문에, 결과가 딱 오늘 필요한 만큼만 나왔다. 뜯어고칠 일이 없었다.

ALT

aspace라는 단어가 있는 페이지의 스크린샷

💡 비개발자 팁

초보가 AI에게 큰 걸 통째로 시키면 결과를 감당 못한다. “이번엔 이만큼만”이라고 범위를 좁혀 요청하는 게 초보의 안전벨트다. 튜토리얼의 프롬프트가 이걸 이미 하고 있다는 걸 그대로 따라만 해도 습관이 붙는다.

개인작업 1 : 브라우저 잠금은 진짜 잠금이 아니었다

스터디 밖에서 개인적으로 학습일지 페이지를 만들다가 겪은 일. 나만 보고 싶어서 비밀번호를 걸었는데, 다음 날 확인해보니 제대로 된 잠금이 아니었다.

ALT

한국사이트 스크린샷

어떻게 알게 됐나

주소창 앞에 view-source:만 붙였다. 그러면 브라우저가 서버에서 받은 원본 HTML을 그대로 보여준다. 학습일지 내용이 원본 안에 다 들어 있었다. display: none으로 화면에만 안 보이게 가려져 있을 뿐이었다.

View Page Source를 누르면 다 보인다는 점..

ALT

한국어 웹사이트의 스크린샷

왜 그런가

세부 페이지 코드가 이런 구조였다.

<div id="contentWrapper" style="display: none;">
  ...학습일지 원문...
</div>

내용이 이미 브라우저에 다 도착한 뒤, 자바스크립트가 그 위에 커튼을 치는 방식.

커튼을 걷어내는 도구(view-source, curl)를 가진 사람에게는 그냥 보였다.

ALT

한국사이트 스크린샷

정적 사이트에서 진짜 잠금 3가지

💡 비개발자 팁

“비밀번호 입력화면”과 “실제 암호화”는 다르다. 화면 표시 여부만 바꾸는 CSS(display: none)는 보안이 아니라 스타일이다.
만약 정말 민감한 정보를 이 방식으로 가려두고 안심했으면 큰일 났을 것.

🛠 사용한 도구

배운 점

💡 핵심 교훈

1. 사이트 배포는 생각보다 훨씬 쉽다

Vercel 원클릭 배포를 진작 알았다면 지난 프로젝트도 다 URL이 있었을 것이다. 어렵다고 지레짐작한 게 가장 큰 걸림돌이었다.

2. 코드 짜기 전 기획(문제정의)에 공을 들인다

박정기 님 강의에서 배운 것. 빨리 결과를 보려고 AI에 통째로 시키면 기술부채와 인지부채가 같이 쌓인다. 나 자신의 이해력이 떨어지는 게 진짜 위험.

3. AI에게 시킬 때는 범위를 미리 좁힌다

“만들어달라”가 아니라 “Attendance만 만들고 나머지는 Coming soon 껍데기로 두라.” 초보의 안전벨트.

4. 암호화는 생각보다 어렵다. 고도화 작업이 필요하다

view-source로 원본이 그대로 보이면 그건 커튼이지 문이 아니다. 정적 사이트에서 진짜 잠금은 세 가지 중에서 골라야 한다.

📚 새로 배운 개념

적용할 점

🎯 결과

📋 복붙 가능한 프롬프트 (Lovable Day 1용)

내가 실제로 튜토리얼 방식으로 던진 뼈대 요청 프롬프트다.

[역할]
당신은 웹앱 뼈대를 만들어주는 도우미다.

[요청]
아래 구조로 앱 뼈대만 만들어라.

- 상단 네비에 메뉴 7개 (Attendance / A / B / C / D / E / F)
- Attendance 페이지만 실제로 구현
  - 서브탭 3개: Submit / Approvals / Weekly Summary
  - 각 서브탭은 지금은 빈 화면 + 제목만
- 나머지 6개 메뉴는 클릭 시 "Coming soon" 표시만

[디자인 참고]
첨부한 이미지의 상단 네비 스타일을 따라라.
색상과 폰트도 이미지를 참고.

[하지 말 것]
- 백엔드 연결 아직 하지 말 것
- 나머지 6개 메뉴에 아무 기능 넣지 말 것

🔜 다음 계획

1. 학습일지 진짜 잠금 방식 결정 (사이트에서 빼기 / Vercel Pro / staticrypt 중)

2. Lovable Day 2 이후 계속 진행. 껍데기에서 실제 신청 흐름 붙이기.

3. 클라이언트 회신 받으면 계산 규칙 확정 및 과거 데이터로 검증.

4. 매번 만들기 전에 “55분 문제정의”를 실제로 지키기.

솔직한 소감

이번 주에서 가장 감정이 오르내린 순간이 세 개 있었다.

첫 번째는 Vercel. 다들 개인 URL을 어떻게 만드나 늘 궁금했는데 클릭 몇 번으로 끝나는 걸 보고 허무했다. 그런데 그 허무함이 나쁜 감정은 아니었다. “이렇게 쉬웠다니"라는 허탈함?

두 번째는 PRD. 45개 질문을 뽑고 23개로 줄이는 과정에서 이틀이 지나갔다. 커리큘럼 하루짜리 진도를 이틀로 늘려서 스스로가 뒤처지는 것 같기도 했다.
그런데 박정기 님 강의에서 “코드 짜기 전 55분”을 듣고, 내가 쓴 이틀이 그 55분이었다는 걸 알게 됐다. 기술부채와 인지부채라는 표현이 특히 오래 남았다.

세 번째는 브라우저 암호화. “학습일지 보안 강화 성공”이라고 뿌듯해했던 게 다음 날 반쪽짜리였다는 걸 알았을 때 살짝 무안했다. 그래도 지금 알게 된 게 다행. 진짜 민감한 정보를 이렇게 가려두고 안심했으면 큰일 났을 것이다.

한 주를 돌아보니, 스터디가 잘 짜여 있어서 커리큘럼 자체에서 무너지진 않았다. 대신 옆길에서 뒤집히고, PRD에서 오래 붙잡고, 배포에서 허무해하는 감정들이 이번 주의 진짜 배움이었다.

개발자와 소통에서 통역이 필요 없는 기획자까지는 아직 멀지만, 다음 주에는 두 걸음 더 갈 수 있을 것 같다.