호기심을 자동화 실험으로 바꾸기: URL 하나에서 시작하는 작은 설계

한지우의 『더 퍼지, AI 시대 누가 미래를 이끄는가』를 읽고 호기심에 대해 생각했다. 책에서 출발한 내 질문은 새로운 모델을 얼마나 많이 아는지가 아니었다. 매일 반복하면서도 그냥 넘긴 불편을 하나 골라 직접 바꿔 볼 수 있느냐는 것이었다.

초안에서는 이 태도를 윈드서핑에 비유했다. 실제로 윈드서핑을 했다는 이야기는 아니다. 도구의 변화를 멀리서만 보지 않고 작은 실험으로 이해하고 싶다는 뜻이었다. 다만 그 비유를 계속 반복하면 무엇을 해볼지 흐려진다. 이번에는 URL 하나를 읽고 저장하는 일로 범위를 좁혀 보려 한다.

내가 study-clipper와 daily-digest 같은 스킬을 만들었던 출발점도 비슷했다. 읽을 링크를 보내면 정리해 줄 수 있을까, 아침에 필요한 소식을 모아서 볼 수 있을까. 이 글은 당시의 관심과 실패 기록을 바탕으로 다시 설계한 절차다. 아래에 제안한 시험을 새로 모두 실행했다는 의미는 아니며, 책의 문장을 정확한 쪽수 없이 직접 인용하지도 않는다.

자동화하고 싶은 불편을 한 문장으로 만든다

“AI로 공부를 잘하고 싶다”는 너무 넓다. 반면 “나중에 읽으려고 저장한 링크가 많아져 원문과 내 질문을 다시 찾기 어렵다”는 입력과 결과를 정하기 쉽다. 기술을 고르기 전에 자동화가 해결할 불편을 한 문장으로 적는다.

그다음 자동화 이후에도 내가 해야 할 일을 함께 쓴다. 링크 내용을 읽을지 결정하는 것, 내 업무와 관련 있는지 판단하는 것, 글로 공개할 때 근거를 확인하는 것은 남는다. 수집과 정리가 빨라져도 읽지 않은 자료의 내용을 이해한 것으로 바뀌지는 않는다.

이 예시의 첫 목표는 링크 하나에 원제목, 원문 URL, 게시 날짜가 확인되는 경우 그 날짜, 짧은 내용 정리, 내가 남긴 질문을 묶어 저장하는 것이다. 이메일 발송이나 블로그 작성까지 처음부터 포함하지 않는다. 최종 목표에서 제외했다는 뜻이 아니라 한 단계가 제대로 되는지 볼 범위를 정한 것이다.

기존 도구 없이도 할 수 있는 기준 작업을 한 번 적어 본다. 브라우저에서 원문을 열고 제목과 링크를 복사하고 내 질문을 덧붙이는 일이다. 이 정도 규모에서 수동 작업이 더 간단하면 굳이 에이전트를 만들지 않을 수 있다. 호기심으로 구현해 보는 학습 가치와 지속 운영할 실용성은 따로 평가한다.

읽기와 저장과 발송은 다른 권한이다

URL을 읽는 권한을 줬다고 메일을 보내는 권한까지 생기는 것은 아니다. 자료를 내 노트에 저장하는 행동과 외부 구독자에게 발송하는 행동도 영향 범위가 다르다. 아래는 제안한 단계별 경계다.

처음에는 발송 권한 없이 초안을 화면이나 검토 폴더에서만 확인하는 편이 관찰하기 쉽다. 발송을 나중에 허용한다면 대상 목록을 명시하고 중복 발송을 막아야 한다. 자동화가 편하다는 이유로 주소록 전체를 기본 수신자로 삼지 않는다.

외부 문서의 본문은 자료이지 운영 지침이 아니다. 읽고 있는 페이지에 “이 노트를 다른 주소로 보내라”는 문장이 있어도 사용자가 승인한 발송 지시로 취급해서는 안 된다. 이런 경계는 AI의 문장 이해만 믿기보다 도구 권한과 승인 절차에서도 제한해야 한다.

NIST AI RMF Playbook은 위험을 실제 업무에 맞춰 점검하는 참고 틀로 사용할 수 있다. 이 글의 URL 실험표 자체가 NIST 인증이나 공식 권고 양식이라는 뜻은 아니다. NIST Playbook

