AI를 적용하기 전에, 줄일 일부터 정한다 — 스킬과 앱을 만들며 세운 기준

두 프로젝트에서 출발한 질문

개인 에이전트에 반복해서 설명하던 절차를 스킬로 만들었다. 그렇게 만든 절차를 여러 실행 환경에서 재사용하려고 agent-skill-garden을 정리했다. 이력서와 공고를 읽고 지원할 만한지 판단하는 Career Radar도 만들었다. 뒤쪽 프로젝트에는 MCP 서버, 위젯, 데이터베이스, 평가 실행기, 호출 측정과 재개 기능까지 붙었다.

앞선 글들은 기능 하나를 만들고, 리뷰에서 드러난 문제를 고치고, 확인한 범위를 기록하는 이야기였다. 이번에는 개별 수정에서 조금 떨어져, 그때 선택한 구성을 정리해 보려 한다.

그보다 앞서 AI Native는 모델이 아니라 운영 능력이다에서는 모델이 바뀌어도 판단과 검증의 기준은 남아야 한다고 썼다. 이번 글은 그 문제의식을 실제 선택 기준으로 이어 보려는 정리다. 기존 기능을 그대로 쓸 때, 스킬로 절차를 재사용할 때, 코드와 실행 환경을 더할 때를 어떻게 구분할 것인가.

돌아보려는 경험도 새로 만든 두 저장소만은 아니다. 기존 도구의 상태를 확인하고, 결과를 대조하고, 다음 작업을 준비하는 데 AI의 도움을 받는 일도 포함된다. 그런 일에 항상 새 앱이 필요한 것은 아니다. 기존 도구가 상태와 이력의 원본으로 남고 AI가 그 위의 확인과 해석을 돕는 방식도, 이 글에서 비교할 중요한 선택지다.

두 프로젝트를 만든 데에는 AI를 붙이는 단위를 직접 나눠 보고 싶다는 생각도 있었다. 반복되는 절차를 제공하는 층과, 그 결과를 저장하고 검증하며 실행을 이어 가는 층은 무엇이 다를까. 도구를 하나 더 만드는 것이 그 차이를 해결하는지, 기존 도구 위에 기준만 더해도 되는지를 보고 싶었다.

나는 불필요한 도구를 덜 만들었으면 한다. 이것은 AI를 적게 쓰자는 이야기가 아니다. 이미 해결된 기능을 다시 만들거나, 생성된 결과를 대조하고 유지할 일을 늘리면서 생산성이 좋아졌다고 판단하는 순서를 경계한다는 뜻이다. 개인 프로젝트라고 이 기준에서 예외는 아니다.

반복 설명을 줄이는 데에는 스킬을 썼다. 저장된 결과를 다시 읽거나 실패한 실행을 이어 가려면 코드와 상태 관리가 필요했다. 비슷하게 AI를 쓰는 작업이어도 맡겨야 할 책임은 달랐다.

어떤 일은 스킬로 충분하고, 어떤 일부터 코드와 실행 환경을 따로 마련해야 할까?

두 프로젝트와 OpenAI·Anthropic의 설계 자료를 바탕으로, 다음 작업에서 참고할 가이드 형태로 적었다. 스킬·에이전트·앱·플랫폼은 순서대로 거쳐야 하는 단계가 아니다. 재사용할 지식, 실행할 코드, 유지할 상태, 적용할 권한에 맞춰 함께 구성할 수 있는 선택지다.

이전에 ‘우리는 TBD다’라는 말 다음에 필요한 것에서 방법론의 이름보다 제품의 조건과 남는 책임을 살펴야 한다고 썼다. AI 적용도 비슷하게 보고 싶다. AI-native라는 이름을 붙인 뒤에도 질문은 남는다. 무엇을 줄이려는가. 그 대신 어떤 비용이 생기는가. 누가 결과를 확인하는가.

이 글은 개인 공개 저장소와 공개 연구·공식 문서를 근거로 썼다. 아래 업무 예시는 설계 기준을 설명하기 위한 가상 예시다. 제품 문서는 2026년 9월 15일 기준이며, 특히 베타 서비스의 제공 범위는 이후 바뀔 수 있다. 연구 결과와 제품 소개, 그리고 내가 제안하는 설계 기준은 구분해서 읽어야 한다.

개인 실험과 조직의 실행은 다른 질문이다

이 질문을 정리하는 데에는 Swit 공동창업자 이주환(Josh Lee)의 ‘1인 1에이전트’에 관한 글도 영향을 주었다. 개인에게 에이전트를 만들게 하는 것과, 조직의 업무를 함께 끝낼 실행 구조를 설계하는 것은 다르다는 문제의식에 공감했다. 각자 산출물을 빨리 만들어도 다음 역할이 그것을 받아갈 수 없다면, 전체 업무가 그만큼 빨라진 것은 아니라는 지적이다.

그가 이전에 공개한 글에서도 이 문제의식이 보인다. 2023년 글은 팀별 도구 선택이 조직 전체에서는 단절과 중복을 만들 수 있다고 설명하고, 2024년 글은 역할별 에이전트와 감독 구조, 권한을 고려하는 데이터 접근을 제시한다. Facebook 글과 같은 글의 재게시본은 아니며, Swit의 문제 진단과 제품 방향을 설명한 관련 글들이다. 그 자체가 모든 조직에서의 생산성 효과를 입증한 자료는 아니다. Swit 2.0과 도구 과잉·통합, Super Work와 에이전트 협업

나는 여기서 개인의 실험과 조직의 운영을 구분해야 한다는 기준을 가져왔다. 다만 모든 팀이 멀티에이전트를 만들거나 완전 자율성을 최종 목표로 삼아야 한다고까지 생각하지는 않는다. 공통 실행 환경이 필요하다는 문제의식과, 지금 새 플랫폼이 필요하다는 판단도 별개다. 기존 도구로 되지 않는 일이 무엇인지, 어디까지 맡기는 것이 유효한지부터 확인하고 싶다.

그래서 아래 기준은 에이전트를 더 크게 만드는 순서가 아니다. 기존 기능으로 끝낼 일, 스킬로 재사용할 일, 코드와 운영 책임을 더해야 할 일을 구분하는 순서다.

1. 원하는 결과와 기존 기능부터 확인한다

첫 질문은 구현 방식보다 원하는 결과다. 현재 상태를 조회하려는지, 내용을 해석하려는지, 반복되는 변경을 실행하려는지부터 나눈다. 그중 기존 제품의 설정이나 기능으로 충족되는 부분은 그대로 사용할 수 있다.

