[2주차 사례글] 내가 만든 검증 도구도 검증이 필요했습니다

1주차 회고를 이렇게 끝냈습니다. "이번 주에 만든 건 터라서 눈에 안 보였습니다. 2주차에는 화면에 보이는 게 나옵니다."

그 말대로 됐습니다. 2주차엔 논문 10편이 실제로 사이트에 떴고, 검색창에 단어를 치면 잡히고, 명령 한 줄로 점검이 되고, 질문 한 줄로 답이 나오고, 마지막엔 인터넷 어디서나 열리는 주소까지 생겼습니다.

그런데 이 글에서 진짜 하고 싶은 이야기는 그 결과물 목록이 아닙니다. 만든 걸 만들고 끝내지 않고, 다시 검증했더니 실제 버그가 나온 순간이 이번 주를 꿰는 진짜 이야기입니다. 일곱 장면으로 나눠서, 이번엔 실제로 쓴 명령과 나온 결과를 그대로 옮겨가며 풀겠습니다.

누구에게 도움이 될까요 — AI와 뭔가를 만들고 "됐다, 통과했다"에서 멈추는 게 불안한 분입니다. 코딩을 몰라도 읽을 수 있게 썼습니다.

그 전 — 1주차 끝의 저

문서만 있었습니다. 기획서(PRD), 실행계획(세부계획 12단계), 규칙집(SCHEMA.md). 전부 "이렇게 하겠다"는 약속이었고, 실제로 작동하는 건 하나도 없었습니다.

장면 1 — 논문 1편을 먼저 끝까지 통과시켰습니다

세부계획에 "논문 10편을 한꺼번에 넣지 말고, 1편을 먼저 끝까지 통과시켜 양식을 굳힌 뒤 늘린다"고 미리 적어뒀습니다. 이유가 있었습니다 — 양식이 틀린 채로 10편을 넣으면 10편을 다 고쳐야 하니까요.

그대로 했습니다. BNNT 리뷰 논문 하나로 SCHEMA의 일곱 칸을 다 채웠는데, 그중 여섯 번째 칸이 제일 손이 많이 갔습니다.

## 6. 한계

**저자가 밝힌 한계**: 별도의 "Limitations" 절은 없지만, 결론(§3 Summary)에서
"합성법들이 BNNT의 질과 양을 크게 개선했지만, 동시에 비정질 붕소·질화붕소·
h-BN 같은 부산물이 생겨 순도를 떨어뜨리는 부작용이 있다"고 명시했다.

**읽으면서 느낀 한계**:
- 다섯 가지 합성법을 수율·순도·비용 기준으로 나란히 비교한 정량 표가 없다.
- BNNT의 TEM 관찰·특성분석 자체를 다루는 절이 없다 — 지금 제 관심사인
  TEM 이미지 분석 쪽과는 직접 연결되지 않는다.

SCHEMA.md가 이 칸을 이렇게 못박아둔 이유를 그제야 이해했습니다: "논문 요약 도구 대부분이 결과만 뽑고 한계는 버린다. 그런데 이 방법을 내가 진짜 쓸 수 있나를 판단할 때 결정적인 건 한계다." 실제로 써보니 정말 그랬습니다 — 결과만 봤으면 "좋은 논문이네"로 끝났을 텐데, 한계를 억지로 채우면서 "TEM 관찰을 안 다룬다"는, 제 관심사와 안 겹치는 지점까지 스스로 알아챘습니다.

양식을 굳힌 다음엔 사이트 검색창(astro-pagefind)을 붙였습니다. 인터넷 글은 전부 부품 두 개를 따로 설치하라고 했지만, 실제 등록 정보를 열어보니 최신 버전은 하나가 다른 하나를 이미 품고 있었습니다.

npm i astro-pagefind

이 한 줄로 끝났습니다. (1주차부터 반복된 패턴입니다 — 인터넷 글은 쓰인 시점에 멈춰 있고, 등록 정보가 지금을 보여줍니다.)

