요즘 AI를 둘러싼 소음과 과장이 많고, 그중 상당수는 일자리 대체와 엔지니어가 잃게 될 것에 집중되어 있습니다. 저는 그 반대편에 대해 써보려 합니다. 플랫폼 팀에서 일상 업무의 일부로 AI 에이전트를 적극 활용해 온 지난 몇 달 동안 제가 얻은 것에 대해서 말입니다.

마법이라고 포장할 생각은 없습니다. 에이전트는 실수도 하고, 명확한 지시를 내리는 데 필요한 엔지니어링 지식을 대체하지도 않습니다. 그럼에도 에이전트와 함께 해온 일부 작업은 확실히 질적인 도약처럼 느껴졌습니다. 코드를 더 빠르게 작성하게 됐지만, 더 큰 변화는 범위입니다. 예전 같으면 미뤄뒀을 일을 이제는 맡을 수 있게 됐습니다.

플랫폼 팀의 문제

제 플랫폼 팀의 도전 과제에 대한 이전 글을 읽어보셨다면 아시겠지만, 맥락은 이렇습니다. 작은 팀이 넓은 영역을 책임지고 있습니다. 저희는 상시로 공유 서비스와 라이브러리, 28개 프로젝트에 걸친 마이크로 프론트엔드 아키텍처, CI 파이프라인 등을 유지보수하고 있습니다.

플랫폼 업무의 답답한 현실은 가장 어려운 문제가 항상 기술적인 것만은 아니라는 점입니다. 종종 문제는 조직적입니다. 20개가 넘는 프로젝트에 걸쳐 고쳐야 할 지점을 찾아내고 해결 방법도 정확히 알면서도 몇 달이 걸리기도 합니다. 각 팀마다 우선순위가 있고 그것이 플랫폼 팀의 추진 과제와 늘 일치하지 않기 때문입니다. 플랫폼 팀의 과제는 “이건 해야 한다”와 “팀이 이를 실행할 여력이 있다” 사이의 간극을 메우는 일입니다.

에이전트가 그 간극을 제가 예상치 못한 방식으로 메우기 시작했습니다.

리서치 업무: 횡단적인 의사결정을 가능하게 하기

플랫폼 팀에서 가장 중요한 의사결정은 종종 가장 확신하기 어려운 것들입니다. 서비스를 폐기하거나 라이브러리를 교체하거나 조직 전반에 새로운 표준을 강제하기 전에 누가 영향을 받는지, 엣지 케이스는 어떤 모습인지 이해해야 합니다. 이런 조사 작업은 늘 비용이 많이 들었고, 그래서 팀들은 불완전한 정보로 결정을 내리거나 제대로 수행할 여력이 없어 결정을 무기한 미루는 경우가 많았습니다.

레거시 서비스 파악하기

수년간 운영되어 온 서비스가 하나 있었습니다. 명확한 소유자도 없고 문서도 거의 없었으며, 계속 제기되던 질문은 하나였습니다. 도대체 누가, 어떻게 이걸 쓰고 있는가? 서비스를 종료해야 한다고 느꼈지만, 실제 사용 현황을 파악하기 전까지는 마이그레이션에 대해 명확한 결정을 내릴 수 없었습니다. 답을 얻으려면 GitLab 전반에서 의존성을 수동으로 추적하고, 레거시 SVN 저장소를 뒤지며, 오래전에 떠난 사람들이 수년 전에 작성한 코드 조각들을 맞춰 전체 그림을 그려야 했습니다.

에이전트를 활용하자 이 탐색 작업의 대부분을 맡길 수 있었습니다. 에이전트는 GitLab과 SVN에 걸쳐 서비스를 사용하는 프로젝트들을 훑고, 호출 지점을 식별하며, 서비스가 각기 다른 맥락에서 어떻게 쓰이고 있는지 요약하고, 제가 유의해야 할 엣지 케이스를 표시해 주었습니다. 이틀 정도 걸렸을 일이 훨씬 짧은 시간 안에 검토하고 발전시킬 수 있는 작업이 되었습니다.

