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

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

경력 배경

• 전문 경력 10년차 소프트웨어 엔지니어로, 디버깅이 더 쉬웠던 이유로 웹 프론트엔드에서 시작했지만 곧 웹 백엔드로 전환한 경력
• 우연의 연속으로 금융, 부기, 결제 처리 도메인의 소프트웨어 개발 역할을 맡았고, 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가 연구자를 불필요하게 만들 수 있다는 가능성
• 목공 취미를 직업으로 바꾸는 선택지까지 떠올리는 결말