그냥 안 된다고 하는 엔지니어는 ZIRP 현상이었다

• 그냥 안 된다고 하는 엔지니어는 코드 변경을 기본적으로 막고 복잡한 기능을 늦추며, 가능한 한 코드가 적게 작성되게 하는 시니어 원형임
• ZIRP 시기에는 낮은 금리와 채용 확대 덕분에 생산성 손실이 덜 중요했고, 과격한 기술 제안을 막는 역할이 기업에 유용했음
• 금리 상승 뒤 기술 기업은 엔지니어의 5~20% 를 해고했고, 주가보다 매출을 중시하면서 “안 된다”를 대신해줄 보호막이 줄어듦
• LLM은 AI 생성 PR과 충분히 쓸 만한 코드로 압박을 키웠지만, 핵심 변화는 AI가 아니라 ZIRP 종료로 바뀐 경제적 유인임
• 이 역할은 사라지지 않지만 순수한 엔지니어링 영역에 더 잘 맞으며, 2010년대보다 제한된 범위와 낮은 가시성을 받아들여야 함

“그냥 안 된다고 하는 엔지니어”의 역할

• 그냥 안 된다고 하는 엔지니어는 시니어·스태프 엔지니어 사이에 존재하는 원형으로, 기능 개발을 늦추고 복잡도를 늘리는 변경을 막으며 가능한 한 코드가 적게 작성되게 하는 역할에 가까움
• 반대편의 그냥 된다고 하는 엔지니어는 빠른 이동을 중시하고 코드 변경을 기본 승인하며, MTTR을 MTBF보다 중시하고 많은 코드를 배포하는 경향이 있음
• 대부분의 엔지니어는 이 양극단 사이에 있지만, 여기서의 초점은 “안 된다”는 역할에 강하게 자신을 동일시하는 엔지니어들임
• AI 시대에는 주니어 엔지니어의 PR뿐 아니라 AI 생성 코드도 대량으로 거절해야 하며, 때로는 매니저나 VP가 만든 코드라 정치적으로 거절하기 어려운 상황도 생김
• 커리어상 처음으로 기준을 낮추고 “예”라고 말하라는 압박을 크게 받지만, 핵심 원인은 AI 자체보다 ZIRP의 종료에 있음

ZIRP가 만든 환경

• ZIRP는 “제로 금리 정책”의 약자로, 2008년부터 2022년 사이 은행이 기업에 거의 0에 가까운 금리로 돈을 빌려주던 소프트웨어 개발 시대를 가리킴
• 투자자들은 빌린 돈을 거의 무엇에나 투입했고, 기술 기업들은 낮은 위험과 높은 보상을 기대할 수 있는 프로젝트를 위해 엔지니어를 계속 고용할 유인이 컸음
• 성공한 기업은 엔지니어 수를 수십 명에서 수천 명까지 늘렸고, 주변적인 오픈소스 프로젝트, 끝없는 기술 마이그레이션, 다른 언어로의 재작성 같은 일을 맡겼음
• 소프트웨어 엔지니어에게는 협상력이 크고, 거의 어떤 일을 하더라도 높은 보수를 받을 수 있던 시기였음
• 경영진은 팀이 너무 빠르게 성장해 세부를 신경 쓰기 어려웠고, 엔지니어 수가 늘어나는 것 자체가 주가에 도움이 되었기 때문에 많은 활동을 크게 문제 삼지 않았음
• 너무 많은 엔지니어가 자유롭게 움직이면 시스템이 관리 불가능해질 수 있었고, 이때 “그냥 안 된다고 하는 엔지니어”가 기업에 유용해짐

왜 ZIRP 시기에는 “안 된다”가 가치 있었나

