24시간 AI Coding Agent 구축 방법

한 줄 가이드: 2026년 밤새 issue를 받아 코드를 고치고 PR을 여는 AI Coding Agent를 구축하려는 팀이 많지만, 첫 단계에서 자주 실수합니다 — Cursor만 설치하거나 API만 사면 된다고 생각하는 것입니다. 오래 돌아가는 autonomous coding agent 뒤에는 상시 실행면, 작업 스케줄링, 객관적 검증이 필요합니다. 아래에서는 아키텍처 계층, 배포 토폴로지, 최소 실행 스택, 프로덕션 강화 네 축으로 바로 따라 할 수 있는 완전 배포 가이드를 정리합니다.

1. 24시간 AI Coding Agent란 무엇인가?

IDE에 깔린 Copilot, Cursor Tab과 달리 24시간 AI Coding Agent가 풀려는 문제는 다릅니다: 당신이 자리에 없을 때, 누가 실제 환경에서 저장소를 수정하고 명령을 실행하며 검증 신호를 받을 수 있는가?

제대로 돌아가는 배포에는 보통 네 가지 능력이 있으며, 하나라도 빠지면 「24시간 autonomous coding agent」라 부르기 어렵습니다:

• 상시 실행 환경(L0) — 끊김 없는 전원·네트워크의 macOS 또는 Linux 노드에서 git, npm, xcodebuild 실행.
• 코딩 Agent 프로세스(L3/L5) — 페어 계층(Claude Code) 또는 자율 계층(OpenHands)이 컨텍스트를 읽고 Diff 작성.
• 작업 진입점과 큐 — GitHub issue label, Webhook, cron, Slack 명령 등으로 「할 일」을 Agent에 전달.
• 객관적 검증(L1) — GitHub Runner 또는 로컬 테스트 스크립트가 조직이 신뢰할 Fact를 생성 — Agent의 「다 했어요」만으로는 부족.

한 줄로: 실행 노드는 기초 공사와 전기·수도, Agent는 일하는 작업자, Runner는 품질 검사원입니다. 많은 팀이 모델 API만 사고 MacBook에서 스크립트를 돌린 뒤 24/7 Agent를 기대하다 실패합니다 — 뚜껑 닫기, 절전, 메모리 경합, 출구 IP 변경이 새벽 3시에 작업을 끊습니다.

2. 한 장으로 보기: 작업 진입부터 머지 가능한 PR까지

아래 인과 체인은 전형적인 autonomous coding agent 파이프라인을 요약합니다. 왼쪽은 주 체인, 오른쪽은 「성공」과 「실패」 대조입니다.

3. 5계층 컴포넌트 분해

AI Agent 인프라 계층과 같이, 24/7 Agent 배포는 한 번에 다 살 필요는 없지만 각 계층이 빠지면 어떤 일이 생기는지 알아야 합니다:

Claude Code는 Diff를, Runner는 Fact를, OpenHands는 Workflow를 만든다 — AI Coding Agent 배포 시 역할을 기억하는 구호입니다. 밤에 lint issue만 자동 처리하려면 L0 + L5 + L1이면 충분한 경우가 많고, 낮에 아키텍처 작업도 페어로 하려면 L3를 추가하되 동일 머신 병행 시 메모리 스케줄링에 주의하세요(병렬 메모리 스케줄링 참고).

4. 배포 토폴로지: 로컬 Mac mini vs Cloud Mac

24시간 AI Coding Agent 실행 노드는 물리 머신, VM, 클라우드 임대 인스턴스 모두 가능합니다. 선택 기준은 브랜드가 아니라 가동 SLA입니다:

순수 백엔드 저장소(Go / Node / Python)는 이론상 Linux VPS에서도 AI Coding Agent를 돌릴 수 있지만, workflow에 xcodebuild, swift test, Apple 서명이 들어가면 실행면은 macOS로 돌아와야 합니다. 2026 배포 가이드가 Mac을 기본으로 쓰는 이유는 감성이 아니라 ABI 경계 때문입니다.

5. 최소 실행 스택(MVP): 밤 작업 한 건 먼저 통과시키기

첫날부터 Kubernetes + 벡터 DB를 깔 필요는 없습니다. 「issue → PR → CI 통과」를 가장 빨리 본 조합은 다음과 같습니다:

• 노드: M4 Mac mini 16GB 또는 동급 Cloud Mac; OpenHands + Runner 겹치면 24GB 권장.
• Agent: OpenHands(자율) 또는 Claude Code + 간단한 shell 래퍼(반자동).
• 모델: Claude / GPT API; 로컬 Ollama는 선택, 24/7 필수 아님.
• 진입: issue에 agent label → GitHub Webhook 트리거.
• 검증: 동일 머신 self-hosted Runner, runs-on: [self-hosted, macOS].
• 컨텍스트: GitHub MCP 읽기 전용 + 저장소 AGENTS.md에 레드라인 명시.

6. 7단계 배포 체크리스트

아래 순서대로 진행하며 각 단계를 개별 검수하세요 — 「다 깔았는데 Runner 미등록」을 막는 핵심 실무 파트입니다.

Step 1 — L0 노드 준비. SSH, 시계 동기화, 디스크 ≥ 256GB 확인(Xcode + 다중 workspace는 용량을 많이 씁니다). Cloud Mac 사용자는 인스턴스 초기화와 고정 IP를 먼저 확인하세요.

