에이전트형 코딩: 업계 리더와의 라운드테이블

안녕하세요.

이번 주 또는 지난 이틀 동안 많은 Android Google 직원으로부터 이야기를 들으셨습니다.

그래서 Android 개발자 커뮤니티의 외부 인사들의 이야기를 들으며 컨퍼런스를 마무리하면 정말 좋겠다고 생각했습니다.

에이전트 코딩과 그 실제 영향에 대해 이야기해 보겠습니다.

먼저 저희를 소개하겠습니다.

저는 Android DevRel의 벤입니다.

이번 컨퍼런스에서 이미 제 이야기를 들으셨지만, 패널을 따라 내려가 보겠습니다.

여러분, 안녕하세요.

제 이름은 비나이이며 Databricks에서 AI 도구 지원 업무를 담당하고 있습니다.

뵙게 되어 반갑습니다.

안녕하세요, 루이스 아르톨라입니다.

저는 Google 지도에서 일하고 있습니다.

저는 AI를 사용하여 에이전트 환경을 구축하고 소프트웨어 개발 주기를 개선하는 팀을 이끌고 있습니다.

안녕하세요, 저는 애니스 데이비스입니다.

Ford에서 일하고 있어.

저는 구독 및 포인트 멤버십 제품을 개발하는 엔지니어링팀을 이끌고 있습니다.

여러분, 안녕하세요.

저는 타이 스미스입니다.

Uber에서 개발자를 지원하고 있습니다.

모바일은 오랫동안 사용되어 왔습니다.

지난 몇 년 동안 AI 도구와 함께하는 이 흥미로운 새로운 시대에 많은 관심이 집중되었습니다.

여러분, 안녕하세요.

저는 카우식 고팔입니다.

저는 Instacart에서 수석 엔지니어로 일하고 있으며, Android 개발에 관한 Fragmented라는 팟캐스트를 시작했습니다.

요즘에는 타이의 말처럼 전략을 조금 바꿔서 AI 개발에 대해 이야기하고 있습니다.

좋습니다.

30분 정도 시간이 있습니다.

시간이 빠르게 지나갈 것 같으니 바로 핵심 질문으로 들어가겠습니다.

Android DevRel에서는 항상 앱을 더 빠르고 쉽게 빌드할 수 있도록 지원하고자 노력해 왔습니다.

이제 AI가 등장했고, 저희는 "정말 그렇습니다.

앱을 더 빠르고 쉽게 빌드할 수 있다고 생각합니다."

하지만 실제로 앱을 더 빠르게 출시하고 있는 것일까요? 아니면 아무런 쓸모가 없는 코드를 대량으로 생성하고 있는 것일까요?

비나이, 시작해 볼까요?

좋습니다.

네, 모두가 서로를 바라보고 있습니다.

멋지네요.

따라서 순수한 수치만 보면 PR, 코드 줄 수 측면에서 출력이 크게 가속화되었으며, 그 결과 코드를 저장하는 위치와 같은 문제에서도 확장성 문제가 발생하고 있습니다.

이러한 가속화는 매우 현실적입니다.

명확하지 않은 것은 이것이 결과에 미치는 영향입니다. 업계 전체가 결과와 관련된 올바른 측정항목이 무엇인지, 이것이 순이익에 미치는 영향을 어떻게 파악할 수 있는지 알아내기 위해 노력하고 있다고 생각합니다.

하지만 실제로 사용되고 있는 것은 분명합니다.

지난 6개월 동안 이전보다 더 많은 코드를 출시한 것 같습니다. 다시 말씀드리지만, 이 부분은 모호하게 유지하겠지만, 매우 긴 기간처럼 느껴집니다.

그 결과 생산성을 측정하는 방법에 대한 전략도 바뀌었다고 생각합니다.

다양한 방식으로 생각해 볼 수 있기 때문입니다.

중앙값을 높이는 방법을 알아내려고 하는 거죠?

이상치와 중앙값을 살펴보면 이 두 범주의 사람들 사이에 5~10배의 차이가 있기 때문에, Google은 하한선을 높이고 중앙값을 높여 이 사람들을 주변의 동료만큼 생산적으로 만드는 데 집중하고 있습니다.

여러 역할이 조합되어 있습니다.

일부 사람들은 훨씬 더 빠르게 움직이고 있습니다.

하루에 100개의 PR을 처리하는 사람들도 있는데, 정말 대단한 일입니다.

하지만 이들이 활동하는 공간은 그런 유형입니다.

이러한 고객은 신규 고객이거나 도구에 더 익숙한 고객일 수 있습니다.

