AI로 일하기

돈독을 4명의 에이전트가 매일 점검하고 있습니다 👥

생각에 잠긴 초록이 아빠

월요일 아침, 커피를 내리면서 보고서 하나를 읽습니다.

지난 한 주 돈독(제가 만드는 자산관리 앱, https://don-doc.com )에서 뭐가 결정됐고, 뭐가 끝났고, 뭐가 아직 안 끝났는지 정리된 문서예요.

그런데 그 보고서, 제가 안 썼습니다.

정확히는 — 제가 쓰라고 시켰습니다. 저 대신 돈독을 매일 들여다보는 AI 에이전트가 네 명 있거든요.

왜 네 명이나 필요했나

혼자 만드는 제품이면 보통 만드는 시간보다 점검하는 시간이 더 무섭습니다. 코드가 늘어날수록 “어제 고친 게 오늘 뭘 깨뜨렸나”, “디자인 가이드랑 안 맞는 색이 또 어디 숨었나”, “이번 기능을 어떻게 알려야 하나”를 매번 손으로 훑어야 하니까요.

저는 그걸 역할별로 쪼개 각각 스케줄을 걸었습니다.

에이전트맡은 일도는 주기
디자이너새 화면·텍스트가 디자인 가이드와 맞는지, 다크모드·반응형이 깨졌는지매일
개발자git log·의존성·TODO를 훑어 리팩토링·기술부채 제안주 1회
마케터새 기능을 사용자 메시지로 바꾸고 SNS·랜딩 카피 초안주 1회
기획자기획 노트와 실제 커밋 사이 갭, 다음에 할 일 우선순위격주
종합 담당위 네 명 산출물을 모아 “이번 주 결정 필요”를 한 장으로매주 월요일

각자 정해진 시간에 혼자 일어나서, 코드와 문서를 읽고, 자기 몫의 보고서를 씁니다. 저는 그 결과만 확인하면 됩니다.

개념도 — 네 명이 각자 일어나 쓰고, 월요일에 모이는 구조

옮기다가 걸린 것 — iCloud가 파일을 두 개로 만들었을 때

삽질에 멘붕한 초록이 아빠

처음엔 이 네 명을 맥북에서 돌렸습니다. 그러다 다른 자동화들처럼 24시간 켜둔 맥미니로 전부 옮기기로 했어요.

옮기는 과정에서 iCloud 동기화가 같은 파일을 두 버전으로 만들어버린 걸 발견했습니다. 파일명 끝에 ” 2”가 붙은 충돌 사본이 열한 개나 쌓여 있었어요.

처음엔 그냥 지우려고 했습니다. 어차피 중복이니까요. 그런데 지우기 전에 열한 쌍을 하나씩 비교해봤습니다.

열한 쌍 전부 내용이 달랐습니다.

분석 기준이 된 코드 커밋부터 서로 갈라져 있었고, 발견한 문제도 겹치지 않았어요. 그대로 지웠으면 실제로 찾아낸 문제 절반이 그냥 사라질 뻔했습니다.

그래서 지우는 대신 이름을 바꿨습니다. 파일 2.md파일-v2.md 로요. 파일 464개를 하나도 안 지우고 그대로 남겼습니다.

여기서 한 가지 더 걸렸습니다. 에이전트가 같은 날 두 번 돌면 스스로 -v2 접미사를 붙이는 규칙이 원래 있었거든요. 이건 의도된 표시라 남겨야 하는데, iCloud가 만든 충돌 사본과 겉보기엔 똑같이 생겼습니다. 결국 “공백+숫자”는 iCloud 충돌, “에이전트가 직접 붙인 -v2”는 의도된 재실행 — 이렇게 구분 규칙을 따로 세웠습니다.

옮기다가 걸린 것 — 조용히 죽어버린 스케줄

종합 담당(주간보고 만드는 에이전트)을 맥미니로 옮길 때는 다른 문제가 나왔습니다.

맥미니에서 에이전트를 실행하는 스크립트에 역할 이름을 허용 목록으로 관리하는 부분이 있었는데, 여기에 종합 담당의 이름이 빠져 있었습니다. 그래서 스케줄이 도는 시각에 조용히 “사용법을 입력하세요” 메시지만 남기고 그대로 종료됐습니다. 에러 로그도 안 남는 방식으로요.

이걸 잡은 건 순전히 “일단 사람이 한 번 수동으로 돌려보자”는 확인 절차 덕분이었습니다. 그 확인을 건너뛰었으면, 월요일 아침에 보고서가 없다는 걸 그제서야 알았을 거예요. 허용 목록에 이름 한 줄 추가하고, 수동 실행으로 정상 종료(5분)와 결과 파일 생성을 확인한 다음에야 예전 위치의 스케줄을 껐습니다.

자동화가 사람보다 잘한 것도 있었다

모든 게 사람이 이겼던 건 아닙니다. 디자이너 에이전트가 어느 날 죽은 CSS 색상 값 다섯 곳을 손으로 찾아 보고했습니다. 그 김에 같은 패턴을 자동으로 잡아내는 검사 스크립트를 하나 만들어 붙였어요.

첫 실행에서 이 스크립트가 스무 곳 넘는 파일에서 스물여덟 곳을 추가로 찾아냈습니다. 에이전트가 눈으로 훑어 찾은 것의 다섯 배가 넘는 규모였어요. 사람이든 AI든, 눈으로 훑는 것과 규칙으로 훑는 건 걸리는 게 다르다는 걸 그때 확인했습니다.

그래도 사람이 남는 자리

여기까지 보면 다 맡겨도 될 것 같지만, 실제로는 결정이 필요한 지점마다 멈춰 섭니다.

기획 담당 에이전트가 두 데이터를 어떻게 연결할지 검토하고 (B)안을 권했던 적이 있습니다. 저는 다른 안을 골랐어요. 나중에 같이 쓰고 싶은 마음은 있지만 지금은 분리해두는 게 맞다고 판단해서요. 에이전트는 근거를 정리해줄 뿐, 마지막 버튼은 항상 제가 누릅니다.

마케팅 담당은 더 정직한 사례입니다. 발행하자고 제안한 콘텐츠 초안 하나가 스무 번 넘게 검토를 거치는 동안 아직 한 번도 실제로 나가지 않았습니다. 에이전트는 계속 소재를 만들지만, “이걸 진짜 올릴지”는 여전히 제 몫이거든요. 이 구조를 만들고 나서 오히려 분명해진 게, AI가 잘하는 건 “계속 훑고 계속 제안하는 것”이고 사람이 잘하는(잘해야 하는) 건 “그중 뭘 실행할지 고르는 것”이라는 점이었습니다.

지금은 이렇게 돌아갑니다

이전: 코드가 늘 때마다 제가 직접 훑어야 했고, 놓친 게 있으면 나중에야 알았습니다.

이후: 네 명이 각자 정해진 시간에 알아서 훑고, 월요일 아침엔 결정할 것만 골라 받습니다. 저는 승인하고, 나머지는 한 번에 커밋으로 반영합니다.

돈독 대시보드 화면 (데모 계정)

따라 하기

같은 구조를 만들어보려는 분을 위한 순서입니다. 터미널을 다룰 수 있는 AI 도구 하나면 됩니다. 저는 Claude Code를 씁니다.

1. 역할부터 쪼개기

프롬프트를 하나로 뭉쳐서 “다 봐줘”라고 하면 에이전트도 사람처럼 뭘 먼저 봐야 할지 헤맵니다. 역할을 먼저 나누는 게 순서입니다.

너는 <내 프로젝트명>을 점검하는 <역할명> 에이전트야.
매번 실행될 때마다:
1. 최근 커밋·로그 7일치를 먼저 읽고 최신 상태를 파악해라
2. 네 역할 범위 안에서만 발견·제안을 적어라 (다른 역할 영역은 건드리지 마)
3. 지난 실행에서 넘어온 미해결 항목은 다시 확인해서 해소됐는지 적어라
4. 결과를 <저장 경로>에 오늘 날짜로 저장해라

이렇게 되면 성공 — 역할마다 결과 파일이 따로 쌓이고, 서로 겹치는 내용이 없습니다.

막히면 — 한 에이전트가 다른 역할 영역까지 건드립니다. “3번 항목 다른 역할 얘기는 빼고 네 역할만” 이라고 되물으면 됩니다.

2. 스케줄 걸기

프롬프트를 만들었으면 정해진 시각에 혼자 실행되게 걸어야 합니다.

목표: 위 에이전트 프롬프트를 매일(또는 매주) 정해진 시각에 자동 실행되게 하는 것.

- 이 기계에서 예약 실행을 걸 수 있는 방법을 알려줘
- 실행 시각과 실행할 명령을 물어보고 설정 파일을 만들어줘
- 설정 직후 예약 시간까지 기다리지 말고 강제로 한 번 실행해서 정상 종료되는지 확인해줘

이렇게 되면 성공 — 강제 실행했을 때 결과 파일이 정상적으로 생깁니다. 이 확인을 건너뛰면, 실제 스케줄 시각에야 문제를 알게 됩니다. 제가 그랬듯이요.

3. 겹치는 이름 미리 정리하기

여러 에이전트가 같은 폴더에 결과를 쌓다 보면 파일명이 겹치거나, 동기화 서비스가 충돌 사본을 만들 수 있습니다.

목표: 여러 에이전트가 같은 폴더에 저장할 때 파일이 안 겹치게 하는 것.

- 파일명 규칙을 <역할명>-<날짜> 형식으로 통일해줘
- 같은 날 다시 실행되면 -v2, -v3 로 구분해줘 (덮어쓰지 마)
- 이 규칙을 프롬프트에 명시로 넣어줘

이 규칙을 미리 넣어두면, 나중에 진짜 동기화 충돌이 났을 때 “이게 의도된 재실행인지 사고인지” 구분이 훨씬 쉬워집니다.

결국 남는 건

에이전트 네 명을 붙였다고 제품이 저절로 좋아지는 건 아닙니다.

다만 매주 제가 훑어야 했던 것들이 이미 정리된 채로 옵니다. 저는 그중에서 결정할 것만 고르면 되고요. 남는 시간은 초록이 재우고 나서 다음 기능 하나를 더 만드는 데 씁니다.

뿌듯해하는 초록이 아빠

오늘도 네 명은 각자 시간에 맞춰, 조용히 돈독을 들여다보고 있습니다. 🐴

이 글은 산업 구조와 만드는 과정을 정리한 개인 기록입니다.
특정 종목의 매수·매도 추천이 아니며, 투자 판단과 그 결과는 독자 본인에게 있습니다.

← 글 목록으로