• 생산성 손실이 큰 문제가 아니었기 때문에, 회사 엔지니어의 절반이 변경을 제안하고 거절당하는 루프에 빠져 있어도 견딜 수 있었음
• 이런 방식은 엔지니어들이 비즈니스 핵심 시스템에 영향을 주지 않게 만드는 효과도 있었음
• 기술적 자유에 취해 수제 데이터베이스로 마이그레이션하자는 식의 과격한 제안을 하는 5%의 엔지니어를 제어하는 데도 도움이 됨
• 매우 높은 기술적 기준을 가진 회사라는 평판은 채용에 긍정적이었고, ZIRP 시기에는 모든 기술 기업이 늘 채용 중이었음
• “주니어는 코드를 많이 만들고, 시니어는 조금 만들며, 스태프는 코드를 제거한다”는 말은 전문가가 거의 움직이지 않아도 된다는 매력을 주지만, 스태프 엔지니어도 필요할 때 많은 동작하는 코드를 매우 빠르게 만들어낼 수 있어야 한다는 점에서 맞지 않음

ZIRP 종료 이후의 변화

• 은행이 금리를 올리자 거의 모든 기술 기업은 즉시 엔지니어의 5~20% 를 해고함
• 주가 부양을 위해 비대한 엔지니어 조직을 유지하는 일이 더 이상 수익성이 없었고, 기업은 실제로 돈을 벌어야 했음
• 여기서 “돈을 벌어야 한다”는 표현은 반드시 이익을 내야 한다는 뜻이 아니라, 적어도 매출을 가져와야 한다는 의미임
• 수백 명의 엔지니어에게 수익성 없는 일을 시켰다고 인정하는 것은 해고의 좋은 공개 설명이 아니었음
• ZIRP 종료가 ChatGPT의 부상과 대략 겹치면서, 기업들은 해고를 AI의 힘 때문이라고 설명할 수 있었음
• “이 변혁적 신기술 덕분에 절반의 엔지니어로 10배 가치를 전달할 수 있다”는 메시지는 강하게 들리지만, 정말 그렇다면 엔지니어를 유지해 20배 가치를 전달하지 않는 이유가 생김

집중도가 높아진 기업과 줄어든 보호막

• 기술 기업들은 지난 20년 중 어느 때보다 더 집중하고 있으며, 이제 무작위적인 일을 많이 벌이기보다 돈을 벌 수 있는 새로운 역량과 기능을 필사적으로 쫓고 있음
• 이 새 환경은 그냥 안 된다고 하는 엔지니어에게 적극적으로 불리함
• 예전에는 이런 엔지니어가 경영진의 암묵적 지원을 받았고, 누군가 불평해도 “그 엔지니어가 뭘 하는지 알고 있으니, 안 된다고 했다면 믿는다”는 식으로 넘어갈 수 있었음
• 이제 그 지원은 사라졌고, 같은 행동이 경영진에게 비판받거나 적극적으로 뒤집히고 있음
• 더 팀플레이어가 되라거나, 예라고 말할 방법을 찾으라거나, 주요 결정에서 더 이상 자문을 받지 못하는 일이 생김
• 2022년 이전에는 보상받던 행동이 나쁜 평가로 이어지고 있으며, 경제적 유인 변화 뒤에 문화 변화가 몇 년 늦게 따라오는 경우도 있음
• 이 변화는 AI에 의존하지 않으며, LLM이 이번 10년에 부상하지 않았더라도 기업은 엔지니어를 해고하고 “안 된다”를 담당하던 엔지니어는 같은 행동이 왜 벌을 받는지 혼란스러워했을 것임

AI가 더한 충격