또한 브라운필드나 플랫폼 작업에 더 많이 참여하는 사람들도 있으며, 이들은 인간의 판단에 더 많은 시간을 할애하고 문제가 발생하지 않도록 해야 하기 때문에 가속화되지 않을 수 있는 다른 유형의 작업을 지원합니다.

이 두 가지를 결합하면 이전보다 훨씬 빨라지지만, 우리에게 정말 흥미로운 주제는 더 많이 배포하고 있음에도 불구하고 비즈니스가 실제로 최종 사용자에게 더 많이 배포하고 있는지 여부입니다.

이 부분은 Google이 지난 1년 동안 투자해 온 영역으로, 단순히 코드를 더 빨리 출시하는 것이 아니라 기능을 더 빨리 출시하고 있는지 파악하기 위한 것입니다.

초기 신호는 그렇다고 말하지만, 순수한 PR과는 매우 다른 모습입니다.

제가 보기에 분명한 것은 사람들이 훨씬 더 많은 PR을 제출하고 있다는 점입니다. 그 수가 증가했습니다.

하지만 지금도 많은 사람들이 'AI와 우리가 가진 도구를 활용해 기존 프로세스를 어떻게 강화할 수 있을까?'라고 생각하는 것 같습니다.

그렇죠?

이전에는 코드를 배포할 때 항상 사람이 프로덕션까지 모든 과정을 관리하는 것으로 생각했습니다.

하지만 지금은 그런 방식이 효과가 있다는 것을 알 수 있습니다.

더 많은 제품을 출시하고 있습니다.

하지만 이전에는 볼 수 없었던 모든 병목 현상이 발생하고 있습니다.

과거에는 이러한 문제가 발생하지 않았지만, 이제는 여러 단계로 구성된 주기의 한 부분을 가속화하고 있으며, 이 부분이 흥미로워지고 있습니다.

더 많은 효과를 제공하고 있지만, 이제는 효과가 쏟아져 나오는 것 같습니다."

따라서 다른 문제에 직면하게 됩니다.

매우 흥미로운 점입니다. 생각해 보면 여러 단계가 있지만, 높은 수준에서 보면 세 단계로 분류할 수 있습니다.

코딩은 확실히 가속화되고 있습니다.

법률, 개인 정보 보호, 제품 출시를 위한 준비 등 다양한 요소를 포함하는 프로덕션 준비 상태가 있고, 그 다음에는 출시가 있습니다.

배송은 거주 지역에 따라 의미가 다릅니다.

완전한 서버 측 제품이라면 출시가 더 간소화된 프로세스를 의미할 수 있지만, 소비자에게 제공되는 제품을 출시할 때는 실험 단계가 여정의 중간 단계에 불과합니다.

여전히 많은 실험과 측정을 해야 합니다. 이 부분은 말씀하신 내용과 관련이 있습니다. 고속도로를 달리는 대도시에서 병목 지점을 지나 가속하기 시작하면 "좋아, 이제 속도를 내자"라고 생각하는 것과 같습니다.

정말 빠르게 진행되고 있어'라고 생각하지만 이제 다음 초크 포인트에 도달합니다.

AI가 분명히 보여주는 것은 마찰 지점이 더 명확하게 보인다는 점이며, 그중 일부는 코딩이나 기술과 아무런 관련이 없습니다.

프로세스, 사람, 그리고 AI를 통해 이를 최적화하는 방법과 관련이 있습니다.

이는 엔드 투 엔드를 간소화하는 방법에 관한 매우 흥미로운 과제입니다.

이 분야에 대해 흥미롭게 생각하는 점은 개인이나 팀이 제품을 완전히 출시하는 데 얼마나 많은 주체성을 가지고 있는가입니다.

내부적으로 살펴보면 내부 도구를 빌드하거나 고객에게 제공되지 않는 도구를 빌드하는 팀이 많습니다.

배송이 훨씬 빨라졌죠?

고객에게 즉시 제공할 수 있는 전적인 권한이 있습니다.

외부 제품이 있는 경우 사용자를 대상으로 실험을 진행하거나, 앱 스토어 출시 시간을 고려하거나, 디자인 및 제품팀과 협업해야 하는 등 다양한 병목 현상이 발생할 수 있습니다. 이로 인해 코드를 작성하는 개발자가 빠르게 움직일 수 있는 여지가 줄어듭니다.

따라서 시스템의 나머지 병목 현상에 부딪히게 됩니다.

따라서 이 두 가지를 서로 다른 영역으로 분할하면 비즈니스 프로세스를 개선할 수 있는 부분을 명확하게 파악할 수 있습니다.

네, 동의합니다. 솔직히 엔지니어링은 결코 병목 현상이 아니었다고 생각합니다.