가령 이슈 목록을 확인하는 작업이라면 저장된 검색과 필터 공유가 출발점이 될 수 있다. 여러 결과를 설명과 함께 읽어야 한다면 문서 연동이나 별도 화면을 검토한다. 조회와 설명 중 어느 부분에 AI가 필요한지도 이때 나눌 수 있다.

공식 기능으로 예를 들면 Jira Cloud는 검색 조건을 필터로 저장하고 공유할 수 있으며, 대시보드에는 수동·주기적 갱신 기능이 있다. Confluence Cloud에도 Jira 항목을 JQL 등으로 조회해 문서에 표시하는 기능이 있다. 이것을 즉시 동기화의 보장으로 읽어서는 안 되고, Data Center의 동작과도 구분해야 한다. 사용하는 배포 형태와 버전, 권한, 필요한 필드와 집계를 실제로 확인한 뒤 대체 가능성을 판단할 일이다. Jira 저장 검색, 대시보드 설정, Confluence의 Jira 목록

원하는 것이 현재 남은 일을 확인하는 것이라면, 첫 후보는 원본을 조회하는 필터다. 원하는 것이 회의에서 어떤 상태를 보고 결정을 내렸는지 남기는 것이라면, 특정 시점을 고정한 문서가 필요할 수 있다. 같은 데이터를 사용해도 목적이 다르다.

여기서 구분할 것은 동적 데이터와 정적 파일 자체가 아니다. 현재 상태를 보여준다는 약속과, 특정 시점을 보존한다는 약속이다.

현재 상태를 보여주려는 화면은 원본 변경을 어떻게 반영하는지 설명해야 한다. 재조회인지, 일정 간격 갱신인지, 캐시인지가 중요하다. 반대로 스냅샷은 생성 시각, 조회 조건, 원본 링크를 남기고 이후 변경을 반영하지 않는다는 점이 명확해야 한다.

별도 화면을 만든다면 갱신 시각과 원본 링크를 함께 제공한다. 사용자가 현재 상태로 받아들일지, 특정 시점의 기록으로 받아들일지 알 수 있도록 하기 위해서다. 원본과 표시된 값이 다를 때 재조회할 방법도 정해 두면 좋다.

특히 숫자나 상태를 전달하는 일이 목적이라면, 모델이 내용을 다시 써야 하는지도 따져야 한다. 필터링과 정렬은 기존 제품이나 코드가 하고, 모델은 차이를 설명하거나 다음 확인 질문을 제안하면 된다. 모든 조회 결과를 새로운 문서로 재작성할 필요는 없다.

정적 문서의 효용을 부정하는 것은 아니다. 의사결정 기록, 감사용 스냅샷, 배포 당시의 변경 목록, 재현 가능한 평가 기준선은 오히려 고정되어야 한다. Career Radar의 커밋된 평가 보고서도 그런 용도다. 최신 운영 화면을 대신하기 위한 것이 아니라, 나중에 같은 비교를 하기 위해 당시 입력과 결과를 보존한다.

내가 경계하는 것은 새로운 표현 자체가 아니라, 그 표현을 유지하기 위해 새로 생기는 일이다. 원본을 조회하면 될 요구를 복사본으로 해결하려면, 추가된 갱신·대조 비용보다 얻는 이점이 무엇인지 설명할 수 있어야 한다. 새로 만들 수 있다는 사실을, 새로 만들어야 하는 이유로 쓰고 싶지는 않다.

적용 범위를 정할 때는 다음 세 질문부터 답해 본다.

1. 기존 제품으로 되는 부분은 무엇인가.
2. 기존 제품으로 되지 않는 요구는 무엇이며, 실제로 확인했는가.
3. 추가한 구성은 사용자의 어떤 단계를 돕는가.

조회 결과는 충분하고 표현만 달라야 한다면 얇은 UI를 검토할 수 있다. 접근 제어가 필요하다면 기존 공유 권한과 저장소 설정부터 확인한다. 이렇게 요구를 나누면 직접 구현할 범위도 구체적이 된다.

예를 들어 Google Drive에는 지정한 사용자와 역할을 기준으로 접근을 제한하는 공유 기능이 있다. 그렇다고 임의의 HTML 앱 실행이나 모든 보안 요구까지 충족한다는 뜻은 아니다. 문서를 제한된 사람에게 전달하는 요구와, 실행 가능한 화면을 제공하는 요구를 먼저 분리해야 기존 기능의 빈 부분을 정확히 비교할 수 있다. Google Drive 공유와 권한

2. 각 구성 요소가 맡을 역할을 나눈다

스킬과 코드, MCP와 실행 환경은 함께 사용할 수 있다. 각각 무엇을 맡고 무엇을 별도로 준비해야 하는지 정리하면 다음과 같다.

Anthropic은 미리 정해진 코드 경로가 모델과 도구를 조율하는 방식과, 모델이 진행 과정과 도구 사용을 동적으로 선택하는 방식을 구분한다. 단순한 접근부터 시작하고, 복잡성을 추가할 때 실제 개선을 확인하라는 권고다. 여기서 “정해진 워크플로”는 제어 흐름이 정해졌다는 뜻이지, 그 안의 모델 출력까지 결정적이라는 뜻은 아니다. Building effective agents

스킬도 단순한 프롬프트 파일만은 아니다. 공식 설명에는 지침과 함께 스크립트·자료를 묶고, 필요한 내용을 단계적으로 읽는 구조가 포함된다. 그러니 경계를 “스킬은 문서, 개발은 코드”로 자르면 틀린다. 새 실행 기반을 만들지 않고 기존 에이전트에 절차와 코드를 공급할 것인가가 더 가까운 질문이다. Agent Skills 설계

MCP는 AI 애플리케이션과 외부 데이터·도구를 연결하는 표준이다. 따라서 스킬이 MCP 도구를 사용하고, 서비스 안의 에이전트가 같은 스킬을 읽는 구성도 가능하다. 연결 표준을 도입했다고 업무의 상태 관리나 운영 책임까지 정해진 것은 아니라는 점은, 이 역할들을 나눠 본 설계상의 해석이다. MCP 소개

절차를 재사용한 예: agent-skill-garden

agent-skill-garden에서 풀고 싶은 문제는 같은 절차를 실행 환경마다 다시 쓰는 것이었다.

공통 스킬과 정책은 한곳에 두고, Claude·Codex·Cursor용 어댑터가 그것을 연결한다. 머신별 경로와 환경 설정은 절차 본문과 분리한다. 설치도 기본은 계획 출력이고, 적용은 따로 요청하도록 되어 있다. 이는 독립된 업무 시스템을 만들기보다, 기존 실행 환경에서 같은 절차를 재사용하려는 구조다. 저장소 구조

