올바른 방향으로 빠르게 나아가는 방법 | Figma 블로그 (새 탭에서 열림)

AI는 소프트웨어 제작 속도를 크게 높였지만, 빠른 실행이 곧 올바른 제품을 의미하지는 않는다. AI가 만든 결과물을 그대로 받아들이면 기술 부채가 늘고, 평균적인 디자인과 기능에 머물 수 있다. 따라서 좋은 팀은 먼저 무엇을 만들지 충분히 고민하고, 명확한 맥락과 시스템을 제공한 뒤, 자신만의 관점으로 결과물을 다듬어야 한다.

AI는 실행을 가속하지만 판단을 대신하지 못한다

• AI는 짧은 프롬프트만으로도 완성도 높아 보이는 프로토타입과 코드를 만들어낸다.
• 그러나 겉보기의 완성도는 내부 구조, 제약 조건, 시스템 동작 방식까지 올바르다는 뜻이 아니다.
• 과거에는 결과물의 세련됨 뒤에 전문가의 의사결정과 트레이드오프가 있었지만, 이제는 AI가 그 빈틈을 임의로 채울 수 있다.
• **인지적 항복(cognitive surrender)**은 AI의 출력을 검토 없이 자신의 판단처럼 받아들이는 현상이다.
• 첫 번째 결과물이 그럴듯하다는 이유로 바로 출시하지 말고, 문제의 본질과 실제로 만들 가치가 있는 것을 먼저 정의해야 한다. 글에서는 이를 **고려의 의무(consideration imperative)**로 표현한다.

맥락과 의도를 먼저 제공해야 한다

• 에이전틱 엔지니어링에서는 개발자의 역할이 코드를 직접 작성하는 것에서 의도를 명확히 표현하고 검증하는 것으로 이동한다.
• Google의 관련 백서는 다음 요소를 중요한 기반으로 제시한다.
  • 결정론적 계층: 테스트, 타입 검사, 검증처럼 매번 동일하게 실행되며 AI의 오류를 잡는 장치
  • 고신호 맥락: 명세, 문서화된 컴포넌트, 설계 원칙 등 에이전트가 의도를 정확히 이해하도록 돕는 정보
  • 명확한 인터페이스: 시스템 각 부분이 어떻게 연결되는지 에이전트가 추측하지 않도록 정의한 계약
• 디자인에서 코드로 전환할 때도 에이전트가 실제 프로덕션 컴포넌트의 구조를 모르면 픽셀을 보고 임의로 재구성할 가능성이 높다.
• Figma MCP의 Code Connect처럼 실제 컴포넌트의 코드, props, variants를 제공하면 에이전트가 기존 시스템에 맞는 결과를 만들 수 있다.
• 강력한 디자인 시스템은 결정 사항을 재사용 가능한 어휘와 가드레일로 codify해 결과물의 일관성을 높이고 코드와 기술 부채를 줄인다.
• 초기에는 명세와 시스템을 준비하는 데 더 많은 시간이 들지만, 장기적으로 유지보수 비용을 낮춘다.

“괜찮은 결과”는 쉽게 평균이 된다

• AI 모델은 방대한 기존 데이터를 학습했기 때문에 이미 널리 사용된 패턴과 스타일, 즉 분포 안의 평균적인 결과를 생성하는 경향이 있다.
• 예를 들면 다음과 같은 결과가 반복될 수 있다.
  • 로고: 단순한 기하학적 형태와 그라디언트
  • 발표 자료: 흔한 산세리프 글꼴과 익숙한 레이아웃
  • React 컴포넌트: 둥근 모서리의 전형적인 카드 UI
• 이런 결과는 틀리지는 않지만 차별성이 부족하다.
• AI가 만든 “충분히 좋은” 결과를 반복해서 받아들이면 사용자의 판단 기준이 좁아지고, “무엇이어야 하는가?”보다 “덜 나쁜 선택은 무엇인가?”를 고르게 된다.
• AI의 품질이 향상될수록 개인이 과거보다 나은 결과를 만들 수 있지만, 동시에 다른 AI 생성물과 비슷해질 위험도 커진다.

제품의 관점은 사람이 결정해야 한다

• AI는 실행과 변형을 빠르게 수행할 수 있지만, 제품의 목적과 차별화된 방향까지 자동으로 결정하게 두어서는 안 된다.
• 명확한 의도와 평가 기준이 없으면 모델이 기본값과 평균적인 패턴을 대신 선택한다.
• 팀은 AI가 제시한 결과를 출발점으로 활용하되, 왜 이 기능과 디자인이 필요한지, 누구를 위한 것인지, 무엇이 달라야 하는지를 직접 판단해야 한다.
• 결국 속도의 핵심은 첫 결과물을 빨리 내는 것이 아니라, 명확한 맥락과 검증 장치를 통해 올바른 방향으로 빠르게 반복하는 것이다.

AI를 활용할 때는 프롬프트 작성보다 먼저 목표, 제약 조건, 성공 기준을 문서화하는 것이 좋다. 테스트·타입 검사·디자인 시스템·명확한 인터페이스를 갖추고, AI 결과물을 반드시 사람의 관점과 제품 기준으로 검토해야 평균적인 결과와 기술 부채를 피할 수 있다.