메뉴
HN
Hacker News 51일 전

LLM이 내 소프트웨어 엔지니어 커리어를 잠식하고 있다

IMP
9/10
핵심 요약

10년 차 소프트웨어 엔지니어가 LLM의 발전으로 인해 오랜 기간 쌓아온 도메인 지식과 분산 시스템 디버깅 능력이 무가치해지는 것을 경험하며 겪은 위기감을 고백합니다. AI 도구가 설계 문서 작성과 시스템 설계, 코드 작성을 빠르게 대체하면서 개발자의 핵심 역량이었던 전문성마저 위협받고 있습니다. 이는 단순 반복 코딩을 넘어 엔지니어의 고차원적 문제 해결 능력까지 AI가 대체할 수 있음을 보여주는 중요한 사례입니다.

번역된 본문

LLM이 내 소프트웨어 엔지니어 커리어를 잠식하고 있지만 나는 어떻게 해야 할지 모르겠다. 2026년 6월 6일. 나는 올해로 10년의 실무 경력을 쌓은 소프트웨어 엔지니어다. 웹 프론트엔드 엔지니어로 커리어를 시작했지만(당시에는 프론트엔드 코드를 디버깅하는 것이 더 쉬웠기 때문에 그 길을 택했다), 곧 웹 백엔드로 전환했고 후회한 적이 없다. 여러 가지 우연한 계기로 백엔드 개발에 발을 들이게 된 후, 금융, 회계, 결제 처리 도메인에서 소프트웨어 개발 역할을 맡게 되었다. 이 과정에서 나는 높은 자율성을 누렸고 프로덕트 매니저(PM) 및 이해관계자들과 긴밀하고 솔직한 관계를 유지했다. 나는 해당 도메인에 대해 많은 것을 배웠고 이를 위해 효과적으로 프로그램을 작성하는 방법을 터득했다: PCI 컴플라이언스, 복식 부기 원장, 에스크로, 정산(Reconciliation), 결제 라이프사이클, 은행 이체의 멱등성(Idempotency) 등이 그것이다. 그때는 내 경력을 도메인 전문가로 만드는 데 집중해야 한다는 것이 명백해 보였다. 그래야 전문가로서 두각을 나타내고, 도메인 전문가에 대한 필요성이 증가하는 징후를 보이는 분야에서 나를 차별화할 수 있다고 생각했다.

잠식되기 시작한 첫 번째 기둥: 도메인 특화 지식 작년, 나는 금융 워크스페이스 분야의 한 회사에 채용되었다. 지금까지 나는 운영 및 서비스에 강력한 결제 및 재무 구성 요소를 가지고 있지만 오직 금융에만 집중하지는 않는 회사들에서 일해왔다. 이 회사는 AI를 전적으로 수용했기 때문에, 나는 입사 첫날부터 ChatGPT와 Claude Enterprise 계정을 받았고 연구, 탐색, 심지어 코딩에 이르기까지 이를 사용하도록 권장받았다(단, 프로덕션에 반영되는 모든 코드 라인은 여전히 내가 검토하고 책임져야 한다는 경고와 함께).

내 첫 프로젝트 중 하나는 레거시 온라인 결제 시스템을 개편하는 것이었는데, 이는 엉망진창이었다. 그들은 (여러 이유 중에서도) 해당 시스템 구축에 대한 나의 이전 경험을 바탕으로 나를 채용했고 그 임무를 나에게 맡겼다. 내가 지금까지 일했던 다른 회사들과 달리, 이 회사는 내가 코딩 전에 작성하는 '설계 문서(Design Docs)'가 엔지니어와 프로덕트 매니저 모두 읽을 수 있기를 원했다. 즉, 기술적인 심층 내용보다는 아키텍처 관점의 글이어야 했다. 나는 AI의 도움을 거의 받지 않고 첫 번째 문서를 작성했다 — 당시에는 LLM을 '확률적 앵무새(Stochastic parrots)'라고 부르기도 했지만, 지금은 그런 생각을 하지 않는다 — 그리고 문서를 전달했다. 나는 내 지식을 가치 있게 여겼고 어떤 LLM도 이를 대체할 수 없다고 생각했다.

그런 다음 내 매니저가 나에게 연락했다: "코드는 좋은 속도로 제출하고 있지만, 설계 문서를 전달하는 데 너무 오래 걸리고 있어. AI를 사용하고 있나? AI를 더 많이 활용해 봐." "이게 작동할 리가 없지"라고 내 머릿속으로 생각했지만, 동의했다. 당시 모델들은 지금 우리가 가진 것들만큼 좋지는 않았지만, 글쓰기와 의사결정 측면에서 확실히 속도를 크게 높여주었다.

그리고 나서 깨닫기 시작했다. 내가 수년간 축적해 온 모든 지식: 구현 방식 간의 트레이드오프, 매입(Acquiring)이 작동하는 방식, 이중 결제를 방지하기 위해 멱등성을 구조화하는 방법 등 모든 것이 쓸모없어지고 있었다. 모델은 여전히 약간의 방향 제어가 필요했지만, 그러한 시스템을 어떻게 구조화할지 연결하는 것이 가능했다. 이것이야말로 오랜 실무 경험을 통해서만 뇌에 발달하는 가장 어려운 부분이었다. 이것이 나의 첫 번째 충격이었다.

하지만 당연히, 나는 이렇게 생각했다. 웹에는 그런 복잡한 시스템이 어떻게 작동하는지 설명하는 기술 문서와 블로그 게시물이 넘쳐난다. 인간에게는 그 모든 것을 배우는 데 오랜 시간이 걸릴 수 있지만, 그것은 훈련 데이터이므로 모델이 습득할 수 있다. 하지만 모델이 결코 잘할 수 없고, 그래서 인간이 빛을 발할 분야가 있는데, 그것은 바로 디버깅이다! 나는 프로덕션 환경에서 레이스 컨디션(Race conditions) 및 분산 시스템을 디버깅한 풍부한 경험을 축적해 왔다. 그것이 내 장기적인 고용 가능성을 보장하는 티켓이라고 생각했다.

잠식되기 시작한 두 번째 기둥: 디버깅 및 분산 시스템 그래서, LLM이 문서 작성과 실제 구현 계획을 도우면서 좋은 성과를 내기 시작한 후, 이내 코드 작성에서도 뛰어난 능력을 보여주었다. 이는 2025년 하반기 Claude Code의 붐을 시작으로, Code...

원문 보기
원문 보기 (영어)
LLMs are eroding my software engineering career and I don't know what to do 06 Jun, 2026 I'm a software engineer, completing 10 years of professional experience this year. I started my career as a web frontend engineer (it was easier for me to debug frontend code back then, so I chose that path), but shortly transitioned to (web) backend and never looked back. Through a series of coincidences, once I stepped into backend development, I ended up working in software development roles in the domains of finance, bookkeeping and payment processing, where I had great autonomy and a close and candid relationship with Product Managers and stakeholders. I learnt a lot about the domain and how to effectively write programs for it: PCI compliance, double-entry ledgers, escrows, reconciliation, payment lifecycles, bank transfer idempotency, etc. It was, then, obvious that I should focus my career on becoming an expert on that domain to stand out as a professional and differentiate myself in a field that showed signs of an increasing need for domain specialists. The first pillar to erode: domain-specific knowledge Last year, I got hired by a company in the finance workspace. So far, I had worked on companies that do have a strong payment and finance component to their operations/offerings, but that were not solely finance-focused companies. That company also embraced AI wholeheartedly, so I got ChatGPT and Claude Enterprise accounts from day one and was encouraged to use them for my research, exploration, and even coding, albeit with a warning that I should still review and own every single line that made it into production. One of my first projects involved reworking the legacy online payment system, which was a mess. They hired me for (among other things) my previous experience in building that and trusted me with the task. Different from the other companies I had worked for so far, they wanted the "Design Docs" I write before coding to be readable by both engineers and product managers - so they shouldn't be a technical deep dive and more of an architectural view. I wrote my first one with minimal AI assistance - I even called LLMs "stochastic parrots" at the time, a view I no longer hold - and delivered it. I valued my knowledge and thought no LLMs could replace it. Then my manager reached out to me: even though you're delivering code at a good pace, you're taking too long to deliver those Design Docs. Are you using AI? You should use more AI. "No way this will work", I thought in my head, but agreed. The models at that time were not as good as the ones we have now, but they did provide a good speed-up on my writing and even the decision-making. And then I started realizing: all the knowledge I have accumulated over the years: the trade-offs between implementations, how acquiring works, how to structure idempotency to prevent double-charges, everything, was becoming useless. Even though the models still needed some steering, they could connect the dots on how to structure such systems, which was the hardest part that only develops in your brain after years of hands-on experience. That was my first shock . But sure, I thought, they can do that because there's plenty of articles on the web on how that shit works along with all the technical documentation, and we have blog posts explaining how to apply the technical tools to the domain. For humans, it may take a long time to learn all that, but that's training data so the models can pick it up. What the models will never be good at, and that's where humans will shine, is debugging! I had accumulated a good experience debugging race conditions and distributed systems in production. That was my ticket to long-term employability. The second pillar to erode: debugging and distributed systems So, after LLMs started getting good at writing docs and helping plan the actual implementations, they became good at coding. It started in the second half of 2025 with the Claude Code hype, then Codex came and so on. Although I was using LLMs for writing unit tests every day before that, I wasn't trusting them to write the full implementation yet. The natural next step was to introduce more AI into writing code. And honestly, I liked it. I like shipping things to production and seeing users happy as much as I like coding, so I was trading one thing that I like for another one that I also like, it was fair. LLMs were becoming good at coding, but it still couldn't debug the mess left behind (by then or by the humans), so I still had a role that was bigger than steering the robot - a ticket to employability. Everything seemed fine. Then came the MCPs, the agentic workflows and Claude 4.5 and the sky started to fall. Claude 4.5, to be honest, wasn't that good. It solved like 60% of the bugs given a stack trace and some context (a Sentry link with Sentry MCP enabled was all it took in most cases). Sometimes it gave a solution that sounded plausible but was totally wrong. This time, however, I stopped doubting the machines. I saw bugs that in the past would easily take 1 day of full-time debugging being one-shotted by Claude Code. Of course, not all of them yet , but the pattern was clear. Then came 4.6, 4.7, GPT 5.5, Opus 4.8 and the DataDog MCP... Now I have CLIs that one-shots bugs across distributed systems for me. Bugs that I couldn't solve in the past. Bugs that would take 2 days of full-time debugging. Bugs across distributed systems that lack distributed observability. 90% of the bugs are one-shotted now, including bizarre race conditions, unexpected corner-cases, third-party integration issues, undocumented API edge cases, everything. I hardly have to intervene. Of course, I'm still employable because someone has to review the code and steer the robot. But I'm just another off-the-shelf engineer now. I have no domain expertise that another Sr. engineer steering an LLM cannot match. All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable . We were taught that generalists and specialists will always have their roles. But now the market is shaping everyone into becoming a generalist. That's not a bad thing per se , until you look under the economics of supply and demand: if everyone is a generalist, the price of a generalist falls if there's no demand to match. And we all know the demand is drying up. The third pillar, the one that hasn't eroded yet: code quality and architecture I still have one pillar standing, though: code quality and software architecture - what's now being reduced to being called "taste" 1 . Along the course of my career, I always liked to refactor, always prized good code, and negotiated time in the sprint for it. DDD, Hexagonal, Clean Architecture, you know all the buzzwords. I like this topic, I like to discuss the trade-offs and different ideas on how to shape codebases. I really like it. This is the last pillar standing. Except that nobody cares anymore. Agents do a really bad job at keeping codebases organized. If you don't steer them, they'll hit a circular dependency issue sooner than you think. Will duplicate code. Add unnecessary comments. Mix up pure functions and side-effects. Disregard the principles of SOLID. That should keep humans employed, except that this skill is now being reduced to the word "taste". But it's not just a renaming, the industry is moving to a world where code organization is less important. Sure, humans should steer the agent to prevent spaghetti codebases with circular dependency graphs. We don't want F -rated codebases that are impossible to touch without breaking something. But a C or D ? It's now fine. Nobody needs A or B -grade codebases anymore because they're being made for LLMs, not for humans to read. I don't want to argue if this is inherently good or bad. If the source code is now written for machines to read and not humans, it may be actually ok t