피그마의 고품질 AI 에이전트 채택 전략

제 이름은 알 블룸입니다. 저는 피그마의 소프트웨어 엔지니어이며, 오늘 강연에서는 코드베이스의 고품질을 유지하면서 피그마의 워크플로에 소프트 에이전트를 어떻게 채택했는지 또는 채택하고 있는지에 대해 이야기할 것입니다. 피그마의 소프트웨어 엔지니어인 아이알 블룸은 회사가 전통적인 소프트웨어 개발에서 AI 우선 도구를 통합하는 방식으로 전환하고 있다고 설명합니다. 그의 발표는 내부 엔지니어링 조직의 워크플로와 코드 품질을 손상시키지 않고 AI 에이전트가 어떻게 통합되고 있는지에 초점을 맞춥니다.

AI 채택은 세 단계로 이루어집니다. 먼저 무언가를 선택한 다음... 동일한 관행을 더 큰 문제에 적용하기 시작하면 AI가 그 부분에서 상당히 실패합니다... 그리고 그 시점부터 AI를 올바르게 사용하는 방법과 올바른 보호 장치를 마련하는 방법을 배우는 진정한 기술을 구축하기 시작합니다. 조직 내 AI 채택 과정은 세 단계로 진행됩니다. 간단한 작업에서의 초기 성공, 이 관행이 더 복잡한 문제에 적용될 때의 심각한 실패 단계로 인해 버그와 신뢰 상실이 발생합니다. 세 번째 단계는 AI를 올바르게 사용하는 방법과 적절한 보호 장치 및 상황 인식을 구현하는 방법을 이해함으로써 진정한 기술을 개발하는 것입니다.

채택은 균등하지 않습니다. AI에 매우 적극적이고 전체 워크플로를 이미 변경한 팀도 있고, 아직 초기 단계에서 실험 중이거나 신뢰를 잃은 팀도 있습니다. 이들 모두는 제품을 출시하기 위해 함께 협력해야 합니다. 피그마는 팀 간 AI 채택 속도가 고르지 않음을 관찰했습니다. 일부 팀은 AI를 워크플로에 완전히 통합하여 매우 발전했지만, 다른 팀은 아직 실험 단계에 있거나 이전의 좌절로 인해 신뢰를 잃었습니다. 이러한 다양한 채택 수준에도 불구하고 모든 팀은 제품의 지속적인 출하를 보장하기 위해 효과적으로 협력해야 합니다.

개발자와 관리자로부터 많이 들은 한 가지는 개발자 자율성 감소로 인해 엔지니어가 직무 만족도의 일부를 잃는다는 것입니다. 많은 사람들이 코드를 작성하고 몰입하는 것에 많은 자부심과 즐거움을 느꼈고, 많은 사람들이 그것을 잃었다고 생각합니다... AI 출력만 기다리고 AI와 대화하는 프롬프트 주기로 들어가면 예전만큼 재미있지 않고 번아웃을 겪게 됩니다. AI 지원 코딩으로의 전환은 개발자 자율성 감소로 이어져, 이전에 코드를 작성하고 '몰입' 상태를 달성하는 데 자부심과 즐거움을 찾았던 엔지니어들의 직무 만족도에 영향을 미쳤습니다. 개발자들이 주로 AI 출력을 기다리고 상호 작용하는 '프롬프트 주기'로의 이러한 변화는 엔지니어링 직원들 사이에서 번아웃과 성취감 상실을 야기하고 있습니다.

모든 맥락을 머릿속에 담고 있는 최고의 엔지니어는 많은 부담을 안게 됩니다... 그들은 에이전트가 제대로 작동하지 않는 모든 부분을 정신적인 덕트 테이프로 함께 붙들고 있으며, 모든 정말 나쁜 것들이 들어오는 것을 막고 있습니다... 그들은 너무 많은 부담을 안고 병목 현상이 되어 정말 좌절합니다. 가장 숙련된 엔지니어, 즉 가장 깊은 기관적 맥락을 가진 사람들은 AI가 생성한 코드를 수동으로 확인하는 데 가장 큰 부담을 지는 경우가 많습니다. 이들은 AI 에이전트에서 발생하는 오류와 위험을 방지하면서 중요한 병목 현상이 되어 상당한 좌절감을 느끼게 하며, 잠재적 문제에 대한 예리한 인식 때문에 AI 채택이 가장 느립니다.

갑자기 모든 디자인 문서와 모든 슬랙 메시지, 모든 이메일이 세네 배 길어졌고, 이메일은 두세 배 많아졌습니다. 그리고 기본적으로 예전과 거의 같은 양을 말합니다. 그래서 커뮤니케이션이 상당히 비효율적으로 변했습니다. AI의 도입으로 인해 디자인 문서, 슬랙 메시지, 이메일을 포함한 커뮤니케이션의 길이와 양이 크게 증가하여 종종 세네 배 더 길어지고 두세 배 더 자주 발생합니다. 그러나 이러한 커뮤니케이션의 급증은 의미 있는 정보나 출하 속도의 비례적 증가와는 상관관계가 없었으며, 결과적으로 전반적인 커뮤니케이션 비효율성을 초래했습니다.

