AI 시대의 프로토타이핑 속도
출처: Hacker News
소개
AI 시대의 프로토타이핑 속도
2026년 5월 31일 일요일 · 7 분
주의: 이것은 지난 1년 동안 내 작업 흐름이 어떻게 변했는지에 대한 개인적인 성찰이며, 어떤 도구를 홍보하기 위한 것이 아닙니다. 여러분의 상황은 (그리고 아마도 그래야 할) 다를 것입니다.
몇 년 전 나는 버려지는 프로토타입에 대한 애정을 글로 남겼었습니다; 아이디어를 머리에서 꺼내어 눈에 보이는 형태로 만들기 위한 작은 증명‑개념들 말이죠. 그때 가장 큰 병목은 나였어요—프로젝트를 뼈대 잡고, 지루한 부분들을 연결하고, 흥미로운 부분을 실제로 테스트할 수 있는 단계에 도달하는 데 걸리는 시간 말이죠. 이제는 그 병목이 거의 사라졌습니다.
이 이야기를 쓰는 것이 조금 망설여졌습니다. 이미 AI에 대한 조심스러운 생각을 공유했고, 그 내용에 전적으로 동의합니다. 업계가 실시간으로 방향을 잡아가고 있다는 점과 조심하는 것이 여전히 중요하다는 점은 변함없어요. 하지만 조심한다고 해서 눈을 감는 것은 아니며, 솔직히 말해서 AI 덕분에 “혹시 …일까?” 에서 “아, 작동한다.” 로 전환하는 속도가 크게 빨라졌습니다.
최근 저장소들
최근 내 GitHub 를 살펴보았다면, 새 저장소들이 연속해서 뜨는 것을 보았을 겁니다:
| 저장소 | 설명 |
|---|---|
| Sakoa | 처음부터 설계하고 있는 진행형 시스템 언어로, 효과 시스템, 세 가지 메모리 모드, 그리고 다중 백엔드를 지원하는 MIR을 포함합니다. |
| Kato | JSON, TOML, YAML 사이 어딘가에 위치하는 표기 언어로, 인간과 에이전트 모두에게 친숙하도록 명시적으로 설계되었습니다. |
| Seal | 비밀을 OS‑네이티브 자격증명 저장소에 보관해 .env 파일을 조용히 없애는 작은 CLI 도구입니다. |
| Karabiner | iOS‑우선, 에이전트‑네이티브 메신저 앱입니다. |
| Plim | 프레임워크에 구애받지 않는 코어와 React 바인딩을 갖춘, 웹용 Notion‑스타일 임베디드 블록 에디터입니다. |
| …그리고 아직 스포트라이트를 받을 준비가 안 된 몇몇 저장소가 더 있습니다. |
몇 년 전이라면 그 목록은 README가 있는 세 개의 저장소, 두 개의 포기된 브랜치, 그리고 내가 조용히 자랑스러워하는 하나의 작동 프로토타입 정도였을 겁니다. 지금은? 프로토타입이 존재합니다. 실행됩니다. 테스트가 있는 것도 있고, 몇몇은 실제 프로젝트처럼 보이기 시작했습니다. 모두가 진지한 제품이 되지는 않겠지만(그게 바로 핵심 포인트입니다), 아이디어를 시도할 수 있다는 자체가 큰 만족감을 줍니다.
넓게 보기
아무도 나에게 경고하지 않은 사실은 AI가 속도뿐 아니라 엔지니어링 작업의 형태 자체를 바꾼다는 점입니다. 내가 매 줄을 직접 타이핑하지 않을 때, 사고 방식이 달라집니다. 경계, 계약, 그리고 조각들이 어떻게 맞물리는지를 고민하게 됩니다. 시스템이 존재하기 전에 전체를 설명하는 프롬프트와 사양을 작성하게 되죠.
이 변화는 작아 보이지만 조용히 혁신을 일으켰습니다. 문제를 해결하기 전에 추상적인 수준에서 계획하고, 에이전트와 사람 모두에게 작업을 위임하는 능력이 눈에 띄게 향상되었습니다. “성공이 어떤 모습인지 정확히 설명해, 방 안에 내가 없어도 주니어 엔지니어나 모델이 행동할 수 있게 하는” 기술은 양쪽 모두에 동일하게 적용됩니다. 비전을 공유하고, 작업을 쪼개며, 어디서 문제가 생길지 미리 예측하는… 이런 근육들을 이제는 훨씬 의식적으로 단련하고 있으며, 그 덕분에 더 강해졌습니다.
생산성에 관해서
나는 이 변화를 꽤 오래전부터 대강 추적해 왔습니다—주로 호기심 때문이죠. 일상적인 엔지니어링 작업을 (대략적인 PR까지 걸리는 시간으로) 측정했을 때, 에이전트가 작업 흐름의 의미 있는 일부가 된 이후 4배 정도 빨라졌습니다. 어떤 날은 더 빠르고, 어떤 날은 덜 빠르며, 가끔은 에이전트가 기묘하게 행동해 되돌리는데 한 시간을 소비하기도 합니다(그 시간도 평균에 포함합니다).
하지만 이 숫자는 더 흥미로운 효과를 과소평가합니다: 내가 맡을 수 있는 작업 종류가 바뀐 겁니다. 이전엔 “괜찮은 아이디어지만 시간 없어서 미루자”라고 넘겼던 일들이 이제는 오후 한 편에 들어갑니다. 고통스러웠던 리팩터링도 이제는 감당할 수 있습니다. 시도 비용이 충분히 낮아져서, 문서로 논쟁하던 아이디어들을 바로 실험해 볼 수 있게 됐습니다.
속도의 대가
모두가 장점만은 아닙니다. 생산성을 높여주는 그 속도는 내가 코드를 직접 타이핑하는 양을 줄였고, 그 결과 내 기술적 손재주를 유지하려면 의식적인 노력이 필요해졌습니다. 도구가 모든 일을 다 해버리면 안 된다는 거래를 하고 싶지 않으니까요. 나는 내가 작업하는 것이 실제로 어떻게 동작하는지 알고 싶습니다.
그래서 의도적으로 수작업을 하는 시간을 만들고 있습니다:
- 손으로 엔드‑투‑엔드 구현하기.
- 요약을 요청하지 말고 직접 소스 코드를 읽기.
- 스택 트레이스를 채팅에 붙여넣기보다 디버거와 마주하기.
느리고 때때로 답답할 수 있지만, 내 정신 건강과 “AI가 충분하지 않을 때엔 실제 엔지니어가 필요하다”는 현실을 위해 꼭 필요합니다.
반대편은 훨씬 즐겁습니다. 새로운 속도 덕분에 탐구, 학습, 프로토타이핑에 시간을 할애하기가 놀라울 정도로 쉬워졌