따로 정리 안 해도 포트폴리오가 저절로 채워진다 — 작업만 하면 사이트에 쌓이는 구조를 만들었다

AI로 30일 챌린지 커리큘럼을 만들며

📝 한줄 요약

포트폴리오·블로그, 따로 업데이트하기 귀찮아서 늘 밀리잖아요. 저는 아예 "작업하면 사이트가 저절로 채워지는" 구조를 만들어 뒀습니다. 이번에 AI로 30일짜리 강의 챌린지 커리큘럼을 만들었더니, 손 하나 더 안 대고 포트폴리오 사이트에 강의 자료로 올라갔어요.

바쁘시면 이것만 읽어도 돼요:

• 진실(원본)은 한 곳에만 두고, 사이트는 그걸 거울처럼 비추게 설계했다.
• 그래서 "커리큘럼을 만든 작업" 자체가 "포트폴리오를 업데이트한 것"이 된다. 정리 노동이 사라진다.
• 발행 여부는 파일에 스위치 하나(공개 켜기/끄기)로 정한다. 코드는 안 건드린다.
• 이번 30일 커리큘럼은 그 구조가 실제로 도는 걸 보여준 사례. Day 파일을 만들고 스위치를 켜자 사이트 강의 탭에 저절로 등장했다.
• 온보딩 강의는 매 기수 반복되니까, 한 번 쌓은 커리큘럼이 계속 누적된다. 일할수록 포트폴리오가 저절로 두꺼워지는 구조.

🎯 이런 분들께 도움돼요

• 포트폴리오·블로그 업데이트가 늘 밀려서 방치 중인 분
• 강의·스터디 커리큘럼을 만드는 강사·스터디장
• 여기저기 흩어진 작업물을 한 사이트로 모으고 싶은 분

😫 문제 상황 (Before)

저는 강의를 하고, 스터디를 운영하고, 이런저런 프로젝트를 벌입니다. 그런데 그렇게 만든 결과물이 자꾸 여기저기 흩어져요. 폴더 어딘가, 노트 어딘가에 쌓이기만 하고.

그리고 그걸 "포트폴리오"로 보여주려면 또 따로 정리를 해야 합니다. 사이트에 옮겨 붙이고, 소개 글 쓰고, 목록 업데이트하고. 이게 너무 귀찮아서 대부분 안 하게 돼요. 그래서 정작 열심히 일해도 밖에서 보면 아무것도 없는 상태가 됩니다.

이번에도 딱 그 상황이 겹쳐서 터졌습니다.

• 외부 계기: 제가 운영하는 온보딩 스터디의 방향이 바뀌면서, 기존에 쓰던 "바이브 코딩(AI로 코딩하기) 입문" 강의를 따로 챌린지로 분리해야 했어요.
• 진짜 문제: 그런데 기존 강의를 오랜만에 열어 보니, 쉽게 쓴다고 썼는데도 초보자가 보기엔 정신이 없더라고요. git이니 오픈소스니 하는 도구를 욕심내서 첫 주에 몰아넣은 탓에, "빠르게 뭔가 만드는 재미"라는 목적과 오히려 정반대로 가 있었습니다.
• 기회: 이왕 손대는 김에 ① 챌린지 ② 강의 포트폴리오 ③ 다른 곳에서도 쓸 4주 커리큘럼, 이 세 개를 한 번에 정리하고 싶었어요.

정리하자면 "그냥 자료 옮기기"가 아니라 아예 다시 설계해야 하는 일이었습니다. 그리고 다 만든 다음, 그걸 또 포트폴리오 사이트에 올리는 노동이 기다리고 있었죠. 그 노동을 없애는 게 이 이야기의 핵심입니다.

🛠️ 사용한 도구

• 도구: Claude Code (터미널에서 AI와 대화하며 파일을 만들고 고치는 도구). 강의를 실제로 따라 할 사람들을 위해서는, 코딩이 필요 없는 Claude Cowork를 기준으로 잡았습니다.
• 모델: Claude Opus
• 특이사항: 이미 "작업 폴더를 거울처럼 비추는 사이트"를 만들어 둔 상태였고, 이번 작업은 그 구조 위에서 진행했습니다.

🔧 작업 과정

흩어진 강의의 "진짜 원본"부터 찾기 — AI가 기록을 뒤져 줬다

시작부터 막혔습니다. 예전에 강의할 때 쓴 사이트를 다시 열었는데, 내용이 뭔가 달랐어요. 나중에 제가 메뉴를 추가하면서 어느샌가 바뀐 것 같은데, 정작 "그때 실제로 강의에 쓴 버전"이 어디 있는지 못 찾겠더라고요.

얼마전에 사이트를 확인했는데 실제 내가 강의할때 사용했던 사이트랑 좀 내용이 다른거 같더라고;;
대체 강의때 사용했던 버전이 어디있는지 못찾겠더라고 그걸 기준으로 정리해야하는데 말이야

여기서 처음 "오!" 했습니다. AI한테 강의 영상 내용을 기준으로 알려주고 "혹시 이전 버전이나 기록을 뒤져 볼래?"라고 했더니, 저장된 히스토리를 뒤져서 "이게 실제 강의 때 쓴 원본이고, 이건 나중에 메뉴를 추가하며 바뀐 버전"이라고 짚어 줬어요.

비개발자 입장에선 이게 꽤 신기했습니다. 저 혼자였으면 "어디 갔지…" 하고 한참 헤맸을 텐데, AI가 과거 기록을 대신 뒤져서 원본을 찾아 준 거죠. 여기서부터 정리를 시작할 수 있었습니다.

"도구 먼저"를 "만드는 재미 먼저"로 뒤집다

원본을 찾아 놓고 보니, 구조 자체가 문제였습니다. AI와 대화하며 커리큘럼을 하나씩 짚다가 이런 자각이 왔어요.

기존에 작성한건 오픈소스와 깃을 사용하게 하고 싶은 욕심에 이 내용을 첫주에 넣어서
어쩌면 첫주에 가장 빠르게 바이브 코딩을 할수 있게 만드는 목적과도 맞지 않은거 같아.

초보자용 강의의 황금률은 "빠른 첫 성취"인데, 제 커리큘럼은 그 성취가 한참 뒤에나 나오게 짜여 있었던 거예요. AI와 주거니 받거니 하다 보니 제 생각의 모순이 눈에 보였습니다.

그래서 순서를 통째로 뒤집었습니다. "만드는 재미 먼저, 어려운 도구는 필요해지는 순간에 하나씩." git·오픈소스를 빼는 게 아니라, "그게 정말 필요해지는 시점"으로 자리를 옮긴 거죠.

매일 뭔가가 쌓이는 "누적형" 프로젝트로

이번 설계에서 가장 공들인 부분입니다. 챌린지의 매 미션이 버려지는 연습이 아니라, 하나의 최종물로 쌓이게 만들고 싶었어요.

과정마다 실용적인 결과물을 하나씩 만들고 그 결과물들을 합쳐서 최종적으로
스터디원에게 도움이 되는 걸로 만들고 싶어. 예를 들어 이런식이지
1.내 학습메이트만들기  2.개념 배우기 페이지·용어사전  3.나만의 학습사이트 만들기  4.깃으로 버전관리

