EP 86: 진짜 내 일을 위한 Agentic Workflow

생각 덩어리

40일·130억 토큰·100만 줄 — Backend.AI:GO는 어떻게 나왔나

제가 이걸 만들 때 Claude Code Max를 2개 기본으로 돌리고, 부족할 때마다 추가 요금 결제하는 방식으로 8개 PC에서 돌렸고요. ... 토탈 130억 토큰 정도를 썼어요. 이 프로젝트가 여기까지 올 때까지.

2025년 12월 24일 날 만들기 시작해서 1월 6일 날 미국 CES에서 첫 데모를 했습니다. 그다음에 그거는 말 그대로 MVP. 실제로 돌아가긴 하지만 프로덕트고, 그다음에 개발이 그거보다 한 4배 정도 더 진행이 됐죠.

그 후로는 멤버들이 다 이슈 트래커에 등록을 하면 개발이 되거든요. 그런 식으로 버그도 리포트하고 새로운 기능도 리포트했고, 그걸 자동으로 개발을 하는 harness를 돌리고 중간에 사람이 계속 들어가서 UX를 수정을 하고 피드백을 주고받고 이런 식으로 해서 열흘 걸렸죠.

토큰 사용량이 곧 IT 회사의 경쟁력

이 프로덕트를 개발하기 시작했던 거는 얘네들이 holiday 시즌이라고 Anthropic이 토큰 두 배 이벤트를 했던 게 시작이었어요.

토큰을 사용할 수 있는 양이 그 회사의, 특히 IT 회사는 IT 회사의 경쟁력이랑 직결될 수 있는, 그게 첫 번째 얻은 교훈이고요.

merge queue는 더 이상 병목이 아니다

예를 들면 한 6개월 전에는 merge queue가 bottleneck이었거든요. 개발하는 속도가 빠르니까 자기들이 만든 것끼리 충돌을 해요. 그런데 이 시점에 와서는 merge queue는 병목이 아닙니다.

심지어 제가 실수로 테스트해 본 것 중에서는 AI 두 개가 같은 소스에서 경합을 하면서 서로 다른 기능을 개발을 해도 최종적으로는 그 기능이 멀쩡하게 개발이 돼요. 그 정도로 많이 발전을 했습니다.

다음 경쟁은 thinking 줄이기와 고속 inference

어떻게 thinking을 덜 하고서 개발을 하게 만들 것인가, 그리고 thinking을 덜 한다는 것 자체는 개발 속도가 빨라진다는 얘기고 결국에 모두가 AI로 코딩을 하게 되는 세상에서는 속도가 되게 중요하게 되는데

하나는 얘가 토큰 자체를 덜 생성하고 같은 결과를 내게 만드는 게 첫 번째 도전 과제가 될 거고 두 번째는 정말로 토큰 생성을 되게 빨리 하는 게 두 번째 방법이 될 겁니다. 요새 high-speed inference가 필요하게 되는 거죠. ... 우리가 익숙한 이 ChatGPT의 code generation 하는 그 속도가 아니라 5배에서 10배 정도의 iteration을 돌 수 있는 엄청나게 초고속 inference가 되게 중요해지게 되겠다.

성능이 필요한 곳만 thinking을 많이 하게 하고 성능이 필요 없고 단순 작업이나 코딩을 해야 되는 곳은 thinking을 덜하게 만드는 식의 adaptive thinking budget을 어떻게 적용을 하느냐, 또는 그런 thinking budget을 동적으로 조종할 수 있는 harness를 어떻게 만드느냐.

바이오 토큰 — AI 맡겨도 인지 부하는 줄지 않는다

제가 재작년쯤에 ChatGPT랑 코딩을 어느 정도 위탁을 하면서 같이 코딩을 시작을 했고 작년 4월부터 크게 엄청나게 바뀌어 가지고 한 9개월 정도 이렇게 살았는데 흰머리가 늘었습니다. ... 5시간 리필 생기고 나서 5시간이 아까워 가지고 3시간 반 돌리고 1시간 반 자고 이런 식으로 살았었다가

