Taste, Productization,
and Shipping

요즘 자꾸 이런 생각을 한다. 의도와 구현이 중요한 시대다.

그런데 이 문장을 그대로 쓰고 나면 어딘가 부족하다.

여기서 말하는 의도를 intention이라고 번역하면 너무 무미건조하다. 내가 말하고 싶은 것은 “나는 이것을 하고 싶다”는 수준의 의도가 아니다. 오히려 taste에 가깝다.

무엇이 중요한 문제인지, 무엇이 좋은 결과인지, 무엇을 만들 가치가 있는지, 무엇은 과감하게 버려야 하는지를 판단하는 감각이다. 제품의 관점에서 말하면 product sense라고 불러도 좋을 것이다.

구현도 마찬가지다. 내가 말하는 구현은 단순한 implementation이 아니다. AI가 implementation의 비용을 빠르게 낮추고 있기 때문이다.

코드를 작성하는 비용도 내려가고, 디자인을 만드는 비용도 내려가고, 서버를 띄우고 데이터를 처리하고 문서를 작성하는 비용도 내려가고 있다. 예전에는 “이걸 실제로 구현했다”는 것만으로도 상당한 능력을 증명할 수 있었다. 앞으로는 점점 그렇지 않을 가능성이 높다.

그래서 구현 이후가 중요해진다. 프로토타입이 아니라 다른 사람에게 건넬 수 있는 수준으로 만드는 것. 기능이 돌아가는 데서 멈추지 않고 품질, 사용성, 안정성, 문서화, 재현성까지 고민하는 것. 나는 이것을 productization이라고 부르고 싶다.

그리고 한 단계가 더 있다.

아무리 잘 만들었어도 실제로 내놓지 않으면 세상과 만나지 못한다. 논문이라면 제출해야 한다. 코드라면 공개해야 한다. 서비스라면 사용자가 써보게 해야 한다. 데이터셋이라면 사람들이 다운로드해서 깨뜨려보게 해야 한다.

즉 마지막에는 shipping이 있어야 한다.

Implementation이 쉬워지면 무엇이 어려워지는가

AI가 코드를 잘 작성하기 시작하면서 종종 이런 이야기를 듣는다.

이제 코딩 능력이 별로 중요하지 않은 것 아닌가?

나는 그렇게 생각하지 않는다.

다만 정확히 말하면, implementation 그 자체의 희소성이 낮아지고 있다.

예전에는 아이디어와 구현 사이에 커다란 장벽이 있었다. 웹서비스 하나를 만들려고 해도 프론트엔드, 백엔드, 데이터베이스, 서버 배포를 알아야 했다.

로봇 시스템 하나를 만들려면 더 많은 것이 필요했다. 센서를 연결하고, 드라이버를 설치하고, ROS node를 붙이고, perception과 planning을 연결하고, 좌표계를 맞추고, 빌드 에러를 잡고, 실제 하드웨어에서 반복적으로 디버깅해야 했다.

그래서 과거에는 “내가 이것을 만들 수 있다”라는 사실 자체가 꽤 큰 경쟁력이었다.

그런데 AI가 이 구간을 빠르게 압축하고 있다. 학부생도 며칠 만에 예전에는 몇 주가 걸렸을 prototype을 만들 수 있다. 프로그래밍 경험이 많지 않은 사람도 작은 서비스를 만들 수 있다. 논문 아이디어를 코드로 옮기고, figure를 만들고, demo page를 만드는 비용도 눈에 띄게 내려가고 있다.

그러면 경쟁력은 자연스럽게 다른 곳으로 이동한다.

무엇을 만들 것인가.
어디까지 만들 것인가.
그리고 실제로 세상에 내놓을 것인가.

Taste는 Intention보다 깊다

Intention은 한 시점에서 선언할 수 있다.

좋은 로봇을 만들고 싶다.
사람에게 도움이 되는 AI를 만들고 싶다.
좋은 연구를 하고 싶다.
좋은 서비스를 만들고 싶다.

이런 intention은 중요하다. 하지만 같은 intention을 가진 두 사람이 완전히 다른 결과물을 만들기도 한다.

둘 다 “좋은 연구”를 하고 싶어 하지만 무엇을 좋은 research question이라고 생각하는지는 다르다. 둘 다 “사용자를 위한 제품”을 만들고 싶어 하지만 어떤 불편을 심각하게 받아들이는지는 다르다. 둘 다 “고품질 시스템”을 만들고 싶어 하지만 어디까지 고쳐야 충분하다고 판단하는지는 다르다.

이 차이가 taste다.

Taste는 단순한 선호가 아니다. 내가 말하는 taste는 일종의 internal evaluation function에 가깝다.