흐름은 이렇게 잡혔습니다. 내 학습 메이트(나를 도와줄 AI 도우미) 만들기 → 첫 페이지 만들기 → 개념·용어 조각 쌓기 → 그것들을 하나의 학습 사이트로 통합. 30일이 끝나면 흩어진 연습물이 아니라 "내 학습 본진" 하나가 손에 남습니다.

첫 주의 딜레마 — 몰아서 vs 매일 조금씩

여기서 한 번 크게 막혔습니다. 제가 운영하는 커뮤니티는 스케줄이 특이해요. 첫 주에 한 달 치를 몰아서 보여주고, 이후에 하나씩 구현하는 방식이거든요. 그런데 챌린지는 원래 "매일 조금씩 꾸준히"가 본질이잖아요. 둘이 정면으로 부딪혔습니다.

첫 주에 몰아넣자니 다른 스터디까지 들으며 너무 빡세고, 안 몰자니 다른 스터디를 따라갈 기본기가 안 잡히고.

해결책은 이랬습니다. 첫 주에는 "최소한의 바이브 코딩 기반"만 다지되, 그 과정에서도 눈에 보이는 간단한 결과물이 나오게 구성했어요. 첫 주부터 다른 스터디를 따라갈 최소 역량은 갖추면서, 동시에 작은 성취감도 얻게. 무거운 도구는 뒤로 미루고요. 아까 "만드는 재미 먼저"로 순서를 뒤집은 게, 이 딜레마까지 같이 풀어 준 셈입니다.

그리고 — 아무것도 안 옮겼는데 사이트에 올라갔다

여기가 이 글의 진짜 핵심입니다.

보통은 커리큘럼을 다 만든 다음, 그걸 포트폴리오 사이트에 또 옮겨 붙이는 작업이 남습니다. 저는 그 노동이 싫어서, 미리 사이트를 이렇게 만들어 뒀어요.

진실(원본)은 제 작업 폴더 한 곳에만 둡니다. 사이트는 그 폴더를 거울처럼 비추기만 합니다.

그래서 이번에도 커리큘럼을 만든 곳은 그냥 제 평소 작업 폴더였는데, 거기에 Day 파일들을 만들고 "공개" 스위치 하나를 켜자 — 사이트의 강의 탭에 강의 카드가 저절로 생겨났습니다. 옮겨 붙이기도, 목록 수정도, 코드 손대는 것도 없었어요.

원리는 단순합니다.

• 폴더 하나 = 강의 하나. 폴더를 만들면 강의가 하나 생긴 것.
• 각 파일에 "공개: 켜기/끄기" 스위치가 있어서, 켜야만 세상에 보입니다. 아직 다듬는 중이면 꺼 두면 되고요.
• 개발용 메모는 특정 표시 뒤에 적어 두면 방문자에겐 안 보입니다. "나만 볼 메모"와 "남에게 보일 소개"가 한 파일 안에서 자동으로 갈립니다.

결국 "커리큘럼을 만드는 작업"이 곧 "포트폴리오를 업데이트하는 작업"이 됩니다. 두 개가 하나로 합쳐지는 거예요.

✅ 결과 (After)

Before vs After

결과물

• 30일 바이브 코딩 챌린지 커리큘럼 — 하루 하나씩, 결과물이 누적되는 6주 구성
• 같은 내용의 4주 강의 커리큘럼 — 강사 포트폴리오·타 강의용
• 둘 다 별도 정리 노동 없이 사이트에 자동 반영

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. "결과물이 곧 콘텐츠가 되게" 구조를 먼저 짜라. 이게 제일 큰 교훈입니다. 만든 걸 나중에 정리하는 게 아니라, 작업하는 곳과 보여지는 곳을 처음부터 연결해 두면 "정리"라는 노동 자체가 사라집니다. 폴더 구조를 곧 사이트 구조로 설계해 두는 거죠.
2. AI와 대화하며 내 생각의 모순을 비춰 보라. "도구를 첫 주에 몰아넣은 게 목적과 정반대였다"는 걸, 혼자선 몰랐는데 AI와 주고받다가 깨달았습니다. AI는 답을 주기도 하지만, 내 생각을 되비추는 거울로도 좋습니다.
3. 버전이 꼬이면 AI에게 기록을 뒤지게 하라. "그때 쓴 버전이 어디 갔지?" 싶을 때, 비개발자도 AI를 시켜 과거 기록을 되짚을 수 있습니다.

이렇게 하면 안 돼요

1. 욕심내서 어려운 걸 앞에 몰지 마세요. 초보자용이라면 "빠른 첫 성취"가 먼저입니다. 좋은 도구라도 필요해지는 순간에 하나씩 꺼내야 따라옵니다.
2. "만든 다음에 정리하자"고 미루지 마세요. 그 정리는 대부분 영원히 안 합니다. 구조로 미리 해결해 두는 편이 낫습니다.

🌍 다른 업무에 적용한다면?

이 "거울 구조"는 강의에만 쓰이는 게 아닙니다. 블로그 글, 프로젝트 소개, 작업 일지 — 뭐든 "원본은 한 곳, 사이트는 그걸 비추기만" 하게 만들면, 일하는 것만으로 자기 브랜딩이 쌓입니다. 마케터라면 캠페인 회고가, 디자이너라면 작업물이, 기획자라면 문서가 저절로 포트폴리오가 되는 식이죠.

🚀 앞으로의 계획

• 게임처럼 즐기는 챌린지로: 이 30일 커리큘럼을 게이미피케이션(게임 요소를 입혀 재미있게 만드는 것) 방식과 붙여서, 매일 체크하며 성취감을 느끼는 형태로 발전시킬 계획입니다.
• "자동 반영" 구조를 전방위로 확장: 지금은 강의·사례글 위주지만, 앞으로 제가 벌이는 모든 프로젝트를 같은 거울 구조에 태워서, 무엇을 하든 자동으로 한 사이트에 쌓이게 만들 생각입니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 초보자용 커리큘럼을 "빠른 첫 성취" 순서로 재설계하기

지금 이 [강의/커리큘럼]을 초보자 관점에서 검토해줘. 특히 "빠른 첫 성취"가 언제 나오는지 봐줘 — 어려운 도구나 개념을 앞쪽에 몰아넣어서, 정작 초보자가 부담 없이 뭔가 만드는 재미를 늦게 느끼게 되어 있진 않은지. 그렇다면 "만드는 재미 먼저, 어려운 도구는 필요해지는 순간으로" 순서를 뒤집는 안을 제안해줘. [강의 주제]는 본인 상황에 맞게 바꾸세요.

프롬프트 2: 매 미션이 최종물로 쌓이는 "누적형" 흐름 설계하기

[기간, 예: 30일] 동안 하루 하나씩 진행하는 챌린지를 설계해줘. 조건: 매 미션이 버려지는 연습이 아니라, 결과물이 하나씩 누적돼서 마지막엔 [최종 결과물, 예: 나만의 학습 사이트] 하나로 합쳐지게 만들어줘. 각 미션이 앞 미션의 결과물 위에 쌓이는 순서로 배치해줘. [ ] 안은 본인 상황에 맞게 바꾸세요.

📝 한줄 요약