리뷰 후속 처리 절차를 예로 들 수 있다. 현재 PR 상태를 확인하고, 지적의 전제를 검증하고, 수정과 검증 결과를 연결하고, 답글과 resolve, 재리뷰 요청을 각각 다루는 절차다. 이 중 상태를 분류하는 계산은 스크립트가 맡을 수 있다. 무엇을 확인해야 하는지와 어떤 행동에 별도 승인이 필요한지는 스킬이 안내한다.

PR의 실제 상태와 리뷰 이력은 GitHub에 있다. 이를 위한 별도 데이터베이스와 포털이 반드시 필요한 것은 아니다. 기존 시스템이 사실의 원본으로 남고, 스킬은 그 위에서 일하는 방법을 제공한다. 리뷰 후속 스킬

다만 같은 파일을 연결했다고 언제나 같은 행동을 한다는 뜻은 아니다. 호스트가 스킬을 어떻게 발견하는지, 어떤 도구를 허용하는지, 실행 당시 무엇을 읽었는지가 다르다. 그래서 이 저장소의 감사 문서도 정적 구성, 합성 검증, 호출 증거, 결과 증거를 나눈다. SKILL.md를 읽었다는 기록만으로 생산성이 개선됐다고 말하지 않는다. 감사와 개인정보 경계

여기서 스킬은 매번 설명하던 업무 지식을 일관된 형태로 제공하는 역할을 맡았다. 다음에 확인할 것은 실행자가 필요한 절차를 잘 찾는지, 그 절차가 검토 부담을 줄이는지다.

결과와 계약을 관리한 예: Career Radar

Career Radar의 판단 기준을 설명하는 것 자체는 스킬로도 가능하다. 이력서와 공고를 읽고, 지원할 만한지 판단하고, 근거 없는 설명을 경계하라고 지시할 수 있다.

내가 코드로 옮긴 부분은 그다음이었다. 구조화된 입력과 판정을 저장하고, 이전 기록을 새 버전에서도 읽고, 근거가 지정한 위치에 실제로 있는지 검사하고, 같은 판정을 화면과 지원 기록에서 재사용하는 일이었다.

현재 개별 판정 경로는 저장된 입력을 읽고, 결정적 검색으로 근거 조각을 찾고, 모델 초안을 받은 뒤 정책·인용·스크리닝 검증을 적용한다. 그 결과를 저장하고 실행 흔적을 남긴다. 모델이 판단을 제안하는 부분과, 프로그램이 계약을 검사하는 부분이 분리되어 있다. Career Radar 아키텍처

개발 중에는 새 점수를 정수로 제한하려다 이전에 저장된 소수 점수를 읽지 못할 뻔했다. 인용 하나가 경계를 벗어났다는 이유로 전체 판정 변환이 실패한 경우도 있었다. 해결은 “모델에게 더 잘 설명하기”만으로 되지 않았다. 읽기 계약과 생성 계약을 나누고, 어떤 오류가 전체 실패를 일으킬지와 어떤 오류는 항목만 제외할지를 코드로 정해야 했다. 사용 확인 후속 기록

이 요구들은 앱의 구성을 선택한 이유다. 사용자에게 얼마나 도움이 되는지는 별도로 확인할 부분이다.

현재 공개 정리 문서는 일반 채팅과의 나란한 비교가 없고, 모델 검증과 호스트 검증에 남은 범위가 있음을 적고 있다. 위치가 맞는 인용이라는 사실도 그 문장이 판단을 의미상 뒷받침한다는 보장이 아니다. 나는 테스트와 실행기를 만들었다는 사실을 사용자의 의사결정이 좋아졌다는 주장으로 바꿀 수 없다. M5 정리와 검증 범위

두 저장소를 놓고 보면 구분이 더 명확하다. 반복하는 방법을 공급하는 데에는 스킬이 맞았고, 기록의 수명과 계약을 관리하는 데에는 코드와 저장소가 필요했다. 그렇다고 모든 스킬을 앱으로 옮겨야 하는 것도, 앱의 모든 절차를 코드로 고정해야 하는 것도 아니었다.

3. 작업의 성격에 맞춰 구현 범위를 정한다

아래는 특정 제품의 공식 분류가 아니라, 앞의 경험과 자료를 종합해 내가 사용할 판단 기준이다.

반복되는 절차와 판단 기준: 스킬

입력과 결과가 기존 도구에 있고, 사람이 실행을 요청하며, 반복되는 판단 기준과 작업 순서가 문제라면 스킬부터 시작할 수 있다. 예를 들면 문서 검토, PR 후속 처리, 정해진 보고 형식에 맞춘 초안 작성이다.

오래 유지할 절차와 실행 때 조회할 사실은 분리하는 편이 좋다. 스킬에는 “어디에서 무엇을 확인하는가”를 두고, 현재 티켓 목록이나 담당자 같은 값은 원본에서 가져온다.

입력과 결과를 명확히 정할 수 있는 계산: 함수나 스크립트

해시 계산, 필드 비교, 허용 목록 검사, 보고서 집계, 입력 검증처럼 조건이 명확한 부분은 모델이 매번 새로 판단할 필요가 없다. 스킬에서 호출하는 작은 스크립트여도 충분하다.

여기서 좋은 신호는 입력과 출력의 계약을 쓸 수 있고, 실패하는 대조군을 만들 수 있다는 것이다. “이 절차를 알아서 잘해”보다 “이 입력이면 이 오류로 거절한다”를 고정할 수 있는 부분을 먼저 뺀다.

설정으로 화면을 만드는 도구: 첫 생성보다 다음 변경

선언형 설정이나 코드 생성이 불필요하다는 뜻은 아니다. 비슷한 입력 화면을 반복해서 만들 때 공통 규칙을 재사용할 수 있다. 공개 프로젝트인 JSON Forms도 데이터 스키마와 UI 스키마를 받아 폼을 렌더링하고, 기본 표현으로 부족한 부분에는 커스텀 React 렌더러를 등록하는 방법을 제공한다. 폼 렌더링의 예시이지, 앱 전체의 코드 생성·배포를 대신한다는 의미는 아니다. UI 스키마, 커스텀 렌더러

새 추상화를 선택한다면 첫 화면을 만드는 데 걸린 시간뿐 아니라 이후의 변경도 봐야 한다. 규칙에 잘 맞는 화면 하나뿐 아니라, 예외 동작이 있는 화면과 기존 화면을 변경하는 작업도 비교한다. 짧은 설정으로 만들 수 있는 부분이 늘어난 만큼, 설정의 문법과 생성기·렌더러의 동작을 이해할 부담이 얼마나 생기는지도 포함한다.

특히 코드를 생성하는 방식이라면 무엇을 원본으로 삼을지 정해야 한다. 생성된 코드를 직접 고쳐도 되는가. 다음 생성 때 그 수정은 보존되는가. 예외를 넣으려면 설정과 템플릿, 생성 결과 중 어디를 바꾸는가. 오류를 원래 입력까지 추적하고, 도구 밖의 일반 코드로 이어갈 방법은 있는가.

