AI 코딩 도구는 인디 개발자의 미적 판단력을 대체할 수 없다

'In the Long Run'이 실제로 해결하려는 문제

_In the Long Run_은 Strava와 직접 연결되어 매우 단순해 보이지만 기발한 기능을 수행합니다. 사용자의 누적 주행 거리를 가져와 이를 유명한 실제 경로 — 대륙 횡단 트레일, 대륙 경로, 수천 킬로미터에 걸쳐 뻗어 있는 상징적인 장거리 회랑(corridors) — 를 따라 전진하는 진행 상황으로 매핑합니다. 각 운동을 독립적인 지표로 취급하는 대신, 이 앱은 모든 달리기를 대륙을 가로지르는 또 하나의 발걸음으로 재배치합니다.

동기 부여의 논리가 곧 실제 제품입니다. 기록이 저조한 한 달을 보낸 러너라도 뒤처지는 것이 아닙니다. 그들은 여전히 가상으로 국가를 횡단하는 과정의 중간 어딘가에 있으며, 그 위치는 초기화되지 않습니다. 전통적인 피트니스 트래킹은 연속 기록(streaks)을 축하하고 공백을 벌합니다. 이 앱은 누적된 노력이 성적표가 아닌 지리적인 이야기를 들려줄 때 러너들이 더 오래 몰입할 것이라는 데 승부수를 던졌습니다.

그 승부수는 실제 디자인 측면에서 결과로 나타납니다. 주요 인터페이스는 페이스 평균이나 주간 합계가 표시되는 대시보드가 아니라 인터랙티브 지도(interactive map)입니다. 사용자들은 지정된 경로를 따라 자신이 어디에 있는지 확인하며, 개발자는 이러한 지도에 경로를 따라 있는 랜드마크, 역사적 유적지, 주요 명소(points of interest)를 채워 넣고 싶어 했습니다. 이를 통해 러너들이 실제 주행 거리가 쌓임에 따라 기대하고 발견할 수 있는 무언가를 제공하고자 한 것입니다. 개발자가 개인적으로 잘 아는 경로의 경우, 해당 콘텐츠를 큐레이션하는 것은 간단했습니다. 하지만 생소한 국가와 지역을 가로지르는 경로의 경우에는 그렇지 않았습니다.

이 지점에서 제품은 데이터 엔지니어링 (Data Engineering)의 문제를 넘어 미적 (Aesthetic) 문제로 전환됩니다. 가상 러닝 진행 상황을 보여주는 인터랙티브 지도 (Interactive Map)는 무엇을 어떻게 드러내느냐에 따라 성패가 갈립니다. 무관한 핀들로 가득 찬 어지러운 지도는 여정의 느낌을 망칩니다. 반대로 너무 빈약한 지도는 탐험에 대한 보상을 제공하지 못합니다. 랜드마크를 선정하는 것 — 즉, 새로운 지역에 가상으로 막 진입한 러너에게 무엇을 보여줄 가치가 있는 것으로 간주할 것인가 — 은 그 어떤 정확도 지표 (Accuracy Metric)로도 측정할 수 없는 판단력을 요구합니다. AI가 대규모로 생성할 수 있는 것과 인간 큐레이터가 실제로 선택할 것 사이의 그 긴장감이야말로, _In the Long Run_의 개발 과정에서 유닛 테스트 (Unit Test)가 잡아낼 수 없는 문제에 부딪힌 지점이었습니다.

1인 인디 개발에서 자동화된 테스트의 한계

자동화된 테스트는 특정 범주의 실패를 잡아냅니다. 마일리지 추적 앱을 위한 테스트 스위트 (Test Suite)는 Strava에 기록된 47.3마일의 러닝이 가상 경로의 정확한 거리 표시로 변환되는지 확인할 수 있습니다. 하지만 대륙의 인터랙티브 지도 위에서 자신의 진행 점이 움직이는 것을 보는 것이 공허함이 아닌 성취감을 주는지까지는 확인할 수 없습니다.

그 차이가 바로 생산성 담론에서 좀처럼 인정하지 않는, 1인 인디 개발이 비용이 많이 드는 지점입니다. 한 명의 개발자가 제품을 출시할 때, '작동하는 것 (Working)'과 '좋은 것 (Good)' 사이의 모든 간극은 단 한 사람의 몫이 됩니다. 사용성 세션 (Usability Session)을 진행하는 UX 리서처도 없고, 어지러운 인터페이스에 반대하는 디자인 리드 (Design Lead)도 없으며, 아무도 요청하지 않은 기능이 사용자가 실제로 기대한 경험을 조용히 해치고 있다고 지적해 줄 포커스 그룹 (Focus Group)도 없습니다. 테스트 스위트는 통과(Green)되고, 빌드 (Build)는 배포되지만, 이것이 제대로 느껴지는지 물어볼 수 있는 유일한 사람은 그것을 만든 본인뿐입니다.

