원문 제목: 지체의 중요성에 대한 생각
원문 저자: Mario Zechner
번역: Peggy, BlockBeats

편집자 주: 생성식 AI가 소프트웨어 엔지니어링으로 진입함에 따라 산업 감정이 '능력 놀라움'에서 '효율성 불안'으로 전환되고 있습니다. 충분히 빨리 쓰지 않고, 충분히 많이 사용하지 않고, 자동화가 충분히 철저하지 않다면 사람들은 쓸모없어지는 압력을 느낄 것으로 보입니다. 그러나 코딩 에이전트가 실제 프로덕션 환경에 진입하면 일부 보다 현실적인 문제가 드러나기 시작합니다: 오류가 확대되고, 복잡성이 무어질고, 시스템이 점차 알아보기 어려워지면서 효율성의 향상이 품질 향상으로 비례하지 않음을 알 수 있습니다.

본문은 현장 경험을 기반으로 이번 '에이젠틱 코딩' 열풍을 심각하게 반성하고 있습니다. 저자는 코딩 에이전트가 인간처럼 실수로 배우지 않는다는 점을 가리키며, 병목 현상과 피드백 메커니즘이 부족한 상황에서 작은 문제가 빠르게 확장되는 것을 설명합니다. 또한 복잡한 코드베이스에서 에이전트의 지역적 시야와 제한적인 회수 능력은 시스템 구조의 혼돈을 더욱 심화시킨다고 지적하였습니다. 이러한 문제들의 본질은 기술 자체에 있지 않고, 사람들이 불안으로 인해 판단력과 통제력을 너무 일찍 내주었기 때문임을 강조했습니다.

그러므로 'AI를 완전히 받아들여야 하는가'라는 불안에 빠지는 대신, 사람과 도구 간의 관계를 재조정하는 것이 더 좋다는 것을 제안했습니다: 에이전트가 지역적이고 제어 가능한 작업을 담당하도록 하고, 시스템 설계, 품질 보증 및 중요한 의사 결정을 꼼꼼히 쥐어짚도록 해야 합니다. 이 과정에서 '느리게 움직이기'가 오히려 능력의 하나가 되는데, 이는 여전히 시스템을 이해하며 선택을 할 수 있고 작업에 대한 통제감을 유지하는 것을 의미합니다.

도구가 계속 발전하는 시대에, 진정으로 부족한 것은 더 빨리 생성하는 능력보다는 복잡성을 판단하고, 효율성과 품질 사이의 선택을 내리는 결단력일지도 모릅니다.

아래는 원문입니다:

거북이의 그 표정, 그것이 내가 이 산업을 볼 때의 표정이야

약 1년 전, 본격적으로 '프로젝트를 처음부터 끝까지 해줄 수 있는' 코딩 에이전트가 등장하기 시작했습니다. 이보다 앞서는 에이더나 초기 커서와 같은 도구들도 있었지만, 그들은 보조 도구일 뿐이었고 '대리인'은 아니었습니다. 새로운 세대의 도구들은 매력적이며, 많은 사람들이 많은 개인 시간을 들여서 항상 하고 싶었지만 시간이 부족했던 프로젝트를 다시 해보았습니다.

저는 이게 그다지 문제라고 생각합니다. 개인 시간에 무언가를 만드는 것 자체가 즐겁기 때문이죠. 대부분의 경우 코드 품질과 유지보수성에 대해 크게 걱정할 필요가 없기 때문입니다. 또 이것은 새로운 기술 스택을 배울 수 있는 경로를 제공하기도 합니다.

크리스마스 휴가 기간 동안, Anthropic과 OpenAI는 일종의 "무료 할당량"도 공개했습니다. 이는 슬롯 머신처럼 사람들을 끌어들였습니다. 많은 사람들에게, 이것은 "에이전트가 코드를 작성하는" 마법을 진정으로 경험하는 것이었습니다. 참여자들이 점점 더 많아졌습니다.

지금은, 코딩 에이전트도 이미 프로덕션 코드베이스에 진입하기 시작했습니다. 12개월이 지나면서, 우리는 이 "진보"의 결과를 보기 시작했습니다. 아래는 내 현재의 견해입니다.

모든 것이 망가졌습니다

이 모든 것이 대부분 경험적인 이야기에 불과하지만, 현재 소프트웨어는 실제로 "언제든지 부서질 수 있는" 느낌을 줍니다. 98%의 가용성은 이제 사태로 변하고 있으며, 대규모 서비스조차 제외되지 않습니다. 사용자 인터페이스에는 테스트팀이 즉각 발견할 수있는 모순한 버그들이 가득합니다.