생성기의 버전 변경이 기존 화면에 미치는 영향과 배포·원복 경로도 비교에 들어간다. 이것들은 코드 생성이 언제나 나쁘다는 이유가 아니라, 코드 생성을 선택할 때 함께 소유해야 하는 비용이다.

첫 화면을 빨리 만드는 데 성공했다고 해서, 다음 변경도 쉬워졌다고 말할 수는 없다. AI가 설정 파일을 잘 써준다는 시연도 같은 한계가 있다. 기존 컴포넌트와 일반 코드로 같은 일을 했을 때보다 생성·검토·수정·운영 전체가 단순해지는지를 보고 싶다.

여러 접점에서 사용하는 기능: 공유 API나 MCP

채팅과 IDE, 별도 UI가 같은 검색이나 검증을 사용한다면 구현을 각각 복제할 이유가 줄어든다. 공통 기능을 API로 제공하고, 필요하면 MCP로 연결할 수 있다.

이때의 목표는 새로운 포털이 아니라 계약의 재사용이다. 동일한 작업이 어느 접점에서 호출되어도 같은 권한 확인과 검증을 거치게 하는 것이다. 반대로 단일 로컬 작업뿐이라면 네트워크 서버를 추가하지 않고 라이브러리를 공유하는 편이 단순할 수 있다.

실행 중 다음 단계를 골라야 하는 작업: 에이전트

여러 자료를 조사하면서 다음 검색을 바꾸거나, 예상하지 못한 원인을 좁혀 가야 하는 작업에는 동적인 도구 선택이 도움이 될 수 있다. 그러나 정해진 세 단계를 순서대로 실행하면 되는 작업까지 에이전트에게 순서를 맡길 필요는 없다.

모델의 자유도가 더 좋은 결과를 내는지, 불필요한 호출과 종료 지연을 만들지는 않는지 비교한다. 실패했을 때 돌아갈 단순 경로도 남긴다. 에이전트라는 이름보다 경로 선택을 맡겨 얻는 이점이 중요하다.

지속 실행과 공유 상태: 서비스 또는 기존 실행 기반

사람이 창을 닫아도 실행되어야 한다. 중간에 멈춘 작업을 이어야 한다. 두 사용자가 같은 대상을 수정할 수 있다. 승인 결과가 남아야 한다. 같은 요청을 다시 보내도 외부 행동이 중복되지 않아야 한다.

이런 요구가 생기면 실행 상태, 재시도, 멱등성, 동시성, 승인과 감사 이력의 문제가 된다. 지침을 잘 쓰는 것만으로는 충분하지 않다. 기존 워크플로 엔진이나 관리형 런타임을 쓰든 직접 구현하든, 누군가 이 책임을 맡아야 한다.

사용자 수만으로 경계를 나누지는 않는다. 한 사람이 쓰더라도 비용 발생이나 외부 전송, 되돌리기 어려운 변경이 있다면 허용 범위와 한도를 실행 환경에서 강제하고, 별도 승인이 필요한 행동을 구분해야 한다. 반대로 여러 사람이 같은 읽기 전용 스킬을 쓰더라도 별도 중앙 서비스가 필요하지 않을 수 있다.

여러 업무가 공유하는 운영 기능: 공통 기반

서로 다른 업무들이 인증, 실행 추적, 비밀 관리, 재시도와 취소, 배포를 반복해서 필요로 한다면 공통화할 근거가 생긴다. 실제로 겹치는 요구부터 묶고, 업무별로 달라야 하는 규칙은 남겨 둔다.

우선 공통 계약과 작은 라이브러리로 중복을 줄일 수 있는지 본다. 독립 서비스가 필요하다면 운영자를 정하고, 어떤 기존 구현을 대체할지 함께 정한다. 플랫폼을 만들고 기존 개별 구현도 그대로 유지하면 이행 비용만 늘 수 있다.

4. 안내할 규칙과 실행에서 검사할 규칙을 구분한다

“승인 전에는 전송하지 않는다”는 스킬 규칙은 중요하다. 하지만 전송 함수가 승인 상태를 확인하지 않고 호출될 수 있다면 최종 방어선은 아니다.

“공개 문서에는 비밀을 넣지 않는다”는 지침도 필요하다. 그러나 이미 권한 없는 입력을 읽었거나 로그에 원문이 저장된 뒤라면 마지막 문장 검사만으로 문제가 해결되지 않는다.

나는 이를 네 가지로 나누고 싶다.

• 스킬: 언제 승인이 필요한지, 무엇을 검토해야 하는지 설명한다.
• 코드: 입력·출력 계약, 허용 동작, 호출 제한을 검사한다.
• 원본 시스템: 현재 사실과 권한, 변경 이력을 관리한다.
• 실행 환경: 실제 접근 권한과 자격 증명, 격리, 실행 수명을 통제한다.

여러 층에 비슷한 규칙이 있는 것이 항상 중복은 아니다. 설명과 강제의 역할이 다르면 방어가 된다. 문제는 같은 강제 규칙을 여러 진입점이 각자 구현하면서 서로 다르게 바뀌는 경우다.

Career Radar에서도 호출용 실행기를 추가하면서 기존 진입점에서 고쳤던 목적지·로그·재시도 설정을 다시 놓친 적이 있다. 이때의 교훈은 스킬에 주의사항 한 줄을 더 넣는 것으로 끝나면 안 된다. 공통 생성 함수나 전송 경계, 그리고 새 진입점까지 검사하는 테스트로 연결해야 한다. 라이브 측정 하네스 기록

절차의 기억은 스킬에 남기되, 반복해서 틀리는 불변 조건은 실행 경계에 둔다.

관측·판정·조치는 서로 다른 계약이다

업무를 점검하는 자동화라면 무엇을 수집하는지, 어떤 기준으로 해석하는지, 그 결과로 무엇을 바꾸는지를 나눈다. 실행이 끝났다는 기록, 기준에 맞는다는 판정, 실제 변경의 성공은 각각 다른 증거를 요구한다.

Career Radar에서도 이 차이를 만났다. 모델이 쓴 설명에 특정 문장이 있다는 이유로 후처리가 실행됐다고 세면, 모델의 표현과 서버가 실제로 한 일을 혼동한다. 지금은 각 검증 단계가 수행한 작업을 개수로 반환하고, 평가에서는 그 진단을 사용한다. 문장은 독자를 위한 설명으로 남긴다. 단계별 진단과 실행 흔적

