LLM이 내 소프트웨어 엔지니어링 커리어를 잠식하고 있으며 무엇을 해야 할지 모르겠다

 (human-in-the-loop.bearblog.dev)
24P by GN⁺ | ★ favorite | 댓글 1개
  • LLM 기반 개발 도구는 설계 문서 작성, 구현 계획, 코드 작성, 디버깅까지 관여하며 10년간 쌓은 결제·금융 백엔드 전문성의 차별화를 약화시킴
  • 금융·결제 영역의 도메인 지식은 PCI 준수, 복식부기 원장, 에스크로, 대사, 결제 생애주기, 은행 이체 멱등성 같은 경험을 바탕으로 한 경쟁력이었지만, 모델이 시스템 구조의 연결고리를 잡아내며 첫 충격을 유발함
  • Claude Code, Codex, MCP, DataDog MCP 등으로 디버깅 자동화가 확장되며, 스택 트레이스와 Sentry 맥락만으로 일부 버그를 해결하고 이후 분산 시스템 버그의 90%를 원샷으로 처리하게 됨
  • 남은 축인 코드 품질과 아키텍처도 “taste”로 축소되며, 사람이 읽기 좋은 A·B 등급 코드베이스보다 LLM이 다루는 C·D 등급 코드베이스를 허용하는 흐름으로 가고 있음
  • 장기 고용 가능성을 지키려면 LLM이 쉽게 잘하지 못할 영역으로 전문성을 옮겨야 하지만, 연구직 전환은 거주 국가, 지원 경쟁, 가족 사정, RSI 가능성으로 제약이 있음

경력 배경

  • 전문 경력 10년차 소프트웨어 엔지니어로, 디버깅이 더 쉬웠던 이유로 웹 프론트엔드에서 시작했지만 백엔드로 전환한 경력이 있음
  • 우연한 계기로 금융, 부기(bookkeeping), 결제 처리 도메인의 소프트웨어 개발 역할을 맡았고, Product Manager 및 이해관계자와 가깝고 솔직한 관계 속에서 높은 자율성 경험
  • PCI 준수(PCI compliance), 복식부기 원장(double-entry ledgers), 에스크로(escrows), 대사(reconciliation), 결제 생애주기(payment lifecycles), 은행 이체 멱등성(bank transfer idempotency) 등 도메인 지식을 축적함
  • 도메인 전문가가 되는 커리어 전략은 도메인 전문가 수요 증가 조짐이 있던 분야에서 전문성을 차별화하는 명확한 선택이었음

무너지기 시작한 첫 번째 기둥: 도메인별 지식

  • 지난해 금융 분야 회사로 이직했고, 이전 회사들은 결제와 금융 요소가 강했지만 금융만을 중심으로 한 회사는 아니었던 상황
  • 새 회사는 AI를 전면 수용했고, ChatGPT와 Claude Enterprise 계정을 첫날부터 제공했으며, 조사·탐색·코딩에 AI를 쓰도록 권장
    • 단, 프로덕션에 들어가는 모든 코드 줄은 직접 검토하고 책임져야 한다는 조건
  • 첫 프로젝트는 엉망인 레거시 온라인 결제 시스템 재작업이었고, 이전 구축 경험 때문에 맡게 된 업무
  • 코딩 전 작성하는 Design Docs는 엔지니어와 Product Manager 모두 읽을 수 있어야 했고, 기술 심층 분석보다 아키텍처 관점이 필요한 문서
  • 첫 Design Docs는 최소한의 AI 도움으로 작성했고, 당시 LLM을 “stochastic parrots”라고 불렀으나 지금은 유지하지 않는 관점
  • 관리자 피드백은 코드는 좋은 속도로 내지만 Design Docs 작성이 너무 오래 걸리며 AI를 더 써야 한다는 요구
  • 당시 모델은 지금만큼 좋지 않았지만, 글쓰기와 의사결정 속도를 높이는 데 충분한 효과
  • 수년간 쌓은 구현 트레이드오프, 매입(acquiring) 작동 방식, 이중 청구를 막는 멱등성 구조화 지식이 가치 하락을 겪는 순간
    • 모델은 여전히 조율이 필요했지만, 시스템을 어떻게 구조화할지 연결고리를 잡아낼 수 있었고, 이는 수년간의 실무 경험 뒤에야 머릿속에서 형성되는 가장 어려운 부분
  • 웹의 설명 글, 기술 문서, 도메인에 기술 도구를 적용하는 블로그 글이 많기 때문에 모델이 이를 학습 데이터로 흡수할 수 있다는 판단
  • 인간이 계속 돋보일 영역은 디버깅이라는 기대가 남았고, 운영 환경의 레이스 컨디션과 분산 시스템 디버깅 경험이 장기 고용 가능성의 근거

