요즘 AI에게 화면을 만들어달라고 하는 일은 꽤 자연스러워졌다. 간단한 프로토타입부터 실제 서비스에 들어갈 만한 UI까지, 몇 마디 설명만으로 결과물을 만들어준다. 처음에는 이 정도면 디자이너가 하던 일을 상당 부분 대신할 수도 있겠다는 생각이 든다.
그런데 막상 여러 번 사용해보면 조금 다른 문제가 보인다. 분명 같은 서비스에 만들어달라고 했는데 결과가 매번 달라지고, 처음에는 그럴듯했던 화면이 실제 제품에 붙이려고 하면 어딘가 어색하다. 기존 디자인 시스템과 맞지 않거나, 이미 서비스에 있는 패턴을 두고 새로운 UI를 만들어버리기도 한다. 그래서 프롬프트에 조건을 하나씩 더 붙인다. “기존 컴포넌트를 사용해줘.” “우리 서비스의 디자인을 따라줘.” “불필요한 요소는 만들지 마.” 그런데 다음 작업에서는 또 처음부터 설명해야 한다.
이쯤 되면 질문이 조금 달라진다. AI에게 더 좋은 프롬프트를 쓰는 것이 정말 답일까?
최근 AI 에이전트를 둘러싼 논의에서는 이 문제를 프롬프트가 아니라 AI가 일하는 환경 자체를 설계하는 것으로 바라보기 시작했다. 그때 등장하는 개념이 바로 Harness(하네스)다.
같은 AI인데 결과가 달라지는 이유
Anthropic이 장시간 자율적으로 애플리케이션을 만드는 실험에서 흥미로운 결과를 공개했다. 같은 Claude를 사용하더라도 어떤 방식으로 작업 환경을 구성하느냐에 따라 결과의 품질이 크게 달라졌다는 것이다.
단순히 AI에게 애플리케이션을 만들어달라고 하는 방식과, 계획을 세우는 단계, 실제 구현을 담당하는 단계, 결과를 평가하는 단계를 나누고 그 사이에 필요한 정보와 산출물을 넘겨주는 방식을 비교했다. 후자의 경우 몇 시간 동안 작업하면서 더 많은 기능과 완성도 높은 결과물을 만들어냈다.
여기서 중요한 건 “Anthropic이 AI를 더 똑똑하게 만들었다”는 이야기가 아니다. 모델 자체가 바뀐 것이 아니라, 모델이 일하는 주변 환경을 바꿨다는 점이다. 이 주변 환경을 통틀어 하네스라고 부른다.
하네스에는 AI가 참고할 정보와 사용할 수 있는 도구가 들어가고, 작업을 어떤 순서로 진행할지에 대한 구조가 만들어진다. 이전 작업의 상태를 어떻게 이어갈지, 결과가 제대로 만들어졌는지 무엇으로 판단할지, 문제가 생겼을 때 다시 시도할지까지 포함될 수 있다.
쉽게 말하면 프롬프트가 “이번에 무엇을 해줘”를 말한다면, 하네스는 “우리 제품에서 일을 할 때는 이런 환경과 규칙 안에서 움직여”를 만들어주는 것이다.
UX 디자이너에게 이게 왜 중요할까
지금까지 UX 디자이너가 AI를 사용할 때 가장 많이 고민했던 것은 프롬프트였다. 어떤 말을 입력해야 원하는 결과가 나오는지, 어떤 순서로 요청해야 하는지, 어떻게 수정해야 더 좋은 화면이 나오는지에 집중했다.
하지만 AI가 단순한 이미지나 문장을 만드는 것을 넘어 실제 제품을 만들고 수정하는 단계로 들어가면서 문제가 달라지고 있다.
AI에게 새로운 화면을 하나 만들어달라고 하는 것은 쉽다. 어려운 건 이미 존재하는 제품 안에 새로운 화면을 자연스럽게 추가하는 것이다.
예를 들어 기존 서비스에 ‘활동 기록’ 페이지를 하나 추가한다고 해보자. 디자이너가 직접 작업한다면 이미 알고 있는 것들이 많다. 이 서비스에서는 버튼을 어떻게 쓰는지, 카드의 밀도는 어느 정도인지, 어떤 정보가 중요할 때 더 크게 보여주는지, 모바일에서 어떤 패턴을 사용하는지 알고 있다. 우리는 이런 것들을 알 수 있지만 AI에게는 그 맥락이 없다.
그래서 AI는 가장 그럴듯한 일반적인 답을 만든다. 둥근 카드가 나오고, 그라데이션이 들어가고, 적당히 큰 제목이 생긴다. 특별히 잘못된 부분은 없지만 우리가 만들던 제품의 화면처럼 보이지 않는다.
이때 매번 프롬프트에 디자인 원칙을 길게 적어주는 대신, 그 정보 자체를 AI가 계속 참고할 수 있는 작업 환경으로 만들어 놓는 것이 하네스의 출발점이다.
실제로 디자인 하네스를 만들어본 사례
이 개념을 UX 디자이너의 입장에서 가장 쉽게 이해할 수 있는 사례가 있다.
Agentic Design School에서는 같은 웹사이트에 새로운 ‘field notes’ 영역을 추가하는 작업을 AI에게 시켰다. 하네스 없이 작업했을 때는 약 50분 동안 네 번의 수정이 필요했다. AI는 그럴듯한 그라데이션과 카드 UI를 만들었지만 기존 사이트의 컴포넌트나 디자인 패턴을 제대로 활용하지 못했다.
반대로 하네스를 만들어 놓은 상태에서는 작업 시간이 약 15분으로 줄었고, 수정도 두 번이면 충분했다. 프롬프트 자체는 길지 않았다. 대신 AI가 DESIGN.md, AGENTS.md, 기존 컴포넌트 등을 먼저 참고하도록 했다. 결과적으로 새 UI를 새롭게 발명하기보다 이미 서비스 안에 존재하는 컴포넌트와 디자인 토큰을 조합해서 화면을 만들었다.
이 차이는 꽤 중요한데, AI가 디자인을 못해서 생긴 문제가 아니였기 때문이다. AI는 충분히 괜찮은 화면을 만들었다. 문제는 무엇이 이 제품에서 괜찮은 화면인지 알려주는 환경이 없었다는 것에 있었다. 하네스는 바로 이런 부분들을 보완할 수 있는 것이다.
그래서 하네스는 어떻게 만들어야 하는가?
디자이너 입장에서 생각하면 거창한 시스템부터 만들 필요는 없다.
가장 먼저 필요한 것은 디자인의 기준을 AI가 읽을 수 있는 형태로 정리하는 것이다. 예를 들어 색상이나 타이포그래피, spacing, radius처럼 이미 디자인 시스템에 존재하는 값뿐 아니라 어떤 컴포넌트를 사용해야 하는지, 어떤 패턴을 반복해서 사용하는지, 반대로 어떤 표현은 사용하지 않는지까지 포함할 수 있다.
특히 중요한 건 추상적인 표현을 줄이는 것이다.
“세련된 화면으로 만들어주세요”는 AI에게 거의 아무것도 알려주지 않는다. 반면 “기존 Card 컴포넌트를 우선 사용하고, 새로운 색상은 만들지 않으며, 모바일에서는 정보의 우선순위를 유지한다”처럼 실제 작업에서 판단할 수 있는 기준을 주면 훨씬 다르게 작동한다.
Agentic Design School의 사례에서도 DESIGN.md에는 컬러와 타이포그래피뿐 아니라 radius, layout, 실제 컴포넌트 목록, 사용하지 말아야 할 디자인 패턴까지 정의되어 있었다. 이런 정보가 매번 프롬프트에 반복되는 대신 프로젝트의 일부로 존재하는 것이다.
여기서 UX 디자이너가 새롭게 해야 할 일은 디자인 원칙을 더 많이 문서화하는 것이 아니다. AI가 반복해서 틀리는 부분을 찾아서, 한 번만 알려주면 되는 지식과 매번 사람이 판단해야 하는 지식을 구분하는 것에 가깝다.
예를 들어 버튼의 스타일이나 spacing처럼 반복되는 규칙은 하네스에 넣을 수 있다. 반면 이번 화면에서 어떤 정보를 가장 강조할지, 사용자가 정말 원하는 것이 무엇인지, 기존 구조를 깨고 새로운 패턴을 만들어야 하는지는 여전히 디자이너가 판단하는 편이 낫다. 그렇기에 하네스가 디자이너를 대신하지는 않는다고 볼 수 있기도 하니 잘 다루기만 한다면 훨씬 좋은 시너지를 낼 수 있을 것이다.
혹시 AI에게 ‘잘 만들어졌는지’까지 맡길 수 있을까??
하네스가 재미있어지는 지점이 있는데, AI가 화면을 만드는 것만으로 끝나지 않고 자기가 만든 결과를 다시 확인하도록 만들 수 있기 때문이다.
Anthropic은 프론트엔드 디자인 실험에서 이 문제를 다뤘다. AI가 스스로 자신의 디자인을 평가하게 하면 mediocre한 결과물도 자신 있게 좋다고 평가하는 문제가 있었고, 이를 해결하기 위해 생성하는 역할과 평가하는 역할을 분리했다. 평가 에이전트는 디자인 품질, 독창성, 완성도, 기능성 같은 기준을 가지고 결과를 검토했고, 실제 실행 중인 화면을 확인하기 위해 Playwright도 사용했다.
"디자이너가 요청하고, AI가 만들고, 디자이너가 보고, 다시 수정 요청을 한다." 이러한 방식은 지금 UX에서도 AI를 이용한 디자인 작업은 보통 이런 식이기 때문에 꽤나 의미있는 것이다.
하네스를 적용하면 중간에 AI가 스스로 검토하는 단계를 넣을 수 있다. 단순히 “괜찮은지 확인해줘”라고 하는 것이 아니라 프로젝트에서 중요하게 보는 기준을 가지고 결과를 다시 살펴보게 만드는 것이다.
그러면 디자이너가 처음부터 모든 작은 오류를 잡아내는 대신, AI가 먼저 반복적인 문제를 걸러내고 디자이너는 더 중요한 판단에 시간을 쓸 수 있다.
물론 이것이 사람의 디자인 리뷰를 없애준다는 의미는 아니다. 오히려 반대다. 사람이 봐야 하는 문제를 더 사람다운 문제로 좁히는 것에 가깝다.
제품에서의 하네스 디자인
하네스가 UX 디자이너에게 중요한 이유는 단순히 AI가 UI를 잘 만들게 하기 위해서만은 아니다.
monday.com이 실제 서비스에 사용하는 feedAgent 사례를 보면 하네스가 훨씬 넓은 범위를 다룬다는 것을 알 수 있다. 이 에이전트는 여러 보드와 문서, 에이전트 활동 등의 데이터를 가져와 사용자에게 중요한 내용을 선별해서 보여준다. 여기서 하네스는 단순한 프롬프트가 아니라 어떤 데이터를 AI에게 전달할지, 에이전트가 어디까지 행동할 수 있는지, 결과를 어떤 형태로 내보낼지, 이후 사용자의 행동을 어떻게 다시 반영할지를 관리한다.
이걸 UX의 언어로 바꾸면 꽤 익숙한 질문들이 된다.
사용자에게 보여주기 전에 어떤 정보가 걸러지는지, AI가 어떤 권한을 가지고 있는지, 결과를 사용자가 믿을 수 있도록 어떤 근거를 보여주는지, 문제가 생겼을 때 사용자가 어떻게 수정하거나 되돌릴 수 있는지를 설계하는 일이다.
결국 AI 제품의 UX는 AI의 답변 화면만으로 끝나지 않는다. AI가 답변에 도달하기까지 어떤 정보와 규칙, 도구를 거치는지까지 제품 경험의 일부가 된다.
그렇다면 디자이너는 무엇부터 시작하면 될까
처음부터 거대한 에이전트 시스템을 만들 필요는 없다.
오히려 지금 AI로 프로토타이핑을 자주 하고 있다면 최근에 반복해서 수정했던 문제부터 보는 것이 좋다. 매번 같은 디자인 규칙을 설명하고 있다면 그것을 문서로 옮길 수 있고, AI가 자꾸 존재하지 않는 컴포넌트를 만든다면 실제 컴포넌트와 사용법을 알려줄 수 있다. 같은 실수가 반복된다면 그 부분을 확인하는 간단한 검증 과정도 추가할 수 있다.
결국 하네스는 AI에게 더 많은 것을 설명하는 방법이 아니라, 매번 설명하지 않아도 되는 것을 제품의 작업 환경으로 옮기는 방법이다.
이렇게 생각하면 하네스가 조금 덜 부담스러울 것이다.
디자인 시스템도 비슷했다. 처음에는 디자이너가 매번 같은 버튼과 색상을 직접 설명했지만, 어느 순간 그것을 규칙과 컴포넌트로 만들었다. 하네스는 그 개념을 AI가 일하는 환경까지 확장한 것에 가깝다.
그리고 여기서 UX 디자이너의 역할도 조금 달라질 수 있다.
앞으로는 “AI에게 어떤 프롬프트를 입력할까?”만큼이나 “우리 제품에서 AI가 어떤 맥락을 알고 일해야 할까?”, “어떤 판단은 자동화하고 어떤 판단은 사람에게 남겨야 할까?”, “AI가 만든 결과를 무엇으로 검증할까?”를 설계해야 한다.
모델의 성능이 좋아질수록 이 문제는 오히려 더 중요해질 가능성이 크다. 좋은 모델이 무엇이든 만들 수 있게 될수록, 무엇을 만들게 할 것인지보다 어떤 환경 안에서 만들게 할 것인지가 제품의 차이를 만들기 때문이다.
그래서 하네스는 개발자만의 개념이라기보다, AI를 제품 안에 제대로 들여놓기 시작한 UX 디자이너가 한 번쯤 알아둘 만한 새로운 설계 영역에 가깝다.
'공부 > UXUI 리뷰' 카테고리의 다른 글
| [UXUI 리뷰] 개인화는 정말 좋은 UX일까? (2) | 2026.07.05 |
|---|---|
| [UX] 2026 iF 디자인 트렌드 리포트 핵심 정리: 인간다움 지향 (0) | 2026.05.17 |
| [UXUI 리뷰] XR UX 패러다임의 전환과 AI Glass ‘최소 간섭 UX’ (1) | 2026.02.08 |
| [UXUI 리뷰] 논란의 쿠팡 인터페이스, 의도된 것이다? (0) | 2025.04.27 |
| [UX/UI 리뷰] 배달의민족 주소 설정 (0) | 2025.02.21 |