몇 년 전부터 했던 말이긴 한데

엔지니어링은 일을 처리하는 방식이 매우 정형화되어 있으며, 항상 비즈니스 측면에서 '문제가 무엇인가?'를 생각합니다.

10가지의 다른 답변을 얻게 됩니다.

그런 다음 '알겠습니다.

이제 이를 제품을 사용한 솔루션으로 전환해 보겠습니다.

이제 잠시 생각해 보겠습니다.

디자인에 관해 이야기해 볼까요?

저쪽으로 차."

엔지니어링 단계에 도달할 때쯤에는 무엇을 해야 하는지 어느 정도 알고 있었습니다.

그런 다음 Stack Overflow로 이동하여 몇 가지를 복사하여 붙여넣고 배포합니다.

AI를 통해 가장 큰 속도 향상을 경험하는 부분은 규정 준수 작업입니다.

XYZ를 현대화하고 싶었거나 Spring Boot 버전을 빠르게 업그레이드하고 싶었던 것들 말입니다.

우리는 이 작업을 매우 빠르게 진행하고 있습니다.

하지만 실제 기능 제공 측면에서는 크게 개선된 점을 보지 못했습니다.

병목 현상이 이동했을 수 있고, 이전에는 병목 현상이 아니었지만 이제는 병목 현상이 된 프로세스에 직면하고 있다는 점을 모두 언급하셨습니다.

하지만 이러한 프로세스는 과거의 힘든 경험에서 얻은 교훈에서 비롯된 것이겠죠?

그렇다면 이러한 관행을 바꿔야 한다는 압박감을 느끼고 계신가요? 가장 대표적인 예가 코드 검토라고 생각합니다.

코드 검토의 미래는 어떻게 될까요?

현재 Google의 조치

네, 듣고 싶습니다.

제가 말씀드린 요점으로 돌아가 보겠습니다.

이러한 병목 현상의 대부분은 우리가 생각한 방식 때문이라고 생각합니다. 예를 들어, 마법 지팡이가 있어서 소프트웨어 엔지니어링을 재창조할 수 있고, 오늘날 AI가 있다면, 우리는 같은 것을 많이 사용할까요? 같은 일을 할까요?

예를 들어 코드 검토는 최종 교차 확인과 같은 작업을 수행하기 위해 사람이 필요했기 때문입니다.

이 부분도 변화하고 있다고 생각합니다. 예를 들어, 현재 코드 검토에 대한 우리의 생각은, 이름을 리팩터링하거나 코드를 리팩터링하려고 할 때, 그리고 모두가 분명히 가지고 있는 훌륭한 테스트가 있다는 것을 알고 있을 때,

AI가 작성해 주니까 괜찮습니다.

아니요, 예를 들어 그 상담사보다 더 잘할 수 있을까요?

잘 모르겠어요. 검토하는 데 시간을 쓰지 않는 게 좋을 것 같아요.

버그를 배포하고 CEO로부터 "이 버그로 인해 X달러의 손실이 발생하고 있습니다"라는 전화를 받는다면, "이 부분은 중요한 영역입니다.

이건 중요한 영역이 아니야'라고 말한 다음 다시 상상해 보세요.

오늘날에는 그렇게 운영되지 않는 것 같습니다.

오늘날에는 'PR이 있습니다.

저는 엔지니어입니다.

이 일에 집중하고 있어.

올라갈 것입니다.

이걸 병합하고 싶어서 한밤중에 비나이에게 코드 검토를 부탁하기도 해요."

반면, 이러한 것들을 다시 생각해 봐야 할 수도 있습니다.

전적으로 동의합니다. 저는 코드 검토를 검증 문제로 생각합니다. 무슨 말이냐면, 제가 무언가를 검증하는 능력에 완전히 자신이 있는 세상에서도 여전히 제 PR의 100% 를 코드 검토할까요?

아마 그렇지 않을 것입니다.

따라서 코드 검토에는 두 가지 목적이 있습니다.

하나는 우리가 올바른 일을 하고 있는지 확인하는 것이고, 두 번째는 교육입니다.

주변 사람들이 내가 무엇을 하고 있는지 알고 있으며, 그 결정에 동의하는지 여부와 같은 것들입니다.

따라서 가속화하고 코드에 반영하고 출시까지 진행해도 괜찮은 작업 카테고리가 분명히 있습니다.

모든 케이스에 적용되지는 않겠지만, 상당히 높은 비율로 적용될 것으로 생각합니다.

이제 이러한 변화에 대비해야 할 때입니다. 커뮤니티 전체가 시스템을 준비해야 합니다. 변화는 곧 다가올 테니까요.

다른 방법은 없습니다.

