계정·권한·모델 라우팅과 AI 개발 기업용 AI 에이전트는 챗봇부터 만들면 안 된다

궁금하면 500원·2026년 6월 11일
AIAgentAI개발AI에이전트AI코딩EnterpriseAILLMLLMOpsModelRouterRBACTurborepo개발자블로그권한관리모노레포바이브코딩소프트웨어아키텍처에이전트플랫폼

AI 미생지능

목록 보기
120/123

기업용 AI 에이전트는 챗봇부터 만들면 안 된다

계정·세션·조직·모델 라우팅부터 AI 코딩을 통제하는 Skill 기반 개발까지

AI 에이전트 서비스를 만든다고 하면 가장 먼저 떠오르는 것은 LLM 호출과 Agent Loop입니다. 사용자의 요청을 받고 모델이 판단한 뒤 Tool을 호출하고, 그 결과를 다시 모델에 전달해 다음 행동을 결정하는 구조입니다.
데모 수준이라면 이것만으로도 충분합니다.

하지만 실제 회사에서 사용하는 Enterprise AI Agent를 만들려면 이야기가 달라집니다.
모델을 호출하는 것보다 먼저 해결해야 할 문제가 많습니다.

누가 시스템을 사용할 수 있는지, 로그인 상태는 어떻게 관리할지, 조직마다 어떤 모델을 허용할지, 관리자의 권한 범위는 어디까지인지 정해야 합니다.
세션과 사용자 행동 기록을 어떻게 남길지, 사내 LLM과 외부 API를 어떻게 함께 관리할지도 고려해야 합니다.
여기에 AI가 생성하는 코드를 일정한 구조 안에서 유지할 방법까지 필요합니다.

결국 기업용 AI Agent의 기반은 화려한 AI 기능이 아닙니다.
먼저 필요한 것은 계정, 세션, 권한, 조직, 모델, 감사 로그를 관리하는 Admin Platform입니다.

1. 처음에는 작은 구현체로 시작합니다

처음부터 거대한 플랫폼을 만들 필요는 없습니다.

특히 사내 일부 조직에서 사용할 서비스라면 시작부터 Kubernetes나 복잡한 분산 DB, 이벤트 스트리밍 시스템까지 넣을 이유는 없습니다.
일단 동작하는 최소 구현체를 만들고 개념을 검증하는 편이 낫습니다.

초기 데이터 저장소라면 SQLite 정도로도 충분합니다.

파일 시스템에 사용자나 Agent 데이터를 JSON으로 저장하는 방법도 있습니다.

/data
  /users
    user-001.json
    user-002.json
  /agents
    agent-001.json

처음에는 단순해 보이지만 파일이 늘어나기 시작하면 금방 관리가 어려워집니다.
여러 요청이 동시에 접근할 때는 파일 접근 동시성 문제까지 생깁니다.

작게 시작하더라도 이런 부분을 생각하면 SQLite가 오히려 편합니다.

소규모 / 단일 서버
        ↓
      SQLite

규모 증가
        ↓
   PostgreSQL

트래픽·서비스 증가
        ↓
필요에 따라 Redis, Queue, Worker 등 추가

처음부터 미래에 생길 모든 문제를 해결할 필요는 없습니다.
대신 나중에 확장할 수 있도록 경계를 잡아두는 것이 중요합니다.

2. 기업용 서비스는 계정과 세션부터 잡아야 합니다

가장 먼저 필요한 것은 계정 시스템입니다.

기본 구조는 이 정도로 시작할 수 있습니다.

Account
 ├─ id
 ├─ email
 ├─ passwordHash
 ├─ status
 ├─ metadata
 └─ createdAt

기업 환경에서는 이메일을 사용자 고유 식별자로 사용하는 것도 주의해야 합니다.

회사 이메일은 영구적인 개인 식별자가 아닙니다.
퇴사자의 계정이 사라진 뒤 같은 이메일 주소를 다른 직원이 다시 받을 수도 있습니다.

그래서 실제 시스템에서는 사번이나 내부 사용자 ID처럼 바뀌지 않는 식별자를 따로 두는 편이 안전합니다.

userId       ← 시스템 내부 식별자
employeeId   ← 회사 인사 시스템 식별자
email        ← 로그인 또는 연락 수단

로그인에 성공하면 세션을 만듭니다.

Login
 ↓
Credential 검증
 ↓
Session 생성
 ↓
Session Token 발급
 ↓
