<div id="readability-page-1" class="page"><div><div tabindex="-1" role="tooltip"><a rel="noopener follow" href="/?source=post_page---byline--2ab92d53f517---------------------------------------" data-discover="true"><div><img alt="한정(Han Jung)" src="https://miro.medium.com/v2/resize:fill:64:64/1*tQfG8hfW5vM4hbRVZucMrg.png" width="32" height="32" loading="lazy" data-testid="authorPhoto"></div></a></div><blockquote>원문: <a href="https://blog.pragmaticengineer.com/new-trend-programming-by-kicking-off-parallel-ai-agents" rel="noopener ugc nofollow" target="_blank">https://blog.pragmaticengineer.com/new-trend-programming-by-kicking-off-parallel-ai-agents</a>안녕하세요, Pragmatic Engineer 뉴스레터의 무료 보너스 호를 가져온 게르겔리입니다. 매 뉴스레터 마다 저는 시니어 엔지니어와 엔지니어링 리더의 관점에서 빅테크와 스타트업을 다룹니다. 오늘은 <a href="https://newsletter.pragmaticengineer.com/p/the-pulse-149-new-trend-programming?ref=blog.pragmaticengineer.com" rel="noopener ugc nofollow" target="_blank">The Pulse #149</a>에서 다룬 한 가지 주제를 다룹니다. 정기 구독자들은 이 글을 2주 전에 받았습니다. 매주 이런 글을 받아보려면 <a href="https://newsletter.pragmaticengineer.com/about?ref=blog.pragmaticengineer.com" rel="noopener ugc nofollow" target="_blank">여기서 구독하세요</a>.</blockquote>클로드 코드, OpenAI 코덱스, 커서 등과 같은 에이전트 기반 커맨드라인 인터페이스가 주류가 되면서, 여러 에이전트를 동시에 시작하여 각각 다른 작업을 수행하도록 하는 실험을 하는 소프트웨어 엔지니어들이 늘어나는 트렌드가 생겨났습니다.저는 앤트로픽 엔지니어 Sid Bidasaria와 <a href="https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built?ref=blog.pragmaticengineer.com" rel="noopener ugc nofollow" target="_blank">클로드 코드가 어떻게 구축되었는지</a>에 대해 이야기를 나눴는데, 대화가 끝나갈 무렵 그는 몇 개의 에이전트를 동시에 실행해 왔고 이를 통해 업무 생산성을 높였다고 언급했습니다. 마찬가지로, 제가 AI 엔지니어링 전문가로 생각하는 소프트웨어 엔지니어 Simon Willison도 “<a href="https://simonwillison.net/2025/Oct/5/parallel-coding-agents/?ref=blog.pragmaticengineer.com" rel="noopener ugc nofollow" target="_blank">병렬 코딩 에이전트 라이프스타일 받아들이기</a>”에 대해 글을 올렸습니다. 그는 글에서 이렇게 말했습니다.“한동안 여러 코딩 에이전트를 동시에 실행하는 엔지니어들의 이야기를 들어왔습니다. 여러 개의 클로드 코드나 OpenAI 코덱스 인스턴스를 동시에 실행하는데, 때로는 같은 저장소에서, 때로는 여러 체크아웃이나 git worktree를 사용하여 실행합니다.저는 처음에 이에 대해 꽤 회의적이었습니다. AI가 생성한 코드는 검토가 필요한데, 이는 모든 것의 병목이 자연스레 제가 얼마나 빨리 그 결과를 검토할 수 있는지에 달려있다는 것을 의미합니다. LLM이 얼마나 빠르게 코드를 생성하는지를 생각하면 단 하나만 따라가기도 힘든데, 오히려 저를 더 뒤처지게 만들 뿐이라면 동시에 여러 개를 실행하는 게 무슨 이점이 있을까요?제 의구심에도 불구하고, 지난 몇 주 동안 저는 조용히 병렬 코딩 에이전트 라이프스타일을 받아들이기 시작했습니다.저는 한 번에 하나의 중요한 변경사항만 집중해서 검토하고 반영할 수 있습니다. 하지만 주요 작업에 큰 인지 부하를 주지 않으면서 병렬로 처리할 수 있는 작업들이 점점 늘어나고 있습니다.Simon은 리서치, 유지보수 작업, 방향성이 있는 작업 등을 사용 사례로 언급하며 <a href="https://simonwillison.net/2025/Oct/5/parallel-coding-agents/?ref=blog.pragmaticengineer.com" rel="noopener ugc nofollow" target="_blank">자신에게 효과적인 방법에 대한 조언을 공유합니다</a>.에이전트를 활용한 병렬 작업이 수십 년간의 소프트웨어 엔지니어링 관행을 뒤집을 가능성이 있는지 생각해 보는 것은 흥미롭습니다. 여러 에이전트를 동시에 시작하는 소프트웨어 엔지니어들이 한 번에 한 가지 문제를 다루는 싱글 스레드 동료들보다 실제로 더 생산적이게 된다고 가정해 봅시다. 그렇다면, 충분히 많은 소프트웨어 엔지니어들이 더 생산적이 되기를 원하거나 이전보다 더 많은 일을 하는 일부 동료들에게 뒤처지고 싶지 않다면, 이 관행은 확산될 가능성이 있습니다.하지만 AI 이전 시대에는 많은 생산적인 엔지니어들에게 몰입(flow) 상태를 유지하는 것이 가장 중요했습니다. 몰입 상태는 대략 다음과 같습니다.<ul><li id="fd69">움직이는 부분들을 이해합니다</li><li id="5578">솔루션을 구축하고, 검증하고, 반복합니다</li><li id="0bed">작동 방식에 만족하면 코드 리뷰를 위해 풀 리퀘스트(pull request)를 제출하거나, 리뷰가 필요 없다면 바로 병합하고 배포합니다</li></ul>이 과정을 중단하면 몰입 상태가 깨지고, 다시 돌아오는 데 시간이 걸립니다. 이것이 소프트웨어 엔지니어들이 코딩 작업에서 진전을 이루기 위해 집중 시간을 우선시하는 경향이 있는 이유입니다.물론, 이것이 모든 높은 생산성을 가진 엔지니어들에게 보편적인 것은 아닙니다. 제가 엔지니어링 매니저였을 때, 제 팀에서 가장 생산적인 엔지니어들은 많은 컨텍스트 스위칭을 했고 여러 가지를 동시에 다루는 데 능숙했습니다. 아래에 테크 리드 역할을 하는 시니어 엔지니어의 평범해 보이는 하루를 적어보겠습니다.<ul><li id="79fa">코드 리뷰. 사무실에 도착해서 전날 밤에 올라온 코드 리뷰들을 확인합니다.</li><li id="5bde">코딩. 자신의 코딩 작업을 진행합니다.</li><li id="0e8f">스탠드업. 일상적인 미팅입니다.</li><li id="fab2">추가 코딩. 작업을 완료합니다. 적어도 그것이 계획입니다. 하지만 실제로는:</li><li id="1761">인터럽션. 코드 리뷰 요청, 도움 요청, 어깨 두드림 등이 계속됩니다. 팀에서 가장 생산적인 엔지니어는 이런 요청들을 정기적으로 받습니다. 팀원들의 차단을 해제하기 위한 코드 리뷰 요청, 막힌 사람을 돕기 위한 요청, 또는 매니저(저 — 죄송합니다!)가 무언가를 도와달라고 어깨를 두드리는 일 등입니다.</li></ul>시니어+ 엔지니어들이 현재 그들이 하는 일과 기존 습관을 기반으로 병렬 AI 에이전트를 다루는 데 자연스럽게 잘할 수 있을지 궁금합니다.<ul><li id="e7e1">병렬 워크플로우 유지. 머릿속에 여러 작업 흐름을 동시에 유지합니다. 예를 들어, 팀원들이 특정 시점에 무엇을 하고 있는지 파악하고 있습니다.</li><li id="6928">여러 작업 흐름에 걸친 코드 리뷰. 그들은 찾아가는 코드 리뷰어이며, 보통 2~5개의 작업 흐름에 걸친 모든 코드 변경사항을 리뷰합니다. 직접 작업을 하지 않을 수도 있지만, 코드가 올바른지 판단할 수 있습니다.</li><li id="13e2">인터럽션 처리 능력. 집중이 계속 깨지는 상황에서도 어떻게 진전을 이루는지 배웠습니다.</li><li id="aedc">동료 지도 능력. 정기적으로 인터럽션을 받기 때문에, 팀원들에게 작업을 위임하고 긴급한 작업을 명확하게 설명하는 방법을 배웠습니다.</li><li id="45df">작문 능력. 이런 엔지니어들은 많은 코드 리뷰를 작성하고, 작업 개요를 담은 RFC(Request for Comments) 같은 문서를 작성하고, 프로젝트를 세분화하는 티켓을 만들고, 동료들의 작업을 비평합니다. 이 모든 것은 서면으로 효과적인 소통을 필요로 합니다.</li></ul>AI 에이전트를 사용하면, 좋은 테크 리드를 만드는 자질이 더 생산적이고 싶어 하는 엔지니어들의 손에 닿게 됩니다. 지금까지 제가 들은 바로는 병렬 에이전트를 성공적으로 사용하는 사람들은 시니어+ 엔지니어들뿐입니다.그렇지만 이 워크플로우가 모든 사람에게 정착한 것은 아닙니다. 저는 Flask 창시자 <a href="https://newsletter.pragmaticengineer.com/p/python-go-rust-typescript-and-ai?ref=blog.pragmaticengineer.com" rel="noopener ugc nofollow" target="_blank">Armin Ronacher</a>에게 병렬 에이전트 경험에 대해 물었습니다. 그는 이렇게 말했습니다.<blockquote>“저는 때때로 병렬 에이전트를 시작하지만, 예전만큼 자주 하지는 않습니다.문제는 제가 검토할 수 있는 양에는 한계가 있다는 것입니다!”</blockquote>하지만 이제 어떤 개발자든 코딩 에이전트를 이용해 병렬 코딩을 시작할 수 있게 되면서, 우리는 새로운 영역에 들어서게 되었습니다. 이것이 엔지니어들의 생산성을 더 높여줄까요, 아니면 그저 사람들이 더 생산적이라고 ‘느끼게’만 하는 걸까요? 어쩌면 한 번에 한 가지 일에만 집중하는 엔지니어들이 시간이 지나면서 더 신뢰할 수 있는 소프트웨어를 만든다는 것이 증명될지도 모릅니다. 또는 병렬 에이전트와 함께 작업하는 것이 더 많은 문제를 놓치게하고 더 많은 반복 작업을 초래하여 모든 이득을 파괴할 수도 있습니다.우리는 알게 될 것입니다. 개인적으로, 더 많은 개발자가 병렬 에이전트를 계속 실험해 볼 것이라고 봅니다.제 생각에는 AI 에이전트와 작업할 때 소프트웨어 엔지니어링의 기본이 더 중요합니다. 저는 제 자신의 사이드 프로젝트에 AI 에이전트를 사용하기 시작했고, 지금까지는 성공적입니다. 저는 다음과 같은 작업을 하고 있습니다.<ul><li id="fab5">테스트: 모든 사이드 프로젝트에는 단위 테스트가 있습니다. 왜냐하면 검증 없이는 제 자신의 작업을 신뢰하지 않는 것을 배웠기 때문입니다.</li><li id="d077">작고 구체적으로 설명된 작업: 범위가 충분히 작은 작업을 주고, 설명하며, 예제를 제공합니다.</li><li id="213b">리팩터링: 세 번째나 네 번째 작업마다 에이전트가 작성한 코드를 리팩터링 하도록 합니다 (예: 메서드로 추출, 새 클래스로 이동).</li><li id="7d3b">리뷰: 에이전트가 무엇을 하는지 추적합니다.</li><li id="62df">개인적으로 작은 일을 합니다: IDE를 열어두고 몇 줄 정도 변경하면 되는 것은 손으로 직접 하여 코드베이스(codebase)를 계속 파악하고 있습니다.</li></ul>저는 다른 엔지니어들에게도 같은 말을 계속 듣습니다. 에이전트가 계속하기 전에 모든 테스트를 통과하도록 하는 것과 같은 엔지니어링 관행을 “의무화”하면 더 나은 결과를 얻을 수 있습니다. 이는 놀라운 일이 아니며 이러한 관행들이 인기를 얻고 있는 이유입니다. AI 에이전트는 비결정적이고 어느 정도 신뢰할 수 없습니다. 이러한 관행들은 그것들을 훨씬 더 신뢰할 수 있고 사용 가능하게 만듭니다.이것은 <a href="https://newsletter.pragmaticengineer.com/p/the-pulse-149-new-trend-programming?ref=blog.pragmaticengineer.com" rel="noopener ugc nofollow" target="_blank">The Pulse #149</a>에서 다룬 다섯 가지 주제 중 하나였습니다. 전체 에디션은 추가로 다음을 다룹니다.<ul><li id="b084">ACP 프로토콜(protocol). Zed 팀이 구축한 새로운 프로토콜로, MCP 프로토콜이 허용하는 것보다 IDE용 AI 툴링을 더 쉽게 구축할 수 있도록 시도합니다.</li><li id="165f">AI 보안 툴링이 놀랍게도 잘 작동합니다? AI 기반 보안 도구는 성숙한 오픈소스 프로젝트에서 보안 결함을 식별하는 데 능숙해 보입니다.</li><li id="cfce">AI가 미국 경제 성장의 유일한 엔진인가? 올해 미국 GDP의 40%가 AI 관련 지출에 기반하고 있으며, 벤처 캐피털의 60%가 AI로 향합니다. 바라건대, 2001년처럼 터지는 버블로 끝나지 않기를 바랍니다.</li><li id="6cc4">8개 대형 테크 기업의 인터뷰 비교. <a href="https://www.linkedin.com/in/puneet-patwari/?ref=blog.pragmaticengineer.com" rel="noopener ugc nofollow" target="_blank">Puneet Patwari</a>는 8개 주요 테크 기업에 지원하여 6개의 오퍼를 받았습니다. 그는 Meta, Amazon, Uber 및 5개의 다른 직장에서의 인터뷰 경험을 비교합니다.</li></ul><a href="https://newsletter.pragmaticengineer.com/p/the-pulse-149-new-trend-programming?ref=blog.pragmaticengineer.com" rel="noopener ugc nofollow" target="_blank">여기서 전체 호를 읽어보세요</a>, 그리고 <a href="https://newsletter.pragmaticengineer.com/p/the-pulse-151?ref=blog.pragmaticengineer.com" rel="noopener ugc nofollow" target="_blank">오늘의 The Pulse를 여기서 확인하세요</a>.이런 글을 받아보려면 <a href="https://newsletter.pragmaticengineer.com/about" rel="noopener ugc nofollow" target="_blank">제 주간 뉴스레터를 구독하세요</a>. 꽤 좋은 읽을거리입니다. 그리고 Substack의 <a href="https://substack.com/top/technology" rel="noopener ugc nofollow" target="_blank">1위 테크 뉴스레터</a>입니다.</div></div>

