아틀라시안은 어떻게 AI-native로 갔나
Quick Summary
아틀라시안은 디자인 시스템을 컴포넌트 저장소에서 AI가 필요한 기준과 맥락을 제때 읽고 적용할 수 있는 ‘맥락 엔진’으로 확장해, 제작 속도와 제품 품질을 함께 관리하는 AI 네이티브 조직으로 전환했다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
아틀라시안은 디자인 시스템을 컴포넌트 저장소에서 AI가 필요한 기준과 맥락을 제때 읽고 적용할 수 있는 ‘맥락 엔진’으로 확장해, 제작 속도와 제품 품질을 함께 관리하는 AI 네이티브 조직으로 전환했다.
📌 핵심 요약
- 아틀라시안은 AI 도입에 앞서 흩어진 디자인 가이드와 코드 라이브러리를 정리하고, 브랜드·제품 경험·접근성·정보 구조를 하나의 기준으로 정렬했다.
- 디자인 시스템을 단순한 사용자 인터페이스 라이브러리가 아니라 사용 조건, 제약, 예외와 판단 근거를 AI에게 필요한 순간 전달하는 맥락 엔진으로 재정의했다.
- 구조화된 콘텐츠와 모델 컨텍스트 프로토콜, 디자인 시스템 스킬, DESIGN.md를 활용하되, 빠른 프로토타입과 실제 제품 코드에서 요구되는 기준을 구분했다.
- 컴포넌트를 고정된 화면의 부품이 아니라 패널·채팅·캔버스 등 여러 환경에서 의미를 유지하며 재조합되는 경험의 단위로 보고, 움직임과 상태 표현까지 시스템화했다.
- 디자인과 엔지니어링의 관계를 일방적인 전달에서 지속적인 협업으로 바꾸고, 디자인 테크놀로지스트와 선행 평가 기준을 통해 더 빠르게 만들고 검토하고 학습하는 조직 구조를 지향했다.
🧩 주요 포인트
- 아틀라시안은 AI 도입에 앞서 흩어진 디자인 가이드와 코드 라이브러리를 정리하고, 브랜드·제품 경험·접근성·정보 구조를 하나의 기준으로 정렬했다.
- 디자인 시스템을 단순한 사용자 인터페이스 라이브러리가 아니라 사용 조건, 제약, 예외와 판단 근거를 AI에게 필요한 순간 전달하는 맥락 엔진으로 재정의했다.
- 구조화된 콘텐츠와 모델 컨텍스트 프로토콜, 디자인 시스템 스킬, DESIGN.md를 활용하되, 빠른 프로토타입과 실제 제품 코드에서 요구되는 기준을 구분했다.
- 컴포넌트를 고정된 화면의 부품이 아니라 패널·채팅·캔버스 등 여러 환경에서 의미를 유지하며 재조합되는 경험의 단위로 보고, 움직임과 상태 표현까지 시스템화했다.
- 디자인과 엔지니어링의 관계를 일방적인 전달에서 지속적인 협업으로 바꾸고, 디자인 테크놀로지스트와 선행 평가 기준을 통해 더 빠르게 만들고 검토하고 학습하는 조직 구조를 지향했다.
🧠 상세 정리
1. 사용자 인터페이스 라이브러리에서 맥락 엔진으로
아틀라시안은 AI를 제품 개발에 넣기 전에 디자인 가이드와 코드 라이브러리를 정리하고, 브랜드와 제품 경험을 연결하며 여러 제품의 기준을 맞췄다. 이런 기반이 없으면 AI는 무엇이 올바른 결과인지 판단할 근거를 갖기 어렵기 때문이다. 이후 디자인 시스템을 컴포넌트 목록이 아니라 AI가 참고해야 할 기준, 맥락, 제약과 사용 조건을 담는 ‘맥락 엔진’으로 확장했다. 시스템은 무엇을 쓸 수 있는지만 아니라 언제 사용해야 하는지, 왜 적합한지, 언제 피해야 하는지, 어디까지 변경할 수 있는지를 설명해야 한다. 이에 따라 디자이너의 무게중심도 화면을 더 많이 그리는 일에서 더 나은 결과가 나오도록 조건과 판단 기준을 설계하는 일로 이동한다.
2. 문서의 양이 아니라 필요한 맥락의 전달
아틀라시안은 많은 문서를 AI에게 한꺼번에 제공한다고 해서 올바른 맥락이 형성되는 것은 아니라고 봤다. 오래된 설명과 최신 코드가 어긋나면 AI는 잘못된 내용을 근거로 겉보기에는 자연스러운 결과를 만들 수 있으며, 사람과 달리 주변에 물어 오류를 바로잡기도 어렵다. 그래서 컴포넌트 사용 조건과 속성, 코드 예시, 콘텐츠 기준, 접근성 요구사항, 토큰과 아이콘 정보를 일정한 형식의 구조화된 콘텐츠로 정리했다. 이 정보는 문서 사이트에만 두지 않고 코드 가까이에 배치해 모델 컨텍스트 프로토콜, 디자인 시스템 스킬, DESIGN.md 등의 방식으로 필요한 환경에서 불러오게 했다. 핵심은 전체 자료를 매번 읽히는 것이 아니라 특정 컴포넌트가 필요한 순간 그 사용 조건과 예시처럼 관련된 기준만 정확히 전달하는 데 있다.
3. 닮은 프로토타입과 실제로 작동하는 제품의 차이
DESIGN.md는 핵심 토큰과 디자인 의도를 하나의 파일에 담아 낯선 도구나 내부 시스템에 직접 연결하기 어려운 환경에서 빠르게 방향을 잡게 한다. 일회성 프로토타입에서는 브랜드 컬러와 간격, 형태와 타이포그래피를 반영해 AI 특유의 일반적인 화면에서 벗어나는 데 유용하다. 그러나 토큰, 컴포넌트 라이브러리, 린트 규칙, 타입 검사와 패키지 구조가 이미 있는 실제 코드에서는 파일 하나만으로 충분하지 않다. 많은 정보를 한꺼번에 읽히면 비용과 응답 시간이 늘고 중요한 맥락이 묻힐 수 있으며, 기존 컴포넌트 대신 비슷하게 생긴 요소를 다시 만들 위험도 있다. 실제 제품에 필요한 것은 버튼처럼 보이는 결과가 아니라 검증된 버튼을 올바른 속성과 상태로 사용하고 접근성, 키보드 동작, 오류 처리와 다크 모드까지 지키는 결과다.
4. 재조합되는 컴포넌트와 움직임의 시스템화
AI가 제품 안으로 들어오면서 같은 정보는 대시보드뿐 아니라 패널, 채팅, 캔버스에서도 다른 형태로 다시 구성될 수 있게 된다. 아틀라시안의 패널 사례는 바깥 구조와 반응형 동작, 접근성, 시각적 리듬은 시스템이 안정적으로 제공하되 본문은 각 제품 맥락에 맞게 열어두는 방식을 보여준다. 이를 위해 디자인 시스템은 무엇을 고정하고 어디부터 제품팀이 조정할 수 있는지 명확히 설명해야 하며, 데이터 구조와 시각 표현, 상호작용 규칙도 함께 정리해야 한다. 또한 AI가 검색하고 판단하고 결과를 만드는 동안 사용자가 상태를 이해하도록 움직임의 속도, 방향, 멈춤과 전환 기준까지 시스템화해야 한다. 수학적으로 맞는 모서리 값이 실제 화면에서는 어색할 수 있다는 사례처럼, 디자이너의 시각적 보정과 감각도 AI와 조직이 참고할 수 있는 명시적인 판단 기준으로 바뀌어야 한다.
5. 핸드오프에서 핸드셰이크로 바뀌는 조직
AI가 프로토타이핑과 구현의 경계에 들어오면서 디자인을 마친 뒤 엔지니어링에 넘기는 선형적 핸드오프는 디자인, 코드, 요구사항이 계속 왕복하는 핸드셰이크로 바뀐다. 디자인 테크놀로지스트는 디자인 의도를 코드로 옮기고 기술적 가능성을 사용자 경험으로 번역하며, 시스템 위에서 안전하게 실험할 수 있는 환경을 만드는 역할을 맡는다. 디자인 시스템 팀도 결과를 사후에 통제하는 게이트키퍼에 머물지 않고 템플릿, 주요 사용자 인터페이스 요소, 접근성 및 콘텐츠 기준을 미리 제공해 더 나은 출발점을 만들어야 한다. 제작 속도가 빨라질수록 사용자 조사, 전문성, 코드 품질, 접근성, 브랜드 표현과 제품 맥락을 포함한 평가 기준은 작업의 뒤가 아니라 앞에 놓여야 한다. 결국 AI 네이티브 조직은 AI 도구를 많이 쓰는 조직이 아니라 작동하는 가능성을 더 빨리 만들고 검토하며 배우되, 무엇을 남기고 버릴지는 사람과 조직의 기준으로 결정하는 조직이다.
🧾 핵심 주장 / 시사점
- AI가 디자인을 정확히 다루게 하려면 조직이 먼저 자신의 디자인 원칙과 예외, 사용 조건과 감각적 판단을 설명할 수 있어야 한다.
- 빠른 프로토타입에서 시스템과 닮은 화면을 만드는 방법과 실제 제품에서 검증된 컴포넌트와 규칙을 정확히 사용하는 방법은 구분되어야 한다.
- AI 네이티브 디자인 시스템의 핵심은 생성량을 늘리는 것이 아니라 더 좋은 출발점과 평가 기준을 제공해 무엇을 남기고 무엇을 버릴지 판단할 수 있게 하는 데 있다.
✅ 액션 아이템
- 아틀라시안 사례처럼 브랜드·제품 경험·접근성·정보 구조를 통합 기준으로 정렬해 산재 가이드를 디자인 시스템으로 통합한다.
- 디자인 시스템을 ‘컴포넌트 저장소’에서 AI 맥락 엔진으로 재정의해 조건·제약·예외와 판단 근거를 즉시 적용 가능한 구조로 정비한다.
- 컴포넌트를 고정형 부품이 아닌 패널·채팅·캔버스 전환 가능한 경험 단위로 보고, 움직임·상태까지 반영한 재조합 규칙을 정의한다.
❓ 열린 질문
- 빠른 프로토타입 기준과 실제 제품 코드 기준은 어떤 지점에서 충돌하며, 어디를 우선 분리 운영할 것인가?
- 컴포넌트를 다중 환경에서 재조합할 때 움직임·상태 표현의 필수 검증 범위는 어디까지 설정할 것인가?
- AI 맥락 엔진이 판단 근거를 제대로 사용하려면 사용 조건·제약·예외의 서술 형식은 어떤 기준으로 고정할 것인가?