API 요청 시 Token 검증

관리자가 특정 세션을 강제로 삭제하면 해당 사용자의 로그인도 즉시 무효화할 수 있어야 합니다.

직원이 퇴사했거나 보안 사고가 발생했을 때 살아 있는 세션을 바로 끊어야 할 수 있기 때문입니다.
기업용 시스템에서는 생각보다 중요한 기능입니다.

3. 세션은 로그인 유지 수단이면서 감사 데이터입니다

기업 시스템에서 세션은 단순히 로그인 상태를 유지하기 위한 값으로 끝나지 않습니다.
세션 자체가 감사 대상이 됩니다.

일반적인 세션 정보에 다음과 같은 데이터를 함께 저장할 수 있습니다.

Session
 ├─ accountId
 ├─ tokenHash
 ├─ createdAt
 ├─ lastAccessAt
 ├─ expiresAt
 ├─ ipAddress
 ├─ userAgent
 ├─ deviceName
 └─ customHeaders

회사마다 필요한 정보도 다릅니다.

자체 보안 프로그램이 HTTP Header에 정보를 넣어 전달하는 회사도 있을 수 있습니다.

X-Employee-Id
X-Device-Id
X-Department
X-Security-Agent

그렇다면 Admin 시스템에서도 이런 값을 수집할 수 있도록 확장 포인트를 열어둬야 합니다.

관리자는 이후 다음과 같은 정보를 확인할 수 있습니다.

김대리
 ├─ 로그인 시각
 ├─ IP
 ├─ 접속 장치
 ├─ 세션 상태
 └─ 마지막 요청 시각

필요하면 특정 세션 하나만 종료하거나 해당 계정의 모든 세션을 제거할 수도 있어야 합니다.

세션과 로그에는 보관 정책이 필요합니다

세션 기록과 접근 로그, Agent 실행 로그는 서비스를 운영할수록 계속 쌓입니다.
무한정 저장할 수는 없습니다.

관리자 설정에서 데이터별 보관 기간을 정할 수 있어야 합니다.

Live Session    : 현재 사용 중인 세션
Session History : 90일 보관
Audit Log       : 정책에 따라 장기 보관
Agent Log       : 30일 보관

오래된 데이터는 주기적으로 정리합니다.

Scheduler
   ↓
Retention Policy 확인
   ↓
만료된 Session / Log 조회
   ↓
Archive 또는 Delete

로그가 계속 쌓여 디스크를 모두 사용하면 서비스 장애로 이어질 수 있습니다.
그래서 로그와 세션 데이터의 Retention Policy는 단순한 부가 기능이라기보다 운영에 필요한 기본 기능에 가깝습니다.

4. Cookie만 보고 인증을 설계하면 안 됩니다

웹 브라우저라면 Cookie를 이용할 수 있습니다.

Cookie: SESSION_ID=...

하지만 기업용 Agent 시스템을 호출하는 Client가 웹 브라우저뿐이라는 보장은 없습니다.

Web
Android
iOS
Desktop
CLI
AI Agent
Batch
Worker

이런 Client가 같은 시스템을 사용할 수 있습니다.

그래서 Header 기반 인증도 함께 지원하는 편이 좋습니다.

Authorization: Bearer <session-token>

기업 정책에 따라 사용자 정의 Header를 사용할 수도 있습니다.

X-Enterprise-Session: <token>

여기서 중요한 것은 Header나 Cookie 이름을 코드에 하드코딩하지 않는 것입니다.

사내 L7 방화벽이나 WAF, Proxy, 보안 솔루션이 특정 Header와 Cookie를 검사하거나 제한할 수 있기 때문입니다.

설정으로 빼두는 편이 대응하기 쉽습니다.

security:
  session:
    header-name: X-Enterprise-Session
    cookie-name: ENTERPRISE_SESSION

겉으로는 사소해 보이지만 기업 환경에서는 이런 설정 하나가 실제 배포 가능 여부를 좌우하기도 합니다.

5. 가입 정책도 하나로 고정하지 않습니다

사내 시스템이라고 가입 요청을 무조건 받아주는 것도 좋은 방법은 아닙니다.

최소한 다음과 같은 정책 정도는 지원할 수 있습니다.

MANUAL
AUTO
RULE_BASED

MANUAL은 관리자가 가입 요청을 직접 확인하는 방식입니다.

가입 신청
 ↓
Pending
 ↓
