당신은 '풀스택(Full Stack) 인재'가 되어야 합니다 You Need To Become A Full Stack Person

https://link.coupang.com/a/c4iZOS

LG전자 2025 그램 17 코어Ultra5 - 노트북 | 쿠팡

 

title : You Need To Become A Full Stack Person

​

AI 활용

 

​

I’ll start off by saying that I am not at all an AI doomer - by any stretch. I don’t believe AI will completely wipe out the need for skilled product managers, engineers, data scientists, UX designers, or many, many other positions. It also won’t wipe out the need for actually caring about craft. You know, the opposite of whatever this is:

​

I see the stuff Large Language Models (LLMs) generate daily, and boy do they still need a lot of intelligent human interfacing in the process. This might, of course, be a point in time constraint. Model capabilities can evolve non-linearly and we might just see one or more variants that will be able to perform a range of tech-adjacent tasks completely independently. Especially if guided properly. Today’s not that day.

​

But you know what - even if and when that day comes, I still see LLMs as idea implementation vehicles and not a replacement for creativity, agency, and taste. They are not a substitute for craft and actually knowing what you’re talking about, which is what I wanted to write down some ideas on.

​

If I wanted you to have one key takeaway from this entire essay - AI slop is not a replacement for a trifecta of domain knowledge, product sense, and engineering skills. Congratulations, you can stop reading this post. Or go on to learn more about my rationale.

​

Oh, and while I don’t believe that LLMs will replace us wholesale, all signs point in the direction of a major role expectation re-shuffle. That transition won’t take weeks, but it’s happening already and my goal is to get you prepared for it.

​

Role Flattening#

In my more-than-a-decade career, I’ve spent some time thinking about career moats and even interviewed Cedric Chin, the guy who coined the term for me, about it.

​

The idea behind a career moat is simple - it’s a unique combination of hard-to-acquire skills and talents that set you up for long-term career security and growth. This combination does not answer the “How easy will it be for me to continuously keep my job?” question and instead focuses on “How easy will it be for me to find my next job?” The former can set up perverse incentives ("Nobody on the team knows how this works other than me.") while the latter aligns them with the market ("Nobody in the world does this set of things better than me.").

​

So, naturally you want to establish a career moat for yourself if you want to accelerate your career growth and build in some resilience. The problem is that career moats are hard to build - they require time and intentional focus. The challenge is amplified by current LLM advancements, where some pieces of your existing tech-related moat might not be as durable.

​

Let’s put this into practical terms. If you’re someone who is absolutely killing it at UX design, can easily put that design into code with a prototype, and then be able to clearly outline the customer scenarios that you need to tackle before working with engineering teams - you have a pretty good collection of skills that can set you apart in a sea of candidates. It’s a nice combo, but is not exactly a moat anymore. Putting designs into code is now easier than ever - in the past few weeks alone, I managed to translate several Figma designs into working web-based prototypes in hours, not days or weeks. Best of all, I didn’t need to dive deep into any of the web frameworks that underpinned those. I had a job to do and I did it.

​

A lot of skills that previously required a specialized person (e.g., ability to put designs into prototypes) became and will continue to become more and more commoditized. Computers start getting better than us at many jobs (remember accounting before Excel), but believe me - it’s OK.

​

Not necessarily. This idea does get to the crux of my thesis, though - while skill commoditization is more common, it’s not a replacement a few timeless traits that will be relevant regardless of AI advancements, and these can actually strengthen the aforementioned career moat.

​

With a lot of the CRUD-like development capabilities becoming within reach of anyone with a keyboard and $20 to toss for a monthly subscription, this also means that anyone can start bringing their software ideas to life. But just like the invention of the 3D printer didn’t magically destroy the manufacturing market, LLMs won’t destroy the tech one. Just because we have robotic surgery machines doesn’t mean we no longer need surgeons that understand the innate workings of the human body. They can just do things differently with their expertise, skill, and experience. Ring a bell?

​

I talked about this before, by the way - the right lens to look through here is that the AI agents and LLM-based systems are merely augmentations that allow you to reach for more. While they are getting better quickly, they still need to lean on your skills to build things the right way. If you have no clue about authentication systems, a LLM isn’t magically going to create intrusion-safe code for you that you can ship to production. It might work but that’s way different than work securely and not expose your data.

​

All this is to say that expertise and an array of “augmentation” skills are still relevant. The specific spectrum of skills that will make you successful, however, is different than what we saw in the past decade. This will be uncomfortable if you haven’t thought too much about it before.

​

The toolbox of capabilities that democratizes the end-to-end of the product development process is significantly more accessible than it was before. There are tools that can help think through specifications for projects, start implementing the code, automate the testing and validation process, and then push and monitor things in production. Not bad for the past year alone, right?

​

What’s also changing is the set of well-defined roles in the industry. I see a trend towards role flattening, a phenomenon where well-defined role responsibilities become significantly blurrier. What was once a clear-cut set of priorities for a discipline becomes a much broader set of responsibilities, and nothing showcases that better than the emergence (or reemergence, depending on the field) of the “product engineer” role.

​

A few years back, “product engineer” would’ve gotten a confused look from me. Today? I am one. Not kidding, by the way - it’s what I do at Microsoft.

​

The shift is quite significant compared to traditional product and product-adjacent roles. I don’t wait for engineering resources - I start building. I don’t wait for engineers to implement spec changes - I open the PR myself. I don’t wait for designers to tweak Figma mocks - I spin up a branch, pull the style guidelines via MCP, generate component variations with Claude Code, and push it for review to GitHub, where Copilot Coding Agent does a first pass. Need a prototype in a framework I’ve never touched? Done in hours. A/B test analysis with anomaly detection? Handled. Pattern recognition across thousands of feedback entries? Easy.

​

The lifehack here is to use all the AI tools to scale myself across what used to be hard role boundaries. And best of all, I’m not special here in any way - anyone with enough agency and curiosity can do this now.

​

