지금 프론트엔드 개발자와 프로덕트 빌더 앞에는 두 가지 선택 문제가 동시에 놓여 있다. 하나는 익숙한 질문이다. 어떤 기술 스택을 골라야 팀이 더 빠르게 움직일 수 있을까. 다른 하나는 낯선 질문이다. 내가 만든 제품을 AI가 사용자에게 추천할까. 흥미로운 건, 이 두 질문의 해답 구조가 놀랍도록 닮아 있다는 점이다.
기술 선택의 진짜 적은 '잘못된 기술'이 아니다
dev.to에 올라온 한 글은 기술 부채(tech debt)의 본질을 다르게 정의한다. 대부분의 기술 부채는 사실 '믿음 부채(belief debt)'라는 것이다. 팀이 실제 문제가 아니라, 한때 유효했거나 어딘가에서 읽은 '정답'을 관성적으로 고수하면서 발생하는 비용이다. Nir Eyal의 프레임을 빌리자면, 믿음은 진리가 아니라 도구다. 기술 스택도 마찬가지다.
이 글이 제안하는 기술 신념 감사(audit) 기준 다섯 가지는 단순하지만 날카롭다. 유용한가, 검증됐는가, 변경 가능한가, 정직한가, 자유를 주는가. 예컨대 '우리는 React 팀이니까 React를 쓴다'는 선언은 개방성 필터를 통과하지 못한다. 반면 'React가 지금 우리에게 맞지만, HTMX로 이 기능을 2일 안에 뽑을 수 있다면 HTMX를 쓴다'는 태도는 기술을 도구로 다루는 것이다.
이 프레임을 AI 도구 선택에 그대로 적용해보면 어떨까. 'Cursor를 써야 한다, 업계 표준이니까'가 아니라 '이 도구가 지금 우리 팀의 컨텍스트 전환 비용을 줄여주는가'를 먼저 물어야 한다. Claude, Copilot, v0.dev를 동시에 쓰는 팀이 있는가 하면, 하나도 안 쓰는 팀도 있다. 중요한 건 도구의 명성이 아니라, 지금 이 팀의 핵심 루프를 더 빠르고 단순하게 만드는가다. 검증되지 않은 '베스트 프랙티스'를 붙들고 있는 순간, 그것은 이미 기술이 아니라 믿음 부채다.
AI가 추천하는 시대, 발견 가능성이 곧 제품 설계다
반대편 이야기를 보자. Mac 앱 Brow의 개발자는 어느 날 자신의 앱 유입 리포트에서 처음 보는 행을 발견했다. chatgpt.com. 누군가 ChatGPT에게 'Mac에서 메뉴바 정리할 수 있는 앱 뭐 써?'라고 물었고, AI는 Brow를 이름과 링크까지 포함해 추천했다. 아무 광고도, 어떤 제안서도 없었다.
수치는 5일간 30건의 다운로드. 크지 않다. 하지만 이 개발자가 주목한 건 규모가 아니라 행동 패턴이다. Google 검색 트래픽은 '아직 쇼핑 중인 사람'을 데려온다. ChatGPT 트래픽은 '이미 추천을 신뢰한 사람'을 데려온다. 전환율 구조 자체가 다르다. 더 결정적인 건, 이전까지 이 채널의 수치는 완전한 제로였다는 사실이다. 0에서 무언가가 된 것, 그것이 진짜 변화다.
AI가 Brow를 알게 된 경로는 단순하다. 공개 웹—앱 사이트, App Store 페이지, 블로그 포스트, Reddit 스레드—에서 학습한 것이다. 모델은 인터넷의 의견을 압축해 한 문장으로 돌려준다. 그렇다면 'AI에게 추천받는 최적화'는 어떤 모습일까. 이 개발자의 답은 본질적으로 오래된 원칙으로 수렴한다. 크롤러가 읽을 수 있는 페이지에 앱이 무엇인지 명확하게 써라. 진짜 언급을 만들어라. 키워드 스터핑은 오히려 역효과다.
선택하고 선택받는 구조는 하나의 원리로 수렴한다
두 이야기를 겹쳐보면 공통된 설계 원리가 드러난다. 실제 문제를 해결하는가, 지금 이 맥락에서 작동하는가, 정직하게 측정되고 있는가.
기술 선택에서 'Kubernetes는 업계 표준이니까'라고 말하는 팀이, 제품 마케팅에서 '좋은 제품이면 알아서 발견되겠지'라고 방치하는 팀과 같은 실수를 저지르고 있다. 반대로, '$5 VPS로 1만 유저를 감당하고 스케일링 문제가 생길 때 K8s를 도입한다'고 말하는 팀은, AI 추천 채널을 직접 모니터링하고 어떤 프롬프트에서 자신의 제품이 언급되는지 추적하는 팀과 같은 사고방식을 가지고 있다. 도구를 관성이 아닌 증거로 다루는 것이다.
프론트엔드 개발자가 지금 설계해야 할 것
Brow 개발자는 로그아웃된 시크릿 세션으로 ChatGPT에 직접 질문해보라고 조언한다. 자신의 계정으로 물으면 AI는 이미 당신을 알고 있어서 왜곡된 답을 내놓는다. 낯선 사람의 시점으로 묻는 것이 유일하게 신뢰할 수 있는 테스트다. 이 조언은 기술 선택에도 그대로 유효하다. 팀 내부의 익숙함이 아니라, 실제 사용자의 경험이라는 차가운 시점으로 기술 선택을 재심해야 한다.
AI가 코드를 생성하고 제품을 추천하는 시대에, 개발자에게 남는 핵심 역량은 무엇인가. 결국 판단이다. 어떤 믿음이 지금 유효한가, 어떤 신호가 의미 있는가, 어떤 구조가 지속 가능한가. AI 도구를 선택하는 기준도, AI에게 선택받는 조건도, 그 판단의 질에서 갈린다. 기술은 느슨하게 쥐어라. 사용자는 단단하게 붙들어라. 이 원칙은 스택 선택에도, 제품 발견 전략에도 동일하게 적용된다.