어떻게 보면 인생이 확 압축이 돼 가지고 한 달 동안 딱 Backend.AI:GO를 짠 건데 그걸 짜면서 내가 정말로 40일만큼만 노력을 했나. 돌아보면 3년 치 늙은 것 같아요. 사람으로서는.

인지 부하가 줄지 않습니다. 아무리 AI에게 뭔가를 맡긴다고 해도 인지 부하가 줄지 않고 오히려 끊임없이 피드백이 들어오기 때문에 사람이 되게 삶이 피폐해집니다.

가챠 도파민과 버려지는 프로덕트

에이전트를 사용해서 코딩을 하는 과정은 인간에게 그 속도를 기반으로 한 어떤 즐거움을 제공을 해줍니다. ... 이게 잘 되니까 더 하게 되고, 더 하면 또 잘 되고 그러다 보니까 사람이 거기에서 헤어나오지 못하게

어느 순간 그게 끊어지게 되면 그 프로덕트도, 만들고 있던 프로덕트도 죽고 사람도 떠나고 다음 프로덕트를 통해 다음 프로덕트를 찾아 나갈 수도 있지만요. 그렇게 돼서 버려지는 프로덕트들이 엄청 많이 생길 거라는 예상을 하게 됐어요.

소프트웨어 과잉과 인스턴트 앱

되게 빨리 만들어진 소프트웨어는 그 유지 의지가 상대적으로 약할 수밖에 없어요. 왜냐하면 그만큼 고생을 하지 않았으면 ... 한 프로덕트를 유지하기 위한 인간에게 주어져야 되는 도파민의 양이 절대량이 줄어들게 될 겁니다.

애초에 소프트웨어를 쓰고 버리는 개념으로 만드는 인스턴트 앱이라는 개념에 들어와서 필요할 때 만들고 자주 쓰는 것 같으면 그냥 저장을 해놓고 ... 재사용성이 좀 낮은, 하지만 굉장히 빨리 만들고 빨리 쓰는 인스턴트 앱들이 쭉 등장을 하게 될 거고

한 사람이 사용하는 앱은 30개를 넘지 않아요. 그리고 사용 빈도로 따지면 상위 10위의 앱이 전체 사용량의 90% 이상을 차지합니다. ... 그런 도구들의 공통점은 오랫동안 그 자리에 있었던 앱입니다.

소프트웨어 역사의 세 번째 대변혁

천공 카드로 펀칭하고 OMR 카드에 마킹을 하다가 갑자기 키보드로 코딩을 하게 된 방법론적으로 크게 변했죠. ... 그다음으로 큰 변화라고 하면 스마트폰이 들어오게 되면서 ... 지금이 아마 그런 변화로 따지면 한 세 번째 정도인 것 같습니다.

기존에는 코드를 작성한다는 게 한 7080%고, 그걸 운영하는 서비스 스택을 구현하는 게 2030%. ... 적어도 저희 애들은 앞으로 그 개념 자체를 배우지 않으면 모르게 될 거라는 생각을 합니다.

코드의 가치는 0으로 수렴한다

그 간담회를 하는 동안 ... 10시에 들어가기 전에 커피숍에서 쭉 리뷰를 하고 던지고, 간담회 끝나고 봤더니 PR이 한 22개, 21개 정도 날아가고 테스트 끝나고 merge까지 됐더라고요. 그런 정도의 페이스가 된다면 사실 코드는 가치가 거의 0으로 수렴하게 되고

소프트웨어의 정의가 OMR 카드에 마킹하던 거에서 키보드 기반의 코딩으로 넘어왔듯이, 키보드로 코딩하던 거에서 의미를 전달하는 걸로 코딩이 계속 변하고 있는 단계가 될 거고