If you’re stuck in the old ways of waterfall processes, fixed role responsibilities, waiting for permission to execute, or sling code over the wall just because it compiled on the first run - I’ve got bad news for you. There’s a reason that with the advent of vibe coding we are yet to see a Cambrian explosion of software businesses. As it turns out, writing code is not the bottleneck - there’s more to software than just auto-generating buckets of Python files.

​

The New Skill Stack#

Let’s revisit the topic of commoditization of skills. If many tech-related capabilities become easily available via LLMs, what does it mean for all of us that work in the field? If writing code becomes easier without prior knowledge, like that of web frameworks, what should one lean into studying and applying?

​

First of all - nothing will change when it comes to understanding of technology from first principles. Literally zero. Don’t let YouTube gurus fool you, because they are full of it. AI doesn’t obviate the need for being able to actually understand how things work.

​

There is no automated replacement for having deep knowledge of the fundamentals. You need to be able to spot that the produced implementation is bullshit because it copied seventeen CSS files in different folders when it could be one. In the same vein, you should be able to spot that returning the expected two-factor authentication code in the JSON body of the request to get said code is an asinine approach. So - learn how the things you care about actually work, it ain’t going away.

​

Second, you need to build or reinforce a new set of skills. Just like in Mortal Kombat you win through using combos, your career moat depends on you being able to wield skill combos. These are applicable to any career track in tech. Being proficient in all of them is what I call being a full-stack person. Treat them as complementary to the deep expertise you should develop first.

​

You might not at all be surprised to learn that you should be developing these skills regardless of LLM advancements. They are entirely company- and team-agnostic and just as relevant if you’re starting your own SaaS business or working for a mega-corp.

​

For every skill, I also include a sample set of questions you can ask about whatever you’re building. It’s not exhaustive - treat it as a starting point.

​

Creativity and Taste#

LLMs can generate thousands of idea variations, but it can’t tell you which one is right for every scenario. Not only that, but because LLMs are trained on vast amounts of existing content that means that the bulk of the output will just be a rehashing of what already exists. That’s why all the AI slop looks the same and every single vibe-coded website has the same rounded corners and purple-blue hues.

​

LLMs are predictive text on steroids and not a replacement for a human brain. What will set you apart is developing an eye for good design, quality code, understanding what resonates with actual humans, and knowing when something just feels off.

​

It’s the difference between technically correct and genuinely compelling. Smartphones existed before the iPhone, and yet the iPhone easily became the go-to choice for a massive part of the population because of the choices Apple made. LLM-generated code might work, but only someone with creativity and taste can determine whether it actually solves a scenario in a way that delights and solves the underlying problem.

​

Questions to ask#

Does the solution feel intuitive and delightful to use?

What makes this approach more elegant than alternatives?

How does this implementation align with user expectations?

Is the design tasteful?

Does the implementation reflect strong opinions about the product?

Is the code intuitive and maintainable?

Is the code structured in a way that allows easy iteration?

Critical Thinking#

LLMs excel at pattern matching. They’re really good at looking at a massive existing corpus of data and then create “cookie cutters” for similar data.

​

They’re not omnipotent, though. Even the most advanced models struggle big time with context-dependent judgment. Critical thinking means knowing which problems to solve, understanding trade-offs, and recognizing when conventional wisdom doesn’t apply. It’s all about asking better questions, not just finding faster answers. Accuracy is much more important than the speed out the output.

​

Questions to ask#

What problem are we actually trying to solve?

Did we specify the problem in enough detail for the LLM to dissect it?

What are the second-order effects of a decision or implementation?

What assumptions am I making that could be wrong about the architecture or user flow?

Are we painting ourselves into a corner with this design down the line?

Communications#

The ability to translate complexity into clarity becomes more valuable as LLMs handle the bulk of the very boring, monotonous, and repetitive tasks. You already know that model output is highly dependent on the quality of the input - if you provide crisper requirements, you will get better results. All those writing courses and nagging teachers that emphasize clarity of thought will be finally paying off.

​

In a very concrete example, GitHub Spec Kit is a project that my team built that introduces the concept of Spec-Driven Development (SDD). Its entire premise is “better specifications yield better products.” The cost of upfront planning results in LLMs being able to better “understand” the intent and then generate the code that best reflects it. It’s not vibe coding, because you can’t vibe code yourself to a good product.

​

Questions to ask#

Can I explain my concept in enough detail that avoids assumptions?

Am I able to document the user stories and scenarios that the product will solve?

Am I able to ask the questions that will avoid ambiguity and confusion about the project?

Are there unknown unknowns that I haven’t discovered, and how do I go about finding them?

Cross-Domain Knowledge#

You don’t need to be an expert in everything, but understanding how the pieces fit together matters today more than ever. You should know enough about frontend, backend, design principles, infrastructure, and data analysis to be able to have an informed conversations and make sound decisions. That’s the new baseline.

​

When I talk about this point, people tend to get all up in arms - “But I am not a frontend engineer, why do I care?” Because someone who is not a frontend engineer but knows just enough about frontend development and knows how to set up a REST API with the help of Claude Code is going to be running laps around you.

​

Questions to ask#

Do I understand the constraints and trade-offs across the stack?

Can I have a productive conversation with specialists in adjacent domains?

Where are the integration points that typically cause friction?

What are the components that I need for this project to begin with?

What are the state of the art tools that I need to be using to be productive?

Are there any architectural choices I should not be making because that’s going to paint me into a corner in the future?

Is the design I am building actually good?

AI Augmentation#

This isn’t about mastering every single tidbit about AI, ML, and transformers. It’s not about reading every paper on ArXiV either. You must know when and how to leverage existing AI tools effectively.

​

In practice, having this skill means being able to understand what LLMs do well, where they fall short, and how to chain them together to improve your output. It’s easier said than done because we’re in the period of AI development where it’s either all doom-and-gloom or “AGI is right around the corner,” when the reality is much more nuanced. Showing a LLM into the process is not a panacea.

​

Questions to ask#

Which parts of this work can this model handle well enough?

Which model is appropriate for the task that I am trying to accomplish?

Am I replacing creative work or routine work with this LLM workflow?