상위 유입경로가 매우 넓고 다양한 표시 경로가 있어 더 많은 PR을 만들 수 있습니다.

그리고 프로세스의 가장 느린 단계만큼 빠릅니다.

많은 팀에서 코드 검토가 바로 이러한 병목 현상에 해당하며, 더 빠르게 움직이는 팀은 이러한 현실을 파악하고 받아들였습니다.

네, 솔직히 말해서 제가 본 PR의 70% 는 괜찮아 보입니다.

전 세계의 모든 코드베이스를 검색하면 PR 댓글은 전반적으로 '괜찮아 보입니다', LGTM일 것입니다.

엔지니어링 전문가로서 우리는 때때로 실제보다 더 많은 공을 자신에게 돌리기도 합니다.

우리는 정말로 우리가 그 안에 있는 것 같다고 생각합니다.

"명령 패턴을 사용했나요?"

아니요. '알겠습니다.

좋아 보이네요."

그렇다면 에이전트가 이 작업을 수행하도록 할 수는 없을까요?

미래에는 '나에게 좋아 보이는 것', '어떤 특성', '어떤 행동이 나에게 그런 느낌을 주었는지'를 파악하는 것이 중요해질 것이라고 생각합니다.

그런 다음 상담사가 동일한 내용을 확인하도록 합니다.

반대로 검토하는 다양한 방법도 생각해 보세요.

요즘 트위터에서 이런 말을 하는 사람들이 있더라고요.

예를 들어 지금 PR을 확인할 때 에이전트가 다른 방식으로 시각화하도록 할 수 있습니다.

이전 사진을 보여 줘.

'after'를 보여줘.

코드를 한 줄씩 검토하는 대신 작성한 테스트를 보여주세요.

하지만 루이스, 뭔가 말씀하시려고 하셨나요?

아니요, 생각할 거리를 던져주는 것 같아요.

예를 들어 CL이나 PR을 사람의 개입 없이 처리해도 안심할 수 있는 수준에 도달할 것입니다.

제가 반론을 제기해 보겠습니다. 마찰에 대해 이야기할 때 마찰은 나쁜 것이라고 생각하는 경향이 있지만 좋은 마찰과 나쁜 마찰이 있습니다.

리뷰는 여전히 긍정적인 마찰에 속한다고 생각합니다.

개발자의 부담을 어떻게 줄일 수 있는지가 관건입니다.

그리고 때로는 그 시점에서 어떻게 하면 검토를 더 효과적으로 또는 효율적으로 할 수 있을까가 문제가 아닙니다.

AI를 사용하여 업스트림 개발을 더 정확하게 만드는 방법입니다.

AI를 어떻게 사용하느냐에 따라 달라지기 때문입니다. 좋은 입력을 제공하면 더 나은 결과물이 나오지만, 나쁜 입력을 제공하면 정말 엉망인 결과물이 나오죠.

따라서 매력적인 최종 상태에 도달하려면 처음부터 AI를 사용하여 아키텍처를 더 잘 이해하고, 개발자의 노력을 줄이면서도 견고한 사양을 갖추어 생성되는 코드의 품질을 높이는 등 AI를 통해 프로세스를 전체적으로 개선해야 한다고 생각합니다.

따라서 개발자의 검토 과정이 더 원활해집니다.

논란의 여지가 없는 최종 상태는 대부분의 사람들이 결국 이 모든 코드가 사람의 검토 없이 배포될 것이라고 생각하는 것입니다.

그동안 모델이 개선되는 상황이 계속되고 있으며, 기술적 실수를 저지르는 것에 대한 우려는 줄어들고 비즈니스 실수를 저지르거나 판단이나 아이디어 구상에 문제가 생기는 것에 대한 우려가 커지고 있습니다.

따라서 검토 단계에서 이를 분리해야 하는 신호에도 포함됩니다.

PR에서 한 줄씩 검토해야 할까요, 아니면 푸시하려는 의도를 검토해야 할까요?

몇 가지 다른 방식으로 생각해 볼 수 있습니다.

하나는 사용자에게 더 관련성 높은 정보를 제공하여 우선순위를 정할 수 있도록 하는 방법입니다.

다른 하나는 이러한 프로그램에서 실험하고 더 빠르게 움직일 수 있는 더 안전한 영역은 무엇인가요?

카우식이 말했듯이 모든 영역에 동일한 수준의 엄격함이 필요한 것은 아닙니다.

이를 식별하여 일부는 더 빠르게 진행하고, 위험을 낮추면서도 규정 준수 지향적이거나 매우 기본적인 영역은 더 높은 마찰을 유지할 수 있습니다. 모델뿐만 아니라 모델에 입력되는 데이터까지 신뢰할 수 있는 지점에 도달할 때까지 말이죠.

