메뉴
HN
Hacker News 2일 전

AI 개발, 이대로 지속 가능한가?

IMP
8/10
핵심 요약

시니어 엔지니어의 3년간 AI 활용 경험을 바탕으로, 소프트웨어 개발 라이프사이클(SDLC)에서 AI가 초래한 실질적인 변화와 역할의 지속 가능성을 분석한 글입니다. AI 도구로 인해 아이디어를 구현하는 비용은 크게 줄어들었지만, 조직 전체의 합의와 조정 비용은 오히려 증가하는 딜레마를 보여줍니다. 또한 AI 활용에 능숙한 시니어 엔지니어의 영향력이 막강해진 반면, 업무의 지속 가능성은 위협받고 있어 실무자 관점에서 매우 중요한 통찰을 제공합니다.

번역된 본문

이게 정말 지속 가능할까? 이 주제에 대해 쓰인 글 중 상당수는 크게 두 부류로 나뉜다. 하나는 보통 이 도구를 사용한 지 6개월 정도 된 사람이나 실제 해야 할 업무가 없는 컨설턴트가 쓴, "AI가 나의 생산성을 30% 높였다"는 글이다. 다른 하나는 AI가 소프트웨어 개발 라이프사이클(SDLC)을 어떻게 바꾸는지에 대한 아키텍처 관점의 글로, 주로 벤더의 관점에서 작성되며 인간의 현실적인 문제는 간과하는 경향이 있다.

나는 조금 다른 부분에 관심이 있다. AI 도입을 깊게 진행한 조직에서 시니어 엔지니어로 일하는 것이 3년이 지난 지금 실제로 어떤 모습인지, 그리고 이 직무의 형태가 여전히 유효한지에 대한 것이다.

생각보다 먼저 구축하는 시대 내가 일하는 방식에서 가장 큰 변화는 아이디어와 작동하는 데모 사이의 간격이 사라졌다는 것이다. 3년 전만 해도 의미 있는 제안이 있었다면 그 과정은 익숙했다. 제안서를 작성하고, 피드백을 받고, 다듬고, 가치를 증명하기 위해 소규모 개념 증명(PoC)을 구축하고, 최소 기능 제품(MVP)으로 발전시킬 팀을 배정받은 뒤, 6~12개월 후에 모든 기능이 탑재되고 플랫폼의 다른 부분과 통합된 무언가를 출시했다. 2023년에 개발자 플랫폼 전반에 새로운 서비스 생성 방식을 구축하기 위해 이런 이니셔티브를 진행했었다. 첫 대화에서 MVP까지 약 1년이 걸렸으며, 엔지니어링 작업이 시작되기 전 3개월 정도는 제안서 작성과 조직 내 합의 과정에 할애했다.

지금은 매우 다르게 일한다. 최근의 사례 하나를 들어보겠다. SDLC에서 병목 현상이 발생하는데, 몇몇 팀이 이를 해결하기 위해 자체적인 봇을 구축했지만 어느 것도 규모가 커졌을 때의 실제 문제를 해결하지 못했다. 나는 간결한 제안서와 작동하는 PoC를 함께 작성하여 2주 이내에 두 가지 모두를 시연했고, 이 데모를 활용해 솔루션이 어떤 모습이어야 하는지에 대한 논의를 이끌어냈다. 이제 기존의 산발적인 노력들을 하나로 통합하는 작업을 진행 중이며, 예전 방식보다 훨씬 빠르게 진행되고 있다.

이러한 변화의 대부분은 긍정적이다. 프레젠테이션 슬라이드는 내 업무 흐름에서 거의 사라졌고 나는 그걸 그리워하지 않는다. 슬라이드는 종종 명확성을 강제하는 수단이 되곤 했지만, 동시에 내용을 쉽게 소화할 수 있도록 중요한 세부 사항을 숨기는 곳이기도 했다. PoC를 제안서처럼 활용하는 모델은 앞서 생각한 부분들을 더 일찍, 더 많이 드러내준다. 이해관계자들은 이제 이론적인 타당성을 읽는 것보다 구체적인 맥락에서 어떻게 작동하는지 보는 것을 원하며, 이것이 더 건강한 논의의 방향이다.