제품 영역에서는 이것을 product sense라고 표현해도 좋다. Product sense에는 조금 더 명시적으로 상대방이 등장한다.

• 누가 이것을 쓰는가.
• 그 사람은 무엇을 불편해하는가.
• 우리가 중요하다고 생각하는 기능과 사용자가 중요하다고 느끼는 기능이 같은가.
• 어떤 friction이 실제 adoption을 막는가.

좋은 product sense는 단순히 “좋은 아이디어를 많이 내는 능력”이 아니다. 문제의 중요도와 사용자의 현실을 제대로 읽는 능력이다.

Implementation과 Productization은 다르다

Implementation의 종료 조건은 비교적 명확하다.

된다.

코드가 실행된다. 로봇이 움직인다. 모델이 학습된다. 웹페이지가 열린다.

Productization의 시작은 오히려 그 이후다.

다른 사람도 쓸 수 있는가?

이 질문을 시작하면 갑자기 해야 할 일이 많아진다.

• 처음 보는 사람이 사용할 수 있는가?
• 설치가 가능한가?
• Error message가 이해 가능한가?
• Edge case에서 무너지지 않는가?
• Failure mode를 예상했는가?
• 문서가 있는가?
• 결과가 재현되는가?
• 사용자가 무엇을 헷갈릴지 생각했는가?
• 불필요한 기능은 제거했는가?
• 가장 중요한 interaction은 충분히 매끄러운가?

그래서 productization은 단순히 engineering quality의 문제가 아니다. 사용자에 대한 공감이 들어간다.

내가 무엇을 구현할 수 있는지를 보여주는 것이 implementation이라면, productization은 내가 상대방의 경험을 얼마나 오래 생각했는가를 보여주는 과정에 더 가깝다.

좋은 product를 보면 만든 사람이 사용자를 얼마나 많이 상상하고 관찰했는지가 느껴진다.

연구에서도 마찬가지다. 좋은 논문은 단지 method가 동작하는 논문이 아니다. Reader가 어디에서 이해를 놓칠지, reviewer가 어떤 질문을 던질지, 후속 연구자가 어떤 코드를 필요로 할지, benchmark가 어떤 식으로 오용될 수 있을지까지 고민한 흔적이 있다.

Productization은 empathy made concrete라고 생각할 수도 있다. 공감이 실제 artifact의 형태로 물질화된 것이다.

Product란 반드시 상업적인 제품을 뜻하지 않는다

여기서 product라고 하면 꼭 startup이나 앱을 생각할 필요는 없다.

연구자에게도 product는 많다. 논문 하나도 product다. 데이터셋도 product다. Benchmark도 product다. 오픈소스 repository도 product다. 강의자료도 product일 수 있다. 학생에게는 잘 만든 프로젝트 하나가 product가 될 수도 있다.

핵심은 돈을 받느냐가 아니다.

다른 누군가가 실제로 사용할 것을 전제로 만들어졌느냐.

자기 컴퓨터에서만 돌아가는 코드는 project일 수 있다. 다른 사람이 clone해서 실제로 사용할 수 있는 순간 product에 가까워진다.

자기 머릿속에서는 명확한 연구 아이디어는 아직 project다. 독자가 읽고, 재현하고, 후속 연구를 시작할 수 있는 형태까지 가면 product에 가까워진다.

마지막 5%는 5%가 아니다

Productization이 어려운 가장 큰 이유 중 하나는 마지막 몇 퍼센트의 비용이 비선형적으로 커지기 때문이다.

90% 품질을 만드는 데 1의 노력이 들었다고 하자. 90%에서 95%로 가는 데 다시 1이 필요한 것이 아니라 10이 필요할 수도 있다. 95%에서 99%로 가는 데 다시 몇 배의 시간이 들 수 있다. 99%에서 99.9%로 가려면 아예 다른 수준의 skill과 discipline이 필요할 수도 있다.

연구도 그렇다. 아이디어를 떠올리는 데는 하루가 걸렸는데 figure를 제대로 만드는 데 일주일이 걸릴 수 있다. 핵심 algorithm은 일주일 만에 만들었는데 evaluation protocol을 제대로 정리하는 데 한 달이 걸릴 수 있다. Prototype은 이틀 만에 만들었는데 누구나 사용할 수 있는 software로 만드는 데 몇 달이 걸릴 수도 있다.

누구나 시작할 수 있게 되는 것은 맞다.
하지만 누구나 끝낼 수 있게 되는 것은 아니다.

오히려 시작 비용이 내려갈수록 finish quality의 차이는 더 크게 보일 가능성이 있다.

그러나 Productization만으로는 부족하다

