사내 AI의 확산과 통제 — 금지가 아니라 설계로 막는다

노코드 확산의 최대 공포는 **"누가 뭘 만들었는지 모르고 비용만 나간다"**는 것이다. 그런데 이 공포에 금지 목록으로 대응하면 확산 자체가 멈춘다. 금지로 막으면 도입이 멈추고, 설계로 막으면 멈추지 않는다.

이 글은 그 설계를 다룬다. 노코드가 어디까지 갈 수 있는지 보여주는 고급 패턴 5종에서 시작해, 플랫폼이 제공하는 관측 수단을 거버넌스 자산으로 바꾸는 방법, 비용이 새는 지점 열 곳, 그리고 사전·배포·사후 3계층 통제 구조까지 이어진다. 개별 워크플로우 패턴은 앞 편에 있다.

용어 정리

노코드의 상한선 — 고급 패턴 다섯

경로 마커 — 작지만 결정적인 UX 장치

웹검색 / 일반질문 / 문서검색 3경로를 라우팅한 뒤 단일 출력으로 모으는 워크플로우다.

경로 마커는 작지만 중요하다. 답변이 사내 문서 기반인지 웹 기반인지를 사용자가 즉시 알면 신뢰 수준을 스스로 조절할 수 있다.

사내 배포 시 "답변의 출처 경로를 항상 표기한다"를 표준 규칙으로 삼을 근거다.

Query Expansion — 노코드가 갈 수 있는 가장 먼 지점

문자열을 배열로 바꾸는 코드 노드는 세 줄이다.

def main(questions: str) -> dict:
    question_list = questions.strip().split(",")
    return {
        "result": [q.strip() for q in question_list],
    }

이 워크플로우가 노코드의 상한선을 보여준다. Query Expansion + 병렬 검색 + Rerank는 코드 기반 RAG에서도 상급 기법인데 노드 조립으로 구현됐다.

동시에 한계도 드러난다. 확장 질의의 품질을 측정할 방법이 없고, 실패 시 재시도 전략을 세밀하게 짤 수 없다. 품질 게이트가 필요해지는 순간이 코드로 이관할 시점이다.

에이전트는 확산 초기의 표준이 아니다

도구 선택을 LLM에 위임하는 구성이다.

사내 배포 관점에서 에이전트는 비용과 경로가 런타임에 결정돼 예측이 안 된다는 점이 결정적 단점이다.

확산 초기에는 워크플로우를 표준으로 삼고, 에이전트는 max_iteration을 낮게 잡아 제한적으로 허용한다.

긴 산출물은 나눠서 만든다

주제 하나로 웹 리서치를 수행하고 섹션별로 나눠 쓴 보고서를 조립하는 워크플로우다. 노드 22개로 가장 크다.

긴 문서를 만드는 표준 패턴이 여기 있다. 수집 팬아웃 → 구조 추출 → 섹션별 병렬 생성 → 템플릿 조립.

LLM 하나에게 "보고서 다 써줘"라고 시키는 것보다 품질·길이·형식 모든 면에서 유리하다. 다만 LLM 호출이 1 + N + 1 + 4회이므로 1건당 비용이 크게 올라간다. 사용 빈도가 높은 업무라면 비용 상한 설계가 먼저다.

오래 걸리는 작업의 체감 지연을 관리한다

핵심은 답변 노드를 흐름 중간에 배치한 것이다. 채팅플로우의 답변 노드는 종료 노드가 아니라 출력 지점이므로, 중간 결과를 즉시 사용자에게 흘려보낼 수 있다.

draft → conclusion → waiting → podcast 순으로 네 번 출력하고, 음성 생성처럼 오래 걸리는 단계 앞에는 대기 안내를 넣었다.

긴 작업의 UX 설계 원칙이 노드 배치로 표현된 사례다. 코드 기반이라면 스트리밍 콜백을 직접 짜야 할 것을 답변 노드를 중간에 놓는 것만으로 해결했다.

관측 — 노코드에도 관측이 있다

트레이싱과 토큰 집계가 있다는 사실이 확산 공포에 대한 1차 방어이고, 관측 데이터를 정기적으로 리뷰하는 루틴이 2차 방어다. 도구가 있어도 보는 사람이 없으면 데이터는 쌓이기만 한다.

워크플로우 도구화 — 거버넌스의 가장 강력한 수단

만든 워크플로우를 다른 앱과 에이전트가 호출할 수 있는 Tool로 등록하는 기능이다.

이것이 노코드 거버넌스의 가장 강력한 도구다.

금지 목록으로 통제하는 대신 안전한 부품만 제공해서 위험한 조합이 애초에 만들어지지 않게 한다.

금지가 아니라 설계로 통제하는 방식이고, 확산 속도를 떨어뜨리지 않는 유일한 통제 방식이기도 하다.

도입 로드맵 — 순서를 지키는 것이 절반이다

0단계(경계) 없이 1단계로 가면 나중에 전부 다시 만들어야 하고, 2단계(부품화) 없이 3단계로 가면 난립한다.

3단계의 성공 지표에 주목할 필요가 있다. 만들어진 앱 수가 아니라 개발 개입 없이 완결된 비율이다. 앱 수는 난립해도 올라가지만 이 비율은 부품이 제대로 갖춰졌을 때만 오른다.

지식베이스 권한 통제

두 번째 행이 가장 중요하다. 프롬프트로 "기밀 문서는 답하지 마라"고 쓰는 것은 통제가 아니다. 적재하지 않는 것만이 통제다.

비용이 새는 열 곳

비용 사고의 전형은 둘이다 — ① 이터레이션 병렬 수를 크게 잡아 순간 폭주 ② 메모리 창 없이 긴 대화가 누적.

둘 다 워크플로우 리뷰에서 눈으로 잡히는 항목이므로, 배포 전 체크리스트에 이 두 개를 명시하는 것만으로 대부분 예방된다.

거버넌스 3계층

배포 전 체크리스트

노코드 산출물에 버전관리 붙이기

단, DSL에는 프롬프트·노드 좌표·UI 상태가 뒤섞여 있어 diff 가독성은 코드보다 나쁘다.

그리고 DSL에 API 키·데이터셋 식별자 같은 민감값이 포함될 수 있으므로 저장소에 올리기 전 마스킹 규칙을 먼저 정해야 한다. 자격증명은 항상 환경변수 쪽에 두는 것이 원칙이다.

설계 원칙 열 가지

열 개를 관통하는 하나는 이것이다. 노코드 도입의 성패는 도구가 아니라 부품과 관측을 누가 언제 갖추느냐로 갈린다. 개발조직의 역할이 구현자에서 플랫폼 제공자로 바뀌고, 평가 기준도 요청 처리량이 아니라 현업이 개발 개입 없이 끝낸 비율로 바뀐다.

노코드 도입과 통제에서 반복해 부딪히는 판단은 RAG 운영 Q&A에 문답으로 모았다.