문서는 과거의 사진이다
문서는 쓰인 순간의 상태를 찍은 사진이다. 그 뒤로 대상은 계속 움직이지만 사진은 그대로 있다. 그런데 우리는 사진을 볼 때 지금 모습이라고 느낀다.
AI는 이 함정에 사람보다 더 잘 빠진다. 문서는 글이라서 읽기 쉽고, 대상을 재려면 파일을 열고 세어 봐야 하기 때문이다. 시키지 않으면 쉬운 쪽을 읽는다.
| 문서가 말하는 것 | 재보면 나오는 것 | |
|---|---|---|
| 시점 | 쓰인 때 | 지금 |
| 범위 | 쓴 사람이 중요하다고 본 것 | 전부 |
| 빠진 것 | 안 적힌 것은 없는 것처럼 보인다 | 있으면 나온다 |
| 읽는 비용 | 싸다 | 비싸다 — 그래서 안 한다 |
"문서에 적힌 값을 그대로 쓰지 말고, 실제 파일을 열어 확인해라. 문서와 다르면 실제 쪽을 기준으로 하고, 차이가 난 항목을 표로 따로 보여 줘."
마지막 문장이 중요하다. 차이 목록을 요구하면 대조를 건너뛸 수 없다. "확인했습니다"만으로는 정말 열어 봤는지 알 수 없다.
재는 방법 네 가지
1. 센다
가장 싸고 가장 잘 듣는다. 파일 개수, 줄 수, 항목 수. "문서에는 12개라고 적혀 있는데 실제로는 14개" — 이 한 줄이 나오는 순간 그 문서 전체를 다시 봐야 한다는 것을 안다.
2. 연다
요약된 설명 대신 실제 파일을 연다. "~로 되어 있다" 는 문장과 파일 안의 실제 값이 다른 경우는 놀랄 만큼 흔하다. 특히 나중에 손으로 한 번 고친 곳이 그렇다.
3. 맞대 본다
같은 내용이 두 곳에 있으면 두 곳을 나란히 놓고 본다. 한쪽만 고쳐진 것은 양쪽을 같이 봐야만 보인다. 한 곳씩 보면 둘 다 멀쩡해 보인다.
4. 돌려 본다
코드라면 실행하고, 화면이라면 브라우저로 열고, 게임이라면 한 판 한다. "논리적으로 맞다"와 "실제로 된다" 사이에는 늘 무언가가 하나 있다.
문서를 버리라는 말이 아니다
문서는 어디를 봐야 하는지를 알려 준다. 그것만으로도 충분히 값어치가 있다. 문제는 문서를 답으로 쓰는 것이지 문서 자체가 아니다.
| 문서의 올바른 쓰임 | 잘못된 쓰임 |
|---|---|
| 어디를 볼지 정한다 | 거기에 뭐가 있는지까지 결론 낸다 |
| 왜 이렇게 했는지 이유를 남긴다 | 지금 값이 얼마인지를 남긴다 |
| 바뀌면 같이 고친다 | 한 번 쓰고 둔다 |
값은 바뀐다. 이유는 잘 안 바뀐다. "군량 소모를 0.02로 했다" 는 다음 주면 틀린 문장이 되지만, "2~3분은 버티게 하려고 군량 소모를 잡았다" 는 한참 간다.
값이 궁금하면 파일을 열면 된다. 파일을 아무리 열어 봐도 안 나오는 것이 이유다. 문서에는 파일에서 못 얻는 것만 적는다.
대조를 습관으로 만드는 두 줄
작업 전:
"이 문서에 적힌 값들이 지금도 맞는지 실제 파일로 먼저 확인해 줘.
다른 것이 있으면 표로 보여 주고, 그다음에 진행하자."
작업 후:
"고친 뒤 실제로 열어서(또는 돌려서) 확인한 결과를 알려 줘.
무엇을 어떻게 확인했는지도 같이."두 줄 다 결과가 아니라 확인 방법을 묻는다. "확인했습니다"는 쓰기 쉽지만 "이렇게 확인했습니다"는 실제로 해야 쓸 수 있다.
정리 — 세 줄
- 문서는 과거의 사진이다. 어디를 볼지는 알려 주지만 답은 아니다.
- 재는 법 넷 — 센다 · 연다 · 맞대 본다 · 돌려 본다.
- 문서에는 값이 아니라 이유를 적는다. 값은 파일에 물으면 된다.
- 내가 가진 설명 문서(README, 설계 메모, 인수인계서 아무거나) 하나를 고른다.
- 이 편의 "작업 전" 한 줄로 문서의 값이 지금도 맞는지 실제 파일로 확인하게 한다.
- 차이 표가 나오면 문서를 고치되, 값보다 이유를 적는 쪽으로 고친다.
AI 가 문서를 읽고 "맞습니다" 라고 하기 쉬운 이유는?
문서는 읽기 쉽고 대상을 재는 것은 비싸다. 시키지 않으면 쉬운 쪽을 읽는다.
재는 방법 넷은?
센다 · 연다 · 맞대 본다 · 돌려 본다.
문서에는 무엇을 적나?
값이 아니라 이유. 값은 파일에 물으면 되고, 이유는 파일을 아무리 열어도 안 나온다.
다음 편은 재다가 잘못됐을 때를 위한 준비 — 되돌릴 수 있게 지우는 법이다.