관리자 승인
 ↓
Active

AUTO는 별도 조건 없이 가입을 허용합니다.

RULE_BASED는 특정 조건을 만족한 경우에만 자동 승인하는 방식입니다.

예를 들어 사내 IP 대역에서 가입한 사용자만 허용할 수 있습니다.

IP ∈ 10.0.0.0/8

사번을 입력받은 뒤 HR DB를 조회하는 방식도 가능합니다.

employeeId 존재
AND
HR DB 조회 성공

회사 이메일 도메인을 확인하는 조건도 만들 수 있습니다.

email domain == company.com

필요하다면 이런 조건을 나중에 간단한 Rule Engine 형태로 확장할 수도 있습니다.

6. Super Admin은 일반 관리자와 분리합니다

최상위 관리자, 즉 Master Admin을 DB의 권한 정보만으로 결정하지 않는 방법도 있습니다.

예를 들어 Docker 실행 환경에서 다음처럼 지정합니다.

MASTER_ADMINS=admin1@example.com,admin2@example.com

애플리케이션이 시작될 때 해당 값을 읽습니다.

Application Start
       ↓
ENV 읽기
       ↓
MASTER_ADMINS 결정
       ↓
System Level 권한 부여

이 구조에서는 DB 관리자 권한을 얻었다고 해서 Master Admin까지 마음대로 변경할 수 없습니다.

Master Admin을 바꾸려면 환경 설정을 변경하고 서비스를 다시 시작해야 합니다.

실제 운영 환경에서는 환경변수에 민감한 값을 평문으로 관리하기보다 Secret Manager나 Vault 같은 별도 비밀 관리 시스템을 사용하는 편이 안전합니다.

개념적으로는 다음처럼 Application DB와 Root of Trust를 분리하는 구조입니다.

Application DB
      ≠
Root of Trust

7. 모델도 중앙에서 관리합니다

계정과 세션을 잡았다면 다음은 Model Registry입니다.

각 Agent가 OpenAI나 로컬 LLM Endpoint를 직접 들고 있게 만들면 나중에 관리하기 어려워집니다. Admin에서 모델 Endpoint를 중앙 관리하는 편이 낫습니다.

예를 들면 다음과 같습니다.

Endpoint
 ├─ LM Studio
 ├─ vLLM
 ├─ Ollama
 ├─ OpenAI
 ├─ Azure OpenAI
 └─ 사내 Enterprise LLM

Endpoint에는 다음과 같은 정보를 둘 수 있습니다.

name
baseUrl
protocol
authentication
headers
enabled

OpenAI Compatible 프로토콜을 지원한다면 다음 API를 사용할 수 있습니다.

GET /v1/models
POST /v1/chat/completions

Endpoint에서 모델 목록을 자동으로 가져올 수도 있고, 해당 기능을 지원하지 않는 서버라면 관리자가 모델을 직접 등록할 수도 있습니다.

같은 모델도 여러 Preset으로 관리합니다

같은 LLM이라고 항상 같은 설정으로 사용할 필요는 없습니다.

코딩 Agent와 일반 Chat Agent는 Temperature부터 다르게 설정할 수 있습니다.

Gemma-Coding
 temperature = 0.4

Gemma-General
 temperature = 1.0

물리적인 모델은 같아도 Inference Preset을 따로 두는 방식입니다.

Preset에는 다음과 같은 설정이 들어갈 수 있습니다.

contextLength
temperature
topP
topK
repeatPenalty
reasoning
modalities

이렇게 하면 Agent가 실제 모델을 직접 고르는 대신 논리적인 모델 설정을 사용할 수 있습니다.

coding-model
general-model
reasoning-model

이 구조를 확장하면 자연스럽게 Model Router로 이어집니다.

8. Docker에서 localhost는 특히 조심해야 합니다

로컬 LLM 서버를 붙이다 보면 자주 만나는 문제가 있습니다.

Agent Admin 서버는 Docker Container에서 실행하고 LM Studio는 Host PC에서 실행한다고 가정해보겠습니다.

Admin 서버에 다음 주소를 넣으면 연결되지 않을 수 있습니다.

http://localhost:1234

Docker Container 내부의 localhost는 Host PC가 아니라 Container 자기 자신이기 때문입니다.

Host PC
 ├─ LM Studio : 1234
 │
 └─ Docker
      └─ Admin Server
           localhost
               ↓
           자기 자신

