토스 개발자의 목소리: AI와 추상화의 탑
아마라의 법칙과 우리가 선 위치
토스 Node.js Developer 정세훈은 “개발자는 AI에게 대체될 것인가?”라는 글에서 아마라의 법칙(Amara’s law)으로 시작한다. “기술의 효과는 단기적으로 과대평가되고, 장기적으로 과소평가되는 경향이 있다.” 그리고 이어진다. “우리는 개발자로서 AI 하이프가 생기는 모든 과정을 직접 겪었습니다. 그리고 지금, 버블의 한가운데 서 있습니다.”
이 문장은 앞서 분석한 모든 것을 관통하는 핵심 통찰이다. PwC 조사의 56% CEO가 AI 투자에서 아무 성과도 보지 못한 것, 엔트리 레벨 채용이 67% 급감한 것, “딸깍했더니 다 해주더라”는 경험, 그리고 “컨트롤러가 리포지토리를 직접 사용하면 안 된다”는 경고. 이 모든 것이 아마라의 법칙의 서로 다른 측면이다.
단기적으로는 과대평가된다. “AI가 개발자를 대체한다”, “이제 코딩 몰라도 된다”, “누구나 개발자가 될 수 있다”. 그러나 장기적으로는? 정세훈의 다음 문장이 답이다.
추상화의 탑과 리팩토링의 시점
“AI가 있다고 해서 더 많은 것을 달성할 수 있고, 더 많은 실험과 도전을 할 수 있다고 생각하는 것은 위험합니다. 그런 방식의 접근은 AI로 인지 부하를 줄여나간다는, 기존 업무를 올바른 방식으로 추상화한다는 전제가 있지 않은 한 지속 가능하지 않습니다.”
이것이 핵심이다. AI는 코드 작성 속도를 높인다. 그러나 그것은 “올바른 방식으로 추상화한다는 전제” 하에서만 지속 가능하다. 올바른 방식이 무엇인가? 바로 앞서 경고한 아키텍처 원칙들이다. 계층형 구조, 관심사의 분리, 의존성 역전, 도메인 독립성.
정세훈은 계속한다. “개발자들이 프로젝트 중간에 리팩토링을 해야 한다고 시간을 달라고 할 때, 이것은 추상화의 레버리지가 흔들리기 시작하는 때입니다. 경험 많은 엔지니어링 리더는 이때를 감지하고 판단할 수 있는 능력이 뛰어납니다.”
그렇다. 전통적 개발에서 우리는 리팩토링이 필요한 시점을 경험으로 안다. 코드 스멜이 보이기 시작한다. 변경이 점점 어려워진다. 테스트가 깨지기 시작한다. 버그가 예상치 못한 곳에서 나타난다. 이때가 “추상화의 레버리지가 흔들리는” 시점이다.
그러나 AI 시대에는? “지금 AI로 인해 우리의 업무가 빠른 속도로 추상화의 탑을 쌓고 있지만, 우리는 이 업무의 추상화를 어느 시점에서 리팩토링해야 하는지 아직 판단하는 경험치가 없습니다.”
vFunction의 경고와 완벽한 일치
이것은 vFunction의 “architectural drift” 경고와 정확히 일치한다. AI는 빠르다. 그리고 잘못된 방향으로 빠르면 재앙이다. “AI가 생성한 코드는 종종 작동한다. 그리고 그것이 정확히 문제다.” 작동하는 코드를 보면 우리는 만족하고 다음으로 넘어간다. 그러나 그 아래에서 architectural drift가 조용히 누적된다.
컨트롤러가 리포지토리를 직접 호출하는 코드가 작동한다. 서비스가 RequestDTO를 받는 코드가 작동한다. AI가 생성한 하나의 파일에 모든 로직이 들어간 코드가 작동한다. 그러나 이것들은 모두 “추상화의 탑”을 잘못 쌓고 있다. 그리고 우리는 “어느 시점에서 리팩토링해야 하는지 판단하는 경험치”가 아직 없다.
왜냐하면 이 속도는 처음이기 때문이다. 전통적으로 기술 부채는 몇 년에 걸쳐 누적되었다. 팀이 바빴고, 마감이 촉박했고, “나중에 리팩토링하자”고 했다. 그리고 나중은 오지 않았다. 그러나 그 과정은 느렸다. 감지할 시간이 있었다.
AI 시대는 다르다. AIT의 분석처럼 “무엇이 몇 년에 걸쳐 누적되던 것이 이제 몇 번의 스프린트에 발생할 수 있다.” 토스 정세훈의 말처럼 “빠른 속도로 추상화의 탑을 쌓고” 있다. 그리고 우리는 언제 멈춰야 하는지, 언제 다시 돌아가 기초를 다져야 하는지 모른다.
AI 퍼스트 조직의 재정의
CIO 기사에서 정세훈은 AI 퍼스트 조직을 다르게 정의한다. “‘무엇을 더 만들 것인가’를 고민하는 단계가 아니라, ‘무엇을 하지 않아도 되게 만들 것인가’를 고민하는 단계”
이것은 심오한 전환이다. 대부분의 조직이 AI를 “더 빠르게 더 많이 만드는 도구”로 본다. 그러나 토스는 AI를 “하지 않아도 되는 것을 식별하는 도구”로 본다. 이 차이가 결정적이다.
“더 빠르게 더 많이” 접근은 앞서 경고한 위험으로 이어진다. 인지 부하 증가, 추상화의 탑, architectural drift, 검증되지 않은 코드의 누적. 반면 “하지 않아도 되는 것” 접근은 본질에 집중한다. 정말 중요한 것은 무엇인가? 우리가 직접 해야 하는 것은 무엇이고, AI에게 맡길 수 있는 것은 무엇인가?
PwC 조사의 성공한 12%와 실패한 56%의 차이가 여기에 있다. 성공한 기업들은 “systems matter more than prompts”를 이해했다. 그들은 AI로 “더 많이”가 아니라 AI로 “올바르게”를 추구했다. 강력한 AI 기반을 구축하고, 기업 전체에 통합하고, 명확한 로드맵을 가졌다. 그 결과 3배 높은 성공률과 4% 높은 이익 마진을 달성했다.
개발자 역할의 진짜 변화
CIO 기사에서 정세훈은 개발자 역할 변화를 명확히 정리한다. “과거에는 개발자가 문제 정의부터 구현까지 모든 단계를 직접 주도해야 했다면, 이제는 AI가 실행의 상당 부분을 담당한다. 그만큼 개발자는 판단과 선택에 더 집중하는 역할로 이동하고 있다.”
이것을 앞서 분석한 “Hello World도 못하지만 공부 안 할 것”과 대조해보자. 구문을 모르는 것은 이제 치명적이지 않다. AI가 구문을 작성한다. 그러나 “판단과 선택”은? 이것은 더욱 중요해졌다.
무엇을 판단하고 선택하는가?
- 아키텍처 설계: 계층을 어떻게 나눌 것인가? 의존성 방향은? 도메인 모델은?
- 품질 기준: 이 코드가 “작동함”을 넘어 “좋은가”? 유지보수 가능한가? 확장 가능한가?
- 비즈니스 로직: 이 요구사항의 진짜 의미는 무엇인가? 엣지 케이스는? 예외는?
- 기술 부채 관리: 지금 빠르게 가는 것과 나중에 리팩토링하는 것 사이의 균형은?
- 팀 협업: 이 결정이 다른 팀에 미치는 영향은? 표준을 따르고 있는가?
이 모든 것이 “Hello World” 구문보다 훨씬 중요하다. 그리고 이것들은 AI가 대신할 수 없는 것들이다. 아니, 더 정확히는 AI에게 올바르게 지시하고, AI의 결과를 올바르게 평가하기 위해 필요한 것들이다.
Skills와 Sub-agents로의 회귀: 토스의 실천
흥미롭게도 토스는 이미 구조화된 접근을 실천하고 있다. 토스 기술 블로그에서 최근 발표한 “API 연동 자동화를 위한 여정: 토스는 왜 사내 MCP 서버를 개발하였는가? with Spring-AI”가 그 예다.
MCP(Model Context Protocol)는 Claude의 공식 프로토콜이다. 그리고 토스는 내부 Swagger 문서를 MCP 서버로 구축했다. 왜? “개발자들에게 익숙해진 불편함을 해결하기 위해”. 즉, 개발자들이 반복적으로 Swagger를 찾고, API 스펙을 확인하고, 코드를 작성하는 과정을 자동화한 것이다.
이것은 정확히 Skills의 개념이다. 토스 내부의 API 구조, 명명 규칙, 인증 방식을 구조화된 지식으로 만들고, AI가 이를 활용할 수 있게 한 것이다. “딸깍했더니 다 해주더라”가 가능한 이유는 이러한 구조화 덕분이다.
또한 토스는 “AI 에반젤리스트” 제도를 운영한다. 약 10여 명의 개발자가 본업과 병행하며 AI 활용을 조직 전반으로 확산시킨다. 정세훈은 “개발자들은 각자 생산성을 높이는 방법을 알고 있어도 특유의 성향 탓에 이를 적극적으로 공유하지 않는 경우가 많다”고 지적한다. AI 활용 노하우가 개인에게 머물지 않고 조직으로 확산되게 하는 것이 핵심이다.
토스의 조직 문화와 AI의 시너지
CIO 기사는 토스 조직 문화의 독특함을 강조한다. “토스는 전통적인 문서 중심 조직이라기보다는, 대부분의 맥락과 의사결정이 슬랙 안에 축적되는 구조. AI가 이러한 대화형 데이터와 결합되면서 온보딩이나 맥락 파악 속도가 눈에 띄게 빨라졌다.”
이것은 중요한 통찰이다. AI는 구조화된 데이터와 잘 작동한다. 그러나 “구조화”가 반드시 “문서”를 의미하지는 않는다. 슬랙 대화도 구조화될 수 있다. 채널, 스레드, 멘션, 리액션. 이 모든 것이 구조다. AI는 “누가 언제 어떤 논의를 했는지를 빠르게 요약하고 연결”할 수 있다.
이것은 다시 Skills의 원리로 돌아간다. 카탈로그 vs 산문. 색인이 있는 책 vs 뒤죽박죽인 책. 구조화된 슬랙 대화는 카탈로그이고 색인이 있는 책이다. AI는 그것을 효과적으로 탐색할 수 있다.
올리브영의 현실: 디버깅과 리팩토링은 여전히 어렵다
CIO 기사는 올리브영 테크 전략 지원팀장 권성환의 발언도 인용한다. “비개발자도 AI를 활용해 그럴듯한 결과물을 만드는 것까지는 가능하지만, 실제 서비스 내부에서 문제가 발생했을 때 디버깅하거나 리팩토링하는 것은 여전히 매우 어렵다. 개발자로서의 전문성은 여전히 살아 있고, 오히려 더 중요해지고 있다.”
이것이 현실이다. “그럴듯한 결과물”과 “프로덕션 서비스” 사이의 거대한 격차. AI는 전자를 만들 수 있다. 그러나 후자는? 디버깅, 리팩토링, 성능 최적화, 보안 강화, 확장성 보장. 이 모든 것이 여전히 개발자의 전문성을 요구한다.
그리고 이것들은 모두 “올바른 추상화”에 기반한다. 잘못된 추상화 위에 쌓인 시스템은 디버깅이 악몽이다. 문제가 어디서 발생하는지 찾을 수 없다. 책임이 흩어져 있다. 의존성이 꼬여 있다. 리팩토링? 불가능에 가깝다. 하나를 건드리면 열 개가 깨진다.
10-20년 후의 우려: 복잡한 시스템 설계 인력 부족
토스 블로그 댓글 중 하나가 중요한 지적을 한다. “다만 10~20년 뒤 복잡한 시스템을 설계할 차세대 인력이 부족할 것이라는 전망은, ‘장기적으로 기술을 과소평가’하는 경향이 있기 때문에 나온 것 아닌가 싶네요.”
이것은 아마라의 법칙의 다른 면이다. 우리는 지금 단기적 효과를 과대평가하고 있을 수 있다. 그러나 동시에 장기적 영향을 과소평가할 수도 있다. 엔트리 레벨 채용이 67% 감소했다. 전통적 “사다리”가 무너지고 있다. 주니어 개발자들이 AI에 의존하며 기본을 배우지 못한다면?
Josh Bersin의 경고를 상기하자. “엔트리 레벨 채용을 억제하는 것은 실수일 수 있다. 젊은 직원들이 AI를 채택하고 혁신하는 속도가 더 빠르다.” 그러나 그들이 AI만 사용하고 기본을 배우지 못한다면? 10-20년 후에 복잡한 시스템을 설계할 시니어 엔지니어가 부족하다면?
이것은 산업 전체의 장기적 위험이다. 단기적으로 AI가 엔트리 레벨을 대체하는 것처럼 보인다. 비용 절감, 효율성 증가. 그러나 장기적으로? 경험 있는 아키텍트, 시스템 설계자, 기술 리더를 어디서 얻는가? 그들은 모두 엔트리 레벨에서 시작해 성장한 사람들이다.
토스의 채용 전략: ML과 데이터 엔지니어
흥미롭게도 토스는 역주행한다. 미주중앙일보 기사(2025년 10월)에 따르면, “올 상반기 개발자 채용 시장에 찬바람이 불었다. AI 코딩 실력이 늘면서 신입 개발자 채용 수요가 감소해서다. 이런 상황에서 토스는 공격적으로 개발자를 끌어모으고 있다. 지난해 말 2000여명이었던 직원 수를 올해 말까지 3000명으로 늘리는 게 목표.”
그러나 누구를 뽑는가? “기계학습(ML) 엔지니어와 데이터 엔지니어를 뽑는 데 주력하고 있다.” “AI 개발자는 안 뽑나”는 질문에 토스 데이터 부문장은 “토스는 다른 IT기업처럼 대규모 언어모델(LLM)을 개발할 계획은 없다. 이미 오픈소스로 풀린 LLM을 미세조정해서 쓰면 되기 때문이다.”
이것은 전략적 명확성이다. 토스는 LLM을 만들지 않는다. 그것은 Anthropic, OpenAI, Google의 영역이다. 대신 토스는 데이터를 활용한다. “토스에는 매일 100테라바이트(TB) 규모 데이터가 축적된다. 한 달로 치면 3페타바이트.” 그리고 “패턴을 발견해 성과를 예측하는 데 특화된” ML 엔지니어와 데이터 분석가를 뽑는다.
이것은 AI 시대의 차별화 전략이다. 모두가 같은 LLM을 사용한다. Claude, GPT, Gemini. 차별화는 어디서 오는가? 데이터와 도메인 전문성. 토스의 3PB 금융 데이터, 그것을 이해하고 활용하는 능력. LLM은 상품화되고 있다. 그러나 데이터 활용 능력은 여전히 희소하고 가치 있다.
종합: 네 가지 분석의 교차점
지금까지의 모든 분석을 종합하면 명확한 그림이 나온다.
1. PwC의 56% 실패와 토스의 “올바른 추상화”
PwC 조사의 56%는 AI 투자에서 아무 성과도 얻지 못했다. 왜? “기본을 잊었기” 때문이다. 사람과 프로세스 투자 없이 기술만 도입했다. 토스의 통찰과 정확히 일치한다. “AI로 인지 부하를 줄여나간다는, 기존 업무를 올바른 방식으로 추상화한다는 전제가 있지 않은 한 지속 가능하지 않습니다.”
성공한 12%는 무엇을 했는가? 강력한 AI 기반 구축, 기업 전체 통합, 명확한 로드맵, Responsible AI 프레임워크. 이것들은 모두 “올바른 추상화”의 형태다. Systems matter more than prompts.
2. 엔트리 레벨 채용 급감과 “복잡한 시스템 설계 인력 부족”
엔트리 레벨 채용이 67% 급감했다. 단기적으로 기업들은 비용을 절감한다. AI가 엔트리 레벨 작업을 대체하니까. 그러나 장기적으로? 10-20년 후 복잡한 시스템을 설계할 시니어 엔지니어는 어디서 오는가?
토스는 다르게 접근한다. 여전히 공격적으로 채용한다. 그러나 특정 유형의 인재를 찾는다. ML 엔지니어, 데이터 엔지니어. 패턴 발견과 예측에 특화된 사람들. LLM 개발이 아니라 데이터 활용. 이것이 장기적 차별화 전략이다.
3. “딸깍했더니 다 해주더라”와 “아키텍처 원칙”의 긴장
Skills와 Sub-agents는 실제로 “딸깍했더니 다 해주더라”를 가능하게 한다. 토스의 MCP 서버가 그 예다. 그러나 이것이 작동하려면 무엇이 필요한가? 구조화된 지식. 명확한 아키텍처. 일관된 패턴.
“컨트롤러가 리포지토리를 직접 사용하면 안 된다”는 원칙을 Skill로 인코딩하면, AI는 그것을 따른다. 인코딩하지 않으면? AI는 가장 간단한 방법을 택한다. 모든 것을 하나의 파일에 넣는다. 계층을 무시한다. Architectural drift가 발생한다.
딸깍의 마법은 준비에서 온다. 그리고 그 준비는 아키텍처 원칙을 이해하고 구조화하는 것이다.
4. “Hello World도 못함”과 “판단과 선택에 집중”의 조화
“Hello World도 못하지만 공부 안 할 것”이라는 선언과 “개발자는 판단과 선택에 더 집중하는 역할로 이동”은 모순이 아니다. 이것들은 같은 전환의 다른 표현이다.
구문을 아는 것은 더 이상 핵심 역량이 아니다. AI가 구문을 작성한다. 그러나 “판단과 선택”은 핵심이다. 아키텍처 설계, 품질 기준, 비즈니스 로직, 기술 부채 관리, 팀 협업. 이것들은 모두 구문보다 높은 수준의 사고를 요구한다.
역설적으로, 구문을 몰라도 되기 때문에 더 중요한 것에 집중할 수 있다. 그러나 “더 중요한 것”을 모르면? 그것이 문제다. 아키텍처 원칙을 모르고, 설계 패턴을 모르고, 시스템 사고를 못 하면, AI가 아무리 빠르게 코드를 작성해도 결과는 기술 부채의 산이다.
결론: 추상화의 탑을 올바르게 쌓는 법
토스 정세훈의 핵심 통찰로 돌아가자. “지금 AI로 인해 우리의 업무가 빠른 속도로 추상화의 탑을 쌓고 있지만, 우리는 이 업무의 추상화를 어느 시점에서 리팩토링해야 하는지 아직 판단하는 경험치가 없습니다.”
이것이 2026년 우리가 마주한 진짜 도전이다. 속도가 문제가 아니다. 방향이 문제다. 추상화가 문제가 아니다. 올바른 추상화가 문제다.
어떻게 올바르게 쌓는가?
아키텍처 원칙을 먼저 세워라: 컨트롤러가 리포지토리를 직접 사용하면 안 되는 이유를 이해하라. 서비스가 RequestDTO를 받으면 안 되는 이유를 이해하라. 이것들은 추상화를 올바르게 쌓는 기초다.
Skills로 원칙을 인코딩하라: 아키텍처 원칙을 구조화된 지식으로 만들어라. AI가 따를 수 있는 형태로 표현하라. 토스의 MCP 서버처럼.
“무엇을 하지 않아도 되는가”를 물어라: “무엇을 더 만들 것인가”가 아니라 “무엇을 하지 않아도 되게 만들 것인가”. 이것이 AI 퍼스트 조직의 진짜 의미다.
리팩토링 시점을 감지하는 법을 배워라: 이것은 새로운 기술이다. 전통적 코드 스멜과 다르다. AI 생성 코드의 스멜을 배워야 한다. 언제 추상화의 탑이 흔들리기 시작하는가?
판단과 선택에 집중하라: 구문은 AI에게 맡겨라. 그러나 아키텍처 설계, 품질 기준, 비즈니스 로직은 당신이 주도하라. 이것이 개발자의 새로운 역할이다.
장기적 인재 파이프라인을 생각하라: 엔트리 레벨을 완전히 없애는 것은 10-20년 후 복잡한 시스템 설계 인력 부족으로 이어질 수 있다. 균형을 찾아라.
우리는 버블의 한가운데 서 있다. 아마라의 법칙을 상기하라. 단기적으로 과대평가되고, 장기적으로 과소평가된다. 지금의 흥분을 넘어 장기적 지속가능성을 생각하라. 추상화의 탑을 빠르게 쌓되, 올바르게 쌓아라. 그것이 2026년 개발자로 살아남는 방법이다.
작성일자: 2026-01-22