자동화를 만들고 나면 보통 dry-run부터 돌려보죠. 실제로 뭔가를 바꾸지는 않고, 어떤 걸 처리하게 될지만 미리 확인해보는 예행연습이에요. 그런데 이 예행연습이 "처리할 대상이 하나도 없음"으로 끝나면, 왠지 성공한 것 같은 기분이 들어요. 에러도 없었으니까요. 사실 이 상태에서는 아무것도 검증된 게 없어요. 모든 게 정상일 때 입력부터 결과까지 한 번에 통과하는 경로를 happy path라고 하는데, 파이프라인이 이 경로를 실제로 통과하는 모습을 아직 한 번도 본 적이 없는 거거든요. 이번 글에서는 이런 상황에서 쓸 수 있는 방법, 즉 테스트 문서 하나를 직접 심어서 자동화의 끝점까지 검증하는 방법을 정리해볼게요. dry-run 0건은 검증이 아니에요 dry-run이 후보 0건으로 조용히 끝났다는 건 두 가지 중 하나예요. 정말 처리할 게 없었거나, 아니면 후보를 찾는 로직 자체가 잘못됐거나요. 어느 쪽인지는 실제 후보를 넣어보기 전까지 알 수 없어요. 그래서 필요한 게 테스트 후보 심기(seeding)예요. 자동화가 처리해야 할 조건을 만족하는 입력물을 일부러 하나 만들어서, 파이프라인의 첫 번째 실제 처리 대상으로 삼는 거죠. 예를 들어 마크다운 노트를 스캔해서 이슈 트래커에 자동 발행하는 파이프라인이라면, 발행 조건을 갖춘 테스트 노트를 하나 만들어두는 식이에요. 이때 중요한 건 결과가 어디에 생겨야 하는지까지 테스트 문서에 미리 못 박아두는 거예요. "이슈가 생기면 성공"이 아니라 "지정한 프로젝트에 생겨야 성공"이어야, 엉뚱한 곳에 결과물이 만들어지는 버그도 같이 잡을 수 있어요. 합격 기준은 관측 가능한 산출물로 적어요 테스트 문서 안에는 합격 기준(Acceptance Criteria)을 체크리스트로 함께 적어두는 게 좋아요. 위의 노트 발행 파이프라인을 예로 들면, 이런 기준을 세울 수 있어요. 산출물 생성 — 지정한 프로젝트에 새 이슈가 만들어진다 원본 상태 갱신 — 테스트 문서의 상태 값이 "발행됨"으로 바뀐다 메타데이터 기록 — 생성된 이슈의 ID와 URL, 갱신 시각이 문서에 남는다 이력 증거 — 원격 저장소에 발행 커밋이 추가된다 재실행 skip — 같은 자동화를 다시 돌리면 이 문서는 "이미 발행됨" 사유로 건너뛴다 공통점이 보이시나요? 전부 눈으로 확인할 수 있는 산출물이에요. 이슈 URL, 상태 값의 diff, 커밋 로그처럼요. "돌아간 것 같다"는 느낌이 아니라 관측 가능한 증거가 기준이 되면, 검증 결과를 두고 해석이 갈릴 일이 없어요. 재실행 검사를 꼭 넣는 이유 다섯 번째 항목이 특히 중요해요. 자동화는 한 번 돌고 끝나는 게 아니라 반복 실행되잖아요. 두 번째 실행에서 같은 문서가 또 처리되면, 중복 산출물이 쌓이기 시작해요. 같은 입력을 여러 번 처리해도 결과가 한 번 처리한 것과 같아야 한다는 성질을 멱등성이라고 하는데, happy path 검증에는 "한 번 더 돌렸을 때 조용히 skip되는가"라는 멱등성 확인까지 포함하는 게 좋아요. 범위 밖과 정리 계획도 같이 적어둬요 테스트 문서에는 이번 검증에서 다루지 않는 것(Out of Scope)도 명시해두는 게 좋아요. 예를 들어 다른 입력물의 처리나, 생성된 산출물의 후속 라이프사이클(닫기, 담당자 지정 등)은 범위 밖이라고요. 범위를 좁혀두면 검증이 끝났는지 아닌지를 명확하게 판단할 수 있어요. 검증이 끝난 뒤의 정리 계획도 미리 적어두세요. 테스트 문서와 그 산출물을 보관 처리할지, 삭제할지요. 테스트용 산출물이 실제 데이터 사이에 남아서 떠돌지 않게 하는 거예요. 정리하면 자동화의 끝점 검증은 이렇게 요약할 수 있어요. dry-run 0건은 성공이 아니라 미검증 상태예요 조건을 만족하는 테스트 문서를 직접 심어서 첫 후보로 만들어요 합격 기준은 관측 가능한 산출물(이슈, diff, 커밋)로 적어요 재실행 시 skip까지 확인해야 반복 실행에 안전해요 범위 밖과 사후 정리 계획도 문서에 남겨요 다음에 자동화를 만들게 되면, dry-run이 조용히 끝났다고 넘어가지 말고 테스트 후보 하나를 직접 심어서 끝까지 흘려보내 보세요. 파이프라인이 실제로 일하는 모습을 한 번은 봐야 믿을 수 있거든요. Remember that failure is an event, not a person.— Zig Ziglar

