사내 AI의 확산과 통제 — 금지가 아니라 설계로 막는다
노코드 워크플로우의 고급 패턴부터 관측·비용 통제·거버넌스 3계층까지, 개발자 없이 굴러가는 AI 업무를 확산 속도를 떨어뜨리지 않고 통제하는 구조를 정리한다.
직접 구축하고 운영하며 정리한 플랫폼 기술 기록입니다. 주제별로 묶어 두었습니다.
노코드 워크플로우의 고급 패턴부터 관측·비용 통제·거버넌스 3계층까지, 개발자 없이 굴러가는 AI 업무를 확산 속도를 떨어뜨리지 않고 통제하는 구조를 정리한다.
RAG를 8단계로 나눠 전체 지도를 그리고, 사전처리의 첫 두 단계인 문서 로드와 텍스트 분할의 선택지·튜닝 파라미터·실패 모드를 정리한다.
코난·IDOL 상용 엔진으로 검색을 구축하다 Elasticsearch로 넘어오며, 규격서가 대신 내려주던 결정을 직접 설계하게 된 과정을 정리한다.
한국어 검색 품질을 결정하는 분석기 파이프라인, 형태소 분석기 Nori, 자소분해 기반 초성·한영검색, 자동완성 전략, 무결과 폴백 정책을 정리한다.
이 카테고리의 30편을 두 번 갠다 — 발행 구조 그대로인 8개 시리즈와 독립편 2로 한 번, 깊이 순서의 15개 주제로 다시 한 번. 목적별 읽는 순서 여덟 갈래를 함께 놓고, 두 지도 어느 쪽에서도 빠지는 편이 없는지 자리를 세어 확인한다.
1인 SaaS·제조유통·서비스콘텐츠 세 업종의 조직 규칙 문서를 열 개 축으로 나란히 놓고, 업종이 바뀔 때 무엇이 바뀌고 무엇이 자리를 지키는지 센다. 원 자료가 같은 파일에 붙이는 200줄이 이 카테고리의 다른 글들이 쓰는 200줄과 같은 값을 다른 목적으로 재고 있다는 것도 짚는다. 뒤쪽은 프롬프트 쪽에서 아직 이 카테고리에 없던 것들 — 안티패턴 5가지와 Plan Mode를 강제 절차로 바꾸는 하드 게이트 한 줄이다.
빈 폴더 하나에서 배포까지 가는 8단계와, 그중 데이터·인증 구간만 확대한 6단계를 나란히 놓는다. 두 순서를 단계별로 대조하면 여덟 중 넷만 여섯과 맞물리고 나머지는 각자 남는다. RLS를 인증보다 먼저 두는 순서의 이유, AI 기능을 붙인 뒤에 터지는 비용 폭주와 프롬프트 주입을 막는 방어선, 그리고 정책을 만든 뒤 익명 역할로 직접 공격해 보는 네 줄짜리 검증까지 이어 붙인다.
배포 전·중·후·롤백·보안·성능 여섯 섹션을 65개 항목으로 펼치고, 섹션마다 다른 점검 주기를 한 장의 흐름도로 그린다. 롤백 섹션은 표가 둘이라 14로 세기 쉬운데 항목은 여덟이며, 합계가 65가 되는지로 검산한다. 뒤쪽은 디버깅 — 재현·가설·검증·회귀방지 4 Phase와 13행 함정 카탈로그, 프롬프트 10패턴이다. 이 카테고리의 다른 글이 쓰는 「증상→원인→해결→예방」 4단과 이름이 같은데 카탈로그가 겹치는지 행 단위로 세어 본 결과도 함께 적는다.
에이전트를 통제하는 세 수단을 규범·강제·절차로 갈라 놓고, 비교표의 「강제력」 열이 셋 중 하나에서만 「있음」이 되는 구조를 본다. 훅 5종·차단 규칙 7종·운영 규약 6항목을 전부 펼치고, 훅 표가 요약한 사고 5가지를 차단 규칙 7종에 하나씩 배정해 어느 둘이 남는지 센다. 훅의 차단 사유가 어느 채널로 나가는지에 대해 원 자료의 표 안에서 두 행이 갈리고, 같은 카테고리의 다른 두 글도 서로 다르게 적어 두었다는 사실도 나란히 놓는다.
에이전트 운영 중 나는 장애를 외부 의존·자원 한도·내부 설정 3계층으로 먼저 좁히고, 증상→원인→해결→예방 4단으로 분해하는 진단 프레임. 가장 자주 나오는 문제 10선과 실제 장애 5건을 같은 틀에 넣고, 일일·주간·월간 점검 루틴과 계층별 진단 순서까지 정리한다.
7개 부서 30개 에이전트 정의서를 한 장의 표로 펼친다. 모델은 opus 10 : sonnet 20으로 갈리고 도구 변형은 세 가지뿐인데, 정작 외부 시스템 연동은 프론트매터에 드러나지 않는다. 사람 검수 필요도의 요약값과 카탈로그를 세어 본 값이 어긋나는 자리, 그리고 같은 카테고리의 다른 글에 있는 30에이전트 표와 이 표가 같은 세트가 아니라는 근거도 함께 짚는다.
에이전트를 만든 다음이 아니라 만들기 전에 정해야 하는 것 — 무엇을 자동화 대상으로 고를지 판단하는 두 도구와, 「끝났다」를 판정하는 5축 정량 루브릭, 그리고 조직 규칙 문서를 60줄로 유지하는 이유를 정리한다. 같은 문서의 분량을 이 카테고리의 다른 글이 200줄로 부른 것과의 관계도 함께 짚는다.
7개 부서 30에이전트 세트에서 개발기술 4종을 자세히 보고, 나머지 26종 중 개발조직 실무로 옮길 수 있는 것과 참고만 할 것을 가른다. 재사용 후보 10종이 실제로 옮기는 것은 에이전트가 아니라 그 에이전트가 강제하던 형식이며, 도입 순서를 개수로 끊는 근거는 트리거 키워드 충돌이다. 마지막으로 이 세트에 아예 자리가 없는 여섯 영역을 짚는다.
에이전트가 10개를 넘을 때 라우팅·비용·디버깅이 동시에 무너지는 메커니즘과, 5개에서 100개까지 구간별로 갈아타야 하는 운영 모델을 정리한다. 재사용 라이브러리와 권한 등급, 비용을 축별로 나누는 방법, 그리고 「그래서 효과가 얼마였나」에 답하는 증명 3종과 반복 실패 패턴 4가지까지 잇는다.