장면 2 — 논문을 늘리다가 페이월에 세 번 막혔습니다

논문을 4편, 그다음 10편까지 늘리는 중이었습니다. 마지막 AI 논문 자리에 SHINE(TEM 이미지 디노이징 논문)을 넣으려는데, PDF가 페이월에 막혀 있었습니다.

1차 — 직접 다운로드

curl -sL -o "shine.pdf" "https://www.science.org/doi/pdf/10.1126/sciadv.ads5552"

결과: PDF가 아니라 5.4KB짜리 HTML 껍데기만 왔습니다. 페이지가 JS로 렌더링되는 방식이라 curl로는 겉모습만 받아지는 것이었습니다.

2차 — PMC(오픈액세스 미러)

Science Advances는 원래 오픈액세스 저널이라 PMC에 무료 사본이 있을 거라 생각했는데, curl로 검색하니 빈 결과만 나왔습니다.

3차 — 대학 리포지토리

curl -sL -o "shine.pdf" "https://scholarworks.bwise.kr/erica/bitstream/.../....pdf"

이번에도 657바이트짜리 HTML만 받아졌습니다.

세 번 다 막히니 AI가 더 파고들지 않고 이렇게 멈췄습니다: "이 세 경로를 시도했는데 다 막혔습니다. 못 구했습니다." 제가 브라우저로 직접 로그인해서 받은 다음, 로컬 파일 경로(~/Downloads/sciadv.ads5552.pdf)만 알려주니 AI가 그 경로에서 바로 읽어 논문 노트를 완성했습니다. 자동화 시도 3번(각 1~2분)과 사람이 직접 받아 넘긴 몇 분을 더해도, 계속 다른 우회로를 찾아 헤맸을 때보다 훨씬 빨랐습니다. (더 자세한 과정은 페이월 사례글에 있습니다.)

여기서 배운 개념: "오픈액세스"라는 말이 "자동화 도구로 바로 받을 수 있다"는 뜻은 아니라는 것입니다. 사람이 브라우저로 열면 문제없이 보이는 페이지도, curl 같은 자동화 요청은 봇 차단(JS 챌린지)에 걸려 껍데기만 받는 경우가 있었습니다.

장면 3 — 개념 페이지 하나로 소재·바이오·AI가 이어졌습니다

논문 노트를 그냥 쌓기만 하면 흩어진 자료입니다. 여기서 처음 만든 개념 페이지 "TEM(투과전자현미경) 관찰"이 그 흩어진 걸 잇는 첫 실이었습니다.

같은 도구(TEM)라도 리뷰·in-situ 관찰·품질 검증·이미지 자체의 노이즈
제거라는 네 가지 다른 역할로 쓰인다는 게, 이 개념 페이지가 논문 노트만
따로 읽어서는 안 보이던 연결을 만들어준다. 소재·바이오·AI 세 주제가
전부 이 개념 하나로 묶인다.

• BNNT 리뷰(소재): 합성법마다 "정말 나노튜브가 만들어졌는지" 사후 확인

• 페로브스카이트(소재): 가열하며 "분해되는 과정 자체"를 실시간 촬영

• 오소리기름 항균 나노섬유(바이오): "은나노입자가 잘 분산됐는지" 검증

• SHINE(AI): "TEM 이미지 자체의 노이즈를 어떻게 없앨지"가 논문의 핵심

같은 도구를 완전히 다른 목적으로 쓰는 논문 네 편이 한 페이지에 모이는 걸 보고, 세부계획에 적어뒀던 "개념 페이지는 주제 다른 논문 여러 편이 걸릴 때 값이 생긴다"는 말이 그냥 문서 속 문장이 아니라는 걸 실감했습니다. (뒤에서 나오지만, 이때는 이 넷 말고 세 편이 더 걸려 있어야 했는데 빠져 있었습니다 — 장면 5에서 이어집니다.)

장면 4 — 논문 10편을 직접 넣어보고 신기했습니다