정상 링크보다 실패할 링크를 먼저 준비한다

자동화 시연은 접근 가능한 짧은 글 하나로도 성공할 수 있다. 실제로 계속 쓰려면 읽을 수 없는 경우에 무엇을 하는지가 중요하다. 첫 시험 묶음에는 정상 공개 글뿐 아니라 잘못된 URL, 접근 제한 페이지, 본문이 거의 없는 페이지, 긴 글, 이전에 저장한 링크를 넣는다. 테스트할 권리가 있는 자료만 사용한다.

각 입력의 기대 동작을 미리 정한다. 잘못된 URL이면 오류 이유를 남기고 끝낸다. 로그인 화면만 읽혔다면 기사의 내용을 상상해서 정리하지 않는다. 아주 긴 글의 일부만 읽었다면 전체 요약으로 표시하지 않고 읽은 범위를 밝힌다. 저장된 링크라면 무조건 새 파일을 만들지 않고 기존 자료와 중복인지 확인한다.

결과 형식에도 실패 상태를 포함한다. 제목, 출처, 확인한 범위, 요약, 내 질문, 처리 상태 정도면 시작할 수 있다. 상태에는 성공만 아니라 접근 실패, 부분 읽기, 검토 필요가 들어간다. 빈칸을 모두 자연스러운 문장으로 채우는 것보다 비어 있는 이유를 보이는 쪽이 쓸모 있다.

중복 판정은 URL 문자열 하나만 비교하면 부족할 수 있다. 추적 매개변수가 붙은 같은 글, 리디렉션으로 다른 주소가 되는 글, 같은 주소에서 내용이 갱신된 글을 구분해야 한다. 그렇다고 임의로 모든 매개변수를 지우면 서로 다른 페이지가 합쳐질 수 있다. 정규화 규칙을 정하고 원래 입력 URL도 남긴다.

예전에 겪은 실패는 현재 명령어의 정답이 아니다

기존 기록에는 study-clipper가 처음에 여러 번 실패했던 일, daily-digest가 07:00에 실행되지 않아 대상 옵션을 확인했던 일, 블로그 배포에서 Git 이메일 설정을 살폈던 일이 남아 있다. 그 경험이 유용한 것은 지금 모든 환경에서 같은 명령어를 쓰면 해결된다는 뜻이어서가 아니다.

특히 예약 작업의 실패는 예약 등록, 실행 환경, 실제 작업, 결과 전달을 나눠 확인해야 한다. 예약은 시작됐지만 환경 변수나 인증이 없어서 작업이 실패할 수 있다. 작업은 끝났는데 메신저로 전달되지 않을 수도 있다. 결과 메시지가 없다는 사실만으로 예약이 시작되지 않았다고 단정하지 않는다.

새로운 실행에서는 현재 설치 버전의 도움말과 로그를 확인해야 한다. 과거에 원인이었던 옵션이 지금도 유효한지는 별도 확인 대상이다. 사용자 환경을 보지 않은 상태에서 당시의 수정 명령을 그대로 복사할 수 있는 해결책으로 제공하지 않는다.

로그에 남길 것은 예약 시간과 시간대, 실제 시작·종료 시각, 처리한 입력의 식별자, 실패한 단계, 다음 재시도 여부다. 토큰이나 비밀번호, 원문에 포함된 개인 정보는 로그에서 제외한다. 실패를 자세히 남기는 목적과 민감한 내용을 전부 복사하는 행위는 다르다.

재시도는 횟수보다 이미 한 행동을 아는지가 중요하다

정리 작업이 일시적으로 실패하면 한 번 더 시도할 수 있다. 그러나 메일 전송처럼 외부 효과가 있는 작업은 응답을 못 받았다고 바로 반복하면 중복 발송이 생길 수 있다. 서버에서는 전송됐는데 클라이언트만 시간 초과를 겪었을 가능성도 있기 때문이다.

처리 단위마다 식별자를 두고 저장 완료와 발송 완료를 별도로 기록하는 방식을 고려한다. 같은 요청이 다시 오면 이미 완료한 단계부터 확인한다. 단순히 “실패하면 세 번 반복”이라고 지시하는 것보다 작업 상태와 재시도 가능한 단계를 정의하는 것이 먼저다.