How do I validate that the LLM output is right?

Are there agents that I delegate tasks to that will make me more efficient?

What’s the right level of human oversight for this task?

Product Sense#

Understanding what to build and why separates tinkerers from product experts. I’ve seen people that call themselves product managers that can’t piece two pieces of customer feedback together - don’t be that. Product sense means having empathy for users, recognizing patterns in feedback, and prioritizing ruthlessly the things that will actually move the needle for the product.

​

To put it bluntly, it’s the skill that prevents you from building technically impressive things that nobody wants.

​

Questions to ask#

What’s the actual customer problem here?

Am I synthesizing feedback or just following it blindly?

Do I ask users for features or patterns that I can use to build the actual solution?

Do I understand the target audience?

What’s the smallest version that delivers real value?

How does the work ladder up to the broader strategy?

Execution Speed#

Ideas are cheap; shipping is hard. Yes, even with vibe coding. Again - look around. Where are the thousands of new SaaS businesses that vibe coding supposedly unlocked? There are not nearly as many as you’d think, and that is because doing things end-to-end is hard. And yet - those that can use modern AI tools to move faster will be at an advantage.

​

Execution speed is about maintaining velocity while keeping in mind why the hell you’re doing this to begin with — knowing when to move fast and ship a MVP versus slow down and do it right. Bias for action compounds over time, and you will need to develop a sense when to push the pedal to the metal.

​

Question to ask#

Am I bikeshedding on irrelevant things?

If this ships today, what’s missing?

Is the decision a one-way or two-way door?

What do I need to learn to make better future decisions?

Will my customers be happy with what I delivered?

Is this incrementally moving me to the end-goal?

Learning Agility#

The half-life of technical knowledge keeps shrinking - in every sense. Web development frameworks become lost in the sands of time faster than you can say “I want pizza.” Learning agility means being able to quickly absorb new concepts, recognize patterns across domains that are applicable in new tools, and adapting your mental models to things that will never be constant. Forget about memorizing frameworks. You need transferable understanding.

​

Questions to ask#

What’s the underlying principle I can apply elsewhere?

How does this relate to patterns I’ve seen before?

What’s the fastest way to validate my understanding?

Are there blind spots in my knowledge that will unlock new insights?

What am I missing, and who do I talk to for me to discover this?

​

Systems Thinking#

As AI handles more isolated tasks, I want to see more people capable of seeing the bigger picture. There are so many people that are highly focused on a set of tasks that they forget about the fact that there’s more to product work than building one subsystem.

​

Systems thinking means understanding how components interact, anticipating cascading effects, and recognizing feedback loops. It’s the skill that prevents local optimizations that hurt global outcomes.

​

Questions to ask#

How does this change ripple through the system?

What are the dependencies I’m not seeing?

Where might this create unintended consequences?

What dependencies will potentially derail my product down the line?

Is it possible that my target audience will be different once I ship?

Agency#

Read up on high agency. No, really - stop reading this blog post, click the link, and spend thirty minutes reading through George’s writing. To me, high agency boils down to a “We’ll figure this out - let’s get to work” attitude. No excuses, no waiting for permission, no futzing around with things that don’t actually have any material impact on the work. High agency people get shit done, and low agency people always find a reason why thing don’t work.

​

Learn to be the bulldozer - no matter the obstacle, you can plow through and pave a way for others.

​

Questions to ask#

Do I just start doing things or do I wait for someone to bless my aspirations?

Do I dwell on the past or do I move forward?

Do I assume that I will figure things out or do I look for reasons things won’t work?

Am I waiting for others to teach me or do I learn things myself?

T-Shaped Is Dead, Long Live Pi-Shaped#

T-shaped used to mean one deep spike plus a thin layer of everything else. That was perfectly fine when roles were somewhat rigid and the handoffs were clean. PMs do one thing, engineers another, and so on.

​

Today, work is much more… messy. Loops are tight and the fastest path from idea to impact crosses multiple disciplines without the bandwidth to necessarily allocate a professional from each discipline to the task. I bet that the durable advantage is now much more π-shaped: two deep spikes sitting on a broad base. Allow me to elaborate on this totally-not-obvious explanation.

​

Broad base: cross-domain fluency — you can speak frontend, backend, data, design, and delivery well enough to make decisions and ship.

Spike 1: product sense — you have taste, judgment, and the ability to turn fuzzy customer problems into clear, valuable outcomes, while having a deep attention to detail.

Spike 2: engineering craft — the skill to make it real, safely and simply, under production constraints.

AI lowers the cost of “type it and it runs.” It does not lower the cost of choosing the right thing, shaping it well, and operating it in the wild. That’s on you. Treat models as multipliers, not managers. They accelerate execution while you own intent, architecture, and accountability.

​

The future is full-stack. Get onboard.

​

---

 

당신은 '풀스택(Full Stack) 인재'가 되어야 합니다

​

저는 절대 AI 종말론자가 아니라는 말부터 시작하겠습니다. 저는 AI가 숙련된 프로덕트 매니저, 엔지니어, 데이터 사이언티스트, UX 디자이너, 혹은 다른 많은 직무를 완전히 대체할 것이라고 생각하지 않습니다. 또한 전문성(craft)에 대한 진정한 관심의 필요성을 없애지도 못할 것입니다. 바로 이런 것과는 정반대의 의미입니다.

저는 대규모 언어 모델(LLM)이 매일 생성하는 결과물을 봅니다. 그리고 이 과정에는 여전히 지적인 인간의 개입이 많이 필요합니다. 물론 이것은 현시점의 한계일 수 있습니다. 모델의 능력은 비선형적으로 발전할 수 있으며, 적절히 유도된다면 기술과 관련된 다양한 작업을 완전히 독립적으로 수행할 수 있는 하나 이상의 변종을 보게 될지도 모릅니다. 하지만 오늘은 그날이 아닙니다.