코딩을 모르는 제가 AI(Claude Code)랑 함께, 공부한 게 하나도 안 버려지고 저절로 쌓이는 학습 사이트 템플릿을 만들었어요. 마크다운 글만 쓰면 위키로 쌓이고, 프로젝트는 자동으로 포트폴리오가 되고, 4주 뒤엔 그게 전자책 한 권으로 묶여요.

바쁘시면 이것만 읽어도 돼요:

• 스터디 수강생이 30일 동안 배운 게 정리 안 해도 실시간으로 쌓이는 사이트가 목표였어요
• 매일 쓴 학습일지 → 사례글 → 위키 → 포트폴리오 → 전자책까지 자동으로 이어져요
• 비개발자는 마크다운 글만 쓰고, 레이아웃·목차·배지는 사이트가 알아서 처리해요
• AI가 처음 만든 걸 그대로 안 받고 3번 뒤엎으며 더 좋은 구조(위키 3단)로 다듬었어요
• 마지막에 "전자책으로 묶자"는 아이디어를 덧붙였더니, 흩어진 기록이 물성 있는 결과물 하나로 응축됐어요

🎯 이런 분들께 도움돼요

• 스터디·강의를 운영하는데, 수강생 결과물이 실용적으로 남았으면 하는 분
• 공부하거나 작업한 게 자꾸 흩어지고 "정리할 엄두가 안 나는" 분
• AI로 뭔가 만들고 싶은데 코딩이 막막한 비개발자
• 진행 과정이 저절로 포트폴리오가 됐으면 하는 분

😫 문제 상황 (Before)

저는 곧 스터디(지피터스 23기)를 여는데, 수강생이 30일 챌린지를 하며 배운 게 실용적으로 손에 남았으면 했어요.

그런데 보통은 이래요. 열심히 공부하고 프로젝트도 만드는데, 그 과정이 여기저기 흩어져요. 나중에 "포트폴리오 정리해야지", "배운 거 정리해야지" 하면 그게 또 큰 일이라 미루게 되고요. 하는 과정은 분명 값진데, 정리를 따로 안 하면 다 날아가는 느낌이었어요.

제가 진짜 원했던 건 이거예요.

내가 하는 모든 과정이 하나도 낭비되지 않고, 일부러 정리하지 않아도 실시간으로 차곡차곡 쌓여서, 그대로 포트폴리오가 되고 결과물이 되는 것.

사실 이건 제 개인 사이트에도 만들고 싶던 뷰였어요. 프로젝트를 진행하면 그게 알아서 포트폴리오가 되는 것. 그걸 이번에 수강생용 학습 사이트로 먼저 구현하게 된 거죠.

🛠️ 사용한 도구

• 도구: Claude Code (Opus)
• 결과물: Astro 정적 사이트 템플릿 (수강생이 복사해서 자기 걸로 씀)
• 특이사항: 저는 코딩을 못 해요. 전부 대화로 만들었어요.

🔧 작업 과정

그냥 "만들어줘"가 아니라, 내가 원하는 흐름부터 설명했어요

먼저 제가 원하는 그림을 AI에게 설명하고, 이미 잘 돌아가는 제 기존 사이트를 참고하게 했어요.

course-renewal/docs/03 읽고 정적 템플릿부터 만들자

AI는 제 설계 문서를 읽고, 제 기존 사이트(아루나 사이트) 구조까지 살펴본 뒤에 뼈대를 잡았어요. 마크다운 파일을 폴더에 넣으면 자동으로 페이지가 되는 구조로요. 수강생은 글만 쓰고, 화면 디자인은 신경 안 써도 되게.

여기서 좋았던 건, AI가 제로에서 상상으로 만든 게 아니라 이미 검증된 제 사이트의 방식을 가져와서 안전하게 옮겼다는 거예요.

AI가 만든 걸 그대로 안 받고, "이건 위키처럼 됐으면 좋겠어"라고 다시 요청했어요

처음엔 배운 자료들이 그냥 카드로 나왔어요. 나쁘진 않았는데, 제가 원한 느낌이 아니었어요.

사례 글이나 학습 자료는 위키 같은 형식으로 나오길 바라거든.
공부를 하면 할수록 학습위키로 쌓이는 거고, 최종적으로 회고 챌린지를 하면서 전자책으로 만들어지는

이 한 마디로 방향이 확 바뀌었어요. AI가 태그로 묶는 방식을 제안했는데, 그것도 제가 "중복되고 불편해 보인다"고 하니까, 결국 왼쪽에 목록 / 가운데 본문 / 오른쪽에 세부 목차가 있는 진짜 위키 형태로 다시 만들었어요.

그리고 여기서 제일 마음에 든 건, 글마다 "몇 주차인지, 어떤 종류인지(개념/사례/회고)"만 적으면 사이트가 알아서 주차별로 정리해준다는 거였어요. 공부할수록 왼쪽 목록이 주르륵 길어지면서 "아, 내가 이만큼 했구나"가 눈에 보이는 거죠.

한 번에 원하는 게 안 나와도, 다시 요청하는 것 자체가 협업이더라고요. 오히려 뒤엎으면서 더 좋은 구조가 나왔어요.

"전자책은 뷰어 말고, 진짜 다운로드가 됐으면 좋겠어"

작업하다 문득 아이디어가 떠올랐어요. 위키에 쌓인 걸 그냥 화면으로 보는 것도 좋지만, 한 권으로 딱 묶여서 손에 잡히면 훨씬 뿌듯하겠다 싶었어요.

전자책은 뷰어 말고 실제로 다운로드 받을 수 있었으면 좋겠어.
그게 더 훨씬 뿌듯할 거 같거든.

그래서 4주 동안 쌓인 위키를 순서대로 묶어 전자책 파일로 내려받는 기능을 넣었어요. 로드맵이 책의 서문이 되고, 주차별 기록이 챕터가 되고요. 처음부터 일관되게 쌓았으니 순서대로 묶기만 하면 책이 되는 거예요. 억지로 짜맞출 필요 없이.

이게 마지막에 덧붙인 건데, 개인적으로 제일 잘한 것 같아요. 흩어진 기록이 물성 있는 결과물 하나로 응축되는 느낌이거든요.

빌드는 되는데 화면만 깨지는, 숨은 버그도 같이 잡았어요

중간에 위키 글 페이지가 전부 에러가 났어요. 이상한 건, 배포용으로 만들 때는 멀쩡한데 미리보기에서만 깨지는 거예요.

AI가 원인을 찾아줬어요. 파일 이름을 한글로 지으면 인터넷 주소로 바뀔 때 깨진다는 거였어요. 그래서 파일 이름은 영어로, 제목만 한글로 쓰게 규칙을 정하고, 그걸 안내문에도 박아놨어요. 나중에 수강생이 똑같이 안 겪게요.

혼자였으면 "왜 안 되지" 하고 한참 헤맸을 텐데, 원인부터 해결까지 금방이었어요.

홈 화면도 "1주차에 직접 만들 랜딩페이지" 자리로 바꿨어요

처음엔 홈이 제 개인 사이트랑 거의 똑같았어요. 근데 생각해보니, 수강생은 1주차에 스스로를 소개하는 랜딩페이지를 만들 예정이었거든요.

1주차에 아이데이션·로드맵 하면서 랜딩페이지를 만들 예정이거든.
그 내용이 홈에 들어가야 해.