여기에는 한 가지 함정이 있다. Productization을 지나치게 강조하면 끝없는 perfectionism으로 갈 수 있다.

아직 부족하다. 조금 더 고쳐야 한다. 한 기능만 더 넣자. UI를 조금 더 다듬자. 실험을 하나만 더 하자.

이렇게 계속하다 보면 영원히 세상에 나오지 않을 수도 있다.

그래서 productization 뒤에는 반드시 shipping이 있어야 한다.

Shipping은 단순히 “출시 버튼을 누르는 것”이 아니다. 실제 세상과 접촉하는 것이다. 내가 만든 것에 외부의 평가 함수가 들어오기 시작하는 순간이다.

사용자가 써본다. Reviewer가 읽는다. 사람들이 코드를 실행한다. 예상하지 못한 방식으로 사용한다. 불평한다. 칭찬한다. 무시하기도 한다.

그리고 내가 중요하다고 생각했던 것과 세상이 중요하게 생각한 것이 얼마나 다른지 알게 된다.

Productization without shipping is still a private project.

완성도는 중요하다. 하지만 실제로 ship하지 않는다면 우리는 자기 내부의 evaluation function만 가지고 계속 학습하게 된다. 외부 reward가 없다.

Shipping은 Reality Check다

연구에서도 shipping은 중요하다. 아이디어를 생각했다. 코드를 구현했다. 실험을 했다. 논문을 다듬었다. 여기까지는 모두 내부 과정이다.

Submit하는 순간 외부 세계가 개입한다.

Reviewer는 우리가 중요하다고 생각한 contribution을 중요하지 않다고 볼 수도 있다. 우리가 사소하다고 생각한 weakness를 치명적이라고 볼 수도 있다. 코드를 공개하면 예상하지 못했던 installation issue가 발견된다. 데이터를 공개하면 사람들이 전혀 다른 방식으로 사용한다.

이 경험이 다시 taste를 만든다.

Shipping은 단순한 endpoint가 아니다. 다음 taste를 학습하기 위한 새로운 observation을 얻는 과정이다.

“프로도 아닌데 어떻게 Product를 만들어요?”

학생들에게 이런 이야기를 하면 자연스럽게 이런 생각이 생길 수 있다.

나는 아직 학생인데.
아직 전문가는 아닌데.
Product급 결과물을 만드는 건 몇 년 일한 사람이 하는 것 아닌가?
Taste도 결국 경험 많은 사람에게 생기는 것 아닌가?

나는 이런 생각 자체가 어느 정도는 비AI 시대에 교육받은 사람이 가진 고정관념이라고 생각한다.

과거에는 실제로 어느 정도 맞았다. 제품급 software를 만들려면 많은 기술을 알아야 했다. 데이터를 분석하려면 직접 programming과 statistics를 익혀야 했다. 좋은 presentation을 만들려면 디자인 skill도 필요했다.

그리고 각 단계에서 할 수 있는 일의 범위도 상당히 달랐다.

하지만 AI가 이 경계를 빠르게 낮추고 있다.

여기서 중요한 것은 AI가 학생을 자동으로 전문가로 만들어준다는 뜻이 아니다.

오히려 중요한 변화는 과거에는 몇 년 뒤에야 시도할 수 있었던 문제를 지금 당장 시도할 수 있게 되었다는 것이다.

따라서 지금 학생에게 가장 위험한 문장 중 하나는 어쩌면 이것일 수도 있다.

나는 아직 학생이니까 여기까지만 하면 된다.

AI 시대에는 이 문장의 유효기간이 빠르게 짧아질 것이다.

AI Transition 세대와 AI Native 세대

지금의 20대와 30대 초반 일부는 독특한 세대라고 생각한다. 이들은 AI transition 세대다.

교육은 대부분 AI 이전의 방식으로 받았다. 검색하고, 외우고, 코드를 직접 작성하고, 한 분야의 skill을 오랫동안 익혀야 했다. 그런데 막 사회에 진입하려고 하거나 커리어를 구축하는 순간 작업 환경 자체가 바뀌었다.

반면 앞으로 대학에 들어오는 학생들은 다르다. 이들은 처음부터 AI와 함께 문제를 해결한다. 코드를 짤 때도 AI가 있다. 글을 쓸 때도 AI가 있다. 디자인할 때도 AI가 있다. 아이디어를 탐색할 때도 AI가 있다. 데이터를 분석할 때도 AI가 있다.

이들은 점점 AI native 세대가 될 것이다.

그래서 transition 세대에게 앞으로 몇 년은 꽤 중요하다고 생각한다.