인정하건대, 이러한 상황은Agent가 등장하기 전에 이미 존재했습니다. 그러나 현재 문제는 명백히 가속화되고 있습니다.

우리는 회사 내부의 실제 상황을 보지 못하지만, 가끔 "AI로 인한 AWS 다운"과 같은 소문이 있다. 아마존 웹 서비스는 즉시 이를 "정정"했지만, 그 후 내부적으로 90일의 재편 계획을 시작했습니다.

최근 Satya Nadella(마이크로소프트 CEO)는 회사 내에서 AI가 급증하고 있다고 강조했습니다. 직접적인 증거는 없지만, Windows의 품질이 저하되고 있다는 느낌이 있습니다. 심지어 마이크로소프트가 게시한 몇몇 블로그를 보면, 그들도 이 점을 인정하는 것으로 보입니다.

코드를 100% AI가 생성했다고 주장하는 회사들은 거의 항상 상상할 수있는 최악의 제품을 내놓습니다. 누출 메모리에 GB 수준, UI 혼돈, 기능 누락, 빈번한 충돌... 이러한 것들은 그들이 "품질을 보증하는 것"으로 생각하지 않았던 것들이며, 특히 "에이전트가 모든 것을 대신해줄 것"을 긍정적인 예로 들지 않습니다.

비공개로는, 대기업이나 소규모 팀 모두가 하나의 것을 이야기합니다: 그들은 이미 "에이전트가 코드를 작성하도록 강요당했습니다". 코드 리뷰 없이 설계 결정을 에이전트에게 맡기고, 아무도 필요로 하지 않는 기능들을 덧붙이면, 결말은 당연히 좋지 않을 것입니다.

우리가 에이전트를 이렇게 사용해서는 안 되는 이유

우리는 거의 모든 엔지니어링 원칙과 주관적 심사를 포기했으며, "중독적인" 작업 방식에 빠져드는 중입니다: 목표는 한 가지뿐 - 가장 적은 시간 내에 가장 많은 코드를 생성하는 것입니다. 결과가 어떻든 상관하지 않습니다.

이것은 자동화된 에이전트 군단을 지휘하는 배치 구성을 세우고 있습니다. 여러분은 비즈를 설치했지만 사실상 제거할 수 없는 "악성 소프트웨어"에 가까운 것임을 전혀 모르고 있습니다. 그냥 "모두 이렇게 하는 거"라고 말할 뿐입니다. 이렇게 하지 않으면 당신은 "죽어 말하다"로 인식됩니다.

여러분은 계속해서 "마트료시카식 루프"에 갇혀 자멸하고 있습니다.

봐요—Anthropic은 에이전트 그룹을 사용하여 C 컴파일러를 만들었지만, 현재는 여전히 문제가 있습니다. 하지만 차세대 모델은 분명 문제를 해결할 수 있을 거에요, 그렇죠?

다시 봐요—Cursor는 대규모 에이전트를 사용하여 브라우저를 만들었지만, 현재는 거의 사용할 수 없으며 가끔씩 수동 개입이 필요합니다. 하지만 차세대 모델은 분명 문제를 해결할 수 있을 거에요, 그렇죠?

"분산 시스템", "분할 정복", "자립 시스템", "블랙 스완 팩토리", "여섯 달 동안 소프트웨어 문제 해결", "SaaS는 죽었어, 내 할머니가 방금 Claw로 Shopify을 구축했어"...

이러한 이야기는 정말로 멋져 보입니다.

물론, 이러한 방식은 여러분처럼 거의 아무도 사용하지 않는(당신을 포함한) 사이드 프로젝트에 대해 아마도 실제로 "작동할지도 모릅니다". 아마도, 정말 누군가 이러한 방식으로 쓰레기가 아닌 실제로 사용되는 소프트웨어 제품을 만드는 천재가 존재할 수도 있습니다. 당신이 그 사람이라면, 저는 진심으로 경탄할 것입니다.

하지만 적어도 제 주변의 개발자 커뮤니티에서는 이러한 방법이 실제로 효과적인 사례를 아직 보지 못했습니다. 물론, 아마 우리 모두가 너무 서투르다는 걸 수도 있겠죠.

학습 없음, 병목 현상 없음, 지연 폭발이 지속적으로 중첩

