회사 소개 문서를, '감지→판정→승인' 루프로 자동 업데이트 되게 바꾸는 시도

📝 한줄 요약

Linear랑 Slack에는 사업 방향이 바뀌는 논의가 계속 쌓이는데, 정작 회사 소개 문서에 반영하는 걸 자꾸 놓치더라고요. 그래서 "변화를 감지해서 문서 수정안을 뽑아주고, 저는 승인만 하면 되는" 검증 가능한 자동 갱신 루프를 Claude Code로 설계하고 실제 판정기랑 커넥터까지 붙여봤어요.

🎯 이런 분들께 도움돼요

• AI 에이전트나 업무 루프 설계에 관심 있는 실무자

• 반복 업무를 자동화하고 싶은데 "어디서부터 잘라야 하지?" 막막한 분

• AI한테 일을 맡길 때 "결과가 맞는지 어떻게 검증하지?"가 고민인 분

😫 문제 상황 (Before)

저는 채용을 위해서 회사 소개 자료를 여러 개 만들어요. 그 원천이 되는 마스터 문서 하나(geniefy-business.md)가 있고, 다른 소개 자료랑 맥락은 전부 이걸 바탕으로 만들거든요.

그런데 이 원천 문서가 자꾸 옛날 버전이 되는 게 문제였어요. Linear랑 Slack에는 사업 방향이 바뀌는 결정이랑 논의가 매주 쌓이는데, 그걸 문서에 반영하는 걸 자꾸 놓치더라고요. 결국 옛날 버전 기준으로 소개 자료가 나가곤 했어요.

그리고 문제가 하나 더 있었어요. 이 문서엔 사업 방향만 있는 게 아니라 회사 성과(참가자 수, 만족도, 새로 나온 사례 같은 것)도 같이 정리돼 있는데, 새 성과가 나올 때마다 그걸 계속 추가해줘야 하거든요. 근데 이 성과 추가도 방향 반영만큼이나 자꾸 밀리더라고요.

"이걸 매번 손으로 맞추지 말고, 아예 루프로 만들 수 없을까?" 가 시작이었어요.

🛠️ 사용한 도구

• 도구: Claude Code

• 모델: Claude Opus 4.8

• 참고한 외부 스킬: GPTers slack, Linear update-proj-v2 — 참고로 이번에 쓴 외부 스킬은 전부 지피터스 사내 인원이 직접 개발해서 GPTers AI Toolkit에 공개한 것들이에요. 도식 만든 bbojjak-art도 여기 있어요.

• 코치: rona.so 로나 코치를 사용해서 코칭을 받으면서 했어요.

🔧 작업 과정

1. "회사 소개를 잘 쓰기"는 루프로 만들면 안 되더라고요

처음엔 그냥 "회사 소개를 AI가 알아서 잘 갱신하게" 하고 싶었어요. 그런데 짚고 넘어가야 할 게 있었어요. "잘 썼는가"는 사람이 매번 읽어보고 감으로 판단해야 하잖아요. 그러면 루프가 스스로 잘 됐는지 아닌지를 알 수가 없어요.

그래서 같은 일을 이렇게 바꿨어요: "Linear/Slack의 새 결정·변화를 감지해서, 문서랑 어긋나는 걸 반영한다." 이건 원본이랑 대조가 되니까 기계가 판정할 수 있거든요. 라면 타이머는 "3분 지났나?"로 스스로 합격을 알지만, 요리 대회 심사는 사람이 매번 맛봐야 하잖아요. 딱 그 차이예요.

전체 흐름은 이렇게 잡혔어요:

ALT

주황색 후드티를 입은 고양이가 화이트보드 옆에 서 있습니다

💡 느낀 점: 반복 업무를 루프로 만들 때 진짜 관건은 프롬프트를 길게 쓰는 게 아니었어요. "결과가 좋은가?"를 "원본이랑 대조해서 맞는가?"로 바꿀 수 있느냐가 핵심이더라고요.