6단계에서 남은 6편(소재2·바이오2·AI2)을 더 넣어 총 10편을 채웠습니다. 이번 주를 돌아보며 제일 기억에 남는 걸 골라보라고 했을 때, 저는 망설임 없이 **"직접 나의 자료 논문 10편을 시도해본 것"**을 꼽았습니다. 이유를 물었더니 답은 짧고 명확했습니다 — "직접 작동하는 것을 보면서 신기했다."

계획을 문서로 짤 때보다, 내 자료가 실제로 사이트에 뜨고 검색되고 질문에 답하는 걸 눈으로 볼 때가 훨씬 크게 와닿았다는 것입니다. 이게 왜 중요하냐면, 1주차 회고에서 "개념을 먼저 잡아두는 게 시간 낭비가 아니었다"고 적었는데, 2주차는 그 반대쪽 확인이었기 때문입니다 — 개념을 아무리 잘 잡아도, 실제로 돌려봐야 진짜인지 압니다.

장면 5 — 점검 도구를 만들었는데, 그 도구 자체가 허술했습니다

여기가 이번 주의 진짜 전환점입니다.

논문 10편, 개념 페이지 1개까지 쌓이니 SCHEMA 규칙(빈 칸 없이 채우기, 원문에 없는 문장 인용 금지, 위키링크 양방향 연결)을 매번 눈으로 확인하기 버거워졌습니다. 그래서 점검 명령 knowledge/lint.mjs를 만들었습니다. 만들고 나서 그냥 믿지 않고, 일부러 문제 4개를 심은 가짜 논문 파일로 테스트했습니다.

npm run lint:knowledge

## 빈항목 (1건)
  - 2099-test-broken.md — '## 6. 한계' 항목이 비어있음
## 끊긴링크 (1건)
  - 2099-test-broken.md — /papers/no-such-paper 대상 페이지 없음
## 인용확인필요 (1건)
  - 2099-test-broken.md — 원문에서 못 찾음: "이건 원문에 절대 없는..."
총 3건 발견.

넷 다 잡혔고, 실제 논문 10편은 문제 0건이었습니다. 여기서 끝냈으면 좋은 하루였을 겁니다. 그런데 이렇게 물어봤습니다.

지금까지 만든 걸 봐줘. 돌아가긴 하는데 어딘가 허술한 것 같아.
어디가 부족한지 짚어주고, 그중 지금 고치면 제일 효과 큰 것부터 알려줘.

1순위로 나온 답이 뜻밖이었습니다 — "링크가 죽었는지 확인하는 것"과 "링크가 SCHEMA §7의 양방향 규칙대로 걸려 있는지 확인하는 것"은 완전히 다른 검사인데, lint가 후자를 아예 안 보고 있다는 지적이었습니다. 실제 데이터를 열어봤습니다.

