기대를 넘어: 최고의 엔지니어링 팀들이 실제로 AI를 활용하는 방법

소프트웨어 엔지니어링 분야의 AI를 둘러싼 담론은 종종 두 가지 극단 사이를 오갑니다. 즉, 인간 개발자가 도태되고 있다는 주장과 AI는 그저 화려한 자동 완성 도구일 뿐이라는 주장입니다. 최근 Platform9, Monday.com, 그리고 PlayStation의 리더십이 참여한 웨비나(webinar)에서는 더욱 미묘한 현실이 드러났습니다. 팀들은 더 이상 단순히 AI를 "시도"하는 것에 그치지 않고, AI를 중심으로 소프트웨어 개발 생명 주기(SDLC, Software Development Life Cycle) 전체를 재구조화하고 있습니다.

저는 이 웨비나에 참석할 기회가 있었으며, 아래의 노트는 토론 과정에서 저에게 눈에 띄었던 주요 아이디어, 관행 및 관찰 사항을 요약한 것입니다.

도구 환경: Cursor와 Claude가 주도하다

마케팅 캠페인에는 다양한 도구들이 등장하지만, 패널들 사이에서는 Claude Code와 Cursor가 가장 흔히 채택되는 AI 코딩 도구로 나타났습니다.

Platform9는 계층화된 접근 방식을 활용합니다. UI 엔지니어는 Cursor를 선호하고, 백엔드 엔지니어는 Windsurf로 기울며, 터미널 중심의 사용자들은 Claude Code를 활용합니다.
Monday.com은 개발자를 위한 주요 로컬 에이전트(local agent)로 Cursor를 선택했으며, Claude Code는 그들의 SDLC 자동화 단계에 동력을 제공합니다.
PlayStation은 기존의 git 저장소 및 생태계와의 원활한 통합 덕분에 주로 GitHub Copilot을 사용합니다.
특히, Gemini는 코딩 작업에는 가장 선호도가 낮은 것으로 강조되었으나, 이미지 생성과 같은 비기술적 요구 사항에는 여전히 유용합니다.

"오케스트레이션 엔지니어(Orchestration Engineer)"의 부상

엔지니어의 역할 정의에 있어 중대한 변화가 일어나고 있습니다. Monday.com의 Michael은 개발자가 **오케스트레이션 엔지니어(orchestration engineers)**로서 활동하는 **"에이전틱 엔지니어링(agentic engineering)"**으로의 전환을 설명했습니다.

Monday.com은 한 달간의 내부 이니셔티브를 통해 엔지니어들이 주로 AI가 생성한 코드에 의존하도록 하는 실험을 진행 중이라고 밝혔습니다.
반복적으로 나타난 주제 중 하나는 코드 그 자체는 차별화 요소로서의 비중이 낮아지고 있다는 점입니다. 대신 아키텍처 (architecture), 제품 이해도 (product understanding), 그리고 시스템 설계 (system design)의 가치가 점점 더 높아지고 있습니다. 이제 인간의 가치는 **아키텍처를 정의(defining architecture)**하고, 제품 목표를 명확히 하며, 피드백 루프 (feedback loops)를 구축하는 데 있습니다. 예를 들어, 한 팀은 AI가 구문 (syntax)을 처리하도록 맡기고 자신들은 아키텍처적 제약 사항을 관리함으로써, 해당 언어에 대한 사전 경험 없이도 Rust를 사용하여 고성능 제품을 성공적으로 구축했습니다.

인프라 및 운영에서의 AI

AI의 활용은 IDE를 훨씬 넘어 복잡한 시스템 관리 영역으로 확장되었습니다:

근본 원인 분석 (Root Cause Analysis): Platform9는 Kubernetes API를 조사하기 위해 에이전트 (agents)를 사용합니다. LLM에 특정 배포 환경에 대한 컨텍스트를 제공함으로써 (그들은 이 과정을 **"컨텍스트 엔지니어링 (context engineering)"**이라 부릅니다), 조사된 사례의 약 50~60%에서 성능 및 구성 문제를 식별할 수 있었으며, 해결 속도를 획기적으로 단축했다고 보고했습니다.
레거시 코드 및 문서화: 검색 증강 생성 (RAG, Retrieval-Augmented Generation)은 수년간 쌓인 기술 부채 (technical debt)와 문서를 파악하는 데 사용되고 있습니다. **Windsurf의 "deep wiki"**와 같은 도구는 저장소 (repositories)를 위한 실시간 문서를 생성할 수 있으며, 이는 새로운 엔지니어를 온보딩 (onboarding)할 때 매우 유용합니다.