에이전트의 문제는: 그들은 실수를 저지를 수 있다는 것입니다. 이 자체로는 별 것 아닙니다, 인간도 실수를 합니다. 아마도 몇 가지 정확성 오류에 불과하며, 인식하기 쉽고 수정하기 쉽기 때문에 추가로 회귀 테스트를 통해 더욱 안정적일 겁니다. 때로는 린터가 잡아내지 못하는 코드 스멜일 수도 있습니다: 쓸모 없는 메소드 여기저기, 부적절한 유형, 중복 코드 등. 이러한 것들은 개별적으로는 심각한 문제가 아니며, 인간 개발자도 이러한 작은 실수를 범합니다.

하지만 "기계"는 인간이 아닙니다. 인간이 동일한 실수를 반복한 후에는 일반적으로 그 실수를 더 이상 반복하지 않도록 배웁니다—누굴 꾸짖거나 진정한 학습 과정을 통해 그 실수를 고치기 때문입니다.

에이전트에게는 이러한 학습 능력이 없습니다, 적어도 기본적으로는 없습니다. 그들은 동일한 오류를 반복하며, 때로는 훈련 데이터에 기반하여 다른 오류의 멋진 조합을 "창조"할 수도 있습니다.

당신은 물론 그것을 "훈련"시킬 수 있습니다: AGENTS.md에 규칙을 작성하여 그런 실수를 범하지 않도록 할 수 있습니다. 또한, 역사적 오류 및 모범 사례를 조회할 수 있는 복잡한 메모리 시스템을 디자인할 수도 있습니다. 이것은 특정 유형의 문제에 대해 실제로 효과적일 수 있습니다. 그러나 전제 조건은—먼저 그 실수를 인식해야 한다는 것입니다.

더 중요한 차이점은 다음과 같습니다: 인간은 병목 지점이지만, 에이전트는 그렇지 않습니다.

인간은 몇 시간 동안 이만큼의 코드를 작성할 수 없습니다. 비록 실수율이 낮더라도, 하루에는 제한된 수의 오류만을 도입할 수 있으며 이러한 오류의 누적은 느려집니다. 일반적으로, '오류로 인한 고통'이 일정 수준으로 누적되면 인간은 (고통을 혐오하는 본능적 이유로) 멈춰서 수정을 합니다. 또는 사람이 교체되어 다른 사람이 수정합니다. 총론적으로 문제는 처리됩니다.

그러나 작은 그룹의 세심한 계획이 수백 번이나 실행된 '군단' 에이전트를 사용할 때, 병목 지점도 '고통감'도 없습니다. 이전에는 사소했던 작은 실수들이 지속할 수 없는 속도로 쌓이게 됩니다. 당신은 이미 그 루프에서 제외되었고, 이 보기에는 해를 놓치게 됩니다. 이런 보이지 않는 문제는 이미 거대한 문제로 자라 있을 때가 많습니다.

어느 날 새로운 기능을 추가하려고 할 때, 현재의 시스템 구조(본질적으로 잘못된 쌓임이 이미)가 수정을 지원하지 않음을 발견하거나 사용자가 최신 릴리스에서 문제가 발생했거나 데이터가 손실될 때 사용자가 불평하기 시작합니다.

이때 당신은 이 코드 집합을 더 이상 신뢰할 수 없다는 것을 깨달을 것입니다.

더 나쁜 것은, 에이전트가 생성한 수천 개의 유닛 테스트, 스냅샷 테스트, 엔드 투 엔드 테스트도 더 이상 신뢰할 수 없습니다. '시스템이 올바르게 작동하는지'를 판단할 수 있는 유일한 방법은 수동 테스트뿐입니다.

축하합니다, 당신은 스스로 (그리고 회사를) 크게 해친 것입니다.

복잡성의 중개인

이제 시스템이 무엇을 하고 있는지 전혀 모르게 되었습니다. 왜냐하면 당신은 제어를 에이전트에게 넘겼기 때문입니다. 그리고 에이전트는 본질적으로 '복잡성을 증폭하는' 것입니다. 그들은 학습 데이터에서 많은 나쁜 아키텍처 결정을 본 적이 있고, 강화 학습 과정에서 이러한 패턴들을 계속 강화합니다. 당신이 시스템을 설계하도록 할 때, 그 결과는 예측 가능합니다.

최종적으로 당신은 이와 같은 결과를 얻습니다: 극도로 복잡한 시스템 구조, 여러 '업계 모베스트 프랙티스'의 서투른 모방 및 문제가 통제될 때까지 제약이 없었던 것입니다.