올바른 결정이었습니다.

Uber 앱에서 새 Android 모듈을 리팩터링하는 것처럼 괜찮을 수도 있습니다.

모든 Android 개발자에게 무료 탑승을 제공하고 있으니 코드를 확인해 보세요.

CEO에게 확인해 봐야 합니다.

죄송합니다, 카우식님.

하지만 이 문제는 이미 해결되었다고 생각합니다.

이미 기능 플래그가 있습니다.

이미 블루-그린 배포를 사용하고 있습니다.

이미 많은 부분을 갖추고 있습니다.

너무 바빠서 제대로 할 수 없다는 것이 문제입니다.

이미 행동 추적을 사용하고 있습니다.

이러한 모든 종류의 데이터가 있지만 모두 서로 다른 시스템에 있습니다.

이미 사고를 추적하고 있습니다.

데이터가 너무 많지만 이를 하나의 포괄적인 추적으로 통합하는 부분이 누락되어 있습니다.

이러한 다양한 회사에서 엔지니어링 컨텍스트 서비스가 어떤 모습인지 파악하고 나면 PR이 병합되더라도 안전하므로 더 이상 걱정할 필요가 없습니다.

기능 플래그 뒤에 숨겨져 있다는 것을 알고 있기 때문입니다.

블루-그린 배포가 있습니다.

모든 모니터링 가능성이 갖춰져 있습니다.

그러면 "파이프라인에 넣어 주세요"라고 자신 있게 말할 수 있습니다.

문제가 발생하면 그 과정에서 모든 가드와 게이트가 있습니다.

대응 속도도 정말 중요하다고 생각합니다.

예를 들어 Android를 예로 들어보겠습니다. Android에서 변경사항을 배포하고 이를 Play 스토어를 통해 배포한 후 소비자에게 배포해야 하는 경우, 내부 배포와 내부 모니터링 가능성, 즉각적인 에이전트가 있는 경우에 비해 즉각적인 핫픽스 기능이 크게 제한됩니다. 이 경우 더 빠르게 움직일 수 있는 기회가 훨씬 더 많습니다.

그래서 제가 여러분께 드리고 싶은 질문 중 하나는, 이러한 앱에서 수행해야 하는 작업이 있지만, 더 쉬운 그린필드 앱이 있고, 브라운필드 앱이 있으며, AI 사용을 확산하기 위해 이러한 검사를 많이 수행하는 데 시간이 필요한 순간이 있다는 것입니다.

많은 분이 대규모 앱을 개발하고 계시죠?

이에 대해 어떻게 생각하시는지 궁금합니다.

CEO에게 3개월 정도 시간을 달라고 해서 앱을 AI에 맞게 준비하는 건가요? 아니면 매일 추가하는 건가요?

네.

어차피 그런 일은 일어나지 않습니다.

아닌 것 같습니다.

대부분의 회사는 그런 호사를 누리지 못합니다.

기술 부채를 처리할 때처럼 시간을 할애해야 한다고 생각합니다. 예를 들어 시간의 20% 를 이 작업에 사용하고, 그중 5% 를 프롬프트 개선에 사용하는 식입니다.

프롬프트가 무엇을 하는지 이해하고 맥락을 개선할 수도 있습니다.

지금까지 이야기한 것처럼, 엔지니어들이 아직 AI의 작동 방식을 이해하지 못하는 것이 큰 이유라고 생각합니다.

여전히 마법 같고 신비롭게 느껴지기 때문에 최고의 가치와 효율성을 얻을 수 있는 방식으로 구성하고 조정하지 못하고 있습니다.

따라서 리더는 '팀의 수준을 높여 이 기술의 작동 방식을 이해하고 더 많은 것을 얻으려면 어떻게 해야 할까?'라고 자문해야 하는 시점이 있다고 생각합니다.

또한 연속성이 있습니다.

기술이 너무 빠르게 변화하고 있기 때문에, 만약 제가 팀에게 지금 당장 일주일 동안 최신 기술을 배우고 이를 실무에 적용하라고 요청한 후, 그들이 계속해서 배우거나 실험할 시간이 없어서 내년에 다시 확인해 본다면, 그들은 새로운 기능에 비해 크게 뒤처져 있을 것입니다.

따라서 비행기를 날리면서 동시에 비행기를 만드는 것과 같은 상황입니다. 안전장치를 마련하고, 학습하고, 상황이 발생함에 따라 조정하고 있으며, 팀은 이 모든 것을 파악하고 있어야 합니다.