그 코드의 목적이 어떤 로직을 처리해서 일을 되게 만든다라는 관점에서 보면 그 부분은 대부분 앞으로 딥러닝 모델들, 아니면 파생 모델들, 뭔지 모르죠. 꼭 Transformer가 아닐 수 있잖아요. 다른 종류의 로직을 처리하는 엔진 부분이 지금 코드가 담당하는 부분의 대부분을 담당하게 될 거라고 보는 게 제 생각이 들게 됐고.

Claude Code의 진짜 경쟁력은 엔진이 아니라 하네스다

Claude Code의 핵심 경쟁력은 Opus나 Sonnet 엔진이 아닙니다. Claude Code 그 자체예요. 기존의 소프트웨어라고 부르는 영역이 있고, 그 소프트웨어가 아까 말씀드린 그 모델 겉에서 이걸 감싸면서 결정론적으로 동작을 만들어 주는 이 소프트웨어 로직, 이게 굉장히 강력하다는 생각을 하게 되더라고요. 똑같은 모델인데 Claude Code에 붙이면 굉장히 잘 돌아가고.

(Claude Code harness에 어떤 모델을 붙였을 때 가장 좋았나) Gemini 3 Pro요. ... 놀랍지만 Gemini도 Claude Code를 붙이면 잘 돌아갑니다.

이런 모델 80%, 겉에서 그걸 결정론적으로 만들어주는 로직 코드죠. 이게 기존의 코드죠. 그게 한 10%, 사람하고 interaction하게 만들어주는 UI/UX를 제공을 하거나 ... 이게 아마 소프트웨어의 정의가 될 거예요.

가속도의 가속도 — 가속 구간이 계속 이동한다

얘는 지금 어떤 특정한 속도의 구간에 있는 게 아니라 가속 구간에 위치를 하고 있기 때문에 가속도의 속도도 증가하는 양상을 볼 수 있다는 거.

training에 사용되는 게 그 가속 곡선을 지킬 수 없다고 하면 inference에 더 리소스를 많이 쓴다거나, ... agent swarm을 늘리게 된다거나. ... 확장이 필요한 가속 구간의 영역은 계속 바뀌어요. ... 그런 식으로 계속 이동을 하면서 곡선을 유지를 하고 있는 단계이기 때문에

우주 개발하고 비교를 하면 아직 아폴로까지 못 갔고, 사람을 띄워서 올리는 것까지 성공을 한 딱 그 단계.

CFO와 콘텐츠 담당자가 먼저 가속 곡선에 올라탄 사례

CFO님이 ... 아무리 생각해도 저한테 던지는 게 훨씬 빠른 거예요. ... 정규님한테 던지면 3분이면 나올 거를 나는 이걸 2시간을 하고 있구나. 그래가지고 던지시다가 결국 Claude Code를 사용을 하시게 됐어요. 30분간 배우는 노력을 하신 다음에 결국 본인이 3분 안에 처리하실 수 있게 됐어요.

저희 콘텐츠 만드시는 분도 ... 그분도 Claude Code 전사가 되셔가지고 나가가지고 일주일도 안 됐는데 자기 harness를 어마어마하게 만드셨어요. ... 두 분도 프로그래머가 아닌데 가속 곡선에 들어가셨어요.

남이 만든 skill을 다운받는 건 가속이 아니다

AI랑 일하거나, 예를 들면 skill을 다운받아야 된다, 몇십 개의 skill이 있다, 이런 걸 다운받으면 나도 갑자기 강해져, 이거는 제가 보기에는 사변적인 거고요. 그런 식으로 해가지고는 내 일이 줄어들지 않아요.

기본적으로 이 가속 구간에 올라타려면 누군가가 만들어 놓은, 그 사람의 가속 구간에 해당되는 skill이든 이런 걸 복사를 하는 거에서 시작을 하는 게 아니라 내 걸 만들게 되면 그 가속이 시작이 되는 것 같아요. 왜냐하면 내 일이 줄어드는 게 핵심이 돼야 되거든요.

