Cover · Issue 003
"한쪽엔 똑같이 찍혀 나오는 공장, 한쪽엔 손때 묻은 작은 공방."
TSTF MAG · 2026
편집부에 짧은 메모 한 통이 도착했다. "이제 각자가 자기 도구를 만드는 시대가 온다"고. 맞는 말일까. 맞다면, 어디까지. 그리고 그 다음엔 무엇이 바뀌는가.
며칠 전, 편집부에 짧은 메모가 하나 도착했다. 보낸 사람은 평범한 개발 동료였다.
"모두가 도구를 만들게 되면서, 과거의 방식인 — 도구를 만들어 배포하는 모델 — 은 저물어갈 것 같다. 앞으론 각자가 방향성만 알고 있으면, 자신에게 맞게 커스터마이징된 도구를 각자 만들어 쓰는 '도구 개인화의 시대'가 올 것이다."
— 편집부에 도착한 메모 · 2026.04짧지만 단단한 주장이다. 그리고 마침 이 메모의 배경처럼 읽히는 또 하나의 문장이 얼마 전 기술 업계에서 크게 회자됐다. AI 연구자 Andrej Karpathy가 2025년 2월에 올린 한 트윗이다.
"나는 이걸 바이브 코딩이라고 부른다. 바이브에 몸을 맡기고, 기하급수에 올라타고, 코드 자체가 존재한다는 사실을 잊어버리는 — 그런 새로운 방식의 코딩이다."
— Andrej Karpathy · 2025.02.02 · X↗Note 바이브 코딩(vibe coding)은 Karpathy가 이름 붙인 코딩 방식이다. 사람이 코드를 한 줄 한 줄 쓰고 검토하는 대신, AI에게 자연어로 말하고 결과만 받는 방식. Karpathy는 "코드가 어떻게 돌아가는지는 이제 잊어라"라고까지 말했다. 주말 장난감 프로젝트에는 훌륭하고, 실제 상용 제품에는 아직 위험한 — 그런 경계의 도구다.
두 문장을 나란히 놓으면 하나의 그림이 보인다. 도구를 만드는 비용이 무너지고 있다. 그리고 어떤 사람들은 그걸 근거로 "도구는 이제 각자가 만든다"고 말하기 시작했다. 이 호는 그 주장을 네 조각으로 쪼개서 본다. 어디까지 맞는지, 어디서 꺾이는지.
메모의 주장을 한 덩어리로 보면 강력한 선언 같다. 하지만 안을 들여다보면 성격이 다른 문장들이 섞여 있다. 어떤 것은 이미 현장에서 일어나고 있는 사실이고, 어떤 것은 아직은 이상에 가깝다. 그 층을 나눠서 보면, 이 흐름에 어떻게 반응해야 할지가 조금 선명해진다.
한 명이 오후 한나절이면 자기 일에 맞춘 작은 자동화 도구 하나를 만드는 일이, 지금은 특별한 일이 아니다. 기획자가 자기 밸런싱 시트용 대시보드를 하루 만에 만들고, QA가 자기만의 반복 테스트 스크립트를 점심시간에 뚝딱 짠다. Cursor, Claude Code, Replit Agent, Windsurf 같은 도구들이 그 진입 장벽을 거의 0에 가깝게 낮췄다. "만들 수 있는 사람"과 "없는 사람"의 경계가 흐려지고 있는 건 맞다.
도구를 만들려면 하나가 필요하다. "내가 뭘 원하는지를 아는 것." 메모에서도 "방향성만 알면"이라고 쓰여 있었다. 그런데 그 "방향성" — 즉 내 일의 어느 부분을 어떻게 바꾸고 싶은가 — 는 생각보다 드문 자원이다. 대부분은 만들 시간이 없거나, 의지가 없거나, 필요를 못 느낀다.
그래서 이 흐름은 모두를 평등하게 만드는 게 아니라, 오히려 격차를 벌릴 가능성도 있다. "자기 도구를 만드는 사람"과 "그 도구를 얻어쓰는 사람"과 "아예 관심 없는 사람"으로 세 부류가 빠르게 갈라질 수 있다. "모두의 시대"라는 선언이 그 격차를 가릴 위험이 있다.
"도구 제작 후 배포 모델이 저문다"는 말도, 반은 맞고 반은 아니다. Claude, Cursor, Unity, Figma 같은 기반 도구들은 오히려 더 커지고 튼튼해지고 있다. 사라지는 건 이런 기반 도구가 아니다. 사라지는 건 "사용자는 쓰기만 한다"는 한 방향 관계다. 이제는 같은 도구를 쓰는 사람이 동시에 그 도구 위에서 작은 도구를 만드는 사람이 된다. 쓰는 행위와 만드는 행위 사이의 선이 흐려지는 것이다.
그래서 이번 호의 진짜 이야기는 "개인화"가 아니다. "레이어링"이다. 옛날에는 도구가 한 덩어리였다. 회사가 만들어 준 하나의 UI를 모두가 그대로 썼다. 지금은 그 도구 위에 각자의 작은 레이어가 얹힌다. 기반은 여전히 누군가 만들어 유지하고, 그 위에 AI 엔진이 얹히고, 그 위에 다시 내가 만든 한 줌의 자동화가 얹힌다. 같은 Claude, 같은 Figma여도 — 내 위에 있는 층은 옆 사람과 다르다.
이게 맞다면, "누가 도구를 만드는가"라는 질문은 바뀐다. "어느 층을 누가 만드는가"로.
"각자가 자기 도구를 만드는 시대"라는 그림은, 마치 한 사람이 처음부터 끝까지 혼자 자기 도구를 만든다는 느낌을 준다. 하지만 실제로 일어나는 일은 그와 다르다. 대부분의 "내 도구"는 거대한 기반 위에 얹힌 얇은 한 층이다. "개인화"라고 부르면 그 구조가 잘 안 보이고, "레이어링"이라고 부르면 구조가 드러난다.
| 개인화 (상상) | 레이어링 (현실) | |
|---|---|---|
| 도구의 구조 | 내가 처음부터 끝까지 만든다 | 기반 위에 내 층을 얹는다 |
| 책임 범위 | 모든 계층 | 내 층만 |
| 유지 보수 | 전부 내 몫 | 기반은 회사·AI 엔진이 맡는다 |
| 필요한 능력 | 완전한 개발 역량 | 방향성 + 조립 능력 |
| 생존 기간 | 만든 사람이 떠나면 끝 | 기반이 살아있는 한 지속 |
이 표에서 흥미로운 지점은 여기다. 만드는 사람 입장에서는 "내가 만들었다"는 감각이 또렷하다. 그런데 실제로는 그는 혼자 만든 게 아니다. 자기도 모르는 사이에 거대한 공용 기반 위에 서 있다. 그 기반은 누군가 계속 만들고 유지하는 중이다. 혼자 만든 것처럼 느껴지지만, 혼자 만든 게 아니다.
이 프레임을 잠시 받아들이면 몇 가지가 따라온다.
이 이야기는 이미 TSTF 안 여러 자리에서 벌어지고 있다. 누군가는 반복 작업을 자동화하는 작은 스크립트를 주말에 만들어 와서 월요일에 돌리고, 누군가는 밸런싱 데이터 위에 자기만의 대시보드를 붙였고, QA에서는 테스트 결과를 AI에 넣고 요약 리포트를 자동으로 받는 시도가 이미 굴러간다.
이게 좋기만 한 이야기는 아니다. 같이 생각해볼 점이 몇 가지 있다.
그래서 질문은 "누가 도구를 만드는가"에서 다음으로 옮겨간다 — "어느 층까지를 팀이 공유하고, 어느 층은 개인에게 맡기는가." 이게 앞으로 몇 년, TSTF가 내부적으로 조금씩 정리해 나가야 할 질문 같다.
이번 호의 결론을 당신에게 미룬다. 답은 정해두지 않았다. 점심 자리에서 한 번쯤 꺼내보길 바라는 질문들이다.
있다면 그건 팀의 다른 사람과 공유되고 있는가? 공유 안 된다면, 그 이유는 시간인가, 형식인가, 아니면 공유할 필요를 못 느껴서인가?
"모두가 도구를 만든 해"로 기억될까, 아니면 "도구의 기반과 표층이 갈라진 해"로 기억될까? 이 둘의 차이는 지금 우리가 무엇을 배워야 하는지에 영향을 주는가?
의미가 남는다면 — 어떤 모습으로 남을까? "같은 도구를 쓰는 사람들"이 아니라면, 무엇으로 묶인 사람들인가?
이번 호는 한 동료의 짧은 메모에서 출발했다. 진단은 예리했고, 동시에 조금 과감하다고 느꼈다. "모두가 자기 도구를 만드는 시대"라는 그림은 아름답지만, 현장을 보면 그 그림과 현실 사이에 적지 않은 간격이 있다는 것도 부정할 수 없었다.
그래서 이번 호는 그 메모에 작은 조정을 덧붙이는 형태가 됐다. 개인화는 맞다. 다만 그 개인화는 혼자서 만드는 것이 아니라, 거대한 기반 위에 얇게 얹은 내 층이다 — 이게 더 정확한 그림이라고 본다. 중요한 건 "개인이 자유로워진다"가 아니라, "도구의 층이 늘어났다"는 구조의 변화다.
이 그림이 맞다면, 우리가 앞으로 던져야 할 질문은 조금 달라진다. "누가 도구를 만드는가"가 아니라, "우리는 어느 층까지 함께 만들고, 어느 층은 각자에게 맡기는가." 이건 TSTF 같은 팀에게 꽤 실용적인 질문이다.
반론과 보완은 언제나 환영한다. 이번 호의 출발 자체가 한 동료의 메모였듯이 — 매거진은 다른 누군가의 메모로 또 이어진다.
— Desk γ바이브 코딩 시대, 앱 유통의 재설계에 관하여.