10년 차 백엔드 개발자가 느낀 LLM발 커리어 침식기

• 10년 차 소프트웨어 엔지니어가 꽤 솔직하게 털어놓은 글임. 핵심은 “LLM이 내 일을 빼앗는다”보다 더 찝찝함

  • 이 사람은 프론트엔드로 시작했다가 백엔드로 넘어갔고, 이후 금융·회계·결제 처리 쪽에서 커리어를 쌓음
  • PCI 컴플라이언스, 복식부기(double-entry ledger), 에스크로(escrow), 정산(reconciliation), 결제 생명주기, 은행 이체 멱등성 같은 지식을 자기 차별점으로 삼아왔음
  • 쉽게 말하면 “그냥 코드 잘 짜는 백엔드”가 아니라 “돈 흐름을 아는 백엔드”로 살아남는 전략이었음

• 첫 번째로 흔들린 건 도메인 지식이었음

  • 새 회사는 금융 중심 회사였고, 입사 첫날부터 ChatGPT와 Claude Enterprise 계정을 줬다고 함
  • 레거시 온라인 결제 시스템을 다시 설계하는 프로젝트를 맡았는데, 회사는 설계 문서(Design Doc)를 엔지니어뿐 아니라 PM도 읽을 수 있게 쓰길 원했음
  • 처음엔 LLM을 “확률적 앵무새”쯤으로 봤고, 자기 경험은 모델이 못 따라올 거라고 생각했음

• 그런데 매니저가 “코드는 빨리 나오는데 설계 문서가 느리다. AI 더 써라”라고 압박하면서 생각이 바뀌기 시작함

  • 당시 모델이 지금만큼 좋진 않았는데도 문서 작성 속도와 의사결정 정리에 꽤 도움이 됐다고 함
  • 더 충격적이었던 건 결제 시스템의 트레이드오프, 인수·정산 흐름, 중복 과금 방지를 위한 멱등성 구조 같은 걸 모델이 어느 정도 연결해냈다는 점임
  • 저자가 몇 년 동안 현장에서 익힌 “머릿속 지도”가 프롬프트로 호출 가능한 지식처럼 보이기 시작한 거임

• 그래서 저자는 다음 방어선으로 디버깅을 떠올림. “그래도 운영 장애, 레이스 컨디션, 분산 시스템 디버깅은 인간 영역이지”라는 생각

  • 특히 분산 시스템의 프로덕션 버그는 로그, 타이밍, 외부 API, 데이터 상태가 엉켜서 경험 많은 사람이 하루 이틀씩 파고드는 일이 많음
  • 저자는 이걸 장기 고용 가능성을 지켜줄 티켓으로 봤음

• 두 번째로 흔들린 건 바로 그 디버깅 감각이었음

  • 2025년 하반기 Claude Code 열풍, 이후 Codex 같은 도구가 나오면서 LLM을 코드 작성에도 더 적극적으로 쓰기 시작했다고 함
  • 처음엔 유닛 테스트 작성 정도는 매일 맡겼지만, 전체 구현을 맡기기엔 신뢰하지 않았음
  • 그래도 “코딩 자체”와 “사용자에게 기능을 배포하는 즐거움”을 맞바꾸는 느낌이라 받아들일 만했다고 함

• 문제는 MCP, 에이전트 워크플로, Claude 4.5 이후부터였음

  • Claude 4.5는 스택 트레이스와 약간의 컨텍스트, Sentry MCP 정도만 주면 버그의 약 60%를 해결했다고 함
  • 물론 그럴듯하지만 완전히 틀린 답도 냈고, 저자도 모델이 완벽하다고 말하진 않음
  • 하지만 예전 같으면 하루 종일 붙잡았을 버그가 Claude Code 한 번에 해결되는 사례가 나오기 시작한 게 포인트임

• 이후 저자가 체감한 변화는 더 세게 옴

  • Claude 4.6, 4.7, GPT 5.5, Opus 4.8, DataDog MCP 같은 흐름을 거치며 분산 시스템 버그까지 CLI가 잡아주는 수준으로 올라갔다고 주장함
  • 과거엔 2일짜리 디버깅이던 문제, 본인도 못 풀었던 문제, 분산 관측성이 부족한 시스템의 문제까지 해결하는 경우가 생겼다고 함
  • 저자 표현으로는 기묘한 레이스 컨디션, 예상 밖 코너 케이스, 서드파티 연동 문제, 문서화 안 된 API 엣지 케이스까지 90%는 한 번에 잡힌다고 함

• 여기서 저자의 불안이 확 커짐. “나는 여전히 고용 가능하지만, 이제 그냥 LLM을 조종하는 흔한 시니어 개발자 중 하나 아닌가?”라는 질문임

  • 누군가는 코드를 리뷰하고 모델을 조종해야 하니 당장 일자리가 없어지는 건 아님
  • 하지만 금융·결제 도메인 전문성, 분산 시스템 디버깅 직감, 운영 경험이 다른 시니어 개발자와 나를 구분해주는 벽이 아니게 됐다고 느낌
  • 시장이 모두를 제너럴리스트로 밀어 넣으면, 수요가 충분하지 않은 상황에서 제너럴리스트의 가격은 떨어진다는 경제 논리도 꺼냄