이미 AI 이전 시대에 확실한 전문성을 구축한 사람은 조금 다르다. 오랫동안 한 분야를 연구한 사람, 전문 자격을 가진 사람, 박사학위 이후 오랜 기간 하나의 문제를 파고든 사람은 AI를 기존 expertise의 multiplier로 사용할 수 있다.

하지만 아직 expertise를 완전히 구축하지 못한 transition 세대는 전략이 달라야 할 수 있다.

일단 천천히 skill을 익히고, 몇 년 뒤에 제대로 된 것을 만들어보자.

라는 전략만으로는 부족할 수도 있다. 몇 년 뒤에는 AI native 세대가 같은 무대에 들어오기 때문이다.

그래서 이 세대에게 필요한 것은 단순히 AI tool을 능숙하게 쓰는 것이 아니다.

Intention을 taste로 발전시키고,
implementation을 productization으로 발전시키고,
실제로 ship하는 경험을 여러 번 해보는 몇 년.

나는 그 밀도가 꽤 중요해질 것이라고 생각한다.

리크루팅에서는 무엇을 봐야 할까

이 생각은 자연스럽게 사람을 뽑을 때 무엇을 봐야 하는가라는 질문으로 이어진다.

앞으로 나는 후보자에게서 두 가지를 특히 보고 싶다.

첫째는 taste와 product sense다.

둘째는 product/project manager로서의 자질이다.

물론 기술 능력도 중요하다. Programming, mathematics, robotics, ML fundamentals 모두 중요하다. 하지만 AI가 skill acquisition의 일부를 빠르게 보조하는 시대에는 어떤 문제를 선택하는가, 어떻게 문제를 구조화하는가, 어느 수준까지 완성하는가, 사람과 resource를 어떻게 조직하는가가 더 중요해질 가능성이 있다.

그런데 이 능력들은 질문 하나로 직접 측정하기 어렵다.

당신은 taste가 있습니까?
당신은 project management를 잘합니까?

라고 물어도 의미 있는 답을 얻기 어렵다.

그래서 나는 오히려 이런 질문이 좋다고 생각한다.

지금까지 가장 재미있었던, 힘들었던, 뜻깊었던, 많이 성장했던, 의미 있었던, 혹은 그냥 내게 들려주고 싶은 인상 깊은 에피소드 하나를 이야기해주세요.

특별히 거창할 필요도 없다. 대회 우승이어도 되고, 팀 프로젝트 실패여도 되고, 동아리에서 있었던 일이거나, 알바에서 겪은 문제일 수도 있다.

나는 결과보다 그 episode의 구조를 보고 싶다.

Episode란 무엇인가

강화학습의 언어를 빌려오면 episode를 조금 더 흥미롭게 볼 수 있다.

한 시점에는 상태 s가 있다. 그 상태에서 행동 a를 취한다. 그 결과 reward r를 얻는다. 그리고 이것이 반복되다가 어떤 termination event에서 하나의 episode가 끝난다.

따라서 나는 하나의 episode를 이야기할 때 최소한 네 가지를 듣고 싶다.

1. 어떤 State였는가?

무슨 일이 있었는가. 그런데 단순히 배경을 설명하는 것만으로는 충분하지 않다. 내가 궁금한 것은 그 사람에게 특별했던 state가 무엇이었는가이다.

무엇이 어려웠는가? 어떤 제약이 있었는가? 다른 사람은 보지 못했던 문제를 본 것이 있는가? 그 순간 가장 중요한 bottleneck을 무엇이라고 판단했는가?

같은 상황을 봐도 사람마다 state representation이 다르다.

누군가는 “시간이 부족했다”고 말한다.
다른 사람은 “시간 부족이 문제가 아니라, 팀이 무엇을 완료라고 정의하는지 합의가 없었다”고 말할 수도 있다.

State를 어떻게 표현하는가 자체가 이미 그 사람의 problem framing 능력을 드러낸다.

2. 어떤 Action을 취했는가?

여기가 가장 중요하다.

그 상황에서 무엇을 했는가. 그리고 더 중요한 질문은 왜 그 행동을 선택했는가?이다.

다른 alternative는 무엇이었는가? 왜 그것을 버렸는가? 어떤 정보를 근거로 판단했는가? 무엇을 감수했는가? 무엇을 우선순위에서 내렸는가? 누구를 설득해야 했는가? 잘못된 판단임을 언제 깨달았는가? 판단을 바꾸었는가?

이 부분에서 기술력도 드러나지만, 그보다 더 중요한 것이 나온다. 그 사람의 evaluation function이다.

무엇을 중요하다고 보았는가. 어떤 risk는 받아들이고 어떤 risk는 받아들이지 않았는가. 언제 충분하다고 판단했는가. 이런 선택들이 taste를 보여준다.

3. 어떤 Reward를 얻었는가?