그래서 홈을 수강생이 직접 쓰는 소개 글이 들어가는 자리로 바꿨어요. 아직 안 썼으면 "1주차에 여기를 채워요" 안내가 뜨고, 채우면 그게 홈이 되는 식으로요.

✅ 결과 (After)

Before vs After

결과물

수강생이 복사해서 바로 쓸 수 있는 학습 사이트 템플릿. 글을 쓸수록 위키가 자라고, 프로젝트가 포트폴리오가 되고, 4주 뒤엔 전자책이 나와요.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 내가 원하는 흐름을 먼저 설명했어요. "만들어줘"가 아니라 "내가 원하는 그림은 이거야"를 말하니 AI가 훨씬 정확하게 잡았어요.
2. 이미 잘 되는 걸 참고하게 했어요. 제 기존 사이트를 보게 하니, 상상으로 만든 게 아니라 검증된 방식을 옮겨줬어요.
3. 한 번에 안 나와도 다시 요청했어요. 카드→태그→위키로 뒤엎으면서 더 좋은 구조가 나왔어요. 다시 요청하는 게 곧 협업이에요.

이렇게 하면 안 돼요

1. AI가 처음 준 걸 그냥 받지 마세요. "이게 맞나?" 싶으면 그 느낌을 그대로 말하면 돼요. 그게 더 좋은 결과로 이어져요.
2. 작은 규칙(파일 이름 등)도 놓치지 마세요. 한글 파일명 하나 때문에 사이트가 깨졌어요. 사소해 보여도 AI한테 원인을 물으면 금방 풀려요.

🌍 다른 업무에 적용한다면?

이 "과정이 저절로 결과가 되는" 구조는 학습 사이트에만 쓸 게 아니에요. 프로젝트 기록, 업무 일지, 취미 기록 등 꾸준히 쌓이는 무엇이든 같은 방식으로 만들 수 있어요. 매일 조금씩 남기면 그게 저절로 정리되고, 나중에 한 권으로 묶이는 식으로요.

🚀 앞으로의 계획

이 방식을 제 개인 사이트에도 적용하려고 해요. 사실 원래 제가 원했던 최종 뷰가 이거였거든요 — 프로젝트를 진행하면 그게 실시간으로 포트폴리오가 되고, 전자책으로까지 완성되는 것. 수강생용을 먼저 만들었으니, 이제 제 걸로도 가져오려고요.

📋 재사용 가능한 프롬프트

프롬프트 1: 내가 원하는 흐름부터 설명하고 만들기 시작할 때

나는 [만들고 싶은 것]을 만들고 싶어. 근데 바로 만들지 말고, 내가 원하는 흐름을 먼저 설명할게: [원하는 그림을 자연어로]. 그리고 이미 잘 되는 예시가 있으면 그걸 참고해: [참고할 것 경로/링크]. 이걸 바탕으로 뼈대부터 잡아줘. 내가 코딩을 몰라도 되게, 최대한 단순하게.

프롬프트 2: AI가 만든 게 맘에 안 들 때 (다시 요청)

지금 만든 건 [어떤 점]이 내가 원한 느낌이 아니야. 내가 바라는 건 [원하는 형태]야. 이 방향으로 다시 만들어줘. 여러 방법이 있으면 각각 뭐가 좋은지 알려주고 추천해줘.

프롬프트 3: 원인 모를 에러가 났을 때

[상황]에서 이런 문제가 났어: [증상]. 바로 고치기 전에, 원인이 뭔지부터 진단해줘. 그리고 다음에 같은 문제 안 겪게 하는 방법도 알려줘.

아루나의 다른 프로젝트가 궁금하다면 → litt.ly/aluna

📝 한줄 요약

폴더 구조가 잘못돼서 시스템이 복잡해졌다고 믿고 전면 개편을 하려 했는데, AI와 하루 종일 대화한 끝에 원인이 git을 백업 용도로 오용한 것임을 찾았다. 도구를 원래 용도로 되돌리자 그동안 덧붙였던 규칙들이 같이 사라졌다.

바쁘시면 이것만 읽어도 돼요:

• 겉으로 보이는 폴더 구조는 단순한데 머릿속에서 시스템이 안 잡혔다. 원인은 폴더가 아니라 그걸 감싸고 있던 git 구조였다
• 구글드라이브 동기화가 git과 충돌 → 백업 포기 → 대체재로 git을 백업에 씀. 여기서부터 꼬였다
• 갈아엎어야 하는 줄 알았던 최상위 폴더 구조는 이미 업계에서 쓰는 방식에 가까웠다. 안 바꿔도 됐다
• git 오용을 걷어내자, 그 이상한 구조를 유지하려고 누덕누덕 붙였던 예외와 규칙이 같이 사라졌다
• 규칙이 자꾸 늘어나는 건 해결이 아니라 증상이었다
• 아직 다 정리되진 않았다. 하지만 원인이 뭔지, 뭘 해야 할지 가닥은 잡혔다

🎯 이런 분들께 도움돼요

• 바이브 코딩하다가 git을 백업인 줄 알고 쓰고 있는 비개발자
• AI한테 시스템 관리를 맡기고 싶은데 "AI가 뭘 놓치는지 내가 모른다"가 불안한 사람

😫 문제 상황 (Before)

시작은 백업이었다.

원래는 구글드라이브 실시간 동기화로 작업 폴더를 통째로 백업하고 있었다. 그런데 이게 git과 맞지 않았다. 동기화가 돌면서 git 내부 파일을 건드려 문제가 생겼다. 그래서 드라이브 백업을 포기했다.

문제는 그다음이다. 백업 수단이 사라지자, git으로 백업을 하기 시작했다.

git은 원래 코드 되돌리기와 배포용 도구지 백업 도구가 아니다. 하지만 당시엔 "GitHub에 올려두면 안전하다"는 감각이 있었고, 그래서 굳이 git을 쓸 필요 없는 폴더까지 전부 레포로 만들어 올렸다. 문서만 있는 폴더, 개인 기록, 실험하다 만 것까지.

여기서부터 구조가 이상해졌다.

• 백업하려고 레포를 만들다 보니 레포 개수가 계속 늘었다
• 폴더를 옮기면 그 안의 git이 따라다니면서 꼬였다. 큰 프로젝트 폴더 안에 작은 프로젝트를 넣으면 git 안에 git이 들어가는 상태가 됐다
• 이 이상한 상태를 유지하려고 예외와 규칙을 계속 덧붙였다. "이 폴더는 이렇게, 저 폴더는 저렇게"

그러다 어느 순간 내 시스템인데 내가 파악을 못 하게 됐다.

겉으로 보이는 폴더는 단순했다. 최상위에 열 개 남짓. 그런데 그걸 감싸고 있는 git 구조가 이상하니까, 머릿속에서 전체 그림이 두루뭉실하게만 잡혔다. 그래서 폴더를 옮기는 게 무서워졌다. 원래 내 방식은 "작업하다 보면 이 폴더는 저쪽으로 옮기는 게 낫겠다" 싶으면 옮기는 건데, 깨질까 봐 못 옮겼다.

시스템이 나를 못 움직이게 만들고 있었다.

