아마존이 소프트웨어 엔지니어를 위한 AI 지침을 개정해, AI를 얼마나 많이 썼는지를 생산성의 척도로 삼지 말라고 강조했다. Terk Terkowitz 부사장 겸 특임 엔지니어가 소개한 지침은 9월 사내에 공유된 뒤 10월 27일 공개됐다.
6
8
15
핵심은 간단하다. AI 사용량이 많다고 해서 더 좋은 소프트웨어나 더 나은 사업 성과가 자동으로 따라오는 것은 아니다. 아마존은 토큰 사용량, AI 도구 도입률, 코드 변경·리뷰 건수 같은 수치를 단독 성과 지표로 쓰는 데 대해 “심각한 결함이 있다”고 지적했다.
5
7
활동량과 성과는 다르다
토큰은 AI 모델이 입력과 출력을 처리할 때 쓰는 텍스트 단위다. 토큰을 많이 썼는지, 팀원 중 얼마나 많은 사람이 AI를 도입했는지, 코드가 얼마나 바뀌었는지는 활동량을 보여줄 수는 있다. 하지만 그 활동이 고객에게 더 나은 경험을 제공했는지, 제품이나 사업에 실질적인 가치를 더했는지는 그 숫자만으로 알기 어렵다.
5
6
이런 지표를 목표로 삼으면 숫자 자체를 높이는 행동이 생길 수 있다. ‘토큰맥싱(tokenmaxxing)’은 결과의 품질을 충분히 살피지 않은 채 AI 도구를 과도하게 사용해 사용량을 늘리는 행태를 가리킨다.
2
14 불필요한 작업은 토큰 비용을 키울 수 있고, 필요 이상의 코드나 복잡성을 만들어낼 위험도 있다.
7
10 AWS 문서도 Amazon Bedrock에서 토큰 수를 주요 비용 요인으로 꼽으며 입력 프롬프트와 출력을 줄이는 방안을 권한다.
AI를 쓰되, 효과를 따져보라는 주문
아마존의 메시지는 AI 사용 자체를 억제하자는 뜻과는 다르다. 엔지니어는 AI를 선택적으로 활용하고, 사용량이나 코드 변경 건수는 다른 정보와 함께 신중히 살펴야 한다. 판단의 중심에는 장기적인 고객·사업 성과가 놓여야 한다는 취지다.
6
11
13
회사는 관리자들에게 AI 도입률이 가장 높은 팀과 낮은 팀을 살펴보라고도 한 것으로 전해졌다.
14 이 방식은 도입률을 곧바로 성과 순위로 보는 것과는 다르다. 팀 간 차이를 살펴보고 어떤 업무에서 AI가 도움이 되는지 파악하는 자료로 활용할 수 있다는 해석이 가능하다. 다만 제공된 자료만으로는 회사가 이 검토를 구체적으로 어떻게 운영하는지까지 확인하기 어렵다.
이 같은 문제의식은 내부 사용량 순위표를 둘러싼 논란과도 맞닿아 있다. 보도에 따르면 아마존은 직원들이 토큰 사용량을 좇는 상황이 벌어진 뒤 5월 내부 AI 사용량 순위표를 없앴다.
9 사용량을 보상하는 지표가 생산적인 결과 대신 숫자를 키우는 행동을 낳을 수 있다는 우려를 보여주는 사례다.
9
확인 가능한 범위와 남은 질문
공개된 자료로 확인되는 결론은 분명하다. 아마존은 AI 도입을 독려하면서도 토큰 소비를 성과와 동일시하지 않으려 한다. 더 중요한 기준은 AI가 실제 엔지니어링 작업과 사업 결과를 개선했는지 여부다.
6
7
반면 엔지니어가 AI가 도움이 되지 않았던 사례를 기록·공유해야 한다는 구체적 지침, ‘기능 출시 속도(feature velocity)’를 포함한 평가 방식, 관리자들이 검토하는 팀의 정확한 하위·상위 비율은 제공된 자료만으로 확인되지 않는다. 아마존의 토큰 한도 설정 여부나 다른 기업의 토큰 제한·저비용 오픈소스 모델 전환 사례도 여기서 확인된 사실로 단정하기 어렵다.
결국 아마존이 제시한 기준은 ‘AI를 많이 썼는가’보다 ‘AI가 실제로 도움이 됐는가’에 가깝다. 사용량은 참고 자료일 수 있지만, 그 자체가 좋은 엔지니어링의 증거는 아니라는 것이다.
6
13