여기서 reward는 꼭 수상이나 성공을 의미하지 않는다.

오히려 중요한 것은 그 행동을 취하고 무엇을 새롭게 알게 되었는가다.

처음 예상과 무엇이 달랐는가? 어떤 판단 기준이 바뀌었는가? 같은 상황이 다시 온다면 무엇을 다르게 할 것인가? 그 경험 이후 자신의 방식 중 무엇을 유지했고, 무엇을 버렸는가?

이것이 episode에서 얻은 learning signal이다.

4. 무엇으로 Terminate되었는가?

마지막으로 termination event가 있다.

그래서 결국 어떻게 되었는가. 프로젝트가 성공했는가. 실패했는가. 출시했는가. 논문을 냈는가. 팀을 정리했는가. 중간에 과감하게 중단했는가.

결과는 분명 중요하다. 다만 결과만 보면 안 된다.

좋은 결과가 잘못된 decision process에서 나올 수도 있다. 반대로 나쁜 결과가 매우 좋은 판단에서 나올 수도 있다.

그래서 나는 outcome보다는 outcome까지의 trajectory를 보고 싶다.

Resume의 점과 Trajectory의 차이

우리는 사람을 평가할 때 흔히 점을 본다.

학교. 학점. 시험 점수. 논문 수. 수상 경력. 인턴십. 자격증.

이런 것들은 유용하다. 하지만 대부분은 긴 trajectory를 몇 개의 scalar로 projection한 것이다. 따라서 많은 정보가 사라진다.

예를 들어 두 사람이 같은 conference에 first-author paper를 한 편 냈다고 하자.

First-author paper, 2026.

CV에는 똑같이 이렇게 적힌다.

하지만 실제 trajectory는 완전히 다를 수 있다.

한 사람은 이미 잘 정의된 문제를 받아서 충실하게 수행했을 수도 있다.

다른 사람은 문제를 처음부터 정의했고, 필요한 데이터를 직접 수집했고, 초기 접근법이 틀렸다는 것을 발견하고 방향을 바꾸었고, 팀원을 설득했고, 실험 프로토콜을 다시 만들었고, 마지막에는 code와 dataset까지 공개했을 수도 있다.

같은 한 줄의 CV지만 두 사람이 살아온 episode는 다르다. 그리고 그 차이는 다음 프로젝트에서 나타날 가능성이 크다.

Taste는 현재 능력치가 아니라 Trajectory에서 나온다

나는 taste를 한 시점의 능력치로 평가하기 어렵다고 생각한다.

수능 만점처럼 표현하기 어렵다. 코딩 테스트 점수처럼 한 시간 만에 측정하기도 어렵다.

왜냐하면 taste는 한 점에서 만들어지지 않기 때문이다.

Taste는 trajectory에서 나온다.

그 사람이 어떤 문제를 선택해왔는지, 무엇에 시간을 써왔는지, 어떤 실패를 겪었는지, 무엇을 보고 감탄했는지, 무엇을 보고 불편함을 느꼈는지, 어떤 것을 끝까지 고쳤는지, 어떤 것은 일찍 포기했는지가 누적된다.

이것들이 반복되면서 내부 evaluation function이 만들어진다.

그래서 누군가의 taste를 알고 싶다면 “무엇을 좋아합니까?”라고 묻기보다는 “지금까지 어떤 episode들을 살아왔습니까?”라고 묻는 편이 더 좋을지도 모른다.

좋은 모델은 좋은 Rollout을 필요로 한다

여기까지 생각하다 보면 사람의 성장도 조금 다르게 보인다.

Machine learning에서 좋은 model을 얻으려면 좋은 data가 필요하다. Reinforcement learning에서는 특히 rollout의 다양성이 중요하다.

항상 같은 initial state에서 항상 같은 policy로 항상 비슷한 reward만 얻은 agent는 새로운 환경에서 쉽게 무너질 수 있다.

사람도 비슷하지 않을까.

그 사람이 어떤 rollout들을 경험했는가.

나는 이것이 앞으로 점점 중요해질 것이라고 생각한다.

물론 단순히 “경험이 많다”는 뜻은 아니다. 같은 distribution의 경험을 반복하는 것은 diversity가 낮은 rollout일 수 있다.

예를 들어 TOEIC 700점에서 900점으로 올라가기 위해 몇 달 동안 비슷한 문제를 더 많이 푸는 것은 분명 의미 있는 훈련이다. Skill은 좋아질 수 있다. 하지만 이것만으로 taste가 크게 확장되었다고 말하기는 어렵다.

내가 말하는 rollout은 조금 다른 것이다.