사람의 판단과 영향을 받는 팀들과의 후속 논의가 필요 없다는 뜻은 아니지만, 조사 작업 자체는 훨씬 다루기 쉬워졌습니다.

아이콘 사용 현황과 WCAG 준수

또 다른 사례는 WCAG AA 표준 준수 여부를 평가하는 작업이었습니다. 그중 일부는 애플리케이션 전반에서 아이콘을 일관되고 올바르게 사용하고 있는지 평가하는 일이었습니다. 문제의 범위와 해결 방법을 파악하려면 어떤 아이콘 컴포넌트가 쓰이고 있는지, 맥락에 맞게 올바르게 쓰이고 있는지, 그리고 실제 WCAG AA 격차가 어디에 있는지를 알아야 했습니다.

프로젝트를 하나씩 수동으로 살펴보는 일은 지루한 작업이 되었을 겁니다. 대신 저는 디자인 시스템 사용 데이터를 기반으로 에이전트를 활용해 각 아이콘 사용 사례를 맥락 속에서 평가하고, 그 결과를 스프레드시트에 정리하도록 했습니다.

저는 필요에 따라 검토하고 수정했지만, 제가 들인 시간은 획기적으로 줄었습니다. 더 중요한 점은 실제 데이터를 바탕으로 다음에 무엇을 할지 결정할 수 있었다는 것입니다.

마이그레이션과 업그레이드: 설계만 하는 게 아니라 직접 실행하기

문제의 범위를 빠르게 파악할 수 있게 되면, 자연스럽게 드는 다음 질문은 같은 방식으로 고칠 수도 있느냐는 것입니다. 에이전트가 저에게 가장 큰 영향을 미친 지점이 바로 여기입니다. 마이그레이션 가이드를 공유하는 수준을 넘어 변경 사항을 직접 배포할 수 있게 됐습니다.

28개 마이크로 프론트엔드에 걸친 React 업그레이드

제 마이크로 프론트엔드 React 업그레이드에 대한 글을 읽어보셨다면, 이런 작업에 얼마나 많은 조율이 필요한지 아실 겁니다. 각 프로젝트는 우선순위가 다른 별개의 팀이 소유하고 있습니다. 단계가 명확하게 문서화된 마이그레이션이라 해도 모든 팀이 이를 실행하도록 만드는 일은 큰 도전입니다.

가장 적극적인 팀들이 마이그레이션을 완료한 뒤에도 최종 릴리스를 막고 있는 프로젝트가 상당수 남아 있었습니다. 팀들이 마이그레이션을 실행할 때까지 기다리는 대신, 저는 에이전트를 활용해 각 프로젝트를 개별적으로 처리했습니다. 마이그레이션 가이드를 따르고, 필요한 설정 변경을 적용하며, 해당 프로젝트 특유의 이슈를 해결하고, MR을 여는 방식이었습니다. 각 프로젝트마다 에이전트가 마이그레이션의 기계적인 부분을 처리했고, 팀들은 실행 요청이 아니라 바로 머지할 수 있는 코드 변경을 받게 됐습니다.

이전

이후

모든 MR이 머지되었습니다. 전체 롤아웃 과정에서 마주한 단 하나의 이슈는 제 MR이 나가기 전에 수동으로 마이그레이션을 진행한 팀에게서 발생했습니다. 에이전트가 생성한 변경 사항이 사람이 직접 만든 변경보다 더 깔끔한 기록을 남겼습니다.

“MR을 열었다”에서 “MR이 머지됐다”로 이어지는 전환율은 “마이그레이션 가이드를 보냈다”에서 “작업이 완료됐다”로 이어지는 전환율보다 압도적으로 높습니다. 팀은 여전히 코드를 검토하고 머지하며 소유권을 갖지만, 머지 전까지 해야 할 일은 줄어듭니다.

