'"됐다"는 말을 그대로 믿었다면 — 4주 동안 일곱 번 속을 뻔한 이야기'

4주 전엔 문서만 있었어요. 지금은 제 논문 21편이 사이트에 올라가 있고, 질문을 던지면 그 논문에서 답과 원문 인용이 돌아오고, 개념끼리 어떻게 이어지는지 그래프로 보여요.

그런데 4주치 기록을 다시 읽어보니, 제가 매주 배운 게 사실 하나였어요. "됐다"는 출력이 됐다는 뜻이 아니라는 것. 일곱 번 속을 뻔했고 일곱 번 다 확인해서 넘겼어요. 이 글은 그 일곱 번의 이야기예요.

누구에게 도움이 될까요 — AI한테 작업을 맡기고 "완료했습니다"라는 답을 받아본 적 있는 분이요. 코딩을 몰라도 읽을 수 있게 썼어요.

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

• "완료했습니다", "저장 완료", "빌드 성공"은 전부 과정에 대한 보고예요. 결과가 아니에요.

• 확인은 항상 결과 쪽에서 직접 세는 것이어야 해요. 저장했다는 로그 대신 실제 개수를 세고, 빌드 성공 화면 대신 실제 주소에 접속해요.

• 이건 AI를 못 믿어서가 아니에요. 사람이 짠 코드도, 제가 쓴 발표자료도 똑같이 틀려 있었어요.

Before — 4주 전의 저

7월 넷째 주에 시작할 때 제 상태는 이랬어요.

• 논문 16편이 하드디스크 폴더에 PDF로만 있었어요. 어느 논문에 무슨 내용이 있는지는 제 머릿속에만 있었고요.

• 개인 지식베이스를 만들려면 벡터DB가 정석이라고 알고 있었어요. 예전 프로젝트에서도 그렇게 만들었거든요.

• 웹사이트 배포는 해본 적이 없었어요.

일곱 번 속을 뻔한 순간들

1주차 ① — "정석"이 정석이 아니었어요

됐다는 신호: 인터넷 글 대부분이 "개인 지식베이스 = 벡터DB"라고 했어요.

실제: 조사해보니 지금 표준은 마크다운 파일과 검색 명령만으로 충분한 쪽이었어요. 노트가 500~1,000편을 넘어야 벡터가 의미 있다는 기준이 반복해서 나왔어요. 제 위키는 그때 8편이었어요.

확인한 방법: 하루한테 이렇게 물었어요.

"지금 시점에서 개인 지식베이스를 만들 때 벡터DB가 정말 필요한지, 최신 자료로 조사해줘. 몇 편 정도부터 필요해지는지 기준도 알려줘."

여기서 벡터를 안 쓰기로 결정한 게 4주 내내 제일 크게 아낀 시간이었어요.

1주차 ② — 아무것도 안 보여주는 출력을 "괜찮다"로 읽었어요

됐다는 신호: git status(어떤 파일이 저장 대기 중인지 보여주는 명령)를 실행했더니 문제될 게 안 보였어요.

실제: 이 명령은 폴더 안에 파일이 여러 개면 폴더 이름 하나로 뭉쳐서 보여줘요. 그 안에 논문 PDF가 들어 있었는지 아닌지가 화면에 아예 안 나온 거예요. 저는 그걸 "문제없음"으로 읽었고요.

이게 제일 아찔했어요. 틀린 걸 봤다면 다시 봤을 텐데, 아무것도 안 보여주는 출력은 문제가 없다고 읽히거든요. 확인하는 방법을 모르면 확인한 줄 알고 지나가요.

2주차 — 문서로 짠 계획이 진짜 돌아가는지 몰랐어요

됐다는 신호: PRD와 세부계획표와 폴더 구조 문서를 다 만들어뒀어요. 보기엔 완벽했죠.

실제: 문서는 "이렇게 하겠다"는 약속일 뿐이었어요.