• 처음 해보는 프로젝트의 책임자가 되어보는 것.
• 사용자가 있는 software를 실제로 배포해보는 것.
• 데이터를 직접 수집해보는 것.
• 동료를 설득해서 작은 팀을 만들어보는 것.
• 자신이 정의한 문제로 연구를 시작해보는 것.
• 실패한 프로젝트를 직접 종료해보는 것.
• 예산을 써보는 것.
• Deadline을 책임져보는 것.
• 내가 만든 것을 전혀 모르는 사람에게 건네줘 보는 것.
• 좋다고 생각한 것을 세상에 ship했는데 아무도 관심을 갖지 않는 경험을 해보는 것.

이런 경험들은 서로 다른 state distribution을 만든다.

그리고 다양한 state를 경험한 사람은 조금씩 연결을 시작한다.

이 상황은 예전에 겪었던 저 상황과 구조적으로 비슷하다.
이 종류의 프로젝트에서는 초기에 이 위험을 먼저 없애야 한다.
사용자가 저 말을 할 때 실제 문제는 다른 곳에 있을 가능성이 높다.
이 정도 품질에서는 ship하면 안 된다.
반대로 이 정도면 이제 ship하고 feedback을 받아야 한다.

이런 judgment들이 누적된다.

그리고 어느 순간 우리는 그것을 taste라고 부른다.

Rollout의 수보다 중요한 것은 Rollout의 질이다

AI 시대에는 한 사람이 할 수 있는 작업의 양이 크게 늘어난다. 예전에는 세 달 걸리던 것을 한 달 안에 시도할 수 있다. 한 사람이 여러 role을 동시에 수행할 수도 있다.

그러면 같은 시간 동안 훨씬 많은 rollout을 경험할 가능성이 생긴다. 이것은 AI transition 세대에게 엄청난 기회라고 생각한다.

과거라면 3년 동안 세 번 해봤을 일을 1년 동안 열 번 해볼 수도 있다.

하지만 단순히 프로젝트 개수를 늘리는 것만으로는 부족하다. Rollout이 의미 있으려면 learning signal이 있어야 한다.

• 왜 잘되었는가.
• 왜 실패했는가.
• 내가 무엇을 잘못 보았는가.
• 다음에는 어떤 state variable을 더 주의해서 볼 것인가.
• 무엇은 다시 반복할 것인가.
• 무엇은 절대로 반복하지 않을 것인가.

이 reflection이 없다면 rollout 수는 많지만 학습은 거의 일어나지 않을 수 있다. AI가 activity를 폭발적으로 늘려준다고 해서 자동으로 taste가 좋아지는 것은 아니다.

AI는 Experience를 압축할 수 있는가

AI는 이미 많은 것을 압축하고 있다.

검색 시간을 압축한다. 코딩 시간을 압축한다. 글쓰기 시간을 압축한다. Prototype 제작 시간을 압축한다.

그렇다면 경험 자체도 압축할 수 있을까?

나는 어느 정도 가능하다고 생각한다.

AI 덕분에 우리는 예전보다 더 빨리 구현할 수 있다. 그렇다면 implementation에 쓰던 시간을 줄이고 productization과 shipping까지 더 자주 갈 수 있다.

즉 한 사람의 인생에서 경험할 수 있는 episode의 수 자체를 늘릴 수 있다. 이게 AI 시대의 가장 큰 educational opportunity 중 하나일지도 모른다.

다만 주의해야 한다.

AI가 너무 많은 부분을 대신해버리면 episode는 많아도 state-action-reward 관계를 이해하지 못할 수 있다.

코드는 만들어졌지만 왜 그렇게 작동하는지 모른다. 문서는 완성되었지만 왜 그 구조가 좋은지 생각하지 않았다. Product는 ship했지만 왜 사용자가 좋아하거나 싫어했는지 분석하지 않았다.

그렇다면 activity는 많지만 taste는 생기지 않는다.

중요한 것은 AI를 이용해 결과물을 많이 생성하는 것이 아니다. AI를 이용해 더 많은 meaningful trajectory를 살아보는 것이다.

Taste와 Productization은 서로를 만든다

처음에는 taste와 productization을 서로 다른 능력이라고 생각했다.

Taste는 무엇을 만들지 판단하는 능력. Productization은 그것을 잘 완성하는 능력.

그런데 계속 생각하다 보면 둘은 꽤 깊게 연결되어 있다.

Productization을 반복해본 사람은 조금씩 taste가 생긴다.

직접 끝까지 만들어본 사람은 안다.

초기에 굉장히 중요해 보였지만 실제 사용자는 전혀 신경 쓰지 않는 기능이 있다는 것을. 처음에는 사소해 보였지만 사용성을 완전히 결정하는 디테일이 있다는 것을. 기술적으로 멋지지만 설명하기 어려운 idea가 있다는 것을. 처음에는 평범해 보여도 실제 문제를 강하게 해결하는 idea가 있다는 것을.