하지만 설령 그런 날이 온다고 해도, 저는 여전히 LLM을 창의성, 주도성, 그리고 안목을 대체하는 것이 아니라 아이디어를 구현하는 '수단'으로 봅니다. LLM은 전문성과 당신이 무엇에 대해 이야기하고 있는지 아는 것을 대체할 수 없으며, 이것이 제가 글로 남기고 싶었던 생각입니다.

이 글 전체에서 여러분이 단 하나의 핵심 메시지를 얻길 바란다면, 그것은 **"AI가 쏟아내는 저질 콘텐츠(AI slop)는 도메인 지식, 프로덕트 감각, 엔지니어링 기술이라는 3박자를 대체할 수 없다"**는 것입니다. 축하합니다. 이제 이 글을 그만 읽으셔도 됩니다. 아니면 제 근거에 대해 더 알아보셔도 좋습니다.

아, 그리고 저는 LLM이 우리를 통째로 대체할 것이라고 믿지는 않지만, 모든 징후는 주요 역할 기대치의 대대적인 재편을 가리키고 있습니다. 이 전환은 몇 주 만에 일어나지는 않겠지만, 이미 일어나고 있으며 제 목표는 여러분이 이에 대비할 수 있도록 돕는 것입니다.

​

역할 평탄화 (Role Flattening)

10년이 넘는 제 경력 동안, 저는 '커리어 해자(career moat)'에 대해 생각하며 시간을 보냈고, 심지어 저를 위해 그 용어를 만든 세드릭 친(Cedric Chin)을 인터뷰하기도 했습니다.

커리어 해자의 개념은 간단합니다. 장기적인 경력 안정성과 성장을 보장하는, 습득하기 어려운 기술과 재능의 독특한 조합입니다. 이 조합은 "내가 계속 직업을 유지하기 얼마나 쉬울까?"라는 질문에 답하는 것이 아니라, "내가 다음 직업을 찾기 얼마나 쉬울까?"에 초점을 맞춥니다. 전자는 "팀에서 나 말고는 이게 어떻게 작동하는지 아무도 몰라"와 같은 비뚤어진 인센티브를 만들 수 있지만, 후자는 "이 세상에서 나보다 이 일련의 작업들을 더 잘하는 사람은 없어"와 같이 시장의 요구와 자신을 일치시킵니다.

따라서 경력 성장을 가속화하고 회복탄력성을 구축하고 싶다면 당연히 자신만의 커리어 해자를 구축하고 싶을 것입니다. 문제는 커리어 해자를 구축하기가 어렵다는 것입니다. 시간과 의도적인 집중이 필요합니다. 이러한 도전은 현재 LLM의 발전으로 인해 더욱 증폭되고 있으며, 기존 기술 관련 해자의 일부가 예전만큼 내구성이 좋지 않을 수 있습니다.

실질적인 예를 들어보겠습니다. 만약 당신이 UX 디자인에 뛰어나고, 그 디자인을 프로토타입 코드로 쉽게 구현할 수 있으며, 엔지니어링팀과 협력하기 전에 해결해야 할 고객 시나리오를 명확하게 설명할 수 있다면, 당신은 수많은 후보자들 사이에서 돋보일 수 있는 훌륭한 기술 조합을 가진 것입니다. 이것은 좋은 조합이지만, 더 이상 정확히 해자라고 할 수는 없습니다. 디자인을 코드로 옮기는 것은 이제 그 어느 때보다 쉬워졌습니다. 지난 몇 주 동안에만 저는 여러 개의 Figma 디자인을 며칠이나 몇 주가 아닌 몇 시간 만에 작동하는 웹 기반 프로토타입으로 번역해냈습니다. 무엇보다도, 그 기반이 되는 웹 프레임워크에 대해 깊이 파고들 필요가 없었습니다. 저는 해야 할 일이 있었고, 그것을 해냈습니다.

이전에는 전문 인력이 필요했던 많은 기술(예: 디자인을 프로토타입으로 구현하는 능력)이 점점 더 보편화되었고 앞으로도 그럴 것입니다. 컴퓨터는 많은 직업에서 우리보다 나아지기 시작했지만(엑셀 이전의 회계를 기억해 보세요), 저를 믿으세요. 괜찮습니다.

꼭 그렇지만은 않습니다. 하지만 이 아이디어는 제 논지의 핵심에 도달합니다. 기술의 보편화가 더 흔해지긴 했지만, 이는 AI의 발전과 상관없이 유효한 몇 가지 시대를 초월한 특성들을 대체할 수 없으며, 이러한 특성들은 오히려 앞서 언급한 커리어 해자를 강화할 수 있습니다.

CRUD(생성, 읽기, 갱신, 삭제)와 같은 많은 개발 기능이 키보드와 월 20달러의 구독료만 있으면 누구나 접근할 수 있게 되면서, 누구나 자신의 소프트웨어 아이디어를 실현할 수 있게 되었습니다. 하지만 3D 프린터의 발명이 마법처럼 제조 시장을 파괴하지 않았듯이, LLM도 기술 시장을 파괴하지 않을 것입니다. 로봇 수술 기계가 있다고 해서 인체의 본질적인 작동 원리를 이해하는 외과 의사가 더 이상 필요하지 않게 되는 것은 아닙니다. 그들은 단지 자신의 전문 지식, 기술, 경험을 바탕으로 일을 다르게 수행할 수 있을 뿐입니다. 뭔가 떠오르지 않나요?

이전에 이에 대해 이야기한 적이 있습니다. 여기서 올바른 관점은 AI 에이전트와 LLM 기반 시스템이 단순히 여러분이 더 많은 것을 성취할 수 있도록 돕는 '능력 증강(augmentations)' 도구라는 것입니다. 그것들이 빠르게 발전하고 있더라도, 여전히 올바른 방식으로 일을 구축하기 위해 여러분의 기술에 의존해야 합니다. 만약 당신이 인증 시스템에 대해 전혀 모른다면, LLM이 마법처럼 침입으로부터 안전하고 프로덕션에 배포할 수 있는 코드를 만들어주지는 않을 것입니다. 작동할 수는 있겠지만, 그것은 '안전하게 작동하고 데이터를 노출하지 않는 것'과는 전혀 다릅니다.