이 경우 Host에 접근할 수 있는 주소를 사용하거나 Docker Network 설정을 별도로 잡아야 합니다.

LLM 플랫폼을 만들다 보면 정작 AI와 직접 관련 없는 이런 네트워크 문제에 시간을 쓰는 경우도 많습니다.

9. 기업용 Agent에서 중요한 것은 조직별 모델 접근 권한입니다

기업용 환경에서는 사용자가 등록된 모든 모델을 마음대로 선택하게 둘 수 없는 경우가 많습니다.

회사에 다음과 같은 모델이 있다고 가정해보겠습니다.

GPT
Claude
Gemma
Qwen
사내 의료 LLM

인사팀에는 Qwen만 허용하고 개발팀에는 여러 Coding Model을 열어둘 수 있습니다.
의료데이터팀은 Private Medical LLM만 사용하도록 제한할 수도 있습니다.

그래서 Organization과 Allowed Models 사이에 관계가 필요합니다.

Organization
     ↓
Allowed Models

예를 들면 다음과 같습니다.

인사팀
 └─ Qwen

개발팀
 ├─ Claude
 ├─ GPT
 └─ Qwen

의료데이터팀
 └─ Private Medical LLM

이렇게 구성하면 해당 조직에 속한 사용자와 Agent에게 허용된 모델만 노출할 수 있습니다.

조직의 Root가 반드시 하나일 필요는 없습니다

조직 시스템을 만들 때 흔히 다음과 같은 구조만 생각하기 쉽습니다.

회사
 ├─ 개발팀
 └─ 인사팀

최상위 Root가 하나라고 가정하는 것입니다.

하지만 실제 조직은 다를 수 있습니다.

한국본사
 ├─ 개발본부
 └─ 경영지원본부

일본법인
 ├─ 개발부
 └─ 영업부

연구소
 ├─ AI Lab
 └─ Data Lab

그래서 조직 구조를 하나의 Tree로 고정하기보다 Forest 형태로 설계하는 것도 고려할 수 있습니다.

Organization Forest
 ├─ Root A
 │   ├─ Child
 │   └─ Child
 │
 ├─ Root B
 │   └─ Child
 │
 └─ Root C

각 조직에는 다음과 같은 정보가 붙습니다.

Organization
 ├─ metadata
 ├─ members
 ├─ admins
 ├─ allowedModels
 └─ policies

10. 관리자 권한에도 Scope가 필요합니다

누군가에게 관리자 권한을 줬다고 해서 회사 전체를 관리할 수 있게 할 필요는 없습니다.

예를 들어 다음 두 권한을 구분할 수 있습니다.

NODE_ADMIN
TREE_ADMIN

NODE_ADMIN은 해당 조직만 관리합니다.

개발1팀 ← 관리 가능

반면 TREE_ADMIN은 해당 조직과 그 아래에 있는 조직까지 관리합니다.

개발본부
 ├─ 개발1팀
 ├─ 개발2팀
 └─ 플랫폼팀

개발본부의 TREE_ADMIN이라면 하위 조직 전체를 관리할 수 있습니다.

단순히 Role만 확인하는 RBAC에서 끝나는 것이 아니라 Resource Scope를 함께 고려하는 권한 구조가 필요한 셈입니다.

대부분의 요청은 Permission Layer를 거칩니다

Enterprise Middleware에서는 Permission Layer가 중요합니다.

전체 구조는 대략 다음처럼 가져갈 수 있습니다.

Client
   ↓
Authentication
   ↓
Session Validation
   ↓
Permission Layer
   ↓
Application

로그인과 가입처럼 인증 전에 접근해야 하는 Endpoint를 제외하면 대부분의 요청이 이 계층을 통과합니다.

예를 들어 사용자가 특정 모델을 사용하려고 하면 다음 순서로 확인할 수 있습니다.

사용자
 ↓
"이 모델을 호출하고 싶다"
 ↓
소속 조직 확인
 ↓
Allowed Models 확인
 ↓
권한 확인
 ↓
허용 또는 거부

이 Permission Layer가 나중에는 그대로 Agent 서버까지 연결됩니다.

11. Agent는 중앙 정책을 따라 움직이게 만듭니다

앞에서 만든 기능을 연결하면 Agent의 실행 구조가 보이기 시작합니다.

Agent Login
      ↓
Session Token 획득
      ↓
Account 조회
      ↓
Organization 조회
      ↓
Organization Policy 조회
      ↓
