---
title: 'AI가 기획·개발·디자인의 경계를 지운다면, 무엇이 남는가'
tags:
  - ai
  - essay
  - software-engineering
  - future-of-work
  - product-development
published: true
date: 2026-06-12
description: '직군의 경계가 무너진다는 말은 절반만 맞다. 무너지는 건 생산이고, 판단과 책임은 오히려 남는다.'
thumbnail: /thumbnails/2026/06/when-job-titles-blur.png
---

## 개요

"프로그래밍의 장벽은 믿을 수 없을 만큼 낮아졌다. 이제 모두가 프로그래머다 — 컴퓨터에게 말만 하면 된다." 젠슨 황이 [2023년 Computex 기조연설](https://fortune.com/2023/05/30/nvidia-ceo-jensen-huang-everyone-programmer-with-ai-chipmaker-taipei-computex/)에서 한 말이다. 샘 올트먼은 [Alexis Ohanian과의 인터뷰](https://fortune.com/2024/02/04/sam-altman-one-person-unicorn-silicon-valley-founder-myth/)에서 테크 CEO 친구들과의 단톡방에 "1인 십억 달러 회사가 언제 처음 나올지"를 두고 내기가 걸려 있다고 했다. AI 없이는 상상도 못 했을 일이, 이제는 일어날 일이 됐다는 것이다.

무대 위의 과장으로만 들리지 않는 이유는, 실제 일터의 풍경이 그 방향으로 움직이고 있어서다. 기획자가 에이전트를 시켜 동작하는 프로토타입을 하루 만에 만든다. 디자이너가 직접 컴포넌트를 짜서 PR을 올린다. 개발자가 시안을 뽑고 카피를 쓴다. 며칠 전까지 "그건 네 일이 아니"라고 선을 긋던 경계가 슬그머니 흐려진다. 통계도 같은 방향이다. Figma가 2025년에 제품을 만드는 사람 1,199명을 조사한 [리포트](https://www.figma.com/blog/2025-shifting-roles-report/)에서, 64%가 자기 일이 두 개 이상의 직군에 걸쳐 있다고 답했고, 3분의 1 이상은 세 개 이상이라고 답했다. 한 해 동안 수행하는 업무의 가짓수는 1년 새 17.5% 늘었다.

담론은 한발 더 나가 있다. ChatPRD를 만든 Claire Vo는 [Product Management Is Dead](https://www.chatprd.ai/blog/product-management-is-dead)에서 기획·디자인·개발의 삼각 편대가 "여러 영역을 다루는 제너럴리스트 팀"으로 대체되는 중이라고 썼고, Dan Shipper는 [지식 경제의 다음은 배분 경제](https://every.to/chain-of-thought/the-knowledge-economy-is-over-welcome-to-the-allocation-economy)라며 일하는 사람의 본질이 "직접 만드는 사람"에서 AI에게 일을 맡기고 결과를 거두는 "모델 매니저"로 바뀐다고 주장했다. 얼마나 아느냐가 아니라 얼마나 잘 맡기느냐로 평가받는 시대가 온다는 것이다.

그래서 어디서나 같은 결론이 들린다. 직군의 경계는 낡았다. 지워야 한다. 모두가 만드는 사람(builder)이 된다.

이 말은 절반만 맞다. 그리고 틀린 절반이 더 중요하다.

[지난 글](https://yceffort.kr/2026/06/do-you-need-to-read-code)에서 나는 코드를 읽는 일이 사라지는 게 아니라 "무엇을 검증해야 하는지 아는 일"로 이동한다고 썼다. 직군 경계도 같은 구조다. 무너지는 한 가지와 남는 한 가지가 있고, 둘을 구분하지 못하면 "경계를 지우자"는 좋은 슬로건이 위험한 조직 설계로 바뀐다. 질문을 하나로 압축하면 이렇다.

**누구나 무엇이든 만들 수 있게 됐다면, 기획·개발·디자인의 경계는 지워도 되는 걸까?**

먼저 "지워야 한다"는 입장을 최대한 강하게 세운다. 약하게 세워놓고 두들기면 의미가 없다.

## 찬성: 경계는 도구가 만든 칸막이였다

**첫째, 직군 경계의 상당 부분은 도구 숙련의 부산물이었다.** 코드를 칠 줄 알아야 개발자였고, 피그마를 다룰 줄 알아야 디자이너였고, 스펙 문서를 쓸 줄 알아야 기획자였다. 그 "만들 줄 아느냐"가 진입장벽이었고, 장벽이 곧 경계였다. 그런데 이 장벽은 본질이 아니라 도구의 한계였다. 그림을 그리려면 손이 필요했듯, 화면을 만들려면 코드가 필요했을 뿐이다. AI가 그 손을 대신하면 장벽이 사라지고, 장벽 위에 세워진 경계도 같이 무너진다. 젠슨 황의 말이 정확히 이 뜻이다. 컴퓨터에게 말만 하면 되는 시대에, "할 줄 아느냐"로 사람을 가르던 선은 의미를 잃는다. 그리고 위에서 본 Figma의 숫자들 — 64%가 두 개 이상의 직군에 걸쳐 일한다 — 은 이게 예측이 아니라 진행형이라는 증거다.

**둘째, 경계의 진짜 비용은 핸드오프였다.** 제품이 느린 이유의 절반은 직군 사이의 번역과 대기였다. 기획이 문서를 넘기고, 디자이너가 시안을 그리고, 개발이 받아 구현하고, 다시 QA로 넘어간다. 단계마다 의도가 새고, 줄을 서서 기다린다. 핸드오프 — 직군 사이에서 산출물을 넘기는 인수인계 — 가 한 번 일어날 때마다 머릿속에 있던 의도는 문서로, 문서는 시안으로, 시안은 코드로 손실 압축된다. 한 사람이 의도를 끝까지 가져가면 이 손실이 통째로 사라진다. AI는 그걸 가능하게 한다. 경계를 지우는 건 일을 대충 하자는 게 아니라, 번역 비용을 0으로 만들자는 공학적 선택이다.

**셋째, 통합은 새 현상이 아니라 반복된 패턴이다.** 한때 프론트엔드와 백엔드는 다른 직군이었지만, 2010년 전후로 풀스택이라는 말이 퍼지더니 주류가 됐다. 개발(Dev)과 운영(Ops)은 부서 벽으로 갈라져 있었지만, Amazon의 Werner Vogels는 이미 [2006년 ACM Queue 인터뷰](https://queue.acm.org/detail.cfm?id=1142065)에서 그 벽을 헐었다고 선언했다. "전통적인 모델은 개발과 운영을 가르는 벽 너머로 소프트웨어를 던져놓고 잊어버리는 것이다. Amazon은 아니다. 만든 사람이 직접 운영한다(You build it, you run it)." 그 후로 20년, 데브옵스가 이겼다는 데 이견이 있는 사람은 없다. 매번 "그 둘은 다른 직군"이라던 사람들이 있었고, 매번 통합한 쪽이 더 빠르고 더 좋은 제품을 만들었다. 직군 경계의 붕괴는 일탈이 아니라, 도구가 충분히 좋아질 때마다 반복되는 정상적인 수렴이다. AI는 그 수렴을 한 단계 더 밀 뿐이다.

**넷째, 작은 팀이 경계 있는 조직을 이긴다.** Linear는 기능 하나를 디자이너 한 명과 엔지니어 두 명, 세 명이 만든다. [전담 PM은 없고](https://www.lennysnewsletter.com/p/how-linear-builds-product) 기획 업무는 엔지니어와 디자이너에게 분산돼 있다. 그렇게 만든 제품이 업계에서 가장 완성도 높다는 평을 듣는다. AI로 무장하면 이 축소는 여기서 멈추지 않는다 — 서너 명이, 혹은 한 명이 예전 스무 명 몫의 제품을 만든다. 올트먼의 1인 유니콘 내기가 그 끝점이다. 경계는 애초에 커진 조직이 협업을 관리하려고 만든 장치였는데, AI가 그 규모 자체를 필요 없게 만든다. 경계가 사라지는 게 아니라, 경계가 필요했던 이유가 사라진다.

**다섯째, 판단조차 점점 도구가 된다.** 가장 흔한 반론을 미리 막아두자. "생산은 AI가 해도 판단은 사람 몫"이라는 방어선 말이다. 그런데 그 방어선도 밀리고 있다. 코드 리뷰는 이미 에이전트가 1차로 달고, 접근성 위반은 자동으로 잡히고, 디자인 시안에는 AI 비평이 붙고, 기획서의 빈틈도 AI가 짚는다. 직군의 알맹이가 판단이라면, 그 판단마저 도구화되는 중이다. Shipper의 배분 경제가 말하는 게 이 단계다. 사람의 일은 판단을 내리는 것에서 판단을 맡기는 것으로 한 칸 더 물러난다. 그러니 "판단은 남는다"는 위안은 시간이 갈수록 얇아진다.

여기까지가 찬성 측의 최선이다. 꽤 강하다. 특히 둘째와 다섯째는 정면으로 받기 어렵다. 그런데 이 논증 전체가 '경계'라는 한 단어에 서로 다른 두 가지를 욱여넣고 있다.

## 그러나: '경계'라는 말에 두 가지가 섞여 있다

**누가 만들 수 있는가**라는 경계와, **무엇이 맞는지 누가 판단하고 책임지는가**라는 경계. 이 둘은 같이 움직이지 않는다. 앞엣것은 무너지고, 뒤엣것은 남는다. 찬성 논증을 하나씩 다시 보자.

### 1. 만들 수 있다는 능력과 맞는지 아는 능력은 다르다

코드를 뽑는 일은 AI가 해도, 그 코드가 맞는지 — 안전한지, 나중에 고칠 수 있는지, 일어나면 안 되는 일이 안 일어나는지 — 를 아는 일은 사람에게 남는다. 코드에서 성립했던 이 구분이 직군에서도 똑같이 성립한다.

각 직군의 진짜 알맹이는 산출물을 만드는 손기술이 아니라, 그 산출물이 맞는지 가려내는 판단이었다. 디자인의 알맹이는 예쁜 시안을 그리는 손이 아니라, 이 화면이 실제 사용자 앞에서 작동하는지 — 엣지 상태에서 무너지지 않는지, 접근성이 깨지지 않는지 — 를 아는 눈이다. 기획의 알맹이는 문서를 쓰는 일이 아니라, 무엇을 만들어야 하고 무엇이 일어나면 안 되는지를 정하는 판단이다. 개발의 알맹이는 코드를 치는 손이 아니라, 그 시스템이 어디서 터질지 아는 감각이다.

찬성 측 첫째 논증("경계는 도구가 만든 칸막이")은 손기술 경계에는 맞지만 판단 경계에는 틀리다. 실제 사용 데이터도 이 구분을 지지한다. Anthropic이 Claude와의 대화 수백만 건을 익명화해 직업 단위로 분석한 [Economic Index](https://www.anthropic.com/news/the-anthropic-economic-index)에서, AI 사용의 57%는 사람의 작업을 거드는 증강이었고 43%가 통째로 맡기는 자동화였다. 그리고 업무의 75% 이상을 AI에 맡기는 직업은 약 4%에 불과했다. 직군이 통째로 대체되는 그림이 아니라, 직군 안의 생산 작업부터 잠식되고 판단 작업이 남는 그림이다.

흥미로운 건 채용 시장의 반응이다. 생산이 자동화되면 디자이너 수요가 줄어야 할 것 같은데, Figma가 채용 책임자들을 조사한 [2026년 리포트](https://www.figma.com/reports/design-hiring-study-2026/)에서는 47%가 디자이너 수요가 늘었다고 답했다(늘었거나 유지라는 답은 82%). 리포트가 인용한 디자인 전문 VC Designer Fund의 추정으로는, 포트폴리오 회사들의 디자인 채용 공고가 2025년 한 해 전년 대비 약 60% 늘었다. 디자인 도구를 파는 회사의 조사라는 점은 감안해야 한다. 다만 주목할 건 수요의 *내용*이다. 채용 담당자의 45% 이상이 시각적 완성도가 아니라 협업, 시스템 사고, 제품 전략 — 전부 판단 쪽 능력 — 을 찾는다고 답했다. 생산이 싸지니, 시장은 판단에 값을 더 쳐주기 시작했다.

### 2. 핸드오프는 비용이자 검증이었다

둘째 논증이 가장 그럴듯한데, 여기에 함정이 있다. 직군 사이의 경계는 마찰이지만 동시에 **상호 검증 지점**이었다. 기획이 넘긴 의도를 디자이너가 받으면서 "이건 사용자가 이해 못 한다"고 걸러내고, 디자이너의 시안을 개발이 받으면서 "이 상태는 구현하면 깨진다"고 걸러낸다. 핸드오프는 단순한 대기 줄이 아니라, 서로 다른 판단이 서로를 점검하는 관문이었다.

한 사람이 의도를 끝까지 가져가면 번역 비용은 사라진다. 그런데 그 검증도 같이 사라진다. 자기가 낸 기획을 자기가 디자인하고 자기가 구현하고 자기가 OK하는 구조는 — 지난 글에서 짚은, AI가 자기 코드에 맞춰 테스트를 쓰고 제 답으로 제 답을 채점하는 순환과 똑같다. 마찰이 사라진 자리에는 속도만 남는 게 아니라, 아무도 반대편에서 점검하지 않는 사각지대도 같이 남는다.

실제 협업 데이터는 경계가 지워지는 게 아니라 더 빽빽해지는 쪽을 가리킨다. Figma의 [디자이너·개발자 조사](https://www.figma.com/reports/designer-developer-trends/)에서 디자이너와 매일 협업한다는 개발자 비율은 2023년 16%에서 2025년 리포트에서는 32%로 두 배가 됐다. 직군이 섞일수록 서로의 판단을 더 자주 빌리게 되는 것이다. 경계를 지우는 게 아니라 경계를 더 자주 건너는 것 — 둘은 다르다.

### 3. 선례들은 책임을 지운 적이 없다

셋째·넷째 논증의 역사는 사실이다. 그런데 그 역사를 자세히 보면 찬성 측 주장과 정반대 방향을 가리킨다. Vogels의 "You build it, you run it"은 개발과 운영의 *경계*를 지운 말이지, *책임*을 지운 말이 아니다. 오히려 정반대다. 같은 인터뷰에서 Vogels는 이렇게 말한다. "개발자에게 운영 책임을 지운 것이 서비스 품질을 크게 끌어올렸다." 통합의 핵심은 만든 사람이 운영까지 _떠안는_ 것이었다. 벽을 허문 게 아니라, 벽 양쪽을 한 사람의 어깨에 올린 것이다.

풀스택도 같다. 프론트와 백을 다 하는 사람은 두 영역의 책임을 다 진다. Linear의 "PM 없음"도 들여다보면 그렇다. 기획 *직함*이 없을 뿐 기획 *판단*은 증발하지 않았다 — 프로젝트마다 리드가 있고, 그 리드가 무엇을 만들지에 대한 판단을 소유한다. 기획 업무는 분산된 게 아니라 판단할 수 있는 사람들에게 재배치된 것이다.

그러니 선례가 증명하는 건 "경계를 지워도 된다"가 아니라 "책임을 한 사람에게 몰아줄 수 있을 때만 경계를 지워도 된다"이다. "경계를 지우자"가 "각 판단을 책임지는 사람을 지우자"로 변질되면 정반대 일이 벌어진다. 누구나 모든 걸 만들지만 아무도 무엇이 맞는지 최종 판정하지 않는 상태. 게이트는 다 통과하는데 게이트 뒤에 응답할 사람이 없는, 책임의 공백이 조직 단위로 생긴다.

### 4. 판단의 도구화는 판단의 소유를 대체하지 않는다

다섯째 논증에 대한 답이다. AI가 판단을 *보조*하는 것과 판단을 *소유*하는 것은 다르다. AI는 접근성 위반 항목을 나열할 수 있다. 그러나 그 목록 중 무엇이 이 제품에서 실제로 중요한지, 무엇을 지금 포기하고 무엇을 막아야 하는지, 그리고 AI의 비평 자체가 맞는지 — 이걸 정하는 건 여전히 사람이다. 검증기를 만들면 검증기를 검증하는 일이 생기듯, 판단을 도구화하면 그 도구의 판단을 수용할지 판정하는 일이 생긴다. 한 칸 물러날 수는 있어도 사라지지는 않는다.

찬성 측이 인용한 배분 경제가 사실 이 점을 인정하고 있다. Shipper의 결론은 "판단이 필요 없어진다"가 아니라 "얼마나 잘 맡기느냐로 평가받는다"이다. 무엇을 맡기고 무엇을 직접 쥘지, 맡긴 결과가 쓸 만한지 — 배분이라는 말 자체가 판단의 다른 이름이다. 모델 매니저가 된다는 건 판단에서 해방되는 게 아니라, 판단만 남기고 나머지를 떼어내는 것이다.

### 5. 뽑을 수 있다는 것을 안다고 착각한다

그래서 진짜 위험은 조직 구조 이전에, 개인이 빠지는 착각이다. 디자이너의 산출물을 뽑을 수 있게 된 것을, 디자이너의 판단을 갖게 된 것으로 착각한다.

기획자가 에이전트로 화면을 만들었다고 디자인 감각이 생긴 게 아니다. 그는 자기가 본 적 없는 엣지 상태가 무너지는 걸 모르고, 접근성이 깨진 줄도 모른 채 "됐다"고 판정한다. Collinsworth가 고백했던 "자기가 올린 PR을 방어할 수 없었다"는 상태가, 직군을 건너 모든 산출물에서 재연되는 것이다. 생성은 공짜로 얻었지만, 안목은 공짜로 따라오지 않는다.

한 문장으로 압축하면 이렇다.

**경계를 넘게 해주는 능력(생산)과, 어느 경계는 넘으면 안 되는지 아는 능력(판단)은 다른 능력이다.**

## 경계는 사라지지 않고 다시 그어진다: 판단의 분업

그럼 반대 측의 승리인가. 그렇게 단순하지 않다. 방향은 찬성이 맞고, 형태는 반대가 맞다. 도구 단위로 그어졌던 경계 — 코드를 치는 사람, 시안을 그리는 사람, 문서를 쓰는 사람 — 는 실제로 무너진다. 그 자리에 판단 단위의 경계가 다시 그어진다. 보안 판단을 책임지는 사람, 사용자 경험 판단을 책임지는 사람, 무엇을 만들지 판단을 책임지는 사람.

왜 판단 단위인가. 문제가 직군의 주소를 따르지 않기 때문이다. 성능 문제가 코드 파일이 아니라 의존성 그래프에 살 듯, 이탈의 원인이 기능이 아니라 카피 한 줄에 있기도 하고, 디자인 문제의 뿌리가 시안이 아니라 데이터 모델에 있기도 하다. 산출물은 직군별로 나오지만 문제는 경계를 무시하고 산다. 문제가 어느 칸에 사는지 주소를 찾는 일 — 그게 깊이가 하는 일이고, 생산을 모두가 하게 된 조직이 분업해야 하는 건 정확히 이 주소 찾기다. 대략 다섯 가지로 정리된다.

**1. 판단의 명문화.** 자기 칸의 판단을 옆 칸 사람이 쓸 수 있는 형태로 바꾸는 일이다. 디자인 원칙, 접근성 체크리스트, "재시도 시 중복 결제가 나면 안 된다"는 목록. 전문가의 눈을 모두에게 줄 수는 없어도, 전문가가 보는 항목은 줄 수 있다.

**2. 호출 규약.** 어디까지는 혼자 가도 되고 어디서부터는 전문가를 불러야 하는지, 트리거를 미리 정한다. 결제 흐름을 바꾸면 부른다, 개인정보 필드를 추가하면 부른다, 같은 식이다.

**3. 선별적 전문가 리뷰.** 모든 산출물에 전문가를 태울 수는 없다. 위험이 큰 소수 — 돈이 흐르는 경로, 첫 사용자 경험, 데이터를 지우는 기능 — 에 전문가의 눈을 배치하고, 나머지는 명문화된 기준과 자동 검사에 맡긴다. 어디가 위험한지 분류하는 일 자체가 그 직군의 판단이다.

**4. 관문의 재설계.** 핸드오프를 없앤 팀일수록, 제 답으로 제 답을 채점하는 순환을 깰 두 번째 눈을 어디에 둘지 따로 정해야 한다. 자연히 생기던 관문이 사라졌으니 이제는 만들어야 생긴다. 아래 Vercel의 사례가 한 형태다 — 핸드오프는 없지만, 두 판단이 같은 산출물 위에서 만난다.

**5. 경계 직군.** 그리고 경계 자체가 직무가 된다. 두 칸의 판단을 모두 깊게 가진 사람 — 시장은 이미 여기에 이름을 붙이기 시작했다.

### 시장은 이미 다시 긋고 있다

디자인 엔지니어(design engineer)가 그 이름이다. Vercel은 [2024년 글](https://vercel.com/blog/design-engineering-at-vercel)에서 이 역할을 "미적 감각과 기술력을 함께 갖춰, 문제를 깊게 이해한 뒤 혼자서 디자인하고 만들고 배포까지 하는 사람"으로 정의했다. 주목할 건 그 다음 문장이다. "완성된 디자인을 넘기는(hand off) 대신, 디자이너가 시작점을 스케치하면 디자인 엔지니어가 피그마나 코드 위에서 함께 다듬어 최종 디자인을 만든다." 직군 구분이 없어진 게 아니다. 핸드오프가 사라진 자리에, 두 판단을 한 몸에 가진 새 직군이 생긴 것이다. 경계가 지워진 게 아니라 더 비싼 경계로 다시 그어졌다. 이 역할은 디자인 판단과 엔지니어링 판단을 _둘 다_ 요구하니까.

반대쪽 끝의 사례도 있다. 2025년 3월, 영업 리드 데이터를 다듬어주는 SaaS인 EnrichLead를 만든 자칭 비개발자 창업자가 "내 SaaS는 전부 Cursor로 만들었다, 손으로 쓴 코드는 0줄"이라며 "AI는 더 이상 조수가 아니라 빌더"라고 X에 자랑했다. [이틀 뒤 그의 트윗](https://pivot-to-ai.com/2025/03/18/guys-im-under-attack-ai-vibe-coding-in-the-wild/)은 이렇게 시작한다. "여러분, 저 공격받고 있어요." API 키 사용량이 한도까지 치솟고, 결제를 우회하는 사람들이 생기고, DB에는 아무 데이터나 꽂히고 있었다. API 키는 코드 안에 박혀 있었고 결제벽은 클라이언트에서 우회 가능했다 — 보안 판단이 있는 사람이라면 출시 전에 잡았을 것들이다. 그는 결국 서비스를 내리며 이렇게 썼다. "여러분 말이 맞았어요. 보안이 안 된 코드를 프로덕션에 올리는 게 아니었어요."

이 사건에서 곱씹을 건 조롱거리가 된 결말이 아니라 중간이다. 그는 경고를 못 받은 게 아니다. 자랑 글에 보안 경고 댓글이 줄줄이 달렸고, 그는 그걸 흘려보냈다. 판단이 없으면 경고도 소음이다. 무엇이 심각한 지적이고 무엇이 트집인지 가려낼 눈이 없으면, 정보가 도착해도 받을 수가 없다.

여기서 예상되는 반박이 있다. "모델이 더 좋아지면 보안도 AI가 챙겨줄 것 아닌가." 부분적으로 맞는 말이다. 반년 뒤의 모델은 API 키를 코드에 박지 말라고 더 강하게 경고할 것이고, 결제벽의 구멍도 더 잘 찾아낼 것이다. 그런데 이 반박은 경고의 *생산*과 경고의 *수용*을 섞고 있다. EnrichLead의 창업자에게 부족했던 건 경고가 아니다 — 사람들이 이미 줬다. 부족했던 건 그 경고를 수용할지, 무시할지, 얼마나 심각하게 받을지 판정하는 능력이었다. AI의 경고가 늘어날수록 이 판정의 부담은 오히려 커진다. 전부 따르면 아무것도 출시하지 못하고, 전부 무시하면 EnrichLead가 된다. 지난 글에서 종료와 수용의 문제라고 불렀던 그 자리가, 직군의 영역에서 그대로 다시 열리는 것이다.

시장의 대답은 두 방향에서 같다. 두 칸의 판단이 깊은 사람에게는 새 직군의 이름과 더 높은 값이 붙고, 판단 없는 생산은 며칠 만에 뚫린다. 경계는 지워지는 게 아니라, 도구 단위에서 판단 단위로 옮겨 그어지고 있다.

덧붙이면, 경계는 조직 안에서 지워져도 시장에서 다시 나타난다. 직군 없는 1인 회사도 판단까지 혼자 하지는 못한다. 법무 검토를 사고, 회계를 맡기고, 보안 감사를 의뢰한다. 사내에 두던 판단을 시장에서 구매하는 것뿐이다. 올트먼의 1인 유니콘이 정말 나온다 해도, 그 회사는 모든 판단을 혼자 하는 회사가 아니라 어떤 판단을 사야 하는지 아는 회사일 것이다. 그리고 무엇을 사야 하는지 아는 것 역시, 판단이다.

## 무엇을 목표로 해야 하나

그럼 일하는 사람은 어느 쪽에 서야 하나. 모든 걸 얕게 하는 평평한 제너럴리스트는 답이 아니라고 본다. 판단은 손기술처럼 빌려올 수 없기 때문이다. 디자인 판단은 사용자 앞에서 시안이 깨지는 걸 직접 겪어본 사람에게만 생기고, 장애가 어디서 터질지 아는 감각은 장애를 직접 추적해본 사람에게만 생긴다. 현실적인 도착지는 T자형이다. 깊은 한 칸 — 판단까지 책임질 수 있는 영역 — 을 세로획으로 갖고, 그 위에서 AI로 옆 칸들을 얕게 가로지르는 사람.

이 말의 기원은 생각보다 오래됐다. [1991년 영국 The Independent의 컴퓨팅 기사](https://wow.agiledata.io/wp-content/uploads/2022/10/David-Guest-1991-The-hunt-is-on-for-the-Renaissance-Man-of-computing.pdf)가 "컴퓨팅의 르네상스형 인간"을 찾는다며 정보 시스템과 경영을 함께 다루는 'T자형 인간(T-shaped People)'을 말했다. 35년 전 컴퓨팅 업계가 찾던 그 모양이, 생산이 공짜가 된 시대에 와서 오히려 더 정확해진 것이다.

세로획에는 가로획이 갖지 못한 성질이 하나 있다. 도구가 바뀌어도 살아남는다는 것이다. 가로획은 도구에 붙어 있다. 에이전트 사용법, 프롬프트 요령, 이번 분기의 워크플로우 — 도구가 바뀌면 같이 리셋된다. 세로획은 도구 위에 있지 않다. 사용자가 어디서 헤매는지 아는 눈, 시스템이 어디서 터지는지 아는 감각은, 피그마에서 코드로, 코드에서 에이전트로 도구가 갈아엎어져도 그대로 이식된다. 시간이 깎아 먹는 자산과 시간이 불려 주는 자산의 차이고, 깊이에 투자할 이유가 하나 더 늘어나는 지점이다.

문제는 T자가 저절로 자라지 않는다는 것이다. 가로획은 쉽다. AI가 매일 넓혀주고, 즉각 보상이 온다. 세로획은 느리다. 직접 부딪힌 시간만큼만 자란다. 그래서 가만히 두면 모두가 세로획 없는, 얕고 넓기만 한 일자형이 된다. 산출물은 다 뽑는데 무엇이 맞는지는 아무도 모르는 팀. 목표를 한 문장으로 준다면 이것이다.

**옆 칸은 AI로 얕게 넘나들되, 자기 한 칸은 판단까지 책임질 수 있을 만큼 깊게 파라.**

행동 규칙으로 분해하면 이렇다.

**1. 설명할 수 없는 산출물을 자기 이름으로 내보내지 않는다.** 지난 글에서 주니어에게 준 규칙과 같은 규칙이다. 코드에서 모든 산출물로 확장될 뿐이다. 화면을 내보내려면 "왜 이 흐름이고, 어떤 사용자가 어디서 걸려 넘어질 수 있는지"를 설명할 수 있어야 한다. 설명할 수 없다면 그건 내 산출물이 아니라, AI의 산출물에 내 이름을 빌려준 것이다.

**2. 옆 칸은 호출 기준과 함께 넘는다.** 옆 칸을 넘보는 것 자체는 좋은 일이고, 막을 수도 없다. 위험한 건 넘는 게 아니라 자기 깊이의 끝이 어딘지 모른 채 넘는 것이다. "여기서부터는 전문가를 부른다"는 자기 목록을 만들고 넘어라. 부르는 게 부끄러운 일이 아니라, 그 목록을 가졌다는 것 자체가 실력이다. EnrichLead의 창업자에게 없었던 게 정확히 이 목록이다.

**3. 깊은 칸은 판단이 쌓이는 곳에서 판다.** 산출물을 더 많이 만드는 건 이제 깊이가 아니다. 생산이 공짜인 시대에 깊이는 판단이 쌓이는 곳 — 리뷰, 장애 대응, 사용자 테스트, 운영 — 에서만 자란다. 가로획 훈련은 일이 알아서 시켜주니, 따로 설계해야 하는 건 세로획 훈련이다.

**4. 경계를 지웠으면 검증을 다시 설계한다.** 이건 조직의 몫이다. 한 사람이 끝까지 가는 팀이라면 내보내기 전에 다른 직군의 눈이 들어오는 지점을 프로세스로 박고, 호출 규약을 개인의 양심이 아니라 팀의 합의로 만든다. 속도는 쉽게 측정되고 사라진 검증은 측정되지 않으니, 가만히 두면 조직은 늘 검증을 지우는 쪽으로 굴러간다.

이제 막 시작하는 사람에게는 질문이 하나 더 남는다. 첫 칸을 어디에 파야 하나. 직군 경계가 흔들리는 시대에 어느 직군으로 출발하느냐는 질문은 그럴듯하지만, 답은 직군에 있지 않다. 판단이 가장 빨리 쌓이는 곳 — 즉 실패가 자주, 그리고 빨리 보이는 곳에 있다. 운영까지 직접 책임지는 작은 제품, 리뷰가 깐깐한 팀, 사용자 반응이 바로 꽂히는 자리. 어느 직군이냐보다 피드백 루프가 짧으냐가 중요하다. 세로획은 결국 내 판단이 틀렸음을 확인당한 횟수만큼 자라기 때문이다.

마지막으로 경고할 함정이 하나 있다. 단기적으로는 시장이 일자형을 보상한다는 것이다. 에이전트로 프로토타입을 쏟아내면 생산적으로 보이고, 직군을 넘나들면 현대적으로 보인다. 하지만 판단 없는 넓이는 첫 대형 사고에서 정체가 드러나고, 그때는 이미 몇 년이 지나 있다. EnrichLead의 창업자도 공격당하기 전까지는 누구보다 생산적으로 _보였다_.

## 마치며

처음 질문에 답하자. 누구나 무엇이든 만들 수 있게 됐다면, 기획·개발·디자인의 경계는 지워도 되는 걸까.

정직하게 양보부터 하면, 지워도 되는 영역이 실존한다. 작고, 초기 단계이고, 실패의 비용이 자기 안에 갇히는 일. 1인 창업의 첫 실험, 프로토타입, 내부 도구. 여기서 직군을 따지는 건 낡은 관료주의이고, 이 영역은 좁지 않으며 커지고 있다. 올트먼의 1인 유니콘도 결국 이 영역이 어디까지 커질 수 있는지에 대한 내기다.

하지만 경계가 있다. 결제가 붙는 순간, 남의 데이터를 받는 순간, 실패가 사용자에게 가닿는 순간 — 그 일은 영역 밖으로 나간다. EnrichLead의 창업자가 틀린 지점도 코드가 아니라 여기였다. 그는 자기가 아직 안전한 영역 안에 있다고 판단했고, 결제를 받기 시작한 순간 이미 밖이었다. 그리고 그 안팎을 가르는 것이, 또 판단이다.

그 바깥의 세계에서는 답이 갈린다. 산출물을 누가 만들 수 있느냐의 경계는 무너진다. 무너져야 한다. 만들 줄 모른다는 이유로 사람을 가르던 선은 사라지는 게 맞다. 하지만 무엇이 맞는지 누가 판단하고 책임지느냐의 경계는 남는다. 생산이 싸질수록 더 비싸진다. 지난 글이 "이해가 필요 없는 코드는 실존하지만, 그 경계선은 이해할 줄 아는 사람만 그을 수 있다"로 끝났는데, 같은 구조의 문장이 직군에서도 성립한다.

**무너져도 되는 경계인지 지켜야 할 경계인지, 그 선을 가르는 일은 깊이를 가진 사람만 할 수 있다.**

옆 칸은 얕게 넘나들어도 된다. 단, 자기 한 칸은 깊어야 한다.

## 참고 자료

- [코드를 읽거나 설명할 줄 몰라도, 스펙을 만족하고 버그를 고칠 수 있다면 상관없을까](https://yceffort.kr/2026/06/do-you-need-to-read-code) - 이 글의 1탄
- [Nvidia CEO: 'Everyone is a programmer' with A.I.](https://fortune.com/2023/05/30/nvidia-ceo-jensen-huang-everyone-programmer-with-ai-chipmaker-taipei-computex/) - Fortune
- [Sam Altman wants AI to create a one-person unicorn](https://fortune.com/2024/02/04/sam-altman-one-person-unicorn-silicon-valley-founder-myth/) - Fortune
- [The Knowledge Economy Is Over. Welcome to the Allocation Economy](https://every.to/chain-of-thought/the-knowledge-economy-is-over-welcome-to-the-allocation-economy) - Dan Shipper
- [Product Management Is Dead](https://www.chatprd.ai/blog/product-management-is-dead) - Claire Vo
- [A Conversation with Werner Vogels](https://queue.acm.org/detail.cfm?id=1142065) - ACM Queue (2006)
- [How Linear builds product](https://www.lennysnewsletter.com/p/how-linear-builds-product) - Lenny's Newsletter
- [Design Engineering at Vercel](https://vercel.com/blog/design-engineering-at-vercel) - Vercel
- [Are Roles and Responsibilities a Thing of the Past?](https://www.figma.com/blog/2025-shifting-roles-report/) - Figma (2025)
- [Why Demand for Designers Is on the Rise](https://www.figma.com/reports/design-hiring-study-2026/) - Figma (2026)
- [Designer and Developer Trends Report](https://www.figma.com/reports/designer-developer-trends/) - Figma (2025)
- [The Anthropic Economic Index](https://www.anthropic.com/news/the-anthropic-economic-index) - Anthropic
- ['Guys, I'm under attack' — AI vibe coding in the wild](https://pivot-to-ai.com/2025/03/18/guys-im-under-attack-ai-vibe-coding-in-the-wild/) - Pivot to AI
- [The hunt is on for the Renaissance Man of computing](https://wow.agiledata.io/wp-content/uploads/2022/10/David-Guest-1991-The-hunt-is-on-for-the-Renaissance-Man-of-computing.pdf) - David Guest, The Independent (1991)