대규모 조직에는 이러한 정보를 정리하여 좀 더 관련성 있고 이해하기 쉽게 만드는 팀이 있습니다.

하지만 이는 현재 업계의 모든 사람이 직면한 과제입니다.

조금 변화를 주고 싶어요.

여러분 중 많은 분이 개발자 인프라와 같은 분야에서 일하고 계십니다.

수천 개의 PR이 있으면 테스트 인프라, 서버가 모두 녹아내리나요?

그리고 여러분의 무용담도 듣고 싶습니다.

Ty?

예.

대단하네요.

내 CI는 매일 밤 나를 울려.

현재 거의 모든 개발자 인프라팀이 컴퓨팅 확장 문제와 효율성 문제로 어려움을 겪고 있습니다.

코드 레드가 진행 중입니다.

엄청난 양의 거래량 증가를 목격합니다.

에이전트와 함께 아키텍처를 변경하고 있습니다.

Bazel을 사용하여 원격 빌드 실행 및 캐싱을 최대한 빠르게 확장하려고 노력하고 있습니다. 예를 들어 모든 메인이 항상 정상 상태여야 하는지, 특정 영역에서 에이전트를 사용하여 사전 수정을 시작할 수 있는지, 엔지니어로부터 들어오는 작업량을 살펴보고 자가 복구 CI나 피드백 루프 단축과 같은 작업을 시도하고 있습니다. 모든 팀이 이러한 모든 작업에 적극적으로 투자하여 효율성을 어느 정도 유지하면서 성장에 발맞추려고 노력하고 있습니다.

하지만 매우 어렵습니다.

네, 타이의 말에 전적으로 동의합니다. 하지만 이 시점부터 10배로 성장한다면 우리가 준비가 되어 있는지 솔직하게 자문해 봐야 한다고 생각합니다.

대부분의 사람들에게 이 질문에 대한 답은 '아니요'일 것입니다.

따라서 미래를 생각할 때 인프라가 지원할 수 있는 규모에 맞춰 목표를 설정하려고 합니다.

AI가 한 일 중 하나는 우리 모두를 더 야심 차게 만들었다는 것입니다. 이미 의미 있는 도약을 보았기 때문에 우리는 솔직히 시스템을 다시 생각하고 있습니다.

맞습니다. 어떤 다른 시스템이 고장날지, 또는 고장날 것으로 예상되는지, 그리고 놀라지 않도록 미리 대비할 수 있는 방법은 무엇인지 생각하고 있습니다.

실제로 Google은 예상치 못한 상황을 방지하려고 노력하고 있습니다.

맞습니다. 우리가 통제하고 있다고 느끼는 한 모두가 행복합니다.

예상치 못한 상황이 발생하는 순간 모두에게 나쁜 소식이 될 수 있습니다.

그렇죠?

따라서 지금은 되돌아보고, 감사하고, 다음에 무엇이 무너질지 파악하기에 좋은 시점입니다.

피할 수 없는 일입니다.

미리 대비하고 싶을 뿐입니다.

Inflow의 CEO가 한 흥미로운 말이 있습니다.

Google이 현재 보유한 수십억 줄의 코드를 작성하는 데 걸린 기간을 설명하고 있었는데, 약 20년이 걸렸다고 합니다. 하지만 AI의 가속화로 인해 많은 기업이 단 몇 년 만에 비슷한 규모를 달성할 수 있을 것으로 보입니다.

모든 회사가 개발을 위해 Google 수준의 인프라를 갖출 준비가 되어 있는 것은 아니라고 생각합니다.

그렇다면 귀사에서는 지출 한도를 설정하고 있나요?

예를 들어, 모든 작업에 토큰을 소모하는 개발자들을 어떻게 관리하시나요? 항상 가장 좋은 모델을 사용하도록 하는 건가요?

어떤 전략을 찾으셨나요? 아니면 실험을 통해 좋은 결과를 얻을 수 있으니 그냥 자유롭게 두는 것이 더 나은가요?

작년은 실험의 해였다고 할 수 있습니다.

모든 작업을 수행합니다.

올해 상반기까지는 합리적으로 사용하기만 하면 됐습니다.

9월부터는 토큰 한도가 적용됩니다.

따라서 개발자에게 토큰 사용량에 대한 제한이 있습니다.

그리고 건강하고 유익한 세션을 진행하고 있는지 파악할 수 있도록 계측 기능도 제공합니다.

건전한 세션이란 무엇을 의미하나요?

세션당 이 정도의 대화가 이루어지나요?

차례란 무엇인가요?

따라서 도구를 사용하여 개발자를 교육하려고 노력하고 있습니다.

이는 첫 단계에 불과합니다.

문제를 해결하려면 먼저 문제가 있다는 것을 알아야 합니다.

