AI 에이전트 웹서비스에 코딩 런타임을 붙이는 방법#

2026-04-19

개인적으로 AI 에이전트 기반의 웹서비스를 구상하거나 개발할 때, 꽤 빠르게 부딪히는 질문이 있습니다.

“이 서비스의 에이전트가 정말 일을 하게 만들려면, 코딩 능력을 어디서 가져와야 할까?”

아이디어를 처음 잡을 때는 흔히 이렇게 생각하기 쉽습니다. 모델 API를 붙이고, 파일 편집 기능을 만들고, 셸 명령을 실행하고, 테스트를 돌리고, 결과를 정리하면 되지 않을까. 하지만 조금만 깊게 들어가 보면, 그 안에는 생각보다 많은 것이 들어 있습니다.

• 저장소 checkout
• 파일 읽기 / 수정
• 셸 명령 실행
• 테스트와 빌드
• git diff와 PR 준비
• 시크릿 주입
• 네트워크 제한
• 시간 제한과 비용 제한
• 작업 실패 후 재시도와 로그 수집

즉 “코딩을 잘하는 에이전트"는 단순히 똑똑한 모델 하나로 생기지 않습니다. 실행 환경, 도구, 승인 구조, 격리, 관측 가능성이 함께 있어야 비로소 쓸 만해집니다.

이 지점에서 필자는 한 가지 결론에 도달했습니다. 코딩 능력 자체를 모두 바닥부터 구현하려는 접근은 1인 개발자에게 대체로 비합리적입니다. 오히려 이미 나와 있는 코딩 에이전트 런타임과 프레임워크를 어떻게 제품 문맥에 맞게 끌어올지 고민하는 쪽이 훨씬 현실적입니다.

먼저 용어부터 정리해야 합니다#

이 분야를 이야기할 때 자주 헷갈리는 이유는, 서로 다른 층의 도구가 모두 “에이전트"라는 말로 묶여 버리기 때문입니다.

필자는 아래처럼 나누는 편이 이해에 도움이 된다고 생각합니다.

처음에는 “AI 에이전트 기반 프레임워크"라는 표현을 쓰고 싶었지만, 공개 글에서는 코딩 에이전트 런타임 또는 개발용 에이전트 실행 엔진이라는 표현이 더 정확하다고 느꼈습니다.

왜냐하면 이 글의 핵심 질문은 “에이전트 프레임워크를 붙일까?“가 아니라, “내 서비스 안에서 개발 작업을 실제로 수행할 엔진을 무엇으로 둘까?” 이기 때문입니다.

개인용 코딩 도구를 웹서비스에 그대로 옮기면 어색해질 수 있습니다#

여기서 고민이 하나 생깁니다.

Claude Code, Codex, Gemini CLI, Cline 같은 도구는 대체로 한 명의 개발자가 자신의 작업 환경에서 쓰는 경험에 맞춰져 있습니다. 그래서 이들을 웹서비스에 바로 넣으려 하면 어딘가 어색해질 수 있습니다.

이유는 간단합니다.

• 개인용 도구는 “내 저장소"와 “내 터미널"이 전제입니다.
• 웹서비스는 “여러 사용자"와 “격리된 실행 환경"이 전제입니다.
• 개인용 도구는 실패해도 내 로컬에서 끝나지만, 웹서비스는 과금, 권한, 감사 로그, 리소스 격리가 함께 따라옵니다.

그래서 필자는 이 계열 도구를 제품의 정체성 그 자체로 드러내기보다, 서비스 내부의 실행 엔진으로 다루는 편이 맞다고 생각합니다.

조금 더 쉽게 말하면 이렇습니다.

• 어색한 방식: 사용자가 웹에서 사실상 호스팅된 IDE를 직접 운영하게 만든다
• 자연스러운 방식: 사용자는 목표와 승인만 관리하고, 뒤에서는 코딩 런타임이 격리된 작업 공간에서 일을 수행한다

이 차이는 꽤 큽니다. 전자는 IDE와 경쟁하게 되고, 후자는 에이전트 팀 운영 서비스가 됩니다.

제품이 가져가야 할 것은 코딩 능력보다 운영 구조입니다#

필자는 AI 에이전트 기반 웹서비스의 해자가 어디에 있는지 다시 봐야 한다고 생각합니다.

대부분의 경우 사용자는 “가장 강한 모델” 하나만 원하는 것이 아닙니다. 실제로는 아래와 같은 것을 함께 원합니다.

• 일을 누구에게 맡길지
• 어떤 역할로 팀을 구성할지
• 어떤 작업은 자동 승인하고, 어떤 작업은 사람 승인을 거칠지
• 예산 한도를 어떻게 둘지
• 작업 이력을 어떻게 쌓을지
• 결과물을 어떻게 자산으로 남길지

즉 제품이 가져가야 할 핵심은 코딩 능력 자체보다 조직화와 운영 구조에 가깝습니다.