• ZIRP가 끝나지 않았다면 LLM은 “그냥 안 된다고 하는 엔지니어”에게 강한 명분을 주었을 수 있음
• AI 보조 코딩을 공개적으로나 내부적으로 의심하기 어려운 기업은 AI 코드의 쓰나미가 회사를 덮치지 않게 막기 위해 이 엔지니어들에게 크게 의존했을 것임
• 실제로는 LLM이 기존 상처에 모욕을 더하는 역할을 하고 있음
• 이전에는 차단됐을 AI 생성 PR이 병합되는 것을 지켜봐야 하고, 자신도 그런 도구를 쓰라는 요구를 받음
• 더 나쁜 점은 AI 도구가 대체로 동작한다는 것임
• 아직 어떤 종류의 재앙도 일으키고 있지 않으며, 코드가 다소 덜 깔끔하고 이해도도 조금 낮지만 충분히 쓸 만함
• 특히 기업이 많은 새 시도를 하고 실패한 것을 버리는 환경에서는 “충분히 좋은” 코드가 통함
• 최근 사고가 늘었다고 보더라도, 실제로 틀렸을 수 있거나 속도 증가·해고 같은 다른 ZIRP 종료 요인이 더 주요 원인일 수 있음
• “그냥 안 된다고 하는 엔지니어”는 생계뿐 아니라 정체성의 위협도 마주함
• 기술적 역할이 기술 산업의 매우 특이한 경제 환경에 의존했다는 점을 받아들이거나, 종말이 바로 코앞에 왔다고 계속 주장해야 하는 상황이 됨

순수한 엔지니어링과 불순한 엔지니어링

• “그냥 안 된다고 하는 엔지니어”가 사라지지는 않지만, 모든 기술 기업에 더 이상 잘 맞지는 않음
• Pure and impure software engineering에서 구분한 순수한 엔지니어링은 컴파일러나 언어 런타임처럼 범위가 잘 정의되고 주로 기술적인 목표를 가진 작업임
• 불순한 엔지니어링은 성공 여부를 확신할 수 없는 새 기능 시도처럼 범위가 불명확하고 고객 주도적인 목표를 가진 작업임
• ZIRP 시기에는 기술 기업이 React) 같은 순수 작업을 훨씬 많이 했고, 불순한 작업까지 순수 작업처럼 다루는 경향이 있었음
• “그냥 안 된다고 하는 엔지니어”는 순수 작업에 매우 잘 맞음
• 순수 코드베이스는 훨씬 높은 품질 기준이 필요하고 느린 개발 주기를 견딜 수 있기 때문임
• 대부분의 기술 기업은 여전히 핵심 인프라 같은 영역에서 어떤 형태의 순수 작업을 하고 있음
• 이 작업은 필수적이지만 거대한 엔지니어링 팀을 필요로 하지 않고, 스포트라이트를 받는 경우도 드묾
• “그냥 안 된다고 하는 엔지니어”로 남고 싶다면 이런 역할로 이동하되, 2010년대보다 더 제한된 범위를 받아들여야 함

논쟁과 보완된 관점

• lobste.rs와 Reddit에서는 AI 코드의 영향은 시간이 지나야 드러나므로 “대체로 동작한다”고 단정하기 이르다는 비판이 있었음
• “아직 말하기 이르다”는 반론은 틀리기 어렵지만, AI 코드가 즉시 치명적이지는 않다는 점은 분명해 보임
• “그냥 안 된다고 하는 엔지니어” 원형이 ZIRP 이전 수십 년 동안도 존재했다는 반론도 있었고, Linus Torvalds가 예로 꼽힘
• 이 원형 자체가 ZIRP가 만든 것은 아니지만, ZIRP가 이 역할의 틈새를 인위적으로 넓혔고 지금은 다시 축소되었다는 관점임
• 동적 언어 사용과 미성숙한 관측성·기능 플래그 도구가 이 역할의 틈새를 만들었다는 반론도 있었음
• Hacker News에서는 이 이론에 더 단단한 증거가 필요하다는 견해가 여럿 나옴
• 이 관점은 개인 경험이라는 작은 창에 기반하며, ZIRP 전후 산업이 어땠는지에 대한 일반화는 사람마다 다를 수 있음
• 이를 검증하려면 2010년과 2026년에 시니어 이상 엔지니어 수백 명을 조사해, 주당 몇 번 “안 된다”고 말했는지와 그 거절이 얼마나 자주 뒤집혔는지 물을 수 있음
• ZIRP 전후 모두 “안 된다”고 말하는 일은 필수적이지만, ZIRP 이후에는 경영진이 그 능력을 빠르게 갖추면서 대신 말해줄 엔지니어 집단의 필요가 줄어든 차이가 있음