따라서 이 콘텐츠를 보는 것은 무료가 아니라는 점을 알 수 있습니다.

이전에는 AI가 무료인 것처럼 느껴졌습니다.

사람들은 그냥 사용하고 있었습니다.

'브랜치를 변경해 줘'라고 하면 '네, 아니스님, 5달러에 브랜치를 변경해 드릴게요'라고 하는 거죠.

이제 '명령줄로 가서 직접 할 수 있겠네'라고 생각하는 단계에 이르렀습니다.

따라서 엔지니어에게 실제 비용에 대한 교육을 시작해야 할 것 같습니다.

ECS 인스턴스를 생성하고 그냥 방치하는 것과는 다릅니다.

AWS가 처음 나왔을 때 우리는 '그래, 내 인스턴스를 사용할 수 있어'라고 생각했을 것입니다.

회사에 엄청난 비용을 초래하고 있었죠.

지금 토큰에서도 같은 일이 일어나고 있다고 생각합니다.

실질적인 한계도 매우 흥미로운 기회를 제공한다고 생각합니다.

처음에 LLM을 사용하기 시작했을 때는 모든 것을 LLM에 던졌습니다.

코드를 검사하고, 문제를 파악하고, 마법을 부리는 것 같죠?

하지만 그에 따른 비용이 발생했습니다.

그리고 업계에서도 이 사실을 깨닫고 있습니다.

이로 인해 개발자와 조직은 이를 최적화하는 방법을 고민해야 합니다.

그 이유는, 예를 들어 구체적인 예를 들어보겠습니다. 사용자 인터페이스 구성요소를 생성하는 생성기가 있고, 이 구성요소가 특정 구조와 단위 테스트 등을 준수해야 하는 경우, 모델이 이를 즉석에서 생성하도록 하는 대신, 이를 생성할 수 있는 결정론적 도구를 생성하도록 하는 것이 더 낫지 않을까요?

따라서 토큰 및 사용량 한도를 유리하게 활용하여 실제로 더 효과적으로 작업할 수 있는 기회가 많습니다.

예, 그리고 이러한 주제에 따라 Instacart에서는 적어도 제한을 도입했습니다.

하지만 목표는 AI 사용량을 제한하는 것이 아니라, 일종의 위생을 가져오거나, 말씀하신 것처럼 성찰을 가져오는 것이라고 생각합니다.

예를 들어 어떤 경우에 특정 모델을 사용해야 하는지, 어떤 경우에 다른 모델을 사용해야 하는지 등을 설명합니다.

시간을 알려주거나 Git 브랜치를 변경하는 데 Fable이나 Astra가 필요하지는 않을 것입니다.

그렇죠?

시간을 들여 스크립트를 작성하면 영구적으로 무료로 사용할 수 있습니다.

토큰이 낭비되지 않습니다.

그렇죠?

따라서 제약 조건이 사용을 제한하기 위한 것이 아니라 모든 것을 한꺼번에 처리하는 것 이상의 생각을 할 수 있도록 돕기 위한 것이라는 점을 추가할 수 있다면 좋을 것 같습니다.

그렇죠?

말씀하신 것처럼 작년은 실험의 해였던 것 같습니다.

올해는 이 기술을 어떻게 효과적으로 사용할 수 있을까에 대한 고민이 많습니다.

네.

여기에 있는 이야기도 많은 공감을 불러일으킵니다.

특히 실험을 더 많이 하는 것에서 효율성과 책임의 균형을 맞추는 것으로 전환하는 과정에서 말이죠.

이는 다양한 투자에서 비롯됩니다.

개발자 교육과 가시성 같은 것들이 있습니다.

애니스가 활성 세션 비용과 정보에 대해 이야기한 것처럼요.

안전한 기본값과 같은 투자는 불필요한 상호작용을 방지하고, 사용 중인 기술이 회귀 및 관련 문제를 효율적으로 찾을 수 있도록 합니다.

지출 비용에 대한 책임도 부여합니다.

토큰 한도가 있습니다.

개발자가 한도에 도달하면 버튼을 한 번 클릭하고 사유를 입력하면 관리자가 승인할 수 있습니다.

따라서 훌륭한 작업이 진행 중이라면 해당 작업을 거치도록 하고 싶습니다.

하지만 낭비가 심하거나 실험적인 작업을 하는 경우, 관리자에게 해당 작업에 비용을 지출해야 하는 이유를 정당화할 수 없으므로 이를 억제하는 데도 도움이 됩니다.

그 결과, 작업을 수행하지 않을 뿐만 아니라 '이것이 올바른 모델 선택인가?'라고 생각하게 됩니다.

