만든 AI 사원은 다음 주에도 사용할 수 있었을까? 채용 후 직면한 4가지 오작동과 지시서 재교육 및 유지보수 운영 (1인 법인 1000마력화

「기합을 넣어서 AI 에이전트를 만든 직후는 감동했지만, 1주가 지나자 업무의 전제가 틀어져 오작동하게 되었다」.

「에러나 오보가 늘어나 결국 사람이 수동으로 다시 하게 되었고, 어느새 아무도 그 에이전트를 사용하지 않게 되었다」.

1인 법인이나 개인 개발, 혹은 팀 개발로 AI 에이전트를 현장에 도입하려고 할 때, 누구나 부딪히는 가장 깊은 골짜기가 **'AI 에이전트의 지속 운영 난이도(프롬프트와 워크플로우의 진부화)'**입니다.

많은 기술 기사나 데모에서는 '이런 에이전트를 만들었습니다', '순식간에 태스크가 완료했습니다'라는 **'채용 첫날의 화려한 성공'**만 이야기합니다.
하지만 실무에서 정말 비용이 들고 성패를 가르는 것은 **'다음 주, 다음 달에도 그 에이전트가 현장에서 계속 움직일 수 있는가'**라는 운영 단계입니다.

장기 연재 '1인 법인 1000마력화 계획'에서는 지금까지 다양한 에이전트를 가동시키고 업무 루프를 구성해 왔습니다.

• 비서 역할(태스크 관리): 기한이나 미병합 PR을 한 장에 모으기 (제1회: Claude Code의 태스크 관리) -
• 제작 담당(게시물 생성): 틀과 설정을 분리하여 SNS 게시물을 대량 생산하기 (제2회: Claude Code로 SNS 게시물을 자동화하는 방법) -
• 분석 담당(반향 분석): 평가식을 고정하여 객관적인 성공 유형을 추출하기 (제3회: Claude Code로 SNS의 반향을 분석하는 방법) -
• 품질 관리 담당(검사 채점): 75점 기준으로 형식 검사와 인간의 판단을 분리하기 (제4회: AI에게 블로그 기사를 채점하게 하는 방법) -
• 루프 연계(Software Factory): Git과 파일을 정본으로 하여 느슨하게 연결하기 (제5회: Claude Code로 여러 AI 에이전트를 연계시키는 방법)

그렇다면, 이렇게 화려하게 '입사'시킨 AI 사원들은 다음 주에도 그대로 완벽하게 움직였을까요?

정답은 **'아니요'**입니다. 현장에 투입한 다음 날부터, 차례로 예상치 못한 오작동, 오검출, 알람의 폭주가 발생했고, 인간 측의 손질과 지시서 재교육에 매달리게 되었습니다.

먼저 결론부터 말씀드리자면, 당사(Nogawa L.prince合同会社)에서는 'AI 사원은 만들고 끝이 아니라, 인간 신입사원처럼 주기적인 재교육(프롬프트와 로직의 개정)이 필요하다'고 받아들이고, 오보 분류와 유지보수 운영 규칙을 확립했습니다.

연재의 제6회로서, 채용 다음 주에 현장에서 실제로 발생한 '4가지 지저분한 실패'와, 거기서 배운 AI 사원의 재교육 규칙을 모두 기록합니다.

• 가장 큰 적은 '오보'와 '노이즈'이다: 오검출이 많은 에이전트는 진짜 이상 징후를 가리고, 인간의 신뢰를 급속히 잃게 합니다. '지나치게 엄격한 검사 항목'은 과감하게 줄이고, 노이즈를 제로에 가깝게 만들 용기가 필요합니다. -
  '처리했는지 여부'까지 확인하지 않으면 태스크 관리는 파탄한다: 미처리된 기한을 잡는 에이전트는, 점차 '처리 완료된 태스크'를 영원히 리마인드하는 좀비가 됩니다. 종료 판정의 시그널을 설계에 포함해야 합니다.

• '사원(판단)'과 '설비(절차)'를 엄격하게 분리한다: 자동문에 이름을 붙여서는 안 됩니다. LLM에 의한 상황 해석/판단을 담당하는 것만 '사원'으로 하고, 단순한 주기 스크립트는 '설비'로 구분함으로써, 유지보수 대상이 명확해집니다.

• この記事が役に立つ人:

• AI 에이전트를 만들어봤지만, 실제 운영에서 에러나 오보에 고민하고 있는 사람

• 프롬프트 개선 사이클이나, 지시서의 보수/버전 관리에 어려움을 느끼는 엔지니어

• 1인 법인이나 소규모 팀에서, AI를 활용한 자율 운영의 재현성을 높이고 싶은 사람

• 제한 사항:

• '100% 노유지보수로 영원히 움직이는 꿈의 AI' 소개가 아닙니다. 실제 비즈니스 실무에서 AI를 계속 운영하기 위한 '보수/운용의 지저분한 지견' 기록입니다.

제 회사에서는, AI 사원의 입사일이나 담당 업무, 실제로 일어난 근무 모습을 'AI 사원 명부'라는 사내 대장에 기록하고 있습니다.

그 기록 중에서, 특히 쓰라린 교훈이 된 4가지 트러블과 재교육 경위를 소개합니다.

가장 먼저 발생한 것은, 아침 보고를 담당하는 비서 역할 에이전트(사내 호칭: 028 '창전 비')의 불량이었습니다.

• 발생 문제:
  매일 아침 보고에서, '기한을 넘긴 태스크가 7건 있습니다!'라는 강한 경고가 매일같이 출력되었습니다. 하지만 사람이 1건씩 확인해보니, 7건 모두 수일 전에 대응 완료했던 태스크였습니다.

비서 역할 에이전트의 지시서는 '문서 내에서 날짜를 탐색하고, 오늘보다 이전인 모든 날짜를 기한 초과로 목록화한다'라는 단순한 로직으로 되어 있었습니다. 즉, '기한이 존재하는지'만 보고, '그 기한이 이미 처리되었는지'는 보지 못했던 것입니다.

• 재교육(지시서 개정):

문서에 '## YYYY-MM-DD 판정'이라는 완료 로그 제목을 설정하는 운영 규칙을 정하고, 에이전트 측에도 '해당 제목보다 앞서 작성된 기한은 완료된 것으로 간주하여 보고 목록에서 제외하라'는 종료 판정 로직을 추가했습니다.

**'기한만 찾아내는 것만으로는 부족하다. 처리되었는지 여부의 완료 신호도 함께 보게 한다'**라는 재교육을 통해 이 오리마인드는 완전히 해소되었습니다.

다음으로 발생한 것은 비서 역할의 업무로, 사내 시스템의 가동 상황을 점검하게 했을 때였습니다.

• 발생 문제:

어느 날 아침, 비서 역할로부터 '사내 설비가 4건, 고장으로 인해 정지했습니다'라는 심각한 보고가 올라왔습니다. 놀라서 조사해 본 결과, 4건 모두 시스템적으로는 완전히 정상이었습니다.

• 원인 분석:

원인은 두 가지였습니다.

첫 번째는, 게시 빈도 부족을 알리는 검사 스크립트가, 부족을 감지하여 올바르게 exit 1 (경고 종료)를 출력했는데, 비서 역할이 이를 일률적으로 '프로그램 프로세스 고장(Crash)'으로 해석했던 것입니다. 감시 경보가 정상적으로 이상을 감지하고 있는 상황일수록, 에이전트에게는 고장처럼 보였던 것입니다.

두 번째는, 주 1회만 작동하는 주기적 배치 작업을 월요일 저녁에 실제 도입했더니, 다음 화요일 아침 시점에서 '주기 실행되지 않았다(발화하지 않았다)'로 판정된 경우였습니다. 다음 월요일까지 실행 시간이 오지 않았을 뿐인데도, 미발화 오류라고 단정했던 것입니다.

• 재교육(지시서 개정):

스크립트의 종료 코드에 의한 경고와 프로세스 고장을 명확히 구분하고, 에이전트의 보고 구분을 다음 3가지로 재정의했습니다.

• 【조치 필요】: 업무상의 경고 (게시 부족 등)
• 【고장】: 프로그램 자체의 크래시나 타임아웃
• 【미도래】: 다음 실행 시간이 아직 오지 않은 정상 대기

매일 아침 4

과거 배포 처리 과정에서 '기사 공개 API는 성공했지만, 로컬 Markdown 파일에 ID를 다시 기록하는 처리가 실패했던' 사례가 있었습니다. 에이전트가 '로컬 파일에 ID가 없다 = 미게시'라고 단순하게 믿고 있었기 때문에, 만약 자동으로 재배포했다면 실제 서비스에 완전히 동일한 기사가 중복 게시되는 사고가 날 뻔했습니다. -
재교육(지시서 개정):

로컬 파일의 플래그를 과신하지 않고, 외부 플랫폼의 공개 API에서 최신 기사 목록을 가져와 '제목 문자열 일치 비교'를 통해 실제 서비스의 게시 상태를 직접 검증하는 크로스체크 로직으로 수정했습니다.

이러한 실패와 재교육의 시행착오를 거치면서, 자체적으로 확립된 'AI 에이전트를 현장에서 오래 사용하기 위한 설계 원칙'은 다음과 같은 3가지입니다.

【AI 사원의 장수 원칙】
① '자동문에 이름을 붙이지 않기' : LLM(판단)과 스크립트(절차)의 경계
② '본체는 Markdown에 두기' : 도구에 의존하지 않는 프롬프트의 포터빌리티
...

당초 저희는 주기적으로 실행되는 GitHub Actions나 Git Hooks, 셸 스크립트 등 사내에서 작동하는 자동화 26개 모두에 'AI 사원'이라는 이름을 붙이고 있었습니다.

하지만 이는 '마트의 자동문에 직원증을 걸고 이름을 부르는 것과 같은' 것이었습니다.

정해진 스크립트를 무미건조하게 실행만 하는 프로그램에 인격이나 역할을 부여해도 유지보수에는 도움이 되지 않습니다. 그래서 저희는 명확히 구분을 했습니다.

판단이 수반되는 경우에만 '사원'으로 취급함으로써, '누구의 지시서(프롬프트)를 수정해야 하는가'와 '어떤 프로그램 코드를 수정해야 하는가'가 명확하게 분리되었습니다.

AI 에이전트의 지시서(프롬프트)를 특정 도구(Claude Code 설정 파일이나, 특정 GUI 도구 관리 화면 등) 안에 직접 내장해 버리면, 도구 업데이트나 환경 변경 때마다 유지보수가 어려워집니다.

저희는 모든 AI 사원의 본체를 prompts/xxx.md 와 같은 순수 Markdown 파일로 리포지토리에 관리하고 있습니다.

Claude Code에서 호출할 경우: .claude/skills/ 에서 'prompts/xxx.md를 읽어 실행하라'고 몇 줄만 참조합니다. -
ChatGPT나 브라우저에서 호출할 경우: prompts/xxx.md 안의 내용을 그대로 복사하여 붙여넣습니다.

기준이나 규칙을 개정할 때는, prompts/ 하위의 Markdown 파일을 git diff로 수정하고 커밋하기만 하면 됩니다. 지시서 자체가 코드처럼 버전 관리되므로, 어떤 변경으로 정확도가 높아졌는지(혹은 낮아졌는지)를 완벽하게 추적할 수 있습니다.

새로운 에이전트의 프롬프트를 작성한 직후에는 누구나 '이제 완벽한 자동화가 되었다'고 만족하기 쉽습니다.

하지만 저희는 **'실제 업무 데이터로 최소 1회 구동하고, 사람이 그 출력을 검증할 때까지는 절대 공식 사원 명부에 등록해서는 안 된다'**라는 채용 규칙을 두고 있습니다.

테스트용의 깨끗한 목업(mock) 데이터에서는 완벽하게 작동해도, 실제 서비스 데이터에는 반드시 '제목 요약', '날짜 형식 차이', '중간 API 실패'와 같은 예외가 존재합니다. 실전의 세례를 거쳐 첫날 수정 작업을 마친 것만 업무 루프에 통합하는 것입니다. 이러한 신중함이 시스템의 견고함을 지탱하고 있습니다.

장기 연재 '1인 법인 1000마력화 계획' 제6회로서, AI 사원 채용 다음 주에 직면했던 실제 트러블과 재교육의 지견을 기록했습니다.

오보(誤報)와 노이즈를 방치하지 않기: 너무 엄격한 검사는 노이즈를 만들고 실제 이상을 놓치게 합니다. 불필요한 항목은 덜어냅니다.

• 완료 판정을 반드시 내리도록 하기: 기한이나 태스크를 처리하는 에이전트에게는 '처리 완료'로 판단할 수 있는 시그널을 함께 전달해야 합니다.
• 직원과 설비를 분리하기: LLM의 판단(직원)과 규칙 기반 자동화(설비)를 혼동해서는 안 됩니다.
• 프롬프트를 Markdown으로 코드 관리하기: 툴 의존성을 배제하고, Git을 이용해 지시서의 버전과 개선 이력을 추적합니다.

AI 에이전트는 한 번 배포한다고 해서 영원히 돌아가는 '마법의 프로그램'이 아닙니다.

업무 환경의 변화나 데이터의 흔들림에 맞춰 사람이 주기적으로 개입하여, 지시서를 다시 쓰고 함께 성장시켜 나가는 '동료' 같은 존재입니다.

이러한 끈질긴 유지보수 루프를 받아들이고 시스템으로 돌릴 수 있게 되었을 때, 비로소 1인 법인은 '1000마력'이라는 흔들림 없는 추진력을 얻을 수 있습니다.

다음 회차(제7회)에서는 **'1인 법인의 AI 운영비를 어떻게 기록할까? 월별 구독 계약비와 인간의 확인 시간을 합친 현실적인 비용 대비 효과'**에 대해 자세히 기록하겠습니다.

• Claude Code로 여러 AI 에이전트를 연계하는 방법, 자율 대화를 버리고 Git과 파일로 연결하는 업무 루프 설계 (1인 법인 1000마력화 계획 제5회)
• AI에게 블로그 기사를 채점하게 하는 방법, 점수와 공개 판단을 분리한 품질 관리 에이전트 설계 (1인 법인 1000마력화 계획 제4회)
• Claude Code로 SNS 반응을 분석하는 방법, 평가식과 성공 유형을 추출하는 에이전트 설계 및 사람에게 남는 의사결정 (1인 법인 1000마력화 계획 제3회)
• Claude Code로 SNS 게시물을 양산하기: 틀(型)과 설정을 분리한 에이전트 지시서 작성법 (1인 법인 1000마력화 계획 제2회)
• Claude Code의 태스크 관리: 기한과 PR(Pull Request)을 한 장으로 만드는 방법 (1인 법인 1000마력화 계획 제1회)