Allowed Model 결정
      ↓
Model Router
      ↓
Inference Endpoint
      ↓
LLM

이 구조에서는 Agent가 임의로 특정 모델에 직접 접근하지 않습니다.

계정과 소속 조직, 정책을 확인한 다음 중앙의 Model Router를 거쳐 허용된 모델에 접근합니다.

개인용 AI Agent와 기업용 AI Agent Platform의 차이가 이런 부분에서 생깁니다.

12. AI가 코드를 만든다면 Monorepo의 경계를 더 강하게 잡아야 합니다

구현은 Turborepo 기반 Monorepo로 구성할 수 있습니다.

apps/
  admin/
  agent/
  api/

packages/
  account/
  organization/
  model/
  protocol/
  common/

apps에는 실행 가능한 애플리케이션을 두고, packages에는 도메인과 공통 규격을 둡니다.

Frontend와 Backend가 함께 사용하는 Protocol은 Common 영역에서 관리할 수 있습니다.

packages/organization

 ├─ common
 │   ├─ protocol
 │   └─ types
 │
 ├─ server
 │   └─ domain
 │
 └─ frontend
     └─ model

여기서 중요한 것은 폴더를 보기 좋게 나누는 것이 아닙니다.

AI가 수정할 수 있는 범위를 물리적으로 좁히는 것이 더 중요합니다.

13. AI 코딩에서는 자유보다 경계가 중요합니다

AI에게 단순히 이렇게 요청할 수도 있습니다.

관리자 사이트를 만들어주세요.

처음에는 그럴듯하게 만들어줄 수 있습니다.

문제는 다음 기능부터입니다.

첫 번째 기능에서는 A라는 구조를 쓰고,
두 번째 기능에서는 전혀 다른 구조를 쓰고,
세 번째 기능에서는 또 새로운 패턴을 가져올 수 있습니다.
기능이 쌓일수록 유지보수하기 어려운 코드가 됩니다.

그래서 AI에게 많은 자유를 주기보다 강한 규칙을 먼저 만들어두는 방식이 필요합니다.

예를 들면 이런 Skill을 둘 수 있습니다.

Architecture Skill
React Skill
i18n Skill
Testing Skill
Deployment Skill
Security Skill

AI가 특정 작업을 시작하면 관련 Skill을 먼저 읽고 그 규칙 안에서만 구현하도록 만드는 방식입니다.

Skill은 긴 프롬프트가 아닙니다

Skill에는 단순한 코딩 스타일보다 훨씬 구체적인 규칙이 들어갈 수 있습니다.

폴더 위치
파일 이름
Dependency 규칙
Protocol 위치
Frontend / Backend 분리
Model 작성법
React 작성법
i18n 사용법
Test 작성법
Deploy 방법

예를 들어 패키지 구조부터 고정합니다.

packages/<domain>/common
packages/<domain>/frontend
packages/<domain>/server

각 영역에서 사용할 수 있는 코드도 제한합니다.

common
→ Framework Dependency 금지

frontend
→ React 관련 코드만 허용

server
→ Server Framework 허용

protocol
→ common에만 정의

이 정도까지 규칙을 잡아두면 AI가 코드를 생성하더라도 프로젝트의 기본 구조를 크게 벗어나기 어렵습니다.

14. 폴더를 잘게 나누는 것도 AI Context를 통제하는 방법입니다

전통적인 개발에서도 모듈 경계는 중요하지만 AI Coding에서는 의미가 하나 더 생깁니다.

AI에게 수정 범위를 명확하게 줄 수 있기 때문입니다.

organization/
model/
account/
session/
permission/

이렇게 도메인을 분리해두면

organization 기능만 수정해주세요.

라는 지시가 훨씬 명확해집니다.

Context 범위도 줄어듭니다. AI가 작은 기능을 수정하기 위해 매번 전체 프로젝트를 읽고 구조를 다시 추측할 필요가 없습니다.

이 관점에서 보면 Modular Architecture는 단순한 코드 정리 방법을 넘어 AI Context Engineering의 수단으로도 사용할 수 있습니다.

15. i18n도 나중으로 미루지 않고 규칙으로 만듭니다

다국어 처리를 나중에 붙이기 시작하면 수정 범위가 상당히 커질 수 있습니다.

처음부터 View에 Literal String을 직접 쓰지 못하도록 제한할 수 있습니다.

예를 들어 다음 코드는 피합니다.