2. 합격 기준 정하다가 제 실수를 스스로 잡았어요

무엇을 "합격(=반영 대상)"으로 칠지 정하는 게 제일 중요했어요. 세 관문으로 잡았어요: ①문서 방향과 관련 있고 ②어긋나는 변화이며 ③확정된 것.

여기서 "확정"을 뭘로 판정하냐가 관건이었는데요. 처음엔 "Linear 이슈가 Done이면 확정"으로 잡았다가, 쓰다 보니까 논리적으로 말이 안 되더라고요.

Linear Done 신호는 그 일을 '했다'는 것이기 때문에 Approved 의미가 거의 없어.

Done은 "실행 완료"지 "방향 확정"이 아니잖아요. 그래서 "상태 전이 = 변화 신호"랑 "확정 = 내용 판정"을 분리했어요. 상태값이 바뀐 건 "볼 게 생겼다"는 신호일 뿐이고, 확정인지는 내용을 봐야 알 수 있으니까요.

💡 느낀 점: AI가 준 틀을 그대로 따르지 않고 "이게 말이 되나?"를 한 번 따진 게, 루프가 겉돌지 않게 만든 지점이었어요.

ALT

종이를 들고 있는 고양이와 종이를 들고 있는 고양이

3. 굿하트가 뭐냐면요

