LLM이 내 소프트웨어 엔지니어 경력을 위협하고 있어, 어떻게 해야 할지 모르겠다.

출처: Hacker News

2026년 6월 6일

나는 소프트웨어 엔지니어이며, 올해로 10년 차가 된다. 커리어를 웹 프론트엔드 엔지니어로 시작했는데(당시엔 프론트엔드 코드를 디버깅하는 것이 더 쉬워서 그 길을 택했다), 곧 (웹) 백엔드로 전향했고 뒤돌아보지 않았다.

우연히 백엔드 개발에 발을 들이면서 금융, 회계, 결제 처리 분야의 소프트웨어 개발 역할을 맡게 되었고, 그곳에서 큰 자율성과 제품 매니저·이해관계자와의 가깝고 솔직한 관계를 경험했다.

그 도메인에 대해 많은 것을 배웠다. PCI 규정, 복식부기 원장, 에스크로, 조정, 결제 라이프사이클, 은행 이체 멱등성 등.

당연히 나는 이 분야의 전문가가 되어 차별화된 전문 인력으로 자리매김해야 한다고 생각했고, 도메인 전문가에 대한 수요가 늘어날 조짐이 보이는 만큼 커리어를 그쪽으로 집중하기로 했다.

첫 번째 약화되는 기둥: 도메인‑특화 지식

작년에 나는 금융 분야 회사에 입사했다. 이전까지는 결제·금융 요소가 강한 기업에서 일했지만, 전적으로 금융에만 집중한 회사는 아니었다.

그 회사는 AI를 전폭적으로 도입했기에 입사 첫날부터 ChatGPT와 Claude Enterprise 계정을 받았고, 연구·탐색·코딩에 활용하도록 독려받았다. 다만, 프로덕션에 들어가는 모든 코드는 직접 검토하고 책임져야 한다는 경고는 있었다.

첫 번째 프로젝트는 레거시 온라인 결제 시스템을 정비하는 것이었다. 그 시스템은 엉망이었고, 나는 이전에 비슷한 시스템을 구축한 경험을 살려 맡게 되었다.

다른 회사와 달리, 그들은 내가 코딩 전에 작성하는 “Design Docs”가 엔지니어와 제품 매니저 모두가 읽을 수 있길 원했다. 즉, 기술적인 깊이보다는 아키텍처적인 관점을 강조했다. 나는 최소한의 AI 도움만 받아 첫 문서를 작성했고, 그때는 LLM을 “확률적 앵무새”라고 부르며 그 시각을 가지고 있었다(현재는 달라졌다).

내 지식이 소중하고, LLM이 이를 대체할 수 없다고 생각했다.

그때 매니저가 다가와 말했다. “코드 속도는 괜찮은데 Design Docs가 너무 오래 걸리네. AI 쓰고 있니? 더 많이 써야 해.”

“이건 안 될 거야”라고 속으로 생각했지만 동의했다. 당시 모델은 지금만큼 좋지는 않았지만, 문서 작성과 의사결정 속도를 크게 끌어올려 주었다.

그리고 나는 깨달았다. 수년간 쌓아온 모든 지식—구현 간 트레이드오프, 획득 방식, 이중 청구를 방지하기 위한 멱등성 구조 등—이 점점 쓸모없어지고 있다는 사실을. 모델이 아직 약간의 방향 제시는 필요했지만, 시스템을 어떻게 설계할지에 대한 연결 고리를 스스로 찾아냈다. 이것이 나에게 첫 충격이었다.

하지만 나는 생각했다. “모델이 할 수 있는 건 웹에 떠다니는 수많은 기사와 기술 문서, 그리고 도메인에 적용하는 방법을 설명한 블로그 포스트 덕분이야. 인간에게는 배우는 데 시간이 오래 걸리지만, 그게 바로 모델이 학습하는 데이터잖아.”

모델이 절대 잘하지 못하고 인간이 빛날 영역은 디버깅이다! 나는 레이스 컨디션과 분산 시스템을 프로덕션에서 디버깅한 경험이 풍부했고, 그게 장기적인 고용 가능성의 티켓이었다.

두 번째 약화되는 기둥: 디버깅과 분산 시스템

LLM이 문서 작성과 구현 계획에 능숙해지면서 코딩에도 뛰어나기 시작했다. 2025년 하반기 Claude Code 열풍으로 시작해 Codex가 뒤를 이었다. 그 전에도 나는 매일 LLM을 이용해 단위 테스트를 작성했지만, 전체 구현을 맡기엔 아직 신뢰가 부족했다.