이것은 AI 보조 개발 (AI-assisted development) 및 자동화된 도구 (automated tooling)가 건드리지 못하는 구조적인 문제입니다. GitHub Copilot과 같은 도구들은 상용구 코드 (boilerplate)를 생성하고, 구현 방안을 제안하며, 명백한 논리적 오류를 잡아낼 수 있습니다. 하지만 이 도구들은 1인 개발자에게, 관심 지점 (points of interest)이 풍부하게 추가된 지도가 러너의 탐험 욕구를 고취시키는지, 아니면 제품이 의도한 집중력을 깨뜨릴 만큼의 시각적 노이즈 (visual noise)를 유발하는지를 말해줄 수는 없습니다. 그러한 판단 (judgment call)은 인간의 영역이며, 1인 운영 체제에서는 설계자 (architect), 엔지니어 (engineer), 제품 관리자 (product manager), 그리고 첫 번째 사용자 (first user)의 역할을 동시에 수행하는 단 한 명의 인간에게 속합니다.

인디 소프트웨어 커뮤니티는 AI 도구가 어떻게 개발 시간을 단축하고 출시 장벽을 낮추는지에 대해 광범위하게 이야기합니다. 두 주장 모두 타당합니다. 하지만 이 논의에서 간과되는 점은, 더 빠른 출시가 미적 및 경험적 결정 (aesthetic and experiential decisions)으로부터 도망치는 것이 아니라, 그러한 결정에 더 빨리 도달하게 된다는 사실입니다. AI 페어 프로그래밍 (pair-programming) 도구를 사용하는 1인 개발자들은 여전히 느낌 (feel), 톤 (tone), 계층 구조 (hierarchy), 그리고 정서적 공명 (emotional resonance)에 관한 모든 질문에 직면하며, 이는 숙련된 제품 팀이라면 여러 직군에 나누어 처리했을 문제들입니다. 생산성 향상은 실재합니다. 하지만 취향 (taste)에 대한 요구사항은 타협 불가능합니다. 그 어떤 자동화된 테스트 프레임워크 (automated test framework)도 제품이 사용하기에 만족스러운지를 검증 (asserting)할 수 있는 방법은 가지고 있지 않습니다.

여기서 AI 코딩 도구가 기여할 수 있는 것과 없는 것

AI 코딩 어시스턴트 (AI coding assistants)는 실제 개발 시간을 압축합니다. API 통합 설정, 데이터베이스 스키마 (database schemas) 연결, 인증 흐름 (authentication flows) 구축과 같이 과거에 몇 주씩 걸리던 상용구 작업들이 이제는 몇 시간 단위로 단축됩니다. 1인 인디 개발자에게 이러한 압축은 실질적이며 측정 가능한 이점입니다.

하지만 결정의 성격이 기술적인 영역에서 감각적인 영역으로 넘어가는 순간, 도구들은 명확한 한계에 부딪힙니다.

In the Long Run의 제작자가 자신의 러닝 앱(running app)에 관심 지점(points of interest)을 추가하며 무엇을 발견했는지 생각해 보십시오. 위치 정보를 가져오고, 응답을 구조화하며, 마커를 렌더링(rendering)하는 근본적인 데이터 파이프라인(data pipeline)은 AI가 효과적으로 가속화할 수 있는 작업의 전형이었습니다. 하지만 미적 레이어(aesthetic layer)는 완전히 다른 문제였습니다. 지도 핀(map pin)의 무게감은 어느 정도여야 할까요? 애니메이션이 갑작스럽게 느껴지지 않고 경쾌하게 느껴지려면 얼마나 지속되어야 할까요? 경로 선과 시각적으로 충돌하지 않으면서 '역사적 유적지'를 나타내는 색상은 무엇일까요? 이 질문들 중 그 어떤 것도 언어 모델(language model)이 프롬프트(prompt)로부터 도출할 수 있는 정답이 없습니다. 이 질문들은 충분히 많은 지도를 보고, 충분히 많은 앱을 사용하며, 기능과 형태의 교차점에서 무엇이 적절한지에 대한 본능을 개발한 인간을 필요로 합니다.