CI 파이프라인 리팩터링

최근 GitLab CI 리팩터링도 비슷한 이야기였습니다. 더 이상 사용되지 않는 only 키워드에서 rules 구문으로 공유 파이프라인을 옮겨야 했습니다. 변경 자체는 잘 알려져 있었지만, 파이프라인을 사용하는 모든 프로젝트에 적용해야 했고, 각 프로젝트마다 나름의 특성과 때로는 브레이킹 체인지까지 처리해야 했습니다.

보통 이런 종류의 변경은 프로젝트마다 도입 속도가 제각각이어서, 팀들이 강제될 때까지 도입을 미루곤 합니다. 이런 불일치는 서로 다른 프로젝트의 파이프라인이 다르게 동작할 때 혼란을 야기할 수 있습니다.

에이전트를 활용해 영향을 받는 모든 프로젝트를 프로그래밍 방식으로 식별하고, 각 프로젝트별로 마이그레이션을 진행하며, 마주한 브레이킹 체인지를 처리하고, MR을 제출함으로써 수동으로 했을 때 걸렸을 시간의 일부만으로 모든 프로젝트에 변경 사항을 적용할 수 있었습니다.

실전 팁

위 사례들을 다시 읽어보면 간단해 보일 수 있습니다. 실제로는 이런 작업들이 안정적으로 잘 돌아가기까지 적지 않은 시행착오가 있었습니다. 커스텀 glab 스킬이 가장 큰 성과였고, 나머지 팁들도 그런 실험 과정에서 나온 것입니다.

툴링을 위한 스킬 정의하기

제가 한 일 중 가장 효과적이었던 것은 glab CLI, 즉 GitLab 커맨드라인 도구를 위한 커스텀 에이전트 스킬을 작성한 것입니다. 스킬은 에이전트에게 특정 작업을 어떻게 수행해야 하는지에 대해 명확하고 주관적인 지침을 담은 마크다운 파일입니다. 이 경우에는 프로젝트 간 검색 방법, MR을 여는 방법, REST API를 통해 파일을 변경하는 방법 등이었습니다.

이것이 없으면 에이전트는 GitLab과 상호작용하기를 거부하거나 일관성 없고 취약한 bash 한 줄 명령어를 만들어냅니다. 잘 정의된 스킬이 있으면 신뢰할 수 있는 플레이북이 생깁니다. Agent Skills는 Cursor, Claude Code, GitHub Copilot 같은 도구에서 지원되는 개방형 표준입니다.

MCP로 에이전트에 내부 컨텍스트 제공하기

기본 상태의 에이전트는 내부 시스템에 대해 아무것도 모릅니다. 코드를 읽을 수는 있지만, 컴포넌트가 무엇을 해야 하는지, 공유 라이브러리의 의도된 API가 어떤 모습인지 알지 못합니다.

저는 이 문제를 저희 디자인 시스템 MCP 서버로 해결했습니다. MCP(Model Context Protocol)는 내부 데이터와 문서를 에이전트가 활용할 수 있도록 구조화되고 질의 가능한 형태로 노출할 수 있게 하는 개방형 표준입니다. 저희 서버는 Storybook 위에 구축되어 에이전트가 컴포넌트 props, 사용 가이드라인, 예제에 접근할 수 있게 합니다. 에이전트가 접근성을 위해 아이콘 사용을 검토할 때 디자인 시스템의 아이콘 관련 컴포넌트가 어떻게 쓰이도록 의도되었는지 조회할 수 있습니다.

MCP가 개방형 표준이기 때문에 동일한 서버가 여러 도구에서 동작합니다. 다만 MCP 서버를 유지보수하는 데는 실제 비용이 들고, 한 번의 투자로 끝나지 않습니다. 저희에게는 그만한 가치가 있었지만, 에이전트에게 로컬 마크다운 파일을 가리키게 하거나 Confluence에 내부 문서가 있다면 Atlassian MCP 같은 것을 사용하는 방법도 있습니다.