이 상태로는 안 되겠다 싶어서 "폴더 구조를 대대적으로 갈아엎자"고 마음먹고 AI와 대화를 시작했다.

🛠️ 사용한 도구

• 도구: Claude Code
• 모델: Claude Opus 5 (1M) / Claude Fable 5 — 교차 검증에 두 모델을 번갈아 사용
• 특이사항: 조사·감사에 서브에이전트를 병렬로 여러 개 돌림

🔧 작업 과정

"왜 자꾸 깃을 빼먹니?" — 세 번 말하고서야 확인된 문제

처음에 나는 이중 git 문제를 걱정했다. 큰 프로젝트 폴더 안에 다른 프로젝트를 넣으면 git이 겹치는 것 아니냐고.

AI는 문제없다고 했다. 두 번을 물었는데 두 번 다 괜찮다고 했다. 세 번째로 콕 집어서 다시 물었다.

지금 자꾸 깃이 문제가 없다고 하는데, 내가 생각하기에는 이런 문제가 있는데.
정말 그게 문제가 안 되는 게 맞아?

그제야 AI가 실제로 폴더 트리를 전부 스캔했고, 이중 git이 4곳 실재한다는 걸 찾아냈다. 내 직감이 맞았던 것이다.

이때 알았다. AI는 내가 콕 집어 말하지 않으면 넘어간다. 그리고 여기서 더 큰 문제로 이어졌다.

"내가 감지 못한 문제는, AI도 못 고친다"

이게 이날의 진짜 발견이었다.

내가 문제를 감지하지 못하면 애초에 네가 문제인지도 몰라서, 그걸 감지할 스크립트조차
네가 만들지 못한다는 거야. 개발에 대해 전혀 전문지식도 없는 사람이고, 파일을 하나하나
다 찾아보고 아는 사람도 아닌데. 내가 감지하지 못한 문제 너는 고치지도 못해.
그러다 보면 계속 구멍이 생기는데, 그 구멍을 감지하질 못하니까 구멍이 있는 줄도 몰라.

AI에게 시스템 관리를 맡길 때의 근본 한계다. AI는 시킨 건 잘한다. 그런데 "시켜야 할 게 뭔지"를 내가 모르면 아무 일도 안 일어난다. 그러면 구멍은 계속 생기는데 아무도 모른다.

AI의 첫 반응은 "감지 장치를 만들자"였다. 점검 스크립트를 만들고, 정기 감사를 돌리고, 경고를 띄우자는 것. 나는 그게 더 걱정됐다. 그럼 내가 파악 못 하는 층이 하나 더 늘어나는 거니까.

규칙을 더 만드는 게 아니라, 종류를 줄이는 것

여기서 방향이 바뀌었다.

어떤 시스템이든 파악하기 어려운 건 좀 별로인 것 같아. 물건이 아주 많아도 제대로 된
원칙으로 정리돼 있으면 파악이 가능하거든. 근데 애초에 정리를 잘하려면 정리할 물건
자체를 제한해야 돼. 미니멀라이프랑 비슷한 거지.

그리고 내가 예전에 쓴 글 하나를 AI에게 읽혔다.

그런데 미니멀위키 프로젝트 한번 확인해 봐. 내가 말한 걸 조금 더 이해할 수 있을 거야.

6월에 내가 쓴 「당신의 위키가 계속 망하는 이유」라는 글이었다. 거기엔 이미 이렇게 써 있었다. "자동화는 엔트로피를 늦출 뿐이다. 정제가 먼저다."

내가 이미 내린 결론이 있는데, AI는 그걸 모르고 반대 방향(감시 장치를 더 쌓는 쪽)으로 가고 있었던 것이다. 이 글을 읽은 뒤 AI가 설계 방향을 바꿨다. 제거 > 자동화 > 감시라는 우선순위로.

나 같은 사람이 또 있나 — 열 갈래 조사

방향은 잡혔는데, 내 방식 자체가 이상한 건 아닌지 확인하고 싶었다.

지금 내가 겪고 있는 이런 문제를 다른 사람들은 어떻게 해결을 해? 나처럼 하는 사람들이
있어? 없다면 왜 없는지. 그런 걸 네가 좀 자세하게 전수조사해봐.

AI가 조사 담당을 열 갈래로 나눠서 동시에 돌렸다. 나온 것 중 결정적이었던 것들:

• "git은 백업이 아니다"가 개발자 세계의 컨센서스였다. 버전관리와 백업은 다른 일이라는 게 상식이었다. 내가 몰랐던 것
• 개발자들은 폴더를 안 옮긴다. 프로젝트가 완료돼도 폴더를 이사시키지 않고, 상태는 GitHub 쪽 설정(보관 토글·배지)으로 표시한다
• 업계 표준 폴더 구조 같은 건 없었다. dev.to 창업자조차 "나는 dev라는 폴더 하나가 있고 그냥 큰 쓰레기통이다"라고 답했다
• 대형 프로젝트 국제표준(ISO 19650)은 생애주기를 폴더가 아니라 '상태 코드'로 관리한다. 위치가 아니라 표시로
• 내가 참고했던 Johnny Decimal은 창시자가 "1인 사업자 케이스는 아직 못 풀었다"고 공식 인정하고 있었다

그리고 하나 더. 내 조합(폴더 이동 + git + 문서와 코드 혼합 + AI 위임)과 정확히 같은 선례는 없었다. 원래 안 섞이는 두 세계를 붙이는 축이라서.

뒤엉킨 문제를 세 개로 쪼개기

조사 결과를 보고 나서 생각이 바뀌었다.

차라리 폴더 구조를 고정으로 가는 거지. 옮기지 않게. 그리고 그 안에서 필요한 프로젝트만
레포로 관리하고. 내가 백업을 하려고 해서 이런 구조가 나온 것 같거든?
백업을 git으로 처리하려고 한 것 자체가 문제였던 것 같기도 해.

AI가 여기서 논의를 세 축으로 분해했다.

쪼개고 보니 명확해졌다. 내가 "대대적 개편"이라고 부르던 것의 실제 차이는 첫 번째 축 하나뿐이었다. 나머지 둘은 이미 답이 나와 있었다. 백업은 백업 도구로, git은 원래 용도로.

그래서 아무것도 안 바꿔도 됐다

설계를 확정하고 보니 결론이 이랬다.

최상위 폴더 구조는 그대로 둔다. 조사해보니 내 폴더 구조는 이미 기록관리에서 수십 년간 살아남은 "기능 기반 분류"에 가까웠다. 갈아엎을 이유가 없었다.

바꾼 건 그걸 감싸던 쪽이다.

• 시스템은 폴더 위치를 읽지 않는다. 진행 상태는 각 폴더의 README에 적힌 정보로 판단한다. 위치는 사람이 보기 편하려고 있는 것
• git은 원래 용도로만. 코드 되돌리기와 배포에만. 백업하려고 만든 레포는 걷어낸다
• 백업은 백업 도구로. 구글드라이브 같은 실시간 양방향 동기화 말고, 개발자들이 쓰는 단방향 스냅샷 방식. 외장하드나 개인용 NAS도 가능하다

그리고 위치와 관련해 만들어뒀던 규칙 6개를 폐기했다. "z_reserve로 가면 레포를 접는다", "프로젝트로 승격하는 순간 git을 만든다" 같은 것들. git 오용이 사라지니까 그걸 지탱하려고 붙였던 규칙들이 존재 이유를 잃은 것이다.