• 세 번째이자 아직 남은 기둥은 코드 품질과 아키텍처임

  • 저자는 리팩터링, 좋은 코드, DDD, 헥사고날 아키텍처, 클린 아키텍처, ADR 같은 주제를 좋아했고 실제로 커리어 내내 중요하게 다뤘다고 함
  • 에이전트는 아직 코드베이스를 깔끔하게 유지하는 데 약함
  • 방치하면 순환 의존성, 중복 코드, 쓸데없는 주석, 순수 함수와 사이드 이펙트의 뒤섞임, SOLID 원칙 무시 같은 문제가 빨리 생긴다고 봄

• 그런데 이 마지막 기둥도 업계에서는 점점 “취향(taste)”으로 축소되는 분위기라고 함

  • 예전엔 사람이 읽고 유지보수할 A급, B급 코드베이스가 이상적이었다면 이제는 LLM이 다룰 수 있는 C급, D급 코드베이스도 괜찮다는 식의 현실론이 커진다는 주장임
  • 소스코드의 주요 독자가 인간이 아니라 모델이 된다면, 인간 기준의 아름다운 구조가 덜 중요해질 수 있다는 거임
  • 저자는 이게 선악의 문제라기보다, 자신이 쌓아온 지식의 시장 가치가 줄어드는 문제라고 봄

• 마지막 고민은 그래서 “이제 뭘 해야 하지?”임

  • 저자는 아직 고용되어 있고, 적어도 현재 회사에서는 당분간 일할 수 있다고 봄
  • 하지만 10년 넘게 쌓은 역량들이 점점 덜 희소해지는 장기 흐름을 어떻게 받아들여야 할지 모르겠다고 함
  • 회사의 채용 공고도 예전엔 “특정 영역의 소프트웨어 엔지니어”였지만 이제는 그냥 “소프트웨어 엔지니어”로 바뀌고, 팀 배정은 오퍼 이후에 이뤄진다고 함

• 저자는 더 LLM이 쉽게 따라오기 어려운 영역으로 도메인 전문성을 옮기는 길도 생각함

  • 수학, 통계, 고급 머신러닝을 다시 공부해서 프런티어 랩 연구직으로 가는 선택지를 떠올림
  • 하지만 자기 나라엔 그런 랩이 거의 없고, 있는 곳은 지원자가 몰리며, 가족 문제 때문에 해외 이주도 쉽지 않다고 함
  • 심지어 그 전환이 가능해질 즈음엔 연구직마저 자동화될 수 있다는 불안까지 덧붙임

• 결론이 명확한 글은 아님. 오히려 결론이 없어서 더 현실적임

  • “목공 취미를 직업으로 바꿔야 하나”라는 농담 비슷한 문장으로 끝나는데, 웃기면서도 별로 웃기지 않음
  • 한국 개발자 입장에서도 남 얘기가 아닌 게, 우리도 도메인 지식·운영 경험·아키텍처 감각을 시니어의 핵심 가치로 이야기해왔기 때문임
  • 이제 질문은 “LLM을 쓸 줄 아느냐”가 아니라, “LLM이 흔하게 만든 능력 위에서 나는 뭘 더 희소하게 만들 수 있느냐”에 가까워짐

---

기술 맥락

• 이 글에서 중요한 기술적 변화는 LLM이 코드 생성 도구에서 운영 컨텍스트를 읽는 에이전트로 넘어갔다는 점이에요. 단순히 함수 하나를 만들어주는 수준이면 개발자의 경험이 여전히 큰 차이를 만들지만, Sentry나 DataDog 같은 도구와 붙으면 모델이 장애 상황의 단서를 직접 읽기 시작하거든요.

• MCP가 언급되는 이유도 여기에 있어요. 모델이 스택 트레이스, 로그, 모니터링 데이터, 이슈 문맥을 한 번에 가져올 수 있으면 “사람이 여기저기 콘솔을 뒤지는 시간”이 줄어들어요. 저자가 디버깅 역량의 가치 하락을 느낀 건 모델 자체보다 이 연결성이 커졌기 때문이에요.

• 결제 시스템 도메인 지식도 비슷해요. 멱등성, 정산, 에스크로, 중복 과금 방지는 원래 경험 많은 백엔드 개발자의 강점이었어요. 그런데 이 지식은 공개 문서, 블로그, 장애 회고, API 문서에 많이 남아 있어서 LLM이 패턴으로 학습하기 좋은 영역이기도 해요.

• 아키텍처가 마지막 기둥으로 남는 이유는 코드 구조의 품질이 단기 정답보다 장기 유지보수에 걸려 있기 때문이에요. 다만 조직이 “사람이 읽기 좋은 코드”보다 “에이전트가 계속 수정 가능한 코드”를 더 실용적으로 보기 시작하면, 좋은 구조의 기준 자체가 바뀔 수 있어요.