감사 데이터를 시작점으로 제공하기

에이전트에게 특정 라이브러리를 어떤 프로젝트가 쓰는지 처음부터 찾아내라고 하는 대신, 답을 바로 주세요. 저희는 어떤 프로젝트가 어떤 컴포넌트를 어떤 버전으로 쓰고 있는지 정확히 알려주는 디자인 시스템 사용 분석 데이터를 갖추고 있습니다. 작업 시작 시점에 이 데이터를 에이전트에게 제공하면 추측이 아니라 저희 사용 데이터에서 출발하게 되므로 더 빠르고 정확합니다.

저는 조직 전반의 의존성 사용 현황을 스캔하고 파싱해 에이전트가 데이터를 직접 조회할 수 있는 MCP 도구를 제공하는 프로젝트를 실험 중입니다.

사전 구조화가 리서치 작업의 실수를 줄입니다

플랫폼 팀에서 리서치 작업은 보통 20개 이상의 프로젝트에 영향을 미치는 의사결정으로 이어지므로 정확성이 중요합니다. 엣지 케이스를 놓친 모호한 요약은 도움이 되지 않을 뿐 아니라 잘못된 결정으로 이어집니다.

리서치 작업에서는 초기에 출력 형식을 정의하는 데 시간을 투자할 가치가 있음을 알게 됐습니다. 에이전트에게 “우리 프로젝트 전반의 아이콘 사용 현황을 조사해 줘”라고 하는 대신, 프로젝트당 한 행으로 구성된 스프레드시트 템플릿과 채워야 할 구체적인 열을 제공하세요.

이렇게 하면 에이전트가 체계적으로 작업하게 됩니다. 프로젝트별로, 열별로 작업하고 각 행마다 완료 기준이 명확해집니다. 구조 없이 열린 형태의 리서치 작업을 맡기면 에이전트는 원하는 것보다 더 높은 추상화 수준에서 요약하거나, 끝났다고 판단해 조기에 중단하는 경향이 있습니다.

마이그레이션 가이드는 어차피 작성하고, 프롬프트로 활용하세요

플랫폼 팀이라면 어차피 변경 사항을 사용하는 팀에 전달하기 위해 마이그레이션 가이드를 작성하게 됩니다. 제가 알게 된 점은 같은 가이드를 에이전트에게 제공하는 것 자체가 유용한 검증 단계가 된다는 것입니다.

에이전트가 혼란스러워하거나 잘못된 방향으로 가면, 이는 종종 지침의 빈틈이나 모호함을 드러냅니다. 가이드에서 다루지 않은 엣지 케이스는 에이전트가 실제 프로젝트에서 마주할 때 드러납니다. 에이전트를 몇 개 프로젝트에 실행해 보는 동안 문서도 스트레스 테스트를 거치게 되고, 이는 결국 변경 사항을 검토하거나 단계를 직접 따라야 하는 팀을 위해서도 가이드를 더 좋게 만듭니다.

도구에 관하여

저는 이런 종류의 작업에 주로 Cursor를 사용해 왔고, Claude Code와 GitHub Copilot으로도 조금씩 실험해 봤습니다. 솔직히 도구 간의 차이보다 중요한 것은 도구에 제공하는 컨텍스트의 품질입니다. 잘 정의된 스킬과 잘 만든 MCP 서버가 도구를 바꾸는 것보다 더 멀리 데려다줍니다.

여기서의 개방형 표준(컨텍스트를 위한 MCP, 마크다운 기반 스킬 파일) 덕분에 한 도구에서의 투자는 대체로 다른 도구로도 이전됩니다. 제공업체와 모델에 따라 가격이 변동하는 상황에서 특정 워크플로우에 너무 종속되기보다는 이 점을 염두에 둘 가치가 있습니다.