무너지기 시작한 두 번째 기둥: 디버깅과 분산 시스템

  • LLM은 문서 작성과 구현 계획 지원에 능숙해진 뒤 코드 작성까지 잘하게 되었고, 2025년 하반기 Claude Code 하이프와 Codex 등장으로 흐름 확대
  • 그 전에도 매일 단위 테스트 작성에는 LLM을 썼지만, 전체 구현을 맡길 만큼 신뢰하지는 않았던 상태
  • 코드 작성에 더 많은 AI를 도입하는 과정은 자연스러운 다음 단계였고, 코딩만큼 프로덕션 배포와 사용자 만족도 좋아했기 때문에 수용 가능한 교환
  • LLM은 코드 작성에 능숙해졌지만, 모델이나 인간이 남긴 혼란을 디버깅하지는 못했기 때문에 로봇을 조율하는 것보다 큰 역할 유지
  • MCP, 에이전트형 워크플로, Claude 4.5 등장 이후 디버깅 축도 흔들리기 시작한 상황
  • Claude 4.5는 스택 트레이스와 일부 맥락만으로 버그의 약 60%를 해결했고, 대부분의 경우 Sentry MCP가 활성화된 Sentry 링크만으로 충분
    • 때로는 그럴듯하지만 완전히 틀린 해결책 생성
  • 이 시점에는 기계에 대한 의심을 멈췄고, 과거라면 하루 종일 디버깅했을 버그를 Claude Code가 한 번에 해결하는 장면 경험
  • 이후 4.6, 4.7, GPT 5.5, Opus 4.8, DataDog MCP 등장으로 CLI가 분산 시스템 버그를 원샷으로 해결하는 상태
    • 과거에 해결하지 못했던 버그, 이틀간 전업 디버깅이 필요했을 버그, 분산 관측성이 부족한 분산 시스템 버그까지 대상
    • 기묘한 레이스 컨디션, 예상하지 못한 코너 케이스, 서드파티 통합 문제, 문서화되지 않은 API 엣지 케이스 등 버그의 90%를 원샷으로 해결
  • 여전히 코드를 검토하고 로봇을 조율할 사람이 필요해 고용 상태는 유지되지만, 기성품 엔지니어가 된 상태
  • 금융·결제 도메인 전문성, 디버깅 직관, 분산 시스템 지식은 다른 시니어 엔지니어가 LLM을 조율해 맞출 수 있는 프롬프트 가능한 지식으로 변화
  • 일반주의자와 전문가 모두 역할이 있다는 기존 교육과 달리, 시장은 모두를 일반주의자로 만드는 흐름
    • 모두가 일반주의자가 되고 수요가 따라오지 않으면 일반주의자의 가격은 하락하며, 수요는 줄어드는 상황

아직 무너지지 않은 세 번째 기둥: 코드 품질과 아키텍처

  • 아직 남은 기둥은 코드 품질과 소프트웨어 아키텍처이며, 현재는 “taste”라는 말로 축소되는 영역
  • 경력 내내 리팩터링을 좋아했고, 좋은 코드를 중시했으며, 스프린트 안에서 이를 위한 시간을 협상해 온 경험
  • DDD, Hexagonal, Clean Architecture 같은 주제에서 트레이드오프와 코드베이스 구조를 논의하는 일을 좋아한 경력
  • 에이전트는 코드베이스를 정돈된 상태로 유지하는 데 매우 약한 도구
    • 조율하지 않으면 순환 의존성 문제가 빠르게 발생
    • 중복 코드 추가, 불필요한 주석 삽입, 순수 함수와 사이드 이펙트 혼합, SOLID 원칙 무시
  • 이 능력은 인간의 고용 가능성을 지켜야 할 영역이지만, 업계는 이를 “taste”라는 단어로 축소하고 코드 조직화의 중요성이 낮은 세계로 이동
  • 사람은 여전히 순환 의존성 그래프를 가진 스파게티 코드베이스를 막기 위해 에이전트를 조율해야 하는 역할
  • 무언가를 고치려 하면 깨지는 F 등급 코드베이스는 원하지 않지만, C나 D 등급은 이제 허용 가능한 수준
  • 더 이상 A나 B 등급 코드베이스가 필요하지 않은 이유는 코드베이스가 인간이 읽기보다 LLM이 다루도록 만들어지고 있기 때문
  • 소스 코드가 이제 인간이 아니라 기계가 읽도록 작성된다면, 기계를 대상으로 삼는 선택도 가능한 상태
  • 코드 품질과 아키텍처 지식도 가치 하락을 겪고 있으며, 책 읽기, 실제 연습, 엔지니어와의 토론, ADR 작성에 쓴 시간이 쓸모없어지고 있음

