개발자의 역할이 바뀌고 있다: 에이전틱 개발의 시대
2025년 11월 25일, 스포티파이의 내부 차트에 하나의 뚜렷한 변곡점이 나타났습니다. 바로 Anthropic의 Opus 4.5 모델이 공개된 날이었죠. 이 날 이후로 스포티파이 엔지니어들의 업무 방식이 눈에 띄게 변화하기 시작했습니다.
"사무실에 왔더니 사람들이 IDE 앞에 앉아 있던 모습이, 3주 후에는 모두가 터미널 앞에 앉아 있더군요." — David Soria Parra, Anthropic
이 변화의 중심에는 **에이전틱 개발(Agentic Development)**이 있습니다. 단순히 AI에게 코드 생성을 요청하는 수준을 넘어, AI 에이전트가 개발 워크플로우의 일부로 자리잡는 현실 말이죠. 스포티파이의 수석 아키텍트 Niklas Gustavsson과 Anthropic의 MCP 공동 창시자 David Soria Parra, AI 리드 Christian Ryan이 함께한 이번 대화는 단순한 기술 발표가 아닌, 실제 대규모 조직에서 에이전트를 어떻게 운영하고 있는지에 대한 생생한 현장 보고서였습니다.
이 글에서는 해당 세션의 핵심 내용을 정리하고, 한국 개발 생태계에서의 적용 가능성을 함께 살펴보겠습니다.
📌 참고 자료: 본 내용은 Spotify Engineering Blog의 원문을 기반으로 재구성했습니다.
Honk: 슬랙에서 시작되는 백그라운드 코딩 에이전트
스포티파이는 자체 개발한 백그라운드 코딩 에이전트 Honk를 운영 중입니다. Honk의 가장 흥미로운 점은 개발자들이 Slack 메시지 하나로 에이전트를 호출할 수 있다는 것입니다.
"요즘 일반적인 사용자 상호작용은 이렇습니다. 누군가 Slack에서 해결하고 싶은 문제를 논의하다가 @Honk를 멘션하는 거죠. '이거 해결해줘' 라고요." — Niklas Gustavsson, Spotify
Honk는 단순한 코드 생성 도구가 아닙니다. 수천 개의 레포지토리를 대상으로 복잡한 소프트웨어 마이그레이션을 수행할 수 있는 에이전트입니다. 스포티파이는 Honk를 통해 이미 1,500개 이상의 PR을 성공적으로 처리했습니다.
Honk의 발전 단계
- 결정론적 코드 마이그레이션 — 단순 반복 작업 자동화
- Slack 네이티브 코딩 에이전트 — 대화형 인터페이스 도입
- 대규모 마이그레이션 에이전트 — 수천 개 레포지토리 동시 처리
실제 사용 예시 (의사 코드)
# Honk가 Slack 메시지를 받았을 때의 내부 로직 (개념적)
# Slack 메시지 예: "@Honk 모든 서비스의 로깅 레벨을 WARN으로 변경해줘"
import re
from typing import List, Dict
class HonkAgent:
def __init__(self, repos: List[str]):
self.repos = repos # 대상 레포지토리 목록
self.context = self._load_context()
def _load_context(self) -> Dict:
# Claude MD 설정과 기술 스택 정보 로드
return {
"coding_standards": "spotify_coding_conventions.md",
"architecture": "service_architecture_overview.md",
"allowed_actions": ["create_pr", "update_config", "refactor"]
}
def process_request(self, message: str) -> List[str]:
# 1. 의도 파악 (Claude API 호출)
intent = self._analyze_intent(message)
# 2. 영향 범위 분석
affected_repos = self._find_affected_repos(intent)
# 3. 각 레포지토리별 PR 생성
pr_urls = []
for repo in affected_repos:
code_change = self._generate_change(repo, intent)
pr = self._create_pull_request(repo, code_change)
pr_urls.append(pr.url)
return pr_urls
def _analyze_intent(self, message: str) -> Dict:
# Claude API를 통한 자연어 분석
# return {"action": "change_log_level", "level": "WARN", "scope": "all_services"}
pass
⚠️ 주의사항: Honk와 같은 에이전트는 강력한 컨텍스트 관리와 안전장치 없이 도입하면 예측 불가능한 결과를 초래할 수 있습니다. 특히 한국의 SI/금융권 환경에서는 규제 준수와 코드 리뷰 프로세스가 선행되어야 합니다.
컨텍스트 엔지니어링: 에이전트 성공의 열쇠
Anthropic의 Christian Ryan이 강조한 핵심은 "과도하게 복잡하게 생각하지 말라"는 것입니다.
"컨텍스트 관리와 컨텍스트 엔지니어링에 관해서는, 엔지니어 전체에 재현 가능한 상당히 단순한 설정을 갖추는 것이 중요합니다. 좋은 Claude MD 설정, 수행하려는 역할이나 도메인의 본질을 포착하는 좋은 스킬 세트면 충분합니다."
효과적인 컨텍스트 설정의 3요소
| 요소 | 설명 | Spotify 적용 사례 |
|---|---|---|
| Claude MD 설정 | 프로젝트별 규칙과 컨벤션 정의 | 코딩 표준, 아키텍처 가이드라인 |
| 도메인 스킬 세트 | 특정 역할/도메인에 특화된 지식 | 서비스별 마이그레이션 패턴 |
| 재현 가능성 | 모든 엔지니어가 동일한 설정 사용 | 중앙 저장소에서 관리되는 설정 파일 |
한국 개발 생태계에서의 적용 맥락
한국 기업에서 에이전틱 개발을 도입할 때 고려할 점은 다음과 같습니다:
- 레거시 시스템과의 통합: 많은 국내 기업이 여전히 Java/Spring 기반의 모놀리식 시스템을 운영 중입니다. 이러한 환경에서 에이전트를 도입하려면 먼저 표준화된 CI/CD 파이프라인과 컨테이너화가 선행되어야 합니다.
- 코드 리뷰 문화: "에이전트가 만든 코드는 누가 책임질 것인가?"라는 질문에 대해 스포티파이/Anthropic 팀은 결과 기반(outcome-based) 접근법을 제안합니다. 누가 만들었는지보다 결과물의 품질과 책임자가 명확해야 한다는 것이죠.
- 보안과 거버넌스: 특히 금융권이나 공공기관에서는 에이전트가 코드를 직접 PR하는 것에 대한 규제 이슈가 있을 수 있습니다. 초기 단계에서는 에이전트가 "제안"만 하고 사람이 최종 승인하는 하이브리드 방식을 추천합니다.
# 예시: 한국 기업을 위한 에이전트 거버넌스 설정 (의사 코드)
# governance_config.yaml
governance:
mode: "suggest_only" # 초기: suggest_only → 이후: auto_pr
approval_required: true
allowed_repos:
- "internal-tools/*"
- "docs/*"
blocked_repos:
- "payment-service/*"
- "user-data-service/*"
review_process:
- agent_generates_diff
- senior_dev_reviews
- automated_tests_pass
- manual_approval
결론: 에이전틱 개발의 미래와 한국 개발자에게 주는 교훈
이번 대화에서 가장 인상 깊었던 점은 2025년이 코드 생성의 해였다면, 다음 프론티어는 유지보수와 삭제까지 포함한 전체 소프트웨어 생명주기라는 David의 전망입니다. 아무도 하고 싶어하지 않지만 모두가 필요로 하는 작업 — 레거시 코드 정리, 의존성 업데이트, 사용하지 않는 기능 제거 — 을 에이전트가 대신하게 될 것입니다.
스포티파이는 Backstage를 인간 중심의 개발자 포털에서 에이전트 우선 플랫폼으로 진화시키고 있으며, MCP 연결이 수동 워크플로우를 대체하고 있습니다.
한국 개발자를 위한 3단계 실천 로드맵
- 1단계 (지금 당장): 팀 내 반복적인 코드 작업(리팩토링, 마이그레이션)을 식별하고, Claude Code나 유사 도구로 파일럿 프로젝트를 진행해보세요.
- 2단계 (3개월 내): 표준화된 Claude MD 설정과 컨텍스트 문서를 팀 전체에 공유하고, 단순 PR 자동화부터 시작해보세요.
- 3단계 (6개월 이상): 거버넌스 체계를 마련하고, 에이전트가 제안한 코드의 품질을 측정하는 메트릭을 도입하세요.
🔍 함께 보면 좋은 글
개발자의 역할이 단순 코드 작성에서 에이전트를 설계하고 조율하는 오케스트레이터로 변화하고 있습니다. 이 변화를 두려워하기보다는, 어떻게 하면 더 가치 있는 일에 집중할 수 있을지 고민해보는 건 어떨까요?