태그
26편
마케팅·영업·고객지원·인사 네 부서의 에이전트 각론이다. 네 부서 모두 자동화를 멈출 지점을 숫자나 게이트로 못박아 두는데, 그 장치의 형태가 부서마다 다르다 — 마케팅은 검수 점수 70, 영업은 할인 승인, 고객지원은 신뢰도 0.85와 0.70, 인사는 HARD-GATE 세 곳이다. 실습 에이전트 ID 일곱 종이 이미 발행된 30에이전트 카탈로그와 이름이 겹치면서 정의는 갈리는 자리도 대조해 둔다.
빈 폴더 하나에서 배포까지 가는 8단계와, 그중 데이터·인증 구간만 확대한 6단계를 나란히 놓는다. 두 순서를 단계별로 대조하면 여덟 중 넷만 여섯과 맞물리고 나머지는 각자 남는다. RLS를 인증보다 먼저 두는 순서의 이유, AI 기능을 붙인 뒤에 터지는 비용 폭주와 프롬프트 주입을 막는 방어선, 그리고 정책을 만든 뒤 익명 역할로 직접 공격해 보는 네 줄짜리 검증까지 이어 붙인다.
배포 전·중·후·롤백·보안·성능 여섯 섹션을 65개 항목으로 펼치고, 섹션마다 다른 점검 주기를 한 장의 흐름도로 그린다. 롤백 섹션은 표가 둘이라 14로 세기 쉬운데 항목은 여덟이며, 합계가 65가 되는지로 검산한다. 뒤쪽은 디버깅 — 재현·가설·검증·회귀방지 4 Phase와 13행 함정 카탈로그, 프롬프트 10패턴이다. 이 카테고리의 다른 글이 쓰는 「증상→원인→해결→예방」 4단과 이름이 같은데 카탈로그가 겹치는지 행 단위로 세어 본 결과도 함께 적는다.
에이전트를 통제하는 세 수단을 규범·강제·절차로 갈라 놓고, 비교표의 「강제력」 열이 셋 중 하나에서만 「있음」이 되는 구조를 본다. 훅 5종·차단 규칙 7종·운영 규약 6항목을 전부 펼치고, 훅 표가 요약한 사고 5가지를 차단 규칙 7종에 하나씩 배정해 어느 둘이 남는지 센다. 훅의 차단 사유가 어느 채널로 나가는지에 대해 원 자료의 표 안에서 두 행이 갈리고, 같은 카테고리의 다른 두 글도 서로 다르게 적어 두었다는 사실도 나란히 놓는다.
스킬과 에이전트를 가르는 것이 기능이 아니라 자율성이라는 데서 출발해, 정의서 한 장을 frontmatter 핵심 5·확장 5와 역할·절차·제약 3섹션으로 분해하고, 문서대로 동작하지 않는다고 보고된 항목 세 건까지 버전 표기 없음을 명기한 채로 옮긴다.
에이전트가 시스템에 영향을 주는 통로는 도구뿐이라는 사실에서 출발해 내장 도구 일곱 개를 리스크 등급으로 다시 묶고, 즉시 실행의 부작용을 제어하는 네 가지 지시 패턴 — Plan Mode·SDD·@파일 참조·이미지 입력 — 을 상황별 선택 기준까지 정리한다.
사람이 부르는 커맨드, AI가 감지하는 스킬, 이벤트만 나면 실행되는 훅을 각각의 파일 구조와 차단 계약까지 내려가 보고, 다섯으로 흩어진 설정을 하나의 매니페스트로 묶는 플러그인 배포까지 잇는다.
권한을 선언형 JSON으로 통제하는 구조를 deny → allow → defaultMode 평가 순서와 5단계 설정 계층으로 정리하고, 패턴 문법으로 표현할 수 없는 조건부 규칙을 훅이 어떻게 메우는지 exit code 2 기반 차단까지 짚는다.
MCP의 N×M 문제와 3요소·전송 방식·스코프를 정리하고, 실무 6종의 인증·권한 설계와 마켓플레이스 선별 5기준을 지나 도구 하나가 점유하는 토큰을 예산으로 다루는 판단까지 잇는다.
노코드 도입은 도구 도입이 아니라 병목 리스크를 거버넌스 리스크로 바꾸는 결정이다. 코드와 노코드를 가르는 기준, 앱 5종의 구조 차이, 사내망 종결 구성을 정리한다.
화면에 고를 컨트롤이 없는 제품에서 라우팅이 어디로 가는지 추적하고, chatbot ↔ tools 되돌림 엣지 하나로 도구 반복 호출을 만든 뒤 라우팅 규칙이 코드가 아니라 프롬프트에 있음을 확인한다.
요청이 컨트롤러에서 테이블까지 내려가는 계층을 세우고 그 위에 로그인 상태를 붙이는 구간을 다룬다. 상태를 서버에 두는 방식과 토큰에 담아 보내는 방식이 각각 무엇을 얻고 무엇을 포기하는지, 그리고 접근 토큰과 갱신 토큰으로 나누는 회전 정책이 그 저울을 어떻게 매듭짓는지가 이 편의 주제다.
로컬 LLM은 싸게 하려고 쓰는 것이 아니다. GGUF 형식과 양자화 등급, VRAM 산정 공식, Ollama 운영, 그리고 온프레미스 도입을 판단하는 기준을 정리한다.
CI/CD 일곱 편 중 여섯째다. 서비스를 내리지 않고 버전을 바꾸는 세 전략이 각각 무엇을 대가로 무엇을 얻는지, Nginx와 Health Check가 트래픽 전환을 어디서 가르는지, 그리고 파이프라인을 실패시키는 쪽의 관문이 어디에 붙는지를 다룬다.
MCP가 무엇을 해결하고 커맨드·스킬·훅이 무엇으로 갈리는지, 도구를 늘리면 무엇이 나빠지고 외부 서버를 무엇으로 거르는지를 결론부터 정리한다. 마지막 셋은 「MCP만 있으면」·「훅이면 완전히」·「스킬이면 자동으로」라는 과신을 교정하는 문항이다.
MCP가 낮춘 것은 가능성이 아니라 통합 비용이라는 지적에서 출발해, 벡터스토어를 애플리케이션 밖으로 떼어 내는 재편과 지식베이스 앞에 인증·토큰 등급·가드레일을 겹쳐 놓는 구조를 정리한다.
CI/CD 일곱 편 중 다섯째다. 도구 두 갈래 중 둘째인 Jenkins를 연다. 빌드가 어느 기계에서 도는지를 직접 정해야 하는 모델에서 Controller와 Agent와 Executor가 무엇을 맡는지, 설정을 폼에 채우는 것과 코드로 적는 것이 무엇을 가르는지, Declarative 문법과 사람이 누르는 승인 게이트가 어디에 놓이는지까지 간다.
생성한 코드를 돌려 보고 고치는 순환을 상태 설계부터 세우고, 임의 코드 실행의 위협 일곱 가지를 격리 등급에 매핑한 뒤 사이클이 있는 그래프를 어떻게 끝낼 것인가를 정리한다.
권한을 어디까지 좁히고 무엇을 첫날부터 남기는지, 장애가 나면 어떤 순서로 좁히는지를 결론부터 정리한다. 비용 폭주를 끊는 자리와 도입 성공을 판정하는 5축, 그리고 「퍼미션 모드가 몇 개인가」에 개수로 답하지 않는 이유까지 열일곱 문항.
검증 노드가 실제로 보장하는 범위, 비용이 늘어나는 세 경로와 종료 조건 4겹, 실행 권한을 줄 때의 최소 요건, 그리고 에이전트가 개발조직에 요구하는 것을 정리한다.
전사 통합 인증을 만들기 전에 정해야 하는 것들을 다룬다. 인증과 인가를 왜 끝까지 따로 써야 하는지, 하나의 로그인을 여럿이 인정하게 만드는 방식들이 각각 무엇을 전제하는지, 그리고 그 결정이 범위 기술서·이벤트 목록·유스케이스·액티비티 다이어그램을 거쳐 다음 단계가 받아 쓸 수 있는 형태로 굳는 과정을 따라간다.
CI/CD 일곱 편 중 넷째다. 도구 두 갈래 중 첫째인 GitHub Actions를 연다. 저장소 이벤트가 그대로 트리거가 되는 모델이 무엇을 공짜로 주고 무엇을 대가로 가져가는지, Workflow → Job → Step 세 층과 Runner 두 종이 무엇을 격리하며 그 사이로 값과 파일을 어떻게 넘기는지까지 간다.
루프의 관리 단위를 런타임 계약으로 정의하고 목표·상태·정책·도구·관찰·검증기·종료·격리 여덟 표면으로 분해한 뒤, 언제 루프가 과설계가 되는지를 검증 가능성 기준으로 가른다.
장기 실행을 관리하는 하네스가 실제로 어떤 부품으로 조립되는지 다섯 구성물로 나누고, 세션 시작 비용을 만드는 고정 지식 일곱 종과 컨텍스트 상한의 벤치마크 근거를 토큰 단위로 분해한다.
ConversableAgent 단일 추상과 네 가지 대화 패턴, 종료 조건을 직접 설계해야 하는 이유, 그리고 Code Executor가 붙는 순간 무너지는 신뢰 경계를 정리한다.
소셜 로그인은 비밀번호를 우리가 들고 있지 않으면서 사용자를 식별하는 방법이다. 이 글은 Authorization Code를 한 번 더 거치는 이유, Spring Security가 폼 로그인과 대칭으로 그것을 얹는 구조, 그리고 인증이 끝난 뒤 필요한 채팅 도메인 모델과 페이징·알림 설계를 다룬다.