AI가 짜준 계획이 어려운 길이었다 — '조사부터' 한 줄로 설치를 통째로 건너뛴 기록

AI가 짜준 계획이 어려운 길이었다 — '조사부터' 한 줄로 설치를 통째로 건너뛴 기록

📝 한줄 요약

계획을 짜달라고 하기 전에 "먼저 조사부터 해줘" 한 줄을 붙였다. 그 한 줄로 내 기획서에 적어둔 방법 세 개가 지금 기준으로는 과하다는 걸 알게 됐고, 프로그램 설치와 버전 업그레이드를 전부 건너뛰었다.

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

• AI에게 계획을 시킬 때 "짜줘" 앞에 "먼저 조사부터 해줘"를 붙였다.

• 내가 기획서에 적어둔 방법 세 가지가 다 필요 없다는 결과가 나왔다.

• 특히 프로그램 세 개를 비교하다가, 정확도 차이보다 설치 준비에 드는 시간이 더 크다는 걸 알게 됐다.

• 인터넷 글 전부가 같은 안내를 하고 있었는데, 원본 정보를 직접 열어보니 그게 낡은 내용이었다.

• 그 결과 실제 작업은 명령 한 줄로 줄고, 프레임워크 업그레이드도 하지 않게 됐다.

• 배운 것: AI는 틀릴 때도 자신 있게 틀린다. 어조로는 구별이 안 되고, 출처를 열어봤는지로만 구별된다.

🎯 이런 분들께 도움돼요

• AI가 짜준 계획을 그대로 따라가다 "이게 맞나" 싶었던 분

• 뭘 만들려는데 도구가 너무 많아서 뭘 골라야 할지 모르겠는 분

• 검색해서 나온 방법대로 했는데 안 되거나 복잡했던 분

😫 문제 상황 (Before)

지난번에 "나만의 지식체계"를 만들기로 정하고 기획서까지 썼다. 무엇을 왜 만들지, 뭐가 되어야 하는지까지 정해뒀다.

문제는 그다음이었다. "그래서 이걸 어떤 순서로 만들지"를 정해야 하는데, 기획서에 적어둔 방법이 정말 최선인지 확신이 없었다. 나는 코딩을 깊이 알지 못하니, AI가 알려준 방법이 어려운 길인지 쉬운 길인지 판단할 기준이 없었다.

기획서에는 논문을 텍스트로 바꿔주는 프로그램 세 개와 사이트에 검색창을 붙이는 방법이 적혀 있었다. 전부 AI가 조사해서 알려준 것이었고 나는 그럴듯하다고 넘어갔다.

🛠️ 사용한 도구

• 도구: Claude Code

• 특이사항: 프로젝트 안에 AI 학습메이트 '하루'의 지침 파일을 두고, 대화를 켜면 내 상황을 자동으로 읽게 해뒀다.

🔧 작업 과정

계획을 짜달라고 하기 전에, 한 줄을 앞에 붙였다

원래는 "기획서 보고 만드는 순서 짜줘"라고 하면 된다. 그런데 그렇게 하면 AI가 자기 기억으로 계획을 짠다. 기억은 배운 시점에 멈춰 있어서, 그때는 정석이었지만 지금은 아닌 방법이 나올 수 있다.

그래서 순서를 하나 바꿨다.

어제 만든 PRD를 바탕으로 세부계획을 세우고 싶어.
단, 계획을 짜기 전에 먼저 조사부터 해줘 —
이걸 지금 만든다면 요즘 제일 쉽고 많이 쓰는 방법이 뭔지 최신 기준으로 찾아봐.
(옛날 방식이 아니라, 지금 초보가 제일 적은 노력으로 만들 수 있는 방법으로.)

그 최신 방법을 바탕으로 세부계획을 세워줘.
나는 코딩을 잘 몰라. 4주 안에 진짜 만들 수 있게, 작은 단계로 잘게 쪼개서
순서대로 정리해줘. 각 단계는 "하루 안에 될 만한 크기"로.
다 정리되면 내 사이트 위키에 저장해줘.

달라진 건 "계획을 짜기 전에 먼저 조사부터" 한 줄뿐이다. 순서를 강제했더니 결과가 크게 달라졌다.

첫 번째 뒤집힘 — 프로그램 세 개가 전부 과했다

내 기획서에는 논문 파일을 글자로 바꿔주는 프로그램 세 개가 후보로 적혀 있었다. 어느 것이 정확한지 비교해서 고르기로 해뒀다.

조사해보니 비교 기준이 잘못돼 있었다. 정확도 차이는 있었지만 세 프로그램 다 쓸 수 있게 만드는 준비 과정이 문제였다. 프로그래밍 언어 환경을 따로 깔고 큰 파일을 내려받아야 했다. 그 준비만 꼬박 하루 넘게 걸릴 일이었다.

