Today, if your framework or documentation isn't in the training corpus of the LLM, then it won't be output. If the system prompt of the tool a developer uses doesn't have your API, library or framework, then it's not in the output.

두 명의 프론트엔드 개발자가 있다. 둘 다 동일한 로그인 폼을 구현해야 한다. 한 명은 Shadcn과 React Query를 사용하고, 다른 한 명은 사내에서 개발한 디자인 시스템을 사용한다. 결과물의 디자인과 기능은 완전히 동일하다. 그런데 첫 번째 개발자는 30분 만에 작업을 끝냈고, 두 번째 개발자는 아직도 LLM이 뱉어낸 환각 코드를 수정하고 있다.

AI 코딩 도구가 일상이 된 지금, 우리는 불편한 질문을 던져야 한다. 결과물이 동일하다면, 어떤 라이브러리를 선택하는 게 더 효율적인가?

자기 강화 피드백 루프

"LLM 학습 데이터에 없으면 존재하지 않는 것과 같다"는 명제가 있다. 원래는 프레임워크 수준에서 논의되던 이야기지만, 이 논리는 모든 라이브러리 수준으로 확장된다.

메커니즘은 단순하다. 대중적으로 사용되는 라이브러리는 웹과 GitHub에 코드 예제가 쌓인다. LLM은 이 데이터로 학습한다. Cursor, Copilot, v0 같은 AI 코딩 도구들은 학습된 라이브러리를 기본값으로 출력한다. 개발자들은 이 출력을 그대로 사용하고, 더 많은 코드가 웹에 쌓인다. 선순환이자 독점이다.

반대로 신규 오픈소스나 사내 라이브러리는 12개월에서 18개월 정도의 "존재하지 않는 기간"을 겪는다. 아무리 기술적으로 우수해도, LLM이 모르면 AI 코딩 도구의 도움을 받을 수 없다. 기술적 우수성과의 경쟁이 아니라 학습 데이터 내 통계적 빈도와의 경쟁인 셈이다.

구조적 비대칭

학습 데이터 관점에서 격차는 압도적이다. Tailwind나 React Query 같은 대중적 라이브러리는 수십만에서 수백만 개의 학습 예제를 갖고 있다. 다양한 맥락과 조합의 사용 패턴, Stack Overflow에 축적된 에러 해결 사례, 버전별 변화까지 학습되어 있다. 반면 비학습 라이브러리는 이 모든 항목이 0이거나 극히 제한적이다.

AI 코딩 도구들의 시스템 프롬프트도 이 편향을 강화한다. Cursor, Bolt, Replit, v0 같은 도구들은 시스템 프롬프트에 특정 라이브러리를 내장하고 있다. "작동하는 것"을 기본값으로 설정했기 때문이다.

출력의 질적 차이도 크다. 대중적 라이브러리를 사용하면 LLM은 확정적이고 관용적인 패턴의 코드를 자신 있게 출력한다. 비학습 라이브러리를 요청하면 추측 기반 출력, 환각, 잦은 수정이 필요한 코드가 나온다.

생산성 격차의 실체

개인 생산성 차원에서 격차를 측정하면 명확하다. 프롬프트를 입력하고 작동하는 코드를 얻기까지 걸리는 시간, 반복 수정 횟수, 디버깅에 소요되는 추가 노력 모두에서 대중적 라이브러리가 압도적으로 유리하다.

비학습 라이브러리를 사용하면 매 프롬프트마다 API 문서와 사용법을 명시적으로 주입해야 한다. LLM이 "창작"한 코드를 실제로 작동하는지 검증하는 추가 리뷰 부담이 생긴다. 일관성 없는 출력으로 코드 스타일이 파편화된다.

결론은 간단하다. UI/UX 구현 결과가 동일하다면 대중적 라이브러리 경로가 압도적으로 효율적이다. 비학습 라이브러리 선택은 "AI 생산성 세금"을 지불하는 것이다.

사내 디자인 시스템의 이중 부담

사내 디자인 시스템은 이 문제의 전형적인 사례다.

첫 번째 부담은 AI 생산성 저하다. "우리 디자인 시스템으로 버튼 만들어줘"라고 프롬프트를 입력하면 환각이나 거부가 돌아온다. "Shadcn으로 버튼 만들어줘"라고 하면 즉시 정확한 코드가 나온다. 사내 디자인 시스템은 LLM 학습 데이터에 단 하나의 예제도 없기 때문이다.

두 번째 부담은 팀 협업 프로세스의 병목이다. 프로젝트에서 UI 수정이 필요한 상황을 생각해보자. 기존 디자인 시스템과 충돌이 발생하면 디자인 시스템 담당자가 전체 가이드를 검토하고, 디자인 시스템 개발자가 시스템을 수정하고, 기존 시스템을 사용하는 다른 프로젝트들과 호환성을 검토한 뒤에야 원래 프로젝트에 적용할 수 있다.

