실전 사례 셋

사례 ① 접속 기록 읽기

문제

직접 돌리는 웹서버는 하루에도 수천 줄씩 접속 기록을 남긴다. 그 안에는 실제 방문자도 있고, 자동으로 긁어 가는 로봇도 있고, 오류도 섞여 있다. 열어 보면 한 줄이 이런 식이다 — 사람이 눈으로 읽을 물건이 아니다.

{"t":"2026-09-16T08:12:44","st":404,"u":"/wp-login.php","c":"CN", ... }

접근

1. 해석부터 확인했다. 도구를 만들기 전에 "이 기록의 각 항목이 무엇을 뜻하는지 표로 정리해 달라"고 시켰다. 여기서 내가 잘못 알고 있던 항목이 두 개 나왔다.
2. 궁금한 것을 먼저 정했다. "무엇을 얼마나 보는가", "어느 나라에서 오는가", "없는 주소를 찾는 요청이 얼마나 되는가" — 세 가지로 좁혔다.
3. 개인정보는 애초에 안 남겼다. 방문자 IP 는 기록 자체에서 뺐다. 없으면 새어 나갈 일도, 지켜야 할 일도 없다.
4. 하루치로 접어 두게 했다. 원본은 2주 뒤 자동으로 지우고, 접힌 요약만 남긴다.

사례 ② 자료 교차 확인

문제

오래된 게임을 다시 만드는 작업에서는 같은 내용이 여러 곳에 흩어진다 — 기획 메모, 데이터 파일, 그리고 실제로 돌아가는 코드. 셋이 어긋나면 게임이 이상하게 동작하는데, 어디가 어긋났는지는 한참 뒤에야 드러난다.

접근

1. 무엇을 볼지 목록으로 먼저 적었다. 확인 항목이 곧 요구사항이 된다.
2. 셋을 각각 읽어 같은 모양으로 정리했다. 이름 · 값 · 나온 곳. 모양이 같아야 비교가 된다.
3. 서로 겨눠 차이만 뽑았다. 맞는 것은 보여 주지 않는다. 사람이 볼 것은 다른 것뿐이다.
4. 절차를 스킬로 굳혔다. 다음부터는 파일 세 개만 주면 같은 순서로 돈다.

사례 ③ 이 사이트의 AI 소식

문제

AI 소식은 하루에도 수십 건씩 쏟아진다. 다 보려면 시간이 안 되고, 안 보면 흐름을 놓친다. 필요한 것은 전부가 아니라 하루 다섯 줄이었다.

접근

1. 모으는 일과 고르는 일을 나눴다. 서버가 3시간마다 국내·해외·영상 피드를 긁어 후보를 쌓는다 — 판단이 필요 없는 일이다.
2. 고르는 일만 맡겼다. 매일 아침 예약 작업이 후보에서 다섯을 골라 원문을 읽고 한국어 요약과 "왜 중요한가"를 붙인다.
3. 실패했을 때 무엇이 남는지 정했다. 예약이 안 돌면 서버가 점수로 고른 자동 선별분이 그대로 보인다.
4. 표시로 구분했다. 사람이 고른 날은 CURATED, 자동인 날은 AUTO 배지가 붙는다. 읽는 쪽이 신뢰도를 알 수 있게.

셋의 공통점

• 규칙이 적혀 있었다. 없었다면 그것부터 적는 일이 1단계였을 것이다.
• 해석을 먼저 확인했다. 만들기 전에 "내가 이렇게 이해했다"를 표로 받아 봤다.
• 출력을 줄였다. 맞는 것은 안 보여 준다. 사람이 볼 것만 남긴다.
• 실패했을 때의 상태를 정했다. 안 도는 날에도 무언가는 남아 있게.

정리 — 세 줄

1. 자동화가 쉬운 일은 규칙이 이미 적혀 있는 일이다.
2. 만들기 전에 해석이 맞는지 표로 받아 확인한다.
3. 출력을 줄이는 것도 기능이고, 실패했을 때 남는 것도 설계다.