그런데 내가 다룰 논문은 열 편이다. 열 편을 위해 하루를 쓸 이유가 없었다. 학습메이트가 논문 파일을 직접 읽어서 글자로 옮겨주면 설치 없이 같은 결과가 나온다.

그래서 프로그램 도입 자체를 뒤로 미뤘다. 미루기가 아니라 순서 바꾸기로 봤다. 논문이 서른 편을 넘거나 표와 수식이 자주 깨지기 시작하면 그때 붙이면 되고, 그런 일이 안 생기면 안 붙여도 된다.

두 번째 뒤집힘 — 인터넷 글 전부가 같은 말을 하는데, 그게 낡은 내용이었다

사이트에 검색창을 붙이는 차례였다. 검색해서 나온 글이 예외 없이 부품 두 개를 설치하라고 안내했다. 여러 사람이 같은 말을 하니 나는 그게 맞다고 생각했다.

그런데 학습메이트가 그 부품의 공식 등록 정보를 직접 열어봤다. 부품 하나가 다른 하나를 이미 안에 품고 있었다. 한 줄만 설치하면 됐다.

블로그 글은 쓰인 시점에 멈춰 있고, 등록 정보는 지금을 보여준다. 여러 사람이 같은 말을 하는 건 서로를 보고 쓴 결과일 수도 있어서, 숫자가 많다고 최신인 건 아니었다.

세 번째 뒤집힘 — 프레임워크를 올릴 필요가 없었다

새 기능을 붙이려면 사이트를 만든 프레임워크부터 최신으로 올려야 하는 경우가 많다. 그런데 올리다가 사이트가 깨지는 게 초보가 제일 많이 하는 헛수고다.

같은 등록 정보에 "이 부품이 어떤 버전과 어울리는지" 제작자가 적어둔 칸이 있었다. 거기에 내 사이트 버전이 들어 있었다. 그러니 올릴 필요가 없었다.

이 칸 한 줄을 확인하는 데 1초도 안 걸렸는데, 안 봤으면 업그레이드를 시도하고 사이트가 깨지고 되돌리는 과정을 겪었을 것이다.

그래서 계획이 이렇게 나왔다

세 가지를 반영해서 만드는 순서를 12단계로 쪼갰다. 각 단계는 하루 안에 될 크기이고, "이게 됐다"를 눈으로 확인할 방법을 함께 적었다.

순서를 정할 때 원칙 네 가지를 세웠는데, 그중 둘이 특히 마음에 든다.

검색창을 자료보다 먼저 붙인다. 검색창이 이미 돌고 있으면 자료를 넣는 순간 자동으로 잡힌다. 반대로 자료를 다 넣은 뒤에 붙이면, 안 잡힐 때 원인이 자료 쪽인지 검색 쪽인지 갈라 봐야 한다. 고장 원인을 하나씩만 남기는 순서가 초보에게 훨씬 싸다.

채점하는 자를 먼저 만든다. 나중에 무거운 방법을 얹어서 가벼운 방법과 비교할 계획인데, 무거운 걸 붙인 뒤에 평가 기준을 만들면 기준을 그쪽에 유리하게 만들 위험이 있다. 그래서 평가 질문과 채점 방식을 먼저 확정하고 점수를 기록해두기로 했다.

그리고 지난번에 예고했던 원본 자료와 가공된 지식을 나누는 폴더 구조를 실제로 만들었다. 원본이 들어가는 자리는 한번 넣으면 고치지 않고, 정리한 지식은 계속 고치는 자리에 둔다. 두 폴더로 나눈 이유는 위치가 실수를 막아주게 하려는 것이다. 같은 폴더에 섞여 있으면 "이게 원본이었나 내가 고친 건가"를 매번 기억에 의존해야 하는데, 사람은 반드시 까먹는다.

막힌 곳 — "확인했다"고 생각했는데 안 본 거였다

논문 원본 파일을 저장소에 올리지 않도록 막고, 정말 막혔는지 확인했다. 확인 결과가 한 줄로 나왔고 원본 파일이 목록에 없었다. 나는 "잘 막혔네"라고 판단했다.

아니었다. 그 한 줄은 "이 폴더 안에 아직 기록 안 된 게 있다"는 말이지, 그 안에 무엇이 있는지는 알려주지 않는다. 도구가 폴더 전체를 하나로 뭉쳐서 보여준 것이었다. 안에 파일이 하나든 백 개든 한 줄이다.

옵션을 하나 붙여 파일 단위로 다시 보니 그제서야 목록이 나왔고, 막힌 게 맞다는 걸 확인했다. 같은 상태를 두 번째 명령으로 봤을 때 처음 알게 된 것이다.

여기서 하나 더 배웠다. "막혔나"만 보면 반쪽이다. 과하게 막혔을 수도 있으니까. 정작 올려야 할 파일까지 막히면 그건 오류가 안 나서 훨씬 늦게 발견된다. 그래서 양쪽을 다 물어보는 습관을 들였다.

