그냥 안 된다고 하는 엔지니어는 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 이후에는 경영진이 그 능력을 빠르게 갖추면서 대신 말해줄 엔지니어 집단의 필요가 줄어든 차이가 있음

[GN⁺]

Hacker News 의견들

• 코드는 부채임. 엔지니어가 “아니오”라고 하는 건 코드 품질에 주관적으로 집착해서가 아니라 복잡도를 줄이려는 것임
  요즘 경영진은 “품질”이라는 말을 오해하는 경우가 많음. 품질은 엔지니어 팀이 코드를 쉽게 추가·수정할 수 있다는 점까지 고려해, 제품을 가능한 빠르고 낮은 비용으로 만들기 위한 적정한 노력의 양을 뜻함
  더 나은 설명은 여기 있음: https://www.nair.sh/guides-and-opinions/communicating-your-e...

  • “품질”은 간단히 정의하기 어려움. 시스템 유지보수의 선(禪) 같은 영역이고, 품질 좋은 코드는 노련하고 지혜로운 프로그래머가 쓰는 것에 가까움
    그 사람이 무엇을 왜 했는지 딱딱한 규칙으로 성문화하려는 시도는 실패할 수밖에 없음
  • 에이전트형 AI의 세계에서는 그 부채가 줄어들기도 하고 커지기도 함. AI 위험을 잘 완화하는 팀은 지속 가능한 코드를 엄청난 양으로 쏟아낼 수 있음

• 이런 식의 탁상 경제학은 양쪽으로 다 논리를 만들 수 있다는 게 문제임
  “제로금리 시대의 끝과 그냥-아니오 엔지니어의 부상”이라고 할 수도 있음. 자본 비용이 더 비싸졌으니 회사는 그 돈을 더 현명하게 써야 하고, 불필요한 것에 날리지 않도록 아니오라고 말하는 엔지니어의 판단이 더 필요해짐

  • 덧붙이면, 경영진이 신뢰하고 판단을 가치 있게 여기는 엔지니어이거나, 아니거나 둘 중 하나임. 아니라면 어차피 나쁜 위치에 있음
  • 이런 글을 볼 때 HN 커뮤니티와 댓글 흐름이 정말 좋음
    글을 읽을수록 “그럴듯한 용어는 다 갖췄고, ZIRP 시대니 그냥-아니오 엔지니어니 하면서 통찰 있어 보이지만, 깊이 들어가면 그 시절 소프트웨어 엔지니어링 현장에서의 내 경험과 전혀 맞지 않고, 지금 AI로 일어나는 거대한 변화도 제대로 진단하지 못한다”는 생각이 들었음. 즉 유행어 헛소리처럼 들렸고, 글 자체에 비추천 버튼이 없는 대신 커뮤니티가 짚어줘서 반가움
  • 비슷하게 봄. 회사마다 단기 성공과 장기 성공 사이의 시간 선호가 다름
  • Sean이 좋은 엔지니어일 수는 있지만, 경제학은 전문 분야 밖으로 보임
  • 높은 금리는 더 높은 긴급성을 뜻하고, 빠르게 회수되는 단기 투자를 가리킴. 여기에 그 긴급성에 잘 올라타는 LLM이 더해지면 AI 쓰레기의 대량생산이 나옴
    AI 프로젝트가 실패하더라도 충분히 빨리 실패해서 다른 일을 하면 되니 상관없음. 처음부터 제대로 하는 건 초기 투자가 큰 장기 프로젝트에서나 중요해짐

• “회사 엔지니어 절반이 끝없이 변경을 제안하고 거절당하는 루프에 얽혀 있어도 완전히 괜찮았다. 어차피 생산적일 필요가 없었고, 그 방식이면 비즈니스 핵심 시스템에 영향을 주지 않았기 때문이다”라는 건, 뭐 관점이긴 함. 꽤 냉소적임

  • 그 시절 FAANG이 경쟁사에 인재가 가지 못하게 하려고 채용했다는 이야기는 많음. 그런데 그렇게 뽑은 사람들에게 뭘 시킬 것인가? 그리고 그들이 문제를 만들지 않게 어떻게 막을 것인가?
    돌이켜보면 냉소적으로 들리지만, 당시에는 같은 사실 묶음을 사람들 감정을 덜 상하게 하는 방식으로 다르게 설명했음
  • 맞음. 그리고 ZIRP와 “노맨” 현상을 연결하는 건 틀렸고, 어쩌면 가장 이상한 상관관계임. 예상 밖 연결을 찾는 걸 좋아하는 편인데도, 이 현상은 ZIRP와 무관하고 그 이전부터 있었음
  • 이 글의 많은 부분은 애초에 검증 가능하지 않음
    Facebook에서 Metaverse를 하는 사람이 새 비즈니스 모델을 시제품화하는 핵심 인력인지, 그냥 바쁜 척하는 업무를 하는지는 나중에야 분명해짐

• 꽤 과격한 해석임. ZIRP가 끝나고 집중도가 높아졌다면 자연스러운 결론은 더 적게가 아니라 더 많이 거절해야 한다는 것 아닌가?
  ZIRP가 온갖 가짜 일을 만들고, 그 가짜 일을 통제하기 위한 계층까지 만들었다고 주장하려면 꽤 억지로 몸을 비틀어야 함

  • 해당 시기는 제로에 가까운 금리의 좋은 예도 아니었음. 적어도 물가상승률을 통제하면 그렇고, 실질금리가 낮거나 심지어 음수였던 다른 시기도 있었음