<button>저장</button>

대신 Resource를 사용합니다.

<button>{resource.save}</button>

리소스는 언어별로 관리합니다.

resources/
 ├─ en
 ├─ es
 ├─ ar
 ├─ ja
 ├─ zh
 └─ ...

JSON에 Key가 있다는 사실만 믿는 대신 Type으로 사용할 수 있는 Key를 제한할 수도 있습니다.

type AccountResourceKey =
  | "account.title"
  | "account.approve"
  | "account.reject";

이렇게 하면 존재하지 않는 Resource Key를 사용했을 때 컴파일 단계에서 잡아낼 수 있습니다.

16. 규칙은 문서로 끝내지 말고 코드로 검사합니다

AI에게

이렇게 만들어주세요.

라고 지시했다고 해서 항상 그대로 지킨다는 보장은 없습니다.

실제로 규칙을 지켰는지 자동으로 검사해야 합니다.

그래서 Skill과 함께 Validation Script를 두는 방식이 좋습니다.

Skill
 ↓
AI Code Generation
 ↓
Static Check
 ↓
Build
 ↓
Acceptance Test

예를 들어 다음과 같은 항목을 검사할 수 있습니다.

View에 Literal 문자열이 있는가?
금지된 Dependency가 있는가?
Protocol 위치가 올바른가?
Domain Boundary를 넘었는가?
Naming Convention을 지켰는가?

AI 개발 규칙을 검사하는 별도의 Linter를 두는 셈입니다.

여기서 중요한 차이가 생깁니다.

프롬프트는 요청이고, 자동 검사는 강제력입니다.

17. AI 시대의 브라우저 테스트

기존에는 Playwright나 Headless Browser를 이용해 테스트 시나리오를 직접 구성하는 방식이 일반적이었습니다.

이제는 자체 브라우저 기능을 가진 Coding Agent도 나오고 있습니다.

AI에게 다음과 같은 작업을 맡길 수 있습니다.

사이트 실행
 ↓
로그인
 ↓
조직 생성
 ↓
모델 할당
 ↓
화면 확인
 ↓
스크린샷
 ↓
오류 분석

결과는 Screenshot과 Report 형태로 남깁니다.

tests/
  2026-08-12/
    login/
    account/
    organization/
    model/

실행 기록에는 다음과 같은 정보를 함께 저장할 수 있습니다.

SUCCESS / FAILURE
Screenshot
Console Error
Request Error
실행 시각
변경 파일

이런 방식이면 개발자가 모든 화면을 직접 클릭하지 않아도 AI가 실행한 테스트 결과를 다시 확인할 수 있습니다.

그렇다고 Unit Test가 사라지는 것은 아닙니다

AI가 브라우저까지 조작한다고 해서 Unit Test와 Integration Test가 필요 없어지는 것은 아닙니다.

각 테스트가 확인하는 영역이 다르기 때문입니다.

Unit Test
→ 작은 로직의 정확성

Integration Test
→ DB·외부 시스템 연동

Contract Test
→ API 규격

Acceptance / E2E
→ 실제 사용자 시나리오

AI를 활용하면 특히 Acceptance Test의 작성과 실행 비용을 줄이기 쉬워집니다.

현실적인 방향은

Unit Test 제거

가 아니라 다음에 가깝습니다.

핵심 로직 Unit Test
+
Contract / Integration Test
+
AI 기반 Acceptance Test

AI가 코드를 빠르게 생성하는 만큼 결과를 확인할 자동 검증 장치도 함께 갖춰두는 편이 안전합니다.

18. Deployment도 정해진 경로로만 수행합니다

배포 역시 AI가 그때그때 명령을 만들어 실행하게 두지 않습니다.

프로젝트에서 공식 배포 명령을 정의할 수 있습니다.

./scripts/deploy.sh admin

AI에게

Admin을 배포해주세요.

라고 요청해도 내부적으로는 이 Script를 사용하도록 강제합니다.

Developer
     ↓
deploy script
     ↑
AI Agent

사람이 실행하든 AI가 실행하든 같은 배포 경로를 타게 됩니다.

이런 규칙이 쌓이면 프로젝트의 재현성도 높아집니다.

19. AI가 만든 코드가 일정하게 나오게 하려면

AI가 만들어낸 결과가 사람과 함께 관리할 만한 수준으로 일정하게 나오는 이유는 단순히 모델의 코딩 능력이 좋아서만은 아닙니다.