그래서 외부 코딩 런타임을 쓰는 전략은 단순한 타협이 아닙니다. 오히려 제품이 진짜로 가져가야 할 부분에 집중하기 위한 선택일 수 있습니다.

SDK를 붙이는가, 런타임을 붙이는가#

이 질문은 처음 보면 단순해 보이지만, 실제로는 그렇지 않습니다.

필자의 현재 결론은 이렇습니다.

정답은 둘 중 하나가 아니라, 런타임 중심 + SDK 제어입니다.

이 말을 풀어 보면:

• 실제 작업은 런타임이 수행합니다.
• SDK는 그 런타임을 프로그래밍적으로 제어하는 수단입니다.

예를 들어 코딩 에이전트가 실제로 해야 하는 일은 결국 작업 디렉토리 안에서 일어납니다. 저장소를 clone하고, 파일을 읽고, 수정하고, 테스트를 돌리고, diff를 만들고, 로그를 남깁니다. 이 모든 것은 어떤 형태로든 workspace runtime이 필요합니다.

그래서 제품 아키텍처 관점에서는 보통 이렇게 보는 편이 정확합니다.

• 통합 단위: SDK가 아니라 workspace runtime
• 호출 방식: SDK, CLI, app-server, headless mode 중 적합한 것을 선택

제품마다 차이도 있습니다.

• Codex는 SDK와 app-server 문맥이 비교적 명확합니다.
• Claude Code는 SDK가 있어도 여전히 런타임 성격이 강합니다.
• Gemini CLI는 공식 SDK가 있어서 서비스 통합 관점에서 눈여겨볼 만합니다.
• OpenHands와 OpenCode는 아예 서비스형 구조에 더 가까운 면이 있습니다.

추천 아키텍처는 Control Plane / Execution Plane 분리입니다#

AI 에이전트 기반 웹서비스에서 코딩 런타임을 붙일 때, 필자는 두 평면으로 나누는 그림이 가장 자연스럽다고 봅니다.

1. Control Plane#

이 층은 제품의 중심 백엔드입니다.

• 작업 생성
• 승인 / 반려
• 상태 관리
• 비용 추적
• 권한 관리
• 로그 조회
• 히스토리 저장

즉 “무엇을, 누구에게, 어떤 정책으로 맡길지” 를 결정합니다.

2. Execution Plane#

이 층은 실제로 작업이 일어나는 곳입니다.

• 저장소 checkout
• 코딩 에이전트 실행
• 테스트 / 빌드
• diff 생성
• 산출물 업로드

즉 “정해진 일을 실제로 수행하는 실행 환경” 입니다.

이 구조가 중요한 이유는, 제품 백엔드와 작업 런타임의 책임이 자연스럽게 분리되기 때문입니다. 그리고 이 분리가 되어 있어야 나중에 특정 런타임을 교체하거나, ECS에서 EKS로 옮기거나, 새 벤더를 추가해도 제품이 흔들리지 않습니다.

실행 단위는 사용자별 하나보다 작업별 분리가 더 낫습니다#

처음에는 이렇게 생각할 수 있습니다.

“사용자마다 하나의 런타임을 띄우면 되는 것 아닌가?”

하지만 코딩 에이전트에서는 보통 작업별 분리가 더 안전합니다.

• 작업 1개 = runner 1개
• 필요하면 같은 세션 동안 잠깐 재사용
• 작업이 끝나면 정리

이 방식이 좋은 이유는 다음과 같습니다.

• 사용자 간 파일 충돌을 피할 수 있습니다.
• 환경변수와 시크릿을 분리하기 쉽습니다.
• 비용과 리소스를 추적하기 쉽습니다.
• 한 작업이 폭주해도 다른 작업에 영향이 덜 갑니다.

즉 Execution Plane은 공유 인프라이고, 그 위에서 작업별로 분리된 runner를 띄우는 구조가 가장 현실적입니다.

인프라는 처음부터 거창할 필요가 없습니다#

이 지점에서 보통 다음 질문이 따라옵니다.

“그럼 이런 runner를 어디에서 돌릴 것인가? ECS? EKS? EC2?”

필자는 초기 단계에서는 ECS/Fargate가 가장 현실적이라고 봅니다.

이유는 간단합니다.

• 작업마다 독립 task를 띄우기 쉽습니다.
• 격리가 비교적 명확합니다.
• 운영 복잡도가 낮습니다.
• 1인 개발자에게 Kubernetes는 종종 과투자입니다.

반면 EKS는 언제 유리해질까요?

• 동시 workspace가 많아질 때
• 장시간 유지되는 세션이 늘어날 때
• 워크스페이스 유형이 다양해질 때
• warm pool이나 정교한 스케줄링이 필요해질 때

즉 초기에는 ECS/Fargate, 성장 후에는 EKS 검토가 가장 균형이 좋다고 생각합니다.

이 전환이 매우 위험하냐고 묻는다면, 필자의 답은 아니오입니다. 다만 전제 조건이 있습니다. 상태와 로그와 산출물을 컨테이너 밖에 두고, Control Plane이 실행 환경 세부 구현을 많이 모르게 설계해야 합니다.

