# 서구는 물건 만드는 법을 잊었고, 이제는 코드를 잊고 있다 > Clean Markdown view of GeekNews topic #28921. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28921](https://news.hada.io/topic?id=28921) - GeekNews Markdown: [https://news.hada.io/topic/28921.md](https://news.hada.io/topic/28921.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-27T09:58:34+09:00 - Updated: 2026-04-27T09:58:34+09:00 - Original source: [techtrenches.dev](https://techtrenches.dev/p/the-west-forgot-how-to-make-things) - Points: 1 - Comments: 1 ## Topic Body - **방산 생산 역량 붕괴**는 은퇴한 숙련 인력과 사라진 공정 지식이 끊기면, 전시 수요가 생겨도 생산을 빠르게 되살리지 못한다는 점을 드러냄 - Stinger, 155mm 포탄, Fogbank 복원 사례는 **비용 최적화와 단일 실패 지점**이 평시 효율을 높였지만 공급망 여유와 복구 속도는 크게 약화시켰음을 보여줌 - 소프트웨어도 더 싼 대체재에 기대며 **인력 파이프라인**을 약화시키는 경로로 움직이고 있고, AI 도입 뒤에는 주니어 채용 축소와 review bottleneck이 함께 커지고 있음 - 숙련은 돈만으로 빠르게 만들 수 없고, 방산과 소프트웨어 모두에서 **지식과 숙련의 축적**에는 수년의 현장 경험과 검토 역량이 필요함 - 주니어가 형성기 실수와 디버깅을 거치지 못하면 **암묵지**가 쌓이지 않아, 장차 senior 엔지니어와 institutional knowledge가 부족해질 위험이 커짐 --- ### 방산 생산 역량 붕괴와 소프트웨어 인력 축소의 평행선 - Raytheon은 [Stinger 생산 재개](https://www.defenseone.com/business/2023/06/raytheon-calls-retirees-help-restart-stinger-missile-production/388067/)를 위해 70대 엔지니어를 다시 불러와, 오래된 종이 도면과 창고에 있던 시험 장비를 바탕으로 공정을 되살려야 했음 - Pentagon이 20년 동안 새 Stinger를 사지 않은 뒤 우크라이나 전쟁으로 수요가 급증했지만, 생산 라인은 닫혀 있었고 전자 부품과 seeker는 단종 상태였으며 2022년 5월 주문분도 2026년에야 인도될 예정이었음 - 전쟁 10개월 만에 **13년치 Stinger 생산량**이 소진될 정도로 수요가 커졌고, 이미 사라진 생산 지식과 인력 공백이 병목으로 떠오름 - 단순한 예산 문제가 아니라 **은퇴한 숙련 인력**이 빠져나간 뒤 대체 인력이 이어지지 않은 구조가 핵심 장애로 작동함 ### 탄약 증산 실패가 드러낸 공급망 취약성 - ## 100만 발 약속과 실제 생산 능력 - EU는 2023년 3월 우크라이나에 12개월 안에 포탄 100만 발을 공급하겠다고 약속했지만, 유럽의 연간 생산 능력은 23만 발 수준이었고 우크라이나는 하루 5,000~7,000발을 소모했음 - 마감 시점까지 유럽은 약 절반만 인도했고, [9개국 11개 매체 조사](https://www.ftm.eu/articles/who-pays-for-ukraine-s-155mm-grenade)에서는 실제 생산 능력이 EU 공식 주장치의 약 3분의 1 수준으로 집계됨 - 100만 발 달성 시점은 2024년 12월로 밀렸고, 원래 약속보다 9개월 늦어짐 - ## 여러 병목이 동시에 겹친 구조 - France는 2007년에 자국 추진제 생산을 중단한 뒤 17년 동안 멈춰 있었음 - 유럽의 주요 TNT 생산처는 Poland 한 곳뿐이었고, Germany의 비축 탄약은 이틀치에 불과했음 - Denmark의 Nammo 공장은 2020년에 닫힌 뒤 처음부터 다시 가동해야 했음 - 유럽 방산 산업은 **소량의 고가 맞춤형 제품**에 최적화돼 있었고, 대량 생산과 위기 대응을 전제로 설계되지 않았음 - ## 미국도 비슷한 약점을 가짐 - 미국도 Scranton의 한 공장, Iowa의 폭약 충전 시설 하나에 의존했고 1986년 이후 자국 TNT 생산이 끊겨 있었음 - 수십억 달러를 투입한 뒤에도 생산량은 목표의 절반에도 미치지 못함 ### 비용 최적화가 만든 단일 실패 지점 - 1993년 Pentagon은 방산 CEO들에게 **통합하지 않으면 도태된다**는 메시지를 던졌고, 그 뒤 51개 주요 방산 업체가 5개로 줄어듦 - 전술 미사일 공급사는 13개에서 3개로, 조선 업체는 8개에서 2개로 줄었고, 노동력은 320만 명에서 110만 명으로 65% 감소함 - 탄약 공급망 곳곳에 **single point of failure**가 생겼고, 155mm 포탄 탄체 제조는 California Coachella의 한 업체에 집중돼 있었음 - 추진 장약도 Canada의 단일 시설에 의존했고, 최소 비용 중심 최적화는 평시 효율을 높였지만 수요 급증에는 거의 여유를 남기지 못함 ### 지식이 사라지면 복구도 늦어짐 - ## Fogbank 복원 실패 - Fogbank는 핵탄두에 쓰이는 기밀 물질로 1975년부터 1989년까지 생산된 뒤 시설이 폐쇄됐음 - 2000년 수명 연장 프로그램을 위해 다시 만들려 했지만 생산 전문성을 가진 인력 대부분이 은퇴하거나 사망했거나 기관을 떠난 상태였고 기록도 거의 남아 있지 않았음 - [GAO 관련 내용](https://en.wikipedia.org/wiki/Fogbank)에 따르면 추가로 6,900만 달러와 여러 해의 역공학을 들여서야 생산 가능한 Fogbank를 다시 확보함 - ## 문서에 없는 암묵지가 결정적이었음 - 새로 만든 Fogbank는 너무 순도가 높았고, 원래 배치에 들어 있던 **의도하지 않은 불순물**이 실제 기능에 중요했다는 사실이 뒤늦게 드러남 - 그 정보는 어떤 문서에도 없었고, 원래 생산을 맡았던 작업자들만 알고 있었는데 이미 은퇴한 뒤였음 - 스스로 만든 물질조차 다시 만들지 못한 이유는 **지식이 사람에게만 남아 있었기 때문**이었음 ### 소프트웨어도 같은 경로로 움직임 - ## 싸고 빠른 대체재가 인력 파이프라인을 약화시킴 - 수십 년에 걸쳐 구축한 역량을 더 싼 대체재로 바꾸고, 인간 인력 파이프라인을 약화시킨 뒤, 위기 때 제거했던 역량이 다시 필요해지는 패턴이 방산과 소프트웨어에서 겹침 - 방산에서 그 대체재가 **peace dividend**였다면, 소프트웨어에서는 AI가 같은 자리를 차지함 - 기존의 [인재 파이프라인 붕괴](https://techtrenches.substack.com/p/ai-wont-save-us-from-the-talent-crisis)와 [이해력 위기](https://techtrenches.dev/p/the-comprehension-extinction-ai-isnt)는 이미 드러나 있었고, 방산 사례는 그 재건 기간이 얼마나 긴지도 함께 보여줌 - ## 재건에는 돈보다 시간이 필요함 - 주요 방산 증산은 단순 체계도 3~5년, 복잡한 체계는 5~10년이 걸렸음 - Stinger는 주문부터 인도까지 최소 30개월, Javelin은 생산량을 두 배도 채 안 되게 늘리는 데 4년 반, 155mm 포탄은 50억 달러를 투입하고도 4년째 목표에 못 미침 - France도 추진제 생산 재개까지 17년이 걸렸고, 제약은 자금보다 **지식과 숙련**에 있었음 - [RAND 연구](https://www.rand.org/content/dam/rand/pubs/monographs/2007/RAND_MG608.1.pdf)는 잠수함 설계 기술의 10%가 PhD 이후에도 현장 10년 경험을 필요로 한다고 봤고, 방산 숙련직도 견습 2~4년과 감독 역량까지 5~8년이 필요했음 - ## 소프트웨어 성장 곡선도 압축되지 않음 - 주니어 개발자가 안정적인 mid-level로 가는 데 3~5년, senior까지 5~8년, principal이나 architect까지는 10년 이상이 걸림 - 이 시간은 돈을 더 쓴다고 줄어들지 않고, AI로도 압축되기 어려워 보임 ### AI 도입 이후의 병목과 숙련 약화 - ## 생산 속도보다 검토 병목이 커짐 - [METR 무작위 대조 실험](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)에서는 숙련 개발자가 AI 코딩 도구를 쓸 때 실제 오픈소스 작업이 오히려 19% 더 오래 걸렸음 - 시작 전에는 AI가 24% 더 빠르게 만들 것이라 예상했지만, 실제 결과와의 차이는 43%포인트였음 - 후속 실험에서는 AI 없이 일해야 한다면 참여하지 않겠다는 개발자 비중도 적지 않았고, AI 없는 작업으로 돌아가는 상상도 쉽지 않아 보였음 - ## 채용 축소와 대학 등록 감소 - [Salesforce](https://sfstandard.com/2025/02/27/salesforce-marcbenioff-layoffs-tech-agents/)는 2025년에 소프트웨어 엔지니어 추가 채용을 하지 않겠다고 했음 - LeadDev 조사에서는 엔지니어링 리더의 54%가 **AI copilots**가 장기적으로 주니어 채용을 줄일 것이라고 봤음 - [CRA 조사](https://cra.org/crn/2025/10/cerp-pulse-survey-a-snapshot-of-2025-undergraduate-computing-enrollment-patterns/)에서는 대학 컴퓨팅 학과의 62%가 올해 등록 감소를 보고함 - ## 코드 리뷰가 핵심 제약으로 이동함 - AI는 코드를 빠르게 생성하지만 인간의 리뷰는 느리게 진행돼 **review bottleneck**이 생김 - 이에 대응해 AI가 AI의 코드를 검토하게 두지 않고, pull request 템플릿에 변경 내용, 변경 이유, 변경 유형, 전후 스크린샷을 반드시 넣도록 바뀜 - 프로젝트별 전담 리뷰어를 추가해 모델이 놓친 부분을 더 많은 눈으로 잡아내려는 방식도 쓰임 ### 앞으로 부족해질 역량 - ## 기술만으로는 부족한 환경으로 바뀜 - 이제는 기술 전문성만으로 충분하지 않고, 책임을 지고 트레이드오프를 설명하며 기계가 자신 있게 내놓는 잘못된 제안을 밀어낼 수 있는 **판단력과 리더십**이 함께 필요함 - 최근 채용에서는 지원자 2,253명 중 2,069명이 탈락하고 4명만 채용됐으며, 전환율은 0.18%였음 - 기술력과 함께 **AI의 오류를 식별하는 판단력**을 가진 인재가 시장에 거의 없다는 현실이 드러남 - ## 문서화만으로는 지식 전수가 끝나지 않음 - Site Books, SDDs, RVS 보고서, 완전한 커버리지를 갖춘 boilerplate 모듈까지 폭넓게 문서화하고 있음 - 지금은 그 문서를 읽는 사람들이 엔지니어링 전문성을 갖고 있어 작동하지만, 그 전문성이 사라질 때도 같은 방식이 유지될지는 불확실함 - 2031년의 모델 성능은 예측할 수 없고, AI가 충분히 좋아져 문제를 덜 만들지도 확실하지 않음 - ## 위기는 예고 없이 오고, senior는 즉시 만들어지지 않음 - 2022년 유럽에서 전면전이 벌어질 것이라 예상하지 못했던 것처럼, 위기는 일정표에 맞춰 오지 않음 - 5~10년 뒤에는 시스템 전체를 이해하고 새벽 2시에 분산 장애를 디버깅하며 코드베이스 밖의 **institutional knowledge**까지 짊어진 senior 엔지니어가 필요해짐 - 그런데 그런 인력은 지금 만들어지지 않고 있고, 배워야 할 주니어는 채용되지 않거나 DoD 자금 연구가 부르는 **AI-mediated competence**를 쌓는 중임 - AI에 프롬프트를 던지는 능력은 남아도, AI가 틀린 지점을 짚어내는 역량은 자라지 않을 수 있음 ### 코드의 Fogbank가 될 수 있는 위험 - 주니어가 디버깅과 형성기 실수를 건너뛰면 **암묵지**가 쌓이지 않고, 현재 세대 엔지니어가 은퇴할 때 그 지식은 AI로 이전되지 않음 - 그 결과 지식은 단순히 사라질 수 있고, 이는 Fogbank에서 벌어진 일과 같은 구조와 맞닿아 있음 - 우크라이나 전쟁은 방산의 최적화 실패가 실제 비용으로 돌아오는 순간이었고, Stinger, Javelin, Fogbank, 생산하지 못한 100만 발 포탄이 그 대가를 보여줌 - 소프트웨어 엔지니어링도 같은 최적화에 베팅하고 있으며, AI가 충분히 좋아지면 이 베팅이 맞을 수 있지만 그렇지 않으면 같은 청구서가 돌아올 수 있음 ## Comments ### Comment 56352 - Author: neo - Created: 2026-04-27T09:58:36+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47907879) - 진짜 문제는 **AI 자체**가 아님 **즉시 이익**을 못 만든다고 사람과 조직의 여유를 없애놓고, 나중에 필요할 때도 그 지식이 남아 있을 거라고 믿는 경영 방식이 문제임 단기 비용 절감은 주니어 채용을 줄이고, 숙련 엔지니어가 가르칠 여유도 없애서 **암묵지 전수**를 끊어버림 결국 남는 건 문서와 자동화뿐이지만, 문서는 현장 경험이 아니고 자동화는 판단력을 대신하지 못함 실제로 시스템을 다뤄본 사람이 빠지면 암묵지는 조직에서 사라지고 생산성도 결국 떨어짐 지금 AI도 같은 패턴으로 팔리고 있고, 많은 영역에서 필요한 건 생산성 향상보다 **인력 감축**에 더 가까워 보임 GE가 분기 실적과 주주 수익 극대화에 매달리다 장기 역량을 비워낸 것과 비슷한 사고방식이 다시 보임 실제 엔지니어링과 멀리 떨어진 의사결정자들이 도구, 프로세스, 문서로 암묵지를 대체할 수 있다고 믿지만 그렇지 않음 사람과 학습 파이프라인을 없애면 그 지식은 조직 안에 남지 않고 사라짐 - **bean-counter**들이 생태계를 장악한 뒤에는 당장 수익성만 최적화했고, 그래서 시스템의 모든 부분이 항상 **100% 가동**돼야 한다고 여김 실험, 수리, 충격 흡수용 여유가 전혀 없고, 요즘 망가진 시스템의 90%는 단기 충격을 받아낼 slack이 없어서 그렇게 된다고 봄 - 많은 사람이 놓치는 부분이 있음 창업 프로젝트는 처음부터 뭔가를 계속 만들어야 하니 기능을 더 만드는 일이 곧 가치가 되지만, **Visa**, **Salesforce**, **LinkedIn** 같은 회사는 이미 제품도 기능도 자원도 충분한 경우가 많음 이런 회사들은 종종 **write more software**라는 망치에 맞는 못을 억지로 찾는 상태가 됨 위시리스트와 A/B 테스트 시스템이 많아 보여도, 정말로 소프트웨어를 더 만들수록 돈이 되는 기회가 뚜렷했다면 이미 했을 가능성이 큼 실제 성장과 새 수요는 이런 곳 바깥에서 더 많이 나오고, 소프트웨어를 못 만들거나 못 사오는 회사들이 오히려 기회를 잡을 수 있음 그리고 핵심은 **fungibility**임 인간 자본은 쉽게 재포장되는 물건이 아니라 살아 있는 것이고, 인재와 기술의 파이프라인은 끊기면 그대로 사라질 수 있음 AI 코딩의 위험도 기존 인간 자본을 끌어다 쓰기만 하고, 미래를 위한 인간 자본을 새로 만들지 못한다는 데 있음 - 그 부분은 완전히 확신하진 않음 내가 맡은 시스템 지식도 상당수는 **문서화**할 수 있고, 그 문서만으로 새 사람이 인수받는 것도 이론상 가능함 다만 필요한 문서량이 말도 안 되게 많다는 게 문제임 작은 시스템조차도 빽빽한 **A4 수만 페이지**는 현실적이라고 봄 새 담당자는 그 엄청난 문서를 거의 전부 외우다시피 이해해야 하고, 회사는 그런 문서 작성 비용이나 새 인력의 학습 비용에 돈 쓰길 싫어함 내 경험상 그래서 안 되는 것이지, 원리적으로 절대 불가능해서는 아님 - 더 근본적이고 넓은 변화처럼 느껴짐 우리는 다른 사람과 **대화할 이유**를 조금씩 없애고 있음 AI에 질문하는 순간 원래 동료와 했을 인간적 상호작용 하나가 사라지는 셈임 이건 코딩만의 문제가 아니고, 주머니 속 **ChatGPT**가 늘 있을 때 어떤 사회적 상호작용을 대체하는지 생각하게 됨 인간은 본질적으로 사회적 존재인데, 우리는 사회화를 가능한 한 계속 최적화해서 없애고 있음 나도 예전처럼 식당에 전화하기보다 **Doordash**를 더 선호하니 이 흐름에서 자유롭지 않음 - 이건 **서구 정부 시스템**이 망가졌다는 신호처럼 보임 이상적인 세상이라면 기업은 중단기 이익을, 정부는 장기 이익을, 개인은 생애 전체를 최적화해야 함 기업이 slack을 줄이고 빡빡하게 돌리면, 정부는 규제로 그 여유와 인재 유입을 유지해 국가 역량을 지켜야 함 그런데 서구에선 로비 집단과 MBA가 기업을 쥐고 흔들고, 정부까지 **돈만 최적화**하는 쪽으로 끌고 가는 듯함 - 코딩 보조 없이 매일 코딩하는 이유는, 그렇게 해야 사소한 것까지 포함해 **손으로 하는 감각**을 잊지 않는다고 믿기 때문임 AI를 쓰지 않는 가장 큰 이유는 화면 앞에 있을 때 웬만하면 아무것에도 **의존하고 싶지 않기** 때문임 물론 문서, 책, Stack Overflow 같은 건 제외함 주변에 사소한 일상 작업까지 전부 AI에 기대는 사람들을 자주 보는데, 그건 사고를 들이는 노력이 극단적으로 줄어든다는 뜻이라 꽤 무섭게 느껴짐 그 정신적 노력을 내주는 건 작은 일이 아님 나한텐 그걸 내주는 순간 의존적인 좀비가 되는 느낌이고, 지식은 거의 매일 반복하는 시행착오에서 나온다고 봄 기술은 늘 사람을 밀고 조종할 수 있음을 보여줬고, AI 의존은 기업이 인간의 가장 섬세한 능력인 **생각하고 궁금해하는 힘**까지 파고드는 최종 형태처럼 보임 - 최근 한 달 정도 **AI 보조 프로그래밍**을 많이 한 뒤, 며칠 동안 예전 방식으로 다시 코딩해봤음 대부분의 시간을 혼란과 좌절 속에서 보냈고, 7시간 가까이 문제와 씨름한 끝에 작업은 끝냈음 그런데 그 어려움 자체가 충격적이어서, 안 쓰던 탓에 내 뇌가 좀 썩은 건가 걱정까지 들었음 그러다 원래도 새 문제를 풀 때는 늘 그렇게 힘들었다는 걸 떠올렸음 처음 보는 문제와 맞붙는 감각은 원래 그 정도로 어렵고, 내가 그 느낌에 익숙하지 않게 된 것뿐이었음 어려움에 익숙해지면 그게 정상처럼 느껴지고, 반대로 어려움이 없는 상태에 익숙해지면 다시 맞닥뜨렸을 때 압도적이고 이상하게 느껴짐 그래서 **불편함과 난이도**를 견디는 능력은 꼭 보존해야 할 근육이라고 생각함 - 나는 AI 이전에도 **IDE 자동완성** 때문에 문법을 자주 잊곤 했음 그게 실제 문제였던 건 새 직장으로 옮기면서 문법 검사나 자동완성이 없는 플랫폼에서 인터뷰용 코드를 써야 할 때 정도였고, 그래서 미리 그런 환경에서 연습했음 실무에서는 문법 자동완성 의존이 큰 문제가 된 적이 없었고, 중요한 건 **언어의 핵심 개념**과 런타임 이해였음 예를 들어 Node.js의 event loop가 어떻게 동작하는지, 비동기·이벤트 기반 프로그램을 어떻게 짜는지가 더 중요했음 - 나는 완전히 반대임 지난 6개월 동안 배포한 코드 중 내가 직접 한 줄이라도 읽은 게 거의 없다고 해도 될 정도임 그런데 그렇게 일하는 편이 훨씬 더 피곤함 손으로 코딩할 때는 문제를 푸는 과정이 퍼즐 같아서 풀고 나면 **만족 루프**와 도파민 보상이 있었음 지금은 하루 대부분이 퍼즐 해결사가 아니라 **QA 담당자**처럼 느껴지고, 그게 몹시 소모적임 AI가 어려운 문제를 대신 풀어줘도, **LLM 슬롯머신**이 주는 만족감은 내가 직접 풀었을 때보다 훨씬 약함 - 요즘은 시간도 인내심도 예전만 못해서 **주 3일**은 AI를 씀 나머지 이틀은 코딩 보조는 안 쓰고, 작업이 끝난 뒤 리뷰만 맡김 이 방식이 정신 건강 유지에도 좋고, 실력의 날도 유지해준다고 봄 - 나는 원래도 언어를 조금만 떠나 있으면 빠르고 능숙하게 쓰는 능력이 남들보다 더 빨리 사라지는 편임 꽤 잘하던 언어여도 기계적인 부분은 금방 흐려짐 그래서 **LLM 보조 작업**은 내 뇌에 표백제를 붓는 느낌일 것 같음 많이 쓸수록 내겐 더 안 좋을 거라는 걸 스스로 느낄 수 있음 필요한 걸 구조화하고 문제 해결하는 능력은 여전히 괜찮은데, 실제 **nuts and bolts**는 금방 증발함 - **돈은 제약이 아니었다. 지식이 제약이었다**는 문장이 아이러니하게 들림 정작 글 자체가 너무 **AI가 쓴 듯한 문체**라 읽기 힘들기 때문임 부자연스럽고 툭툭 끊기는 흐름에 LLM 특유의 말버릇이 가득함 글쓰기 능력도 결국 퇴화하는 기술임 언어 유창성 때문에 AI를 쓰는 건 이해해도, 생성된 글보다는 차라리 **AI 번역**이 더 낫다고 느낌 직접 쓸 정도의 관심도 없다면, 내가 굳이 읽을 이유도 잘 모르겠음 - 다들 **end-to-end 코드 생성**이나 dark factory에는 꽤 관대하면서, 글을 LLM이 쓰면 갑자기 거부감을 드러내는 게 신기함 내겐 코드와 산문이 본질적으로 크게 다르지 않음 둘 다 키워드, 문법, 구문, 의미 있는 조합으로 이루어짐 AI가 만든 문장이 의미 없거나 읽기 어렵다면, 같은 논리로 **AI가 만든 코드**도 읽기 어렵고 신뢰하기 힘들어야 함 이중잣대는 좀 그만뒀으면 좋겠음 - 나는 전혀 AI가 쓴 글처럼 느끼지 않았음 오히려 HN에서 종종 다들 좋다고 넘겨버리는 **AI 잡문**보다 훨씬 나았음 - **LLM**은 인간이 실제로 쓴 문법과 문체를 학습함 그래서 사람들이 LLM 특유라고 느끼는 특징 일부는, 실제로는 인간이 먼저 쓰던 문체가 다시 인간 손으로 반복되는 것일 수도 있음 - **명백히 AI 생성**이라고 하는데, 그걸 어떻게 구분하는지 궁금함 - 그게 정말 그렇게 명백한지는 모르겠음 웹 검색 상단에서 AI가 만든 글을 하루에도 여러 개 보고 바로 넘기곤 하지만, 이 글은 그런 부류와는 꽤 달라 보였음 - 회사들이 개발자의 **경력 수준**을 제대로 가늠할 수 있다는 생각이 잘 안 듦 junior, mid, senior, lead 같은 구분은 외양일 뿐이고, 실제로는 여러 축에 걸친 연속체인데 유행 기술에 따라 왜곡되기 쉬움 엄밀히 말하면 회사에 고용되지 않아도 senior급 개발자가 될 수는 있다고 봄 결국 핵심은 스스로 배우고 만들려는 의지와 투자 시간임 요즘 회사들이 진짜 원하는 건 개발 실력보다도, **망가진 조직 구조**와 서툰 커뮤니케이션·예산 구조를 어떻게든 우회해본 경험 같음 그런 게 senior를 뜻하는지, 아니면 그냥 정치에 능숙하다는 뜻인지는 모르겠음 소프트웨어가 실패해서 착시가 깨질 때 이런 패턴이 특히 잘 드러남 - 개발자는 크게 **두 종류**로 나뉜다고 봄 문제를 받으면 필요한 걸 스스로 배우고, 모르는 부분을 파고들고, 의미 있는 결과를 반복적으로 내고, 필요한 사람과 소통하고, 진행 상황을 공유하고, 팀에 도움을 주고받으며, 빠진 부분도 먼저 채우는 사람이 한 부류임 나머지는 그냥 나머지임 커리어 초반 몇 년 안에 어느 쪽인지 대체로 드러나고, 뒤의 부류를 앞의 부류로 바꾸는 건 거의 불가능함 그래서 30년 경력의 **senior**라도 후자일 수 있고, 막 졸업한 사람이라도 전자일 수 있음 물론 정치력, 대인관계, 허세 같은 데 매우 능해서 관리층 눈에는 전자로 보이지만 실제론 후자인 사람도 있음 하지만 그건 더 이상 소프트웨어를 만드는 능력 이야기는 아님 또 전자에 속해도 저평가되거나 승진 못 할 수 있고, 실제 커리어 성공과의 상관관계는 그리 크지 않음 - 충분히 큰 조직 바깥에서는 개발자의 **seniority**라는 말이 실질적 의미를 갖기 어렵다고 봄 스스로 어떤 라벨이든 붙일 수는 있지만 좀 이상한 일임 프리랜서는 포트폴리오로, 학계 컴퓨터 과학자는 논문으로, OSS 기여자는 기여량과 영향력으로 평가받음 어느 경우든 결국 학습과 구축에 들인 노력에 비례함 다만 고용 여부와 무관하게, 전문성은 책으로만 배울 수 있는 것에 의해 정해지지 않음 **이해관계자 관리**나 해결책 발표 같은 건 읽어서 익히기 어렵고, 실제 연습과 피드백이 필요함 senior 엔지니어는 코드만 잘 쓰는 사람이 아니라 SDLC 전 범위에서 스스로 기여하고 다른 사람도 도울 수 있는 사람이며, 그런 역량은 아마추어 프로젝트보다 **프로 환경**에서 훨씬 키우기 쉬움 - 결국 사회 안에서 일하는 이상 **영향력**을 내는 능력이 seniority와 연결됨 거기엔 대체로 사회적·조직적 기술이 필요하고, 불만스러워도 세상은 원래 그렇게 돌아감 - 이게 우울하지만 꽤 맞는 말처럼 느껴짐 동시에 나는 이런 걸 가능한 한 모르고 싶기도 함 누구를 위해 내 머릿속을 뜯어내듯 맞추고 싶진 않고, 이런 종류의 문제 속에서 일하는 건 순수한 고통임 - 회사에 고용되지 않고 **senior developer**가 된다는 건 현실적으로 매우 드물다고 봄 고용되지 않은 외과의가 senior surgeon이 될 수 있겠냐는 얘기와 비슷함 몇 년간 실제로 직업으로 해본 경험 없이 senior가 되긴 어렵고, 이쪽은 **경험이 전부**에 가까움 책만으로는 필요한 이해를 체화할 수 없고, 인간은 읽거나 보기만 해서는 충분히 내면화하지 못함 직접 해봐야 진짜 배움이 생김 사실과 기법은 책으로 배울 수 있어도, 미슐랭 레스토랑 책을 읽었다고 바로 **Michelin Chef**가 되진 않음 - **AI 코드 생성기**는 트롤 같음 자신감 있게 그럴듯하지만 일부는 틀린 내용을 내놓고, 결국 인간이 그 오류를 잡아야 함 이건 재미도 없고 **flow**도 없음 - 내 경험은 정반대였음 나는 남이 만든 실수를 고치는 걸 즐기고, 특히 **LLM을 이기는 느낌**을 좋아함 전통적인 몰입 상태보다 오히려 LLM을 집요하게 감시하면서 더 오래 집중할 수 있었음 - 그건 인간이 만든 **PR 리뷰**와 비슷한 흐름을 가져야 한다고 봄 - AI가 만든 건 다 트롤처럼 느껴짐 거기엔 논리가 없고 **패턴 반복**만 있을 뿐인데, 똑똑하다는 엔지니어들이 왜 거기에 속는지 이해가 안 됨 - 이 글 자체도 꽤 분명하게 **AI 도움**을 받은 것 같다는 점이 좀 아이러니함 AI 보조 자체를 비판하는 건 아니지만, 글의 주제와 나란히 놓고 보면 생각할 거리를 던짐 - AI가 글에 집어넣는 **클리셰**는 눈에 잘 띄고 꽤 거슬리며 매우 부자연스러움 사람들은 글을 "다듬으려고" 쓰는 것 같지만, 실제론 안 썼을 때가 더 읽기 좋았을 가능성이 큼 요즘 특히 거슬리는 건 쉼표 대신 마침표를 남발하는 식의 문장임 `My people lived the other side of this equation. Not the factory floor. The receiving end.` 무게감을 주려는 의도 같지만, 필요 없는 자리에서까지 그렇게 써서 액션 영화 예고편 대사를 읽는 느낌이 남 - 나도 몇 단락 읽다가 멈췄음 윤리적으로 AI 사용 자체가 문제라는 건 아니지만, **LLM 문체**가 워낙 거슬렸음 게다가 사람들이 텍스트에 불필요한 분량과 filler를 계속 추가하는 데 쓰다 보니, 이제는 그런 글을 몇 페이지씩 헤치고 지나가야 함 더 나쁜 건 최소한 인간의 새로운 통찰에 기대고 있는 글인지, 아니면 그냥 **write me something about X** 프롬프트로 전부 생성한 글인지 쉽게 구분할 방법이 없다는 점임 지금 수준에선 후자라면 읽을 가치가 거의 없다고 봐도 무리가 아님 - 나도 AI 보조 자체는 문제 삼지 않지만, 이 경우엔 글의 **핵심 주장**을 스스로 약화시킴 내겐 동성애를 비난하던 사제가 남성 매춘부와 침대에서 들킨 것 같은 느낌임 코카인을 했는지는 선택 사항이지만, 어쨌든 입맛이 씁쓸하게 남음 - 뭐를 근거로 그렇게 판단하는지 궁금함 이 텍스트에는 흔히 말하는 뻔한 AI 흔적이 많지 않고, 내가 보기에 LLM 특유처럼 보이는 건 짧고 단호한 문장 구조 정도임 그런데 그런 문체는 **Hemingway** 이후 영어권에서 꽤 권위 있는 글쓰기 방식이기도 했음 - 예전엔 AI가 아니라 **동유럽 원격 계약 개발팀**이 더 싼 대안으로 여겨졌던 것 아닌가 싶음 - 그게 왜 계획이었는지 모르겠음 애초에 사람 수가 충분하지도 않음 그리고 여기 **동경 15도 동쪽**에서도 결국 다 같이 해고당했음 실제 계획은 그냥 AI 관련이 아니면 전반적으로 **덜 하자**에 가까웠던 것 같고, 다들 누가 먼저 해고를 시작하나 눈치만 본 듯함 나는 6개월 동안 파트타임으로 일했는데, 의사결정자들은 장기적으로 이 편이 더 낫다고 분명히 말했음 해고보단 낫지만 그런 생활을 계속 버틸 수는 없었음 검소한 편이지만 그 정도까진 아니었음 - 기꺼이 도와주고, 결국 **대체까지** 해주겠다는 식이었음 - 값싼 해외 노동력은 지금도 모든 대형 기술 회사에서 여전히 매우 흔하다고 봄 그들은 정말로 돈 쓰기 싫어하고, 특히 **미국인과 건강보험**에는 더더욱 돈을 쓰기 싫어함 이렇게 미국 기업들이 미국인을 일자리 밖으로 밀어내는 빠른 궤도로 가는데도 별 제동이 없는 게 이상하게 느껴짐 - 대부분은 **India**였음 - 실제론 **H1B 인도인**과 인도 아웃소싱이 핵심이었음 유럽인으로서 동유럽 개발자도 분명 봤지만, 내가 함께 일한 모든 회사에 있던 건 아니었음 반면 인도 인력은 늘 있었음 품질 면에선 늘 비슷한 이야기였고, 자세히 풀진 않겠지만 받아들일 준비가 된 사람은 내가 무슨 말을 하려는지 이미 알 거라고 봄 - 80년대 말 처음 들은 **Formal verification in software** 수업에서 2000년대 초 내가 떠나기 전 신입생에게 맡겼던 **Programming in Java** 수업까지를 보면, 학문적 엄밀함이 절벽처럼 무너지고 그 자리를 **취업 정렬**이 대신했다고 느낌 예전의 가르침은 사고하는 법에 가까웠는데, 나중엔 잘 받는 직업을 얻는 법으로 바뀌었음 - 맞음 기업들이 신규 직원을 더 이상 훈련시키고 싶어 하지 않았기 때문임 교육생 급여도, 가르치는 사람 비용도 다 돈이 드니 그 비용을 **학위 요구사항**으로 대학과 학생, 정부 쪽에 넘겨버렸음 취업 조건으로 훈련비를 직원에게 내라고 하면 사기 냄새 난다고 하면서도, 정작 **degree mill 시스템**은 너무 쉽게 넘어가는 게 이상함 - 사람은 완벽하지 않음 러시아 침공 며칠 전 **우크라이나**에 갔을 때 키이우의 여행과 호텔은 매우 저렴했고, 현지인들에게 침공 가능성을 물어보면 다들 **안 일어난다**고 했음 러시아는 늘 공격적으로 말만 할 뿐 실제로 그러진 않는다는 반응이었음 준비가 충분하지 않았고, 그 결과 며칠 만에 영토의 20%를 잃었음 오스트리아로 돌아온 뒤엔 내가 만났던 사람들 중 일부가 죽었을지도 모른다는 생각이 계속 남았음 그 뒤 **Dubai**와 **Saudi Arabia**에서도 기업가이자 엔지니어로 있으면서 드론이 인프라를 공격하면 어떻게 할 거냐고 물었는데, 러시아 전쟁과 이란의 첫 공격을 봤다면 그런 공격은 분명 예상 가능했음 그런데 또다시 **안 일어난다**는 답을 들었음 제대로 준비하지 않아서 수백억 달러를 잃었고, 수년간 수억 달러만 썼어도 막을 수 있었을 것이라 봄 결국 문제는 AI가 아니라 **인간**임 - **우크라이나**는 2014년부터 계속 준비해왔음 준비가 없었다면 지금쯤 키이우에 러시아 측 대변인이 앉아 있었을 거라고 봄 - 나도 우크라이나는 오히려 꽤 잘 준비했다고 봄 첫 2주를 버텨냈기 때문에 장기전으로 넘어갔고, 돈바스 전쟁도 이미 **8년**이나 이어지고 있었음 우크라이나 사람들이 그 상대가 러시아가 아니라는 착각 속에 있었다고 보긴 어려움 - 반대로 전 세계엔 상상 속 외국과의 전쟁을 떠들며 수십억을 쓰자고 하는 **지도자들**도 넘침 알고 보면 그 계약을 따야 하는 친구가 있는 경우도 많고, 상대편이 쳐들어오면 가족이 즉시 죽는다는 식의 공포를 팖 - 지나고 나서 똑똑한 척하긴 쉬움 당신은 누군가가 **절대 안 일어난다**고 했는데 실제로는 일어난 사례 두 개를 골라온 것뿐임 같은 말을 했고 실제로도 아무 일도 안 일어난 수많은 경우는 어떻게 할 건지 묻게 됨 복권을 사는 수백만 명에게 내가 "당첨 안 된다"라고 말하면 거의 모두에게 맞는 예측이 됨 한 명이 당첨됐다고 해서 내 예측이 틀렸던 건 아니고, 그건 단지 **reporting bias**일 수 있음 - 실제로는 준비했음 다들 **푸틴**이 그렇게까지 멍청할 거라 확신하진 못했지만, 우크라이나군은 만일의 경우에 대비해 방어선, 비축, 방어 전술 준비로 매우 바빴음 - 날이 갈수록 **Peter Naur**의 *programming as theory building*이 더 중요해지는 느낌임 링크: [https://gwern.net/doc/cs/algorithm/1985-naur.pdf](https://gwern.net/doc/cs/algorithm/1985-naur.pdf) - 나도 가장 먼저 떠오른 글이 바로 이 논문이었음 강력히 추천할 만한 읽을거리임