AI 코딩 도구가 프로젝트를 너무 쉽게 바꾸게 만들었습니다

AI 요약

글쓴이는 공개 GitHub 저장소만 84개라고 밝힙니다. 오래된 실험과 중단한 프로젝트까지 포함한 숫자지만, AI 코딩 도구가 새 아이디어를 곧바로 코드로 옮기는 일을 얼마나 쉽게 만들었는지 보여주는 사례입니다. 원래도 새 아이디어에 쉽게 끌리는 성향이 있었지만, AI가 그 성향을 만든 것은 아닙니다. 시작을 막아 주던 마찰을 크게 줄였다는 게 글쓴이의 설명입니다.

시작 비용이 낮아졌습니다

예전에는 아이디어가 떠올라도 라이브러리를 조사하고 문서를 읽거나, 낯선 프레임워크를 배울지 따져야 했습니다. 그 과정에서 흥미가 식으면 시작하지 않는 경우도 있었습니다. 이제는 터미널 MIDI 플레이어가 있으면 좋겠다는 생각을 한 뒤 10분 만에 Rust 프로젝트를 만들고 Ratatui 인터페이스와 MIDI 재생을 시험할 수 있습니다. 설정과 보일러플레이트를 붙잡는 시간이 줄면서 낯선 기술이나 작은 도구도 직접 시도하기 쉬워졌습니다.

글쓴이는 Rust, 터미널 UI, 로컬 AI 모델, MCP 서버, 데스크톱 앱, 브라우저 API, 이미지·오디오 도구 등을 실험했습니다. 일부는 실제 프로젝트가 됐고, 일부는 배움이나 검증을 마친 뒤 한 저녁 만에 멈췄습니다. 빠르게 만들어 본 뒤 아이디어가 생각만큼 흥미롭지 않다는 사실을 알아내는 일도 실패가 아니라 프로토타입의 역할이라고 봅니다.

시작은 빨라졌지만 마무리는 그대로입니다

문제는 새 프로젝트의 시작과 완성 사이에 있던 필터가 얇아졌다는 점입니다. 작업 중 생긴 작은 불편이 새 도구 아이디어로 이어지고, AI 코딩 에이전트가 가능하다고 답하면 곧바로 새 저장소를 만들게 됩니다. 특히 기존 도구가 거의 마음에 들지만 한 가지가 아쉽다는 생각은 새 프로젝트를 시작하게 만드는 흔한 계기입니다. 기존 작업은 터미널 탭에 남겨 둔 채 새 아이디어로 옮겨 가기도 합니다.

AI는 프로젝트를 0%에서 30%까지 빠르게 끌어올립니다. 그러나 그쯤 되면 다음 아이디어가 매력적으로 보이기 쉽습니다. 시작 단계에는 새로 만드는 재미가 있고, 구조도 깨끗하며, 사용자의 버그 신고나 예외 상황도 아직 없습니다. 반면 마무리 단계에는 지루한 버그 수정, 엣지 케이스 처리, 문서 작성, 테스트, 패키징, 배포, 접근성 점검과 의존성 업데이트가 기다립니다. AI가 이런 일을 도울 수는 있어도 새 프로젝트를 시작하는 재미까지 대신 만들어 주지는 않습니다.

실험과 프로젝트를 구분합니다

글쓴이는 새 프로젝트를 시작하지 말자고 주장하지 않습니다. 모든 저장소가 제품이 되거나 사용자를 모을 필요는 없습니다. 라이브러리를 배우거나 아이디어가 가능한지 확인하려고 만든 도구도 가치가 있습니다. 다만 아이디어를 탐색하는 일과 계속 유지할 프로젝트를 시작하는 일은 다르게 취급하자고 제안합니다. 프로토타입을 자유롭게 만들되, 무엇을 계속할지는 더 신중히 고르는 방식입니다.

실험이 궁금증을 풀었거나 아이디어가 충분히 강하지 않다고 드러났다면 저장소를 보관해도 됩니다. 반대로 며칠 뒤 다시 열었을 때도 계속 만들고 싶다는 마음이 든다면, 처음 떠올랐을 때의 흥분보다 나은 지속의 신호일 수 있습니다. 글쓴이는 자신이 AI 때문에 만성적인 프로젝트 시작자가 된 것은 아니라고 말합니다. 원래 그랬고, AI는 삽을 더 빠르게 쥐여 줬을 뿐이라고 덧붙입니다.