• “그냥-예스 엔지니어”와 “그냥-아니오 엔지니어”라는 구분, 그리고 MTBF보다 MTTR을 우선하는 관점이 마음에 듦
  나는 분명 “그냥-예스” 쪽이지만, 나쁜 아키텍처 선택은 나중에 고치기 매우 고통스러울 수 있고, 기능은 출시 전보다 사용자가 생긴 뒤에 훨씬 고치기 어려워진다는 단서가 있음. 그래서 약간은 “그냥-아니오”, 적어도 “먼저 잠깐 생각하자” 쪽이기도 함
  “그냥-예스”와 “그냥-아니오”의 균형은 프로젝트에 크게 달려 있음. 금융이나 의료라면 기본값이 “아니오”인 게 나을 수 있지만, 엉뚱한 스타트업 아이디어라면 YOLO임

  • 그런 “그냥 예스” 태도는 결국 확실한 재앙으로 이어짐. 제품을 고칠 시간은 오지 않기 때문임
    정리할 시간을 요구하는 건 사실상 아니오라고 말하는 것과 같음. 개발 책임자는 그럴 권한을 가져야 하고 실제로 써야 함. 절대 쓰지 않는다면 사실상 그 권한이 없는 것과 같음

• 대안 없이 “아니오”만 하는 엔지니어가 되면 안 됨. 그건 좋은 엔지니어가 아니라 게으르면서 좋아 보이려는 것임
  엔지니어가 레거시 때문에 이상적이지는 않지만 필요한 해법을 내놓는 경우가 많음. 그리고 아니, 전체 시스템을 다시 써서 “올바른 방식”으로 만들 수는 없음. “아니오”라고 하거나 해법이 이상적이지 않다고 짚는 것만으로 초고지능 천재가 되는 게 아님

  • 딱 그런 소프트웨어 개발 매니저가 기억남. 시스템을 잘 알던 사람이 매니저가 됐고, 여러 제품 관리자와 다른 개발자들에게 계속 아니오라고 하기 시작했음
    비즈니스 사람들과의 회의에서는 코딩을 안다는 이유로 위압적으로 굴었고, 최악은 제안에 동의하지 않을 때 대안을 전혀 내지 않았다는 점임. 같이 일하기 어려웠음
    이 글이 말하는 ZIRP 인간이 그 사람인가 싶음

• LLM과 에이전트에 부족한 점이 있으면, 개선을 기다리기보다 기준을 낮추자고 파는 흐름이 있음. “MTTR에 집중하라”는 식임
  코드가 나쁜가? 읽지 말고, 검토하지 말고, 병목인 사람을 루프에서 빼라. 이런 서사가 곳곳에 퍼져 있음
  이 기술은 꽤 유용하니, 증상만 처리하는 대신 도구와 더 잘 일하는 방법과 그에 맞춘 프로세스 개선에 집중했으면 함

  • 둘 다 하고 있는 것 아닌가? AI 연구소들은 자기 쪽에서 개선하고 있을 테고, 더 나은 에이전트를 만드는 사람들도 있음. 개인은 실력을 키우거나 AGENTS.md를 조정할 수도 있음
    할 수 있는 일은 끝이 없지만, 실제 프로젝트에 쓰는 시간과 그런 개선에 쓰는 시간을 어떻게 나눌지가 문제임

• “엔지니어가 많을수록 주가에 유리했다… 은행이 금리를 올리자… 주가를 띄우기 위해 비대한 엔지니어 조직을 유지하는 게 더는 수익성이 없었다”라는데, 소프트웨어 엔지니어 인원수와 주가를 연결하는 메커니즘으로 알려진 게 있나? 아니면 그냥 경험적으로 관찰된 현상인가?

• “예전에는 주니어 엔지니어가 손으로 쓴 PR에 아니오라고 하면 됐지만, 이제는 AI 생성 코드가 쏟아지고, 그중 일부는 정치적으로 거절하기 어려운 매니저와 VP가 만든 것”이라니 세상에
  대형 기술 회사에서 일했지만 InstructGPT 등이 나오기 전에 업계를 떠나서, 내부에서의 LLM 코드 생성을 겪어본 적이 없음. 정말 이런 일이 벌어지고 있나? 상위 관리자와 VP가 LLM으로 만든 코드 변경을 제안한다고? 나는 못 버틸 것 같음

  • 실제로 일어나고 있음. 친구가 제품 관리자가 올린 2만5천 줄 PR을 상대해야 했다고 말해줬음
    정치적 부담도 진짜임. 그냥 “안 됩니다”라고 할 수 없는데, 뭘 하는지도 잘 모르고 질문에 답도 못 하는 사람이 올린 2만5천 줄짜리 PR을 의미 있게 검토하기는 꽤 힘듦
  • Shopify의 CEO가 공개 저장소에 PR을 올리고 있음: https://github.com/Shopify/liquid/pull/2056
    공정하게 말하면 그는 회사 초기에 liquid와 Shopify의 많은 부분을 직접 만들었으니 경험 없는 사람은 아니지만, 그래도 그렇긴 함

• 검증하기 어려운 가설로 보임. 무언가를 해내려는 회사라면, 어떤 결정에 장기 비용이 생기는지 알려주며 우선순위 정리를 도와줄 사람이 있는 게 당연히 말이 되지 않나?