그러나 문제는 여기에 그치지 않습니다. 당신의 에이전트들은 서로의 실행 프로세스를 공유하지 않으며 완전한 코드베이스를 볼 수 없으며 다른 에이전트 또는 당신이나 다른 에이전트가 이전에 한 결정을 이해하지 못합니다. 그러므로 그들의 결정은 항상 '지역적'입니다.

이것이 앞에서 언급한 문제로 직접적으로 이어집니다: 대량의 중복 코드, 추상화만을 위한 추상화된 구조, 다양한 불일치. 이러한 문제는 계속해서 증가하며, 결국 돌이킬 수 없는 복잡한 시스템을 형성하게 됩니다.

이는 인간이 작성한 기업급 코드베이스와 매우 유사합니다. 그 복잡성은 일반적으로 수년간의 쌓인 결과입니다: 고통이 많은 사람들에게 분산되어 있고, 각 사람은 '수정 필요'의 임계점에 도달하지 못했으며, 조직 자체의 관용도가 매우 높기 때문에 복잡성은 조직과 함께 '공생 진화'했습니다.

그러나 인간 + 에이전트의 결합에서는이 프로세스가 크게 가속화됩니다. 두 명의 사람, 에이전트 무리와 함께하면 몇 주 만에이 복잡성에 도달할 수 있습니다.

에이전트 검색의 검색률이 매우 낮음

당신은 아마도 에이전트가 '여왕 청소'를 도와 시스템을 리팩토링하고 최적화하여 깨끗하게 만들 것이라고 희망할 것입니다. 그러나 문제는 이제 그들이 그것을 할 수 없다는 점입니다.

코드베이스가 매우 크고 복잡하기 때문에 그들은 항상 지역적으로만 볼 수 있었습니다. 이겢 큰 상황 창이 부족하다거나, 수백만 줄의 코드 속에서 장기적인 컨텍스트 매커니즘이 실패한 것만큼 간단하지는 않습니다. 문제는 더 깊게 숨겨져 있습니다.

시스템을 수정하려는 에이전트가 될 때까지는 먼저 수정해야 할 모든 코드와 재사용 가능한 기존 구현을 찾아야합니다. 이 단계를 우리는 에이전트 검색이라고 합니다.

에이전트가이 작업을 수행하는 방법은 당신이 그에게 제공하는 도구에 달렸습니다: Bash + ripgrep 일 수 있고, 검색 가능한 코드 인덱스, LSP 서비스, 벡터 데이터베이스 등이 될 수 있습니다...

그러나 사용하는 도구에 상관없이 본질은 동일합니다: 코드베이스가 클수록 검색률이 낮아집니다. 그리고 검색률이 낮다는 것은: 에이전트가 모든 관련 코드를 찾을 수 없으므로 올바른 수정을 수행할 수 없다는 것을 의미합니다.

이것이 처음에 '코드 냄새'라고 하는 작은 오류가 발생하는 이유입니다. 그들은 이미 구현을 찾지 못하였기 때문에 중복 코드를 생성하여 일관성을 위반하고, 이러한 문제점은 계속 확산되고 겹쳐지면서 극도로 복잡한 '쓰레기 꽃'을 피웁니다.

그렇다면 우리는 이 모든 것을 어떻게 피할 수 있을까요?

우리는 현재 어떻게 에이전트와 협업해야합니까

에이전트 코딩은 해마처럼, 매우 빠른 코드 생성 속도와 그 '부드러운 부드러움 중간적으로 강렬한' 지능으로 당신을 끌어들입니다. 그들은 종종 놀랍도록 빠르게 고품질로 몇 가지 간단한 작업을 수행 할 수 있습니다. 진짜 문제가 시작되는 것은 당신이 '이건 너무 강해, 컴퓨터야, 내 대신 일 해!'라는 생각을 가질 때입니다.

작업 자체를 에이전트에게 맡기는 것에는 물론 문제가 없습니다. 좋은 에이전트 작업은 일반적으로 몇 가지 특성을 갖추고 있습니 다. 범위를 잘 제한할 수 있으며 전체 시스템을 이해 할 필요가 없습니다; 작업이 폐쇄 루프라는 것이, 즉 에이전트가 결과를 자체로 판단 할 수 있습니다; 출력이 핵심 경로가 아니며 일시적인 도구 또는 내부 사용 소프트웨어 일뿐이며 실제 사용자나 수익에 영향을주지 않습니다; 또는 당신이 사고를 보조하기위한 '고무 오리'가 필요한 경우 - 본질적으로 귀하의 생각을 가져 와서 인터넷의 압축 된 지식 및 합성 데이터와 충돌 시키는 것입니다.

