확인하지 않으면 틀린 채로 갑니다 — 1주차에 여섯 번 되풀이한 한 가지

일주일 전 제 손에는 남의 템플릿 하나가 있었어요. 지금은 인터넷에 올라간 제 사이트에 글 13편이 있고, 논문이 들어갈 폴더와 노트 양식까지 서 있습니다.

그런데 이 글에서 자랑하려는 건 결과물이 아니에요. 한 주를 마치고 매일 쓴 학습일지 네 편을 나란히 놓고 봤더니, 날마다 다른 걸 배운 게 아니었어요. 같은 일이 여섯 번 반복됐습니다.

확인하지 않으면 틀린 채로 갑니다.

여섯 번 다 확인해서 잡았습니다. 안 잡았으면 하나같이 나중에 훨씬 크게 터질 일이었어요. 그 여섯 장면을 순서대로 풀겠습니다.

누구에게 도움이 될까요 — AI와 뭔가를 만들기 시작했는데 “AI가 그렇다니까 그런가 보다” 하고 넘어가는 게 불안한 분이요. 코딩을 몰라도 읽을 수 있게 썼습니다.

그 전에 — 한 주 전의 저

“지식을 체계로 쌓고 싶은데 매번 흩어지고, 어디서 시작할지 막막하다.”

이게 출발점이었어요. 자료는 옵시디언에, 결정은 대화창에 흩어져 있고 새 대화를 켜면 매번 처음부터 다시 설명해야 했습니다.

장면 1 — AI가 처음에 짚어준 게 틀렸어요 (7/23)

첫날 AKM이라는 개념을 정리했어요. AI가 “AI Knowledge Management”라고 알려줬고, 저는 그럴듯하다고 생각했습니다. 그런데 원문을 찾아 읽어보니 Agent Knowledge Management(에이전트 지식관리)였어요.

한 단어 차이지만 뜻이 완전히 달라요. “AI가 지식을 관리한다”가 아니라 “AI 에이전트가 무엇을 읽고 어디 저장하고 어떻게 실행하고 실패를 어디로 되돌릴지 정하는 운영 구조” 였습니다. 이걸 틀린 채로 갔으면 개념페이지 한 장이 아니라 4주 프로젝트의 방향이 어긋났을 거예요.

그래서 학습메이트에게 규칙을 하나 박아뒀습니다.

도구 설치법·명령어·설정처럼 정확해야 하고 자주 바뀌는 것은
기억으로 지어내지 말고, 최신 공식문서를 확인해서 알려줘.

이 한 줄이 이번 주 내내 일했어요.

장면 2 — 계획을 짜기 전에 사례를 찾게 했어요 (7/24)

4주 계획을 세울 때, 그냥 “계획 짜줘”라고 하면 그럴듯한 계획이 나옵니다. 문제는 그럴듯한 것과 맞는 것이 다르다는 거죠. 그래서 이렇게 부탁했어요.

막연히 짜지 말고, 이걸 실제로 만든 사람들의 사례를 먼저 찾아줘.
그 사례들에 근거해서 계획을 세워줘.

사례 여섯 개가 나왔고, 그중 성공한 것들이 하나같이 같은 순서를 쓰고 있었어요. 위키를 먼저 만들고 검색을 나중에 얹는 순서요. 제 감으로 짰으면 반대로 갔을 겁니다. 검색이 더 재미있어 보였거든요.

장면 3 — 배포 직전에 일지가 공개될 뻔했어요 (7/26)

사이트를 인터넷에 올리려는데, 학습일지 폴더가 git이 무시하는 목록에 없었어요. 저장소를 공개로 만들었으면 제 일지 원문이 그대로 인터넷에 올라갔을 겁니다.

배포 전에 발견해서 저장소를 비공개로 정했어요. 여기서 배운 건 올리기 전에 무엇이 올라가는지 봐야 한다는 거예요. 올린 다음에 지우는 건 훨씬 어렵습니다.

💡 여기에 저장소를 private으로 만드는 화면 스크린샷을 넣으면 좋아요.