이 모든 것은 전문성과 일련의 "증강" 기술이 여전히 유의미하다는 것을 말해줍니다. 하지만 여러분을 성공으로 이끌 구체적인 기술의 스펙트럼은 지난 10년간 우리가 봐왔던 것과는 다릅니다. 이전에 이에 대해 많이 생각해 보지 않았다면 불편할 것입니다.

제품 개발 프로세스의 처음부터 끝까지를 민주화하는 능력의 도구 상자는 이전보다 훨씬 더 접근하기 쉬워졌습니다. 프로젝트 사양을 구상하고, 코드 구현을 시작하며, 테스트 및 검증 프로세스를 자동화하고, 프로덕션에 배포하고 모니터링하는 데 도움이 되는 도구들이 있습니다. 불과 1년 만에 이룬 성과치고는 나쁘지 않죠?

또한 업계의 잘 정의된 역할 세트도 변하고 있습니다. 저는 잘 정의된 역할 책임이 상당히 모호해지는 현상인 '역할 평탄화(role flattening)' 경향을 봅니다. 한때 명확했던 직무별 우선순위가 훨씬 더 광범위한 책임 영역이 되었습니다. 이러한 현상을 '프로덕트 엔지니어(product engineer)' 역할의 출현(분야에 따라서는 재출현)보다 더 잘 보여주는 것은 없습니다.

몇 년 전만 해도 "프로덕트 엔지니어"라는 말은 저를 혼란스럽게 했을 것입니다. 오늘은? 제가 바로 그 일을 하고 있습니다. 농담이 아닙니다. 제가 Microsoft에서 하는 일이 바로 그것입니다.

이러한 변화는 전통적인 프로덕트 및 관련 역할과 비교할 때 상당히 큽니다. 저는 엔지니어링 리소스를 기다리지 않고 직접 구축을 시작합니다. 엔지니어가 사양 변경을 구현하기를 기다리지 않고, 직접 PR(Pull Request)을 엽니다. 디자이너가 Figma 목업(mock)을 수정하기를 기다리지 않고, 브랜치를 만들고, MCP를 통해 스타일 가이드라인을 가져오고, Claude Code로 컴포넌트 변형을 생성한 다음, GitHub에 리뷰를 요청하면 Copilot 코딩 에이전트가 첫 번째 검토를 수행합니다. 한 번도 만져본 적 없는 프레임워크로 프로토타입이 필요하다고 요? 몇 시간이면 됩니다. 이상 징후 탐지를 포함한 A/B 테스트 분석? 처리됐습니다. 수천 개의 피드백 항목에서 패턴 인식? 쉽습니다.

여기서의 비결은 모든 AI 도구를 사용하여 과거에는 넘기 어려웠던 역할의 경계를 넘어 제 자신을 확장하는 것입니다. 그리고 무엇보다도, 저는 이 점에서 특별하지 않습니다. 충분한 주도성과 호기심만 있다면 누구나 지금 당장 이 일을 할 수 있습니다.

만약 당신이 폭포수 프로세스, 고정된 역할 책임, 실행 허가를 기다리는 방식, 또는 컴파일이 한 번에 되었다는 이유만으로 코드를 벽 너머로 던져버리는 낡은 방식에 갇혀 있다면, 나쁜 소식이 있습니다. '감(vibe)으로 하는 코딩'이 출현했음에도 불구하고 소프트웨어 비즈니스의 캄브리아기 대폭발을 아직 보지 못한 데에는 이유가 있습니다. 알고 보니 코드 작성은 병목 현상이 아니었습니다. 소프트웨어에는 단순히 Python 파일을 자동으로 생성하는 것 이상의 것이 있습니다.

​

새로운 스킬 스택 (The New Skill Stack)

기술의 보편화 주제로 다시 돌아가 봅시다. 만약 많은 기술 관련 역량들이 LLM을 통해 쉽게 이용 가능해진다면, 이 분야에서 일하는 우리 모두에게 이것은 무엇을 의미할까요? 웹 프레임워크와 같은 사전 지식 없이도 코드 작성이 쉬워진다면, 우리는 무엇을 공부하고 적용하는 데 집중해야 할까요?

첫째, 기술을 제1원칙(first principles)부터 이해하는 것에 관해서는 아무것도 변하지 않을 것입니다. 말 그대로 0입니다. 유튜브 전문가들이 당신을 속이도록 내버려 두지 마세요. 그들은 허풍쟁이입니다. AI가 사물이 실제로 어떻게 작동하는지 이해할 필요성을 없애주지 않습니다.

기본 사항에 대한 깊은 지식을 대체할 수 있는 자동화된 것은 없습니다. 당신은 생성된 구현물이 17개의 CSS 파일을 서로 다른 폴더에 복사했기 때문에 헛소리라는 것을 간파할 수 있어야 합니다(하나로 충분했을 텐데 말이죠). 마찬가지로, 2단계 인증 코드를 요청하는 JSON 본문에 예상되는 인증 코드를 반환하는 것이 어리석은 접근 방식임을 간파할 수 있어야 합니다. 그러니 당신이 중요하게 생각하는 것들이 실제로 어떻게 작동하는지 배우세요. 그것은 사라지지 않습니다.

둘째, 새로운 기술 세트를 구축하거나 강화해야 합니다. '모탈 컴뱃'에서 콤보를 사용해야 이기는 것처럼, 당신의 커리어 해자는 당신이 **'기술 콤보'**를 구사할 수 있느냐에 달려 있습니다. 이는 기술 분야의 모든 커리어 트랙에 적용됩니다. 이 모든 것에 능숙해지는 것을 저는 **'풀스택 인재(full-stack person)'**라고 부릅니다. 이를 당신이 먼저 개발해야 할 깊은 전문 지식을 보완하는 것으로 생각하세요.