Claude Code나 Codex 같은 AI 에이전트에게 일을 맡기면, 지시는 채팅창에 쓰고 결과는 터미널에 흘러가 버려요. 며칠 지나면 "그때 뭘 시켰더라? 왜 이렇게 고쳤지?"가 기억나지 않죠. 이 문제는 생각보다 간단하게 풀 수 있어요. 지시를 채팅 대신 마크다운 노트에 쓰고, 에이전트가 같은 노트에 결과를 적게 하면 돼요. Obsidian을 이미 쓰고 있다면 따로 도구를 들일 필요도 없어요. 노트 한 장 = 지시서 + 작업 기록 작업 하나를 노트 한 장으로 만들어요. 위쪽에는 내가 쓰는 지시, 아래쪽에는 에이전트가 쓰는 결과가 들어가요. --- status: todo agent: claude created: 2026-10-01 --- 목표 로그인 화면에서 비밀번호 오류 메시지가 두 번 뜨는 문제 고치기 맥락 - 관련 파일: `src/auth/LoginForm.tsx` - 지난주 폼 검증 로직을 바꾼 뒤부터 생긴 것 같음 완료 조건 - 오류 메시지가 한 번만 뜬다 - 기존 로그인 테스트가 통과한다 하지 말 것 - 폼 라이브러리 교체 같은 큰 리팩터링 결과 (에이전트가 작성) 채팅창에 한 줄로 던질 때보다 손이 조금 더 가요. 대신 완료 조건과 하지 말 것을 적는 순간 지시가 훨씬 또렷해지고, 에이전트가 엉뚱한 방향으로 가는 일도 줄어요. 에이전트에게 넘기는 방법 노트 경로만 알려주면 돼요. 에이전트는 파일을 직접 읽을 수 있거든요. tasks/로그인-오류-메시지.md 읽고 작업해줘. 끝나면 노트의 결과에 정리해줘. Obsidian 볼트 안에서 에이전트를 실행하거나, 볼트 경로를 알려주면 같은 방식으로 쓸 수 있어요. 결과를 남기는 규칙 정하기 결과를 매번 어떻게 적으라고 말하기는 번거로워요. 에이전트가 매 세션 읽는 지침 파일에 한 번만 적어두면 돼요. Claude Code라면 CLAUDE.md, Codex라면 AGENTS.md예요. 작업 노트 규칙 - 작업 노트를 받으면 끝난 뒤 ` 결과`에 아래 항목을 적는다. - 바꾼 파일 목록 - 왜 그렇게 고쳤는지 (선택하지 않은 방법이 있으면 함께) - 확인한 방법 (실행한 테스트나 명령) - 남은 일이나 확인하지 못한 부분 - frontmatter의 `status`를 `done` 또는 `failed`로 바꾼다. 핵심은 왜 그렇게 고쳤는지예요. 코드 변경은 git에도 남지만, 판단 이유는 따로 적지 않으면 사라지거든요. status는 보조 정보로만 생각하세요. 에이전트가 중간에 멈추면 값이 안 바뀔 수 있어서, 실시간 상태판으로 믿기엔 부족해요. "끝난 것과 실패한 것을 나중에 골라내는 표시" 정도로 쓰면 충분해요. 쌓인 노트 다시 꺼내 쓰기 노트가 쌓이면 이게 그대로 작업 기록이 돼요. 이때부터 Obsidian의 장점이 살아나요. 검색 — "로그인 오류" 같은 키워드로 당시 지시와 결과를 한 번에 찾아요 링크 — 이어지는 작업은 [[로그인-오류-메시지]]처럼 이전 노트를 링크해서 맥락을 넘겨요 템플릿 — 잘 굴러간 노트의 구조를 템플릿으로 저장해서 다음 지시에 재사용해요 Dataview 플러그인을 쓴다면 실패한 작업만 모아서 다시 맡길 목록을 만들 수도 있어요. LIST FROM "tasks" WHERE status = "failed" SORT created DESC 이 방식이 맞지 않는 경우 모든 상황에 맞는 건 아니에요. 여러 에이전트를 동시에 돌리면서 누가 무엇을 잡고 있는지 정확히 추적해야 한다면, GitHub 이슈 같은 전용 도구가 더 확실해요. 노트의 frontmatter는 잠금 장치가 아니라서 두 에이전트가 같은 노트를 동시에 집을 수도 있거든요. 반대로 혼자서 에이전트 몇 개를 번갈아 쓰고, 이미 Obsidian에 생각을 정리하는 사람이라면 잘 맞아요. 기획하던 노트에서 바로 지시서를 쓰고, 결과도 같은 곳에서 읽을 수 있으니까요. 다음 작업 하나부터 거창하게 시작할 필요는 없어요. 다음에 에이전트에게 맡길 일 하나를 채팅 대신 노트로 써보세요. 목표, 완료 조건, 하지 말 것 세 칸만 채워도 지시가 달라지고, 결과가 노트에 남는 순간 그 작업은 다시 찾을 수 있는 기록이 돼요. The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.— George Shaw