장면 4 — 순서에 이유가 있었어요 (4일차)

되돌리기를 배우는 날이었어요. 커리큘럼이 “먼저 저장(커밋)하고, 그다음 일부러 망가뜨렸다가 되돌려보라”고 했습니다. 저는 순서가 왜 그런지 몰랐어요.

해보고 알았습니다. 저장하지 않은 건 되돌릴 수 없어요. git이 아직 모르는 파일은 “되돌릴 지점”이 없으니까요. 순서를 바꿔서 망가뜨리기부터 했으면 되돌아갈 데가 없었을 겁니다.

일부러 랜딩 글을 ㅁㄴㅇㄹ asdf로 망가뜨려놓고 화면으로 확인한 다음, 명령 한 줄로 되돌렸어요. 되돌아오는 걸 눈으로 보고 나니 사이트를 건드리는 게 덜 무서워졌습니다.

장면 5 — 정석이 정석이 아니었어요 (5일차)

기획서를 쓰면서 만드는 방법을 다시 조사하게 했어요. 제가 알던 정석은 벡터DB였습니다. 전에 만든 프로젝트에서도 그렇게 했고요.

조사 결과가 뒤집혔어요. 지금은 마크다운과 기본 검색만으로 하는 쪽이 표준이고, 노트가 500~1,000편 이하면 벡터가 필요 없다는 거였어요. 제 위키는 8편이었습니다. 한참 못 미쳤죠.

여기서 그냥 가벼운 쪽으로 갈아탈 수도 있었는데, 학습메이트가 짚어줬어요. 벡터를 빼면 제가 데이터 쪽에서 보여줄 알맹이가 얇아진다고요. 그래서 가벼운 것으로 먼저 만들고, 나중에 벡터를 얹어 둘을 비교하기로 정했습니다.

“무거운 걸 썼다”보다 **“무거운 게 진짜 필요한지 재봤다”**가 더 정직하고 내세울 것도 많다고 봤어요. 이게 이번 주 제일 큰 판단이었습니다.

같은 날 하나 더 걸렸어요. 계획 문서의 순서가 한 주씩 밀려 있어서 고쳤는데, 그 문서를 만들어준 AI 절차 파일에 옛 순서가 그대로 박혀 있었어요. 안 고쳤으면 다음에 그 절차를 돌릴 때 오늘 고친 게 되돌아갔을 겁니다. 결과물만 고치고 끝낼 게 아니라 그걸 만드는 절차까지 봐야 했어요.

장면 6 — “확인했다”고 생각했는데 안 본 거였어요 (6일차)

이게 제일 아찔했어요.

논문 원본 파일을 git에 올리지 않도록 막고, 정말 막혔는지 확인했습니다. 확인 명령을 넣었더니 이렇게 나왔어요.

?? knowledge/raw/

한 줄이에요. 저는 “논문 파일이 안 보이니 잘 막혔네”라고 판단하고 넘어가려 했습니다.

아니었어요. 저 한 줄은 “이 폴더 안에 아직 기록 안 된 게 있다”는 말이지, 그 안에 무엇이 있는지는 알려주지 않아요. git은 폴더 전체가 아직 기록 안 된 상태면 폴더 하나로 뭉쳐서 보여줍니다. 안에 파일이 1개든 100개든 한 줄이에요.

파일 단위로 보려면 옵션을 붙여야 했어요.

git status --short -uall knowledge/raw/

이번엔 파일 이름이 나왔고, 그제서야 막힌 걸 확인했습니다. 같은 상태를 두 번째 명령으로 봤을 때 처음 알게 된 거예요.

여기서 한 걸음 더 갔어요. “막혔나”만 보면 반쪽이에요. 과하게 막혔을 수도 있으니까요. 정작 올려야 할 노트까지 막히면 그건 에러가 안 나서 훨씬 늦게 발견됩니다. 그래서 양쪽을 다 물었어요.

# 막아야 할 것이 막혔나
git check-ignore -v knowledge/raw/some-paper.pdf