쉽게 말해, 제품은 launch_workspace()만 알고, 뒤에서 그것이 Fargate task인지 Kubernetes pod인지 바꿀 수 있어야 합니다.

어떤 후보를 먼저 볼 것인가#

이번 주제를 조사하면서 필자가 흥미롭게 본 후보들을 간단히 정리해 보면 아래와 같습니다.

먼저 진지하게 볼 후보#

참고용으로 볼 후보#

문제 영역이 조금 다른 후보#

여기서 중요한 것은 “누가 더 유명한가"보다 내 서비스 안에 어떤 경계로 들어올 수 있는가 입니다. 필자가 보기에 Codex, Gemini CLI, OpenHands, OpenCode, Cline은 이 질문에 대한 답이 비교적 분명한 편입니다.

이 전략이 특히 의미 있었던 이유#

이번 고민을 정리하면서 필자에게 가장 의미 있었던 포인트는 세 가지였습니다.

1. 제품은 IDE가 아니라 운영 계층이 될 수 있습니다#

처음에는 “웹서비스 안에서 각 사용자가 자기 개발 환경을 갖게 해주는 것"을 상상하게 됩니다. 그런데 조금 더 생각해 보면, 꼭 사용자가 환경을 직접 관리할 필요는 없습니다.

오히려 사용자는:

• 목표를 말하고
• 승인 정책을 정하고
• 비용 한도를 보고
• 팀 구성을 바꾸고
• 결과를 검토하는 쪽

에 집중하는 편이 더 자연스럽습니다.

즉 제품은 호스팅된 IDE가 아니라 개발 에이전트 팀을 운영하는 계층이 될 수 있습니다.

2. 코딩 능력은 차별점의 전부가 아닙니다#

좋은 코딩 런타임은 점점 더 많아질 가능성이 큽니다. 그렇다면 제품이 붙잡아야 할 것은 “가장 강한 한 가지 런타임” 자체가 아니라, 그 런타임들을 어떤 정책과 구조로 묶을 것인가 입니다.

이 관점에서 보면 제품이 가져가야 할 본질은 아래와 같습니다.

• 어떤 작업은 자동 승인할지
• 어떤 작업은 사람 검토를 거칠지
• 어떤 에이전트가 어떤 역할을 맡을지
• 어떤 결과를 기록하고 재사용할지

이것은 단순한 모델 선택 문제보다 훨씬 제품적입니다.

3. 첫 유즈케이스는 좁아야 합니다#

이런 시스템은 금방 큰 비전을 품게 됩니다. 하지만 실제로는 첫 유즈케이스를 좁게 잡는 것이 중요합니다.

예를 들어 아래 정도면 충분히 강한 출발점이 될 수 있습니다.

1. GitHub 저장소 연결
2. 이슈 하나 선택
3. 격리된 runner에서 수정
4. 테스트 결과와 diff 제시
5. 사용자 승인
6. PR 생성

이 정도만 잘 작동해도, 그 위에 리뷰어 에이전트, QA 에이전트, 비용 정책, 장기 메모리 같은 것을 차례로 올릴 수 있습니다.

결국 제품이 소유해야 할 것은 무엇인가#

필자는 이 질문의 최종 답이 꽤 단순하다고 느꼈습니다.

AI 에이전트 기반 웹서비스가 직접 소유해야 할 것은:

• 사용자 경험
• 승인 구조
• 팀 운영 방식
• 작업 기록
• 비용 정책
• 보안과 격리

이고,

직접 처음부터 만들 필요가 없는 것은:

• 코딩 에이전트 루프 전부
• 파일 편집과 셸 실행 하네스 전부
• 모든 런타임 제어 기능 전부

입니다.

즉 코딩 런타임은 백엔드 실행 엔진, 제품은 운영 계층이라는 구도가 가장 현실적으로 느껴집니다.

마치며#

AI 에이전트 기반 웹서비스를 만들 때 가장 위험한 유혹 중 하나는, “핵심이 중요하니 전부 직접 만들어야 한다"는 생각입니다. 하지만 코딩 에이전트 영역은 이미 빠르게 발전하고 있고, 런타임과 SDK와 서비스형 제품이 계속 나오고 있습니다.

이 상황에서 더 중요한 질문은 이것일지 모릅니다.

“가장 좋은 코딩 에이전트를 내가 직접 만들 수 있는가?”

보다,

“이미 존재하는 코딩 에이전트 런타임을 내 서비스의 문맥 안에서 가장 잘 조직할 수 있는가?”

필자는 지금 시점에서는 두 번째 질문이 훨씬 더 생산적이라고 생각합니다.

그리고 그 질문에 대한 첫 답은 아마도 이것일 것입니다.

좋은 제품은 코딩 런타임을 전면에 내세우기보다, 그 위에서 사람과 에이전트와 승인 구조를 잘 엮어 주는 쪽에 더 가까울 것입니다.