프로젝트 개발자가 직접 UI를 수정하고 싶어도 권한과 구조적으로 불가능하다. "디자인 시스템을 건드리면 안 돼요"라는 암묵적 금기가 있다. 단순한 UI 수정에도 외부 의존성이 발생한다. 디자인 시스템 담당자는 피처 개발 지원에 급하게 투입되는 패턴이 반복되고, 본연의 업무인 시스템 고도화와 긴급 지원 사이에서 충돌한다. 한 사람의 일정이 여러 프로젝트를 블로킹하는 병목 인력이 된다.

대중적 라이브러리를 사용하면 프로젝트 개발자가 직접 Shadcn 컴포넌트를 수정하고 확장할 수 있다. 외부 의존성 없이 즉시 작업을 진행하고, LLM이 수정 방법까지 제안하니 자율적으로 문제를 해결한다.

AI 생산성 저하와 팀 프로세스 병목이 결합하면 복합적 비효율이 발생한다. 사내 디자인 시스템 고집의 숨겨진 비용은 예상보다 훨씬 크다.

전략적 선택지

첫 번째 선택지는 대중적 라이브러리 전면 채택이다. 즉각적인 AI 생산성, 개발자 자율성 확보, 병목 인력 제거라는 장점이 있다. 차별화 약화와 외부 의존성이라는 단점이 있지만, 스타트업이나 MVP, 속도 우선 프로젝트에 적합하다.

두 번째 선택지는 하이브리드 전략이다. 대중적 라이브러리를 기반으로 그 위에 커스터마이징 레이어를 얹는다. Shadcn을 포크하거나 Tailwind 위에 디자인 토큰을 매핑하는 식이다. 기반이 대중적 라이브러리이므로 개발자가 직접 수정할 수 있다. 브랜드 차별화와 AI 생산성 모두 필요한 경우에 적합하다.

세 번째 선택지는 RAG를 통한 비학습 라이브러리 주입이다. 사내 문서와 코드를 RAG로 LLM에 주입한다. 그러나 현실적 한계가 있다. 사내 라이브러리 전체 문서와 예제 코드는 매번 프론트엔드 코딩을 할 때마다 적지 않은 토큰을 차지한다. 선택적 검색 시 관련성이 떨어지고, 전체 주입 시 토큰 한계를 초과한다. 긴 컨텍스트에서 LLM 성능이 저하되는 "Lost in the Middle" 현상도 있다. 무엇보다 팀 협업 병목 문제는 RAG로 해결되지 않는다. 파인튜닝은 대기업이나 규제 산업에서 장기 투자가 가능하고 조직 프로세스 개선을 병행할 때만 의미 있는 선택지다.

의사결정은 세 가지 질문으로 정리할 수 있다. 비학습 라이브러리로만 구현 가능한 고유 기능이 있는가? 없다면 대중적 라이브러리를 채택한다. 있다면 RAG와 컨텍스트 주입에 투자할 리소스가 있는가? 없다면 하이브리드 전략을 택한다. 있다면 팀 협업 프로세스 병목도 함께 해결할 의지가 있는가? 없다면 역시 하이브리드 전략이 낫다. RAG만으로는 절반의 해결이다. 모두 있다면 RAG와 조직 개편을 병행한다.

라이브러리 선택 기준의 재정립

기존에 라이브러리를 선택할 때는 기술적 우수성, 팀 친숙도, 유지보수성을 기준으로 삼았다. 이제 두 가지 기준이 추가되어야 한다. LLM 학습 데이터에 존재하는가? 개발자가 자율적으로 수정 가능한가?

기존에 사용 중인 비학습 라이브러리가 있다면 마이그레이션을 고려해야 한다. "이미 투자했으니 계속 써야 한다"는 매몰 비용 오류의 함정을 경계해야 한다. 장기적인 AI 생산성 손실과 팀 병목 비용을 단기 전환 비용과 비교해보라.

신규 프로젝트의 원칙은 명확하다. LLM이 아는 것부터 시작하고 필요한 만큼만 커스터마이징한다. 병목 인력을 만들지 않는 구조를 설계한다.

통계적 현실주의

동일한 결과물을 구현할 수 있다면 LLM이 아는 라이브러리가 압도적으로 유리하다. 비학습 라이브러리는 AI 생산성 저하와 팀 프로세스 병목이라는 이중 부담을 지운다.

기술적 우수성, 내부 최적화, 브랜드 일관성 모두 중요하다. 그러나 AI 코딩 시대에 LLM이 모르는 것은 존재하지 않는 것과 같다. 여기에 팀 협업 병목까지 더해지면 숨겨진 비용은 기하급수적으로 증가한다.

최고의 도구가 아닌, 가장 효과적인 도구를 선택하는 현실주의가 필요하다. 개인 생산성과 팀 생산성, 두 차원 모두를 고려한 전략적 판단이 필요한 시점이다.