어떤 failure는 치명적이고 어떤 failure는 받아들일 수 있다는 것을.

이런 것은 책에서 읽을 수는 있다. 하지만 자신만의 evaluation function으로 만들기 위해서는 직접 productization과 shipping을 여러 번 경험해야 한다.

Taste는 반복된 productization과 shipping 뒤에 남는 residue일지도 모른다.

그리고 좋은 taste를 가진 사람은 다음번에는 더 좋은 문제를 고른다. 더 좋은 문제를 고르면 더 좋은 episode를 경험할 가능성이 커진다. 더 좋은 episode는 다시 더 좋은 taste를 만든다.

선순환이 생긴다.

Shipping은 Taste를 교정한다

Taste는 자기 안에서만 만들면 위험하다. 자기 취향을 taste라고 착각할 수 있기 때문이다.

내가 아름답다고 느낀다고 해서 다른 사람에게 가치 있는 것은 아니다. 내가 좋은 research question이라고 느낀다고 해서 community가 반드시 중요하게 보는 것은 아니다. 내가 편하다고 느낀다고 해서 사용자가 편한 것도 아니다.

그래서 shipping은 일종의 calibration이다.

내 내부 evaluation function과 외부 세계의 evaluation function을 비교하는 과정이다. 그리고 이 gap을 반복해서 경험하면 taste가 조금씩 현실과 맞아간다.

Taste는 혼자 깊이 생각한다고만 생기는 것이 아니라 세상에 계속 내놓고 틀려보면서 교정되는 능력이기도 하다.

그렇다면 교육은 무엇을 해야 하는가

여기까지 오면 교육에 대한 질문도 생긴다.

앞으로 학생에게 무엇을 가르쳐야 할까.

지식을 전달하는 것은 여전히 중요하다. 기초를 공부하는 것도 여전히 중요하다. 수학, physics, programming, system fundamentals은 사라지지 않는다.

하지만 AI가 상당한 skill과 knowledge를 on-demand로 공급할 수 있다면 교육의 역할 중 하나는 점점 이런 질문으로 이동해야 할지도 모른다.

어떻게 학생에게 다양하고 의미 있는 rollout을 경험하게 할 것인가?

좋은 수업은 내용을 명확하게 설명하는 수업이어야 한다. 하지만 동시에 학생을 이전에 경험하지 못한 state로 보내는 수업이어야 할 수도 있다.

좋은 연구지도도 마찬가지다. 정답을 빨리 알려주는 것이 항상 최선은 아니다. 학생이 좋은 episode를 직접 만들어갈 수 있게 해야 한다.

사용자를 직접 만나게 해볼 수도 있다. 논문을 처음부터 끝까지 책임지게 할 수도 있다. 팀원을 이끌게 할 수도 있다. 실패한 프로젝트를 종료하는 판단도 해보게 할 수 있다. 실제로 software를 배포해보게 할 수도 있다. 자기가 만든 것에 다른 사람이 불평하는 경험도 필요하다.

왜냐하면 어떤 것은 직접 살아보아야만 배우기 때문이다.

Project Manager라는 역할도 다시 볼 필요가 있다

나는 AI 시대에 project manager라는 능력도 다시 중요해질 것이라고 생각한다.

예전에는 manager가 “실제 구현을 하지 않는 사람”처럼 오해되기도 했다. 하지만 좋은 project manager는 단순히 일정을 관리하는 사람이 아니다.

무엇을 만들어야 하는지 정의하고, 문제를 작은 단위로 나누고, 의존성을 파악하고, 누가 무엇을 맡아야 하는지 결정하고, 무엇을 버릴지 선택하고, quality bar를 정하고, 언제 ship해야 하는지 판단하는 사람이다.

Project management는 상당 부분 taste + product sense + prioritization + shipping discipline의 결합이다.

AI가 individual implementation capacity를 크게 늘릴수록 오히려 이런 능력의 가치가 커질 수 있다.

한 사람이 할 수 있는 일이 많아진다는 것은 반대로 잘못된 방향으로도 훨씬 더 빠르게 갈 수 있다는 뜻이기 때문이다.

좋은 후보자는 무엇을 이야기할까

그래서 리크루팅에서 에피소드를 물었을 때 꼭 성공담을 기대하는 것은 아니다.

오히려 흥미로운 답은 이런 것일 수도 있다.

처음에는 A가 핵심 문제라고 생각했는데, 실제 사용자를 만나보니 B가 진짜 문제라는 것을 알았다.

그래서 기존 구현의 절반을 버렸다.

