직접 해 본 결과만 적습니다 · 확인하지 못한 것은 그렇게 표시합니다
써 AI 마케팅 적용기 시중에 나온 AI 방법을 실무에 넣어 보고, 쓸만한지 남깁니다
처음이라면

일부를 보고 전체를 단정한 실수를 하루에 다섯 번 했습니다 — 확인 절차로 막는 법

계속 쓴다2026-08-10·읽기 6분·글 써봄

하루를 정리하다 보니 같은 유형의 실수를 다섯 번 했습니다. 전부 같은 모양이었습니다.

일부를 보고 전체를 단정했습니다.

AI검수를 만들 때든 일하는법을 정할 때든, 이건 능력 문제가 아니라 확인 절차가 없었던 것이었습니다.

1. "전부" 라는 말을 쓰기 전에 멈춥니다 2. 실제로 몇 개를 봤는지 셉니다 3. 전체가 몇 개인지도 셉니다 4. 둘을 같이 말합니다

AI검수·일하는법에서 반복된 모양

일부만 보고 전체를 단정한 사례들을 정리한 터미널 화면

한 말 실제로 본 것
"파일이 전부 정상입니다" 30개 중 3개
"로그에 오류가 없습니다" 4,000줄 중 앞 20줄
"그 경로는 안 씁니다" 검색을 한 폴더에서만 함
"이 값은 항상 양수입니다" 몇 번 돌려보고 그렇게 판단
"설정이 반영됐습니다" 파일만 확인하고 실행 상태는 안 봄

전부 거짓말은 아니었습니다. 본 범위 안에서는 맞는 말이었습니다. 문제는 본 범위를 안 밝힌 것입니다.

듣는 쪽은 "전부 봤구나" 로 이해합니다. 그래서 나중에 문제가 나오면 신뢰가 무너집니다.

왜 반복되나 — 확인 절차가 없었다

원인 — 확인이 적당히 하면 되는 것으로 돼 있었기 때문입니다. 몇 개를 봐야 하는지 정해진 게 없으니, 그럴듯해 보이는 만큼 보고 멈춥니다.

그리고 몇 개를 봤는지 안 세면 스스로도 얼마나 봤는지 모릅니다. 세 개를 보고도 "충분히 봤다" 는 느낌이 듭니다.

저는 이걸 "다음엔 더 조심하자" 로 넘기려 했습니다. 그러고 그날 또 했습니다. 조심은 절차가 아닙니다.

다섯 번을 늘어놓고 보니 공통점이 하나 더 있었습니다. 전부 시간이 없다고 느낄 때 났습니다. 빨리 답해야 한다고 생각하면 본 만큼만 말하게 됩니다.

그래서 절차를 만들 때도 시간이 안 드는 것으로 잡았습니다. "몇 개 중 몇 개" 를 붙이는 건 몇 초면 됩니다. 전부 다시 확인하는 절차였다면 바쁠 때 또 건너뛰었을 겁니다.

말투에 단서가 있습니다

해결 — 특정 단어를 쓰려는 순간이 멈출 지점입니다.

단정하는 표현을 쓰기 전에 멈추는 지점을 정리한 터미널 화면

이 말을 쓰려 할 때 물어볼 것
전부 / 모두 정말 전부 봤나? 몇 개 중 몇 개?
없습니다 어디까지 찾아봤나?
항상 / 절대 몇 번 확인했나? 예외 조건은?
확인했습니다 무엇을 어떻게 확인했나?

저는 이 네 단어를 쓸 때 한 번 멈추는 습관을 들이고 있습니다. 완전히 없어지진 않았는데 확실히 줄었습니다.

조심하는 대신 세어서 말합니다

해결 — 표현을 바꾸는 게 아니라 숫자를 붙입니다.

조심하는 방식과 세어서 말하는 방식을 비교한 터미널 화면

전 후
"파일이 전부 정상입니다" "30개 중 3개를 열어봤고 그 셋은 정상입니다"
"로그에 오류가 없습니다" "최근 200줄에 오류 없음. 전체는 4,000줄"
"그 경로는 안 씁니다" "이 폴더에서 검색한 결과 안 나옴. 다른 폴더는 미확인"

숫자를 붙이면 스스로도 알게 됩니다. "30개 중 3개" 라고 쓰려는 순간 "이걸로 전부라고 해도 되나" 가 자연스럽게 떠오릅니다.

전체를 봐야 하면 기계로 셉니다

대안 — 표본으로 충분한 경우가 있고 전부 봐야 하는 경우가 있습니다. 후자면 사람이 보지 말고 세게 합니다.