이게 이날 가장 좋았던 부분이다. 뭘 더 만들어서 해결한 게 아니라, 잘못 쓰던 걸 걷어내니까 나머지가 같이 사라졌다.

확인 한 번 더 — AI가 한 작업을 다른 세션에서 검증

설계 문서를 만드는 세션에서 AI가 좀 이상하게 대답한다는 느낌이 있었다. 그래서 새 세션을 열고 모델을 바꿔서 시켰다.

원본 세션이 파일로 보관돼 있잖아. 거기서 확인해서 모순되거나 이상하게 작업한 게 있으면
네가 전수조사해서 확인해줬으면 좋겠어. 냉정하게. 아주 꼼꼼히.

여기서 몇 가지가 나왔다. AI가 내 답변을 듣기도 전에 "확정"이라고 문서에 적어둔 것, 세어보겠다고 다섯 번 말하고 한 번도 안 센 숫자가 그대로 계획에 박혀 있던 것 등이다. 실제로 세어보니 그 숫자가 틀렸고, 그대로 진행했으면 살아있는 공개 레포 5개가 잘못 접힐 뻔했다.

내가 잡아낸 게 아니라 AI에게 시켜서 나온 결과다. 같은 세션 안에서는 자기가 방금 내린 결정을 잘 못 뒤집는데, 세션과 모델을 바꾸니까 냉정하게 봤다.

대시보드를 처음 펼쳐보고

정리 작업을 절반쯤 진행한 뒤, 전체 현황을 한 화면에 띄웠다. 처음 보는 화면이었다.

이렇게 펼쳐놓고 보니까 내가 괜히 파악을 못 하는 게 아니구나라는 생각이. 뭔가 많고
복잡한데? 뭐가 뭔지 잘 모르겠고, 활성된 것과 비활성된 게 다 펼쳐져 있고, 보류된 것 중에서는
뭐가 왜 보류가 됐는지도 잘 모르겠고.

기분이 나쁘진 않았다. "내가 못 하는 게 아니라 실제로 복잡한 거였다"는 확인이었으니까. 그동안은 복잡한지 아닌지조차 볼 수가 없었다.

✅ 결과 (After)

Before vs After

솔직하게 남은 것

아직 다 정리되지 않았다. 레포 정리도 진행 중이고, 백업 도구도 아직 정식 도입 전이라 임시로 폴더를 통째 복사해두고 작업했다. 카테고리 정리와 보류함 정리도 남았다.

그래도 원인이 뭔지, 어떻게 해야 할지 가닥이 잡혔다. 그동안은 그것조차 몰라서 답답했다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 구조를 바꾸기 전에 "도구를 원래 용도로 쓰고 있나"부터 본다

나는 폴더 구조가 문제라고 믿고 전면 개편을 하려 했다. 실제 원인은 백업 도구가 아닌 걸 백업에 쓴 것이었다. 갈아엎을 문제가 아니라 오용 문제였다.

AI에게 물을 때도 "이 구조 어떻게 바꿀까"보다 "내가 이 도구를 원래 용도대로 쓰고 있는 게 맞아?"가 훨씬 좋은 질문이었다.

2. 규칙이 자꾸 늘어나면 그건 답이 아니라 증상이다

문제가 생길 때마다 규칙을 하나씩 붙였다. "이 경우엔 이렇게 하자." 그게 쌓여서 내가 내 시스템을 파악 못 하게 됐다.

예외를 계속 덧붙여야 유지되는 구조는 이미 틀어진 것이다. 규칙을 잘 만드는 게 아니라, 규칙이 필요 없어지게 만드는 쪽을 봐야 했다.

이렇게 하면 안 돼요

AI가 "문제없습니다"라고 하면 그냥 넘어가는 것

이중 git 문제는 두 번을 물었는데 두 번 다 괜찮다는 답이 왔다. 세 번째로 콕 집어 말하고 나서야 실제로 세어봤고, 4곳이 나왔다. 직감이 계속 걸리면 "실제로 확인해봐"라고 시켜야 한다.

AI가 제안하는 대로 장치를 계속 늘리는 것

AI는 문제를 발견하면 대체로 뭔가를 추가해서 해결하려 한다. 점검 스크립트, 자동 감사, 경고 알림. 그때마다 내가 파악 못 하는 층이 하나씩 늘어난다. 비개발자에겐 이게 특히 위험하다. 더하는 방향으로 갈 때 한 번쯤 "빼는 방법은 없어?"라고 물어보는 게 좋다.

🌍 다른 업무에 적용한다면

이 방식은 폴더 관리 말고도 쓸 수 있다.

• 엑셀·노션이 계속 무거워질 때: 시트를 재설계하기 전에, 원래 그 도구가 할 일이 아닌 걸 억지로 시키고 있는 건 아닌지 본다
• 업무 규칙이 자꾸 늘어날 때: 규칙을 정리하기 전에, 규칙을 만들게 하는 원인 자체를 없앨 수 있는지 본다
• AI에게 뭔가 맡기고 불안할 때: 같은 작업을 다른 세션이나 다른 모델에게 검증시킨다

🚀 앞으로의 계획

• 백업 도구 정식 도입 (임시로 통째 복사해둔 상태)
• 레포 정리 마무리 — 백업용으로 만들었던 것들 걷어내기
• 카테고리 정리와 보류함 정리
• 현황을 한눈에 보는 칸반보드

📋 재사용 가능한 프롬프트

프롬프트 1: 구조를 갈아엎기 전에 원인 확인하기

지금 [내 시스템/폴더/작업 방식]이 복잡해서 관리가 안 된다고 느껴. 그래서 [구조를 전면 개편]하려고 하는데, 그 전에 확인하고 싶은 게 있어.

혹시 진짜 원인이 구조가 아니라, 내가 어떤 도구를 원래 용도가 아닌 데 쓰고 있어서일 가능성은 없어? 내가 지금 쓰는 도구들이 각각 원래 용도대로 쓰이고 있는지 하나씩 짚어줘. 오용하고 있는 게 있으면 그것 때문에 파생된 문제도 같이 알려줘.

프롬프트 2: 규칙을 늘리는 대신 줄이기

이 문제를 해결하려고 규칙이나 자동화 장치를 추가하려는 것 같은데, 잠깐 멈춰줘.

규칙을 더하는 방법 말고, 문제 자체가 없어지게 만드는 방법은 없어? 다음 순서로 검토해줘: ①이 종류를 아예 없앨 수 있나 ②없앨 수 없다면 자동화할 수 있나 ③자동화도 안 되면 그때 감시 장치. 1번부터 검토하고, 3번으로 가야 한다면 왜인지 설명해줘.

프롬프트 3: AI가 한 작업을 다른 세션에서 검증하기

이전 세션에서 작업한 [문서/코드]가 좀 미덥지 않아. 원본 대화 기록이 남아 있으니 그걸 기준으로 검증해줘.

• 내가 실제로 요청한 것과 결과물이 일치하는지
• 내가 승인하지 않은 걸 "확정"으로 적어둔 게 있는지
• 문서에 적힌 숫자나 사실이 실제로 확인된 것인지, 추정인지