dev.to 반응

• @deanlee — 시작에 드는 활성화 에너지가 낮아지면 시작과 완성의 선택 가치가 달라집니다. 익숙하지 않은 스택의 기본 틀을 만드는 데 노력이 필요할 때는 그 마찰이 진입 장벽처럼 작동해, 지속해서 집중할 가치가 낮은 호기심을 걸러냅니다. 에이전트가 보일러플레이트를 처리하면 85번째 저장소를 만드는 일은 새로움은 즉시 얻고 진입 비용은 들지 않는 사실상 공짜 선택권이 됩니다. 하지만 유지보수와 마무리 비용은 가파르게 늘어납니다. 버려진 프로토타입은 조금씩 머릿속 부담을 더하고, 초기 코드를 빠르게 만드는 재미는 출시를 끝내는 지루한 작업과 계속 경쟁합니다.
  • @sizzlebop — 정말 좋은 관점입니다. 이제 시작은 거의 너무 싸게 느껴지지만, 마무리에는 예전처럼 집중력과 꾸준함이 듭니다. 버려 둔 프로토타입이 주는 인지적 부담도 실제로 큽니다. 규모가 작아도 머릿속 한구석에 계속 남아 있습니다. 고맙습니다. 제가 설명한 긴장 관계를 어떤 부분에서는 저보다 더 잘 풀어 주셨습니다.
• @sinarezaei — 흥미로운 점은 AI가 프로젝트를 더 많이 시작하게 한다는 사실 자체가 아니라, 탐색 비용을 바꾼다는 점입니다. 예전에는 스택을 배우고 환경을 설정하고 문서를 읽는 마찰이 많은 아이디어를 자연스럽게 걸러냈습니다. 이제는 몇 시간 만에 아이디어를 시험하고 계속할 가치가 있는지 판단할 만큼 근거를 얻습니다. 예를 들어 대시보드 아이디어가 있으면 Next.js, API, 데이터베이스를 붙여 작동하는 버전을 만들어 볼 수 있습니다. 실험 결과 상호작용 방식이 마음에 들지 않으면 나머지 시스템을 몇 주 동안 만들지 않고도 그만둘 수 있습니다. 문제는 성공한 프로토타입을 계속하겠다는 약속으로 착각할 때 생깁니다. 저에게 유용한 구분은 자유롭게 탐색하고, 선택적으로 전념하는 것입니다. 프로토타입이 30%에 도달했다고 해서 반드시 미완성 프로젝트인 것은 아닙니다. 다음 70%를 투자할 가치가 없다는 점을 증명하는 데 30%면 충분할 때도 있습니다. AI가 그 과정을 빠르게 합니다. 어떤 실험을 시스템으로 발전시키고 어떤 실험을 보관할지 판단하는 일이 실제 역량이 됩니다.
  • @sizzlebop — 이 관점이 정말 마음에 듭니다. ‘탐색 비용’이라는 표현이 정확합니다. AI 덕분에 많은 시간을 쏟기 전에 아이디어가 실제로 흥미로운지 알아보기가 훨씬 쉬워졌습니다. 프로토타입과 약속을 구분하는 점도 중요합니다. 많은 사람이 여기서 헷갈리는 것 같습니다. 30%짜리 프로젝트가 전부 미완성 실패작은 아닙니다. 계속할 가치가 있는지 확인했다면 맡은 일을 다 한 셈일 수도 있습니다. ‘자유롭게 탐색하고, 선택적으로 전념한다’는 문장이 참 좋습니다.
