요즘 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는 주로 비용을 절감하고 더 적은 인원으로 같은 일을 하는 것이라는 서사가 있다. 어떤 맥락에서는 그 말이 맞을 수도 있다. 하지만 내 경험상 더 흥미로운 이야기는 예전에는 할 가치가 없다고 여겨졌던 일들을 해내는 것에 관한 것이다. 더 넓은 범위를 커버하고, 더 높은 기준을 유지하며, 그렇지 않았다면 백로그에 무기한 남았을 마이그레이션을 맡고, 마침내 플랫폼의 결정과 현실 세계의 결과 사이의 고리를 닫는 일이다.

그것이 나를 들뜨게 하는 지점이다. 무엇이 대체될지에 대한 두려움이 아니라, 무엇이 가능해지는가에 대한 질문이다.