하지만 여기에는 분명한 트레이드오프가 존재하며, 업계가 이에 대해 솔직하지 못하다고 생각한다. 무언가를 구축하는 비용은 급격히 낮아졌지만, 조직적으로 합의하는 비용은 줄어들지 않았다. 오히려 늘어났다. 예전에는 제안서 하나 쓸 시간에 각기 다른 세 개의 팀이 동일한 문제에 대한 작동하는 솔루션을 각각 만들어낼 수 있다면, 병목 현상은 엔지니어링에서 조율로 이동하게 된다. 앞서 말한 MR(Merge Request) 리뷰 상황이 좋은 예다. 이제는 다른 사람이 만든 봇을 채택하는 것보다 새로운 봇을 만드는 것이 더 쉬워졌고, 이는 응집력을 달성하기가 더 쉬워진 것이 아니라 더 어려워졌음을 의미한다. 우리는 더 많은 문제를 더 빨리 해결하고 있지만, 조직 수준의 조율 작업이 그 대가를 치르고 있다.

이와 관련하여 한 가지 더 짚고 넘어갈 점은, 이러한 변화가 AI 도구를 활용해 빠르게 구축할 수 있는 사람들에게 유리하고 그렇지 못한 사람들에게 불리하게 작용한다는 것이다. 행동으로 옮기려는 편향성은 분명히 존재하지만, 이것이 공평한 것은 아니다. 이러한 도구를 효과적으로 채택한 엔지니어들이 더 자주 의견을 내고, 그들의 제안이 더 진지하게 받아들어지며, 채택하지 못한 사람들보다 방향성을 더 많이 결정한다. 이는 현재 AI를 적극적으로 도입하는 모든 조직 내부에서 발생하는 기술의 재분배이며, 우리 대부분은 이에 대해 공개적으로 이야기하지 않고 있다.

시니어의 역할은 더 막강해졌지만, 덜 지속 가능해졌다 3년간의 경험에서 직관에 반하는 사실을 하나 꼽자면, AI가 주니어 역할보다 시니어 역할에 더 일찍 자리 잡았다는 점이다. 일반적인 통념은 AI가 주니어 엔지니어를 위협하고 시니어 엔지니어를 순수 전략가로 끌어올린다는 것이다. 내 경험은 오히려 그 반대에 가깝다. 왜냐하면 시니어 엔지니어가 바로 SDLC 전반에 걸쳐 AI를 어디에 적용할 수 있는지 인식하고, 제안서를 작성하고, 조직 내 정치를 헤쳐 나가며, 이제는 직접 그것을 구축할 수 있는 위치에 있는 사람들이기 때문이라고 생각한다. (원문 누락으로 인해 문맥상 시니어 엔지니어가 과거에 했던 일과 지금의 과부하 상태를 묘사하는 부분으로 마무리됩니다.)