다른 점검 도구에도 같은 질문을 적용할 수 있다. 필요한 자료를 얻지 못한 상태와, 자료를 충분히 확인했는데 문제가 없는 상태를 구분하는가. 실행 도구의 오류와 점검 대상의 결함을 구분하는가. 문제를 발견하지 못했다는 것과, 필요한 범위를 검증했다는 것은 다르다.

최종 비교를 코드로 고정해도 비교할 대상과 기대값을 모델이 골랐다면 그 앞의 불확실성은 남는다. 어떤 범위를 검사했는지, 무엇을 빠뜨릴 수 있는지, 기준을 바꿀 때 누가 검토하는지까지 확인해야 한다.

담당자를 표에 적는 것은 출발점이다. 판단할 수 없는 결과가 나왔을 때 보류할지, 사람이 확인할지, 어떤 조건에서 실제 변경을 허용할지가 실행 경로에 연결되어야 한다. 알림을 받는 사람과 조치를 결정할 권한을 가진 사람이 다를 수도 있다. 도구가 낸 판정을 다음 담당자에게 넘기는 것만으로 책임이 정해지지는 않는다.

따라서 점검 도구의 실행 완료와 업무 전체의 효과는 구분하고 싶다. 잘못된 경보를 분류하고 기준을 유지하는 시간까지 포함해, 필요한 판단과 조치를 더 적은 부담으로 끝냈는지를 본다.

5. 직접 구현할 부분과 관리형 서비스에 맡길 부분을 비교한다

맡아야 할 운영 책임이 생겼다고 해서 그 구현체까지 직접 만들어야 하는 것은 아니다. 모델 공급사도 이제 모델 호출뿐 아니라 세션과 실행 수명을 관리하는 층을 제공한다.

OpenAI의 현재 문서는 Responses API, Agents SDK, Agents API를 나눠 설명한다. 모델 응답을 직접 통합할지, 애플리케이션에서 SDK의 루프를 실행할지, 관리형 세션과 실행 체계를 사용할지의 선택이다. 기능이 적은 것에서 많은 것으로 올라가는 순서라기보다 실행과 상태 관리의 책임 배분에 가깝다. OpenAI Agents 선택 가이드

2026년 9월 10일 공개 베타로 출시된 Agents API는 세션·오케스트레이션·컨텍스트 관리와 복구를 서비스에서 맡고, 애플리케이션이 도구와 실행 환경을 연결하는 구성을 제공한다. 확인 시점에는 미국 데이터 레지던시만 지원하고 ZDR 대상이 아니므로, 자체 샌드박스를 붙인다는 이유만으로 데이터 요구가 충족된다고 보면 안 된다. Agents API 개요, 출시 기록

Anthropic의 Claude Managed Agents도 장시간 비동기 작업을 위한 관리형 실행 체계를 제공한다. 도구·MCP·Skills를 함께 구성하고 세션과 이벤트를 다룬다. 스킬을 버리고 서비스로 이동하는 것이 아니라, 같은 스킬을 서비스가 운영하는 실행 안에서 사용할 수 있다. 역시 베타이며, 확인 시점의 문서는 ZDR 적용 대상이 아니라고 밝힌다. Claude Managed Agents 개요

이 서비스들을 직접 비교 실행한 것은 아니다. 따라서 어느 것이 더 빠르거나 저렴하다는 추천은 하지 않는다. 다만 새 실행 플랫폼을 기획한다면, 이미 제공되는 기능과 직접 소유해야 하는 도메인 기능을 먼저 나눌 수 있다.

관리형 서비스의 비교표에는 모델 성능 외에 다음 항목이 있어야 한다.

• 데이터가 어디로 가고 얼마나 남는가. 원본의 권한을 어떻게 적용하는가.
• 중단·재개·중복 요청을 어떻게 처리하며, 실패를 어디까지 관찰할 수 있는가.
• 승인을 어느 지점에서 강제하고, 실행당 비용과 시간 제한을 걸 수 있는가.
• 결과와 이력을 내보낼 수 있는가. 공급자 변경이나 장애 때 단순 경로로 돌아갈 수 있는가.
• 서비스가 제공하지 않는 부분의 운영자는 누구인가.

접근 제어와 보관 요구를 만족하지 못하면 기능이 많아도 후보에서 빠질 수 있다. 반대로 이미 쓰는 제품이 요구를 충족한다면, 직접 만드는 것이 학습에는 유익해도 운영상의 최선인지는 별도로 판단해야 한다.

운영 사례에서 참고할 점

OpenAI가 공개한 내부 데이터 에이전트 사례에서 눈에 들어온 것은 큰 모델이나 데이터 규모보다 도구 구성에 대한 설명이었다. 초기에 겹치는 기능까지 모두 노출하니 에이전트가 혼란스러워했고, 호출 가능한 도구를 제한하고 통합했다고 한다.

동시에 기존 Slack·IDE·MCP 같은 접점을 활용하고 사용자 권한을 승계했으며, 전문가의 기준 SQL과 생성 SQL의 결과를 비교하는 평가를 운영했다. 새로운 에이전트를 만들되, 원본 권한과 평가 기준을 별도로 유지한 것이다. 공급사가 공개한 운영 사례이지 독립적인 생산성 실험은 아니지만, 기능 수를 늘리는 것과 사용자 문제를 해결하는 것이 다르다는 설계 사례로 읽을 수 있다. OpenAI 데이터 에이전트 사례

Cisco 사례에서는 공통 기반과 개인화를 함께 봐야 한다. 2026년 7월의 공식 설명은 Circuit이라는 공통 환경에서 모델과 기업 데이터에 접근하고, 직원들이 프롬프트와 프로젝트를 공유하며 연결 기능과 에이전트를 만들 수 있다고 한다. 개인의 실험을 금지하고 중앙에서 모든 기능을 만드는 방식으로 설명하지 않는다. 목표도 최대 자율성이 아니라 작업에 맞는 자율성이라고 명시한다. Cisco의 AI 운영 기반

이어 8월에 소개한 MyAgent는 그 기반 위에서 개인의 맥락을 활용하고, 승인된 모델·시스템·데이터 경로를 통해 업무를 연결하는 방향이다. 사람이 감독하고 결과에 책임지는 구조도 함께 설명한다. 당시 글은 확대 배포 중이라는 발표이며, 모든 직원의 업무가 끝까지 자동화됐다는 검증 결과로 읽지 않았다. Cisco MyAgent 소개

내가 참고할 점은 ‘개인 에이전트냐, 공통 플랫폼이냐’의 양자택일이 아니다. 공통으로 통제할 권한과 데이터 경로를 마련하면서 업무별 실험과 재사용을 연결하는 방식이다. 이 사례를 보고 곧바로 비슷한 플랫폼을 새로 만들기보다, 지금 환경에서 어느 책임이 비어 있는지 먼저 확인하고 싶다.