이제 무엇을 해야 하나

  • 당분간은 (최소한 현재 회사에서는) 고용을 유지하리라 보지만, 장기적 전망은 불확실
  • 장기적으로는 10년, 비전문 경험까지 더하면 그 이상을 투자해 익힌 것들의 가치가 점점 낮아지는 상태
  • 마지막 전문성 기둥도 “taste”로 축소된 상태
  • 약 8개월 전 현재 회사에서 (회사 측 설명상 AI와 무관한) 정리해고가 있었고, 해고된 뛰어난 전 동료들이 여전히 구직 중
    • 이들 다수가 동일한 문제, 즉 도메인 전문성만으로는 더 이상 차별화되지 못하는 상황을 겪음
  • 회사는 다시 몇몇 역할을 채용 중이지만, 도메인 친숙도는 더 이상 강한 차별화 요소가 아니게 됨
    • 예전에는 “Software Engineer - Area” 형태로 공고를 냈지만, 이제는 “Software Engineer”만 쓰고 팀 배정은 오퍼 수락 뒤 진행
  • 깊은 도메인 경험을 쌓을 기회가 없었던 뛰어난 엔지니어에게는 더 나은 취업 기회가 생긴 변화
  • 평생 도메인 지식을 모아 온 뛰어난 엔지니어도 같은 차선에서 경쟁하게 된 변화
  • 장기 고용 가능성을 지키는 유일한 선택은 LLM이 쉽게 잘하지 못할 영역으로 도메인 전문성을 옮기는 일
  • 대학으로 돌아가 수학, 통계, 고급 Machine Learning을 배우고 frontier lab 연구직에 지원하는 선택지도 고민
    • 거주 국가에는 frontier lab이 없고, 존재하는 소수의 연구소는 지원자가 몰리는 상태
    • 가족 사정 때문에 다른 나라로 이동하기 어려운 상황
    • 이동이 가능해질 때쯤 RSI(재귀적 자기 개선)가 연구자를 불필요하게 만들 수 있다는 가능성도 있음
  • 목공 취미를 직업으로 전환하는 것까지 고려할 정도의 막막함을 토로

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 뭐라고? 하루 종일 LLM을 조종하지만 금융 제품의 책임자가 되는 데 동의할 일은 절대 없음
    첫 번째 기둥은 여전히 남아 있음. 저자가 자기 영향력을 모르는 것일 수는 있지만, 되돌린 PR이라는 증거를 보면 내가 깊이 아는 영역 밖으로 나갈 때는 에이전트가 헛소리하는지 더 이상 판별할 수 없다는 걸 앎. 저자가 말한 분산 시스템 접근권까지 가진 우리 최상위 에이전트도 자주 틀리고, 시야가 좁고, 계속 멍청한 짓을 함. 결국 팀 엔지니어들의 전문성이 다시 궤도에 올려놓음

    • 신원 노출을 피하려고 임시 계정으로 씀. 규제 대상 제품을 만드는 FinTech에서 일하고 있고 Mythos에 접근 가능함
      Mythos가 우리 코드베이스 일부를 특정 규정 위반이라고 자신 있게 판정했고, 지금 방식으로 운영하면 심각한 위험이라고 했음. 하지만 사실이 아니었고, 규정 요구사항을 환각한 것이었음. 해당 코드는 이미 사람인 법무 자문이 검토했기 때문에 알 수 있었음. 이게 현재 이용 가능한 최첨단 모델이라고 함. 코드 작성 보조에는 생성형 AI를 많이 쓰지만, 중기적으로도 이런 도구에 의존해 규정 준수 금융 제품을 실제로 만들 수는 없음. 그건 완전히 미친 짓임. 많은 FinTech 회사가 속도 향상에 에이전트를 쓰는 건 맞지만, 사람이 실제로 파고들지 않은 채 제품 출시에 쓰면 엄청난 위험을 떠안는 것임
    • “팀 엔지니어들의 전문성이 다시 궤도에 올려놓는다”고 하지만, 동료들이 나보다 더 전문가가 아니라고 어떻게 확신할 수 있음?
      LLM 이전에는 대부분 회사에서 뛰어난 엔지니어와 평범한 엔지니어가 함께 일할 여지가 있었음. LLM 이후에는 “최고” 엔지니어만 살아남을 수 있음. 더 이상 평범한 엔지니어가 필요 없기 때문임. HN 특성상 이 글을 읽는 엔지니어 대부분은 자신이 회사/도시/국가 기준 상위 10~5%라고 생각하고, 그래서 LLM 도입의 영향을 받을 “평범한” 엔지니어가 아니라고 여길 것임. 통계적으로는 아마 틀렸을 가능성이 큼. 결국 자존심 문제임. 당신은 락스타가 아닐 가능성이 높고, LLM이 결국 당신 일을 가져갈 수 있음. 늘 그렇듯 승자는 기업과 임원뿐이고, 우리 대부분은 사슬의 맨 끝에 있으니 피해를 보게 됨
    • 복잡한 요구사항이 있는 PR에서는 초기 PR까지 걸리는 시간은 매우 짧아졌지만, 이후 리뷰어와 개발자 사이의 핑퐁이 시작되는 걸 봄
      내 경우에는 개발자가 일부를 바이브 코딩했고, 요구사항이나 자기 코드에 대한 깊은 이해가 없어 여러 번 반복해야 고쳐짐. 이걸 인간 문제라고 할 수도 있지만, 내가 보는 순효과는 이렇다. 복잡한 경우 예전의 “적당히 긴 PR 작성 시간 + 적당히 긴 리뷰 시간”이 “매우 짧은 PR 작성 시간 + 더 길어진 리뷰 시간”으로 바뀐 듯함. 이런 경우 실제 이득이 있는지 모르겠음. 때로 기능적으로 맞는 코드라도 중간 함수가 너무 많아 장황하고, 앞으로의 리뷰에 영향을 줄 것 같음
    • 안타깝게도 소프트웨어 관련 산업 전반이 LLM/코드 생성을 받아들이고 있음. 은행, FinTech, 보험 모두 그렇다
      나도 같은 우려를 하고 있지만, “전달 속도와 ROI가 그만한 가치가 있으니 걱정하지 말라”는 식으로 자주 무시되거나 얼버무려짐
    • “LLM을 하루 종일 조종하지만 금융 제품의 책임자가 되는 데 동의할 일은 없다”는 말이 특정 고용주에서 얼마나 더 유지될지 모르겠음
      개인적으로 접하는 모든 FinTech 회사는 작년부터 개발자용 AI 계정 비슷한 것을 갖고 있었음. Jane Street 같은 곳에서도 직원들이 블로그를 올려 대부분 에이전트를 지휘한다고 말함. 당신 회사가 얼마나 더 버틸 수 있다고 봄?

  • “AI가 X를 80~100% 정확도로 못 하니 우리 직업은 안전하다”는 댓글을 많이 봄
    지나치게 비관적으로 들리고 싶진 않지만, 모델은 빠르게 좋아지고 있음. 3년 전쯤 지금 상태를 설명하며 “모델이 프롬프트 하나로 약 30분 만에 전체 MVP 앱을 만든다”고 했다면 공상과학처럼 들렸을 것임. 지금 모델이 겪는 환각률 감소, 규정 준수 보장, 깔끔한 코드베이스 유지 같은 장애물은 해결이 멀어 보이지 않음. 특정 정보 가져오기도 여러 MCP 서버/RAG로 이미 부분적으로 가능함. 소프트웨어 엔지니어의 미래가 걱정됨. 이런 결함이 해결되면 직업은 어디에 자리 잡을까? AI 모델에 작업을 위임하는 역할? 불행히도 이건 수년의 전문성을 요구하지 않아 양날의 검임. AI 출력 검토? 이해 안 되는 각 줄을 설명하라고 하면 됨. 인간 계산수가 디지털 컴퓨터로 대체됐듯, 더 큰 해고 물결을 더 보게 될 것 같음. 복잡한 수학 계산을 머리로 하는 건 재미있는 도전일 수 있지만 컴퓨터보다 훨씬 느리고 오류가 많음. 마찬가지로 손으로 코드를 만드는 일은 재미있는 “도전”으로 보이고, AI는 현대의 계산기로 보이게 될 것 같음

    • 이 짧은 클립을 꼭 보길 권함
      https://youtu.be/5eqRuVp65eY?si=3fLT6S5q2OIUcu6r
    • 모델이 빠르게 좋아지고 있고, 3년 전에는 지금 상태가 공상과학처럼 들렸을 거라는 말은 완전히 맞음
      많은 것은 계속 크게 개선될 것임. 다만 기술이 만든 급격한 혼란의 현대사를 보면 반복되는 패턴이 있음. 눈사태나 돌발 홍수처럼, 이런 급격한 변화는 특정 기술의 중요한 돌파구 하나 이상에서 시작되는 경우가 많음. 초반 변화 속도는 빠르고 거칠지만, 새로 열린 낮은 과실을 따고 새 영역에서 새로운 장벽과 마찰을 만나면서 점차 둔화됨. 이런 시기 초반에는 최근의 이례적 변화율을 그대로 미래에 외삽하는 예측력이 낮음. 갑작스러운 극단적 폭발은 장기 추세선으로 회귀하는 경향이 있음. 현재 LLM 혼란은 2010년 이후 연구가 2017년 트랜스포머 논문으로 쌓이고, 그 주변 연구를 빠르게 촉발한 데서 비롯됐다고 볼 수 있음. 그렇다면 지금은 LLM 급격한 폭발 국면의 중반 또는 후반일 수 있음. 모든 LLM 응용을 끌어올리는 근본적이고 폭넓은 돌파구의 속도는 분명 느려졌고, 최근의 영향 큰 발견 다수는 특정 영역을 향한 확장, 최적화, 튜닝, 제품화에 있음. 내일 또 다른 트랜스포머급 돌파구가 없다는 뜻은 아니지만, 역사적으로 블랙스완은 무리 지어 다니는 일이 드묾
    • 왜 개발자 해고에서 멈춘다고 봄? 소프트웨어 회사들이 사업 운영을 LLM 제공자에 의존하게 되면, 온프레미스 제품부터 SaaS까지 전 세계적으로 이 회사들의 대규모 붕괴를 볼 수 있다고 봄
      고객은 오늘날처럼 소프트웨어 도구를 사지 않고, 필요한 소프트웨어를 전부 내부에서 만들거나 프롬프트 엔지니어 컨설턴트로 만들 수 있음. 매우 다른 세상이 될 수 있음
    • AI가 100%에 도달하는 시점에 대한 이론은 뭔가? PM과 비즈니스 분석가가 모든 소프트웨어를 만드는 건가?
      아니면 전 세계에 1인 창업 회사 700개쯤만 있고 나머지는 모두 일하지 못하는 건가? 매트릭스인가?
    • 모델이 그 정도로 좋아지고 있다고 생각한다면 좀 망상에 가까움
      Claude 3.5가 나왔을 때보다 생산성이 그렇게 많이 늘지 않았음. 모든 LLM에 무제한 접근할 수 있지만 대부분은 쓰레기고, 절약하는 일보다 만드는 일이 더 많음. 이 도구로 이득 보는 사람은 저품질 결과물을 빠르게 찍어내는 사람뿐임. 동의하지 않는다면 당신도 그런 사람임

  • 내 경력 경로는 저자와 놀라울 정도로 비슷함. 이상하게도 저자가 무너진 첫 번째 기둥으로 보는 부분이 지금은 가장 멀쩡해 보임
    LLM은 우리 사업 특수성에서 반복적으로 실패함. 지역 세법, 회계 절차의 세부 사항, 우리 원장 구현의 특수성 같은 것들임. 리팩터링, 언어 간 변환, 기존 코드의 버그 추적에는 훌륭하지만, 우리 도메인을 반복하고 확장할 때는 미묘하게 틀린 부분이 항상 많음. 내가 일한 회사들이 해자 구축을 위해 일부러 복잡한 영역을 다뤄서 그럴 수도 있음. 복제본을 만들 책이 세상에 없고, 노하우가 내부에 남아 있기 때문에 사업이 유지되는 회사들임. 또 관리자가 설계 문서를 AI로 빠르게 만들라고 권하는 FinTech라면 돈을 다루는 사업을 하기엔 너무 부주의해 보임. 특히 작은 거래가 대량으로 발생하는 경우 수백만 단위가 잘못 배분되기 너무 쉬움. 이런 버그는 정말 다루기 힘듦. 로직 수정은 1단계일 뿐이고, 이후 불변 데이터베이스에 잘못 계산된 데이터를 고치고, 규제 절차와 고객 커뮤니케이션을 처리해야 함. 수정 사항은 새 기능과 관측 가능성이 고려해야 하는 함정이 됨. “2월 2일 데이터에 튀는 부분이 있는 건 X 사고 때문이라는 걸 기억하라” 같은 식임

    • 진짜로 이전에 만들어진 적 없는 것을 만들 때는 LLM에 아키텍처 결정을 맡길 수 없음
      여러 물리 시뮬레이션 기반 제품을 만들고 있는데, 순수하게 제1원리 기반임. 그런데 능동적 연구, 사고, 검증 없이 맡기면 수백 자릿수 배로 느린 계산 코드를 만들면서, 터무니없는 대체 경로와 지름길을 넣어 결과적으로 쓸모없는 계산을 만들어냄. 이런 일이 아마 95% 정도 발생함. 감독은 매우 중요하고, 아키텍처 사고는 아직 외주화할 수 없음. 외주화할 수 있는 건 실행뿐임
    • 지역 세법, 회계 절차, 원장 구현의 특수성은 도메인 전문성이고, 소프트웨어 엔지니어가 꼭 필요하진 않음
      물론 시니어 소프트웨어 엔지니어가 여기에 전문가인 경우가 많지만 필수는 아님. 전통적으로는 엔지니어가 비즈니스 전문가에게 묻지 않고도 업무의 90%쯤 처리할 수 있으면 마찰 없는 생산에 유용했지만, 바로 그 “전통”이 끝났다는 게 원문이 다루는 핵심임. 새 세상에서 시니어 엔지니어의 일은 그 도메인 전문성을 직접 갖는 게 아니라, 에이전트가 그것을 갖도록 하거나 획득하도록 만들고, 그것이 검증 가능하게 맞는지 보장하는 것임. 고급 비즈니스 도메인 전문성이 자신을 안전하게 해준다고 붙잡는 시니어 엔지니어는 전환하지 않은 주니어만큼 곧 막다른 길에 놓일 것임
    • Claude나 GPT-5에게 흔한 사용 사례의 흐름도 일관되게 잘 만들게 못 하겠음. 도메인 특화 내용은 말할 것도 없음
      깊은 어휘를 갖고 있어서 실제보다 더 잘 아는 것처럼 들림. 코드를 쓰고 눈에 보이는 오류를 디버깅하는 건 아주 잘하지만, 그건 절반쯤은 테스트 장치 덕분임
    • 제품 기능과 그 기능이 반영해야 하는 규정을 LLM과 함께 공통 이해로 맞추게 하는 기술이 도움이 될 수 있음
      핵심 아이디어는 문서를 LLM에 제공하고, LLM이 많은 질문을 하면서 모호함과 오해 가능성을 해소하게 하는 것임. Skills를 한번 살펴보길 권함. 정말 도움이 됨. https://www.youtube.com/watch?v=6BB6exR8Zd8
    • 우리 회사도 복잡한 규정과 도메인 특화 시스템 구현을 많이 다루고, 예전에는 AI가 여기에 고전했음
      잘 정리한 claude.md/agents.md 파일로 문제를 풀 수 있었음. 여기에 supermemory.ai도 구현해서, 새로 내린 결정이 새 세션을 시작할 때마다 AI 에이전트에게 항상 회상되도록 했음

  • Steve Jobs의 악명 높은 “아이디어는 싸다”는 말을 늘 떠올림
    실행이 전부이고 최전선 LLM이 실행을 해결한다면, 이제 아이디어가 풍요로 가는 관문이 됨. 하지만 풍요 자체가 “붙잡아 두는 힘”을 보장하진 않음. 자주 간과되는 건 인간이 그 일에 머무르려는 의지와 신경 쓰는 마음임. 많은 사람은 무언가를 만들고, 유지하고, 소유할 만큼 신경 쓰지 않거나 원하지 않음. V1은 더 빨리 출시할 수 있겠지만 계속 갈아 넣을 수 있나? 좋은 예는 AI 음악 도구 Suno에서 보임. 이제 꽤 좋은 결과물을 냄. 많은 사람이 자기만의 작은 세계를 갖고 놀다가 금방 지치고 떠나며, 소수의 다작 창작자만 남아 그것을 “일 같은” 환경으로 바꿈. 위임과 실행의 규모와 경제성은 바뀌었을 수 있지만, 고려할 요소는 아직 많음

    • Suno를 조금 써봤는데, “정말 좋은 결과물을 낸다”는 말에는 동의 못 함
      음악 교양이 제한적인 사람으로서도 그렇게 느끼니, 음악가는 더 비판적일 가능성이 큼. 처음 몇 번은 인상적이고 멜로디도 중독성 있음. 예전에는 배경에서 이상하게 들렸지만 대부분은 고쳤음. 하지만 수십 곡을 지나면 항상 비슷하게 들리기 시작함. 전부 일반적이고, 노래가 이야기를 하지 않으며, 기업 광고에 깔리는 음악 같은 느낌임. 프롬프트를 더 정확히 써도 잘 안 됐고, 곡을 흥미롭게 만들 디테일은 대부분 무시함. 가장 흥미로운 결과는 오히려 버그처럼 궤도에서 벗어나게 만들었을 때였음. 아주 다른 두 장르를 섞어 달라고 했더니 전에 들어본 기억이 없는 불안한 느낌의 결과가 나왔음. 하지만 더 작업하려면 늘 어렵고, 계속 일반적인 결과로 돌아가려 하며 세부 지시를 무시함. Suno는 리믹스는 할 수 있음. 코드와 비슷함. LLM은 이미 작동하는 무언가를 다른 언어에서 작동하게 옮기는 포팅에는 매우 좋음. 하지만 아이디어만 있으면 독창적인 부분에서 망침. LLM이 아이디어를 제대로 구현하게 하려면 너무 많은 지침을 줘야 해서, 자연어의 모호함과 싸우며 사실상 직접 코드를 쓰는 것과 비슷해짐
    • 최전선 LLM이 실행을 “해결”하지는 않음
      충분히 밀어붙이고, 실제 작동하는 코드를 얻을 수 있는 시스템을 갖추면 실행을 해결할 수 있음. 하지만 그게 바로 엔지니어링임. 지금 기본 상태로는 엔지니어링을 대체하기엔 한참 멀었음. 3년 뒤에는 가능할지도 모름. 빠르게 움직이고 있으니까. 하지만 오늘 당장 “더 나은 Rust 컴파일러를 만들어줘”라고 말하고 뒤로 기대 앉아 결과를 받을 수는 없음
    • Suno는 좋은 예임. 많은 곡의 가사를 쓰고 Suno로 “프로듀싱”했는데, 원하는 소리가 나오기까지 수십에서 수백 번의 리믹스/커버/확장 수정이나 편집기에서의 많은 시간이 필요함
      곡들은 내가 좋아하고 재생목록에서 들을 만하지만, Suno 알고리즘에서는 큰 반응을 얻지 못했음. 다른 곳에서도 많이 홍보하지 않았고, 올려봤을 때도 좋아요 몇 개가 전부였음. 실망하진 않음. 나 자신을 위해 음악을 만들었고 공유는 부수 효과였기 때문임. 여기서 얻은 결론은 사람들이 내가 만든 것에 관심을 갖고 즐기게 만드는 데는 많은 일이 필요하다는 것임. 마케팅해야 하고, 사람들 앞에 가져가야 하고, 주목하게 해야 함. 또한 영상, 이야기, 페르소나, 어떤 분위기 같은 것과 연결해 좋아할 이유를 줘야 한다고 확신함. “붙게” 만들려면 같은 청중을 상대로 그 모든 것을 반복해야 하고, 그들이 익숙해지게 해야 함. 그래서 지속성이 필요하고, 팔려는 대상에 진심으로 신경 써야 함. 사람들이 붙기 전에 내가 먼저 붙어 있어야 함
    • https://x.com/chamath/status/2033385903520129161
      https://en.wikipedia.org/wiki/Sturgeon%27s_law
      Sturgeon의 법칙은 “모든 것의 90%는 쓰레기다”라고 말함. 이 격언은 미국 SF 작가이자 비평가인 Theodore Sturgeon이 장르의 가치를 옹호하며 만든 것임. Sturgeon은 어느 분야든 대부분의 작품은 낮은 품질이라고 보았고, 따라서 SF만 유독 열등한 것은 아니라고 했음
    • AI 음악 도구에 대해 더 설명해 줄 수 있음?
      내 인상으로는 한 번에 생성하는 도구처럼 쓰임. 음악은 잘 모르지만, 예술가에게는 중간 단계, 트랙 분리, 악기 맞춤화 등 내가 모르는 여러 요소가 필요할 것 같음. 이런 게 없으면 전문 작업에 쓰이기 어렵다고 봄

  • 이 글에 완전히 동의하진 않음. 바이브 코더가 중간 정도 복잡도의 시스템을 설계, 개발, 구현하면서 모든 걸 터뜨리지 않을 수는 없음
    Claude 같은 애플리케이션을 잘 쓰는 데 큰 부분은 컴퓨터 과학 개념에 대한 개념적 이해와 경험임. 바이브 코더에게는 절대 없는 것들임. 있었다면 바이브 코더가 아니었을 것임

  • “무엇을 해야 할지 모르겠다”면 파도를 타면 됨
    웹사이트/웹앱이 파도였을 때도 탔음. 나는 인터넷 이전에 소프트웨어 업계에 들어왔고 계속 말을 갈아탔음. 새 기술을 배우기에 너무 늦은 나이는 없음. 새 파도는 새 종류의 일과 노동자를 만듦. 그중 하나가 되면 됨. 짐승을 타고, 도구를 숙달하라. 같은 게임이 다시 온 것임

    • 동의함
      꾸준히 수요가 있는 기술이 있다면, 새 일, 새 프로세스, 새 사람 등 무엇이든 머릿속에 구조화하는 능력임. 나는 프로토타입 기계공으로 일하면서 이 능력을 날카로운 도구로 이해하고 발전시켰음. 익숙하지 않은 사람을 위해 말하면, 프로토타입 기계공은 매주 짧은 일정 속에서 까다로운 부품을 만들기 위해 필요한 일을 해내는 사람임. 금속, 플라스틱, 뭐든 다룸. 프로세스, 공작기계, 재료에 빠르게 익숙해지는 데 능숙해짐. 그렇게 한동안 하다 보면 새 정보를 매우 빠르게 흡수하고, 많은 사람보다 일을 훨씬 빠르고 정확하게 이해할 수 있게 됨. 누구나 시작할 수 있음. 호기심을 갖고 무언가를 만들면 됨. 그리고 더 만들어라. 만든 것을 공유하고, 다른 사람들이 원하는 것을 만들어라
    • 전반적으로 사회가 더 요동치는 느낌은 있지만, 본질적으로 같은 노래와 춤이 다시 반복되는 것임
      90년대와 00년대에는 “객체 지향 프로그래밍이 모든 것을 바꾼다”는 파도가 있었음. 이전에 수백 번 성공적으로 해온 일을 이제 객체 지향으로 한다는 식이었음. 비행기 관련 코드를 쓰나? 비행기의 모든 것을 하는 전능한 비행기 객체를 사면 된다는 이야기를 대학에서 실제로 들었음. 그런데 객체 지향이 만능은 아니었나? 코드 생성, Ruby on Rails를 돌려봐라. 2초 만에 웹사이트를 만든다. 코드 생성이 여기저기 있었음. 이상한 방향으로 가더니 TDD가 나옴. TDD를 안 하면 감옥에 가둬야 할 만큼 나쁜 엔지니어라는 실제 대화를 본 적 있음. 아니, TDD가 아니라 BDD가 해결책이라더라. Lean, 아니 Agile, 아니 소문자 agile, 하지만 처음은 그것이었다, 아니 Scrum, 아니 XML, 잠깐 그건 지난 10년이고, JSON, 그리고 마침내 SAFe. 그리고 이제 “이 챗봇 봤어?”임. 매 반복은 주의를 기울이면 좋은 것을 가져옴. 하지만 많은 과장과 불안도 함께 가져옴. 실험하고 배우면 됨. 내게 변하지 않은 한 가지는, 거의 모두가 자기 꿈이 이뤄졌을 때의 결과를 신중히 생각하느니 차라리 죽으려 한다는 것임. 그게 계속 사실인 한, 사람들은 자신을 대신해 과장된 유행의 용을 타 줄 누군가에게 계속 돈을 낼 것임
    • “도구를 숙달하라”고 하지만, 이 도구들의 가치 제안 자체가 쌓을 기술이나 숙달이 없다는 것임
      전체 저품질 결과물 공장 흐름, 아니 “AI 네이티브” 흐름은 이렇다. “와, 챗봇을 구슬려 내가 전혀 이해하지 못하는 걸 만들게 했어. 나는 일을 참 잘해!” 만들기의 참가상 같은 것임. 다른 무언가가 만들고, 나는 잘 이해하지도 못하면서 공을 가져감. 내 노력에는 복리 수익이 없음. 배운 교훈도 없음. 이해도 쌓이지 않음. 미래 혁신으로 이어질 통찰도 없음. 차별화도 없음. 그저 정신이 마비될 만큼 허공에 소리 지르다가 슬롯머신이 “충분히 좋아 보이는” 저품질 혼합물을 뱉으면, 다음 날 또 반복함. 그게 게임이라면 나는 빠지겠음. 다른 사람들이 즐긴다니 좋긴 하겠지만, 여기에 어떤 숙달이 있다고 생각하는 건 망상임. 이 도구로 “성공”하는 유일한 조건은 신경 쓰기를 멈추고 항복하는 것임

  • 예전에도 올렸지만 다시 올릴 가치가 있음
    LLM 사용에 매우 적극적인 회사에서 DevOps 일을 함. 단계는 대략 이랬음. LLM에게 “많은 것”을 시켜보기, 더 많이 시키기, 여러 에이전트 실행, 다시 단일 에이전트로 돌아가되 도구를 만들게 하기, 그리고 사람과 LLM 모두 사용할 수 있는 결정론적 도구로 가기. 이유는 이렇다. 배포와 테스트 모두에서 결정론적 도구는 이진 답을 주고 반복 가능함. 장애가 나면 사람이 실행할 수 있는 도구로 항상 돌아갈 수 있음. 더 빠름. 간단한 스크립트는 30초 미만에 실행되지만, “그럴듯한 헛소리”는 늘 2~3분 걸리는 듯했음. 결국 이 글로 돌아옴. https://spawn-queue.acm.org/doi/10.1145/3194653.3197520 즉 “작업 목록을 만들고, 각 작업의 스크립트를 쓰고, 스크립트를 함수로 결합하고, 함수가 시스템이 된다”는 것임. 덧붙이면, LLM이 하고 싶은 대로 두면 기꺼이 코드를 만듦. 테스트를 추가해 테스트가 작동하는지 확인할 수 있음. 예전에도 사람 코드에 그렇게 했잖음. 코드도 읽을 수 있음. 코드를 읽으면 작동하는 코드를 만들면서도 완전히 미친 짓을 할 때가 있음. 사람도 그러긴 하지만 별개 이야기임. 결국 만들어지는 시스템이 말이 되는지 여전히 확인해야 함. 더 간단히 말하면, 코딩은 죽었을 수 있지만 소프트웨어 엔지니어링은 살아서 잘 뛰고 있음

    • 이 방식이 맞음
      대형 LLM에게 모든 것을 시킬 수 있음. 가능하고 실제로 하기도 함. 하지만 돈이 엄청나게 들고 오래 걸림. 대신 AI로 도구를 만들어 프로세스의 가능한 많은 작업을 결정론적으로 처리하게 하고, AI가 그 도구를 쓰게 하면 훨씬 빠르고 싸게 굴러감. 덤으로 결국 비싼 클라우드 AI를 버리고 소형/중형 로컬 모델로 돌릴 수도 있음

  • 저자의 미래상이 맞다면, 유능한 소프트웨어 엔지니어는 안전함
    도메인 지식은 좋은 엔지니어링 원칙을 적용하는 법보다 훨씬 빠르게 배울 수 있음. 주된 경쟁력이 도메인 지식인 엔지니어는 아마 엔지니어링 자체에서는 그렇게 뛰어나지 않을 수 있음. 그래도 쌓아온 도메인 지식이 필요한 업계 다른 영역에서 일자리를 찾을 수는 있음

    • 일주일 전 전체 스레드에서는 도메인 전문성이 항상 진짜 해자였다고 했음: https://news.ycombinator.com/item?id=48340411
    • 도메인 지식을 좋은 엔지니어링 원칙보다 훨씬 빨리 배울 수 있다는 말이 보편적으로 맞는지 모르겠음
      쉽게 얻을 수 있는 도메인 지식이라고 오만하게 군 좋은 소프트웨어 엔지니어들이 수많은 ERP 시스템을 망친 적이 있음. IT의 엄청난 부분은 말 그대로 비즈니스 규칙을 시스템에 넣는 일임
    • 부분적으로 동의하지 않음. 큰 틀의 도메인 지식은 빨리 배울 수 있지만, 복잡성을 고려한 미묘한 이해로 다듬는 데는 특히 고유한 조직, 흔히 “소프트웨어 개발 회사”로 여겨지지 않는 조직에서는 수년에서 수십 년이 걸릴 수 있음
      그런데도 좋은 소프트웨어 엔지니어링 관행을 따르지 않는 “전문” 소프트웨어 개발자를 여전히 보고, 코드 리뷰도 함. 주된 경쟁력이 도메인 지식인 엔지니어가 엔지니어링에 뛰어나지 않을 수 있다는 말은, 도메인 지식이 없는 엔지니어에게도 마찬가지로 적용됨. 적어도 내 경험상 그렇다. 우리가 운이 없었을지도 모르지만
    • 가치 있는 도메인 지식의 개발과 습득은 어렵고, 위험하며, 비싸고, 느린 과정임
      가치 있는 도메인 지식은 어제의 지식이 아니라 오늘과 내일의 지식이기 때문임. 도메인 지식이 중요한 분야에서는 그것이 엔지니어링과 깊게 얽혀 있음. Jeff Dean에게 Unreal Engine을 처음부터 개발하라고 맡기진 않을 것임. 그렇다 해도 도메인 지식 전문가들이 완전히 내재화하지 못했거나 충분히 실행하지 않는 소프트웨어 엔지니어링 원칙도 많음. 도메인 지식이 가치 있는 한 이 상태도 계속될 것임. 소프트웨어 엔지니어링 역시 또 하나의 도메인이기 때문임
    • 도메인 지식을 더 빨리 배울 수 있을까? 나는 반대 의견임
      전문 지식을 얻는 것보다 방법론은 훨씬 빨리 개선할 수 있음. 전자는 접근 방식의 문제라 강제하고 빠르게 끌어올릴 수 있음. 후자는 그 사람의 학습 성향, 역량, 당시 가용 시간에 좌우되고, 합리적 지원 이상으로 강제할 수 없음. 또한 스스로 쌓이는 성격이 있어서 초반 학습 곡선이 훨씬 가파름

  • Claude Code와 Opus 4.7을 쓰고 있는데, 생성한 코드가 틀린다기보다 너무 많이 쓰는 경향이 있음
    특정 기능을 생각하고 코드에 가장 잘 맞게 넣는 방식은 여전히 가치 있음. Claude는 종종 스택의 한 계층, 예를 들면 표현 계층을 골라 거기에 밀어 넣음. 몇 주 뒤 같은 데이터가 다른 곳에서도 필요해지면 Claude는 서비스 계층의 코드를 재사용하지 못하고 일종의 “이식”을 함. 사람이 주의를 기울이지 않으면 코드량은 두 배가 되고 로직은 중복됨. Claude 같은 AI 도구가 조만간 이 부분에서 좋아질 것 같진 않음. 내가 일하는 곳에서는 이미 비용을 아끼려고 Opus 4.7 사용을 줄이라는 압박이 있음. 누군가는 “간단한 버그 수정”에는 더 작은 모델을 쓰자고 했음. 가끔은 되겠지만, 실제로 얼마나 자주 미리 간단한 버그 수정이라고 알 수 있을까? 비용이 올라가면 이 도구로 “모든 코드”를 쓰려는 관심은 줄어들 것 같음. 사람들이 더 싸고 덜 효과적인 모델로 옮겨가면, 그 코드를 리뷰하지 말자는 압박도 사라질 가능성이 큼. 결국 어디에 도착할지 보겠지만, 저자가 두려워하는 만큼 극적으로 달라지진 않을지도 모름

    • AI가 너무 많은 코드를 쓴다는 비판에 동의함
      AI에게 운영 코드 줄 수를 절반으로 줄이고, 재사용할 수 있는 다른 라이브러리가 있는지 보라고 말하는 것만으로도 놀라울 만큼 효과적임. 중복을 찾아 빼내는 리팩터링 봇도 만들 수 있을 것 같음. 지금은 기본 제공되지 않지만, 불가능한지는 분명하지 않음
    • 나도 코드가 너무 많아지는 문제를 봄
      다만 열린 질문은 코드가 너무 많은 것이 실제로 문제인지임. 이 도구들은 이제 삶의 일부임. 문제를 더 빨리 풀거나 디버깅하고, 소프트웨어에 버그가 더 적다면, 그건 너무 많은 코드가 아니라 딱 맞는 코드 줄 수일 수 있음
    • 얼마 전 코드베이스에 fooBar()와 fooBarExtended() 두 함수가 있는 상황이 있었음
      후자는 현재 문제에 필요한 추가 매개변수와 기능을 갖고 있었음. 그런데 Claude는 그 함수를 호출하는 대신 첫 번째 함수에 같은 확장 매개변수를 계속 추가하려 했음. 그러지 말라고 말한 뒤에도 나중에 또 같은 제안을 했고, 가끔 정말 짜증남

  • 업계의 미래를 어떻게 보든, 장인 목공에서 장인 소프트웨어보다 더 큰 직업적 성공을 찾기는 어렵다고 봄

    • 맞춤 가구/캐비닛 시장은 이미 꽤 힘들고, 목공은 프로그래머에게 너무 흔한 취미라 우리 중 상당수가 뛰어들면 시장은 금방 심하게 공급 과잉이 될 것임
      내가 만든 가구를 팔아보라는 말을 들은 적이 있는데, 내 대답은 항상 같음. 취미를 직업으로 바꾸는 실수를 한 번 했고, 다시 그 실수를 할 생각은 없음. 적어도 소프트웨어는 아직 꽤 돈을 잘 줌
    • 목공을 무엇으로 보느냐에 따라 다름
      함께 일하는 사람 중 데크, 정원, 카라반, 창고, 울타리 같은 걸 만드는 사람이 있는데 정말 잘 벌고 있음. 물론 공정하게 말하면 그 사람은 실력도 엄청남
    • 손으로 조각한 독특한 모양의 문이 있는 역사적 주택을 갖고 있음
      문틀이 썩어서 목공에게 교체품 제작비로 4천 달러를 냈음. 문 자체를 교체하려면 쉽게 2만5천 달러가 들 것임. 손조각 문이 많은 주요 역사 지구로 이사하면 괜찮은 돈을 벌 수 있음
    • 시장의 아주 작은 비율, 아마 1%도 안 되는 일부는 여전히 수제품에 돈을 낼 의향이 있음. 완전히 현대적이면서 복고풍이면 보너스도 있음. 예를 들면 스팀펑크 키보드 같은 것
      하지만 손으로 만든 소프트웨어에 돈을 내고 싶어 하는 시장 비율은 정확히 0%임
    • layoffs.fyi를 봐라. 곧 해고될 가능성이 높음. 내일이 아니어도 AI가 더 좋아질 때까지 몇 년만 더 주면 됨. 이건 내리막 일방통행임
      목공이 아니라 농사임. 땅을 마련하고 직접 먹을 것을 길러야 함. 경제에 아예 참여하지 않는 것이 유일한 생존법임
답변달기