Stories by Jung Han on Medium

한정

원문: https://blog.pragmaticengineer.com/new-trend-programming-by-kicking-off-parallel-ai-agents
안녕하세요, Pragmatic Engineer 뉴스레터의 무료 보너스 호를 가져온 게르겔리입니다. 매 뉴스레터 마다 저는 시니어 엔지니어와 엔지니어링 리더의 관점에서 빅테크와 스타트업을 다룹니다. 오늘은 The Pulse #149에서 다룬 한 가지 주제를 다룹니다. 정기 구독자들은 이 글을 2주 전에 받았습니다. 매주 이런 글을 받아보려면 여기서 구독하세요.
클로드 코드, OpenAI 코덱스, 커서 등과 같은 에이전트 기반 커맨드라인 인터페이스가 주류가 되면서, 여러 에이전트를 동시에 시작하여 각각 다른 작업을 수행하도록 하는 실험을 하는 소프트웨어 엔지니어들이 늘어나는 트렌드가 생겨났습니다.
저는 앤트로픽 엔지니어 Sid Bidasaria와 클로드 코드가 어떻게 구축되었는지에 대해 이야기를 나눴는데, 대화가 끝나갈 무렵 그는 몇 개의 에이전트를 동시에 실행해 왔고 이를 통해 업무 생산성을 높였다고 언급했습니다. 마찬가지로, 제가 AI 엔지니어링 전문가로 생각하는 소프트웨어 엔지니어 Simon Willison도 “병렬 코딩 에이전트 라이프스타일 받아들이기”에 대해 글을 올렸습니다. 그는 글에서 이렇게 말했습니다.
“한동안 여러 코딩 에이전트를 동시에 실행하는 엔지니어들의 이야기를 들어왔습니다. 여러 개의 클로드 코드나 OpenAI 코덱스 인스턴스를 동시에 실행하는데, 때로는 같은 저장소에서, 때로는 여러 체크아웃이나 git worktree를 사용하여 실행합니다.
저는 처음에 이에 대해 꽤 회의적이었습니다. AI가 생성한 코드는 검토가 필요한데, 이는 모든 것의 병목이 자연스레 제가 얼마나 빨리 그 결과를 검토할 수 있는지에 달려있다는 것을 의미합니다. LLM이 얼마나 빠르게 코드를 생성하는지를 생각하면 단 하나만 따라가기도 힘든데, 오히려 저를 더 뒤처지게 만들 뿐이라면 동시에 여러 개를 실행하는 게 무슨 이점이 있을까요?
제 의구심에도 불구하고, 지난 몇 주 동안 저는 조용히 병렬 코딩 에이전트 라이프스타일을 받아들이기 시작했습니다.
저는 한 번에 하나의 중요한 변경사항만 집중해서 검토하고 반영할 수 있습니다. 하지만 주요 작업에 큰 인지 부하를 주지 않으면서 병렬로 처리할 수 있는 작업들이 점점 늘어나고 있습니다.
Simon은 리서치, 유지보수 작업, 방향성이 있는 작업 등을 사용 사례로 언급하며 자신에게 효과적인 방법에 대한 조언을 공유합니다.
에이전트를 활용한 병렬 작업이 수십 년간의 소프트웨어 엔지니어링 관행을 뒤집을 가능성이 있는지 생각해 보는 것은 흥미롭습니다. 여러 에이전트를 동시에 시작하는 소프트웨어 엔지니어들이 한 번에 한 가지 문제를 다루는 싱글 스레드 동료들보다 실제로 더 생산적이게 된다고 가정해 봅시다. 그렇다면, 충분히 많은 소프트웨어 엔지니어들이 더 생산적이 되기를 원하거나 이전보다 더 많은 일을 하는 일부 동료들에게 뒤처지고 싶지 않다면, 이 관행은 확산될 가능성이 있습니다.
하지만 AI 이전 시대에는 많은 생산적인 엔지니어들에게 몰입(flow) 상태를 유지하는 것이 가장 중요했습니다. 몰입 상태는 대략 다음과 같습니다.
움직이는 부분들을 이해합니다
솔루션을 구축하고, 검증하고, 반복합니다
작동 방식에 만족하면 코드 리뷰를 위해 풀 리퀘스트(pull request)를 제출하거나, 리뷰가 필요 없다면 바로 병합하고 배포합니다
이 과정을 중단하면 몰입 상태가 깨지고, 다시 돌아오는 데 시간이 걸립니다. 이것이 소프트웨어 엔지니어들이 코딩 작업에서 진전을 이루기 위해 집중 시간을 우선시하는 경향이 있는 이유입니다.
물론, 이것이 모든 높은 생산성을 가진 엔지니어들에게 보편적인 것은 아닙니다. 제가 엔지니어링 매니저였을 때, 제 팀에서 가장 생산적인 엔지니어들은 많은 컨텍스트 스위칭을 했고 여러 가지를 동시에 다루는 데 능숙했습니다. 아래에 테크 리드 역할을 하는 시니어 엔지니어의 평범해 보이는 하루를 적어보겠습니다.
코드 리뷰. 사무실에 도착해서 전날 밤에 올라온 코드 리뷰들을 확인합니다.
코딩. 자신의 코딩 작업을 진행합니다.
스탠드업. 일상적인 미팅입니다.
추가 코딩. 작업을 완료합니다. 적어도 그것이 계획입니다. 하지만 실제로는:
인터럽션. 코드 리뷰 요청, 도움 요청, 어깨 두드림 등이 계속됩니다. 팀에서 가장 생산적인 엔지니어는 이런 요청들을 정기적으로 받습니다. 팀원들의 차단을 해제하기 위한 코드 리뷰 요청, 막힌 사람을 돕기 위한 요청, 또는 매니저(저 — 죄송합니다!)가 무언가를 도와달라고 어깨를 두드리는 일 등입니다.
시니어+ 엔지니어들이 현재 그들이 하는 일과 기존 습관을 기반으로 병렬 AI 에이전트를 다루는 데 자연스럽게 잘할 수 있을지 궁금합니다.
병렬 워크플로우 유지. 머릿속에 여러 작업 흐름을 동시에 유지합니다. 예를 들어, 팀원들이 특정 시점에 무엇을 하고 있는지 파악하고 있습니다.
여러 작업 흐름에 걸친 코드 리뷰. 그들은 찾아가는 코드 리뷰어이며, 보통 2~5개의 작업 흐름에 걸친 모든 코드 변경사항을 리뷰합니다. 직접 작업을 하지 않을 수도 있지만, 코드가 올바른지 판단할 수 있습니다.
인터럽션 처리 능력. 집중이 계속 깨지는 상황에서도 어떻게 진전을 이루는지 배웠습니다.
동료 지도 능력. 정기적으로 인터럽션을 받기 때문에, 팀원들에게 작업을 위임하고 긴급한 작업을 명확하게 설명하는 방법을 배웠습니다.
작문 능력. 이런 엔지니어들은 많은 코드 리뷰를 작성하고, 작업 개요를 담은 RFC(Request for Comments) 같은 문서를 작성하고, 프로젝트를 세분화하는 티켓을 만들고, 동료들의 작업을 비평합니다. 이 모든 것은 서면으로 효과적인 소통을 필요로 합니다.
AI 에이전트를 사용하면, 좋은 테크 리드를 만드는 자질이 더 생산적이고 싶어 하는 엔지니어들의 손에 닿게 됩니다. 지금까지 제가 들은 바로는 병렬 에이전트를 성공적으로 사용하는 사람들은 시니어+ 엔지니어들뿐입니다.
그렇지만 이 워크플로우가 모든 사람에게 정착한 것은 아닙니다. 저는 Flask 창시자 Armin Ronacher에게 병렬 에이전트 경험에 대해 물었습니다. 그는 이렇게 말했습니다.
“저는 때때로 병렬 에이전트를 시작하지만, 예전만큼 자주 하지는 않습니다.
문제는 제가 검토할 수 있는 양에는 한계가 있다는 것입니다!”
하지만 이제 어떤 개발자든 코딩 에이전트를 이용해 병렬 코딩을 시작할 수 있게 되면서, 우리는 새로운 영역에 들어서게 되었습니다. 이것이 엔지니어들의 생산성을 더 높여줄까요, 아니면 그저 사람들이 더 생산적이라고 ‘느끼게’만 하는 걸까요? 어쩌면 한 번에 한 가지 일에만 집중하는 엔지니어들이 시간이 지나면서 더 신뢰할 수 있는 소프트웨어를 만든다는 것이 증명될지도 모릅니다. 또는 병렬 에이전트와 함께 작업하는 것이 더 많은 문제를 놓치게하고 더 많은 반복 작업을 초래하여 모든 이득을 파괴할 수도 있습니다.
우리는 알게 될 것입니다. 개인적으로, 더 많은 개발자가 병렬 에이전트를 계속 실험해 볼 것이라고 봅니다.
제 생각에는 AI 에이전트와 작업할 때 소프트웨어 엔지니어링의 기본이 더 중요합니다. 저는 제 자신의 사이드 프로젝트에 AI 에이전트를 사용하기 시작했고, 지금까지는 성공적입니다. 저는 다음과 같은 작업을 하고 있습니다.
테스트: 모든 사이드 프로젝트에는 단위 테스트가 있습니다. 왜냐하면 검증 없이는 제 자신의 작업을 신뢰하지 않는 것을 배웠기 때문입니다.
작고 구체적으로 설명된 작업: 범위가 충분히 작은 작업을 주고, 설명하며, 예제를 제공합니다.
리팩터링: 세 번째나 네 번째 작업마다 에이전트가 작성한 코드를 리팩터링 하도록 합니다 (예: 메서드로 추출, 새 클래스로 이동).
리뷰: 에이전트가 무엇을 하는지 추적합니다.
개인적으로 작은 일을 합니다: IDE를 열어두고 몇 줄 정도 변경하면 되는 것은 손으로 직접 하여 코드베이스(codebase)를 계속 파악하고 있습니다.
저는 다른 엔지니어들에게도 같은 말을 계속 듣습니다. 에이전트가 계속하기 전에 모든 테스트를 통과하도록 하는 것과 같은 엔지니어링 관행을 “의무화”하면 더 나은 결과를 얻을 수 있습니다. 이는 놀라운 일이 아니며 이러한 관행들이 인기를 얻고 있는 이유입니다. AI 에이전트는 비결정적이고 어느 정도 신뢰할 수 없습니다. 이러한 관행들은 그것들을 훨씬 더 신뢰할 수 있고 사용 가능하게 만듭니다.
이것은 The Pulse #149에서 다룬 다섯 가지 주제 중 하나였습니다. 전체 에디션은 추가로 다음을 다룹니다.
ACP 프로토콜(protocol). Zed 팀이 구축한 새로운 프로토콜로, MCP 프로토콜이 허용하는 것보다 IDE용 AI 툴링을 더 쉽게 구축할 수 있도록 시도합니다.
AI 보안 툴링이 놀랍게도 잘 작동합니다? AI 기반 보안 도구는 성숙한 오픈소스 프로젝트에서 보안 결함을 식별하는 데 능숙해 보입니다.
AI가 미국 경제 성장의 유일한 엔진인가? 올해 미국 GDP의 40%가 AI 관련 지출에 기반하고 있으며, 벤처 캐피털의 60%가 AI로 향합니다. 바라건대, 2001년처럼 터지는 버블로 끝나지 않기를 바랍니다.
8개 대형 테크 기업의 인터뷰 비교. Puneet Patwari는 8개 주요 테크 기업에 지원하여 6개의 오퍼를 받았습니다. 그는 Meta, Amazon, Uber 및 5개의 다른 직장에서의 인터뷰 경험을 비교합니다.
여기서 전체 호를 읽어보세요, 그리고 오늘의 The Pulse를 여기서 확인하세요.
이런 글을 받아보려면 제 주간 뉴스레터를 구독하세요. 꽤 좋은 읽을거리입니다. 그리고 Substack의 1위 테크 뉴스레터입니다.

(번역) 새로운 트렌드: 병렬 AI 에이전트를 활용한 프로그래밍

댓글