Anthropic의 다중 에이전트 리서치 사례도 다른 방향에서 같은 주의를 준다. 내부 리서치 평가에서는 다중 에이전트가 단일 에이전트보다 좋은 성과를 냈지만, 일반 채팅 대비 토큰 사용이 크게 늘었고 중복 조사와 과도한 하위 에이전트 생성도 문제였다. 책임 분할과 예산, 평가와 복구가 함께 필요했다. 이는 병렬화가 유효한 작업의 사례이지, 에이전트를 많이 만들수록 좋다는 증거는 아니다. 다중 에이전트 리서치 시스템

도구 검색 기능도 이미 제공된다. Anthropic과 OpenAI 모두 필요한 도구 정의를 나중에 불러오는 방식을 설명한다. 컨텍스트에 모든 정의를 한꺼번에 넣는 부담을 줄이는 접근이다. 하지만 검색이 잘된다고 두 도구 중 누가 최신 계약을 소유하는지, 누가 장애에 대응하는지까지 해결되지는 않는다. 발견 비용과 운영 비용은 별개라는 것이 이 기능들을 읽고 내린 판단이다. Anthropic 도구 사용, OpenAI Tool search

6. 적용 전후에 같은 완료 기준으로 비교한다

개인의 작업 다음에 남는 일을 본다

개인이 초안을 만드는 단계와 업무 전체가 완료되는 단계는 다를 수 있다. 검토자가 근거를 다시 찾고, 다음 담당자가 형식을 바꾸고, 승인자가 맥락을 다시 확인해야 한다면 생성 시간만으로 효과를 설명하기 어렵다.

가상의 문서 승인 작업을 생각해 보자. 작성은 빨라졌지만 검토에 들어오는 문서의 양만 늘고 승인 가능한 결과는 그대로라면, 완료된 일이 아니라 진행 중인 일이 쌓일 수 있다. 반대로 근거 정리와 누락 검사로 검토 단계가 짧아지면 전체 흐름에도 도움이 될 수 있다. 개인 도구라서 효과가 없는 것도, 팀 단위 에이전트라서 효과가 있는 것도 아니다. 어느 병목과 재작업을 줄였는지가 중요하다.

그래서 다음 담당자가 받아갈 조건을 먼저 적는다. 필요한 근거, 확인된 사실과 미확인 사항, 승인할 사람, 다음 단계로 넘길 상태다. 에이전트끼리 직접 통신하는 구조가 아니어도 이 인계는 개선할 수 있다. 기존 업무 시스템에 상태를 남기고, 정해진 형식과 검증을 공유하는 것으로 충분한 경우도 있다.

내 작업이 빨라졌다는 이유로 다음 사람에게 늘어난 확인 작업을 계산에서 빼지는 않았으면 한다. AI 적용의 단위를 고를 때도 개인의 입력부터 다음 단계의 수용까지 함께 보고 싶다.

효과를 판단할 근거를 나눈다

구성을 선택했다면 다음에는 적용 효과를 본다. 기존 글에서 합성 테스트와 실제 호출을 나눠 적었듯이, 구현이 동작한다는 것과 업무에 도움이 된다는 것도 나눠 확인한다. 공개 연구도 작업과 측정 방법에 따라 서로 다른 결과를 보고한다.

METR의 2025년 실험은 익숙한 저장소에서 일하는 숙련 개발자들이 AI를 허용한 조건에서 더 오래 걸렸고, 체감은 그와 달랐다고 보고했다. 다만 2026년 후속 발표는 도구와 작업 선택이 바뀌었으며 선택 편향 등으로 현재 효과를 신뢰성 있게 추정하기 어렵다고 설명한다. 초기 결과를 모든 AI 작업에 적용할 수는 없다. METR 초기 실험, 후속 발표

반대로 기업의 Copilot 접근 권한을 무작위 배정한 세 현장 실험은 주간 완료 PR 수 증가를 보고했다. DORA 2025는 AI 채택과 전달 처리량·안정성의 관계를 각각 살폈다. 앞의 완료 시간 실험과는 측정값도 방법도 다르다. 특정 도구가 언제나 좋거나 나쁘다는 결론보다, 내 작업의 완료 기준을 먼저 정해야 한다는 참고 자료로 읽었다. Copilot 현장 실험, DORA 2025

점수의 이름보다 무엇을 읽고 매겼는지 본다

프롬프트나 에이전트 사용을 점수화하는 도구도 이 구분에서 예외가 아니다. 하나의 대시보드에 나란히 보이는 값이라도 서로 다른 질문의 답일 수 있다.

계획과 검증을 명확히 요청하는 습관은 유용하다. 다만 요청문을 채점한 점수와, 그 요청대로 실행했는지 검사한 결과와, 실제로 일이 좋아졌는지는 별개다. 대화 전체를 읽는 평가도 마찬가지다. 그 대화 밖의 검토와 수정, 다른 도구에서 한 작업까지 자동으로 알고 있는 것은 아니다.

Anthropic의 평가 가이드도 실행 기록과 환경에 남은 최종 결과를 구분한다. 모델을 평가자로 사용할 때는 해당 분야 전문가의 판단과 대조해 보정하고, 정보가 부족하면 판단을 유보할 수 있게 하라고 권고한다. 자동 평가를 실제 운영 관찰과 사용자 피드백, 사람 검토와 함께 사용하라는 설명이다. 이것은 특정 프롬프트 점수 제품을 검증한 자료가 아니라, 평가 자체도 검증해야 한다는 설계 근거다. 에이전트 평가 가이드

평가 기준이 작업에 맞는지도 확인한다. 단순 조회에 병렬 에이전트가 필요하지 않을 수 있고, 이미 공유된 절차를 불러왔다면 요청문을 다시 길게 쓰지 않아도 될 수 있다. 적용할 이유가 없는 항목을 어떻게 처리하는지, 짧게 끝난 좋은 실행을 낮게 보지는 않는지 점검해야 한다. 점수를 올리기 위해 불필요한 계획·위임·설명을 덧붙이게 된다면 도구의 목적을 다시 봐야 한다.

좋은 사례를 골라 공통 습관을 소개하는 일은 교육과 가설 수집에 도움이 된다. 하지만 결과가 좋은 사례만 골라 찾은 습관이 그 결과의 원인이었다고 바로 말할 수는 없다. 업무 종류와 난도, 경험, 기존 자산, 검토 지원의 차이도 남아 있다. 요청문을 편집한 전후의 점수 비교도 채점 기준의 반응을 보여줄 뿐이다. 두 방식으로 실제 업무를 끝냈을 때의 차이는 따로 확인해야 한다.