인디 빌더(indie builders)에게 위험한 점은 바로 속도(velocity)와 느낌(feel) 사이의 이러한 간극입니다. AI 보조 개발(AI-assisted development)은 빠른 출시(shipping)를 보상합니다. 피드백 루프(feedback loops)는 출력물을 강화합니다. 더 많은 기능, 더 빠른 속도, 더 깔끔한 코드 말입니다. 개발자는 그 추진력을 따라가며 모든 기능 테스트(functional test)를 통과하지만, 사용자를 다시 돌아오게 만드는 품질을 놓친 애플리케이션을 만들어낼 수 있습니다. 지도는 작동합니다. 데이터는 로드됩니다. 진행 상황 추적은 정확하게 계산됩니다. 하지만 제품은 여전히 공허하게 느껴집니다. 시각적 무게감(visual weight), 타이밍(timing), 또는 계층 구조(hierarchy)에 대해 누구도 의도적인 결정(deliberate calls)을 내리지 않았기 때문입니다. 이러한 결정들이 쌓여 사용자들이 '다듬어진(polished)' 상태라고 설명하는 경험을 만듭니다.

프롬프트 엔지니어링(Prompt engineering)은 이 문제를 해결하지 못합니다. 모델에게 색상 팔레트(color palette)나 애니메이션 지속 시간(animation duration)을 제안해 달라고 요청할 수 있습니다. 모델은 답을 줄 것입니다. 그 답은 통계적으로는 합리적일 것이나 미적으로는 평범할 것입니다. 취향(taste)은 평균을 내어 잘 나타나는 패턴이 아니기 때문입니다. 사람들이 실제로 사랑하는 제품을 출시하는 인디 개발자들은 기술적인 고된 작업(technical grind)을 제거하는 데 AI를 사용하고, 그렇게 확보한 시간을 도구가 내릴 수 없는 주관적인 결정(subjective calls)에 투자합니다. 이 두 번째 단계를 건너뛰는 빌더들은 작동은 하지만 무시당하는 제품을 출시하게 됩니다.

소프트 스킬이 아닌, 경쟁 우위로서의 취향 (Taste as a competitive moat, not a soft skill)

AI는 기능적인 소프트웨어를 구축하는 비용을 저렴하게 만들었습니다. 이제 프롬프트(Prompt)와 인내심만 있다면 어떤 개발자라도 몇 시간 만에 작동하는 CRUD 앱, 인증 흐름(Authentication flows), API 통합(API integrations)을 생성할 수 있습니다. 이러한 범용화(Commoditization)는 경쟁의 양상을 변화시킵니다. 누구나 작동하는 무언가를 출시할 수 있게 될 때, 질문은 '누군가가 그것을 사용하고 싶어 하는가'로 옮겨가며, 그 답은 취향(Taste)의 영역에 존재합니다.

취향은 단순한 장식이 아닙니다. 그것은 훌륭한 디자인이 어떤 느낌을 주는지, 그리고 왜 효과적인지를 연구하며 수년을 보낸 사람의 축적된 판단력입니다. 혼자서 제품을 만드는 인디 개발자들에게 취향은 독점적인 데이터셋(Proprietary dataset)이나 유통 우위(Distribution advantage)와 정확히 같은 방식으로 경쟁 우위(Competitive moat)로서 기능합니다. 기능적 동등성(Feature parity)을 달성하기 위해 프롬프트만 사용하는 경쟁자는 이를 복제할 수 없습니다.

1인 개발자가 만든 실행 중인 동기 부여 앱인 _In the Long Run_은 이를 정확히 보여줍니다. 이 앱은 Strava 주행 거리를 뉴질랜드 남섬의 길이, 유럽 대륙의 너비와 같은 유명한 실제 경로를 따라 진행 상황으로 표시하며, 그 진행 상황을 대화형 지도(Interactive maps)로 렌더링합니다. 그 이면의 엔지니어링은 복제 가능합니다. 디자인 측면에서의 질문은 다음과 같습니다. '이 지도가 당신으로 하여금 내일 아침 운동화 끈을 묶고 싶게 만드는가?', '스칸디나비아 해안선을 따라 조금씩 이동하는 당신의 점을 보는 것이, 힘든 한 주를 보낸 후에도 결국 앱을 다시 열게 만드는 정서적 끌림(Emotional pull)을 만들어내는가?' 이것은 미적(Aesthetic) 문제입니다. 어떤 테스트 스위트(Test suite)도 이를 잡아낼 수 없으며, 어떤 린터(Linter)도 이를 지적할 수 없습니다.