LLM의 발전과 상관없이 이러한 기술을 개발해야 한다는 사실에 전혀 놀라지 않을 수도 있습니다. 이것들은 전적으로 회사나 팀에 구애받지 않으며, 당신이 자신만의 SaaS 비즈니스를 시작하든 거대 기업에서 일하든 똑같이 중요합니다.

각 기술에 대해, 당신이 만들고 있는 것에 대해 스스로 물어볼 수 있는 질문 샘플도 포함했습니다. 이것이 전부는 아닙니다. 시작점으로 삼으세요.

​

​

1. 창의성과 안목 (Creativity and Taste)

LLM은 수천 가지 아이디어 변형을 생성할 수 있지만, 어떤 것이 모든 시나리오에 적합한지 말해줄 수는 없습니다. 뿐만 아니라 LLM은 방대한 양의 기존 콘텐츠로 학습되기 때문에, 출력물의 대부분은 이미 존재하는 것의 재탕일 뿐입니다. 모든 AI 저질 콘텐츠가 똑같아 보이고, '감으로 코딩된' 모든 웹사이트가 동일한 둥근 모서리와 보라색-파란색 색조를 띠는 이유가 바로 이것입니다.

LLM은 강화된 자동 완성 기능일 뿐, 인간의 뇌를 대체할 수 없습니다. 당신을 차별화하는 것은 좋은 디자인과 양질의 코드에 대한 안목을 개발하고, 실제 사람들에게 공감을 불러일으키는 것이 무엇인지 이해하며, 무언가 '느낌이 이상할 때'를 아는 것입니다.

이는 '기술적으로 올바른 것'과 '진정으로 매력적인 것'의 차이입니다. 아이폰 이전에도 스마트폰은 존재했지만, 애플이 내린 선택들 때문에 아이폰은 순식간에 엄청난 인구의 선택을 받았습니다. LLM이 생성한 코드는 작동할 수 있지만, 창의성과 안목을 가진 사람만이 그것이 실제로 사용자를 기쁘게 하고 근본적인 문제를 해결하는 방식으로 시나리오를 해결하는지 판단할 수 있습니다.

스스로 물어볼 질문:

• 이 솔루션이 직관적이고 사용하기 즐겁게 느껴지는가?
• 이 접근 방식이 다른 대안보다 더 우아한 이유는 무엇인가?
• 이 구현은 사용자 기대치와 어떻게 부합하는가?
• 디자인에 안목이 반영되어 있는가?
• 구현이 제품에 대한 확고한 신념을 반영하는가?
• 코드가 직관적이고 유지보수하기 쉬운가?
• 코드가 쉬운 반복(iteration)을 허용하는 방식으로 구조화되어 있는가?

​

2. 비판적 사고 (Critical Thinking)

LLM은 패턴 매칭에 탁월합니다. 방대한 기존 데이터 코퍼스를 보고 유사한 데이터에 대한 "쿠키 커터(판박이 틀)"를 만드는 데 정말 능숙합니다.

하지만 전지전능하지는 않습니다. 가장 진보된 모델조차도 맥락 의존적인 판단에는 큰 어려움을 겪습니다. 비판적 사고란 어떤 문제를 해결해야 할지 알고, 트레이드오프(trade-off)를 이해하며, 통념이 적용되지 않는 시점을 인식하는 것을 의미합니다. 이는 단순히 더 빠른 답을 찾는 것이 아니라, 더 나은 질문을 하는 것에 관한 것입니다. 출력 속도보다 정확성이 훨씬 더 중요합니다.

스스로 물어볼 질문:

• 우리가 실제로 해결하려는 문제는 무엇인가?
• LLM이 분석할 수 있을 만큼 문제를 충분히 상세하게 명시했는가?
• 결정이나 구현이 가져올 2차 효과(second-order effects)는 무엇인가?
• 내가 아키텍처나 사용자 플로우에 대해 잘못 가정하고 있는 것은 무엇인가?
• 이 디자인으로 인해 나중에 궁지에 몰리게 되는 것은 아닌가?

​

3. 커뮤니케이션 (Communications)

LLM이 매우 지루하고 단조로우며 반복적인 작업의 대부분을 처리하게 됨에 따라, 복잡성을 명확성으로 변환하는 능력이 더욱 가치 있어집니다. 당신은 이미 모델의 출력이 입력의 품질에 크게 좌우된다는 것을 알고 있습니다. 더 명확한 요구 사항을 제공하면 더 나은 결과를 얻을 수 있습니다. 그동안의 모든 글쓰기 과정과 명확한 사고를 강조했던 까다로운 선생님들의 가르침이 드디어 빛을 발할 것입니다.

매우 구체적인 예로, 저희 팀이 만든 GitHub Spec Kit 프로젝트는 '명세 기반 개발(Spec-Driven Development, SDD)'이라는 개념을 도입합니다. 이 프로젝트의 전제는 "더 나은 명세서가 더 나은 제품을 낳는다"는 것입니다. 초기에 기획에 비용을 들이면 LLM이 의도를 더 잘 "이해"하고, 그 의도를 가장 잘 반영하는 코드를 생성할 수 있게 됩니다. 이것은 '감으로 하는 코딩'이 아닙니다. 감으로 코딩해서는 좋은 제품을 만들 수 없기 때문입니다.

스스로 물어볼 질문:

• 가정을 피하면서 내 콘셉트를 충분히 자세하게 설명할 수 있는가?
• 제품이 해결할 사용자 스토리와 시나리오를 문서화할 수 있는가?
• 프로젝트에 대한 모호함과 혼란을 피할 수 있는 질문을 할 수 있는가?
• 내가 아직 발견하지 못한 '미지의 미지(unknown unknowns)'가 있는가? 그리고 그것을 찾기 위해 어떻게 해야 하는가?

​

4. 다분야 지식 (Cross-Domain Knowledge)

모든 것의 전문가가 될 필요는 없지만, 조각들이 어떻게 맞춰지는지 이해하는 것은 오늘날 그 어느 때보다 중요합니다. 정보에 입각한 대화를 나누고 건전한 결정을 내릴 수 있으려면 프론트엔드, 백엔드, 디자인 원칙, 인프라, 데이터 분석에 대해 충분히 알아야 합니다. 그것이 새로운 기준선입니다.