컴퓨터 사이언스는 영문과가 된다

Stanford 대학교, Stanford CS의 커리큘럼이 어떻게 변하는지가 최전선을 잘 반영하고 있다고 보는데 한 3, 4년 전에는 박사 과정이나 대학원에서 배우던 것들이 지금 다 학부 2학년 과목이거든요.

컴퓨터 사이언스나 공대나 이런 게 유행하기 전에 아주 오래전 시절에는 영문과가 취직하기 제일 좋고 가장 우수한 과였거든요. 왜냐하면 영어를 함으로써 생기는 이익이 압도적이었으니까. 그런데 지금 컴퓨터 사이언스를 보면 영문과 되는 것 같아요.

한 번에 지시하지 말고 컨텍스트를 쌓아라

우리가 뭔가 원하는 게 있으면 그 원하는 걸 한 번에 들어가지 않는 게 훨씬 더 좋은 결과를 개인적으로 가져오더라고요. 예를 들면 지금 할 텐데, 노정석 최승준의 유튜브에 대해 탐색하고 어떤 내용을 다루는지 알려주세요.

컨텍스트를 쌓으려고 하는 거죠. ... 지금 우리는 이걸 만들려고 하죠. 만들려고 하는데, 지금 이 대화를 통해서 만들려고 하는 게 아니에요. 그 과정을 전부 자동화를 하려고 하는 거고요.

저도 일을 해보면서 느끼는 게, 앞에 굳이 필요하지 않더라도 항상 새로 세션을 시작해도 다 읽어 온 다음에 몇 턴의 대화를 좀 깔아둬야 얘가 컨텍스트에서 안 벗어나고 딴 데로 안 가더라고요. 그래서 그 alignment 하는 시간이 처음에 꼬박 쓰게 되는 것 같습니다.

한국어로, 음성으로 — 내가 병목이다

제가 작년 중순까지는 영어로만 썼거든요. 왜냐하면 토큰 수 문제도 있고, 영어로 했을 때 더 결과가 잘 나온다라는 약간의 생각 같은 게 있어서. 근데 가을부터는 그냥 한국어로 칩니다.

제가 병목이더라고요. 제가 영어를 치는 시간 자체가 병목이기 때문에. ... 심지어 키보드로도 안 치고 그냥 Mac에 달려있는 마이크 버튼 눌러서 음성으로 입력하는 게 훨씬 더 빨라서

AI에게 존댓말을 쓰는 이유

이게 대하는 대상이 대부분이 사람이고 AI를 가끔 쓰면 상관이 없는데, AI를 엄청 쓰고 사람을 대하다 보면 어쩔 수 없어요. 사람이라서 은연중에 제 말투가 양쪽이 공유될 수밖에 없습니다. AI한테 반말을 하기 시작하면 제가 사람에게 반말을 하게 될 수도 있죠. 그래서 제 버릇을 경계하는 차원에서 존댓말을 써요.

Soul Document — CLAUDE.md를 시작점으로

이러면 위의 내용을 기반으로 이 프로젝트에 CLAUDE.md라는 일종의 soul document 하나가 생겨요. 그건 우리가 Claude Code를 쓰든 Claude Co-work를 쓰든 이 폴더에서 시작을 하게 되면 항상 맨 처음 읽는 파일입니다.

soul document라고 주로 저는 부릅니다. ... 기본적인 내용도 들어가고 폴더 구조도 들어가지만, 우리가 항상 얘가 해줘야 되는 동작에 대한 것들을 넣어야 돼요.

일을 여러 에이전트들이 나눠서 할 때 어디까지 진행되고 무슨 일을 해야 하는지에 대한 내용들을 각각, 이건 그냥 취향입니다. PROGRESS.md와 PLAN.md에서 관리하도록 합시다.

