코드 놀이터는 어디로 사라졌을까?
Source: Dev.to
코딩 인터뷰 준비 시작하기
기술 인터뷰 실력을 향상시키고 싶었다. 바로 여기서 이야기가 시작된다.
몇 년 전 Udemy에서 Master the Coding Interview 라는 ZTM(Zero to Mastery) 강의를 듣고 있었다. 이 강의는 기본을 잘 다룬다: 알고리즘이란 무엇인지, 자료구조가 하는 일, 그리고 거의 모든 엔지니어링 의사결정의 근간이 되는 시간·메모리 관계 등. 많은 사람들이 비판하지만, 나는 꽤 괜찮다고 생각했다.
Replit, Glot.io, 그리고 초기 플레이그라운드
강사는 모든 예제를 Replit을 이용해 가르쳤다. 예제 전체와 실시간 코딩이 모두 브라우저 안에서 이루어졌다. 당시 Replit은 정말 인상적이었다. 작은 가상 머신을 손 안에 둔 느낌이었고, 코드를 작성하고 실행하고 심지어 터미널까지 사용할 수 있었다. 시각적으로도 깔끔하고 사용하기 편했기에 마음에 들었다.
하지만 강의 초반에 강사가 한 마디를 덧붙였다: “Replit에 비용을 지불하고 싶지 않다면 Glot.io를 써보세요.” 그래서 나는 해봤다.
Glot은 디자인이 그다지 예쁘지는 않았지만 무료였고, 수십 개 언어를 마찰 없이 실행했으며, 자신이 해야 할 일 외에 다른 걸 시도하지 않았다. 나는 대부분의 연습문제를 그곳에서 해결했다—강의 예제를 복사하고, 수정하고, 일부러 깨트려 보면서 왜 그런지 이해했다. 바로 플레이그라운드가 해야 할 일을 해냈다.
몇 년 뒤 도구를 다시 살펴보기
시간이 흘러 기본 개념을 다시 복습하고 싶었다—인증 준비와 인터뷰 대비를 위해. 그래서 같은 도구들을 찾았다.
먼저 Replit을 켰다. 예전 모습이 떠올라서 혹시 개선됐을까 싶었다. 변화는 있었지만, 내가 기대한 방향은 아니었다. 사이트에 들어서자마자 채팅 인터페이스가 나타났다: AI 코딩 어시스턴트였다. 또 다른 AI에게 “Replit에 무슨 일이 있었나요?”라고 물었더니, 전환 이유를 설명하고 PlayCode.io를 대안으로 추천했다.
PlayCode.io 역시 챗봇 형태였다. 나는 코드를 대신 써줄 에이전트를 찾는 게 아니라, 생각하는 연습을 하고 싶었다. 두 목적은 완전히 달랐다.
Glot.io로 돌아가기
그래서 다시 Glot.io로 갔다. 아직 살아 있었고, 여전히 무료였으며, 내가 저장해 둔 연습문제도 있었다. 하지만 언어 런타임은 몇 년째 업데이트되지 않았다. 최신 파이썬이나 활발히 진화하는 언어를 시험하고 싶다면 Glot은 더 이상 선택지가 아니었다. 이해는 한다. 수익 모델 없이 무료 실행 인프라를 유지하는 건 정말 힘든 일이다. Glot은 오랫동안 해냈고 그 점은 칭찬받아 마땅하지만, 내가 필요로 하는 것을 제공하지는 못했다.
플레이그라운드가 AI로 전환한 이유
핵심은 이렇다: AI로 전환한 플레이그라운드들은 무작위로 그렇게 된 것이 아니다. 논리가 있었다.
- 이 플랫폼들은 이미 가장 어려운 부분—클라우드에서 안전하게 코드를 대규모로 실행할 수 있는 인프라—를 구축해 두었다. 이는 정말 만들기 힘든 기술이다.
- 인프라를 구축하면서 동시에 사용자들이 작성한 방대한 코드를 축적했다.
동시에 시장은 명확한 신호를 보냈다. 대부분의 사람들은 코딩을 배우고 싶어 하지 않는다; 앱을 원한다. 기술자와 비기술자 사이에는 언제나 보이지 않는 장벽이 있었다—DNS 설정, 배포 파이프라인, 프로토타입과 실제 사용자에게 제공되는 제품 사이의 차이 등. 그 장벽은 실제로 존재했고, 좋은 아이디어가 제품이 되는 것을 막았다.
AI가 등장해 “todo 앱을 만들어줘” 라고 하면 바로 실행 가능한 결과물을 제공할 수 있게 되자, 플레이그라운드들은 명백한 선택지를 보았다: 이미 갖춘 인프라 위에 AI 레이어를 얹고, 코드를 직접 작성하고 싶어 하는 거대한 시장에 바로 판매하자.
이것은 냉소적인 판단이 아니라 합리적인 판단이다. 기업은 문제를 해결하기 위해 존재하는데, 그들이 해결하려던 문제는 “코드를 실행하고 싶다”에서 “코드 없이 소프트웨어를 만들고 싶다”로 바뀌었다. 비즈니스 모델은 명확했다.
남겨진 격차
그 격차는 아무도 급히 메우지 않을 정도로 작아 보였지만, 나는 그 격차가 사소하다고 생각하지 않는다. “코드로 생각하고, 스스로 문제를 다루며, 실수를 통해 왜 동작하는지 이해한다”는 공간은 “AI에게 문제를 해결해 달라 요청한다”는 공간과 다르다. 두 경우 모두 활용도는 있지만, 오직 전자만이 정신 모델을 구축한다.
사람들이 거의 얘기하지 않는 점은 이렇다: 산업은 변했지만 채용 프로세스는 크게 변하지 않았다. 기술 인터뷰는 여전히 진행되고, 인증도 여전히 가치가 있다. 기업은 여전히 화이트보드에서 문제를 풀어보거나 최소한 그 능력을 보여주길 기대한다. AI가 이제 모든 편집기에 내장됐지만, 문을 통과하기 위한 기준은 사람들이 생각하는 것만큼 크게 움직이지 않았다.
솔직히 말하면, 그 이유가 있다. AI에 의해 대체되는 사람들은 AI에게 사고를 맡긴 사람들이다. AI를 도구로 활용해 더 나아가려는 사람들은 살아남는다. 이 격차는 ‘이해’에서 비롯되며, 이해는 코드를 직접 쓰고, 문제를 풀고, 때로는 스스로 어려움을 만들면서 얻는다.
여러 언어의 가치
그래서 나는 여러 언어를 섞어 쓰고 싶었다. 새로운 프로그래밍 언어를 배우는 자체가 일종의 정신 운동이다—익숙한 문제를 다른 시각으로 보게 만든다. 난해한 언어는 그 효과를 더욱 극대화한다: 예를 들어 Brainfuck으로 의미 있는 코드를 짤 수 있다면, C에서 포인터와 스택 할당을 다루는 것이 덜 추상적으로 느껴진다. 더 어려운 퍼즐을 풀면 일반 퍼즐이 쉬워지는 것과 같다. 커스텀 인터프리터를 지원하는 것도 같은 원리다—아주 작은 언어라도 만들면 모든 언어를 보는 시각이 바뀐다.
Babelpad.dev 소개
바로 babelpad.dev다. 여러 언어, 심지어 특이한 언어까지 지원한다. 계정도 필요 없고, 에이전트도 없고, 마찰도 없다. 오직 코드와 출력만 있다.
개인적인 동기
예전에 학생들을 튜터링할 때, 문제 세트를 주고 큰 소리로 생각하도록 시켰다. 기억한 내용을 시험하기 위함이 아니라, 그들의 사고 과정을 관찰하기 위해서다. 이것이 바로 누군가의 정신 모델이 어디서 부서지는지, 어떻게 도와줄 수 있는지를 파악하는 유일한 방법이다.
알고리즘과 자료구조는 소프트웨어 개발에 동일한 역할을 한다. 패턴을 인식하고, 복잡성을 판단하며, 코드를 한 줄도 쓰기 전에 트레이드‑오프를 고민하게 만든다. 이는 AI가 만든 코드를 리뷰할 때, 혹은 에이전트가 제안한 아키텍처가 2년 뒤에 유지보수 악몽이 될지 판단할 때 꼭 필요하다.
실제 서비스에 레드‑블랙 트리를 직접 구현할 필요는 없다. 하지만 한 번도 다뤄보지 않은 사람은 언제 어떤 도구를 써야 할지, 혹은 잘못된 도구에 맞서야 할지를 알기 어렵다.
도구는 바뀌었지만, 근본적인 스킬은 변하지 않았다.
사용 방법
시도해 보고 싶다면: babelpad.dev
앞으로 다룰 내용
- Babelpad 뒤에 있는 기술 스택 (Svelte + Cloudflare + Piston)
- 난해한 언어와 내가 직접 인터프리터를 만들 수 있게 지원한 이유
- 프로그래밍 교육에 Babelpad를 어떻게 활용하고 있는지