만들고 있는 아이템을 고민하다가 영상 하나를 보게 됐어요. 제가 풀려는 문제가 YC(Y Combinator)가 보기에도 풀기 어려운 문제라는 내용이었죠. 그 영상과 YC 글에서 말하는 타르핏 아이디어가 뭔지, 그리고 제 아이템에 어떻게 적용되는지 정리해볼게요. How to Get and Evaluate Startup Ideas | Startup School Tarpit ideas - what are tarpit ideas &x26; how to avoid them 타르핏 아이디어란 타르핏 아이디어(Tarpit idea)는 해결하려는 문제가 그럴듯하게 들리지만, 실제 사용자 행동에 의해 무너지는 아이템이에요. 똑똑한 사람들이 여러 번 시도했는데도 아직 아무도 성공하지 못한 스타트업 컨셉이죠. 시장에 발을 들여놓기 전까지는 탄탄해 보여요. 그런데 막상 해볼수록 나아지지 않아요. 타르(tar)로 채워진 구덩이에 빠진 것처럼, 발버둥칠수록 더 깊이 빠지는 거예요. 아이템은 겉으로 드러나지 않는 원인 때문에 실패해요. 문제를 해결하는 과정에서 해결되지 않는 다른 문제들이 튀어나오거든요. 즉 그 아이디어 안에는 실패하게 만드는 숨겨진 요인이 존재해요. 타르핏에 공통으로 숨어 있는 요인들 영상과 글에서 정리한 숨겨진 요인들을 제 언어로 다시 적어봤어요. 존재하지 않는 행동 패턴 — 우리 생각엔 사용자가 그렇게 행동할 것 같지만, 실제로는 그런 행동 패턴이 없어요. 통제 불가능한 획득 비용 — 네트워크를 만들려면 사용자 획득 비용이 감당할 수 없을 만큼 들어가요. 이론상으로만 되는 수익화 — 계산으로는 효과가 있어 보이지만 실제로는 실패하는 수익화 전략이에요. 시작되지 않는 네트워크 효과 — 네트워크 효과가 돌아야 의미가 있는 기능인데, 그 효과가 아예 시작되지 않아요. 완벽하지 않은 시장 타이밍 — 다만 이건 크게 상관없을 것 같다는 게 제 생각이에요. 욕망과 습관의 불일치 — 사용자는 쓸 거라고 말하지만 실제로는 쓰지 않아요. 인지한 유용성(욕망)이 실제 행동(습관)으로 이어지지 않는 거죠. 낮은 빈도와 높은 마찰 — 습관이 생길 만큼 반복되지 않고, 획득 비용(CAC)을 개선할 만큼 쓸 일이 없어요. 중요해 보이지만 꼭 필요하진 않은 거예요. 닭이 먼저냐 계란이 먼저냐 — 제품이 사용자에게 가치가 있어야 하는데, 가치가 없어서 사용자가 쓰지 않아요. 사회적 중력 — 어색하고 느리고 눈에 안 띄어서, 사용자가 공유와 참여를 피해요. 수익화 신기루 — 참여도는 높은데 지불 의사나 반복 지출 의사가 명확히 드러나지 않아요. 창업자 문제 — 나는 문제를 느끼는 것 같지만, 시장이 긴급하게 원하는 건 아니에요. 사례: 친구와 약속 잡는 앱 제가 만들고 있는 아이템이 바로 이 영역에 있었어요. 영상에서 지적하는 숨겨진 요인을 하나씩 따라가 보면 이래요. 놀고 싶은 사람이 연락하는 상대는 집에 있고 싶거나, 애초에 놀고 싶지 않을 수 있어요. 앱은 욕구를 강요할 수 없어요. 그래서 플레이크 비율(flake rate, 하기로 했지만 실제로는 참여하지 않은 사람의 비율)이 생겨요. 계획이 깨지는 건 사람들이 포기하기 때문이에요. 합의에 도달하지 못한 이유는 조정 도구가 부족해서가 아니라, 실제로 누군가가 원하지 않았기 때문이죠. 약속은 감정적인 문제가 더 큰데, 저는 조정 과정을 문제 삼고 있었어요. 중요도가 낮은 일에 집중하고 있던 셈이에요. 영상은 방향을 이렇게 제안해요. 약속 생성 기능부터 변명을 만들어주는 완곡한 거절까지, 미리 준비된 옵션과 안전한 기본 설정을 제공하라는 거예요. 일정 계획 수립을 돕는 것보다 사회적 현상 자체를 더 중요하게 다루면 나아질 수 있다고 말해요. 수익화도 만만치 않아요. 수익화할 수 있는 요인은 예약 판매 정도인데, 그러려면 높은 시장 점유율이 먼저 있어야 해요. 그리고 어떤 사용자가 탈퇴하면 그 친구들도 쓸 이유가 사라져요. 그래서 이런 질문들이 남아요. 아무도 실제로 약속을 잡지 않을 때, 이 서비스를 여는 게 충분히 즐거울까? 사회적으로 비난받을 수 있는 일정(밤샘 클럽, 헌팅 술집 등)까지 공개되는 걸 어떻게 피할 수 있을까? 약속이 잡히기 전에도 가치를 제공할 수 있을까? 아무도 먼저 사용하지 않을 땐 어떻게 될까? 무너지는 원인 네 가지 위 내용을 앞의 공통 요인에 대입하면 네 가지로 압축돼요. 낮은 빈도 — 습관이 될 만큼 자주 쓰지 않아요. 행동 불일치 — 쓰겠다고 말하지만 실제로는 쓰지 않아요. 인수 함정 — 네트워크를 만들기 위한 획득 비용이 감당이 안 돼요. 수익화 환상 — 참여는 있어도 지불 의사가 보이지 않아요. 타르핏을 발견했다면 타르핏 아이디어를 붙잡고 있는 사람에게 이런 영상은 좌절하라고 만들어진 게 아니에요. 오히려 해야 할 일이 분명해져요. 먼저 망했던 이유들을 찾아서 숨겨진 요인을 파악해요. 그다음 그 요인이 왜 중요한지 이해하고요. 마지막으로 그 요인을 포기할지, 아니면 극복할 방법을 찾을지 결정하면 돼요. 그럴듯한 아이디어일수록 한 번쯤 "이게 타르핏은 아닐까?" 하고 물어보세요. 빠져나오는 데 드는 비용은 늦게 알수록 커지거든요. If you do not change direction, you may end up where you are heading.— Lao Tzu