일정은 늦어졌지만 결과적으로 사용자가 실제로 쓰는 기능 하나에 집중했다.

이후부터 나는 프로젝트 초기에 직접 사용자를 관찰하려고 한다.

이 짧은 이야기 안에도 많은 것이 들어 있다.

State representation. Action. Alternative. Decision criterion. Reward. Termination.

그리고 무엇보다 그 경험이 다음 policy를 어떻게 바꾸었는가.

나는 이런 이야기가 듣고 싶다.

능력치보다 Policy

사람을 볼 때 우리는 자꾸 능력치를 본다.

현재 Python을 얼마나 잘하는가. 논문을 몇 편 썼는가. 시험 점수가 몇 점인가.

하지만 앞으로는 조금 다른 질문도 중요해질 것이다.

새로운 state에 들어갔을 때 어떤 action을 선택할 사람인가?

즉 현재의 scalar 능력치보다 policy의 품질이다.

물론 policy는 직접 볼 수 없다. 그래서 trajectory를 봐야 한다.

과거의 여러 episode에서 어떤 state를 어떻게 해석했고, 어떤 action을 취했고, 어떤 reward를 얻었고, 그 후 policy를 어떻게 업데이트했는지 본다.

그것이 그 사람의 미래 행동을 조금 더 잘 설명할 수 있다.

Intention에서 Taste로, Implementation에서 Shipping까지

결국 내가 처음에 생각했던 “의도와 구현이 중요한 시대다”라는 문장은 조금 수정할 필요가 있다.

Intention만으로는 부족하다. Taste와 product sense가 필요하다.

Implementation만으로는 부족하다. Productization이 필요하다.

Productization만으로도 부족하다. Shipping이 필요하다.

그래서 지금 내가 더 중요하다고 느끼는 것은 다음 세 가지다.

AI 시대의 중요한 질문은 어쩌면 Rollout이다

앞으로 사람의 성장에 대해 생각할 때 나는 이 질문을 더 자주 하게 될 것 같다.

어떻게 더 다양하고 의미 있는 rollout을 수집할 것인가?

단순히 바쁘게 살자는 이야기가 아니다. 일을 많이 하자는 이야기도 아니다.

같은 state에서 같은 action을 반복하는 경험을 많이 쌓는 것과 서로 다른 state에서 실제 판단을 내려보는 경험을 쌓는 것은 다르다.

새로운 책임을 맡아보고, 새로운 사람과 일해보고, 새로운 사용자를 만나보고, 무언가를 처음부터 끝까지 만들어보고, ship하고, 실패하고, 다시 수정하는 것.

이런 episode가 필요하다.

그리고 episode를 그냥 지나치지 않고 왜 그런 결과가 나왔는지를 해석해야 한다. 그렇게 trajectory가 만들어진다.

마지막으로

나는 앞으로 사람을 차별화하는 것이 단순히 “현재 무엇을 할 수 있는가”만은 아닐 것이라고 생각한다.

AI는 많은 skill의 acquisition cost를 낮추고 있다. Implementation의 장벽도 낮아지고 있다.

그러면 희소성은 자연스럽게 다른 곳으로 이동한다.

무엇을 만들 가치가 있는지 알아보는 taste.
사용자의 문제를 읽는 product sense.
Prototype을 product급 artifact로 끌어올리는 productization 능력.
그리고 결국 실제로 세상에 내놓는 shipping discipline.

이 능력들은 하루아침에 생기지 않는다. 한 번의 시험 점수로도 설명하기 어렵다. 하나의 성공적인 프로젝트만으로도 만들어지지 않는다.

여러 episode를 살아야 한다. 서로 다른 state를 만나야 한다. 실제로 action을 선택해야 한다. Reward와 failure를 받아야 한다. 그리고 그 결과로 자신의 policy를 계속 수정해야 한다.

그래서 AI transition 세대에게 지금 몇 년은 특별히 중요할 수 있다.

AI를 이용해 예전보다 조금 더 빨리 과제를 끝내는 데만 만족할 것인가.

아니면 과거라면 하나를 경험했을 시간에 세 개, 다섯 개의 의미 있는 rollout을 살아볼 것인가.

직접 문제를 고르고, 끝까지 만들고, 실제로 ship하고, 그 결과를 다시 자신의 taste로 흡수할 것인가.

프로가 된 다음에 이런 경험을 시작할 이유는 없다. 오히려 지금 시작해야 한다.

앞으로 경쟁력은 하나의 완성된 능력치보다는 그 사람이 지금까지 어떤 trajectory를 살아왔고, 그 trajectory를 통해 어떤 taste와 policy를 학습했는가에서 더 크게 드러날지도 모른다.