확인한 방법: 논문 10편을 한꺼번에 넣지 않고 1편만 먼저 끝까지 통과시켰어요. 넣고, 사이트에 뜨는지 보고, 검색해서 답이 나오는지 보고, 그다음에 나머지를 늘렸어요. 1편에서 걸린 문제가 10편에서 걸렸으면 10배로 고쳐야 했을 거예요.

재사용 팁: AI에게 반복 작업을 시킬 때는 "일단 1개만 끝까지 해보고 보여줘"라고 먼저 말하세요. 통과하면 그때 "이 방식으로 나머지 다 해줘"라고 하면 돼요.

3주차 ① — "128개 저장 완료"인데 실제로는 0개였어요

됐다는 신호: 논문을 잘게 잘라 데이터베이스에 넣는 프로그램이 "128개 저장 완료"라고 찍었어요.

실제: 데이터베이스에서 직접 세어보니 0개였어요. 데이터베이스에 넣는 부분에서 형식이 안 맞아 조용히 실패했는데, 프로그램은 오류를 못 알아채고 성공했다고 출력한 거예요.

확인한 방법: 저장하는 쪽 로그를 보지 않고, 받는 쪽에서 개수를 셌어요.

SELECT count(*) FROM chunks;

count(*)는 "지금 여기 몇 개 있어?"를 묻는 명령이에요. 넣은 쪽이 뭐라고 말하든, 받는 쪽이 세어준 숫자가 진짜예요.

📷 여기에 "128개 저장 완료" 출력과 count() = 0 결과를 나란히 놓은 화면을 넣으면 좋아요.*

3주차 ② — 제가 공들여 만든 게 졌어요

됐다는 신호: 벡터 검색 파이프라인을 다 만들었어요. 논문을 자르고, 의미를 숫자로 바꾸고, 전용 데이터베이스에 넣는 것까지요. 최신 방식이니 당연히 더 좋을 거라 생각했어요.

실제: 같은 질문 10개로 채점했더니 벡터 9점, 기존 키워드 검색 21점(40점 만점). 제가 며칠 들여 만든 쪽이 더 나빴어요.

확인한 방법: 순서를 지킨 게 전부였어요. 벡터를 붙이기 전에 채점 기준부터 정하고, 기존 방식으로 먼저 점수를 매겨뒀어요.나중에 정했다면 결과에 맞춰 기준을 슬쩍 바꿨을지도 몰라요.

솔직히 실망스러웠어요. 그런데 그 결과를 포장하지 않고 그대로 기록했어요. 지금 돌아보면 4주 중 제일 잘한 일이에요.

재사용 팁: 새 기술을 도입할 때는 도입 전에 채점표를 만들고 지금 방식의 점수를 먼저 기록해두세요. 이걸 기준선(baseline)이라고 해요. 기준선이 없으면 새 기술이 좋아졌는지 나빠졌는지 말할 수가 없어요.

4주차 ① — 로컬 빌드가 성공했는데 배포는 실패했어요

됐다는 신호: 새 기능(그래프뷰·챗봇)을 만들고 npm run build를 돌렸더니 성공했어요. 올리고 나서 다 됐다고 생각했어요.

실제: "서버가 작동 안 하는 것 같은데"라는 말을 들었어요. 확인해보니 원인이 서로 다른 장애 3개가 겹쳐 있었어요. 배포 자체가 조용히 실패한 것, 사이트 설정에 적힌 주소가 실제 주소와 달랐던 것, 새로 넣은 패키지가 기존 설정과 버전이 충돌한 것.

확인한 방법: 코드를 고치기 전에 상태부터 봤어요.

vercel inspect <배포주소> --logs
curl -I https://learning-hub-virid.vercel.app

앞쪽은 배포 플랫폼에 "왜 실패했는지 그대로 보여줘"라고 묻는 명령이고, 뒤쪽은 실제 주소를 직접 두드려서 응답을 받아보는 명령이에요. 빌드 성공 화면은 제 컴퓨터 이야기고, 이 둘은 실제 서버 이야기예요.