제가 이 점에 대해 이야기하면 사람들은 "하지만 저는 프론트엔드 엔지니어가 아닌데, 왜 신경 써야 하죠?"라며 발끈하는 경향이 있습니다. 왜냐하면, 프론트엔드 엔지니어는 아니지만 프론트엔드 개발에 대해 '충분히' 알고 Claude Code의 도움을 받아 REST API를 설정할 줄 아는 사람이 당신을 훨씬 앞서 나갈 것이기 때문입니다.

스스로 물어볼 질문:

• 나는 스택 전반의 제약 조건과 트레이드오프를 이해하고 있는가?
• 인접 분야의 전문가들과 생산적인 대화를 나눌 수 있는가?
• 일반적으로 마찰을 일으키는 통합 지점은 어디인가?
• 이 프로젝트를 시작하기 위해 필요한 구성 요소는 무엇인가?
• 생산성을 높이기 위해 사용해야 할 최신 도구는 무엇인가?
• 미래에 나를 궁지에 몰아넣을 수 있기 때문에 선택하지 말아야 할 아키텍처가 있는가?
• 내가 만들고 있는 디자인이 정말 좋은가?

​

5. AI를 통한 (능력) 증강 (AI Augmentation)

이것은 AI, ML, 트랜스포머에 대한 모든 자질구레한 지식을 마스터하라는 것이 아닙니다. ArXiV의 모든 논문을 읽으라는 것도 아닙니다. 당신은 기존 AI 도구를 언제, 어떻게 효과적으로 활용할지 알아야 합니다.

실제로 이 기술을 가졌다는 것은 LLM이 잘하는 것, 부족한 것, 그리고 출력을 향상시키기 위해 LLM들을 어떻게 연결(chain)해야 하는지를 이해할 수 있음을 의미합니다. 지금 우리는 AI 개발의 시대에 살고 있습니다. 현실은 훨씬 더 미묘하지만, 세상은 온통 파멸의 시나리오 아니면 "AGI(일반인공지능)가 코앞에 왔다"는 이야기뿐이라 말처럼 쉽지는 않습니다. 프로세스에 LLM을 도입하는 것이 만병통치약은 아닙니다.

스스로 물어볼 질문:

• 이 작업의 어느 부분을 이 모델이 충분히 잘 처리할 수 있는가?
• 내가 하려는 작업에 적합한 모델은 무엇인가?
• 나는 이 LLM 워크플로우로 창의적인 작업을 대체하고 있는가, 아니면 일상적인 작업을 대체하고 있는가?
• LLM의 출력이 올바른지 어떻게 검증할 것인가?
• 나를 더 효율적으로 만들어 줄, 작업을 위임할 수 있는 에이전트가 있는가?
• 이 작업에 적절한 수준의 인간 감독은 어느 정도인가?

​

6. 프로덕트 감각 (Product Sense)

무엇을, 왜 만들어야 하는지 이해하는 것은 단순한 기술자와 프로덕트 전문가를 구분합니다. 저는 스스로를 프로덕트 매니저라고 부르면서도 고객 피드백 두 조각을 제대로 엮지 못하는 사람들을 본 적이 있습니다. 그렇게 되지 마세요. 프로덕트 감각이란 사용자에 대한 공감, 피드백에서 패턴 인식, 그리고 실제로 제품에 변화를 가져올 것들을 가차 없이 우선순위로 정하는 것을 의미합니다.

직설적으로 말해서, 이것은 당신이 '아무도 원하지 않는 기술적으로 인상적인 것'을 만들지 않도록 막아주는 기술입니다.

스스로 물어볼 질문:

• 여기서 실제 고객 문제는 무엇인가?
• 나는 피드백을 종합하고 있는가, 아니면 맹목적으로 따르고 있는가?
• 나는 사용자에게 기능을 묻고 있는가, 아니면 실제 솔루션을 구축하는 데 사용할 수 있는 패턴을 묻고 있는가?
• 나는 타겟 고객을 이해하고 있는가?
• 실질적인 가치를 전달하는 가장 작은 버전(MVP)은 무엇인가?
• 이 작업이 더 큰 전략과 어떻게 연결되는가?

​

7. 실행 속도 (Execution Speed)

아이디어는 저렴하고, 출시(shipping)는 어렵습니다. 네, '감으로 하는 코딩'으로도 마찬가지입니다. 다시 한번 주위를 둘러보세요. '감으로 하는 코딩'이 열어젖혔다는 수천 개의 새로운 SaaS 비즈니스는 어디에 있습니까? 생각만큼 많지 않습니다. 이는 처음부터 끝까지 무언가를 해내는 것이 어렵기 때문입니다. 그럼에도 불구하고, 현대의 AI 도구를 사용하여 더 빨리 움직일 수 있는 사람들이 유리할 것입니다.

실행 속도는 '도대체 이걸 왜 하고 있는지'를 염두에 두면서 속도를 유지하는 것입니다. 언제 빨리 움직여 MVP를 출시해야 할지, 언제 속도를 늦추고 제대로 해야 할지 아는 것입니다. 행동 편향(Bias for action)은 시간이 지남에 따라 복리 효과를 냅니다. 당신은 언제 가속 페달을 밟아야 할지에 대한 감각을 개발해야 합니다.

스스로 물어볼 질문:

• 나는 관련 없는 사소한 것(bikeshedding)에 매달리고 있는가?
• 만약 오늘 이것을 출시한다면, 무엇이 빠졌는가?
• 이 결정은 편도문인가, 양방향문인가 (되돌릴 수 있는가)?
• 미래에 더 나은 결정을 내리기 위해 무엇을 배워야 하는가?
• 고객이 내가 제공한 것에 만족할 것인가?
• 이것이 나를 최종 목표로 점진적으로 이동시키고 있는가?

​

8. 학습 민첩성 (Learning Agility)