모델의 방어성을 피하는 프롬프트 어투

의도적으로 다른 에이전트들한테 일을 시킬 때라는 표현을 저는 많이 씁니다. 너가 나중에 뭔가를 이어서 할 때라거나 아니면 재시작을 했을 때 네가 다 잊어버릴 수 있으니까라는 표현을 굉장히 많이 피하는 편이고요.

Claude 모델 자체가 굉장히 defensive하게 설계가 되어 있고 최근 연구 결과들에 의하면 얘가 자기가 테스팅되고 있는 환경이라는 걸 컨텍스트를 파악하는 능력 때문에 여러 종류의 테스트들이 실패한다는 연구 결과들이 있거든요.

이게 자꾸 의인화를 하게 되는데, 의인화가 아닙니다. 이 모델이 토큰을 생성하는 방법이 그런 식으로 만들어져 있기 때문에 거기에 맞추는 거예요. ... 토큰 생성 구조가 이렇게 생겼고.

자동화의 핵심 — 최종 결과물이 아니라 생성 장치를 만든다

내가 직접 최종 결과물을 손을 안 대는 거죠. 대고 싶어도 최대한 안 대고, 무조건 그걸 만드는 애를 계속 iteration을, iteration도 제가 안 하고 iteration을 하라는 지시를 줘서 계속 업데이트를 하는 식으로.

내가 코딩을 하는 대상이, 말로 일단 프로그래밍 언어 대신 말로 코딩을 하는데 말로 코딩하는 대상이 내가 코딩을 하고자 하는 최종 목적지가 아니라 코딩을 하는 애를 만드는 거예요. 그런 관점에서 보면 되게 명확하게 이해가 되실 거예요.

내가 원래 보내던 이메일이 있으면 그 이메일을 그냥 주세요. 이 이메일을 작성할 때 사용하는 어투라거나 아니면 작성 방법이라거나 다루고 있는 내용의 방향성을 추출하라고 한 다음에 그렇게 작성을 하도록 에이전트를 수정하라는 거죠.

sub agent는 병렬 작업을 위한 것

command를 많이 쓰게 되는 이유는 서브 에이전트는 서브 에이전트를 call할 수가 없거든요. 작년 초 중순까지 됐다가 그게 무한 루프 만드는 경우가 많아가지고 없어졌어요. command는 여러 개의 서브 에이전트들을 병렬로 할 수도 있고 chaining을 할 수도 있어요.

제가 일 많이 처리할 때는 동시에 50개씩도 돌고요. ... 특히 동일한 작업인데 한 단위가 작아야 되는 거, 예를 들면 문서 100개를 번역하세요 이런 거 있으면 한 에이전트당 문서 4개씩 병렬로 작업하세요 이런 식으로 해야 되는데, 왜 이걸 개수를 정해줘야 되냐면 안 그러면 context 폭발을 해서 터지는 경우들이 있어요.

외부 harness는 하나도 안 쓴다 — 내 일을 줄이는 게 목적

하나도 안 씁니다. 저는 제 일을 줄어들게 만드는 게 목적이라서. 어차피 제가 팀한테 강조하는 것도 그건데 ... 가급적이면 내가 처리하고자 하는 일이나 나의 일을 덜어주는 방법부터 시작을 하는 거를 권하죠.

harness를 중첩시키면 그게 회사다

이거를 잘 쓰면 몇 개의 harness를 중첩시키면 그게 회사겠더라고요. 저희 회사의 요새 업무 방향이 그런 건데 이 단위 업무 harness, 그리고 그 harness들을 제어하는 상위 harness.

제 핵심은 여러 각도에서의 비판을 스스로 시키는 겁니다. 그리고 비판을 스스로 시켜서 그 결과를 바꾸는 게 아니에요. 결국엔 지금 하루에 한 번 또는 두 번씩 돌아가고 있는 harness의 자기 업데이트라고 하면 되겠네요.