그래서 나는 점수를 잘 받는 방법보다, 그 점수가 좋은 결과와 어디까지 연결되는지 먼저 확인하고 싶다. 평가를 부정하는 것이 아니라, 관찰과 해석과 의사결정 사이에 필요한 근거를 생략하지 않겠다는 뜻이다.

기록할 항목

내가 제안하는 비교 단위는 수용 가능한 결과에 도달한 업무 한 건이다. 아래는 연구가 검증한 단일 표준이 아니라, 두 프로젝트의 다음 판단에 사용할 실무 기준이다.

토큰과 호출 수는 비용과 실행을 이해하는 자료다. 스킬 수와 PR 수는 산출물의 양이다. 사용 빈도는 수요의 신호가 될 수 있다. 어느 것도 혼자서는 사용자 가치의 증명이 아니다.

예를 들어 자동 보고서가 30초 만에 만들어졌다고 해도 원본 대조에 10분이 필요하다면, 30초만 측정하면 안 된다. 이 숫자는 측정 결과가 아니라 설명용 가정이다. 보고서를 만드는 사람의 시간이 줄고 읽는 사람의 시간이 늘었다면 둘 다 계산해야 한다.

개인 에이전트가 병렬로 실행되는 경우도 비슷하다. 벽시계 시간과 사람이 실제로 주의를 쓴 시간을 분리한다. 기다리는 동안 다른 일을 할 수 있다는 장점과, 여러 결과를 다시 모으는 검토 비용을 동시에 본다.

측정을 사람 순위표로 바꾸지도 않겠다. 목표는 누가 AI를 많이 썼는지 평가하는 것이 아니라, 어떤 경로가 같은 품질의 업무를 더 적은 부담으로 끝내는지 찾는 것이다. 원문 프롬프트나 민감한 업무 내용을 전부 중앙 수집하지 않아도, 목적에 필요한 단계와 시간·오류 분류를 제한적으로 기록할 수 있다.

일반 채팅, 스킬, 앱을 나란히 놓아 보기

새 도구의 가치를 보려면 비교 대상이 있어야 한다. “예전에는 손으로 했다”는 기억만으로는 현재의 일반 채팅이나 기존 제품 기능보다 나은지 알기 어렵다.

가능한 작업에는 세 경로를 놓아 볼 수 있다.

1. 기존 제품과 일반 채팅으로 수행한다.
2. 같은 입력과 권한으로 스킬을 사용한다.
3. 새 워크플로나 앱을 사용한다.

각 경로에서 완료의 기준은 같아야 한다. 지원 우선순위를 정하는 작업이라면 예쁜 카드의 수가 아니라, 필요한 근거를 확인하고 다음 행동을 정할 수 있는지를 본다. 이슈 점검이라면 문서가 생성됐는지가 아니라, 수정해야 할 대상을 정확히 찾고 수정 후 남은 대상을 다시 확인할 수 있는지를 본다.

가능하면 모델과 입력, 도구 접근 권한을 맞춘다. 전체 시스템을 비교하려고 일부 조건이 다르다면 그 차이를 적는다. 같은 문제를 반복하면 학습 효과가 생기므로 순서를 바꾸거나 비슷한 난도의 작업을 짝지을 수 있다. 적은 수의 파일럿은 방향을 정하는 자료이지 일반적인 효과 크기를 입증하는 실험은 아니다.

그리고 성공한 데모만 남기지 않는다. 타임아웃, 설정 오류, 도구를 고르다 포기한 경우, 수동으로 다시 끝낸 경우도 비교에 들어가야 한다. 결과 파일을 잃어버린 실행을 보고서에서 지워 버리면 사용자가 겪은 비용도 사라진다.

Career Radar의 다음 가치 검증도 결국 이 자리로 돌아온다. 저장과 재개, 검증기를 잘 만들었다는 사실은 기반이다. 그 기반이 실제 판단을 더 쉽게 만드는지는 다른 질문이다. agent-skill-garden 역시 설치 가능성과 재사용 가능성 다음에, 올바른 절차를 찾는 시간과 검토 부담을 비교해야 한다.

7. 함께 사용할 때의 원본과 유지 책임을 정한다

개인의 실험을 장려하는 일과 운영 도구로 채택하는 일은 별도 판단이라고 생각한다. 교육과 탐색에서는 여러 방법을 시도할 수 있다. 다만 그 결과를 다른 사람이 반복해서 사용하고, 외부 시스템을 변경하거나 업무의 완료 여부를 맡기기 시작하면 유지 조건도 함께 정해야 한다.

이때 필요한 것은 모든 개인 스킬을 제품처럼 관리하는 일이 아니다. 어느 도구가 공유 업무의 일부가 됐는지 구분하는 일이다. 담당자가 바뀌어도 이어받을 수 있는지, 같은 기능을 만드는 대신 재사용할 수 있는지, 접근 권한을 회수하고 실패를 복구할 수 있는지를 확인한다.

여러 사람이 쓰거나 여러 실행 환경에 연결할 때는 공통으로 지켜야 할 계약을 정한다. 하나의 화면으로 모을지, 기존 접점을 유지할지는 그다음에 선택할 수 있다.

사실의 원본. 상태는 어디에서 수정하고 어느 저장소가 최종 권위를 갖는가. 검색 색인·캐시·보고서는 파생물임을 명시한다. 여러 뷰가 있는 것 자체는 문제가 아니다. 각 뷰가 어떤 원본과 시점을 보여주는지 알 수 없는 것이 문제다.

기능의 소유자. 비슷한 이름의 스킬과 도구가 같은 일을 한다면 어느 것이 유지되는가. 새 구현이 기존 것을 대체하는지, 다른 요구를 맡는지, 사용자가 어떻게 구분하는지 적는다.

권한과 부작용. 읽기와 변경, 내부 계산과 외부 전송을 구분한다. 승인 후에도 실제 실행 시점의 권한과 대상 상태를 다시 확인해야 하는 행동이 있다.

실행과 실패. 같은 실행을 식별하고, 어디에서 중단됐는지 알 수 있어야 한다. 다시 실행하면 무엇을 재사용하고 무엇을 다시 호출하는지도 계약이다.

검증과 교체. 어느 버전에서 무엇을 확인했는지, 다음 변경이 어떤 기존 데이터를 계속 읽어야 하는지, 대체 도구로 넘어갈 때 무엇을 내보낼 수 있는지 정한다.

공통의 상태를 이해한다는 것도 모두에게 같은 데이터를 보여준다는 뜻은 아니다. 각자의 권한 범위 안에서 상태의 의미와 기준 시점, 변경 규칙, 인계 조건을 일관되게 해석한다는 뜻에 가깝다.