세 번째 장애가 특히 배운 게 많았어요. 배포를 살리려고 Node 버전을 20으로 고정했는데, 새로 넣은 패키지가 22를 요구해서 방금 고친 설정과 부딪혔어요. 여기서 버전을 다시 올려 맞추는 대신 그 패키지를 아예 빼고 필요한 기능만 직접 호출하는 쪽을 골랐어요. 맞추려 할수록 꼬이는 상황에서는 하나를 없애는 게 나았어요.

이 이야기는 4주차 사례글에 절차까지 자세히 적어뒀어요.

4주차 ② — 코드로는 멀쩡한 버그였어요

됐다는 신호: 챗봇 구현을 AI(Codex)에게 맡기고 결과를 받았어요. 코드를 읽어보니 패널이 처음엔 닫혀 있게 되어 있었어요.

실제: 실제로 브라우저에 띄우니 패널이 처음부터 열려 있었어요. 웹에서 "이건 숨겨"라고 지정하는 기본 속성보다, 제가 준 디자인 규칙이 우선순위에서 이겨버려서 숨기기가 조용히 무시된 거예요.

확인한 방법: Playwright로 실제 화면을 띄워서 봤어요. 브라우저를 자동으로 열어 화면을 확인해주는 도구예요. 이건 코드를 아무리 읽어도 안 보이는 종류의 버그라, 띄워보는 것 말고는 방법이 없었어요.

📷 여기에 챗봇 패널이 처음부터 열려 있는 화면과 고친 뒤 화면을 넣으면 좋아요.

이번 구현은 설계·구현·검증을 각각 다른 담당으로 나눠서 했어요. 설계는 Claude가 문서로 쓰고, 구현은 Codex가 별도 프로그램에서 하고, 검증은 다시 Claude가 그 문서의 확인 명령을 직접 실행하는 방식이에요. 구현한 쪽이 스스로 "다 됐습니다"라고 하는 걸 증거로 인정하지 않겠다는 구조인데, 실제로 그 검증 단계에서 이 버그가 잡혔어요.

4주차 ③ — 제가 만든 발표자료가 틀려 있었어요

됐다는 신호: 발표 슬라이드 16장을 만들었어요. 제가 직접 확인하며 쓴 숫자들이었고요.

실제: 슬라이드를 다듬다가 숫자를 다시 조회해보니 2군데가 틀려 있었어요. 점검 항목 개수와 특정 개념에 연결된 논문 편수요. 슬라이드를 만든 뒤에도 작업이 계속됐는데, 그 사이 늘어난 숫자가 반영이 안 된 거예요.

확인한 방법: 슬라이드에 적힌 숫자를 하나씩 코드와 데이터에서 다시 세어봤어요.

이게 마지막 사례인 게 상징적이에요. 앞의 여섯 번은 인터넷 글이 틀렸거나, 도구가 틀렸거나, AI가 틀렸어요. 마지막 한 번은 제가 틀렸고요. 같은 확인 방법이 저한테도 그대로 적용됐어요.

그래서 만든 확인 체크리스트

4주치를 정리하니 확인 방법이 딱 세 가지로 모여요. 그대로 가져다 쓰셔도 돼요.

그리고 AI에게 작업을 맡길 때 쓰는 문장 하나요.

"완료했다는 말 대신, 결과를 직접 확인한 명령과 그 출력을 보여줘."

이 한 줄이 "완료했습니다"를 증거로 인정하지 않게 만들어줘요.

After — 4주 뒤

숫자보다 남은 게 더 분명해요. 성공했다는 말을 결과로 인정하지 않는 습관. 이건 이 프로젝트가 끝나도 다음 것에 그대로 가져갈 수 있어요.

마무리

시작할 땐 매주 새로운 걸 배우는 4주일 줄 알았어요. 실제로는 같은 걸 네 번, 점점 어려운 상대에게 배운 4주였어요. 1주차엔 인터넷 글이 틀렸고, 3주차엔 제가 공들여 만든 게 졌고, 4주차엔 제 발표자료가 틀렸어요.

삽질은 많았는데, 결국 다 되니까 뿌듯해요.