그러한 감각을 구축하는 개발자들은 의도적인 노출을 통해 이를 달성합니다. 정서적 반응을 일으키는 앱을 연구하고, 강력한 시각적 정체성(Visual identities)을 가진 제품 뒤에 숨겨진 결정들을 읽으며, 왜 그런지 설명할 수 있기 전에 무언가가 적절하다고 느껴지는 직관을 기를 수 있을 만큼 충분히 많은 것을 만들어냅니다. 그 과정은 수년이 걸립니다. AI 어시스턴트는 지도 타일 구성(Map tile configurations)을 생성하고 색상 팔레트(Color palettes)를 제안할 수는 있지만, 새벽 6시에 휴대폰을 바라보며 이 앱에 한 달을 더 헌신할 가치가 있는지 고민하는 러너의 체감된 경험(Felt experience)에는 접근할 수 없습니다.

향후 5년 동안 제품을 차별화할 인디 빌더(Indie builders)들은 AI를 가장 효율적으로 사용하는 사람들이 아닙니다. 그들은 AI를 기능적인 스캐폴딩(Scaffolding, 구조 구축)을 처리하는 데 사용하면서, 모델이 시뮬레이션할 수 없는 단 하나의 기술에 자신의 시간을 투자하는 사람들입니다.

AI 보조 빌더들의 차세대 실무적 시사점

AI 보조 코딩 도구를 사용하는 인디 개발자들은 자신의 워크플로(Workflow)에서 명확한 선을 그어야 합니다. 한쪽은 구축(Building)을 위한 것이고, 다른 한쪽은 판단(Judgment)을 위한 것입니다. 구축(Build-it) 단계는 AI가 진정으로 모든 것을 가속화하는 지점입니다. 기능의 스캐폴딩(Scaffolding), 보일러플레이트(Boilerplate) 생성, 데이터 파이프라인 처리, 로직 디버깅(Debugging) 등이 여기에 해당합니다. 이러한 작업은 모델에 맡기고 더 빠르게 출시하십시오. 하지만 '제대로 느껴지게 만드는(Make-it-feel-right)' 단계 — 어떤 지도 마커가 시각적 무게감을 가져야 하는지, 어떤 데이터 포인트가 화면 공간을 차지할 자격이 있는지, 어떤 상호작용이 단순한 기능적 동작을 넘어 보람차게 느껴질지 결정하는 단계 —는 인간의 영역으로 남습니다. 이 경계를 흐리는 것이 바로 AI 보조 1인 개발이 조용히 실패하는 지점입니다.

실제 Strava 주행 거리를 유명한 세계 경로와 매핑하는 가상 러닝 앱인 'In the Long Run'을 구축한 경험은 이를 정확히 보여줍니다. AI는 대규모로 후보 랜드마크와 역사적 장소들을 찾아낼 수 있습니다. 하지만 경험이 산만하거나 임의적으로 느껴지지 않도록 어떤 장소가 지도에 포함되어야 할지를 결정할 수는 없었습니다. 그러한 큐레이션적 결정(Curatorial call)에는 제품이 어떤 느낌을 주어야 하는지에 대한 구체적인 비전을 가진 개발자가 필요했으며, 그 어떤 자동화된 검증 단계도 이를 대체할 수 없었습니다.

실제 사용자에게 조기에 출시하는 것은 미적 결정에 대한 유일하고 신뢰할 수 있는 피드백 루프(Feedback loop)로 남아 있습니다. 내부 테스트는 기능이 작동하는지 알려줍니다. 사용자 행동은 그것이 공감을 불러일으키는지 알려줍니다. 이 두 가지 사이에는 도구를 통한 지름길이 없습니다. 실제 러너들이 지도와 어떻게 상호작용하는지 — 무엇을 탐색하고, 무엇을 무시하며, 어디에서 이탈하는지 —를 관찰하는 것은 프롬프트(Prompt)가 생성할 수 없는 신호(Signal)를 만들어냅니다.

AI 도구 산업은 잘못된 대화를 나누고 있습니다. 지배적인 담론은 AI가 이제 개발자를 위해 무엇을 할 수 있는지에 집중합니다: 테스트 작성, 컴포넌트(Component) 생성, 문서 요약 등 말입니다. 한참 뒤처진 대화는 개발자가 여전히 스스로 소유해야 하는 것이 무엇인지에 대해 묻습니다. 미적 판단력(Aesthetic judgment), 제품에 대한 취향(Product taste), 그리고 제품이 실제로 무엇을 위한 것인지에 대한 결정 — 이것들은 여전히 이전할 수 없는 기술로 남아 있습니다. AI를 강력한 실행 계층(Execution layer)이 아닌 완전한 창의적 파트너로 취급하는 개발자들은, 작동은 하지만 사람의 마음을 움직이지는 못하는 제품을 출시하게 될 것입니다. 이러한 환경에서 번창하는 인디 빌더(Indie builders)들은 프로세스의 모든 단계에서 자신이 어떤 역할을 수행하고 있는지 의식하며 머무는 사람들입니다.

원문은 Newzlet에 게시되었습니다.