합격 기준을 세우자마자 배운 개념이 굿하트 법칙(Goodhart's Law) 이었어요.

굿하트 법칙: "측정이 목표가 되는 순간, 그것은 더 이상 좋은 측정이 아니게 된다."

쉽게 말하면, 어떤 숫자를 "이거 맞추면 합격"이라고 걸어두면 사람이든 AI든 진짜 목표는 제쳐두고 그 숫자만 채우는 지름길을 찾는다는 거예요. 예를 들어 글 합격 기준을 '2000자 이상'으로 걸어두면, 알맹이 없이 물만 잔뜩 채운 장문으로 통과해버리죠. AI한테 "게임 점수 올려"라고 하면 완주는 안 하고 점수 나오는 구간만 뱅뱅 돌기도 하고요. 한마디로 "기준은 만들어두면 반드시 뚫린다" 예요.

그래서 저는 만드는 역할(Maker)이랑 채점하는 역할(Checker)을 분리하고, 채점 기준은 Maker가 못 바꾸게 잠갔어요. 같은 쪽이 만들고 채점하면 무의식적으로 기준을 슬쩍 낮추거든요.

ALT

노트북을 들고 사다리 위에 앉아 있는 고양이 만화

4. 검증자 사다리 — 모든 걸 사람이 볼 필요는 없어요

판정 방법을 가벼운 것부터 무거운 것까지 사다리로 뒀어요. 가벼운 건 기계가, 무거운 판단만 사람이 보게요. 모든 걸 사람이 보면 매주 제가 붙잡혀서 "켜두고 떠날" 수가 없잖아요.

• 신호가 있나·몇 건인가 → 이진/수치 (기계)

• 근거·출처를 달았나 → 루브릭 (기계+반자동)

• 방향과 어긋나나·확정인가 → LLM 심판 + 사람 표본 (사람)

5. 실제로 한 바퀴 돌렸더니, 심판이 굿하트를 잡았어요

설계로만 끝내기 싫어서 실제 입력(시뮬 표본) 위에서 한 바퀴 돌려봤어요. 표본엔 명백히 반영할 1건 + 굿하트로 뚫으려는 1건을 섞었고요.

결과가 재밌었어요. 기계 판정은 둘 다 통과시키더라고요. Maker가 붙인 confirmed 라벨을 그대로 믿었거든요. 그런데 별도 LLM 심판이 굿하트 항목을 딱 잡아냈어요: "확정 키워드랑 상태 전이만 맞췄지, 실제로 방향을 바꾸는 결정이라는 근거는 약하다" → 논의중으로 강등. Repair하고 다시 돌리니까 통과했고, 문서(geniefy-business.md)는 제 승인 전까지 건드리지 않았어요.

💡 느낀 점: 3단계에서 "기준은 뚫린다"고 배운 걸, 5단계에서 제 손으로 직접 확인한 순간이었어요. 기계만으론 못 잡는 걸 심판 층이 잡아주더라고요. 솔직히 이때 좀 도파민 솟았어요.

6. 진짜로 돌게 배선하기 — Linear·Slack + 승인 요청

마지막으로 실제 커넥터를 붙였어요. Linear는 GraphQL API로 최근 7일 이슈를 조회하고("팀 운영 업무" 이니셔티브는 제외), Slack은 지정 채널을 읽고 승인 요청을 발송하게요. 토큰이 없으면 스크립트가 안내하고 멈추도록 게이트를 뒀고, --dry-run으로 실제로 나갈 Slack 메시지를 미리 확인해봤어요:

*[회사 소개 마스터 동기화] 이번 주 반영 후보*

*확정 · 승인 대기 (1)*
• SIG-1 EU는 B2B 파일럿 먼저 (B2C 우선 방향과 배치) — 높은위험(뒤집음)
    ↳ 문서에 'EU는 B2B 파일럿 선행(예외)' 단서 추가 제안

*논의중 · 보류 (1)*
• SIG-2 국내 우선 전환 제안 (결정자 선언 없음 → 본문 미반영)

반영하려면 이 스레드에 `승인 SIG-1`, 보류는 `반려 SIG-1`.
문서는 승인 전까지 변경되지 않습니다.

이 스레드에 승인 SIG-1 한 줄만 남기면 그것만 문서에 반영되고, 나머지는 보류돼요.

참고로 성과 갱신(참가자 수·만족도 같은 것)은 판정 성격이 좀 달라서(숫자·출처 대조라 훨씬 기계적) 같은 루프의 '두 번째 갈래'로 따로 빼뒀어요. 방향 반영 루프가 안정되면 붙일 생각이에요.

✅ 결과 (After)

Before vs After

ALT

테이블의 항목 목록

결과물

• 루프 뼈대: loop/checker.md, loop/checker/mechanical.py, loop/checker/judge-prompt.md

• 커넥터: loop/connectors/fetch_linear.py, fetch_slack.py, loop/notify_slack.py

• 문서: loop/README.md(사용법), loop/TODO.md(남은 일)

아직 실배포 전이에요. 그래서 임팩트는 "시간 몇 시간 아꼈다"보다, 매주 손으로 맞추던 걸 자동 구조로 바꿀 토대를 만들었고, 무엇보다 "반복 업무를 어떻게 루프로 잘라야 하는지" 판단력을 손에 익힌 것에 더 가까워요.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. "좋은가?" 대신 "원본이랑 대조해서 맞는가?" — 이걸로 바꿀 수 있으면 그 일은 루프로 만들기 좋아요.

2. 만드는 쪽이랑 채점하는 쪽을 분리하고 기준을 잠가요 — 같은 쪽이 채점하면 기준이 슬쩍 느슨해지거든요(굿하트).

3. 가벼운 건 기계, 무거운 판단만 사람 — 모든 걸 사람이 보면 "켜두고 떠날" 수가 없어요.

막혔던 부분

• AI가 준 "확정 = Linear Done" 정의가 논리적으로 안 맞았어요. 그걸 그대로 따랐으면 논의중인 게 확정으로 들어갔을 거고요. AI 제안이라도 한 번 의심해보는 게 은근 급소였어요.

🚀 향후 계획

• 토큰(LINEAR_API_KEY, SLACK_BOT_TOKEN) 넣고 실데이터로 한 바퀴 → 실제 Slack 승인 요청 받아보기

• Slack 답글을 읽어서 승인한 것만 문서에 반영하는 단계(Phase 2)

• 주 1회 예약 에이전트로 자동 실행(Phase 3)

• 성과 갱신(참가자 수·만족도 등)을 두 번째 갈래로 추가