원문 보기
원문 보기 (영어)
Is this sustainable? Posted on Sunday May 24, 2026 A lot of what's been written on this topic falls into one of two camps: the "AI made me 30% more productive" piece, usually written by someone six months into using the tools and often by a consultant who doesn't have a job to actually do, and the architectural piece about how AI changes the SDLC, which tends to be written from a vendor perspective and skips over the human reality. I'm interested in something else: what it's actually like to be a senior engineer in an org that's gone deep on this, three years in, and whether the shape of the role still makes sense. We build before we think The biggest change in how I work is the collapse of the gap between idea and demoable thing. Three years ago, if I had a meaningful proposal, the process was familiar: write a proposal, get feedback, iterate, build a small PoC to demonstrate value, get a team assigned to take it to MVP, ship something fully featured and integrated with the rest of the platform six to twelve months later. I ran an initiative like this in 2023 to bootstrap a new style of service creation across our developer platform. It took about a year from first conversation to MVP, with maybe three months of that on the proposal and alignment work before any engineering started. Now I work very differently. A recent example: there's a bottleneck emerging in our SDLC around merge request review, and a few teams have built homegrown bots to address it, none of which solve the actual problem at scale. I wrote a thin proposal and a working PoC together, demoed both within a couple of weeks, and used the demo to drive the conversation about what the solution should look like. We're now consolidating the existing efforts into something cohesive, far quicker than the old process would have allowed. Most of this is good. The slide deck has largely disappeared from my workflow and I don't miss it. Slide decks were often a forcing function for clarity, but they were also a place where we buried detail to make things digestible, and the PoC-as-proposal model exposes more of the thinking earlier. Stakeholders increasingly want to see how something works in a concrete context rather than read a theoretical case for it, and that's a healthier place to have the conversation. But the trade is real, and I don't think the industry is being honest about it. The cost of building has collapsed, but the cost of aligning organisationally has not. If anything, it's gone up. When three different teams can each produce a working solution to the same problem in the time it used to take to write a proposal, the bottleneck moves from engineering to coordination. The MR review situation is a good example: it's now easier to build a new bot than to adopt someone else's, which means cohesion gets harder to achieve, not easier. We're solving more problems, faster, and the org-level alignment work is paying the price. There's a related point worth making, which is that this shift advantages people who can build fast with AI tools and disadvantages people who can't. The bias to action is genuine, but it isn't neutral. The engineers who've adopted these tools effectively get heard more often, get their proposals taken seriously more often, and shape direction more than those who haven't. That's a skills redistribution happening inside every AI-forward org right now, and most of us aren't talking about it openly. The senior role got more powerful and less sustainable The counterintuitive thing I'd report from three years in is that AI landed on senior roles earlier than it landed on junior ones. The standard narrative is that AI threatens entry-level engineers and elevates senior ones into pure strategy. My experience is closer to the opposite, and I think it's because senior engineers are the people positioned to recognise where AI can apply across the SDLC, write the proposals, navigate the org, and now also build the thing themselves. The work that used to need a team now sometimes needs one person with the right tools, and that person tends to be senior because seniority is where the system-level understanding lives. The result, in my case, is that I code more than I have in years. Three years ago I coded maybe once a fortnight, mostly throwaway PoCs to demonstrate concepts. Now I code most days of the week, in between other work. The kind of code is different too. It used to be isolated demos. Now it's PoCs that I'm genuinely comfortable throwing away once they've answered the question, and some integration work at the platform level that previously would have required a dedicated chunk of time I couldn't carve out. The disposability matters. When PoCs are cheap, you can investigate three approaches in the time it used to take to investigate one, and that changes how you understand problems. At the same time, the writing load went up. Not tactical writing, that's mostly disappeared, but strategy and vision work. I'm shaping direction across multiple workstreams simultaneously, in a way I couldn't have three years ago, and AI tools make that possible because I can context-switch between drafts more fluidly. I can work on a few problems at once and produce coherent thinking on each, which used to require sequencing. So the role expanded in two directions at the same time. More hands-on engineering and more strategic writing, alongside more meetings as I get pulled into conversations as the SME on GenAI in developer experience and tooling across the org. Logically this shouldn't be possible. The week is the same length it was three years ago. What gave way is the human-focused work. Mentoring is the clearest example. I have less time for 1-2-1s than I did three years ago, and that isn't an accident, it's a choice I've made under pressure. The 1-2-1 work doesn't benefit from AI tooling. You can't backload it. It requires dedicated time and attention, and when the other parts of the role are expanding to consume the available hours, the mentoring is the first thing to go. I'm not relieved about this and I think it's a real problem, both for me and for the engineers I should be developing. The pattern is the same shape as the alignment problem in the previous section: AI made the technical work cheaper, and the human work, the mentoring, the alignment, the problem definition, became disproportionately expensive relative to everything else, and therefore got squeezed. The other thing that gave way was thinking time. There's very little of it in my working day now. The productivity gains from AI got captured by output volume rather than output quality. The org's expectations rose to absorb the speed-up, and the slack that used to exist between tasks, the unstructured time where strategic thinking actually happens, got eaten first because it's invisible on a dashboard. I'm at a point in my career where thinking is supposed to be most of the job, and most of it now happens on holiday because the working week doesn't accommodate it. The honest version of where I've landed is that the role isn't sustainable at this pace. The motivation right now is real, I'm learning constantly and the work has genuine impact, but the volume of what I'm being asked to deliver is rising faster than AI is making me capable of delivering it. The productivity story says we ship more because we're more productive. The lived version is that we ship more because expectations expanded by more than the productivity gain, and the gap is being made up in hours, attention, and the parts of the role that weren't supposed to be optional. The depth I bet on When I returned from five months of paternity leave in early 2024, the org needed someone at my level to lead GenAI work in developer experience and I was the available person. It wasn't a bet so much as an opportunity I recognised when it showed up. I took enough time to satisfy myself that this wave was different from previous hype cycles before I committed, but