✅ 결과 (After)

Before vs After

결과물

• 라이브 사이트: https://learning-hub-virid.vercel.app

• 만드는 순서(12단계)와 폴더 규칙이 사이트에 문서로 올라가 있다.

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

효과적이었던 것

1. "짜줘" 앞에 "조사부터 해줘"를 붙이기. 순서를 강제하는 것만으로 결과가 달라진다. AI는 시키면 기억으로 답하고, 조사시키면 지금 기준으로 답한다.

2. "지금 초보가 제일 적은 노력으로 할 수 있는 방법으로"라는 조건을 명시하기. 이 조건이 없으면 정확하지만 무거운 방법이 나온다.

3. 인터넷 글 대신 원본 정보를 열어보게 시키기. "공식 등록 정보를 직접 확인해줘"라고 하면 남의 정리가 아니라 지금 사실을 본다.

이렇게 하면 안 돼요

1. 여러 사람이 같은 말을 한다고 최신이라고 믿기. 서로를 보고 쓴 결과일 수 있다.

2. 도구를 정확도만으로 고르기. 그 도구를 쓸 수 있게 만드는 준비 비용을 함께 봐야 한다. 준비가 목적을 넘어서면 안 쓰는 게 낫다.

3. 결과가 짧게 나왔다고 확인됐다고 넘기기. 아무것도 안 보여주는 답은 "문제 없음"으로 읽히지만, 실은 아무것도 안 물어본 것일 수 있다.

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

무언가를 도입하기 전에 "이걸 쓸 수 있게 만드는 데 드는 비용"을 먼저 재보는 데 그대로 쓸 수 있다. 새 협업 도구든 새 자동화 서비스든 마찬가지다. 기능 비교표는 쉽게 구할 수 있지만 준비 비용은 잘 안 적혀 있어서, 그것만 따로 물어보면 판단이 달라진다.

보고서나 기획안을 쓸 때도 쓴다. "이 주제로 초안 써줘" 대신 "먼저 지금 이 분야에서 통하는 기준을 조사하고, 그다음 초안을 써줘"로 순서를 바꾸면 낡은 틀이 덜 나온다.

🚀 앞으로의 계획

다음은 논문 한 편을 처음부터 끝까지 통과시켜 노트 양식을 굳히는 일이다. 한 편으로 양식을 확정한 뒤에 열 편으로 늘린다. 첫 편에서 양식이 틀리면 열 편을 다 고쳐야 하니까.

그다음이 검색창이다. 이제 명령 한 줄이면 되는 걸 알고 있으니 오래 걸리지 않을 것이다. 검색창이 먼저 돌기 시작하면 논문을 넣는 대로 자동으로 잡힌다.

늘리기 전에 정해야 할 것도 남아 있다. 논문 요약을 사이트에 띄울지 여부다. 저장소는 비공개지만 배포된 주소는 누구나 열 수 있어서, 이 결정이 검색 범위까지 함께 정한다.

📋 재사용 가능한 프롬프트

프롬프트 1: 계획을 짜기 전에 조사부터 시키기

계획을 짜기 전에 먼저 조사부터 해줘 — [만들려는 것]을 지금 만든다면 요즘 제일 쉽고 많이 쓰는 방법이 뭔지 최신 기준으로 찾아봐. (옛날 방식이 아니라, 지금 초보가 제일 적은 노력으로 만들 수 있는 방법으로.)

>

그 최신 방법을 바탕으로 계획을 세워줘. 작은 단계로 잘게 쪼개서 순서대로, 각 단계는 "하루 안에 될 만한 크기"로.

>

[만들려는 것]과 [기간]을 본인 상황에 맞게 바꾸세요.

프롬프트 2: 도구를 준비 비용까지 넣어 비교하기

[후보 도구들]을 비교해줘. 기능과 정확도만 보지 말고, 이 도구를 실제로 쓸 수 있게 만드는 데 드는 준비 비용도 같이 알려줘 — 뭘 설치해야 하고, 얼마나 걸리고, 내가 뭘 새로 배워야 하는지. 그리고 내 규모([다룰 분량])에서 그 비용을 들일 값이 있는지 판단해줘.

프롬프트 3: 인터넷 글이 아니라 원본을 보게 하기

이거 인터넷 글 말고 공식 등록 정보나 원본 문서를 직접 열어서 확인해줘. 검색 결과가 여러 개 같은 말을 해도, 그게 옛 버전 기준일 수 있으니까 지금 기준으로 맞는지 1차 출처로 확인해줘.

프롬프트 4: 확인까지 시키기

[할 일]을 해줘. 그리고 실제로 그렇게 됐는지 확인까지 해줘. 막아야 할 게 막혔는지, 통과해야 할 게 통과하는지 양쪽 다 봐줘. 도구가 결과를 뭉쳐서 보여주면 낱개로 다시 확인해줘.