오히려 AI가 마음대로 움직일 수 없게 제한했기 때문입니다.

Architecture
Naming
Folder
Dependency
Test
Deploy
i18n
Security

이런 요소에 규칙을 두면 AI가 작업할 때마다 새로운 방법을 만들어낼 여지가 줄어듭니다.

결과적으로 여러 번 기능을 추가해도 비슷한 구조를 유지하게 됩니다.

AI Coding
       ↓
Unlimited Freedom

AI Coding
       ↓
Constrained Generation
       ↓
Validation
       ↓
Repeatable Architecture

이것이 Skill 기반 AI 개발에서 중요한 부분입니다.

20. 기업용 Agent Admin에서 먼저 필요한 기능

여기까지 구현했어도 정작 AI Agent 자체는 거의 만들지 않은 셈입니다.

그래도 운영에 필요한 기반은 상당 부분 준비됩니다.

Account

가입
승인
비활성화
관리자 지정

Session

발급
만료
조회
강제 종료
감사 기록

Organization

조직 Tree
Member
Admin Scope

Model

Endpoint
Model
Preset
Organization별 허용 Model

Permission

Account
Organization
Role
Resource Scope

이 정도가 기업용 Agent Platform에서 먼저 필요한 최소 Admin Plane이라고 볼 수 있습니다.

21. 이제 그 위에 실제 Agent 기능을 올립니다

기반을 만들고 나면 그다음부터 Agent 기능을 붙입니다.

Admin Platform
     │
     ├─ Account
     ├─ Session
     ├─ Organization
     ├─ Permission
     └─ Model Router
             │
             ▼
        Agent Server
             │
             ▼
        Agent Runtime

Agent Runtime에서는 기본적인 Agent Loop가 실행됩니다.

User Request
     ↓
Context 구성
     ↓
Model 호출
     ↓
Reasoning
     ↓
Tool 선택
     ↓
Tool 실행
     ↓
Observation
     ↓
다음 판단

이후 필요에 따라 다음 기능을 붙일 수 있습니다.

Guardrail
Prompt Rewriter
Model Router
Tool Permission
RAG
Code RAG
Agent Memory
Audit
Evaluation
Observability
Cost Control

중요한 것은 이 기능들이 따로 동작하는 것이 아니라 앞에서 만든 Account, Organization, Permission 구조 위에서 작동한다는 점입니다.

22. PDF 관리 도구도 같은 방식으로 접근할 수 있습니다

같은 개발 방식을 대량의 PDF 문서를 관리하는 서비스에도 적용할 수 있습니다.

스캔한 PDF가 수백 권까지 늘어나면 단순한 파일 시스템만으로 관리하기 쉽지 않습니다.

다음과 같은 기능을 가진 PDF Library를 만들 수 있습니다.

PDF Library
 ├─ Tags
 ├─ Bookmark
 ├─ Metadata
 ├─ Search
 └─ Viewer

PDF Viewer의 렌더링 성능을 높이기 위해 WebAssembly 기반 PDF 처리와 WebGPU 기반 렌더링을 조합하는 접근도 가능합니다.

페이지를 열었을 때 낮은 해상도로 먼저 빠르게 렌더링하고, 이후 고해상도 결과로 교체하는 방식입니다.

Page Request
     ↓
Low Resolution Render
     ↓
즉시 표시
     ↓
High Resolution Render
     ↓
화면 교체

전체 고해상도 렌더링이 끝날 때까지 기다리지 않아도 되기 때문에 체감 속도를 높일 수 있습니다.

여기에 태그와 북마크를 추가하면 개인 문서가 수백~수천 개로 늘어나도 정리하기 쉬워집니다.

이 프로젝트 역시 특정 기술을 쓰는 것 자체가 목적은 아닙니다.
실제로 불편한 부분을 해결하기 위해 필요한 기술을 조합하는 것이 핵심입니다.

23. AI Coding 시대에도 개발 지식이 필요한 이유

AI에게 대부분의 구현을 맡길 수 있게 되면서 개발자의 역할이 사라지는 것처럼 보일 수도 있습니다.

하지만 실제 프로젝트에서는 AI가 내놓은 결과를 판단할 수 있는 개발 지식이 여전히 필요합니다.

AI에게

알아서 잘 만들어주세요.

라고 요청했을 때 정말 잘 만든 것인지 판단해야 하기 때문입니다.