만약 이러한 조건을 충족한다면, 그것은 에이전트에게 맡길 수 있는 업무입니다. 다만, 여전히 인간으로서 최종 품질 검사자 역할을 해야 합니다.

예를 들어, Andrej Karpathy가 제안한 자동 연구 방법을 사용하여 애플리케이션 시작 시간을 최적화하고 싶다면? 좋습니다. 하지만, 그 코드가 프로덕션에 사용 가능하다고 확신할 수 없다는 것을 명심해야 합니다. 자동 연구가 효과가 있는 이유는 그것에 평가 함수를 제공하여 특정 지표(예: 시작 시간 또는 손실) 주변으로 최적화할 수 있기 때문입니다. 그러나 이 평가 함수는 매우 한정적인 측면만 다룹니다. 에이전트는 평가 함수에 없는 모든 지표를 무시하고, 코드 품질, 시스템 복잡성 및 때로는 정확성조차도 무시할 수 있습니다. - 평가 함수 자체에 문제가 있는 경우의 수도 있습니다.

핵심 아이디어는 사실 매우 간단합니다: 에이전트에게 지루하고 새로운 것을 배울 수 없는 작업이나 시간이 없어서 시도하지 못했던 탐구 작업을 맡기십시오. 그런 다음 결과물을 검토하여 실제로 합리적이고 올바른 부분을 선별하고 마지막 구현을 완료하십시오. 물론, 이 단계도 에이전트의 도움을 받을 수 있습니다.

하지만 더 강조하고 싶은 것은, 정말로, 조금 더 천천히 해야 한다는 것입니다.

자신에게 생각할 시간을 주십시오. 당신이 무엇을 하고 있으며 왜 그것을 해야 하는지에 대해 고민하십시오. 자신에게 "아니"라고 말할 기회를 주십시오. "아니, 이건 우리에게 필요하지 않아요." 에이전트에게 분명한 제한을 정하십시오: 하루에 생성할 수 있는 코드 양을 제한하고, 이 양은 실제로 검토할 수 있는 능력과 일치해야 합니다. 시스템의 "전체 형태"를 결정하는 아키텍처, API 등과 같은 부분은 직접 작성해야 합니다. 자동 완성을 사용하여 "소스 코드를 직접 작성하는 느낌"을 얻을 수도 있고, 에이전트와 함께 페어 프로그래밍을 할 수도 있지만 핵심은: 당신은 코드 안에 있어야 합니다.

왜냐하면, 코드를 직접 작성하거나 한 단계씩 구축되는 것을 지켜보는 것 자체가 "마찰감"을 초래합니다. 이 마찰이 당신에게 도달하려는 바, 시스템이 어떻게 작동하는지, 전체 "느낌"이 어떻게 되는지를 보다 명확하게 만들어 줍니다. 이것이 경험과 "취향"이 작용하는 곳이며, 이것은 현재 가장 선진적인 모델이 아직 대체할 수 없는 것입니다. 천천히 해서, 약간의 마찰을 이겨내는 것이 바로 여러분이 학습하고 성장하는 방식입니다.

결국, 여러분이 받는 것은 여전히 유지 가능한 시스템일 것입니다 — 적어도 에이전트가 나타나기 전보다는 나은 수준일 것입니다. 맞습니다, 과거의 시스템이 완벽하지는 않았습니다. 그러나 여러분의 사용자들은 여러분이 제품을 "사용하기 좋은" 것으로 만들어 줄 것입니다. 그렇지 않고 막 나온 쓰레기 같은 것이 아닙니다.

수행하는 기능이 적을지 모르지만, 더 정확해집니다. "아니"라고 말하는 것을 배우는 것 자체가 능력입니다. 여러분은 편히 자투리도 잘 것입니다, 적어도 시스템이 어떻게 작동하는지 알고 있을 것입니다. 이해함으로써, 에이전트 검색의 리콜 문제를 보완하고, 에이전트의 출력을 더 신뢰할 수 있게 만들고, 더 적은 보정이 필요하게 할 수 있습니다.

시스템에 문제가 발생할 때 직접 해결할 수 있고, 처음부터 설계가 합리적이지 않을 때 문제를 이해하고 더 나은 형태로 재구성할 수 있습니다. 에이전트가 있는지 여부는 그리 중요하지 않습니다.

모든 것은disziplin을 필요로 합니다. 모든 것은 인간과 떼어 놓을 수 없습니다.

[원문 링크]

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia