메뉴
HN
Hacker News • 37일 전

AI는 주니어 엔지니어의 가치를 없애지 않았다, 오히려 키웠다

IMP
7/10
핵심 요약

저자는 AI가 주니어 엔지니어의 역할을 대체한 것이 아니라 그 가치를 높였다고 주장합니다. 실제로 인턴이 AI의 도움을 받아 수년간 방치됐던 고객 기능 개발을 주도적으로 완수한 사례를 소개하며, 엔지니어의 본질은 코드 작성이 아니라 기술적 복잡성을 관리하며 고객 문제를 해결하는 것이라고 강조합니다. 또한 AI 덕분에 신입 엔지니어의 교육 비용도 크게 줄어들었다고 분석합니다.

번역된 본문

아이들은 정말 괜찮습니다

AI는 주니어의 가치를 지우지 않았습니다. 오히려 높였습니다.

2026년 8월 18일 · 4분 읽기

"AI가 주니어의 한계적 가치를 집어삼켰다". 이것이 이 주제에 관한 지난 글에서 받은 피드백이었습니다. 이 주장에 따르면, 주니어 엔지니어의 업무는 대략 다음과 같이 진행됩니다.

솔루션이 필요합니다. 더 경험 많은 사람(시니어 엔지니어)이 이를 계획하고 설계합니다. 시니어 엔지니어는 업무를 여러 개의 작은 태스크로 분해하며, 수행해야 할 단계를 명확히 합니다. 각 태스크는 주니어 엔지니어에게 주어집니다. 주니어 엔지니어는 이를 실행하는데, 요즘은 AI 도구에 프롬프트를 입력하고 풀 리퀘스트(PR)를 만드는 것을 의미합니다. PR은 더 시니어인 엔지니어들로부터 피드백을 받습니다. 주니어 엔지니어는 피드백을 받아 다시 AI 도구에 가져가 수정안을 제안합니다. 완료될 때까지 반복합니다.

만약 위의 과정이 실제로 일어나는 일이라면, 왜 주니어 엔지니어가 필요할까요? 그들은 단지 요청을(그리고 때로는 노이즈를) 한 곳에서 다른 곳으로 전달하기만 할 뿐이고, 풀타임 급여를 받습니다. 타당한 지적입니다.

결론을 내리기 전에, 다른 이야기를 살펴봅시다. 어쩌면 같은 이야기를 다른 방식으로 접근한 것일 수도 있습니다.

저희 제품에는 수년간 요청되었지만 아직 만들어지지 않은 기능이 있었습니다. 지나치게 복잡하지는 않았지만, 중요하지도 않았습니다. 적어도 우선순위 문턱을 넘을 만큼 충분히 많은 고객에게 중요하지는 않았습니다. 그래서 해가 거듭될수록 일부 고객은 자신에게 필요한 기능이 없어 실망했습니다.

이번 여름, 저희는 이 문제를 인턴(주니어 엔지니어보다 경력이 짧은)에게 할당했습니다. 인턴이 이 기능 개발을 주도했습니다. 문제와 요구사항을 이해하기 위해 프로덕트 매니저와 대화했습니다. 접근 방식을 담은 설계 문서를 작성하고, 팀과 방향을 맞추고, 직접 만들었습니다. 물론 AI와 함께 일하는 팀의 도움을 받았습니다. 하지만 주도한 것은 인턴이었습니다. 불일치를 처리하고, 기술과 제품 양쪽에서 트레이드오프를 이해했습니다. 문제를 발견할 때마다 접근 방식을 조정했습니다. 그리고 가치를 전달했습니다. AI가 코드 대부분을 생성했지만, 결정의 주인은 인턴이었습니다. 해결되지 못했을 고객 문제가 이제 해결되었습니다. 인턴이, 회사 입장에서 매우 낮은 비용으로 해결한 것입니다.

모든 엔지니어는 복잡성을 관리합니다. 달라지는 것은 그 양입니다.

앞으로도 어떤 회사든 시니어 엔지니어가 필요하다는 사실 이상으로, 주니어 엔지니어가 여전히 가치 있는 실용적인 이유들이 있습니다.

주니어 엔지니어는 여전히 조직에 처리 능력을 더해줍니다. 엔지니어의 일은 명세에 따라 코드를 작성하는 것(또는 AI 도구에 프롬프트를 입력하는 것)이 아니기 때문입니다. 엔지니어의 일은 소프트웨어로 고객 문제를 해결하면서, 어떻게 해결할지 결정하는 데 존재하는 기술적 복잡성을 관리하는 것입니다. 이는 모든 엔지니어에게 해당됩니다. 스태프 엔지니어는 많은 복잡성을 관리하고, 주니어 엔지니어는 적은 복잡성을 관리합니다. 하지만 역할은 같습니다.

이것은 코딩을 넘어섭니다. 문제를 이해하는 것이 필요하고, 고객 관점도 이해하는 것이 필요합니다. 기능을 특정 방식으로 만들면 특정한 트레이드오프가 따라온다는 것을 이해해야 합니다. 그리고 이러한 트레이드오프는 코드베이스보다 더 넓은 맥락을 필요로 하기 때문에, AI가 결정할 수 있는 범위를 넘어섭니다. 기술적 의사결정은 여전히 매우 중요하며, 주니어 엔지니어가 여기에 기여하여 조직이 더 많은 일을 할 수 있게 합니다.

교육이 실제로 훨씬 저렴해졌습니다. 경력 초기 엔지니어의 교육 비용 대부분은 회사의 기술적 맥락, 즉 대규모 코드베이스와 아키텍처의 세부 사항을 이해하는 것과, 언어, 도구, 패턴 같은 소프트웨어 기본 교육을 제공하는 데 듭니다. 과거에는 이것이 주니어 엔지니어의 상당한 주도적 노력(주제를 조사하고 공부하는 것)이나, 기본 개념을 설명하는 데 시간을 쓰는 시니어 동료들의 실제 인력 투입을 필요로 했습니다. 이러한 노력이 완전히 사라진 것은 아닙니다. 인간에게서 나오는 맥락이 여전히 생산성의 핵심이기 때문입니다.

원문 보기
원문 보기 (영어)
The Kids Are Really Alright AI didn't erase the junior's value. It increased it. August 18, 2026 · 4 min read “AI ate the junior’s marginal value” . This is the feedback I got from the last post on this topic . According to this argument, the work of a junior engineer goes something like this: There is a need for a solution. Someone more experienced (a senior engineer) plans it and designs it. The senior engineer breaks down the work in multiple small tasks, clarifying the steps to be taken. Each task is given to a junior engineer. The junior engineer executes it, which nowadays means prompting it to an AI tool, and creating a pull request (PR). The PR receives feedback from more senior engineers. The junior engineer gets the feedback and takes it to the AI tool again, proposing changes. Repeat until done. If the process above is what happens in practice, why do we need a junior engineer? They are just passing through requests (and sometimes adding noise) from one place to the other, and they cost a full time salary. That’s fair. Before we jump to conclusions, let’s look at a different story. Or maybe the same story, approached in a different manner. In our product, there was a feature which had been requested for years, but had not been built yet. It wasn’t overly complex, but it was not critical. Or at least not critical for enough customers to make it through the prioritization threshold. This meant that year over year some customers were frustrated they didn’t have a feature they needed. This summer, we assigned the problem to an intern (that’s less tenure than a junior engineer). The intern led the development of this feature. They talked to the product manager to understand the problem and requirements. They wrote the design document on how to approach it, aligned with the team, and built it. Of course they did that with the help of AI, and the team they were working with. But they led it. They dealt with the inconsistencies, with understanding trade-offs, both in the technical and product areas. They adapted the approach as they found issues. And delivered value. AI did produce much of the code, and they owned the decisions. A customer problem that would not have been solved has now been solved. By an intern, at a very low cost for the company. All engineers manage complexity. What changes is how much. Beyond the fact that any company will need senior engineers in the future, there are very pragmatic reasons why junior engineers are still valuable. Junior engineers still add capacity to an organization. And that’s because the work of an engineer is not to write the code (or prompt an AI tool) according to a spec. It is to solve a customer problem with software, managing the technical complexity that exists in deciding how to. That applies to all engineers. Staff engineers manage a lot of complexity. Junior engineers manage a little complexity. But the role is the same. This goes beyond coding. It requires understanding the problem, and also the customer perspective. It requires understanding that if you build a feature in a particular manner, it will lead to a particular set of trade-offs. And those trade-offs are beyond what AI can decide, because they require context that is broader than the codebase. Technical decision making is still very important and junior engineers add to it, enabling an organization to do more. Training actually became much cheaper. Most of the training cost for an early tenure engineer is to understand the company’s technical context, meaning the nuances of a large codebase and architecture, and to provide basic training on software, like the language, the tooling, the patterns. In the past, this either required meaningful proactivity from a junior engineer, researching topics and studying, or it required actual human effort from more senior peers, who would spend time explaining basic concepts. This effort has not been eliminated, as context coming from humans is still key for productivity in software. But a lot of this work can be short-circuited with the use of AI. Being AI-native is valuable. We cannot, as an industry, say that engineers need to be AI-native in job descriptions and then not hire the people that fit this description the best. If the assumption is that AI is going to radically simplify the technical portion of the role, then the people who have started their careers with AI will be in the best spot once they have acquired the experience. Going back to the earlier example, the feature the intern shipped had been requested for a long time. It wasn’t important enough to get prioritized, but required too much judgment to hand it to AI. These tasks exist and will continue to exist in every team. AI expands what every level can handle, including juniors. More important than that, engineering organizations will continue to need technical judgment. And the future judgment for your organization should be growing right now.