# 나쁨: 몇 개 열어보고 판단
# 좋음: 전부 확인하고 개수를 남긴다
total=0; bad=0
for f in data/*.json; do
  total=$((total+1))
  python3 -c "import json,sys; json.load(open('$f'))" 2>/dev/null || bad=$((bad+1))
done
echo "$total 개 중 $bad 개 이상"

사람이 30개를 열어보는 것보다 이게 빠르고 정확합니다. "전부" 라고 말하려면 전부 세야 하고, 세는 건 기계가 잘합니다.

로그도 마찬가지입니다. 앞 20줄을 보는 대신 전체에서 오류만 뽑아 세면 됩니다.

grep -c "ERROR\|Traceback" logs/app.log

저는 이 한 줄을 알기 전까지 tail -50 으로 끝부분만 보고 판단했습니다. 끝부분에 없으면 없다고 봤는데, 문제는 대개 중간에 한 번 나고 지나갑니다.

파일이 여러 개면 이렇게 셉니다. 개수가 나오면 "전부" 라고 말할 근거가 생깁니다.

find logs -name "*.log" | wc -l          # 전체 몇 개인지
grep -rl "ERROR" logs/ | wc -l           # 그중 오류가 있는 건 몇 개인지

"30개 중 3개에 오류" 라고 말할 수 있게 되는 것이 목적입니다. 정확한 표현은 정확한 숫자에서 나옵니다.

자주 쓰는 세는 명령

제가 실제로 쓰는 것들입니다. 외워 두면 "전부" 를 근거 있게 말할 수 있습니다.

세고 싶은 것 명령
파일 개수 ls data/*.json \| wc -l
그중 조건에 맞는 것 grep -l "ERROR" logs/*.log \| wc -l
특정 문자열 등장 횟수 grep -c "Traceback" app.log
응답 코드별 개수 awk '{print $9}' access.log \| sort \| uniq -c
코드에서 호출 지점 grep -rn "publish(" --include="*.py" . \| wc -l

마지막 줄이 특히 자주 씁니다. "그 함수는 한 군데서만 부릅니다" 라고 말하기 전에 세어 보면, 대개 두세 군데 더 나옵니다.

응답 코드도 마찬가지입니다. 200 만 몇 개 보고 "정상입니다" 라고 하지 말고, 4xx 와 5xx 가 몇 개인지 세는 편이 정확합니다.

지적받으면 대개 스스로 찾습니다

주의 — 흥미로운 점이 있었습니다. "그거 전부 확인한 거 맞아?" 라는 지적을 받으면, 다시 보고 스스로 빠진 것을 전부 찾아냈습니다.

능력이 없어서 놓친 게 아니었습니다. 멈춰서 다시 보는 계기가 없었을 뿐입니다.

저는 그 지적을 받고 다시 봤을 때, 빠진 것을 찾는 데 몇 분도 안 걸렸습니다. 이미 어디를 봐야 하는지 알고 있었던 겁니다. 몰라서 못 한 게 아니라 안 해서 못 한 것이었습니다.

그래서 고치는 방향도 "더 잘하자" 가 아니라 "멈추는 지점을 만들자" 가 됐습니다. 위의 네 단어가 그 지점입니다.

이 방식의 좋은 점은 남이 확인해 줄 필요가 없다는 것입니다. 지적을 기다리는 대신 스스로 멈춥니다. 저는 요즘 보고를 쓰다가 "전부" 를 타이핑하는 순간 손이 멈춥니다.

확인 못 한 것

표본을 몇 개 보면 충분한지는 기준을 못 잡았습니다. 전부 세는 게 항상 가능한 건 아니고, 그때 몇 개를 봐야 하는지 모르겠습니다.

대상의 성격에 따라 다를 것 같은데, 지금은 "전부 못 봤으면 그렇게 말한다" 로만 처리하고 있습니다. 개수 기준을 세우는 건 아직 못 했습니다.

판정 — 계속 쓴다

숫자를 붙여 말하는 방식은 효과가 있었습니다. 표현만 바꾸는 게 아니라 스스로 확인 범위를 인식하게 됩니다.

네 단어에서 멈추는 습관도 그렇습니다. 완전히 없어지진 않았지만 눈에 띄게 줄었습니다.

전부 봐야 하면 기계로 세는 것이 제일 확실했습니다. 사람이 꼼꼼히 보는 것보다 빠르고 정확합니다.

직접 하실 분께

하나. 전부 / 없습니다 / 항상 / 확인했습니다 를 쓰려 할 때 한 번 멈추세요.

둘. "몇 개 중 몇 개" 를 같이 말합니다. 이것만으로 대부분 걸러집니다.

셋. 전부 확인해야 하면 기계로 셉니다. 사람이 표본으로 보고 "전부" 라고 하지 않습니다.

넷. 지적을 받으면 대개 스스로 찾습니다. 멈추는 지점을 만드는 것이 실력을 올리는 것보다 빠릅니다.

다음에는 전부 못 볼 때 표본을 몇 개 봐야 충분한지 기준을 세워보려고 합니다. 되면 이어서 적겠습니다.