• @ipvolt — ‘거의 원하는 대로인데, 한 가지가…’라는 대목이 제 얘기 같았습니다. 저도 지금 그러고 있습니다. 프록시 서비스를 출시하기까지 일주일 남았는데, 그사이에 ‘금방 만들면 되겠지’ 하며 사이드 도구 두 개를 내놨습니다. MCP 서버와 대역폭 측정기입니다. 둘 다 실제로 쓸모는 있었지만, 정작 주 제품은 아직 완성되지 않았습니다. 저장소가 84개라면 어떤 걸 끝까지 만들지 어떻게 고르시나요?
  • @sizzlebop — 솔직히 아주 체계적인 방법은 없습니다. 제가 계속 쓰고 유지할 만큼 유용하거나, 다른 사람이 쓰기 시작해 개선할 이유가 생기면 대개 마무리까지 갑니다. 나머지는 대부분 실험입니다. 알고 싶었던 걸 배웠거나 아이디어가 작동한다는 점을 확인했다면 그대로 둬도 괜찮습니다. 실제로 계속할 가치가 있는 일과 재미있는 우회로를 구분하는 게 더 어렵습니다. ‘금방 만들면 되겠지’ 하다가 사이드 도구 두 개를 내고 주 제품은 기다리게 한 상황은 너무 공감됩니다.
• @innokentyb — 실험과 약속을 구분할 때 ‘승격 계약’을 더할 수 있습니다. 프로토타입을 프로젝트로 바꾸기 전에 무엇을 알아냈는지, 다음에 되돌리기 어려운 비용이 무엇인지, 중단하거나 다시 검토할 날짜가 언제인지 적어 두는 방식입니다. 그렇지 않으면 ‘충분히 배웠다’와 ‘흥미를 잃었다’가 저장소 보관함에서 똑같아 보이고, 이름을 붙인 모든 프로토타입이 계속 주의를 요구합니다. 시작 비용이 낮은 건 가치가 있습니다. 빠진 장치는 제한된 프로젝트 예산 안에서 계속할지 경쟁하게 만드는 일입니다.
  • @sizzlebop — ‘승격 계약’이라는 생각이 정말 좋습니다. 필요한 걸 배운 경우와 그냥 흥미를 잃고 잊어버린 경우를 구분하는 데 유용할 것 같습니다. 이름을 붙인 프로토타입이 계속 주의를 요구한다는 말도 뼈아픕니다. 이름과 저장소, 아이콘까지 생기면 제 뇌는 그 프로젝트가 그럴 만한지 따지기도 전에 진짜 프로젝트처럼 취급합니다. 계속할 일을 한정된 주의력 안에서 경쟁시키는 게 제가 더 잘해야 할 부분일 것 같습니다.
• @dhruv_malaviya_cdcc71e595 — 활성화 에너지 관점이 맞습니다. 한 걸음 더 나가면 시작 비용은 10분의 1로 줄었지만 완성 비용은 그대로입니다. 그 비율 변화가 실제 문제입니다. 저장소 84개는 의지력이 약해서 나온 결과가 아니라 비용 곡선의 한쪽만 움직인 결과입니다. 그렇다고 예전 마찰을 되살릴 필요는 없습니다. 그럴 수도 없고, 그럴 필요도 거의 없습니다. 84개 중 일부 덕분에 Rust, 터미널 UI, MCP 서버를 배웠을 텐데 예전 필터는 그런 일도 막았을 겁니다. 그 필터가 무엇을 거르는지 현명하게 판단한 것도 아닙니다. 다시 넣을 마찰은 의도적인 마찰입니다. 코드를 쓰기 전에 완료 상태를 한 문단으로 적어 보세요. 명세서가 아니라, 나중에 그만둘 때 흐지부지된 것이 아니라 결정이었다고 말할 정도면 됩니다. 제가 볼 지표는 저장소 수가 아닙니다. 마무리에 드는 비용을 미리 알고도 오늘 시작할 프로젝트가 몇 개인지입니다. 그 수는 대개 84보다 훨씬 적고, 설계할 가치가 있는 지표입니다.
  • @sizzlebop — 그 구분이 정말 마음에 듭니다. 시작은 크게 쉬워졌지만 마무리는 그대로라는 점이 불균형을 만드는 것 같습니다. 예전의 마찰을 되돌리고 싶지 않다는 데도 동의합니다. 제가 배운 것 중 상당수는 예전 필터를 통과하지 못했을 프로젝트에서 나왔을 테니까요. 하지만 의도적인 마찰이라는 생각은 흥미롭습니다. 프로젝트의 반짝이는 부분에 너무 애착을 갖기 전에 ‘완료’가 무엇인지 정하는 것만으로도 도움이 될 것 같습니다. 무언가를 그냥 저장소 묘지로 흘려보내지 않고, 그만두기로 결정하는 일로 다루자는 생각도 특히 좋습니다.

원문: dev.to / 번역·요약: Trawling