이 무게가 맞나요?

경쟁 압박으로 인해 이러한 토큰의 비용이 감소하기 시작했습니다.

하지만 일반적으로 엔지니어들이 이 문제를 고민하는 것은 Google이 제공하는 자금을 잘 관리하는 것이며, 실시간으로 이것이 올바르고 건전한 접근 방식이라고 생각합니다.

장기적으로는 이러한 결정을 내릴 필요가 없도록 하는 것입니다.

그렇죠?

자동 모델 라우팅과 같은 기능을 통해 사용자가 고민할 필요가 없도록 해야 합니다.

하지만 그동안은 정상 상태입니다.

네.

Google은 개발자가 직접 결정하지 않고도 작업을 적절한 모델에 매핑할 수 있도록 모델 라우터와 같은 기능을 개발하는 데 많은 노력을 기울여 왔습니다.

하지만 적절한 트립와이어를 갖추는 것도 중요합니다.

따라서 토큰 한도를 몇 가지 방식으로 고려합니다.

Google은 개발자를 차단하지 않습니다.

하지만 잠시 멈추고 적절한 영역에 적절한 방식으로 지출되고 있는지 확인하는 시간이 필요합니다.

따라서 개발자가 직접 차단 해제할 수 있는 일일 한도와 같은 제한이 있습니다.

포털로 이동하여 버튼을 클릭하고 '놀라운 일은 일어나지 않았습니다.

내가 주도권을 쥐고 있어."

그렇죠?

이것은 간단한 레버 중 하나입니다. 모든 사용자가 루프를 실행하고 있으며 이러한 루프는 밤새 실행될 수 있으므로 비용이 증가하지 않도록 해야 합니다.

따라서 이는 매우 합리적입니다.

한편, 개발자가 최고의 모델을 사용할 수 있도록 지원하는 것도 중요합니다.

하지만 이러한 카테고리의 모델을 위해 최첨단 예산을 마련했습니다.

따라서 월 예산이 설정되어 있습니다.

충분히 높습니다.

차단되지 않았습니다.

차단을 해제해야 하는 경우 예외 절차가 있습니다.

관리자에게 전송됩니다.

지금 하고 있는 일을 설명하는 순간입니다.

플랫폼팀은 의사 결정자가 아닙니다. 의사 결정은 작업이 이루어지는 곳과 가까운 곳에서 이루어져야 하기 때문입니다.

프런티어 모델 사용과 관련해서도 한도 내에서 완전한 유연성을 제공합니다.

이러한 방식이 효과적인 이유는 궁극적으로 프로세스에 예측 가능성을 가져다주기 때문입니다.

그렇죠?

토큰 지출 예산을 책정할 때 계획한 내용을 반영해야 하는데, 이는 모두에게 어려운 과제입니다. 이러한 레버를 사용하면 이를 수행할 수 있습니다.

이러한 대화에서 흥미로운 점이 무엇인지 아시나요?

우리 모두가 회사에서 일하기 때문이라고 생각합니다.

기업도 마찬가지입니다.

따라서 모든 토큰에 대해 비용을 지불해야 합니다.

그렇죠?

하지만 인터넷에는 구독 요금제를 사용하는 사람들도 있습니다.

따라서 이들에게는 계산이 매우 다릅니다.

그렇죠?

하지만 아시다시피 모든 토큰에 대해 생각해야 하는 동일한 풀에 모두가 속하게 되는 것은 시간문제입니다.

그때가 되면, 지금 기업들이 해야 하는 것처럼, 좀 더 책임감 있는 자세를 취해야 하는 상황이 올 것입니다.

아니면 예산이 무제한인 최첨단 연구소에서 일하는 경우입니다.

그런 다음 계속 운영하면서 트위터에 가득한 AI 네이티브 방식의 흥미로운 작업 방식을 많이 만들어 내는 것입니다.

모든 회사가 이를 모방하고 싶어 하지만, 토큰을 사용하고 싶어 하지는 않습니다.

Google에서 일하는 직원들이 있습니다.

정말 궁금합니다.

어떻게 작동하나요?

Google에서 제공하는 예산은 얼마인가요?

루이스, 이 질문에 답변해 주시겠어요?

경제적인 측면에 대해서는 제가 말씀드릴 수 있는 부분이 아닌 것 같습니다.

Google은 다양한 조직이 있는 매우 큰 회사입니다.

하지만 시간이 딱 맞아서 완벽하게 마무리할 수 있겠네요.

편리하네요.

Saved by the bell.

정말 훌륭한 진행이었습니다.

PR 담당자는…

패널 여러분께 감사드리며, ADS에 참석해 주셔서 감사합니다.