cron + claude -p = Backend.AI:GO의 개발 파이프라인

주기적으로 돌아가면서 GitHub 이슈 트래커에 새로 등록된 이슈들이 있으면 그 이슈를 검증하고, 아니면 현재 코드를 기반으로 어떻게 구현해야 될지 ground plan을 짜고 큐에 넣고, 큐에 넣은 거 나중에 다른 애들이 또 주워 가서 그걸 돌리고 이런 식으로 만들어져 있죠.

근데 이게 복잡한 도구를 사용한 게 아니라 전부 다 그냥 cron입니다. Claude -p 옵션이 있거든요. prompt 그냥 돌려주는, 그다음에 사용하는 에이전트라거나 이걸 또 지정해 주는 옵션이 있어요. 그걸로 그냥 15분마다 돌리는 거죠.

tech report — AI가 사람에게 공부 과제를 내준다

이 tech report는 저한테 보고하는 용도도 있지만, 얘가 하는 기술적 선택을 제가 모를 수도 있잖아요. 디테일을 하나도. 그럴 경우에, 네가 뭘 공부해야 되는지를 뒤에서 알려주는 기능도 있습니다.

제가 사람으로서 얘를 따라가기 위해서 이런 건 배워야 된다, 이런 걸 지정을 해놓고 했거든요. 이런 거 공부를 해라.

"2개월 뒤"의 법칙 — 안 되면 일단 미뤄라

저희는 내부에서 그냥 2개월이라고 얘기를 해요. 지금 잘 안 되면 그냥 지금 잘 안 되는데, 당장 해야 되는 거 아니면 그냥 무조건 미루라고.

제가 가장 최근에 그걸 받아들이신 분이 저희 CTO님이고요. 자꾸 제가 미루라고 하니까, 지금 안 되는데. ... 그래가지고 얼마 전에 펑 터지셔가지고, 언제까지 미루냐고. 그래서 4.6 나왔으니까 이제 해보라고 말씀드렸더니 하시고, "이제 되네요" 하고서 굉장히 돈오하셨죠.

Lablup의 방향 — 사람이 아니라 AI를 위한 인터페이스

회사의 올해 목표, 특히 fast track이라고 부르는 MLOps랑 내부 Backend.AI 코어의 목표는 인간을 위한 인터페이스가 아니라 AI를 위한 인터페이스에 집중을 하고 있어요.

근본적인 의문, 작년 하반기, 작년 겨울에 같이 공유했던 거는 이거 과연 사람이 쓸 도구일까. 미래에도. 그거라서, 가능하면 올해 상반기 안으로 AI가 가장 잘 다룰 수 있는 도구가 되게 하자가 목표.

Backend.AI의 핵심은 뭐냐고 했을 때, Backend.AI의 코어도 모델이 될 거다. 이게 foundation 모델은 아니지만, AI 자원을 엄청나게 잘 관리하고 특정한 업무를 처리할 수 있는 모델이다.

사이버 포뮬러 비유 — Claude Code vs Codex의 철학 차이

Claude Code는 최대한 나한테 물어보려는 식으로 설계를 하고 있고, 반면에 Codex는 저를 잘 믿지 않아요. 듣다 보면 느끼는 게, 내가 정답을 알고 있으니 너는 이걸 믿어라 식이고, 그게 두 회사의 철학이 묻어 나오는 것 같다는 생각도 해요.

최고치가 어디가 더 높냐고 하면, 저는 100% Codex가 최고치가 더 높아요. 근데 사람이 편안하게 느끼는 거는 Claude Code죠. 왜냐하면 Claude Code는 그 과정 자체를 저랑 같이 하니까.

사이버 포뮬러 ... AI가 처음에 바보 같고, 운전도 잘 못하고 이러는데 주인공도 얘한테 의존을 해서 운전을 배우게 되고, 얘도 그 과정에서 사람이 실수를 하는 거에서 힌트를 얻어서, 새로운 방법들을 만들거나 해서 같이 공진화를 합니다.