# 올려야 할 것이 통과하나 (출력 없으면 통과)
git check-ignore -q knowledge/raw/some-paper.md

같은 날 인터넷 글도 한 번 뒤집었어요. 사이트에 검색창을 붙이려고 찾아보니 검색 결과가 전부 부품 두 개를 설치하라고 했습니다. 그런데 그 부품의 등록 정보를 직접 열어보니 하나가 다른 하나를 이미 품고 있었어요. 한 줄이면 됐습니다. 블로그는 쓰인 시점에 멈춰 있고, 등록 정보는 지금을 보여줘요.

그래서 어떻게 됐나

커리큘럼이 마지막에 짚어준 게 인상 깊었어요. 이번 주에 만든 문서를 실무 이름으로 바꿔보면 이렇게 됩니다.

코딩을 배운 게 아니라 프로젝트를 굴리는 법을 배운 거예요. 저는 연구센터에서 장비 사업을 총괄할 때 이 문서들을 만들었어요. 이름만 다르고 역할이 같습니다.

가져가서 쓰세요

조사부터 시키는 프롬프트

계획을 짜기 전에 이걸 앞에 붙이면 계획이 가벼워집니다. 실제로 이번 주에 이걸로 파이썬 도구 설치를 통째로 생략했어요.

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

확인까지 시키는 프롬프트

“해줘”로 끝내면 됐는지 알 수 없어요. 뒤에 한 줄을 붙이세요.

[할 일]을 해줘.
그리고 실제로 그렇게 됐는지 확인까지 해줘.
막아야 할 게 막혔는지, 통과해야 할 게 통과하는지 양쪽 다 봐줘.

확인 3단 체크리스트

무언가를 막거나 걸렀다면 세 가지를 보세요.

• 막아야 할 것이 막혔나
• 통과해야 할 것이 통과하나 (이걸 빼면 과하게 막힌 걸 못 잡아요)
• 도구가 파일 단위로 보여주나 (폴더로 뭉쳐 보여주면 확인한 게 아니에요)

AI에게 박아둘 규칙 한 줄

정확해야 하고 자주 바뀌는 것(설치법·명령어·버전)은
기억으로 답하지 말고 공식 출처를 확인해서 알려줘.

배운 것

틀린 답보다 빈 답이 위험해요. 틀린 걸 봤다면 다시 봤을 거예요. 그런데 아무것도 안 보여주는 출력은 “문제 없음”으로 읽힙니다. 확인하는 방법을 모르면 확인한 줄 알고 지나가요.

AI는 틀릴 때 자신 있게 틀려요. 첫날 AKM 뜻도, 인터넷 글의 설치 안내도 다 자신 있는 어조였습니다. 어조로는 구별이 안 돼요. 구별되는 건 출처를 열어봤는지 여부뿐이에요.

쉬운 길이 항상 이득은 아니에요. 가벼운 방법을 알게 됐을 때 갈아타기 쉬웠는데, 그러면 제가 보여줄 게 얇아졌어요. 쉬운 길을 알고 나서 왜 어려운 길을 가는지 말할 수 있게 된 것이 이번 주 수확입니다.

개념을 먼저 잡는 게 시간 낭비가 아니었어요. 첫날 이해한 원본/지식 분리가 계획과 기획서를 거쳐 마지막 날 폴더 구조가 됐습니다. 첫날의 개념이 그대로 손에 잡히는 게 됐어요.

다음 주

논문을 늘리기 전에 미뤄둔 결정 두 개를 먼저 정하려고 해요. 이번 주에 배운 걸 순서로 옮기는 거예요. 결정을 안 하고 넣기 시작하면 나중에 넣은 걸 전부 손봐야 하니까요.

그리고 2주차에는 화면에 보이는 게 나옵니다. 이번 주에 만든 건 터라서 눈에 안 보였어요. 하루 종일 했는데 화면에 새로 뜬 게 없는 날은 좀 허전했습니다. 그래도 집을 지을 때 터는 원래 안 보이는 거니까요.