같은 AI, 완전히 다른 경험
50년 경력 개발자 James Randall은 AI가 자신의 워크플로우에 들어온 뒤 코딩이 '공허해졌다'고 묘사했다. 반면 Homeworld 스튜디오 창립자 Alex Garden은 같은 기술을 쓰면서 새벽 2시에 예전의 설렘을 되찾았다고 말한다. 동일한 AI 도구, 극단적으로 다른 감정 반응. 이 간극은 도대체 어디서 오는 걸까.
dev.to에 게재된 분석 'Interface IS Cognition'은 이 질문에 날카롭게 답한다. 변수는 AI의 성능이 아니라 인터페이스가 만들어내는 인지 구조라는 것이다. 실제로 15개의 LLM을 동일 가중치로 두고 프롬프트 형식만 바꿨을 때 성능이 5~62퍼센트포인트 달라졌다는 연구 결과가 이를 뒷받침한다. 같은 모델, 같은 데이터—다른 인터페이스, 완전히 다른 결과. 인터페이스는 파이프가 아니라 틀(mold)이다.
'댄스'를 '벽'으로 만드는 인터페이스
해당 분석은 인터페이스를 네 가지 모드로 분류한다: Wall(벽), Window(창), Gate(문), Dance(춤). 이 중 가장 중요한 개념은 Dance다. 코드를 치면 즉시 컴파일러 피드백이 오고, 손가락이 움직이면서 사고가 깊어지는 그 흐름—Randall이 잃었다고 말한 것이 바로 이것이다. 그는 도구를 '사용'했던 게 아니라 도구와 '함께 생각'했다. 피아니스트가 손가락 위치가 아닌 화음으로 사고하듯이.
AI가 그 댄스를 끊어버렸다. 나쁜 AI라서가 아니라 너무 잘 하기 때문에. 프롬프트 작성 → AI 생성 → 결과 검토 → 승인이라는 세 단계 체크포인트가, 한때 끊김 없이 이어지던 창작의 흐름을 Wall 모드로 전환해버린 것이다. Hacker News의 한 댓글은 이를 "급여 인상도 없이 관리자로 승진된 것"이라고 표현했다. 생산량은 늘었지만 craft는 사라졌다.
Garden의 경험이 달랐던 이유는 그가 AI를 Dance 확장의 도구로 연결했기 때문이다. 체크포인트가 아니라 루프의 확장. 인터페이스 설계가 인지 경험 자체를 결정한다는 테제는 이처럼 매우 구체적인 수준에서 증명된다.
인터페이스 문제는 경험에서 끝나지 않는다
그런데 인터페이스의 설계 실패가 단순히 개발자의 감정적 경험에만 영향을 미친다면, 이는 절반짜리 문제다. 코드 품질까지 직결된다는 점이 더 심각하다. dev.to에 올라온 또 다른 글 'AI-Generated Backends Almost Always Get CORS Wrong'은 이 지점을 정확히 찌른다.
AI 코드 에디터가 기본으로 생성하는 Express 백엔드에는 app.use(cors())가 거의 반드시 들어간다. 설정 없이. 이는 모든 출처의 요청을 허용하는 와일드카드 정책으로, 인증이 없는 공개 API라면 무방하지만 JWT나 세션 쿠키가 붙는 순간 자격증명 탈취 벡터가 된다. 공격자가 evil.com에서 credentials: 'include'로 요청을 보내면, 사용자의 세션 정보가 그대로 빠져나간다.
왜 AI는 반복적으로 이 패턴을 생성할까. 학습 데이터가 보안 의식이 낮았던 시절의 Stack Overflow 답변과 튜토리얼 코드로 가득 차 있기 때문이다. AI는 '즉시 작동하고 많이 추천받은 코드'를 최적화 기준으로 삼는다. 보안 취약점은 유닛 테스트에서 걸리지 않는다. 인시던트 리포트에서 걸린다. 수정 자체는 세 줄이면 된다—하지만 그걸 알아야 고칠 수 있다.
프로덕션 현실: AI 코드 비율은 얼마나 될까
그렇다면 실제 현장에서 AI가 생성한 코드는 얼마나 프로덕션에 반영되고 있을까. 'Reality Check: How Much AI-Generated Code Is Actually Used in Production'이라는 글에서 한 개발자는 솔직한 수치를 공유한다. 사이드 프로젝트에서는 75%, 실무에서는 약 25%.
차이를 만드는 건 코드베이스의 상태다. 아키텍처가 명확하고 최신 스택을 쓰는 프로젝트에서는 SQL 생성, 유닛 테스트 초안, 보일러플레이트 코드 작성에서 AI가 확실히 힘을 발휘한다. 반면 레거시 시스템—숨겨진 의존성, 산재한 비즈니스 룰, 10년 이상 된 .NET Framework 코드베이스—에서는 AI가 거의 도움이 안 된다. 컨텍스트 이해가 문법 생성보다 훨씬 중요한 환경이기 때문이다.
"AI가 곧 대부분의 코드를 쓸 것"이라는 과대 서사와 실무 현장 사이의 간극은 여전히 크다. 하지만 그 간극이 AI의 능력 문제만은 아니다. AI를 어떤 인터페이스로 연결하느냐—어떤 컨텍스트를 제공하고, 어떤 플로우로 통합하느냐—가 실질적인 활용률을 결정한다.
인터페이스 설계자가 쥔 진짜 레버
세 가지 이야기가 하나의 테제로 수렴한다. AI 도구의 실력은 모델이 아니라 인터페이스가 결정한다. 인터페이스가 창의적 흐름을 끊으면 개발자는 댄서에서 관리자로 강등된다. 인터페이스가 보안 컨텍스트를 생략하면 잘 작동하는 취약한 코드가 생산된다. 인터페이스가 레거시 코드베이스의 맥락을 전달하지 못하면 AI는 무용지물이 된다.
이는 프론트엔드 개발자—특히 AI 도구를 설계하거나 팀에 도입하는 사람—에게 구체적인 질문을 던진다. 지금 당신의 AI 워크플로우는 Wall인가, Dance인가? 프롬프트 창 하나로 모든 것을 처리하는 구조라면, 그것이 만들어내는 체크포인트 단절을 인식하고 있는가? CORS 같은 보안 컨텍스트를 AI가 기본적으로 인식하도록 시스템 프롬프트나 린터를 설계했는가?
모델 성능 경쟁은 계속될 것이다. 하지만 같은 모델도 어떻게 래핑하느냐에 따라 62퍼센트포인트 차이가 난다면, 진짜 차별화는 인터페이스 레이어에 있다. AI 도구를 고르는 시대에서, AI 경험을 설계하는 시대로—그 전환점에 우리는 지금 서 있다.