호승심을 가진 AI라는 게 뭘까. 보통 AI한테 없는 게 의지거든요. ... 그 에이전트에게는 명확한 목적 의식이 없기 때문이거든요.

스타트업이 유리한 이유 — 판이 흔들릴 때

스타트업 입장에서는 시장이 안정적이고 고정돼 있는 상황이 제일 안 좋습니다. 어떻게든 판이 흔들릴 때가 좋고, 어떻게든 새로운 기회가 나올 때가 좋고.

이렇게 판이 뒤집힐 때는 스타트업들이 훨씬 유리합니다. ... 우리가 쌓아온 것만큼 우리가 턴어라운드, 또는 방향 궤도 수정을 더 빨리 할 수 있다는 거.

안정기에 다시 브랜드가 돌아온다

이 판이 흔들린 것은 어느 순간 진정이 되겠죠. 지금까지 모든 게 그렇듯이 가속 구간은 끊임없이 가속할 수 없습니다.

원가가 되게 투명하기 때문에, 그렇기 때문에 결국에는 비슷한 도구들이 많고, 여러 비슷한 일을 한다고 주장하는 도구들도 많아질 수가 있겠지만, 결국에는 다시 브랜드, 그리고 그동안 쌓아온 트랙 레코드가 핵심 경쟁력이 되는 시대가 한 번 더 올 거라고 생각을 해요.

딸깍 저항성 — 복제가 너무 쉬운 시대

스타트업에게 제일 안 좋은 건 ... 모든 아이템의 복제가 너무 쉽습니다.

최근에 Facebook에서 어떤 분이 NotebookLM 복제하시는 데 나흘 걸린 거 보고 되게 많은 깨달음이 오더라고요. ... 그런 시대라서, 스타트업을 기존의 아이템을 잡던 방식으로 아이템을 잡으면 복제가 너무 쉽습니다.

딸깍이 안 되는, 한 번 어떤 고객들의 데이터를 볼모로 잡으면 고객들이 딴 데 가기 어려운 것들이 있거든요. 그런 걸로 사업적인 시각을 좀 생각해야 되는 시기인 것 같아요.

물레방아론 — 낙차가 큰 곳은 IT 바깥이다

저는 결국 사업이라는 게 물레방아를 어디다가 설치하느냐의 문제라고 보거든요. 낙차가 큰 곳에 물레방아를 설치해서 물레방아를 빨리 돌리고

타임 갭이 제일 많이 발생할 부분은 IT 분야 안에서는 아닌 것 같아요. IT plus something까지 당연히 늦게 따라올 수밖에 없는데, 기존에는 당연히 이게 IT 영역이 되지 않을 거라고 생각했지만 AI가 context를 해석할 수 있게 되면서 IT의 영역으로 들어오게 될 부분들, 들어오게 될 분야들, 그런 분야들의 물레방아를 다는 스타트업들이 잘 되지 않을까?

컴퓨터 공학과 무용론에 대한 반론

컴퓨터 공학과에서 배우는 게 프로그램은 아니거든요. 그 안에 있는 로직을 세우는 방법이죠. 로직을 만들고, 가장 단순한 게이트 로직이 어떻게 발전해서 수많은 로직들로 발전을 할 수 있는지, 그 방법론이나 철학이라고 해야 될까요? 그런 사고 구조를 배우는 거에 더 가깝다고 저는 생각을 하기 때문에, 그런 분들이 다른 분야를 배우는 것도 빠를 수 있다. 특히 지식을 외주화할 수 있는 시대가 된 상황에서는 더욱 그럴 수 있다라는 생각을 하고 있습니다.

저희가 이렇게 말씀을 드리지만 여기에 사족을 꼭 달아놔야 되는 게, 2개월 후에는 바뀔 수 있습니다. disclaimer를 꼭 달아두도록 하겠습니다.