이를 처음부터 별도 레지스트리 서비스로 만들 필요는 없다. 작은 저장소의 문서와 테스트, 기존 권한 체계로 시작할 수 있다. 다음 문제를 해결하기 위해 상태와 자동화가 실제로 필요해질 때 서비스로 확장하면 된다.

카탈로그에는 해결하는 사용자 문제, 원본 시스템, 소유자, 입력·출력, 부작용, 검증된 버전, 대체 관계를 함께 적는다. 사용자는 적합한 기능을 찾고, 유지 담당자는 변경의 영향을 확인하는 데 사용할 수 있다.

관측 도구가 멈춰도 사실의 원본은 남아야 한다

공통 도구를 쓰는 것과 그 도구만 진실을 알고 있게 만드는 것은 다르다. 수집이 지연되거나 일부 입력을 놓칠 수 있으므로, 숫자와 함께 어떤 기간·도구·사용자·작업이 수집됐는지 확인할 수 있어야 한다. 미수집, 처리 중, 해당 없음, 확인된 0은 서로 다른 상태다.

관측 중단이 실제 실행까지 멈추게 한다면 운영상의 단일 장애점이 될 수 있다. 업무는 계속되지만 불완전한 기록이 판단의 유일한 근거가 된다면, 그것은 판단 근거가 한곳에 치우친 문제다. 둘을 구분해야 대응도 정할 수 있다.

대책이 반드시 두 번째 관측 플랫폼을 만드는 것은 아니다. 원본 변경 이력을 확인하는 경로, 장애 구간의 표시, 누락 자료의 재수집과 중복 제거, 정정 후 다시 계산하는 방법부터 정한다. 보관 기간과 접근 권한을 지키면서 필요한 증거를 내보낼 수 있는지도 본다. 복구되지 않은 구간의 점수는 비교에서 제외하거나 판단을 유보하고, 그 제외 범위도 숨기지 않는다.

일반 관측 기록의 저장 실패가 이미 완료한 업무 결과까지 실패로 바꾸게 할 필요는 없다. 반면 감사 기록이 필수인 고위험 변경은 별도 정책에 따라 보류해야 할 수 있다. 무엇을 계속하고 무엇을 멈출지 도구 도입 전에 정할 일이다.

관측 도구의 빈칸을 사람의 무활동으로 바꾸어 읽지 않았으면 한다. 수집·복구·정정에 드는 시간도 운영 비용이다. 대시보드를 유지하는 일이 원래 줄이려던 업무보다 커지지는 않는지 함께 확인한다.

시작할 때 남겨 둘 짧은 메모

개인 실험에서 많은 도구를 만들어 보는 것은 충분히 가치가 있다. Career Radar도 포트폴리오와 학습의 성격이 있다. 중요한 것은 학습 성과를 운영 효과와 혼동하지 않는 것이다.

실험이라면 무엇을 배우려는지와 언제 끝낼지 적으면 된다. 반복 사용할 운영 도구라면 유지 책임과 대체 경로가 필요하다. 전자가 후자로 조용히 넘어가는 순간, 만든 사람에게만 있던 지식이 사용자 모두의 의존성이 된다.

그래서 시작할 때 이런 짧은 제안서를 남기고 싶다.

사용자와 완료할 일:
현재 방법과 불편의 근거:
기존 제품으로 되는 부분 / 확인한 빈 부분:
추가할 최소 구성: 설정, 스킬, 스크립트, 연결, 서비스 중 무엇인가
사실의 원본과 파생 데이터의 갱신 규칙:
권한, 외부 전송, 승인, 실패 시 돌아갈 경로:
같은 품질에서 비교할 시간과 사람의 부담:
지표가 직접 관찰한 것 / 추정한 것 / 수집하지 못한 것:
설정·생성 도구의 예외 처리와 일반 코드로 돌아갈 경로:
관측 장애 때 계속할 일·보류할 판단·정정 방법:
유지 담당자와 다시 검토할 시점:
적용 후 단순화할 작업 / 효과가 없을 때 돌아갈 방법:

모든 칸을 길게 채울 필요는 없다. 확인한 것은 적고, 아직 결정하지 못한 것은 질문으로 남긴다. 실험이 끝나면 그 질문을 다시 보면서 유지하거나 단순화할 부분을 정한다.

스킬만으로 반복 설명과 재작업을 충분히 줄였다면 그 구성으로 유지해도 된다. 저장과 복구가 필요해졌다면 해당 부분을 추가한다. 선택한 형태보다 다음 요구를 확인하면서 조정하는 과정이 중요하다.

내가 기대하는 AI 적용

두 프로젝트를 만들며 정리한 기준은 이렇다. 반복하는 방법은 스킬로, 일관되게 적용해야 하는 규칙은 코드로, 공유하는 사실은 원본 시스템에, 지속 실행과 권한의 강제는 그 책임을 맡은 실행 환경에 둔다. 기존 제품의 기능과 관리형 서비스도 같은 기준으로 비교한다.

이것은 두 프로젝트가 입증한 보편적인 정답은 아니다. 구현과 리뷰에서 확인한 경계를 다음 설계에 써 보기 위해 정리한 기준이다. 실제 업무에 도움이 되는지는 같은 완료 조건으로 사용해 보고 확인할 부분이 남아 있다.

나는 개인에게 실험할 기회를 주는 것에 찬성한다. 다만 도구를 배포한 뒤 연결과 유지의 책임까지 각자 알아서 해결하게 두는 것을 AI 전략의 완성으로 보고 싶지는 않다. 공통으로 해결할 문제에는 기반과 담당자를 두고, 업무별로 달라야 하는 절차에는 선택할 여지를 주었으면 한다.

마찬가지로 모든 문제를 공통 플랫폼이나 멀티에이전트로 해결하려는 것도 답은 아니라고 생각한다. 기존 제품의 설정 하나로 충분한 일이 있고, 스킬과 스크립트가 맞는 일이 있으며, 독립적인 실행 체계가 필요한 일도 있다. 자율성이 높을수록 좋은 것도 아니다. 어떤 선택에도 은탄환은 없다.

이 가이드에서 가장 남기고 싶은 기준은 단순하다. 필요하지 않은 도구를 더 만들기 전에, 지금 업무에서 무엇이 기다리고 무엇을 다시 하고 있는지부터 확인한다. 새 도구가 필요하다면 그 이유와 남는 책임을 함께 정하고, 만든 뒤에는 생성량이 아니라 완료와 재작업을 본다.

앞선 글에서는 작은 변경을 만들고 어디까지 확인했는지 적었다. 다음 AI 적용에서도 그 순서를 이어 가려 한다. AI를 얼마나 많이 붙였는지보다, 사람이 끝내려던 일을 얼마나 잘 끝낼 수 있게 됐는지 설명할 수 있었으면 한다.