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

Source: Dev.to

소프트웨어 엔지니어링에서 AI에 대한 이야기는 종종 두 극단 사이를 오갑니다. 인간 개발자가 사라지고 있다는 주장과 AI가 단지 멋진 자동완성 도구에 불과하다는 주장 사이에서 말이죠. Platform9, Monday.com, PlayStation의 리더십이 참여한 최근 웨비나에서는 보다 미묘한 현실이 드러났습니다. 팀들은 이제 AI를 “시도”하는 수준을 넘어, 전체 소프트웨어 개발 라이프사이클(SDLC)을 AI 중심으로 재구성하고 있습니다.
제가 해당 웨비나에 참석할 기회가 있었으며, 아래 메모는 토론 중 눈에 띈 핵심 아이디어, 실천 방안, 관찰 내용의 요약입니다.

The Tooling Landscape: Cursor and Claude Take the Lead

마케팅 캠페인에서는 다양한 도구가 소개되지만, 패널리스트들 사이에서는 Claude Code와 Cursor가 가장 많이 채택된 AI 코딩 도구로 보였습니다.

• Platform9은 계층화된 접근 방식을 사용합니다. UI 엔지니어는 Cursor를, 백엔드 엔지니어는 Windsurf를, 터미널 중심 사용자는 Claude Code를 선호합니다.
• Monday.com은 개발자를 위한 주요 로컬 에이전트로 Cursor에 집중했으며, SDLC의 자동화 단계는 Claude Code가 담당합니다.
• PlayStation은 기존 Git 저장소와 생태계와의 원활한 통합 덕분에 GitHub Copilot을 주로 사용합니다.
• 특히 Gemini는 코딩 작업에서는 가장 선호되지 않는 도구로 언급됐지만, 이미지 생성 같은 비기술적 요구에는 여전히 유용합니다.

The Rise of the “Orchestration Engineer”

엔지니어 역할 정의에 큰 변화가 일어나고 있습니다. Monday.com의 Michael은 개발자가 “에이전트 기반 엔지니어링”(agentic engineering) 으로 전환하면서 오케스트레이션 엔지니어가 된다고 설명했습니다.

• Monday.com은 엔지니어가 한 달 동안 주로 AI가 생성한 코드를 활용하도록 하는 내부 실험을 진행 중이라고 공유했습니다.
• 반복적으로 등장한 주제는 코드 자체가 차별화 요소가 점점 줄어들고, 아키텍처, 제품 이해, 시스템 설계가 더욱 가치 있게 된다는 점입니다. 인간의 가치는 이제 아키텍처 정의, 제품 목표 명확화, 피드백 루프 구축에 있습니다. 예를 들어, 한 팀은 Rust에 대한 사전 경험이 없었지만 AI가 구문을 처리하도록 하고, 자신들은 아키텍처 제약을 관리함으로써 고성능 제품을 성공적으로 만들었습니다.

AI in Infrastructure and Operations

AI 적용 범위가 IDE를 넘어 복잡한 시스템 관리까지 확대되었습니다.

• Root Cause Analysis: Platform9은 에이전트를 이용해 Kubernetes API를 질의합니다. 특정 배포에 대한 컨텍스트를 LLM에 제공하는 “컨텍스트 엔지니어링” 과정을 통해 조사된 사례의 약 50~60%에서 성능 및 구성 문제를 식별했으며, 해결 속도가 크게 빨라졌다고 합니다.
• Legacy Code and Documentation: Retrieval‑Augmented Generation(RAG)을 활용해 수년간 쌓인 기술 부채와 문서를 정리하고 있습니다. Windsurf의 “deep wiki” 같은 도구는 저장소에 대한 실시간 문서를 생성해 신규 엔지니어 온보딩에 큰 도움이 됩니다.

Security, Compliance, and Guardrails

PlayStation과 같은 대기업에게 보안은 가장 큰 제약 조건입니다.

• Data Privacy: 프라이버시 문제를 해결하기 위해 기업들은 AWS Bedrock이나 Google Cloud AI와 같이 데이터 처리와 거버넌스에 대한 강력한 제어를 제공하는 관리형 AI 플랫폼을 선호합니다.
• Human-in-the-Loop: 주요 기업에서는 AI가 생성한 코드가 엄격한 수동 검토 없이 프로덕션에 배포되지 않습니다.
• Automating Bureaucracy: AI는 코딩이 아닌 “지루한 작업”을 자동화하는 데 뛰어납니다. 예를 들어, 국제 회의 요약, 리더십용 보고서 작성, 영업팀을 위한 300개 질문 보안 설문 자동화 등은 이전에 엔지니어와 리더십이 수작업으로 처리하던 시간을 크게 절감했습니다.

Emerging Challenges: Noise and Bias

생산성 향상에도 불구하고 몇 가지 장벽이 남아 있습니다.

• The Review Bottleneck: AI가 코드를 인간보다 빠르게 생성하면서 리뷰 속도가 따라가지 못해 GitHub에서 신호‑대‑잡음 비율 문제가 발생합니다. 봇 댓글과 멘션이 넘쳐나 리뷰어가 중요한 변경 사항을 찾기 어려워집니다.
• Creative Biasing: AI 제안을 너무 일찍 받아들이면 사고의 폭이 제한될 수 있다는 우려가 있습니다. 엔지니어가 AI의 특정 경로에 편향되면 보다 창의적이고 독립적인 해결책을 탐색하지 못할 위험이 있습니다.
• Model Diversity: 일부 리더는 코드 생성에 한 모델(예: Claude)을 사용하고, 검토에는 다른 모델을 활용해 “의견 다양성”을 확보함으로써 오류를 더 많이 잡아내자는 입장을 제시합니다.

Conclusion

엔지니어링의 미래는 전체 SDLC를 탐색할 수 있는 자율 에이전트 쪽으로 이동하고 있습니다. 스타트업은 AI가 생성한 변형을 직접 고객에게 배포해 “가장자리에서 살아가고” 있지만, 대기업은 정교한 내부 가드레일 시스템 구축에 집중하고 있습니다. 규모와 관계없이 핵심은 변하지 않습니다. 가장 성공적인 엔지니어는 올바른 질문을 던지고, AI 에이전트가 작동할 적절한 환경을 정의할 수 있는 사람입니다.

제가 가장 크게 느낀 점은 AI가 엔지니어를 대체한다는 것이 아니라 엔지니어 역할 자체가 변화하고 있다는 점입니다. 토론은 반복해서 코드 생산보다 아키텍처, 컨텍스트, 의사결정에 초점을 맞추었습니다. 이 비전이 현실이 되든 아니든, 선도적인 팀들은 1년 전만 해도 비현실적으로 들렸던 워크플로를 이미 실험하고 있다는 점은 분명합니다.