awk '/## 관련 개념/,0' src/content/papers/*.md | grep -c "tem-observation"
# → 7편이 tem-observation으로 링크를 걺

논문 쪽은 7편이 링크를 걸고 있었는데, 개념 페이지 "TEM 관찰" 쪽 "어느 논문에서 나왔나" 절에는 4편(BNNT 리뷰·페로브스카이트·오소리기름· SHINE)만 돌아오는 링크가 있었습니다. BNNT 이중성장·BNNT 벽수제어(겸 수질정화)·Ag-ZnO 광촉매 항균, 이 세 논문이 개념 페이지 쪽에서 안 잡혀 있었던 것입니다. 점검을 통과했다는 사실이, 정작 그 점검이 안 보는 종류의 문제까지 숨겨버린 셈이었습니다.

검사 항목을 두 개 더 추가했습니다.

## 일방통행 (3건)
  - 2015-adhikari-agzno-photocatalyst.md → /concepts/tem-observation
    링크는 있는데, tem-observation.md에는 이 논문으로 돌아오는 링크가 없음
  - 2019-kim-bnnt-dual-growth.md → /concepts/tem-observation
    링크는 있는데, tem-observation.md에는 이 논문으로 돌아오는 링크가 없음
  - 2020-cho-bnnt-water-purification.md → /concepts/tem-observation
    링크는 있는데, tem-observation.md에는 이 논문으로 돌아오는 링크가 없음
총 3건 발견.

정확히 예상한 3건이 잡혔습니다. 개념 페이지에 빠진 역링크 3개를 채운 뒤 다시 돌리니 문제 0건이 됐습니다. 여기에 하나 더 — 원본: frontmatter 값이 실제 파일과 일치하는지 대조하는 검사도 추가해서, 지금은 lint가 빈항목·끊긴링크·인용확인필요·일방통행·원본불일치 5가지를 봅니다.

장면 6 — 질문하면 답+출처+원문 인용이 같이 나오는 걸 확인했습니다

lint 다음은 세부계획 8단계 — 질문 명령이었습니다. 벡터 검색은 3주차 몫이라, knowledge/ask.mjs는 키워드로 먼저 만들었습니다. 실제로 물어봤습니다.

npm run ask:knowledge -- "BNNT 수율"

1. Boron nitride nanotubes: synthesis and applications (논문, 점수 61)
   출처: /papers/2018-kim-bnnt-synthesis
   답(2. 연구문제): "BNNT는 1995년 첫 합성 이후 CNT에 비해 수율과 품질이
   낮아 실용화가 막혀 있었는데, 지금까지 어떤 합성법들이 이 문제를
   얼마나 풀었고 어떤 응용까지 왔는가"를 정리하는 것이 목적이다.
   원문 인용: "Since BNNT was first synthesized in 1995, developing
   efficient BNNT production route has been a significant issue due
   to low yield and poor quality in comparison with CNT..."

한 줄 명령에 답(발췌)·출처 논문·원문 인용 세 가지가 다 나왔습니다. "TEM 디노이징"으로도 물어봤는데, 이번엔 SHINE 논문뿐 아니라 개념 페이지("TEM 관찰")까지 같이 잡혔습니다 — 장면 3에서 만든 개념 페이지가 검색 결과에도 도움이 되는 걸 처음 확인한 순간이었습니다.

장면 7 — GitHub에 올리고, 배포까지 끝냈습니다

마지막으로 지금까지 만든 걸 실제로 인터넷에 올렸습니다.

git push origin main
vercel --prod --yes

Production: https://learning-m1gd46115-jun-hee-kim-s-projects.vercel.app [23s]
Aliased: https://learning-hub-virid.vercel.app [23s]

배포 로그에 주소가 두 개 뜨는 게 눈에 띄었습니다. 하나는 이번 배포 하나에만 붙는 일회용 스냅샷 주소였고, 다른 하나(learning-hub-virid. vercel.app)는 "지금 프로덕션은 이거야"라고 가리키는 고정 별칭 (alias)이었습니다. 1주차에 옛 배포 URL 7개를 찾아 지웠던 이유가 바로 이 스냅샷 주소들이 배포할 때마다 계속 새로 생기기 때문이었는데, alias 방식 덕분에 사람들에게는 항상 같은 주소 하나만 알려주면 된다는 걸 다시 확인했습니다.

배포 뒤엔 실제로 접속해서 확인했습니다.

curl -s -o /dev/null -w "HTTP %{http_code}\n" https://learning-hub-virid.vercel.app
# HTTP 200

프로젝트 카드 페이지(/projects/my-knowledge-system)에 들어가보니 "작업 기록" 아래에 이번 주 사례글까지 자동으로 붙어 있었습니다 — 사례글 프론트매터에 프로젝트: my-knowledge-system만 적으면 알아서 연결되는 구조를 1주차에 만들어뒀는데, 그게 그대로 작동했습니다.

그래서 어떻게 됐나

배운 것

점검 도구가 있다는 사실 자체가 안심의 근거가 되면 안 됩니다. "lint를 돌렸는데 통과했다"는 "그 lint가 보는 항목에 한해" 문제가 없다는 뜻일 뿐입니다. 애초에 안 보는 종류의 문제는 통과와 상관없이 그대로 숨어 있을 수 있습니다. 제가 처음 만든 lint는 "링크가 존재하는가"만 봤고 "링크가 규칙대로 쌍을 이루는가"는 안 봤는데, 그 틈에 실제 버그가 몇 시간째 있었습니다.

"다 됐어?"보다 "허술한 데 짚어주고, 효과 큰 것부터"가 훨씬 나은 질문이었습니다. 그냥 봐달라고 하면 막연한 확인으로 끝나기 쉬운데, 우선순위를 매겨달라고 구체적으로 물으니 실제로 고칠 가치가 있는 지점을 순서대로 받을 수 있었습니다.

AI도 세 번 막히면 넷째부터는 사람에게 넘기는 게 맞습니다. 페이월 사건에서, AI가 계속 다른 우회로를 찾는 대신 "이 세 경로를 시도했는데 다 막혔다"고 구체적으로 보고했습니다. 제가 브라우저 로그인 한 번으로 몇 분 안에 풀렸으니, 그 판단이 맞았습니다.

결과물보다 태도가 남았습니다. 논문 10편, 점검 명령, 질문 명령, 배포 주소 — 이 목록보다, "만든 걸 믿지 않고 다시 검증하는 습관"이 이번 주 진짜 수확입니다.

가져가서 쓰세요

만든 걸 다시 검증받는 프롬프트

만들고 나서 "됐다"로 끝내지 말고 이렇게 물어보세요. 우선순위가 있는 답이 옵니다.

지금까지 만든 걸 봐줘. 돌아가긴 하는데 어딘가 허술한 것 같아.
어디가 부족한지 짚어주고, 그중 지금 고치면 제일 효과 큰 것부터 알려줘.

점검 도구 자체를 점검하는 체크리스트

• 검사 항목마다 "이게 정확히 뭘 보고, 뭘 안 보는지" 한 줄로 적을 수 있습니까? (못 적으면 항목이 애매한 것입니다)

• 일부러 틀린 데이터를 만들어서 진짜로 잡히는지 테스트했습니까?

• "존재하는가"와 "관계가 규칙대로 완전한가(양방향 등)"를 따로 구분해서 검사합니까?

• 만든 뒤 다시 검토를 요청했습니까? (같은 사람/AI가 "됐다"고 끝내지 않기)

AI가 파일을 못 받아올 때 체크리스트

• 직접 URL 다운로드를 시도했습니까? (curl -sL -o 파일명 URL)

• 받은 파일이 진짜인지 확인했습니까? (file 파일명 — "HTML"이면 실패)

• 오픈액세스 미러(PMC·arXiv 등)도 시도했습니까?

• 몇 번까지 시도하고 사람에게 넘길지 미리 정해뒀습니까? (저는 3번이 적당했습니다)

배포 확인 체크리스트

• 배포 로그의 "Production"과 "Aliased" 주소가 다르다면, 사람들에게는 Aliased(고정) 주소를 알려주세요.

• 배포 후 curl -s -o /dev/null -w "%{http_code}"로 실제 응답 코드를 확인하세요.

• 새로 추가한 페이지가 실제로 열리는지 주소 하나는 직접 열어보세요.

다음 주

이미 세부계획에 3주차가 정해져 있습니다. 평가 질문 10개와 채점 방식을 먼저 확정하고(벡터를 붙이기 전에 채점 기준부터 정해야 결과를 부풀리지 않는다는 원칙), 지금 만든 ask.mjs(가벼운 검색)로 먼저 기준 점수를 매긴 다음, 벡터 검색을 얹어서 같은 질문으로 비교합니다.

이번 주에 제일 크게 배운 건 결과물이 아니라 태도였습니다. 만든 걸 믿지 않고 다시 검증하는 습관, 그게 다음 주에도 그대로 갑니다.