Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
AI 에이전트가 개발 속도를 혁신적으로 높이고 있지만, 요구사항 정의와 아키텍처 설계에 대한 근본적인 사고 과정은 여전히 중요합니다. 단순히 많은 결과물을 빠르게 생성하는 것만으로는 부족하며, 여러 맥락을 동시에 유지하고 검증하는 능력이 핵심 역량이 됩니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기“요구사항이 불분명한 프로젝트에 에이전트를 투입하면 잘못된 답을 더 빨리 얻게 된다”고 하지만, 그 속도가 워낙 빨라서 이제는 올바른 요구사항을 찾아내는 최선의 방법이 됨.
생각을 멈춘다면 그렇지 않음. 속도에 눈이 멀어 방향을 의심하지 않는 모습을 갈수록 자주 보게 됨. 시작 전에 충분히 생각하지 않았다면 결과가 틀렸다는 사실은 어떻게 알 수 있을까?
에이전트와 며칠 작업해 기능을 완성했지만, 정작 만들어야 했던 것과는 미묘하게 다를 수 있음. 에이전트는 전체 맥락을 몰랐고, 개발자도 문제를 충분히 이해하지 않아 차이를 발견하지 못한 것임. 다른 기능과 어떻게 맞물려야 하는지 잠시만 생각했어도 알아챘을 수 있음.
예전에는 대규모 아키텍처 변경이 필요해 투자할 가치가 없던 기능도 이제는 에이전트와 코드 상당 부분을 다시 작성해 구현하게 됨. 겉으로는 작동하지만 아무도 원리를 이해하지 못하고, 해결 방식 자체가 잘못됐을 수도 있음. 예전이라면 논의했을 아키텍처의 상충관계를 충분히 검토하지 않은 채 결정하게 됨.
요구사항 목록을 만드는 데 무엇이 더 좋은 출발점일까? 빈 종이일까, 아니면 토큰 비용 4달러와 한 시간으로 한 번에 만들었고 명백히 20군데가 틀린 개념 증명용 시제품일까?
AI 이전부터 존재하던 안티패턴임. 테스터 주도 개발이라고 부를 만함. 제대로 만드는 대신 일단 무언가를 만들고, 실패하면 통과할 때까지 이것저것 무작위로 바꾸는 방식임.
대개 아무도 이해하지 못하고 예상 밖의 상황마다 고장 나는 코드가 됨. AI는 이 과정을 훨씬 빠르게 만들 뿐, 잘못됐다는 사실은 그대로임.
AI가 너무 빠르게 많은 결과를 생성해서 전부 검토하고 평가하기 어려움. 설계나 아키텍처를 물으면 대안 2~3개를 제안하고, 조금만 더 질문해도 어느새 30쪽 넘는 내용이 쌓이곤 함.
검증 비용이 매우 낮고, 틀린 답에서 올바른 답을 추론할 수 있어야 성립함. 둘 다 항상 참인 것은 아님.
어떤 접근법의 치명적인 결함은 한참 뒤에야 드러나고, 실패한 시도를 잔뜩 모아도 올바른 길이 명확해지지 않을 수 있음. 여전히 사고가 필요함.
순차 작업은 여전히 순차적임. 달라진 점은 엔지니어 한 명이 여러 순차 작업을 병렬로 진행할 수 있다는 것임.
티켓 하나를 끝내고 다음 티켓으로 넘어가던 방식은 끝났음. 우리 팀 엔지니어들은 보통 5개 정도를 동시에 진행하며, 훨씬 많을 때도 있음. 여러 기능을 함께 개발하거나, 기능 개발 중에 CI·개발자 경험·도구 개선·버그 수정을 병행함.
앞으로 평범한 엔지니어와 뛰어난 엔지니어를 가르는 것은 기술력이 아니라, 얼마나 많은 맥락을 유지하고 번아웃 없이 작업을 전환할 수 있느냐임.
이슈 5개를 동시에 처리한다는 사람의 세부 사항에 대한 주의력과 업무 태도는 분명 의심스러움. 그보다 훨씬 많다면 더더욱 그럼.
병렬로 진행할 수 있다면 순차 작업이 아닌 것 아닌가?
인간의 멀티태스킹은 작업 품질을 떨어뜨린다는 이유로 이미 반박된 것 아니었나? 결국 제대로 집중하지 못하는 사람을 선발하는 셈임. 아예 TikTok을 작은 화면으로 띄워줘야 흥미를 유지할 듯함.
글쓴이는 첫 번째 예시부터 『맨먼스 미신』을 잘못 적용하고 있음. 아이디어 생성이나 문제 해결·수정이 아니라 소프트웨어 제작에 적용되는 논지임.
제작이라도 비용이 저렴하다면 다름. 서로 조율하지 않고 해결책 100개를 저렴하게 생성한 뒤 빠르게 평가해 최선의 것을 고를 수 있다면, 제작은 수정이나 문제 해결에 훨씬 가까워짐.
“명확한 조율 없이 자율 에이전트 9개를 한 코드베이스에 투입하면 서로의 작업을 고속으로 덮어쓴다”는 것은 쉽게 해결할 수 있는 문제임.
거의 모든 에이전트 실행·조율 도구가 서로 다른 모델의 하위 에이전트나 스레드를 생성하고 협업시키는 기능을 지원함. 특별한 기술도 필요 없음. 기본 Claude 세션에서도 codex로 코드를 검토하고 발견한 사항을 처리하라고 시키곤 함.
이제는 1인월이 아니라 반나절에 가까움. 애플리케이션을 나눠 맡기면 Claude Code를 쓰는 개발자 9명이 전례 없이 짧은 시간에 만들 수 있음.
어떻게 하는 건가? 에이전트 2개만 병렬로 실행해도 서로 작업을 방해하고 기다리며, 성능 테스트도 동시에 실행해서 측정값이 심하게 흔들림.
단, 그 애플리케이션이 실제로 작동하지 않는다는 조건이 붙음. AI 이전에도 작동하지 않는 애플리케이션을 만들었다면 개선이라고 할 수는 있겠음.
제품을 만드는 것과 팔리는 제품을 만드는 것은 다름. 여기서는 어느 쪽을 말하는 건가? 내 생각에 『맨먼스 미신』은 후자를 다룸.
Brooks가 짚은 핵심 중 하나는 조율 비용임. 한정된 영역에서 일하는 사람이 늘수록 조율과 소통도 더 필요해짐.
한 코드베이스에서 서로의 작업을 덮어쓰는 일은 사람도 자주 함. 이런 상황에서는 에이전트도 사람만큼 조율해야 함. 관건은 사람보다 효율적으로 조율해서 이 문제를 덜 겪을 수 있느냐임.
Git worktree와 팀 리더 에이전트가 이끄는 하위 에이전트를 쓰면 됨. 나는 훨씬 빠르게 일을 끝내고 있음. 그냥 잘못 사용하고 있는 것임.
『맨먼스 미신』은 프로그래밍뿐 아니라 그 주변의 모든 과정을 다룸. 대규모 조직의 프로젝트는 아무나 언제든 처리할 수 있는 작업 묶음이 아니라, 단축할 수 없는 단계가 있는 임신에 더 가깝다는 논지임.
반면 이 글은 AI 모델을 병렬화할 수 있는지를 다루는 듯함. 그렇다면 당연히 가능하고, 작업을 병렬로 진행할 수 있도록 분해해야 함. 최전선의 예로 OpenAI의 수학 성과도 에이전트를 대규모로 병렬화해서 나온 것이며, 밀레니엄 문제를 나흘 정도에 풀 수 있었던 이유도 그것임.
에이전트는 시행착오로 문제 공간을 빠르게 탐색하는 데 유용해 보임. 여러 방법을 시도하면서 통하는 것을 찾는 작업, 특히 반복 작업이나 역공학, 성능 최적화에 잘 맞음. 에이전트 군집이 빛나는 영역은 이런 쪽이라고 봄. 다만 에이전트가 해결할 수 있다고 홍보되는 범위보다는 훨씬 좁음.
핵심은 빠른 피드백 순환임. 놀라운 수학 증명을 해내는 LLM이라면 생물학이나 암 연구에서도 대단한 성과를 낼 수 있다고 확신함.
하지만 생물학은 실제 물리적 실험이 필요하고, 생명체를 대상으로 오랜 시간을 기다려야 하는 경우도 많아 반복 주기를 충분히 줄이기 어려움. 실험실을 완벽히 자동화하고 수천 개를 만들어도 순수 수학이나 컴퓨팅 문제의 반복 속도에는 미치지 못함.
LLM은 여전히 자기 자신에게 지시를 작성하는 일에 서툴고, 따라서 스스로를 관리하는 데도 약함. 지시를 지나치게 구체화하는 경향이 있음.
나와 똑같은 복제본이 있다면 “그 일 해줘”라고 하겠지만, 에이전트는 방법과 조건, 사용할 기술, 조립 방식까지 지정함. 하위 에이전트도 똑같이 똑똑한데 구현 선택이 제한되는 셈임. 개발 중 더 나은 구성을 발견해도 최적의 결과보다 지시를 정확히 충족하는 데 시간을 쓰게 됨.
상사의 결정을 의심하거나 설명을 요청할 수도 없고, 구현 방식까지 강요받는 회사와 비슷함. 실제로 그런 회사도 있지만 결과는 대체로 좋지 않음. 물론 일부 작업에는 통하기도 함.
이상하지 않은가? 에이전트의 효율을 크게 높여주니 주요 연구소가 최우선으로 최적화해야 할 작업처럼 보임.
그런데 이것은 /plan이나 계획 수립 기능, PLAN.md 등을 사용하는 일반적인 계획 후 구현 방식 아닌가? 에이전트가 다른 에이전트에 지시할 때 잘못된 방식이라면, 사람이 직접 /plan을 실행할 때도 마찬가지임.
구현하면서 새로운 사실을 발견하는 것이 당연하므로, 구현 에이전트를 그렇게 제약하는 것이 늘 이상하게 느껴졌음. 구현 중 계획과 모순되는 사실이나 계획의 결함을 발견하면 다시 전달하도록 지시해야 할지도 모름.
LLM과 다른 접근법이나 아키텍처를 논의하면 자꾸 “현재 코드가 이것을 사용하지 않으니 버려도 된다”, “현재 코드가 이렇게 동작하니 이 접근법은 호환되지 않는다”로 돌아감. 코드가 무엇을 해야 하는가를 멈춰서 묻는 데 서툼. 바꿀 수 없는 결정도 아닌데, 기존 선택에 제약받기를 좋아하는 듯함.
단순 반복 작업에는 더 저렴한 모델을 쓰는 것이 일반적이지 않은가?
나도 이런 현상을 봤지만 아직 해결법은 모르겠음. “grill me”처럼 집요하게 질문하며 해야 할 일을 체계적으로 구체화하는 데는 가치가 있음. 하지만 결과로 나온 계획이 구현 방식을 지나치게 강제해서, 에이전트가 결국 중요하지 않은 목표를 좇게 될 때도 있음.