보안, 컴플라이언스 및 가드레일

PlayStation과 같은 대기업에게 보안은 가장 주요한 제약 사항입니다.

데이터 프라이버시 (Data Privacy): 프라이버시 문제를 해결하기 위해, 기업들은 종종 AWS Bedrock 또는 Google Cloud의 AI 서비스와 같은 관리형 AI 플랫폼 (managed AI platforms)에 의존합니다. 이러한 플랫폼은 소비자 대상 서비스보다 데이터 처리 및 거버넌스 (governance) 측면에서 더 강력한 제어 기능을 제공합니다.
인간 참여형 (Human-in-the-Loop): 주요 기업에서는 AI가 생성한 코드가 엄격한 수동 검토 (manual review)를 거치지 않고서는 절대로 프로덕션 (production) 환경에 반영되지 않습니다.
관료적 업무 자동화 (Automating Bureaucracy): AI는 코딩 이외의 "지루한 업무 (drudgery)"를 처리하는 데 매우 효과적임이 입증되었습니다. 예를 들어, 경영진을 위한 국제 회의 요약이나 영업 팀을 위한 300개 문항의 보안 설문지 (security questionnaires) 자동화와 같은 작업들이 이에 해당하며, 이러한 작업들은 이전에는 엔지니어와 경영진의 수많은 수동 작업 시간을 소모하게 만들었습니다.

새로운 과제: 노이즈와 편향 (Emerging Challenges: Noise and Bias)

생산성 향상에도 불구하고, 몇 가지 장애물이 남아 있습니다:

검토 병목 현상 (The Review Bottleneck): AI는 인간이 검토하는 속도보다 더 빠르게 코드를 생성할 수 있으며, 이는 GitHub에서 **신호 대 잡음비 문제 (signal-to-noise ratio problem)**를 야기합니다. 봇의 댓글과 멘션 양이 너무 많아져 검토자가 중요한 변경 사항을 찾는 것이 어려워집니다.
창의적 편향 (Creative Biasing): 문제에 접근할 때 AI를 사용하는 것이 "사고를 제한할 수 있다"는 우려가 있습니다. 엔지니어가 너무 이른 단계에서 AI의 제안에 의존하게 되면, 특정 경로에 편향되어 더 창의적이고 독립적인 솔루션을 탐색하지 못할 수 있습니다.
모델 다양성 (Model Diversity): 일부 리더들은 코드 생성에는 하나의 모델(예: Claude)을 사용하고, 검토에는 다른 모델을 사용하여 더 많은 오류를 잡아낼 수 있는 "의견의 다양성 (diversity of opinion)"을 확보할 것을 권장합니다.

**결론 (Conclusion)

엔지니어링의 미래는 전체 소프트웨어 개발 생명주기 (SDLC)를 탐색할 수 있는 **자율 에이전트 (autonomous agents)**를 향해 나아가고 있습니다. 스타트업들은 무엇이 효과적인지 확인하기 위해 AI가 생성한 변형 모델을 고객에게 직접 배포하며 이미 "한계에 도전 (living on the edge)"하고 있는 반면, 대기업들은 정교한 **내부 가드레일 시스템 (internal guardrail systems)**을 구축하는 데 집중하고 있습니다. 규모와 상관없이 핵심은 동일합니다. 가장 성공적인 엔지니어는 올바른 질문을 던지고, 자신의 AI 에이전트가 작동할 수 있는 올바른 환경을 정의할 수 있는 사람이 될 것입니다.

제가 얻은 가장 큰 교훈은 AI가 엔지니어를 대체한다는 것이 아니었습니다. 그것은 엔지니어의 역할이 변화하고 있다는 점이었습니다. 논의는 단순한 코드 생성보다는 아키텍처 (architecture), 컨텍스트 (context), 그리고 의사결정 (decision-making)으로 반복해서 돌아왔습니다. 이러한 비전이 현실이 되든 그렇지 않든, 선도적인 팀들은 불과 1년 전만 해도 비현실적으로 들렸을 워크플로 (workflows)를 이미 실험하고 있다는 점은 분명합니다.