# AI가 여러분의 프로세스를 더 빠르게 만들지는 않을 것 같습니다 > Clean Markdown view of GeekNews topic #29610. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29610](https://news.hada.io/topic?id=29610) - GeekNews Markdown: [https://news.hada.io/topic/29610.md](https://news.hada.io/topic/29610.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-18T09:58:25+09:00 - Updated: 2026-05-18T09:58:25+09:00 - Original source: [frederickvanbrabant.com](https://frederickvanbrabant.com/blog/2026-05-15-i-dont-think-ai-will-make-your-processes-go-faster/) - Points: 5 - Comments: 1 ## Topic Body - 프로세스 최적화 흐름 속에서 AI에 대한 **비현실적 기대**가 확산되고 있으나, 단순히 AI 도입만으로 처리 속도가 개선되지는 않음 - 소프트웨어 개발이 오래 걸리는 진짜 원인은 코딩 속도가 아니라, **모호한 요구사항을 명확한 문제 정의로 전환하는 과정**에 있음 - AI 코드 생성도 동일한 **업스트림 문제**에 직면하며, 정확한 결과를 위해 도메인·제품 전문가의 깊은 개입이 필수적임 - AI 활용 비교 사례에서 흔히 누락되는 **핸드홀딩(handholding) 과정**이 실제 생산성 격차를 만들며, 인간 개발자도 동일한 상세 문서를 받으면 생산성이 급상승함 - 진정한 프로세스 가속화를 위해서는 The Goal의 교훈처럼 **"병목 지점에 예측 가능하고 고품질의 입력을 공급"** 하는 것이 우선 과제임 --- ### 시장 침체 속 프로세스 최적화와 AI 기대 - 시장이 침체될 때 조직 대부분이 부분적으로라도 프로세스 최적화에 집중하는 경향, 최근에는 여기에 AI라는 요소와 **비현실적인 기대**가 더해지는 상황 - [The Toyota Way](https://en.wikipedia.org/wiki/The_Toyota_Way)와 [The Goal](https://en.wikipedia.org/wiki/The_Goal_%28novel%29)은 많은 프로세스 최적화가 무엇에 집중해야 하는지 오해하기 쉽다는 점을 떠올리게 함 - 오래 걸리는 구간은 개선을 시작할 신호일 수 있지만, 문제가 실제로 생기는 지점이라고 단정할 수 없음 - 단순히 사람을 더 투입하거나 AI가 속도를 크게 높일 것이라고 기대하면, 왜 일이 늦어지는지 보지 못함 - 프로세스를 빠르게 하려면 작업자가 실제로 일을 시작하고 끝낼 수 있는 **입력과 조건**을 갖췄는지 먼저 확인해야 함 ### 시각적 병목(The visual bottleneck) - Gantt 차트 예시를 통해 가장 오래 걸리는 단계가 **소프트웨어 개발**임을 시각적으로 확인 가능 - 본래 BPMN을 사용하는 것이 일반적이나, 설명을 쉽게 하기 위해 Gantt 차트로 제시 - 프로젝트 throughput 개선이 목표라면 가장 오래 걸리는 단계를 우선 살펴보는 접근 자체는 옳음 - 문제는 사람들이 이를 해결하는 방식 - 인력을 더 투입(throw people at the problem) - AI가 훨씬 빠르게 만들어 줄 것이라 가정 - 정작 **"왜 이 단계가 오래 걸리는가"** 를 들여다보지 않음, 더 중요한 점은 **소요 시간이 길다고 해서 문제의 원인이 그 단계에 있는 것은 아님** ### 업스트림에서 문제 해결하기 - 소프트웨어 개발을 예로 들지만, 원하는 것보다 오래 걸리는 모든 프로세스에 동일하게 적용 가능 - 소프트웨어 개발은 단순히 **타이핑 속도**를 높인다고 빨라지지 않음, 그렇다면 모두가 타이핑 수업을 듣고 있었을 것 - 소프트웨어 개발의 본질은 **문제를 컴퓨터가 자동으로 해결할 수 있는 솔루션으로 번역하는 작업**, 가급적 안전하고 확장 가능한 방식으로 - 이를 위해서는 문제에 대한 전체적인 이해가 필요함 - 워터폴 방식에 가깝다면 기능 문서나 범위 문서가 필요함 - 애자일 방식이면 도메인 전문가와의 지속적 반복(iteration) - 실제로 개발을 느리게 만드는 부분은 **제목만 있는 모호한 feature 요청이 무엇을 의미하는지 파악하는 과정** - **"판매가 완료되면 사용자에게 메일을 보낸다(send mail to user once sale is completed)"** 이 요청도 바로 구현 가능한 요구사항이 아님 - 메일을 보낼 수는 있지만 메일에 무엇이 들어가야 하는가 - 판매 프로세스에 문제가 있었다면 오류 메일은 보내야 하는가 - 판매가 "완료"되는 시점은 언제인가 ### AI에 다 맡기면 된다는 주장 - 자주 듣는 주장은 **AI 코드 생성**으로 개발 단계를 우회하고, 소프트웨어 개발자가 프로젝트 매니저 역할만 하면 된다는 것 - 많은 사람은 기존의 긴 소프트웨어 개발 구간이 3일 정도의 **AI 개발** 구간으로 대체될 것이라고 기대함 - 사람들이 기대하는 AI 개발의 결과 모습이 있으나, 실제로는 그렇게 작동하지 않음, 동일한 **업스트림 이슈**에 그대로 직면 - AI가 코드를 빠르게 생성할 수 있다는 점은 사실(그것이 좋은 일인지는 별개 논쟁)이지만, **빠른 생성이 곧 올바른 코드 생성은 아님** - 인간 vs AI 개발 비교에서 항상 무시되는 것은 AI가 제대로 작동하도록 하기 위한 **핸드홀딩(handholding)** 과정 - 이 방식이 기존 방식보다 빠를 수는 있지만, **공정한 비교가 아님** - AI 개발이 작동하려면 도메인 전문가와 제품 전문가의 훨씬 깊은 참여가 필요함 - 모든 기능을 아주 작은 세부사항까지 작성해야 함 - 모든 버그 수정도 원하는 결과가 무엇인지 자세히 정리해야 함 - 이것이 바로 소프트웨어 개발자들이 직업이 시작된 이래로 줄곧 요구해 온 것, 즉 **문제와 최종 결과물에 대한 상세한 개요 제공** - 인간 개발자에게 동일한 분량의 feature/scope 문서를 제공하면 생산성도 급격히 향상될 것 ### 실제로 프로세스 속도를 올리는 방법 - 프로세스 속도를 높이려면 일을 해야 하는 사람들이 **실제로 그 일을 할 수 있는 수단을 모두 갖추도록** 보장해야 함 - 법률 승인 프로세스가 느리다면, **법률 승인 프로세스를 시작하기 위해 무엇이 필요한지** 먼저 살펴야 함 - 불완전한 문서 때문에 다섯 명을 쫓아다녀야 하는 상황이라면, 부서에 변호사를 더 투입해도 속도가 빨라지지 않음 - [The Goal](https://en.wikipedia.org/wiki/The_Goal_%28novel%29)의 큰 교훈 중 하나는 병목이 예측 가능하고 품질 높은 입력을 받아야 한다는 것임 - **"bottlenecks should receive predictable, high-quality inputs"** - **프로세스 자동화의 첫 번째 출발점**은 병목 구간 자체가 아니라, 병목이 받을 **입력 품질**과 예측 가능성을 높이는 쪽이어야 함 ## Comments ### Comment 57664 - Author: neo - Created: 2026-05-18T09:58:25+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48168221) - 소프트웨어 개발이 처음부터 원해 온 건 “문제와 원하는 결과를 자세히 설명받는 것”이라는 말이 있지만, 사실 그 자체가 **소프트웨어 엔지니어링**임 2026년에도 충분히 자세한 요구사항과 명세만 있으면 완벽한 해법을 한 번에 만들 수 있다는 생각은 버려야 함 내 경험상 AI 덕분에 기능이나 아이디어를 훨씬 빠르게 반복할 수 있게 됐고, 이제 마찰은 대부분 다른 팀과의 정렬과 조율에서 생김 프로세스를 빠르게 하려면 **조율 비용**을 줄이고 개인과 팀이 판단하고 실행할 권한을 더 가져야 한다고 봄 - 2026년에는 충분히 자세한 요구사항이 있어도 작동 가능한 해법조차 한 번에 만들 수 있다는 생각도 버려야 함 Anthropic도 완벽한 명세, 참조 구현, 수년간 사람이 쓴 수천 개의 테스트가 있었는데도 작동 가능한 **C 컴파일러** 같은 단순한 것조차 만들지 못했음 현재 모델은 완벽한 명세와 완벽한 테스트가 있어도, 세심한 사람의 감독 없이 사소하지 않은 운영 소프트웨어를 만들 만큼 충분하지 않음 완벽한 명세와 사람이 직접 쓴 완벽한 테스트 묶음이 없다면 더 어려워지고, 아마 2027년쯤 가능할지도 모름 - 동의하지 않음 오후에 제품 담당자가 떠올린 작업을 자주 받는데, 그들은 정상 경로만 신경 쓰고 때로는 그 일부만 신경 씀 글로벌 회사라 각 국가의 규정과 법을 지켜야 하는데, 기능을 구현한 뒤 “사실 우리가 운영하는 시장의 90%에서는 법적으로 이걸 할 수 없다”는 말을 듣고, 다시 비활성화 기능을 붙임 그러고 나면 “그중 일부 시장에서는 **규제 절차**를 거치면 가능하니 그렇게 구현해 달라”고 돌아옴 마감이 코앞이라 결국 해법을 해킹하듯 고쳐야 함 이건 소프트웨어 엔지니어링이 아니며, 소프트웨어 자체와도 관련이 없음 소프트웨어 엔지니어의 일은 요구사항 목록을 받아 그 요구사항을 달성하는 방법을 찾는 것이고, **요구사항 수집**은 소프트웨어 엔지니어링 문제가 아님 소프트웨어는 구현이고 제품은 동작이며, 만들 대상의 동작은 진지하게 만들기 전에 알려져 있어야 함 누군가 일주일만 미루고 실사를 했다면 확장 가능하고, 확장하기 쉽고, 유지보수하기 쉽고, 미래를 더 편하게 만드는 구조를 설계할 수 있었을 것임 - 완전히 동의함 첫 프로그램을 쓴 지 40년이 넘었지만, 먼저 명세를 완성하고 그다음 소프트웨어를 작성해서 모든 게 잘된 경우를 본 적이 없음 사소하지 않은 엔지니어링에서 가장 어려운 부분은 **문제를 이해하는 것**이고, 소프트웨어의 초기 버전들은 그 이해에 도달하는 방식임 그래서 AI 기반 “소프트웨어 공장”은 절대 잘 작동하지 않을 거라고 봄 결국 다시 폭포수 개발이고, 아키텍트가 UML 다이어그램을 쓰고 프로그래머 팀에게 본질적으로 단순한 구현 작업을 넘기지만, 정작 **틀린 것**을 구현하게 됨 AI는 틀린 첫 번째 버전에서 덜 틀린 두 번째 버전으로 빠르게 가는 데는 매우 좋음 다만 핵심 임무가 해결하려는 문제를 이해하는 것임을 잊으면 안 됨 - 모호한 요구사항을 해결할 최선의 방법을 찾는 일이 좋아서 엔지니어링에 들어왔음 자세한 명세만 받는다면 그냥 코딩 로봇일 뿐이고, 그런 일은 주니어에게 넘김 - 요즘 의사결정자나 요구사항을 쓰는 사람들도 AI를 쓰기 시작하는 걸 일상에서 봄 예전처럼 내 일은 그 요구사항을 읽고, 이해하고, 내가 아는 현실에 비춰 검증하는 것임 코드도 마찬가지임 지난 최소 20년간 소프트웨어 엔지니어링의 핵심은 **아무도 믿지 말라**였고, 이건 변하지 않았으며 여전히 많은 시간과 노력이 듦 - LLM이 처음 나왔을 때는 사람들이 “Facebook 클론 만들어줘” 같은 식으로 말하면 된다고 생각했던 것 같음 이제는 요구사항을 더 정확히 쓰고 더 잘 정의해야 한다는 걸 깨닫고 있음 이것이 늘 소프트웨어의 **병목**이었음 예전에 일할 때는 “데이터를 가져와서 사용자에게 줘” 같은 요구사항을 실제로 받았음 어떤 데이터인지, 어디 저장돼 있는지, 어떤 형식으로 반환해야 하는지 정의가 없어서 제품 담당자와 긴 시간을 들여 진짜 원하는 걸 찾아야 했음 LLM으로 좋은 결과를 얻으려면 비슷한 일이 필요하고, 모호한 요구사항은 모호한 결과를 낳음 - 내가 본 바로는 PM들이 **Claude Code**나 **Codex**처럼 코드베이스에 연결된 AI를 써서 티켓이 훨씬 더 상세해졌음 어떤 문제가 왜 있는지, 예를 들어 백엔드에는 X 필드가 있지만 프런트엔드에는 없다는 식으로 템플릿을 채우고, 데이터를 어디서 어떻게 가져올지, 수용 기준은 무엇인지까지 적음 예전에는 게으름이나 “개발자가 알아서 하겠지”라는 생각 때문에 하지 않았을 일임 이후 개발자는 이 Jira 티켓 내용을 원하는 LLM 에이전트에 복사해 붙여넣거나, Atlassian MCP로 LLM이 자동으로 읽게 할 수 있음 이 덕분에 개발자에게 큰 도움이 됐고 요구사항도 매우 명확해졌음 솔직히 첫 단계만 보면 PM들이 이미 기능 구현의 절반까지 와 있는 것 같아서, 미래에는 PM들이 전부 직접 하고 몇몇 개발자는 완전한 구현자라기보다 **SDET**처럼 남을지도 모르겠음 - 이건 Fred Brooks가 1986년 고전 에세이 **No Silver Bullet**의 “Expert Systems”와 “Automatic Programming” 절에서 상당 부분 예측했음 거기서 바이브 코딩의 핵심 특징과 지금 우리가 겪는 경험을 정확히 설명함 신중히 선택된 몇몇 영역에서 초기 성공을 거둔 뒤, 그 영역 밖으로 확장되면서 합리적이지만 혁명적이지는 않은 생산성 향상이 나타난다는 내용임 [https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...]() - 완전히 맞고, 이건 당연하다고 생각했음 “Facebook 클론 만들어줘”에 가까운 프롬프트를 써 본 적이 없고, 대신 어떻게 동작해야 하는지 설명함 예를 들어 `/etc/hosts`를 읽고, `.conf`에서 설정된 특정 호스트 값을 찾고, 각 설정에 이름을 붙이고, 현재 환경을 판단하며, Ubuntu 22 기본 GNOME 오른쪽 위에 아이콘을 만들고, 클릭하면 설정 이름을 나열하고, 선택 시 `/etc/hosts`를 백업한 뒤 특정 호스트명 줄만 수정하는 **Python 스크립트**를 요청했음 이걸로 단순한 GNOME 앱 표시기 환경 전환기가 거의 한 번에 나왔고, 몇 줄만 고치면 대부분 동작했음 LLM에 제대로 된 명세를 주면 잘 만들며, 원하는 걸 설명하기 위해 가짜 DSL을 만들어도 알아서 이해함 - 이제 제품 책임자들이 자기 일을 LLM에 떠넘기려 함 이전 프로세스가 안 됐던 이유는 요구사항 작성자가 비즈니스 의도를 이해하지 못했거나 부주의해서 모호하거나 나쁜 요구사항을 냈기 때문임 LLM은 같은 모호하거나 나쁜 요구사항을 그럴듯해 보이게 만들 뿐이고, 깊이 파보면 문제가 드러남 - 더 나쁜 점은, 사람으로 된 소프트웨어 팀이라면 모호한 요구사항에 대해 적어도 잘 운영되는 조직에서는 추가 명세를 요구한다는 것임 “‘데이터를 가져온다’가 무슨 뜻인가요?” 같은 질문이 나옴 LLM은 그냥 “물론이죠! 데이터를 가져와 사용자에게 주는 완성된 코드입니다”라고 하고 끝냄 - 이 글은 AI가 개발 단계에만 영향을 준다고 가정하지만, 그건 확실히 사실이 아님 아이디어 발상, 법무, 문서화, 개발, 배포를 포함해 모든 단계의 속도를 높일 수 있음 아이디어 발상에서는 아이디어를 주고받고 지식 기반과 대조하며 설계 문서를 만들 수 있고, 문서화에서는 문서의 큰 부분을 생성할 수 있음 개발은 당연하고, 배포에서는 배포 매니페스트와 테스트 도구, 클라우드 플랫폼 관련 지식을 만들 수 있음 모든 단계가 AI로 더 낫고 빠르게 될 수 있으며, 전부는 아니어도 많은 부분이 가능함 개발도 마찬가지로, 문제를 누구보다 잘 이해하고 해법을 만드는 부분도 있지만 순수하게 잡일인 부분도 있음 버튼이 X를 해야 한다는 걸 알고 있다면 그 버튼을 디자인하고 배치하고 hover와 press 상태의 예외를 생각하고 백엔드에 연결하는 작업은 건너뛸 수 있는 **잡일**이며, 거의 모든 단계에 같은 원리가 적용됨 - 글에 대체로 동의함 새로운 중요한 기능을 추가하려고 하면 보통 업무 담당자들과 며칠, 몇 주, 몇 달씩 회의하면서 시스템 X, Y, Z 사이에서 일이 어떻게 흐르는지와 중요한 예외들을 이해해야 함 예를 들어 하위 집합 A는 이렇게 처리하고 B는 저렇게 처리하지만 마지막 단계에서는 두 그룹을 합치며, 단 C는 특수 프로세스 97이 필요하다는 식임 그 이해를 바탕으로 여러 시스템에 걸친 **시스템 해법 설계**가 따라오고, 내부 시스템과 벤더 시스템이 섞이며 각 시스템의 커스터마이즈 가능 수준이 달라 최종 해법의 형태를 여러 방향으로 밀어냄 코딩 속도를 높이는 데 가치는 분명 있지만, 퍼즐의 한 조각일 뿐이고 현재 LLM은 도메인 정보를 수집하고 해법을 정의하는 데 도움을 주지 못함 - 우리 조직의 경험도 위 내용과 맞음 한 가지가 더 있는데, 이제 더 많은 역할의 사람들이 예전에는 물리적인 절차로 힘으로 밀어붙이던 문제를 해결하는 **소프트웨어 도구**를 만들 수 있게 됨 우리는 작은 제조업체라 깊은 소프트웨어 엔지니어링 경험이 필요한 거대한 기업 프로젝트는 아니지만, 단순한 소프트웨어 도구들이 곳곳에서 프로세스와 생산성을 개선하고 있음 출하 책임자가 예전에는 많은 노동 시간을 태워 해결하던 문제를 맞춤 도구로 풀 수 있게 되면 정말 놀라운 일이 벌어짐 - 이 글은 우리 회사에서 실제로 벌어지는 일과 거의 같음 소프트웨어 개발에 AI를 많이 쓰고 있지만 더 빨리 출시하고 있지는 않고, 비슷하거나 다른 이유로 더 느린 것 같기도 함 유토피아가 오길 기다리는 묘한 느낌인데 오지 않고, 정확히 어디가 문제인지도 짚기 어려움 - AI를 효과적으로 쓰는 사람이 남에게 증명해야 할 의무는 없음 오히려 이런 의견 불일치와 불신이 시장에서 **기회와 돌출 지점**을 만듦 - 결국 전부 숫자라는 걸 사람들이 모름 프로젝트 참여자들의 평균 IQ가 140이라면 IQ 150인 AI는 파이프라인의 모든 개인을 복제할 수 있음 AI가 이건 못 한다, 저건 못 한다고 하는 사람들은 이 **IQ 격차**가 단조롭게 커지고 있다는 사실을 받아들여야 함 - 한편으로 이 글은 대규모 조직에서 기술 업무를 하는 많은 사람이 생각하고 현장에서 보는 것을 정확히 설명한 깔끔한 글임 작성자에게 110% 동의하고, 다른 사람들도 이 글의 내용을 이해했으면 함 다른 한편으로는 HN에서도, 실제 직장에서도 최근 이런 얘기를 수십 번은 한 느낌임 리더들은 AI가 정말 속도를 높일 거라고 가장할 사회적·금전적 유인이 있기 때문에 블로그 글 하나로 설득되지 않을 것임 그래서 이제는 그들의 **AI 프로젝트**가 실패하거나 기존 프로젝트처럼 느리게 가는 걸 기다리고, 뭔가 배우길 바랄 뿐임 - 슬프지만 맞는 것 같음 회사에서 이런 글을 공유하는 것도 꺼리게 되는데, 현상 유지와 맞지 않는 내용은 잘 받아들여지지 않는 느낌임 - 이런 글이 회사에서 논의될 때마다 핵심은 항상 다른 곳이 더 빠르게 새 기능을 출시하거나 가져올 수 있다면 뒤처질 위험, 더 정확히는 **FOMO**가 더 크다는 쪽으로 감 - 동의하지 않음 시각 자료와 Gantt 차트는 정확히 PM들이 이해할 수 있는 **PM식 언어**라고 봄 C레벨과 투자자들이 혁신 신호 보내기를 계속하는 한 당장 해결되지는 않겠지만, 그런 것도 영원히 지속되지는 못함 - 주택담보대출을 다 갚아서 한동안 일에 조금 까다롭게 굴 수 있는 사치가 있음 그래서 요즘은 정원 일을 하고, 에이전트형 도구로 개인 코딩 프로젝트에 집착하며 시간을 보냄 처음부터 고성능 OLTP 데이터베이스를 만들고, 새로운 논리 관계형 영속 프로그래밍 환경을 만들고, 특이한 수학 기반 신시사이저와 FPGA 소프트 프로세서를 만드는 식임 평범한 사람들이 하는 평범한 일들임 그래서 한 사람이 손에 쥐었을 때 이 도구들이 무엇을 할 수 있는지 알고 있고, 정말 놀라움 하지만 회사에 다니는 친구들에게서 최소 토큰 할당량을 정하거나 “스타 AI 코더” 리더보드를 만들고, “코드 리뷰하지 말라”, “손으로 코딩하지 말라”고 하는 이야기를 들으면 고개가 저어짐 겨울에 계약 일을 조금 해봤는데 괜찮았지만, 창업자가 주말마다 새 프로젝트 전체를 바이브 코딩하는 동안 코드 리뷰는 LLM끼리 결투하는 모양으로 퇴화했음 이 도구들은 팀워크나 진짜 팀 소프트웨어 엔지니어링에는 별로임 업계가 정리될 때까지 그냥 물러나 지켜볼 생각임 일하기 괜찮은 곳은 “천천히 해!”라고 말할 줄 알고, 그렇게 말해도 버틸 수 있는 나이 든 현명한 사람들이 있는 곳뿐일 것임 그동안 온타리오 해밀턴 지역에서 자른 루바브 한 묶음 5달러에 판매 중임 아스파라거스도 있고, 아주 많음 - 흥미로운 양면성이 있음 이미 잘하는 일에서는 LLM이 상대적으로 별 영향이 없지만, 내가 못하는 일에서는 엄청난 게임 체인저임 대기업은 프로젝트에 필요한 대부분의 역할을 채용할 수 있으므로 전체 효과가 상대적으로 작을 것임 기껏해야 한 사람이 다섯 사람 몫의 일을 어중간하게 하게 해서 인건비를 줄이고, 그 대가로 더 나쁜 제품을 얻는 정도일 수 있음 단기 이득과 장기 비용의 조합이 어떻게 될지는 뻔함 하지만 작은 스튜디오나 독립 개발자에게 LLM은 큰 변화임 다섯 사람 몫을 어중간하게라도 하는 건, 그 역할 없이 버티거나 서드파티 자산이나 다른 콘텐츠에 의존하거나, 더 나쁘게는 즉흥으로 끔찍하게 해보는 것보다 훨씬 큰 도약임 프로그래머가 디자이너 없이 배치한 게 분명한 거의 모든 프로그램 UI를 보면 됨 아니면 Dribbble에서 뭔가 베끼려 하지만 실력이 부족한 경우도 있음 AI를 쓰면 갑자기 모든 것과 모든 사람을 그럴듯하게 베낄 수 있고, 사실 그게 AI의 거의 전체 작동 방식임 - “이미 잘하는 일에서는 LLM이 상대적으로 별 영향이 없고, 못하는 일에서는 엄청난 변화”라는 건 **겔만 망각 효과**일 가능성이 있지 않나 싶음 교과서적 정의처럼 들림 개인적으로는 정반대임 LLM은 내가 무엇을 하는지 정확히 이미 알고 있을 때만 도움이 됨 - 사소하지 않은 소프트웨어 개발이 코딩 50%도 안 된다는 걸 사람들이 잘 이해하지 못함 코딩 단계는 보통 가장 쉬운 편이고 주니어 개발자에게 맡겨짐 큰 조직에서 대부분의 제품 변경은 여러 시스템과 사람의 운영을 가로지름 시니어와 미드레벨은 대체로 로컬 우선순위를 기존의 **사이버네틱 개체** 안에서 새 배열로 맞추고, 각자 우선순위를 가진 다른 팀들로부터 그 새 비전에 대한 동의를 얻는 데 시간을 씀 여기에는 자연스럽게 많은 트레이드오프와 정치가 들어감 시니어 엔지니어들은 자신이 책임지는 시스템에 “무게”를 더하는 걸 피하고, 범위 추가나 의도한 진행 방향에서 벗어나는 것을 막기 위해 강하게 싸움 그래서 타협이 필요하거나, 우선순위 선택을 위해 경영진으로 에스컬레이션해야 함 AI가 이것도 해결할 수 있을지 모르지만, 그건 훨씬 더 어려운 일임 - LLM이 거의 코드 작성자에 불과했다는 말은 1년 전에는 맞았지만 지금은 아님 이제는 **도구 호출자**라서 코딩 에이전트는 린트, 타입 검사, 테스트를 실행하고 그 오류를 고치며, Sentry 같은 관측성 플랫폼을 파고들어 근본 원인을 찾고, 벤치마크를 돌려 느린 코드나 핫 패스를 찾고, 사용하는 라이브러리의 새 메이저 버전에 대한 마이그레이션 문서를 읽고 적용해 시스템을 최신 상태로 유지할 수 있음 이런 것들이 에이전트에 역압을 걸고 시스템을 더 잘 이해하게 하도록 구성돼 있지 않다면, 그저 멍청한 LLM 코드 작성자에 머물 것임 하지만 모델과 하네스가 빠르게 개선되는 상황에서는 분명 그보다 훨씬 더 멀리 갈 수 있음 - 이 글은 대체로 맞고, AI가 프로세스를 더 빠르게 하려면 어디에 집중해야 하는지 힌트를 줌 예를 들어 한 제품 관리자가 이해관계자와의 회의가 끝날 때 **인터랙티브 프로토타입**이 나오지 않으면 실패로 간주되는 미래를 상상한다고 말했는데, 방향성은 맞다고 느낌 또 하나 예상하는 건 바이브 코딩이 “Excel 2.0”이 되는 것임 대화형 앱을 상당히 셀프서비스로 만들 수 있게 해주고, IT가 이를 더 나은 보안 보장, 적절한 접근 제어와 로깅, 확장성, 변경 관리 등을 갖춘 것으로 바꾸려는 지속적인 전쟁에 들어가게 됨 더 큰 역사적 관점에서 보면 모든 혁명적 전환은 초기에 “증기 말”을 만들어냄 증기기관 발명 당시 사람들은 교통의 미래가 증기로 움직이는 말 모양 물체가 기존 수레를 끄는 형태일 거라고 상상했음 나중에야 우리는 교통의 기능을 형태와 분리해 이해하게 됨 원래 MOOC를 이야기할 때 **증기 말**을 말하기 시작했는데, MOOC가 전형적인 증기 말 아이디어였음 - 이해관계자 회의가 끝날 때 인터랙티브 프로토타입이 없으면 실패라는 생각이라면, 그냥 **Balsamiq** 같은 걸 배우면 됨 프로토타입을 만드는 데 코드가 필요하지 않음 장면을 담는 데 배우와 카메라가 꼭 필요하지 않고 몇 장의 스케치면 되는 것과 같음 - 제시된 Gantt는 폭포수 모델이거나 소프트웨어에 최종 목적지가 있다고 보는 다른 방법론의 예시임 오늘날 소프트웨어의 99.999%는 그렇게 만들어지지 않음 현대 소프트웨어 개발에는 목적지가 없음 2주 단위로 비즈니스가 소프트웨어가 해야 할 일을 바꿈 새 기능, 새 통합, 바뀐 기능, 업그레이드되거나 교체된 구성요소, 더 큰 규모, 다른 호스팅이 계속 생김 몇 년이 지나면 소프트웨어는 근본적으로 변형되고, 품질과 테스트는 창밖으로 날아감 임시방편으로 변경을 처리하는 일뿐 아니라 엔트로피와 싸우는 끊임없는 고역이 이어짐 소프트웨어는 다치고, 생활 방식이 바뀌고, 늙어가는 **살아 있는 존재**가 됨 회사는 우울한 동물을 살려두려는 동물원 사육사처럼 괴물을 관리하는 보호자가 됨 사람은 습관의 동물이므로 AI를 써도 같은 문제가 모두 생길 것임 다만 모든 것이 조금 빨라지고 코드 리뷰가 코드를 조금 더 낫게 할 수 있음 동시에 좋은 테스트의 부재와 더 빠른 배포 욕구가 모든 것을 조금 더 나쁘게 만들 것임 이 밀고 당김의 결과로 소프트웨어 품질은 거의 비슷하지만 조금 더 빠르게 움직이게 됨 결국 더 빠른 프로세스는 생기겠지만, 나머지는 여전히 고역이라 아무도 크게 체감하지 못할 것임 아마 모두가 더 빨리 번아웃될 가능성이 큼 복잡한 데는 이유가 있고, 그 이유를 제거하지 않고는 복잡성을 제거할 수 없음 도구로 **비즈니스 문제**를 해결할 수는 없음 - “AI가 코드를 빠르게 생성할 수는 있지만, 그게 올바른 코드를 생성한다는 뜻은 아니다”라는 말에 대해, 실제로 코드는 거의 항상 맞음 마음에 안 드는 건 보통 코드가 추가되는 방식임 코드베이스를 충분히 잘 알면 어디에 추가해야 하는지, 이름을 어떻게 지어야 하는지, 주석을 얼마나 어디에 달아야 하는지 같은 의례가 있음 에이전트가 그걸 제대로 못 하면 나 같은 사람은 짜증이 나고, **AGENTS.md**에 적어도 실패하는 것 같음 “사람 개발자에게도 같은 양의 기능·범위 문서를 주면 생산성이 급등할 것”이라는 말은 IT에서 거의 20년 일했지만 절대 일어날 수 있다고 믿지 않음 설령 일어나도 너무 드물어서 논할 가치가 없음 - 내 경험으로는 완전히 일상적으로 일어남 이미 작성된 시스템을 복제하는 데 드는 노력과 그 시스템을 처음부터 만드는 데 드는 노력을 비교해 보면 됨 - “코드는 거의 항상 맞다”는 건 내 경험과 다름 특히 입력이 버그나 성능 문제일 때 자주 환각하고, 손잡아주지 않으면 오진함 그래도 무엇을 하는지 지켜보고 올바른 방향으로 밀어주면 **근본 원인 분석**과 분석은 잘하고 효율도 높일 수 있음 사람은 기계에 비해 정보를 소화하고 분석하는 속도에 한계가 있어 생산성 향상에도 천장이 생긴다고 봄 - AI가 프로세스를 우회해야 하는 건 아니지만, 그래도 속도를 높일 수는 있음 리팩터링, 상용구 코드 작성, 전에 보지 못한 오류 발견, 린터가 잡지 못하는 것들에 도움을 줄 수 있음 많은 댓글은 표준적으로 알려진 프로세스를 쓰지 않거나, AI를 쓰면 그 표준을 따를 필요가 없다고 가정하는 것처럼 보임 더 많은 코드와 기능을 출시할 수 있느냐면, 좋은 요구사항과 충분한 테스트가 있다면 당연히 가능함 AI가 쓴 모든 코드는 리뷰와 테스트를 거쳐야 하고, 분리된 커밋과 풀 리퀘스트로 나뉘어야 함 수천 줄짜리 PR을 올리는 사람은 경고 신호임 AI 없이도 그렇게 하지 않을 텐데, 왜 AI를 쓴다고 그렇게 하겠나 대규모 재작성이나 리팩터링만 알려진 예외지만, 그때도 변경 과정을 볼 수 있도록 전환 가능한 개별 커밋이 있어야 더 나은 판단이 가능하다고 봄 거대한 한 방 커밋이나 PR을 보여주면 거절할 것임 평범한 개발자가 감사할 수 있는 조각으로 나눠야 함