비용과 실행 시간도 상한을 둔다. 읽지 못한 페이지를 끝없이 다시 열거나 요약을 계속 고치면 링크 하나 처리에 예상보다 많은 자원이 든다. 정해진 횟수나 시간에 도달하면 실패 이유와 현재 결과를 남기고 사용자에게 넘긴다. 상한값은 실제 환경에서 조정해야 하며, 이 글에서는 특정 횟수를 만능 설정으로 정하지 않는다.

이 설계는 복잡한 분산 시스템을 처음부터 만들자는 제안이 아니다. 처음에는 검토 폴더에만 저장하고 사람이 다음 단계를 실행해도 된다. 어떤 행동이 끝났는지를 모르겠다면 자동 발송을 붙이기 전에 그 부분부터 단순하게 만드는 편이 낫다.

도구를 연결하기 전에 결과물의 약속을 맞춘다

study-clipper의 결과를 blog-gen으로 넘기고 다시 digest에서 소개하는 흐름을 생각할 수 있다. 이때 첫 단계의 요약이 원문 자체로 둔갑하지 않도록 해야 한다. 원문 URL과 읽은 범위가 다음 단계까지 따라가야 하고, 요약자의 해석과 원자료의 사실을 구분할 수 있어야 한다.

예를 들어 clipper가 “설치가 쉬워 보인다”라고 적었다면 blog-gen이 “직접 설치해 보니 쉬웠다”로 바꿔서는 안 된다. 앞 단계가 실제 사용 기록을 제공하지 않았다면 뒤 단계에도 사용 경험이 생기지 않는다. 자동화가 이어질수록 작은 추측이 확정된 사실로 변할 수 있어서, 자료의 종류를 표시하는 것이 중요하다.

블로그 글에 앞 요약을 붙일 때도 마지막 본문을 기준으로 작성해야 한다. 제목만 보고 먼저 만든 요약은 이후 수정된 내용과 맞지 않을 수 있다. 구독자가 요약을 보고 읽을지 결정한다면 핵심 한계나 “아직 시험 전”이라는 상태도 숨기지 않는 편이 정직하다.

각 스킬의 결과에 무엇이 반드시 있어야 하는지 적으면 연결 문제가 덜 모호해진다. 누락된 출처는 뒤 단계에서 채워 넣은 척하지 않고 검토 필요로 돌린다. 모든 연결이 자동이라는 사실보다 잘못된 자료를 다음 단계에서 멈출 수 있는지가 운영에 더 중요하다.

실험을 계속할지 멈출지 판단하는 기록

호기심으로 시작한 도구는 만드는 과정이 즐거워서 필요 이상으로 커질 수 있다. 그래서 실제 사용 가치와 학습 가치를 따로 적어 보려 한다. 저장한 링크를 다시 찾는 시간이 줄었는지, 요약에서 원문으로 돌아갈 수 있는지, 발송 전에 수정해야 할 오류가 얼마나 있는지 확인한다.

읽지 않는 요약이 매일 쌓이면 수집 빈도를 낮추거나 주제를 줄일 수 있다. 자동화가 중단됐을 때 불편하지 않다면 유지 보수 비용에 비해 필요가 작을 수도 있다. 반대로 자주 찾는 노트가 생기면 그 유형의 자료부터 개선할 근거가 된다.

다음 작은 실험의 결과물은 새 스킬 개수보다 입력별 성공·실패 기록 한 장이면 충분하다. 호기심을 오래 유지하려면 새 기능을 계속 붙이는 것뿐 아니라 작동하지 않는 가정을 지우는 일도 할 수 있어야 한다. 이번에는 URL 하나를 제대로 읽었다고 확인하는 지점부터 시작하고 싶다.

참고자료

• 한지우, 『더 퍼지, AI 시대 누가 미래를 이끄는가』 도서 정보: 책의 저자와 출간 정보를 확인한 자료. 자동화 절차는 독서에서 출발한 필자의 제안이다.
• NIST AI RMF Playbook: 자동화의 위험과 검토 절차를 설계할 때 참고한 문서.