무엇이 달라지는가

에이전트는 실수합니다. 명확한 컨텍스트와 잘 정의된 작업이 필요합니다. 여전히 결과물을 검토하고, 에이전트가 무엇을 했는지 이해하며, 자신의 판단을 적용해야 합니다. 에이전트가 어려워하는 작업도 있고, 원하는 결과를 얻기 위해 기획 단계에서 몇 번의 반복이 계속 필요한 경우도 있습니다.

“AI가 엔지니어를 대체한다”는 프레임은 여기서 흥미로운 지점을 놓치고 있습니다. 제가 경험한 것은 오히려 이것에 가깝습니다. 한 명의 엔지니어가 감당할 수 있는 일의 상한이 높아졌다는 것입니다.

이전에는 28개 프로젝트에 영향을 미치는 문제를 발견해도 고치는 데 수개월의 조율이 필요할 거라 여기고 받아들였습니다. 이제는 그냥 제가 직접 고치고 팀이 그 작업을 검토하도록 할 수 있습니다. 그들에게 직접 변경하라고 요청하는 대신 말입니다. 이전에는 수십 개 저장소에 걸친 리서치 작업이 일주일짜리 투자였을 수 있습니다. 이제는 반나절이면 될 수도 있습니다.

이는 플랫폼 팀이 책임지는 영역에 비해 거의 항상 인력이 부족하기 때문에 중요합니다. 저희는 늘 무엇에 도전할 가치가 있는지 어려운 결정을 내려야 했습니다. AI 에이전트는 관련된 인간의 판단을 대체하는 것이 아니라, 이전에는 그 작업을 엄청나게 비싸게 만들었던 기계적인 실행을 처리함으로써 경제적으로 실행 가능한 일의 범위를 넓히고 있습니다.

여기에는 플랫폼 업무 특유의 더 개인적인 지점도 있다고 생각합니다. 플랫폼 팀에 있을 때 지속적으로 느끼는 좌절 중 하나는 영향력으로부터 멀어진 느낌입니다. 변경을 만들어도 도입은 느리고, 롤아웃은 고르지 않으며, 뭔가 제대로 되지 않았다는 것을 알게 될 때쯤이면 수개월이 지나 있습니다. 요청에 대응하고, 팀의 막힘을 풀어주며, 필요해지기를 기다리는 수동적인 느낌이 들 수 있습니다.

제가 느낀 점은 에이전트가 이러한 역학을 바꿀 수 있다는 것입니다. 사용하는 모든 팀에 바로 머지할 수 있는 MR을 전달하는 것은 단순히 더 빠른 것뿐 아니라, 결과를 즉시 확인할 수 있다는 의미이기도 합니다. 블로커가 수개월이 아니라 수일 만에 드러납니다. 다른 팀이 제 작업을 우선순위에 두느냐에 따라 딜리버리의 많은 부분이 좌우되던 기존 플랫폼 역할에서는 이루기 어려웠던 진정한 엔드투엔드 오너십을 느낄 수 있습니다.

AI는 주로 비용을 절감하고 더 적은 인원으로 같은 일을 하는 것이라는 서사가 있습니다. 어떤 맥락에서는 그럴 수도 있습니다. 하지만 제 경험상 더 흥미로운 이야기는 이전에는 할 가치가 없었던 일을 하게 되는 것에 관한 것입니다. 더 넓은 영역을 커버하고, 더 높은 기준을 유지하며, 그렇지 않았다면 백로그에 무기한 남아 있었을 마이그레이션을 해내고, 마침내 플랫폼의 결정과 현실 세계의 결과 사이의 고리를 닫는 일 말입니다.

바로 그 점이 저를 들뜨게 합니다. 무엇이 대체될지에 대한 두려움이 아니라, 무엇이 가능해지는지에 대한 질문 말입니다.