냉정하게 봐줘. 문제가 없으면 없다고 해도 되는데, 있으면 근거와 함께 알려줘.

마무리

전면 개편을 각오하고 시작했는데, 결론은 "폴더는 그대로 두고 잘못 쓰던 도구만 제자리로"였다. 복잡해 보이는 문제일수록 구조를 손대기 전에 뭘 오용하고 있는지부터 보는 게 빠를 수 있다.

아직 진행 중인 작업이라 깔끔한 완결은 아니다. 그래도 원인을 알고 움직이는 것과 모르고 답답한 건 완전히 다르다.

아루나의 다른 프로젝트가 궁금하다면 → litt.ly/aluna

작업 기록과 프로젝트 현황은 여기에 정리하고 있습니다 → aluna-site.vercel.app

📝 한줄 요약

AI가 코드 짜는 걸 지켜보다가 "이거 완전 방치형 게임인데?" 싶어서, 내 AI 에이전트들이 바탕화면에서 캐릭터가 되어 일하는 오버레이 게임을 만들었습니다. 목표는 하나 — 일을 노는 것처럼 재밌게.

바쁘시면 이것만 읽어도 돼요:

• 만든 것: 내 Claude(AI) 에이전트가 바탕화면 구석에서 캐릭터로 일하는 방치형 펫 게임. 진짜로 지금 하는 작업을 캐릭터가 연기함
• 시작한 이유: AI가 일하는 게 늘 방치형 게임처럼 보였다. 그럼 진짜 게임으로 만들면 일도 노는 것처럼 재밌지 않을까?
• 가장 인상적이었던 순간: 한 모델(오푸스)로 8시간을 고쳐도 안 되던 화면 배치가, 게임 잘 만든다는 다른 모델(페이블5)로 바꾸니 접근 자체를 갈아엎어 한 번에 풀렸다
• 핵심 교훈: AI가 버그를 계속 못 고치면 "추측하지 말고 직접 재봐"라고 시켜라. 추측 5번보다 계측 1번
• 결과: 일하는데 옆에서 캐릭터가 움직이니까 확실히 덜 지루하다. 원래 목표 그대로 달성

🎯 이런 분들께 도움돼요

• 일이 지겨운 분 — "일을 재밌게 만드는" 발상 자체에 관심 있는 분
• AI로 뭔가 만들다 버그에 계속 막혀본 분
• 비개발자인데 AI로 내 취향의 물건을 만들어보고 싶은 분

😫 문제 상황 (Before)

특별히 불편해서 시작한 건 아니었습니다. 그냥 오래된 생각이 하나 있었어요.

AI한테 일을 시켜놓고 옆에서 지켜보고 있으면, 이게 꼭 방치형 게임 같았습니다. 방치형 게임 아시죠? 내가 뭘 안 해도 캐릭터가 알아서 자원 캐고 성장하는 걸 구경하는 게임. AI가 코드를 척척 짜는 걸 보고 있으면 딱 그 느낌이었어요.

그러다 이런 생각이 들었습니다.

AI가 일하는 게 방치형 게임 같다면, 그걸 진짜 게임으로 만들면 어떨까? 그럼 일하는 것도 노는 것처럼 재밌게 할 수 있지 않을까?

마침 요즘 뭔가 재밌는 일을 하고 싶던 참이었고, 새로 나온 AI 모델(페이블5)이 게임을 잘 만든다는 얘기를 들어서 한번 써보고 싶기도 했습니다. 그래서 시작했어요.

🛠️ 사용한 도구

• 도구: Claude Code (터미널에서 대화하며 코딩하는 AI 도구)
• 모델: Opus 4.8, 그리고 Fable 5 (중간에 교체 — 이게 이 글의 핵심입니다)
• 특이사항: 저는 개발자가 아닙니다. 코드를 직접 짜지 않고, AI에게 말로 시켜서(바이브 코딩) 만들었습니다

🔧 작업 과정

먼저 정한 것 — "그냥 알림"과 뭐가 다른가

만들기 전에 AI와 컨셉부터 정리했습니다. 사실 "AI가 일하면 캐릭터가 반응한다"는 것만으로는, 이미 나와 있는 여러 알림 프로그램과 다를 게 없었거든요.

그래서 게임 요소를 넣기로 했습니다. 새 작업을 시작할 때마다 캐릭터가 태어나서 수집되고(도감), 시간마다 정해둔 구호를 외치고, 지금 무슨 작업을 하는지 혼잣말을 하는 식으로요.

1을 충실히 하되 2의 게임요소도 필요해. 1만 충실히 하면 사실 기존에 이미 나온 클로드 아이콘으로 독에서 알림해주는 거랑 별 다를게 없으니까... ai작업을 새로 시작하며 ai에이젼트가 생길때 마다 다양한 종류의 햄스터가 태어나고 그걸 수집할수 있다건가.

화면을 가리는 문제 — 공간이 아니라 '시간'으로 나눴다

바로 현실적인 고민이 생겼습니다. 저는 VS코드(코딩 화면)를 꽉 채워놓고 일해서, 캐릭터가 여러 마리 나오면 화면을 가려서 오히려 방해가 됐어요.

근데 고민되는 부분이 사실 난 일할때 창 가득 vs코드 창을 켜놓고 일해서 햄스터들이 너무 많이 나와서 화면을 가리면 일하는데 방해가 되. 만약 햄스터가 있다면... 한마리만 방해되지 않게 나와있거나 하는게 제일 좋지.

AI가 여기서 좋은 정리를 해줬습니다. 이 앱은 목적이 둘인데(알림은 봐야 하고, 관상은 안 봐도 되고) 서로 충돌한다는 거였어요. 그래서 공간이 아니라 시간(모드)으로 나누자는 결론이 나왔습니다. 평소엔 대표 캐릭터 한 마리만 구석에 작게(안 방해), 클릭하면 나머지가 우르르 펼쳐지는 방식으로요.

AI가 진짜 하는 일을 말하게 하기

이 게임의 핵심은 여기였습니다. 남들 데스크펫은 가짜 랜덤 대사를 말하지만, 제 건 실제 연동이니까 "진짜 지금 하는 일"을 말할 수 있었거든요. 그런데 처음엔 말풍선이 잘 안 뜨거나 내용이 빈약했습니다.

응 잘되. 근데 아까부터 보니까 음...ai가 일하는데 어떤걸 하는지 표현하는 말풍선이 안뜨거나 너무 내용이 한정적인거 같아.

이왕이면 실용적으로 만들고 싶었습니다. 그래서 물었어요.

근데 말풍선이 좀 실용적이 면 좋겠어. 어떤내용이 말풍선에 나오면 보다 실용적일까? 예를 들어 오류가 났거나, 작업이 다 끝났을때 알려주면 도움이 될거 같아. 그 외에 또 뭐가 있을까?

여기서 AI가 인상적인 판단을 했습니다. "오류 알림"을 만들려다가, 추측으로 코드를 짜는 대신 실제로 테스트를 해보고 "도구가 실패했을 때는 신호가 아예 안 온다"는 걸 발견한 거예요. 그래서 안 되는 걸 붙잡지 않고 접었습니다. 대신 완료·대기·오래걸림 세 가지 알림만 남겼어요. (안 되는 걸 우기지 않는 게 오히려 시간을 아꼈습니다.)