예를 들어 다음과 같은 문제를 찾아내려면 기본적인 엔지니어링 지식이 필요합니다.

Docker localhost 문제
Session 설계 문제
잘못된 권한 구조
Organization Root 가정
DB와 Root 권한 결합
Model 접근 제어 부재
Dependency Boundary 붕괴
로그 무한 증가

AI가 코드를 만드는 속도는 확실히 빨라졌습니다.

하지만 어떤 구조로 만들어야 하는지 결정하는 책임까지 없어진 것은 아닙니다.

24. 결국 중요한 것은 Prompt보다 Engineering Harness입니다

AI Coding 초창기에는 좋은 Prompt를 작성하는 방법이 많이 이야기됐습니다.

프로젝트가 커지면 Prompt 하나만으로는 부족합니다.

더 중요한 것은 AI가 작업하는 환경 자체를 설계하는 것입니다.

AI Agent
   │
   ├─ Skills
   ├─ Architecture Rules
   ├─ Linter
   ├─ Test
   ├─ Browser
   ├─ Script
   ├─ Git
   └─ CI/CD

AI에게 그때마다 좋은 코드를 작성해달라고 부탁하는 것이 아닙니다.

좋은 코드가 아닌 결과는 나오기 어렵도록 환경 자체를 구성하는 것입니다.

이런 구조를 AI 개발의 Harness라고 볼 수 있습니다.

마무리

기업용 AI Agent를 만든다고 처음부터 Agent Loop와 RAG부터 구현할 필요는 없습니다.

오히려 먼저 필요한 것은 평범해 보이는 기능들입니다.

Account
Session
Organization
Permission
Model Registry
Model Router
Audit

이 기반이 있어야 Agent를 회사의 조직과 보안 정책에 맞게 통제할 수 있습니다.

AI를 활용해 이 시스템을 개발할 때도 마찬가지입니다.
AI에게 마음대로 코드를 만들게 두기보다 다음과 같은 규칙을 먼저 잡아두는 편이 낫습니다.

Architecture
Skill
Boundary
Validation
Test
Deployment Rule

AI 시대의 개발을 단순히

AI가 대신 코드를 작성합니다.

정도로 보는 것은 부족합니다.

조금 더 정확하게 표현하면 다음에 가깝습니다.

사람이 시스템의 구조와 규칙을 설계하고, AI가 그 경계 안에서 구현하도록 만듭니다.

Agent Server와 Agent Client까지 연결되면 앞에서 만든 Account, Session, Organization, Permission, Model Router가 실제 Agent 실행 정책으로 이어집니다.

User
 ↓
Session
 ↓
Organization
 ↓
Permission
 ↓
Model Router
 ↓
Agent Runtime
 ↓
Tool / RAG / LLM

여기까지 연결돼야 단순한 AI 챗봇이 아니라 기업에서 운영할 수 있는 AI Agent Platform의 형태가 나옵니다.

AI가 코드 대부분을 작성하는 시대가 오더라도 개발자의 역할이 그대로 사라지는 것은 아닙니다. 직접 코드를 타이핑하는 비중은 줄어들 수 있지만, 대신 AI가 움직일 범위를 정하고 아키텍처의 경계를 만들고 결과를 검증하는 일이 더 중요해집니다.

AI 시대의 개발자는 코드를 가장 많이 작성하는 사람보다 AI가 엉뚱한 방향으로 코드를 만들지 못하도록 시스템을 설계하고 통제하는 사람에 가까워지고 있습니다.

학습하고느낀점

예전에는 AI 코딩이라고 하면 얼마나 빨리 코드를 만들어주는지가 먼저 눈에 들어왔는데, 이번 내용을 보면서 오히려 반대라는 생각이 들었습니다.

AI가 코드를 많이 작성할수록 아키텍처, 경계, 테스트 같은
개발자의 기본기가 더 중요해질 수 있습니다.

AI가 개발자를 필요 없게 만드는 것이 아니라,
개발자가 직접 코드를 작성하는 역할에서 AI가 제대로 일할 수 있는 환경을 설계하고
결과를 검증하는 역할로 바뀌고 있다는 느낌을 받았습니다.

profile
궁금하면 500원
레거시를 이해하면서도 새로운 기술을 현실적으로 적용할 수 있는 백엔드 개발자가 되는 것이 목표입니다.
이전 포스트

1비트 LLM이 아이폰에서 돌아가는 이유

0개의 댓글