Step 2 — 제한된 git 신원 생성. Agent 전용 GitHub App 또는 deploy key: feature 브랜치만 쓰기, 기본적으로 main 쓰기 금지. 프로덕션 비밀키, npm token은 Agent 환경 변수에 넣지 않습니다.

Step 3 — 코딩 Agent 설치. OpenHands 예시(Docker 또는 네이티브는 공식 문서 따름):

# L0 노드에서 OpenHands 클론 후 공식 문서대로 LLM API Key 설정
git clone https://github.com/OpenHands/OpenHands.git
cd OpenHands
# .env 설정: MODEL, GITHUB_TOKEN(issue 읽기 전용), WORKSPACE_BASE
make run

Step 4 — MCP 연결(선택이지만 권장). 대형 저장소는 CodeGraph MCP로 의존 관계를 「볼 수 있게」 한 뒤 수정하세요.

Step 5 — GitHub Runner 등록. Agent와 동일 머신에 등록, label 예: macos-agent. workflow 조각:

# .github/workflows/agent-verify.yml
name: Agent PR Verify
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  verify:
    runs-on: [self-hosted, macOS, agent]
    steps:
      - uses: actions/checkout@v4
      - run: swift test   # 또는 npm test / go test

Step 6 — 작업 진입점 설정. GitHub Webhook을 서버의 경량 HTTP 서비스로 연결하거나 OpenHands 내장 연동 사용; label agent-ready로 필터해 모든 comment가 트리거되지 않게 합니다.

Step 7 — 모니터링과 차단. 작업별 token 사용량, 소요 시간, 변경 파일 수 기록; 단일 작업 타임아웃(예: 90분) 시 자동 kill; 동시성은 1로 시작해 안정 후 2로 확대.

7. 프로덕션 강화: Agent가 새벽에 main을 망치지 않게

Autonomous coding agent의 최대 리스크는 「모델이 멍청해서」가 아니라 권한 과다 + 무인 검토 부재입니다. 출시 전 최소한 다음을 적용하세요:

8. 비용과 스펙 추정

24시간 AI Coding Agent 비용은 보통 세 덩어리로 나뉩니다:

• 연산 노드: Mac mini 일회성 + 전기; Cloud Mac은 일/주 구독(임대 vs 구매 비교).
• 모델 API: autonomous agent는 다중 루프로 페어 코딩 대비 5–20배 token; 작업별 예산 상한 권장.
• 운영 인력: 초기에는 주당 몇 시간 로그·prompt·stuck 작업 정리; 「설치만 하면 제로 유지보수」는 가정하지 마세요.

스펙 경험치: OpenHands만 + 중간 규모 저장소면 16GB 가능하나 Swap 위험; Agent, Runner, 선택 Ollama를 동일 머신에 두면 24GB가 더 안심(16GB vs 24GB 참고).

9. 흔한 실패 사례

• 페어 도구를 autonomous agent로 착각 — Claude Code 세션은 끝나면 멈춤, 별도 스케줄 래퍼 없으면 24/7 아님.
• Fact 계층 부재 — Agent만 「테스트 통과」 주장, Runner는 한 번도 안 돌림(self-hosted Runner가 가치 있는 이유).
• 과도한 동시성 — autonomous 작업 두 개가 16GB에서 동시 실행 → Swap 지옥.
• 컨텍스트 맨몸 — 백만 줄 monorepo에 CodeGraph 없이 수정 = 맹목 리팩터링.
• 타임존·알림 무시 — 실패 알림 없이 아침에 반쯤 된 PR만 발견.

10. 자주 묻는 질문

Q: Cursor Background Agent도 24시간 AI Coding Agent인가?
A: Cursor는 호스팅 실행면을 제공해 로컬 24/7을 안 켜도 됩니다 — 다만 저장소 권한, CI 검증, 컴플라이언스 경계는 직접 설정해야 합니다. 자체 호스팅 배포의 의미는 데이터와 실행이 완전히 통제하는 노드에 있다는 것입니다.

Q: GitHub Copilot Workspace / OpenAI Codex를 쓸 수 있나?
A: L3/L5의 모델·UI 계층으로 사용 가능; 배포 계층은 여전히 실행 환경 + 스케줄링 + 검증입니다. Codex가 ChatGPT와 합쳐진 뒤 더 페어에 가깝고, 무인 운영에는 workflow 래퍼가 필요합니다(Codex 통합 해설).

Q: Linux에서 Docker OpenHands만으로 충분한가?
A: 순수 Web / 백엔드는 충분; Apple 툴체인 단계는 macOS 노드로 전환해야 합니다. 혼합 팀 흔한 구조: Linux에서 스케줄링, macOS Cloud Mac에서 빌드와 Agent.

Q: 혼자 유지보수하는데 24/7이 필요한가?
A: 낮에만 페어 코딩이면 필수 아님. 24/7 AI Coding Agent는 issue 적체, 타임존 팀, 「기술 부채 정리」를 밤 머신 시간으로 옮기고 싶을 때 적합합니다.

Q: Devin / Factory 같은 상용 autonomous agent와 비교하면?
A: 상용 제품은 Agent + 실행면 + UI를 묶어 팝니다. 자체 배포는 감사 가능, 권한 커스터마이즈, 기존 Runner/MCP 스택 정렬이 목적입니다. 많은 팀이 「상용 Agent로 탐색, 자체 호스팅 노드로 양산」을 택합니다.