요약
AI 에이전트를 늘려도 브룩스의 법칙은 사라지지 않고 모양만 바뀝니다.
얀 반덴베르흐가 1975년 프레더릭 브룩스의 책 『맨먼스 미신』에 나온 법칙을 AI 시대에 맞춰 다시 따져 봤습니다. 늦어진 소프트웨어 프로젝트에 인력을 더 넣으면 더 늦어진다는 법칙이 AI 에이전트에도 통하는지 묻는 글입니다.
왜 중요한가
- 에이전트 수를 늘리는 것만으로는 일정이 당겨지지 않는다는 점을 짚습니다.
- 병목이 사람 수에서 요구사항 정의와 검토로 옮겨 갔고, 그 부담은 결국 에이전트를 부리는 개발자가 진다는 뜻입니다.
핵심 내용
- 사람을 관리하던 부담은 없어지지 않고 에이전트를 관리하는 부담으로 옮겨 갔다고 했습니다.
- 완료 기준 정하기, 코드 검토, 환각(AI가 지어낸 그럴듯한 오류) 잡기, 결과 통합은 여전히 사람 몫입니다.
- 그래서 법칙을 "불분명한 요구사항에 에이전트를 더하면 틀린 답이 더 빨리 나온다"로 고쳐 쓰자고 제안했습니다.
- 아홉 명이 달려들어도 아기를 한 달 만에 낳을 수 없듯, 순서대로 해야 하는 일은 여전히 순서대로 해야 합니다.
- 조율 없이 여러 에이전트를 한 코드베이스에 풀면 서로의 작업을 덮어쓰며 빠르게 헛돈다고 했습니다.
HN 반응
- 틀린 답이 빨리 나오니 오히려 요구사항을 찾는 좋은 방법이라는 의견과, 속도에 눈이 멀어 틀린 줄도 모른다는 반론이 맞섰습니다.
- AI가 잘하는 개발자와 대충 하는 개발자의 차이를 함께 키운다는 경험담이 많았고, 동료들의 실력이 눈에 띄게 줄었다는 증언도 나왔습니다.
우리 팀 개발자들을 보면서 흥미로운 점을 발견했습니다.
잘하는 사람들은 예전보다 훨씬 빠르게 좋은 해법을 내놓고 있습니다.
그렇지 못한 사람들은 예전에 하던 엉터리 짓을 그대로 하면서, 이제는 확인조차 하지 않습니다. 예를 들어 "프런트엔드에는 구현하지 말 것"이라는 요구사항이 있었는데, 일부라도 프런트엔드에 구현되어 있다는 이유로 PR이 세 번이나 반려됐습니다.
이유가 뭔지는 잘 모르겠지만, 아마 이런 것 같습니다.
아키텍처 선택과 그 결과를 이해하지 못함
"귀찮게 하지 말고 월급이나 줘"라는 태도
결국 AI가 사람의 좋은 면과 나쁜 면을 모두 증폭시킨 셈입니다.
이거 저예요, 인정합니다. 예전에는 코드 리뷰를 받고 머지하려면 제대로 동작하는 해법을 꼼꼼하게 만들어야 했습니다. 그게 보통이었고요. 그렇게 만든 건 내가 직접 썼으니 자랑스러워할 만한 좋은 작업물이었죠!
그런데 이제는 예전에 저를 꼼꼼히 검토하던 사람들(말씀하신 잘하는 개발자들)이 에이전트로 저보다 훨씬 빠르게 일하면서 저를 여전히 꼼꼼히 검토합니다. 동료들 앞에서 제 평범함을 실감하게 됩니다. 그래서 이제는 일의 품질에 별로 신경 쓰지 않습니다. "먹고살 만큼만 하자"의 기준선이 훨씬 높아졌고, 저는 거기에 맞추느라 허덕이고 있으니까요.
올해 월급쟁이 일은 온 힘을 쏟을 만한 동기가 못 된다는 걸 깨달았습니다. 이런 가드레일과 경영진의 결정 아래 갇혀 있는 게 그 어느 때보다 질립니다.
신경 쓰는 사람을 그렇지 않은 문화 속에 던져 놓으면 이렇게 됩니다. 그 문화는 단기 목표만 맞춰 내놓고 대가는 나중에 치르자는 식이니까요. 어떤 프로젝트에서는 그래도 말이 되지만, 고객이 정말 의존하고 실패 비용이 큰 서비스 같은 곳에서는 명백히 단기적인 사고입니다. 속도가 회사의 유일한 해자라면 남는 건 죽음의 행군뿐입니다.
제 상황도 아주 비슷합니다.
저도 이런 생각이 들어요. 월급은 그대로인데 왜 임원들에게 생산성을 더 퍼 줘야 하죠? 미국의 청교도적인 노동 숭배와 개인주의적 경쟁 문화는 평범한 사람들의 삶이 나아지는 데 전혀 도움이 안 됩니다.
저는 미국 직장 사정을 잘 몰라서 그런데, 연봉 협상이라는 게 없나요? 연봉이 불만이라면 더 높은 연봉을 요구할 협상력을 키우고 싶지 않으세요? 그리고 고객이나 최종 사용자가 아니라 임원을 위해 일한다고 느끼게 만드는 업무 구조가 뭔지도 궁금합니다. 내 시스템을 쓰는 사람들이 매끄럽게 쓰기를 바라는 게 당연하지 않나요?
최종 사용자를 만족시키는 건 부수 효과일 뿐입니다. 제 안녕이 먼저예요.
다른 답글에서도 비슷한 말씀을 하셨으니 여기서 답하겠습니다. 성과는 경영진이 가져가는데 제가 왜 뼈 빠지게 일하며 사용자를 기쁘게 해야 하죠?
연봉 협상을 해도, 어느 회사에서든 내가 회사에 가져다주는 가치에 걸맞은 보상은 거의 받을 수 없습니다. 원래 그렇게 설계돼 있어요. 기본급을 받는 대신 소득이 갑자기 끊길 위험을 넘기는 거니까요.
저는 이제 그 위험이 그다지 무섭지 않은 지점에 와 있는데, 스스로도 이상합니다. 예전에는 그 위험을 감수하는 걸 생각해 본 적도 없거든요. 그리고 창업자들은 대개 지금 제가 느끼는 이런 감정에 이끌려 나선다는 걸 배우고 있습니다.
그렇지 않습니다. 미국 기업들은 연봉 이야기를 꺼내는 것 자체를 노동자의 결함으로 여기는 문화를 만드는 데 성공했어요. 충성심이 부족하다는 증거처럼 취급하죠.
상황이 나아지고는 있지만 인사팀은 여전히 연봉을 다른 사람과 절대 공유하지 말라고 입버릇처럼 말합니다. 그러면 해고당할 수 있다고 넌지시 암시하는 경우도 많고요.
연봉 협상은 연간 생활비 인상분이나 승진 때로 한정돼 있습니다. 그 밖에는 연봉 얘기를 하는 게 아예 기대되지 않아요. 절대로요.
어느 정도는 동의하지만, 요즘은 일자리가 있다는 것만으로도 운이 좋은 편이라서 안타깝게도 그게 우선이죠.
바로 그런 "나는 챙겼으니 알 바 아냐" 하는 태도가 정치가 우경화하는 이유 중 하나입니다. 그리고 최악인 건, 저도 이해는 간다는 점이에요. 다만 제 사회 지향적인 가치관과는 맞지 않을 뿐입니다.
세금이나 사회보험료를 내는 건 괜찮아요. 그런데 지금은 매달 생활비를 맞추려고 정기적으로 저축을 헐어 써야 하고, 몇 년째 저축 통장에 들어가는 돈이 하나도 없습니다.
솔직하게 말씀해 주셔서 고맙습니다.
운이 좋으시네요. 제가 불행히도 코드 리뷰를 해 준 사람들은 전부(대략 10명) LLM 코드 생성을 쓰기 시작한 뒤로 역량이 승진 단계로 0.5에서 3단계쯤 떨어졌습니다. 그리고 잘하던 개발자일수록 잃을 실력이 더 많아서 더 심했습니다.
제가 개인적으로 가장 "좋아하는" 사례는, 반년 전쯤 저를 온보딩해 준 리드 엔지니어가 "날 JS 날짜 객체 쓰지 말 것. 날짜와 관련된 건 전부 이 라이브러리를 쓸 것"이라고 직접 정해 둔 문서화된 정책을 잊어버린 일입니다. 그는 자바스크립트 날짜를 쓰는 MR을 올렸는데, 그걸로 복잡한 연산까지 했습니다(그것도 틀리게요. 시간대, 서머타임, 윤일이 있는 해, 30일이 아닌 달을 전혀 고려하지 않았거든요).
제가 보기엔 사람들이 신중한 수준보다 빨리 운전하거나 운전하면서 휴대폰을 쓰는 이유와 똑같습니다. 사고가 나기 전까지는 안전하고 기분 좋게 느껴지니까요. 게다가 대부분의 조직은 명세의 상세함도, 테스트 커버리지도, 리뷰 커버리지도 근처에도 못 미치기 때문에 망가진 부분이 한참 뒤에야 발견됩니다.
많은 사람에게는 (체감상) 사소한 디테일에 신경 쓰거나 집착하지 않게 된 것이라고 생각합니다. AI 덕분에 더 높은 수준에서 일하기가 아주 쉬워졌으니까요. (확실하지는 않지만) 리드나 관리직으로 올라간 개발자들 상당수도 마찬가지일 것 같습니다. 어느 시점이 되면 디테일은 개인적으로 크게 중요하지 않게 되고, 에너지를 다른 곳에 써야 하니까요.
그래도 사람들이 지표를 모으고 있기를 바랍니다. 얼마 전 장애가 증가 추세라서 추가 회의를 했는데, 주로 그것이 여러 부서(예: 고객지원)에 어떤 영향을 주는지, 매출 손실 가능성이 얼마나 되는지(가입 페이지가 사흘 동안 죽어 있으면 제품이나 서비스를 팔 수 없죠)를 논의했습니다.
문제는 그런 장애에 단일한 원인이 없다는 겁니다. 엔지니어가 수백 명이고, 애플리케이션과 서드파티 연동이 수십 개이며, 각자 다른 기기 조합을 쓰는 (잠재) 고객이 수백만 명이라 모든 걸 통제하기란 사실상 불가능합니다.
하지만 이건 엄격한 정책 아래서 주의 깊은 사람이 짠 코드냐 즉흥적으로 알아서 짜낸 AI 코드냐를 넘어서, 실시간 모니터링이나 장애 대응 같은 한 단계 위의 문제로 이어집니다.
관리직이나 스태프급 이상으로 올라가면 개별 디테일이 덜 중요해진다는 말씀은 맞습니다. 더 전략적이거나 운영적인 수준에서 일하게 되니까요. 하지만 누군가는 여전히 사소한 디테일에 집착해야 합니다(논의를 쉽게 하려고, 실제로 중요한 디테일만 말하는 것이고 그 범위에 대해서는 폭넓은 합의가 있다고 가정하겠습니다). 그 디테일이 그들에게 중요하지 않게 되는 게 아닙니다. 다른 누군가가 자기 대신 그 디테일을 챙겨 줄 것이라는 가정, 혹은 약속에 의존해야 더 넓은 시야로 일할 수 있게 되는 것이죠.
문제는 아무도 그 디테일을 실제로 챙기지 않게 됐을 때 생깁니다. 디테일을 챙기는 사람이 없으면 상위 수준의 일은 훨씬 덜 유용하고 덜 효과적이 되고, 최악의 경우 아무 의미도 없어집니다.
저도 같은 걸 보고 있습니다. 기술이 꽤 빠르게 퇴화하고, 사람들이 집중력을 유지하지 못하며 전반적으로 감각이 무뎌지고 있어요. 숏폼 영상이 일으키는 브레인 롯이 LLM을 통해 우리 업계에도 퍼지고 있습니다. 이런 일이 벌어지는 걸 보는 건, 특히 제가 아끼는 사람들에게서 보는 건 전혀 즐겁지 않습니다.
이 댓글을 읽기 전까지는 왜 숏폼 콘텐츠와 우리 업계의 LLM 사이의 유사성을 보지 못했는지 모르겠는데, 정말 적절한 비유입니다. 저도 그런 인상을 받고 있어요. 저는 숏폼 콘텐츠 공장을 전염병처럼 피하듯이 "에이전트형 코드 생성"도 최대한 멀리합니다. 다만 LLM은 리서치 보조로서는 저에게 엄청난 도움이 됐습니다. 아주 지엽적인 문제를 찾아보고 나에게 맞춰진 답을 받을 수 있다는 건 멋진 일이에요. 덕분에 머리는 계속 날카롭게 유지되고, 조각을 직접 맞춰 가는 재미도 예전보다 훨씬 빠르게 누리고 있습니다.
저는 (아직은?) 리서치 보조로 LLM이 마음에 들지 않습니다. 환각을 떨쳐낼 수가 없어서요. 정확히 말하면 하늘이 파랗다고 하는데 지금 흐린 날씨는 아닌지 확인하느라 시간을 너무 많이 낭비하게 됩니다.
하지만 특히 코드가 점점 더 빠르고 더 대충 던져지는 지금은, 린터가 쉽게 잡지 못하는 특정 항목을 확인하거나 제가 찾기 전에 보안, 구현, 아키텍처 결함을 찾아내는 코드 리뷰에는 꽤 훌륭해지고 있다고 봅니다. 예를 들면 이런 질문입니다. 'knex.raw에 템플릿 리터럴을 쓰는 코드가 있나?', '더 나은 방법 대신 N+1 DB 조회를 하고 있나?', '추가하거나 수정한 테스트가 여기 정의된 테스트 케이스 템플릿을 따르고 있나?'
동의합니다. 저는 코드베이스를 작성하는 도구보다 코드베이스를 질의하는 시스템으로서의 AI를 더 신뢰합니다.
인간 의도의 증폭기죠. 열심히 일해서 암을 정복하고 싶으세요? 좋습니다! AI가 도와줄 수 있어요. 대충 시간만 때우면서 최소한만 하고 싶으세요? AI는 그것도 도와줄 수 있습니다.
문제는 틀린 답이 너무 빨리 나와서, 이제는 그게 올바른 요구사항을 알아내는 가장 좋은 방법이라는 겁니다.
머리를 꺼 놓지 않는다면 그렇겠죠. 지금 가는 길이 맞는지 한 번도 따져 보지 않고, 속도에 눈이 멀어 버리는 경우를 점점 더 많이 보는 것 같습니다. 애초에 시작하기 전에 충분히 생각해 보지 않았다면 틀린 답인지 어떻게 알죠?
한 가지 예를 들겠습니다. 에이전트를 어떤 작업에 풀어 놓고 계속 돌려서 며칠 뒤 기능 하나가 나옵니다. 그런데 그건 만들어야 했던 게 아닙니다. 에이전트는 맥락을 다 갖고 있지 않아서 조금 어긋난 걸 만들었고, 나는 문제를 충분히 내재화하지 못했기 때문에 그걸 알아채지도 못합니다. 예전처럼 이 기능이 다른 부분과 어떻게 맞물려야 하는지 잠깐 멈춰서 생각했다면 알아챘을 겁니다.
두 번째 예입니다. 예전에는 들이는 시간에 비해 가치가 없어서 하지 못했던 일이 있습니다. 구현하려면 아키텍처를 크게 바꿔야 하는 기능 같은 것이죠. 에이전트와 함께 시도해서 코드 상당 부분을 갈아엎었고 동작하는 것 같습니다. 하지만 이제 어떻게 동작하는지 아무도 모르고, 잘못된 해법일 수도 있는데 그냥 밀고 나갔습니다. 예전 같으면 앉아서 아키텍처의 트레이드오프를 논의하고 고민했을 텐데, 이제는 별생각 없이 결정 하나가 내려져 버렸습니다.
반대 논거도 있습니다. 매몰 비용 오류가 문제가 됐다는 얘기는 거의 들어 본 적이 없죠.
저는 AI 없이 일할 때 일주일 동안 작업하고 나서야 틀렸다는 걸 깨닫는 일이 있었는데, 그때는 너무 많은 시간을 쏟았으니 계속 밀고 나갈 유인이 더 커서 매몰 비용을 무시하기 어려웠습니다.
이제는 신경 쓰지 않습니다. 한 시간이면 되니까 버리고 다른 걸 시도하는 데 아무 부담이 없어요.
팀으로 일할 때는 이 말이 더 와닿습니다. 며칠 동안 손으로 코딩한 팀원에게 잘못된 방향으로 가고 있다고 설득하는 것이 AI로 만든 팀원을 설득하는 것보다 더 어렵습니다. AI가 쓴 코드에는 개인적인 애착이 없으니까요. 물론 직접 손으로 썼을 때처럼 모든 줄을 이해하지 못한다는 뜻이기도 하지만, 애착이 없다는 건 분명 이점입니다.
프로그래머에게 하던 일을 멈추라고 설득해야 하는 상황이 아주 드물게보다 더 자주 생긴다면, 제 생각에는 리더십이 나쁘다는 강한 신호입니다. 이 사람들은 자기가 하는 일을 정말 사랑하고 그래서 애착이 큰 건데, 그 애정을 내쫓고 싶으신가요?
그래서 이 글에서 제가 얻을 수 있는 교훈은 다음과 같습니다.
AI는 나쁜 리더십을 완화하는 수단으로 쓸 수 있다.
프로그래머는 자기가 하는 일에 훨씬 덜 신경 써야 한다.
아닙니다. 기술적 불확실성을 해소하려고 프로토타입이나 스파이크를 만드는 건 건전한 관행입니다. 그런 건 버려도 되는 것으로 취급해야 합니다.
가끔 사람들이 프로토타입에 애착을 갖는데, 그러면 역효과가 납니다. 가장 흔한 예는 "잘했어요, 2주짜리 스파이크로 이 프로젝트가 실현 불가능하다는 걸 알았으니 접고 더 임팩트 있는 프로젝트로 넘어갑시다" 같은 경우입니다.
AI를 쓰면서 저도 같은 행동을 봤습니다. 사람 피드백을 구하지도, 같은 문제를 다룬 선행 사례가 있는지 스스로 묻지도 않고 계속 밀어붙입니다. 결국 매몰 비용 오류에 빠질 뿐 아니라 섀도 IT 여정까지 거쳐 몇 주 만에 세대를 넘나드는 기술 부채를 쌓아 올립니다.
피드백 루프와 동료의 건설적인 피드백을 받을 자리를 스스로 만들지 않는다면 AI도 그 문제를 해결해 주지 못합니다.
"같은 문제를 다룬 선행 사례가 있는지 스스로 묻지도 않고"
AI에게 묻는 것이 곧 바퀴를 또 발명하지 않도록 선행 사례를 묻는 일입니다.
반대로 전부 바꾸는 데도 실제 비용이 어느 정도는 있어야 한다고 봅니다.
덜 익은 기능을 출시해 놓고 그다음 몇 주 동안 큰 덩어리를 뜯어내 갈아 끼우면서 온갖 문제를 일으키는 사람들을 봅니다.
글쎄요. "하나는 버릴 각오로 만들어라"라는 말 들어 보셨죠?
데모가 눈앞에 있으면 고객이 실제로 뭘 원하는지 논의하기가 언제나 더 쉽습니다.
저는 점점 더 프로덕트 오너와 짧은 피드백 루프를 돌리고 있고, 같은 스프린트 안에 끝나기도 합니다. 자전거 창고 논쟁(bikeshedding)조차 돌아오지 않는데, 꽤 탄탄한 디자인 가이드라인이 있어서일 수도 있겠네요.
아니면 그게 사실은 원하던 게 아니라는 사실조차 깨닫지 못합니다. 말끔히 다듬어진 제품이 눈앞에 있으면 처음에 가졌던 흐릿한 아이디어와 비교하기가 어렵거든요.
천천히 가야 디테일이 해법을 빚어낼 시간이 생긴다고 생각합니다. "음, 이건 생각만큼 말이 안 되네, 문제를 다르게 정의하는 게 더 나을지도 몰라..." 하는 순간이 오죠. 문제가 충분히 스며들게 두지 않으면 리치 히키가 말하는 "해먹 주도 개발(hammock driven development)"을 얻지 못합니다.
물론 스며들 필요 없는 문제도 있습니다. 많은 문제는 그냥 코드를 쭉 뽑아내면 됩니다. 저는 딱 한 가지 문제를 완벽하게 해결하는 괴물 스크립트를 대충 이어 붙이는 걸 정말 좋아합니다.
완전히 렌더링된 컨셉 아트를 놓고 논의하는 것과 같습니다. 그림에 빠져 길을 잃게 되죠. 게다가 "이미 이렇게 멋진데 뭘 더 깊이 생각해" 하는 은근한 암시가 늘 따라붙습니다. 그래서 브레인스토밍에는 스케치나 대충 칠한 썸네일이 가장 좋습니다. 그래야 틀을 벗어나 생각하기 쉬우니까요.
데모도 마찬가지입니다. 대충 와이어프레임을 그리거나 기본 부트스트랩 스타일로 만들면 문제의 핵심을 겨냥하기가 훨씬 쉽습니다. 완성된 사이트로는 그렇지 않고요.