TECH 으로 돌아가기
TECH HACKER NEWS 오늘 7분 읽기 24 READS

에이전트가 코드를 굴리게 하려면: '자율주행 코드베이스'로 가는 길

에이전트가 코드를 굴리게 하려면: '자율주행 코드베이스'로 가는 길
SOURCE IMAGE · HACKER NEWS

AI 코딩 에이전트를 둘러싼 흥분이 한 차례 가라앉았다. 개발 도구 스타트업 Detail.dev는 최근 블로그에서 지금을 '토큰맥싱(tokenmaxxing) 이후'의 시기로 규정하며, 업계가 하이프 사이클의 '환멸의 골짜기'에 들어섰다고 진단했다. 올해 상반기 많은 엔지니어링 조직이 가능한 한 많은 작업을 에이전트 부대와 적대적 루프(adversarial loop)에 떠넘겼지만, 결과는 실망스러웠다는 것이다. 미심쩍은 코드는 산더미처럼 쌓였는데 정작 대단한 소프트웨어의 물결은 오지 않았고, 그 많은 토큰을 태운 대가의 투자 대비 효과는 기껏해야 불분명한 수준에 머물렀다.

흥미로운 지점은 이 글이 실패를 모델의 한계로 돌리지 않는다는 데 있다. 필자의 주장은 오히려 반대다. 지금의 에이전트는 이미 훨씬 더 많은 일을 해낼 만큼 충분히 좋으며, 문제는 그것들이 놓인 '환경'에 있다는 것이다. 에이전트는 게임을 한 번에 만들어내기도 하고, 적절한 가드레일만 있으면 복잡한 코드베이스의 대규모 마이그레이션이나 새 언어로의 재작성까지 인상적으로 수행한다. 그럼에도 '진짜' 소프트웨어 작업은 여전히 사람이 운전대를 잡고 있다.

병목은 모델이 아니라 개발 환경

에이전트가 실수하는 지점은 대개 '보이지 않는 곳'이다. 체계적으로 재현할 방법이 없는 경쟁 상태(race condition), 데이터의 실제 형태를 모른 채 지나치는 느린 쿼리 같은 것들이다. 여기에 더해 에이전트는 모호함이라면 무엇이든 방어하려는 성향 탓에 불필요하게 방어적인 코드를 대량으로 쏟아낸다. 사각지대가 있으면 실수가 생기고, 실수는 신뢰를 갉아먹으며, 낮아진 신뢰는 더 깐깐한 리뷰를 요구한다. 그 결과 사람이 넘겨줄 수 있는 일의 양이 제한된다. 그래서 지금 엔지니어링 팀이 할 수 있는 가장 중요한 투자는, 에이전트가 코드를 실제로 이리저리 굴려보고 버그의 유무를 판단할 수 있도록 개발 환경을 극도로 친화적으로 만드는 일이라고 필자는 강조한다.

문제는 이 작업이 끝이 보이지 않는 잡일이자 일회성 땜질의 구덩이라는 점이다. 대표적인 데이터를 갖춘 로컬 개발 환경은 계속 움직이는 표적이고, 좋은 테스트를 쉽게 짜게 해줄 올바른 추상화를 찾아내는 일도 어렵다. 무엇보다 이 일은 코드베이스마다 제각각이고, 잘 해내는 사람이 극소수인 여전히 '기술'이 아닌 '기예'의 영역이다. 소위 '소프트웨어 공장'들이 실망스러웠던 이유 하나가 여기에 있다는 것이 필자의 진단이다.

루프를 짜는 일이 아니라 좋은 아이디어를 내는 일

소프트웨어가 상당 부분 스스로 굴러가면 엔지니어는 무엇을 하게 될까. 흔한 답은 '에이전트 루프를 설계하는 일'이지만, 이 글은 이를 오답으로 본다. 지금 수지 맞는 루프를 짜는 것이 엄청난 노동인 이유는 툴체인이 아직 무르익지 않았기 때문일 뿐이며, 필요한 부품이 갖춰지면 루프 구성은 쉽고 믿을 만하며 저렴해질 것이라는 논리다. 실제로 CI·CD 구축은 한때 수개월짜리 프로젝트였지만 지금은 성숙한 도구 덕에 하루면 끝난다. 루프에도 같은 전환이 오리라는 전망이다. 따라서 가장 값진 엔지니어링 작업은 결국 '좋은 아이디어를 갖는 일'로 남는다. 기능에 대한 발상과 구현을 단순화할 추상화를 찾는 일, 즉 소프트웨어 공장 바깥에서 오는 판단이야말로 사람의 몫이라는 것이다.

이 비전이 성립하려면 새로운 기본기(primitive)가 필요하다. 지난 시대의 도구들도 대부분 여전히 쓰이겠지만 형태가 달라진다. APM은 위젯 가득한 UI가 아니라 로그를 읽는 에이전트가 주로 조회하고, CI는 더 나은 머지 큐를 갖추며, A/B 테스트는 에이전트가 직접 운용하는 식이다. 2010년대에 소프트웨어를 클라우드로 옮기며 서버의 물리적 위치를 더는 신경 쓰지 않게 된 것처럼, 이번에도 지저분한 과도기를 거쳐 빠진 기본기들을 하나씩 채워 넣게 되리라는 비유다.

Detail의 접근: 기예를 과학으로

Detail이 내놓는 해법은 개발 환경의 '에이전트 준비도'를 정량화하는 것이다. 임의의 코드베이스에서 팀이 고치고 싶어 할 버그들의 유용한 작업 뭉치를 부트스트랩으로 만들어내고, 이를 이용해 어떤 투자가 높은 ROI를 내는지 판별하며, 저장소가 얼마나 에이전트 친화적인지 벤치마킹하겠다는 구상이다. 팀은 낮게 매달린 열매부터 개발 환경의 간극을 메워나가고, 저수준 버그를 거의 자율적으로 처리할 수 있게 되면 사람은 고부가가치 작업에 집중한다. 회사는 이 비전의 일부를 이번에 처음 공개했다고 밝혔다.

실무자 입장에서 이 글의 쓸모는 명확한 우선순위 재조정에 있다. AI를 금지하지도, 무작정 토큰을 쏟아붓지도 말고, 재현 가능한 테스트 데이터와 관측 가능성을 갖춘 개발 환경 정비에 힘을 실으라는 조언이다. 다만 유의할 점도 있다. 준비도를 측정하는 벤치마크와 부트스트랩 방식은 아직 제품으로 검증되지 않은 회사의 가설이며, 글 자체가 자사 제품 방향을 설명하는 성격을 띤다. 클라우드 전환에 빗댄 낙관 역시 여러 전제가 맞아떨어질 때의 이야기다. 그럼에도 '병목은 모델이 아니라 환경'이라는 프레임은, 에이전트 도입에서 성과를 내지 못하고 있는 팀이 지금 당장 점검해볼 만한 관점이다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://blog.detail.dev/posts/towards-self-driving-codebases...
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...