조직에 코딩 에이전트를 도입하는 방법 (품질 저하 없이) — 에얄 블룸(Eyal Blum), 피그마(Figma)
AAI Engineer
Computing/SoftwareManagement
Transcript
00:00:00안녕하세요, 제 이름은 에얄 블람입니다. 피그마의 소프트웨어 엔지니어이고,
00:00:17오늘 발표에서는 코드베이스의 높은 품질을 유지하면서 피그마의 워크플로에
00:00:25에이전트를 어떻게 적용해 왔고 또 적응해 나가고 있는지 이야기해 보려고 합니다.
00:00:32잘 아시다시피 피그마는 디자인과 엔지니어링, 그리고 이제는
00:00:40AI 에이전트가 함께 협력하여 코드를 배포하는 브라우저 기반 편집기입니다.
00:00:44피그마는 전통적인 도구에서 AI 우선 도구로 매우 강력하게 전환했지만,
00:00:52이번 발표에서는 우리 제품에 대해서 이야기하기보다는
00:00:55내부 조직과 엔지니어링 조직이 AI 에이전트에 어떻게 적응해 왔는지에 대해 더 이야기하겠습니다.
00:01:04조직과 회사, 개인 모두 내부적으로 발견한 것은 일종의
00:01:11AI 도입에 관한 3막의 과정이 존재한다는 점입니다.
00:01:16무언가를 집어드는 것으로 시작합니다. 이 방에 계신 많은 분들처럼
00:01:21AI에 푹 빠져서 이미 한동안 AI를 사용해 온 분들이 무언가를 시도하고
00:01:27단순한 작업들이 아주 잘 작동하도록 만들어 10배 더 빨라지는 식이죠.
00:01:30그러다 그 동일한 관행을 더 큰 문제에 적용하기 시작하면 AI는 꽤 심각하게 실패하고 나쁜 결과물과 수많은 버그를 낳습니다.
00:01:40버그가 많이 생기죠.
00:01:41그렇게 쌓았던 신뢰가 무너지고, 바로 그 시점에서 진정한 기술을 쌓기 시작합니다. 즉,
00:01:50AI를 올바르게 사용하는 법을 배우고, 올바른 가드레일과 올바른 프롬프팅,
00:01:55그리고 올바른 컨텍스트 등 실제 기술을 구축하기 위해 우리가 온 종일 이야기해 온 모든 것들을 설정하는 법을 배우는 것입니다.
00:02:02그리고 내부적으로 일어나고 있는 한 가지 현상은 팀이든 개인이든 AI 도입 속도가 고르지 않다는 점입니다.
00:02:12AI를 매우 적극적으로 수용하여 이미 전체 워크플로를 전환한 팀이 있는가 하면, 여전히 초기 단계에서 실험 중이거나 자신감을 잃은 팀도 있습니다. 우리 제품을 출시하려면 이들이 모두 함께 협력해야 합니다.
00:02:28따라서 이들은 조직 내에서 공존해야 하며, 모든 이들을 여정에 동참시키고 누구나 이야기의 3막으로 이끌면서 이들을 지원할 방법을 찾아야 합니다.
00:02:44이러한 주된 마찰 지점 외에도, AI를 도입하면서 발생하는 다른 마찰 지점들도 주목하게 되었습니다.
00:02:54개발자들로부터 자주 들었고 관리자들도 알아채고 있는 한 가지는, 개발자 자율성이 줄어들면서 엔지니어들의 직무 만족도가 일부 저하된다는 점입니다.
00:03:04많은 이들이 코드를 작성하고 몰입 상태에 들어가는 것에서 큰 자부심과 즐거움을 느꼈는데, 그 요소가 많이 사라졌거나 잃어버리고 있다고 느낍니다. 단순히 AI의 결과물을 기다리고 AI와 대화하는 프롬프트 주기로 빠져들면서 예전만큼의 재미를 느끼지 못하고 있죠.
00:03:22또 다른 흥미로운 점은 우리 최고의 엔지니어들이 모든 컨텍스트를 자신의 머릿속에 담아두려 한다는 것입니다. 결국 그들은 부담감을 느끼게 되고, 에이전트가 제대로 작동하지 않는 모든 곳을 정신적인 청테이프로 겨우겨우 엮어가며 아주 안 좋은 상황들이 유입되는 것을 막아내거나, 문서화되지 않은 모든 제도적 컨텍스트를 머릿속에 지닌 채 엄청난 부담을 떠안게 됩니다.
00:03:52결과적으로 그들은 병목 현상의 주범이 되고 큰 좌절감을 느끼며, 모든 문제를 직접 겪기 때문에 오히려 도입에 가장 소극적인 모습을 보이게 됩니다.
00:04:04이것은 우리가 목격한 또 다른 큰 문제입니다. 그리고 여기에 있는 모든 분들이 공감하시겠지만, 어느 순간부터 모든 디자인 문서와 슬랙 메시지, 이메일이 세 배 혹은 네 배로 길어졌고 이메일 수도 두세 배로 늘어났는데 담긴 내용은 예전과 거의 비슷합니다.
00:04:28따라서 소통이 꽤 비효율적으로 변했고, 무엇이 고품질이고 중요한 것인지 그렇지 않은지를 구분하는 기준을 파악하기가 어려워졌습니다.
00:04:40그래서 저는 남은 몇 분 동안 우리가 얻은 교훈들과 이를 어떻게 적용하려고 노력해 왔는지에 대해 이야기하고자 합니다.
00:04:50이것은 아직 끝에 도달한 것이 아니라 여정 중에 있으며, 이러한 여러 방향에서 정말 흥미로운 진전을 목격하고 있습니다.
00:04:57여기 계신 많은 연사분들도 언급하셨겠지만, 검증에 투자하는 것이 아마도 우리 코드베이스에서 가장 가치 있는 일일 것입니다.
00:05:11워크플로에서 인간이 해야 했던 작업을 에이전트가 검증할 수 있도록 언제든 앞당길(left-shift) 수 있다면 말이죠.
00:05:19예를 들어 Playwright MCP가 나왔을 때, 인간이 직접 코드를 탐색하는 대신 이제 에이전트가 코드를 탐색할 수 있게 되었고, 이는 많은 팀의 생산성에 큰 도약을 안겨주었습니다.
00:05:33그것은 우리에게 언제나 큰 성공이었습니다.
00:05:37다른 한편으로 더욱 좋은 점은, 에이전트가 유용하다고 판단한 것을 발견했을 때 시간을 들여 그것을 가져와 결정론적(deterministic) 흐름으로 부호화하는 것입니다.
00:05:51쉽게 반복할 수 있는 결정론적 흐름은 토큰과 시간을 절약해 주며, LLM이 추론을 필요로 할 때만 LLM을 사용하고 있다는 확신을 줍니다.
00:06:01하지만 이미 알려져 있고 기본적으로 테스트로 인코딩할 수 있는 작업이 있다면, 그 시간을 투자하는 것은 언제나 큰 이득으로 돌아옵니다.
00:06:11그리고 또 다른 팁으로, 기술이나 에이전트에 여러분이 작성 중인 코드를 TDD(테스트 주도 개발) 스타일의 레드에서 그린으로 가는 방식으로 작성하라고 지시하면 거의 항상 더 나은 결과를 얻을 수 있습니다.
00:06:26먼저 목표를 설정한 다음 에이전트에게 그 목표를 향해 노력하도록 지시하기 때문입니다.
00:06:30나중에 테스트를 작성하는 것보다 코드를 먼저 작성하게 하는 편이 거의 항상 더 나은 결과를 줍니다. 그러면 검증 기준을 통과하기 위해 코드를 억지로 끼워맞추는 대신 테스트를 코드에 맞출 수 있기 때문입니다.
00:06:42이것은 테스트 피라미드, 즉 이전의 고전적인 테스트 피라미드입니다. 테스트 자체를 생각해보면 엔드투엔드(E2E) 테스트와 통합 테스트, 유닛 테스트가 있었죠.
00:06:54이와 매우 유사하게 가능한 한 많은 부분을 린팅, 컴파일러, 유닛 테스트 같은 결정론적 분석 영역으로 낮추고, 쉽게 커버할 수 있는 부분은 기준에 따라 에이전트가 검토하도록 할 수 있습니다.
00:07:12그리고 이미 정립된 아키텍처 표준들도 마찬가지입니다.
00:07:15코드베이스에 쉽게 인코딩된 아키텍처 표준들을 에이전트에게 이전할 수 있습니다.
00:07:19그리고 맨 꼭대기에서만 기능과 관련된 일종의 인간 검토를 거치면 됩니다. 인간이 실제로 관여해야 하는 일에만 인간이 참여하도록 남겨두는 것이죠.
00:07:31그리고 정말 중요한 또 한 가지는 프롬프팅 대 기획(planning)입니다. 이것은 개발자에게 자율성을 돌려주고 코드 작성의 기술을 대체할 수 있는 대안을 찾는 것과 밀접하게 연결되어 있습니다.
00:07:50따라서 많은 시간을 들여 계획을 작성한 다음, 자동화 가능한 구현 작업으로서 에이전트에게 넘겨주는 방식은 개발하는 즐거움을 프로세스에 다시 불어넣어 준다는 것을 발견했습니다.
00:08:07따라서 매우 상세한 계획을 작성하는 데 일주일을 쓰거나, 모든 결정을 내리고, 구체화하고, 피드백을 주고받는 것은 드문 일이 아닙니다.
00:08:17그리고 모든 준비가 끝나고 결정 사항이 확실해졌을 때만 에이전트에게 전달하면, 에이전트가 구현을 마친 후 다시 돌려줍니다.
00:08:26이 방식은 개발 속도를 높이는 것뿐만 아니라 개발 과정의 즐거움을 되찾는 데도 매우 성공적이었습니다.
00:08:36그렇다면 좋은 계획이란 무엇일까요? 가장 먼저 상단에 '이유(Why)'를 작성하는 것이 매우 중요합니다.
00:08:43설계 문서(Design Doc)를 작성할 때처럼 굵직한 핵심 섹션을 두면 에이전트가 엉뚱한 방향으로 표류하는 것을 방지하는 데 큰 도움이 됩니다.
00:08:49여기에 에이전트를 위한 요약본을 제공해야 합니다. 그렇지 않으면 시간이 지날수록 방향이 흐트러질 수 있으며, 에이전트가 마음대로 임의로 변경하지 못하게 해야 합니다.
00:08:58따라서 '이유'부터 시작하여, 계획이 각각 독립적으로 검증 가능한 작은 부분들로 나뉘어 있는지 확인해야 합니다.
00:09:08적절한 크기를 가늠하는 저만의 기준은 해당 부분에 해당하는 PR을 내가 리뷰하고 싶은가 하는 점입니다. 한 번에 앉아서 리뷰하기에는 너무 커 보인다면요.
00:09:18이걸 읽으려면 먼저 커피 한 잔 마셔야겠다고 생각이 드는 테스트 같은 것이죠.
00:09:22그 말은 너무 크다는 뜻이므로 더 작은 조각으로 쪼개야 한다는 의미입니다.
00:09:26그리고 각 단계가 독립적으로 검증 가능한지 확인합니다. 왜냐하면 5단계가 있는데 1단계가 작성만 되고 검증되지 않은 채, 그 모든 가정 위에 나머지가 전부 구축되는 상황은 절대 피하고 싶기 때문입니다.
00:09:41따라서 각 단계마다 검증 게이트나 예외 기준을 두는 것이 계획이 방향을 잃지 않고 견고해지도록 만드는 데 큰 도움이 됩니다.
00:09:51컨텍스트를 관리하고 그 위에 소프트웨어 팩토리를 구축하는 등 기술적인 방법은 다양합니다.
00:09:58하지만 일단 계획이 마련되면 이를 구현하기 위해 어떤 루프나 워크플로든 원하는 방식을 사용할 수 있습니다.
00:10:05이것은 제가 무작위로 가져온 계획의 스크린샷이지만, 제가 평소에 눈여겨보는 부분은 이렇습니다.
00:10:12상단에 위치한 실행 요약(Executive summary).
00:10:14세부 단계별로 쪼갠 다음, 하위 에이전트에 그대로 집어넣을 수 있도록 각 단계마다 상세한 내용을 작성합니다.
00:10:20그러면 하위 에이전트가 독립적으로 그 작업을 처리하며 다른 걱정을 할 필요가 없어집니다.
00:10:24물론 이 외에도 잘 작동하는 다른 워크플로들이나 다양한 계획 구조가 존재합니다.
00:10:29제가 생각하는 AI 워크플로의 큰 장점 중 하나는 모든 사람이 자신에게 가장 잘 맞는 방식을 직접 설정할 수 있다는 점입니다.
00:10:41아닙니다, 괜찮습니다.
00:10:43누구나 자신에게 딱 맞는 워크플로를 아주 손쉽게 구축할 수 있습니다.
00:10:47따라서 모든 사람을 하나의 방식으로 통일하려는 것은 오히려 수확 체감(효용 감소)을 낳습니다.
00:10:51각자의 작업 흐름에 잘 맞고 다른 팀원들과 원활하게 소통할 수만 있다면 전반적으로 아주 훌륭하게 작동합니다.
00:10:58이것은 하나의 예시이자 자랑 같은 것인데, 계획을 통해 나온 결과물은 대략 이런 모습일 수 있습니다.
00:11:04여기에 아마 20개 정도의 PR이 있을 겁니다.
00:11:07어떤 것은 10줄 정도이고 어떤 것은 100줄 정도이겠지만, 아마 그보다 더 큰 것은 없을 것입니다.
00:11:12이를 통해 -- AI 이전의 세상이었다면 이 계획을 작업하는 데만 일주일이 걸렸을 겁니다.
00:11:19다른 세 팀과 조율하는 데 또 일주일이 걸렸을 테고, 그런 다음 에이전트에게 보내 야간에 구현을 맡겼겠죠.
00:11:26그렇게 돌아온 결과물은 -- 아마 하나의 계획이 아니라 두 개의 계획에서 나온 거겠지만 -- 기본적으로 6주어치의 코딩 작업이 단 일주일 만에 끝난 것입니다.
00:11:36제가 5배의 속도 향상을 얻었다고 말하는 이유가 바로 이것입니다.
00:11:40물론 항상 염두에 두어야 하는 마지막 단계의 리뷰 주기를 포함하더라도 말이죠.
00:11:45계획 세기에서 넘어가서, 회의론자들과 가장 많은 업무 부담을 안고 있는 사람들이 겪었던 문제로 다시 돌아가 보겠습니다.
00:11:53그들을 논의에 꼭 참여시키고 그들의 피드백을 매우 진지하게 받아들이세요.
00:11:59그들이 회의적인 이유는 여러분의 검증이 부족한 부분과 도구가 실패하는 지점을 정확히 보고 있기 때문입니다.
00:12:05따라서 그들의 피드백은 에이전트를 개선하고 코드베이스와 상호작용하는 방식을 발전시키는 로드맵 그 자체입니다.
00:12:12어떻게 하면 그들에게 AI를 쓰게 만들 수 있을지 고민하기보다, 그냥 그들을 이 과정에 끌어들이세요.
00:12:19조직 내에서 AI를 안전하게 만드는 로드맵의 책임자를 그들에게 맡기는 겁니다.
00:12:25그러면 그들이 만드는 개선 사항들이 실제로 자신의 삶을 더 낫게 만들고 있다는 것을 깨닫는 순간 자연스럽게 동참하게 될 것입니다.
00:12:33보시다시피, 그들은 무엇을 고쳐야 하는지 말해주는 데 전혀 주저하지 않을 겁니다.
00:12:37이것은 여러 사람들과 함께 단 한 시간도 안 되어 앉아서 진행한 결과입니다.
00:12:40그리고 이것이 바로 브레인스토밍의 결과물입니다.
00:12:45제 팀에서 특히 유용했던 또 다른 방법은 -- 현재 더 넓은 조직으로도 채택하기 위해 노력하고 있는 것인데요 --
00:12:53바로 '주의력 인지 커뮤니케이션(Attention-aware communication)'을 실천하는 것입니다.
00:12:58AI 시대에 인간의 주의력은 희소 자원입니다.
00:13:01여러 강연에서도 들었고, 많은 사람들이 똑같은 결론에 도달했다고 생각합니다.
00:13:06더 많은 사람의 주의력을 얻을 수 있습니다.
00:13:08따라서 어디에 시간을 쓰고 무엇을 읽고 있는지가 정말 중요해집니다.
00:13:13이것은 매우 부족한 자원인 만큼, 무엇이 AI로 생성되었고 무엇이 사람이 작성했는지 표시해 두는 것은 이를 읽는 데 시간을 얼마나 써야 하는지 파악하는 데 큰 도움이 되며,
00:13:24통신의 이 부분에서 어느 정도의 깊이를 기대할 수 있는지 알 수 있게 해줍니다.
00:13:31그리고 그것은 일종의 커뮤니케이션 스타일에 대한 새로운 문화를 구축하는 것입니다.
00:13:35정말 큰 도움이 됩니다.
00:13:36예를 들어, 제가 함께 일하는 팀에서는 항상 모든 PR 설명의 시작을 이런 식으로 작성하기로 결정했습니다.
00:13:45제가 직접 손으로 쓴 내용은 이것이 무엇을 하는지 아주 짧게 설명할 수 있고, 그 후에 AI가 작성한 설명이 뒤따르는 식입니다.
00:13:54그저... 아마 읽어보게 될 겁니다.
00:13:55잘못된 부분을 제거하기 위해 수정하겠지만, 팀원이 여기에 모든 줄을 직접 쓴 것은 아닙니다.
00:14:00그러므로 더 의심을 품어야 하고, 상단에 제가 쓴 내용에 더 주의를 기울여야 하며, 이를 덮어써야 합니다.
00:14:05Slack이나 이메일에서도 마찬가지로, 모든 사람이 커뮤니케이션을 작성할 때 AI를 사용한다는 사실을 자연스럽게 받아들이되,
00:14:15어떤 것을 읽어야 하고 어떤 것에 덜 주의를 기울여야 하는지 말하는 것을 부끄러워하지 마십시오.
00:14:21예전에, 아마 올해 초였을 겁니다, 저는 조직 내의 시니어 엔지니어 중 AI 회의론자가 매우 강한 사람들에게 연락을 시도했습니다.
00:14:35무엇이 문제인지, 어떤 상황인지 알아보려고 그들에게 연락해 당신이 남긴 PR 코멘트 중 일부를 분석해 보려고 했다고 말했습니다.
00:14:42물론 저는 그것을 하기 위해 AI를 사용했습니다.
00:14:45그리고 제가 쓴 것과 AI가 생성한 것을 명확하게 구분하지 않았고, 그들은 매우 화를 냈습니다.
00:14:54그들은 이렇게 말했습니다. 왜 이런 걸 보내는가, 내가 이렇게 존경하는 사람이 분명히 이렇게 엉성한 것을 보낼 것이라고는 기대하지 않았다.
00:15:02그래서 저는... 사과했습니다.
00:15:05명확하게 표시하고 제 의도를 드러냈어야 했다는 것을 깨달았습니다.
00:15:08이것은 내가 쓴 것이다.
00:15:10이것은 AI가 쓴 것이며, 이것이 엉성한지 아닌지 알 수 있는 맥락이 없기 때문에 당신의 피드백이 필요하다고 말입니다.
00:15:15그리고 그것이 바로 제가 여러분에게 부탁하는 것입니다.
00:15:17따라서 이러한 교훈과 문화의 변화는 우리가 직면해 온 엔지니어링 과제만큼이나 중요합니다.
00:15:28도입과 관련해서 정말 도움이 되는 또 다른 점은, 도입이 진행됨에 따라 우리가 구현해 온 아주 멋진 도구와 워크플로우가 많이 있다는 것입니다.
00:15:41하지만 진정으로 효과적인 방법 중 하나는 사람들이 있는 그 자리에서 바로 AI를 사용하도록 하는 것입니다.
00:15:47그렇게 하면 일상적인 작업에서 AI 사용을 정상화하는 데 진정으로 도움이 되고 마찰을 줄여줍니다.
00:15:54그리고 진정으로 가장 강력한 기능 중 하나는 Slack 메시지에서 누군가와 함께 에이전트를 태그하고 이렇게 말하는 것입니다. 내 대신 이거 좀 해줄 수 있어?
00:16:02그리고 에이전트가 스레드에서 원스톱으로 처리를 완료하도록 하는 것입니다?
00:16:07그런 종류의 일은 정말 강력합니다.
00:16:09그런 다음 그 위에 모든 것이 자동화되도록 하고 온갖 멋진 것들을 추가할 수 있습니다.
00:16:14하지만 완전히 동의하지 않는 사람과 대화 중일 때, 수동 공격적이지 않은 방식으로 태그하면서 이렇게 말할 수 있습니다. 이번에는 에이전트가 이걸 해낼 수 있는지 한번 시도해 보자고.
00:16:26그리고 그들이 처리를 완료하고 좋은 경험을 하게 된다면, 다른 경우에도 스스로 직접 시도해 보는 데 진정으로 도움이 됩니다.
00:16:33그리고 우리의 여정은 계속됩니다.
00:16:37우리는 외부로 AI를 출시하고 있음에도 여전히 배우고 있으며, AI 도입을 진행 중이고, 자동화 스토리가 아직 완전히 갖춰지지 않은 상태에서 항상 수많은 것들을 실험하고 있습니다.
00:16:50일부 빌드 시스템에 존재하는 모든 종속성을 고려할 때, 언제 클라우드 에이전트를 사용해야 하는지, 어떻게 효과적으로 사용할 수 있는지 여전히 파악하려 노력하고 있습니다.
00:16:58그래서 우리는 계속해서 배워나가는 중입니다.
00:17:01이것은 문화적 변화입니다.
00:17:02이것은 엔지니어링의 변화입니다.
00:17:03여러분은 어떠실지 모르겠지만, 저는 지난 15년 동안 실리콘밸리에서 일해 왔고, 문화와 기술 측면에서 제가 목격한 모든 것 중 이것이 자릿수가 다를 정도로 가장 큰 변화입니다.
00:17:16그러니 우리 모두 여기에 함께 있고, 다 함께 알아가는 중입니다.
00:17:19그리고 그것이 오늘 여러분과 이야기하고 싶었던 내용입니다.
00:17:22감사합니다.
00:17:28감사합니다.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video