기술 지식의 반감기는 모든 면에서 계속 줄어들고 있습니다. 웹 개발 프레임워크는 "피자 먹고 싶다"라고 말하는 것보다 더 빨리 시간의 모래 속으로 사라집니다. 학습 민첩성이란 새로운 개념을 빠르게 흡수하고, 새로운 도구에 적용 가능한 도메인 전반의 패턴을 인식하며, 결코 일정하지 않을 것들에 당신의 멘탈 모델을 적응시키는 것을 의미합니다. 프레임워크를 암기하는 것은 잊어버리세요. 당신에게는 **전이 가능한 이해(transferable understanding)**가 필요합니다.

스스로 물어볼 질문:

• 다른 곳에 적용할 수 있는 근본적인 원리는 무엇인가?
• 이것은 내가 이전에 보았던 패턴과 어떤 관련이 있는가?
• 나의 이해를 검증하는 가장 빠른 방법은 무엇인가?
• 새로운 통찰력을 열어줄 내 지식의 맹점은 없는가?
• 내가 놓치고 있는 것은 무엇이며, 이것을 발견하기 위해 누구와 이야기해야 하는가?

​

9. 시스템 사고 (Systems Thinking)

AI가 더 많은 고립된 작업을 처리함에 따라, 저는 더 큰 그림을 볼 수 있는 사람들이 더 많아지기를 바랍니다. 너무나 많은 사람들이 하나의 하위 시스템을 구축하는 것보다 프로덕트 작업에 더 많은 것이 있다는 사실을 잊은 채, 일련의 작업에만 고도로 집중합니다.

시스템 사고란 구성 요소가 어떻게 상호 작용하는지 이해하고, 연쇄 효과를 예측하며, 피드백 루프를 인식하는 것을 의미합니다. 이는 전체적인 성과를 해치는 국지적 최적화를 방지하는 기술입니다.

스스로 물어볼 질문:

• 이 변화가 시스템 전체에 어떤 파급 효과를 미칠까?
• 내가 보지 못하고 있는 의존성은 무엇인가?
• 이것이 어디에서 의도하지 않은 결과를 초래할 수 있는가?
• 나중에 내 제품을 탈선시킬 수 있는 잠재적인 의존성은 무엇인가?
• 출시하고 나면 내 타겟 고객이 달라질 가능성이 있는가?

​

10. 주도성 (Agency)

'높은 주도성(high agency)'에 대해 읽어보세요. 아니, 정말로 이 블로그 포스트 읽는 것을 멈추고, 링크를 클릭해서 조지(George)의 글을 읽는 데 30분을 쓰세요. 저에게 '높은 주도성'은 "우리는 방법을 찾을 것이다. 일이나 하자"라는 태도로 요약됩니다. 변명도 없고, 허락을 기다리지도 않으며, 실제 작업에 아무런 영향을 미치지 않는 일에 빈둥거리지도 않습니다. 주도성이 높은 사람들은 일을 완수해내고, 주도성이 낮은 사람들은 항상 일이 안 되는 이유를 찾아냅니다.

불도저가 되는 법을 배우세요. 장애물이 무엇이든, 당신은 그것을 밀어붙이고 다른 사람들을 위한 길을 열 수 있습니다.

스스로 물어볼 질문:

• 나는 그냥 일을 시작하는가, 아니면 누군가 내 포부를 축복해 주기를 기다리는가?
• 나는 과거에 연연하는가, 아니면 앞으로 나아가는가?
• 나는 내가 방법을 찾을 것이라고 가정하는가, 아니면 일이 안 될 이유를 찾는가?
• 나는 다른 사람이 가르쳐 주기를 기다리는가, 아니면 스스로 배우는가?

​

T자형은 죽었다, 파이(π)자형 만세

'T자형'은 하나의 깊은 전문성(spike)과 다른 모든 것에 대한 얕은 지식의 층을 의미했습니다. 역할이 다소 경직되고 인수인계가 깔끔했을 때는 그것으로 완벽하게 충분했습니다. PM은 한 가지 일을 하고, 엔지니어는 다른 일을 하는 식이었습니다.

오늘날의 일은 훨씬 더... 지저분합니다. 피드백 루프는 촘촘하고, 아이디어에서 임팩트까지 가는 가장 빠른 길은 여러 분야를 가로지르며, 각 분야의 전문가를 그 작업에 할당할 만한 대역폭(bandwidth)이 반드시 있는 것도 아닙니다. 저는 이제 내구성 있는 우위가 훨씬 더 **'파이(π)자형'**에 있다고 확신합니다. 즉, 넓은 기반 위에 두 개의 깊은 전문성이 있는 형태입니다. 전혀 명확하지 않은 이 설명을 좀 더 자세히 설명하겠습니다.

• 넓은 기반: 다분야(cross-domain)에 대한 능숙함 — 당신은 결정을 내리고 결과물을 출시(ship)할 수 있을 만큼 프론트엔드, 백엔드, 데이터, 디자인, 그리고 배포(delivery)에 대해 충분히 말할 수 있습니다.
• 전문성 1: 프로덕트 감각 — 당신은 안목과 판단력, 그리고 모호한 고객 문제를 명확하고 가치 있는 결과물로 바꾸는 능력을 갖추고 있으며, 세부 사항에 깊은 주의를 기울입니다.
• 전문성 2: 엔지니어링 전문성(craft) — 프로덕션 환경의 제약 하에서, 그것을 안전하고 단순하게 현실로 만들 수 있는 기술입니다.

AI는 "타이핑하면 실행되는" 비용을 낮춥니다. 하지만 올바른 것을 선택하고, 그것을 잘 다듬고, 실제 환경에서 운영하는 비용을 낮추지는 않습니다. 그것은 당신의 몫입니다. 모델을 관리자가 아닌 '승수(multiplier)'로 취급하세요. 당신이 의도, 아키텍처, 그리고 책임을 소유하는 동안, 모델은 실행을 가속화합니다.

미래는 풀스택입니다. 탑승하세요.

​

#AI시대 #풀스택인재 #역할평탄화 #새로운스킬스택 #파이형인재 #프로덕트감각