그리고 8시간의 벽 — 화면 배치가 계속 어긋났다

문제는 캐릭터와 소품(액자·노트)을 화면에 예쁘게 정렬하는 거였습니다. 이게 정말 안 풀렸어요.

캐릭터가 너무 크거나, 점프할 때 머리가 잘리거나, 말풍선이 엉뚱한 데 떠 있거나, 소품이 겹치거나. 고치면 다른 게 틀어지고, 또 고치면 또 틀어지고. 제 채팅 기록이 이렇게 흘러갑니다.

다 엉망 되었네..

전혀 안되 다 겹쳐 있고 이상해

계속 위치를 못마추고 있네 이걸 어떻게 해결하는게 좋을까?

오푸스(당시 쓰던 모델)로 이걸 8시간 가까이 붙잡고 있었습니다. AI가 픽셀 좌표를 하나하나 계산해서 "여기서 몇 픽셀 위, 몇 픽셀 옆"을 맞추려는 방식이었는데, 하나를 맞추면 다른 하나가 어긋나는 무한 굴레였어요.

그래서 마침 "게임 잘 만든다"던 페이블5로 모델을 바꿔봤습니다.

결과가 놀라웠어요. 페이블5는 좌표를 하나하나 맞추는 방식 자체를 버렸습니다. 대신 브라우저가 알아서 요소들을 정렬해주는 방식(flexbox)으로 구조를 통째로 갈아엎었어요. 사람이 좌표를 계산하는 게 아니라, 애초에 겹칠 수 없게 판을 짜버린 거죠. 8시간을 헤매던 게 접근을 바꾸니 단번에 풀렸습니다.

이게 이번 작업에서 제일 크게 배운 순간이었어요. 같은 문제라도 모델마다 푸는 방식이 다르다. 안 풀리면 붙잡고 있지 말고 갈아타 볼 것.

캐릭터도 더 귀엽게, 눈도 마우스를 따라오게

배치가 풀리고 나선 캐릭터를 다듬었습니다. 처음엔 제가 코드로 찍은 픽셀 도트였는데 좀 뚝뚝했어요. 예전에 써봤던 비슷한 오픈소스(clawd-on-desk)의 캐릭터가 더 귀엽고 자연스러워서, 그걸 참고했습니다.

솔직히 지금 디자인이 별로야... 이 레포의 클로드 이미지를 참고해서 해보자

눈을 깜빡이고, 마우스를 따라 눈동자가 움직이고, 완료하면 폴짝 뛰는 것까지 붙였습니다. 여기서도 방향을 하나 잡았어요. 참고한 오픈소스를 "베낄 대상"이 아니라 "부품 창고"로 보기. 캐릭터 움직임 같은 부품은 가져오되, 게임의 핵심(수집·도감)은 제가 창작하는 걸로요.

✅ 결과 (After)

원래 목표는 하나였습니다. "일을 노는 것처럼 재밌게." 그건 이뤘어요.

여러 AI 창을 켜고 일할 때, 옆에서 캐릭터가 타자 치고 잠자고 완료하면 폴짝 뛰는 걸 보고 있으면 확실히 덜 지루합니다. 작업이 노는 것처럼 느껴져요.

Before vs After

결과물

우측 하단에 작은 캐릭터 한 마리가 떠 있다가, 클릭하면 지금 돌아가는 AI들이 여러 마리로 펼쳐집니다. 급훈 액자를 누르면 다 같이 구호를 외치고, 노트에는 오늘 작업 통계가 적혀 있어요.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 안 풀리면 모델을 바꿔봐라. 오푸스로 8시간을 헤맨 걸 페이블5가 접근을 바꿔 한 방에 풀었습니다. 같은 AI 도구여도 모델마다 문제 푸는 방식이 다릅니다.
2. AI한테 "추측하지 말고 직접 재봐"라고 시켜라. 이게 이번의 핵심 교훈입니다. 버그가 계속 안 잡힐 때, AI가 "아마 이것 때문일 거야"라고 추측으로 고치면 헛발질만 반복돼요. "짐작하지 말고 실제로 로그를 찍어서 확인해봐"라고 시키면, 진짜 원인이 엉뚱한 데 있는 경우가 많습니다. 추측 다섯 번보다 계측 한 번이 빠릅니다.
3. 안 되는 건 우기지 말고 먼저 확인시켜라. "오류 알림"처럼 원래 불가능한 걸 AI가 붙잡으면 시간만 날립니다. "이거 원래 되는 거 맞아?"부터 테스트하게 하면 헛수고를 막아요.

이렇게 하면 안 돼요

1. 한 모델로 무한정 붙잡고 있기. 저는 8시간을 버렸습니다. 두세 번 시도해서 안 풀리면 접근이나 모델을 바꿀 신호예요.
2. AI의 "아마 ~때문일 거예요"를 그냥 믿기. 추측이 맞을 때도 있지만, 안 잡히는 버그는 대개 추측이 틀린 겁니다. 확인부터 시키세요.

🌍 다른 업무에 적용한다면?

"일을 재밌게 만든다"는 발상은 게임이 아니어도 됩니다. 반복적이고 지겨운 작업에, 진행 상황이 눈에 보이는 작은 장치 하나만 붙여도 체감이 달라져요. 완료하면 소리가 나거나, 오늘 한 일이 한눈에 쌓이거나 하는 것만으로요.

그리고 "추측하지 말고 재보게 하라"는 팁은 코딩이 아닌 어떤 AI 작업에도 통합니다. AI가 자신 있게 틀린 답을 낼 때, 근거를 직접 확인하게 시키는 습관이요.

🚀 앞으로의 계획

세 가지를 다 만들 생각입니다.

1. 도감 — 프로젝트별로 캐릭터를 수집하는 진열장. 지금은 데이터만 쌓고 있고, 며칠 뒤 데이터가 차면 UI를 붙일 예정
2. 체크리스트 — 오늘 할일을 적고 체크하면 캐릭터가 만세하는 기능
3. 품종 색 — 프로젝트·모델마다 캐릭터 색이 달라지는 수집 요소

📋 재사용 가능한 프롬프트

프롬프트 1: 버그가 계속 안 잡힐 때

이 버그를 지금까지 [고친 방법들]로 시도했는데 계속 안 됩니다. 추측으로 또 고치지 말고, 진짜 원인이 뭔지 실제로 확인할 수 있게 로그(진단 정보)를 먼저 심어서 재봐 주세요. 계측 결과를 보고 나서 고칩시다.

프롬프트 2: AI가 어떤 기능을 만들려 할 때 (되는지부터 확인)

[만들고 싶은 기능]을 넣고 싶은데, 이게 지금 환경에서 원래 가능한 건지부터 확인해줘. 추측하지 말고, 실제로 되는지 간단히 테스트해본 다음에 되면 만들고 안 되면 대안을 알려줘.

프롬프트 3: 한 방식으로 계속 막힐 때

지금 [현재 방식]으로 [문제]를 풀려는데 계속 막힙니다. 이 방식 말고 아예 접근을 바꾸는 다른 방법은 없을까요? [예: 좌표를 하나하나 맞추는 대신, 알아서 정렬되는 구조는 없나요?]