다음 자연스러운 단계는 코딩에 더 많은 AI를 도입하는 것이었다. 솔직히 나는 그게 좋았다. 나는 코드를 프로덕션에 배포하고 사용자가 만족하는 모습을 보는 것을 코딩만큼 좋아했기에, 내가 좋아하는 일을 또 다른 내가 좋아하는 일과 교환한 셈이었다.

LLM은 코딩에 점점 능숙해졌지만, 남겨진 엉망을 디버깅하진 못했다(그때든 인간이든). 그래서 나는 로봇을 조종하는 역할보다 더 큰, 고용 가능성을 보장하는 티켓을 가지고 있었다.

모든 것이 괜찮아 보였다.

그때 MCP, 에이전시 워크플로, Claude 4.5가 등장했고, 하늘이 무너지는 듯했다.

솔직히 Claude 4.5는 그다지 좋지 않았다. 스택 트레이스와 약간의 컨텍스트(대부분 Sentry 링크와 MCP 활성화만 있으면 됨)를 주면 버그의 약 60%를 해결했지만, 가끔은 그럴듯해 보이지만 완전히 틀린 해결책을 제시했다.

하지만 이번엔 나는 기계에 의심을 품지 않았다. 과거라면 하루 종일 디버깅해야 했을 버그가 Claude Code 한 번에 해결되는 것을 보았다. 아직은 전부는 아니지만, 패턴은 명확했다.

그 뒤로 4.6, 4.7, GPT 5.5, Opus 4.8, DataDog MCP가 연이어 등장했다. 이제 나는 CLI 하나로 분산 시스템 전반에 걸친 버그를 한 번에 잡는다. 과거엔 해결하지 못했던 버그, 2일 이상 걸리던 디버깅, 관측성이 부족한 분산 시스템의 버그까지도 90% 이상이 한 번에 해결된다. 이상한 레이스 컨디션, 예상치 못한 코너 케이스, 서드파티 연동 문제, 문서화되지 않은 API 엣지 케이스 등 모든 것이 포함된다. 이제는 거의 개입할 필요가 없다.

물론 나는 여전히 고용 가능하다. 누군가는 코드를 검토하고 로봇을 조종해야 하기 때문이다. 하지만 나는 이제 그냥 기성품 엔지니어에 불과하다. 다른 시니어 엔지니어가 LLM을 조종하는 데 있어 내가 가진 금융·결제 도메인 전문성, 디버깅 직관, 분산 시스템 지식은 모두 프롬프트로 대체될 수 있다.

우리는 일반인과 전문가가 각각의 역할을 가질 것이라고 배워왔다. 하지만 이제 시장은 모두를 일반인으로 만들고 있다. 이것이 반드시 나쁜 것만은 아니다. 하지만 공급·수요의 경제학을 살펴보면, 모두가 일반인이라면 일반인의 가치는 수요가 맞춰지지 않을 경우 급락한다. 그리고 우리는 그 수요가 점점 사라지고 있음을 안다.

아직 남아 있는 세 번째 기둥: 코드 품질과 아키텍처

나는 아직 한 기둥이 남아 있다: 코드 품질과 소프트웨어 아키텍처—요즘은 *“맛”*이라고 불린다1.

내 커리어 동안 나는 항상 리팩터링을 좋아했고, 좋은 코드를 중시했으며, 스프린트 시간 안에서 이를 위해 협상했다. DDD, 헥사고날, 클린 아키텍처… 모든 버즈워드를 알고 있다. 나는 이 주제를 정말 좋아한다. 코드베이스를 어떻게 설계할지, 트레이드오프와 다양한 아이디어를 논의하는 것을 즐긴다.

이것이 마지막으로 남은 기둥이다. 다만 이제는 아무도 신경 쓰지 않는다.

에이전트는 코드베이스를 정리하는 데 매우 서툴다. 조종하지 않으면 순환 의존성 문제를 금방 일으키고, 중복 코드를 만들며, 불필요한 주석을 추가하고, 순수 함수와 부수 효과를 뒤섞으며, SOLID 원칙을 무시한다.

이것이 인간을 고용 가능한 상태로 유지할 수 있는 마지막 기술이었지만, 이제는 … (글이 여기서 끊김)