검증에 투자하는 것은 우리 코드베이스에서 할 수 있는 가장 가치 있는 일일 것입니다... 플레이라이트 MCP가 출시되었을 때, 사람이 코드를 탐색하는 대신 에이전트가 코드를 탐색할 수 있게 되었습니다. 이것은 생산성 향상에 큰 도움이 되었습니다... 에이전트가 유용하다고 찾은 것을 발견하면, 시간을 들여 그것을 결정론적 흐름으로 인코딩하는 것이 더 좋습니다. 아이알 블룸은 특히 '레프트 시프트(Left-shift)' 접근 방식을 통한 검증 투자가 코드베이스에 가장 가치 있는 활동이라고 강조합니다. 그는 AI 에이전트가 코드를 자율적으로 탐색할 수 있게 하여 생산성을 크게 향상시키는 플레이라이트 MCP와 같은 예를 인용합니다. 또한 그는 성공적인 AI 패턴을 결정론적 흐름으로 인코딩하여 토큰 사용량을 줄이고 전반적인 신뢰성을 향상시킬 것을 주장합니다.

기술이나 에이전트에게 TDD 스타일의 레드 투 그린(Red to Green) 방식으로 코드를 작성하도록 지시하면 거의 항상 더 나은 결과를 얻을 수 있습니다. AI 에이전트 기반 코딩에 테스트 주도 개발(TDD) 원칙을 적용하면 항상 우수한 결과가 나옵니다. 이 접근 방식은 코드를 작성하기 전에 테스트를 정의하는 것으로, 에이전트가 기존 테스트를 통과하기 위해 결함 있는 코드를 수정하는 대신 특정 검증 기준을 충족하도록 장려합니다.

린팅, 컴파일러, 단위 테스트 자체 등 가능한 한 많은 것을 결정론적 분석으로 옮기십시오. 아이알 블룸은 가능한 한 많은 테스트를 린팅, 컴파일러, 단위 테스트를 포함한 결정론적 분석으로 전환할 것을 권장합니다. 따라서 인간 검토는 주로 아키텍처 기능과 높은 수준의 전략적 목표를 위해 예약되어야 합니다.

계획을 작성하는 데 많은 시간을 할애하고 에이전트에게 자동적으로 수행할 수 있는 구현으로 충분히 판매하는 것이 빌딩의 즐거움을 다시 프로세스에 도입하는 데 정말 도움이 된다고 생각합니다. 아이알 블룸은 순수한 프롬프트 방식보다 상세한 계획이 개발자에게 코딩의 본질적인 즐거움을 되찾아줄 수 있다고 주장합니다. 그는 일주일 동안 세심한 계획을 세우면 엄청난 효율성 향상을 가져올 수 있다고 제안합니다. 이러한 계획은 AI 구현 전에 팀원들이 반복적으로 검토하여 품질과 정렬을 보장할 수 있습니다.

맨 위에 '왜'를 시작하는 것이 매우 중요합니다. 에이전트 드리프트를 방지하는 데 정말 도움이 됩니다. 아이알 블룸은 AI 에이전트 드리프트를 방지하기 위해 요약에 명확한 '왜'를 포함하여 계획을 시작하는 것의 중요성을 강조합니다. 그는 또한 각 작업의 적절한 크기와 범위를 결정하기 위해 '커피 브레이크 논리'를 사용하여 계획을 작고 독립적으로 검증 가능한 세그먼트로 나누도록 권장합니다.

각 단계에 검증 게이트 또는 예외 기준을 두는 것은 계획이 드리프트에 강하게 만드는 데 정말 도움이 됩니다. 아이알 블룸에 따르면, 다단계 계획의 각 단계에 검증 게이트 또는 예외 기준을 구현하는 것은 드리프트에 대한 탄력성을 높이는 데 중요합니다. 이 접근 방식은 프로세스 초기에 검증되지 않은 가정을 포착하고 해결하여 오류가 하류로 전파되는 것을 방지합니다.

모든 사람을 한 가지에 집중시키려고 하면 수확 체감의 법칙이 나타나지만, 자신의 흐름에 맞고 다른 사람들이 그들과 함께 반복할 수 있다면 일반적으로 매우 잘 작동한다고 생각합니다. 아이알 블룸은 모든 팀을 단일 AI 워크플로에 집중시키려는 시도는 수확 체감의 법칙을 초래한다고 주장합니다. 대신 그는 개발자들이 자신의 개별 워크플로에 가장 적합한 도구를 구성할 수 있도록 권한을 부여하되, 이러한 설정이 다른 팀원들과 효과적인 협업 및 반복 작업을 가능하게 하는 한 그렇게 해야 한다고 주장합니다.

이것은 AI 이전 세계에서 일어난 일인데, 이 계획을 저는 아마 일주일 동안 작업했습니다. 다른 세 팀과 또 일주일 동안 조율한 다음, 밤새 구현하도록 에이전트에게 보냈고, 결과가 돌아왔습니다. 아이알 블룸은 수동 코딩으로 6주가 걸렸을 작업을 단 1주일로 줄여 상당한 효율성 향상을 보여줍니다. 이 과정은 일주일의 상세한 계획, 그 다음 다른 세 팀과의 일주일 조율을 포함했습니다. 이어서, 이 계획은 밤새 구현을 위해 AI 에이전트에게 제출되었으며, 이는 개발 속도의 상당한 가속화를 입증합니다.