AI 네이티브 프론트엔드 개발

AI 네이티브 프론트엔드란

코드를 사람이 아니라 AI가 100% 쓰는 조직에서의 프론트엔드 개발이다. 기획은 동작하는 프로토타입을, 디자인은 HTML·CSS 코드를, BE는 확인용 화면까지 붙인 기능을 만들어 온다. 모두가 빌더가 되면 FE의 일은 기능을 처음부터 구현하는 것에서 받아 온 결과를 하나의 제품으로 통합하고, AI가 스스로 완성도를 맞출 수 있는 환경을 만드는 것으로 옮겨 간다.

영역	예전	AI 네이티브
구현	FE가 이벤트·상태·API 연결을 직접 짠다	AI가 짜고, FE는 위임 방식과 판단 기준을 스킬로 남긴다
코드 이해	직접 짜면서 쌓인다	구조를 AI와 함께 고치며 쌓는다
맥락 보관	머릿속, 사후 문서	이슈(작업 계약)와 PR(증거)
디자인 반영	시안을 보고 다시 구현	디자인 코드를 그대로 쓰고 픽셀 비교로 수렴
FE의 책임	피처 구현	통합, 완성도, 재현·비교·관측 환경

개발자 역할 전반의 변화는 AI 시대 개발자의 역할에 있다. 이 노트는 프론트엔드 실무에서 쓰는 방법을 다룬다.

AI에게 일을 맡기는 법

1. 금지 규칙보다 "고치는 방법"을 스킬로

CLAUDE.md·AGENTS.md에 규칙을 빽빽하게 적고 린트·훅으로 막는 금지형 하네스는 기존 코드를 정리할 때는 잘 통한다. 하지만 새 기능을 만들 때는 역효과가 난다.

증상	원인
조금 짜면 훅·린트가 막고, 리팩터링만 반복하다 기능이 완성되지 않는다	구현과 정리를 한 번에 강요한다. 사람도 먼저 구현하고 나중에 정리한다
맥락 압축이 반복되며 처음 의도가 흐려지고 토큰만 쓴다	검사·수정 루프가 본 작업보다 커진다
겉은 규칙대로인데 안에 스파게티 코드가 숨어 있다	AI가 규칙을 피하는 코드를 만든다. 금지 목록은 좋은 코드를 정의하지 못한다

그래서 자유롭게 구현하게 한 뒤 정리한다. 정리 방법은 금지 목록이 아니라 내가 리팩터링하는 방식으로 준다. 이 방식을 처음부터 글로 다 쓰기는 어렵다. 대신 마음에 안 드는 파일 하나를 놓고 AI와 대화한다.

flowchart TB
  q["#quot;이거 뭐가 별로야? 어떻게 고칠 거야?#quot;"]
  no["#quot;아니, 그게 아니고#quot;"]
  yes["#quot;맞아, 그거 해 봐#quot;"]
  fix["고치게 함"]
  skill["#quot;지금까지 한 방식을 스킬로 만들어 둬#quot;"]
  use["쓰다가 어긋나면 이유를 묻고 스킬을 고친다"]
  q -->|"내 생각과 다르면"| no
  no -->|"맞는 말이 나올 때까지"| q
  q --> yes --> fix
  fix -->|"결과가 마음에 들 때까지"| fix
  fix --> skill --> use
  use --> skill

AI가 먼저 설명하고 사람이 동의·반대하는 동안 감각적으로 하던 판단이 대화에 드러난다. 암묵지를 대화로 꺼내 스킬로 굳히는 방법이다. 단일 책임, 개방-폐쇄 원칙, 응집도, 네이밍도 같은 식으로 스킬로 만든다. 어디에 적용할지는 "코드 스멜 찾아 줘"로 AI에게 찾게 하고, 무엇을 먼저 다룰지와 어떤 스킬을 쓸지만 사람이 고른다. 스킬 작성법은 Claude 스킬 만들기 가이드에 있다.

2. 문서를 읽지 말고 구조를 바꾸며 이해한다

AI가 쓴 코드를 이해하려고 보고서·아키텍처 문서를 계속 받으면 코드만큼 많은 문서가 생긴다. 읽기도 버겁고, 코드가 바뀌어도 문서는 저절로 갱신되지 않아 관리 비용이 된다. 잘 정리된 문서를 읽는다고 이해가 생기지 않는다. 직접 코딩할 때도 이해는 고쳐 보고 구조를 바꾸면서 생겼다.

컨셉맵을 ASCII 트리로 그리게 한다. 머메이드나 표보다 트리가 빨리 나오고 구조가 잘 들어온다. 묶인 모듈의 상위 개념을 보면 나머지는 추론할 수 있다.
그림을 보며 "이 모듈은 왜 여기 있어?", "이 둘을 묶으면 상위 개념이 뭐야?"라고 묻고, 납득이 안 되면 다른 배치로 바꾸게 한다.
이렇게 직접 고친 구조는 내 멘탈 모델을 담는다. 나중에 다시 봐도 왜 그렇게 정리했는지 알기 때문에 긴 보고서가 필요 없어진다.
무엇을 물어야 할지 모르면 "이 레포를 파악하려면 뭘 물어봐야 해?"부터 묻는다.

3. 의도 정렬: 고치기 전에 순서대로 맞춘다

기대가 없으면 AI는 아주 잘하는 것처럼 보인다. 원하는 것이 분명해지는 순간부터 어렵다. 그래서 수정에 들어가기 전에 다음 순서로 의도를 맞추는 대화(discuss) 단계를 둔다.

순서	확인할 것
1. 의도와 배경	왜 이 일을 꺼냈나, 어떤 사건·반복 상황 때문인가. 코드·문서에서 알 수 있는 것은 AI가 먼저 찾고, 알 수 없는 것만 묻는다
2. 이상·현재·간극	무엇이 어떻게 되면 만족인가, 지금 실제 상태는 어떤가, 차이의 원인은 무엇인가. 사용자가 제안한 수정 방법을 바로 정답으로 삼지 않는다
3. 제약과 자원	바꿀 수 없는 조건, 재사용할 기존 코드·도구
4. 외부 근거	알려진 해법·표준·생태계 흐름. 다만 우리 상황에 맞는지는 따로 판단한다
5. 목표와 해법	원인 중 무엇을 바꿀지(목표)와 어떻게 바꿀지(해법)를 나눈다
6. 부작용과 장애물	새 비용·위험, 대안보다 나은 이유

중간에 "그게 아니고"로 전제가 바뀌면 그 지점으로 돌아가 뒤의 판단을 다시 잇는다. 정해 둔 해법을 지키려고 조건 하나를 덧붙이는 식으로 처리하지 않는다.
확인된 것과 아직 열린 것을 짧은 표로 보여 주게 하면 지금 무엇을 이야기하는지 놓치지 않는다.
"이해한 대로 설명해 봐"로 확인한다.
논의 동의를 코드 수정 허락으로 받아들이지 않게 대화와 실행을 나눈다. 논의가 끝나면 만들 것, 완료 기준, 하면 안 되는 것을 정리하고 실행을 제안한 뒤 승인을 받는다.

플랜 모드나 인터뷰형 스킬과 같은 목적이다. 대충 한 말을 대신 구조화해 보여 주니 내 지시가 모호했는지도 드러난다.

4. 맥락은 이슈와 PR에 둔다

대화로 맞춘 맥락을 별도 MD 문서나 LLM 위키로 관리하면 그것도 일이 된다. 답은 원래 하던 방식에 있다. 이슈를 먼저 쓰고, 그 이슈로 개발하고, PR에서 확인한 뒤 머지한다.

산출물	역할	꼭 남길 것
이슈	작업 지시서 + 나중의 검증 기준	왜 하는가(배경·의도), 최종 목적(계약), 하면 안 되는 것(목적만으로는 해석 여지가 남는다)
진행 기록	작업 중 상태	이슈 코멘트로 남긴다
PR	증거가 담긴 보고서	수정 전후, 변경 이유, 확인할 링크·스크린샷. 장황하지 않게

대화에 함께한 사람은 모호한 이슈도 아는 배경으로 채워 읽는다. 이슈는 대화를 모르는 다른 에이전트가 읽어도 같은 작업이 나와야 한다. 서브에이전트 여러 개에게 같은 이슈로 구현시켜 결과가 비슷한지 비교하면 모호함을 확인할 수 있다.
PR에 증거를 남기게 하면 AI가 증거를 만들려고 실제로 확인하므로 셀프 체크 장치가 된다.
이슈·PR 작성법도 리팩터링 스킬처럼 결과를 보며 고쳐 가며 스킬로 만든다.
반복하는 방법·판단 기준은 스킬, 작업별 배경·목적·결과는 이슈·PR에 둔다. 쌓인 이슈·PR은 AI가 다음 작업에서 히스토리를 찾는 자산이 된다.

5. 병렬로 맡기고, 이탈을 알아챈다

한 작업을 빨리 끝내게 하는 데는 한계가 있다. 속도를 더 내려면 여러 작업을 동시에 맡겨야 한다.

에이전트끼리 같은 파일을 밟지 않게 작업마다 워크트리를 쓴다.
워크트리는 공간만 나눈다. 결과는 같은 제품으로 합쳐지므로 모듈의 책임·경계와 이슈의 범위가 먼저 나뉘어 있어야 충돌과 회귀가 줄어든다. 병렬로 얻은 속도를 합치는 데 다 쓰지 않으려면 일을 나누는 단계부터 병렬을 고려한다.
비슷한 작업을 여러 번 맡기면 걸리는 시간에 감이 생긴다. 유독 오래 걸리거나 진행 설명이 이상하면 멈춘다(ESC). 방치하면 토큰만 쓰거나, 더 나쁘게는 잘못된 방향으로 코드를 쌓아 되돌리는 비용까지 생긴다.
멈춘 뒤에는 정답을 알려 주기보다 지금 무엇을 왜 하고 있다고 생각하는지 설명하게 한다. 맥락 압축 등으로 이해한 목적이 처음 의도와 달라져 있는 경우가 많다. 원인을 스스로 짚게 하거나 "이 태스크부터 끝내고 보여 줘"처럼 작은 목표를 주면 대개 스스로 해결한다. AI는 해결책을 알지만, 잘못된 길에 들어선 것을 스스로 알아채는 눈이 약하다.

병렬 작업 구성은 루프 엔지니어링에 자세하다.

6. 모델이 바뀌면 스킬을 줄인다

더 강한 모델에서는 촘촘하게 짠 워크플로 스킬이 오히려 방해가 된다. 확인을 너무 자주 기다리거나, 이미 잘하는 일을 장황한 설명이 가로막는다. 이전 모델에서 잘되던 방법이 다음 모델에서도 좋다는 보장은 없다.

줄일 것	남길 것
모델이 이미 잘하는 일의 자세한 절차	프로젝트 고유 환경(서버 띄우기, 테스트 방법)
단계마다 확인을 받는 촘촘한 흐름	원하는 결과와 취향(이슈 문체, 리팩터링 방향)
	자주 하는 요청의 매크로("머지해 줘", "수정한 거 보여 줘", "이슈 목록 가져와서 해결해")

새 모델이 나오면 기존 스킬을 그 모델에 맞게 간소화해 달라고 시키는 것만으로도 동작이 좋아진다.

디자인과 같은 화면 만들기

디자인 코드를 공유하는 구조

AI로 만든 디자인 HTML·CSS를 받아도 AI가 옮기면 2px, 4px씩 어긋난다. 작은 차이가 쌓이면 화면 전체가 달라 보인다. 그래서 더 정확히 옮기게 하기보다 옮기는 과정 자체를 줄인다.

원칙은 디자인 레포는 디자인이 소유하고, 최소한의 환경만 맞추는 것이다. 모든 데이터를 props로 받는 순수 UI로 만들면 props 드릴링으로 복잡도가 폭증하고, FE가 디자인 컴포넌트를 직접 고쳐 쓰면 디자인(시안 비교용 variants)과 제품(기능 중심 단일 컴포넌트)의 목적이 달라 충돌이 잦다. 맞추는 최소 환경은 이렇다.

프레임워크와 스타일 규칙: React 컴포넌트, 바닐라 CSS + BEM 네이밍, 디자인 시스템에 없는 수치 금지, 에이전트 지침 공유.
규칙은 머지 시점에 건다. 작성 중에 막으면 디자인 품질이 떨어지므로 PR 머지 단계의 린트로 검사한다.
이벤트 핸들러는 dispatch만 한다. Redux처럼 컴포넌트 안에 로직을 두지 않고 정해진 액션 문자열로 스토어에 보내게 하면, 디자인과 제품이 같은 인터페이스를 갖고 디자인 컴포넌트도 비대해지지 않는다.

픽셀 diff 도구

AI는 코드 수준으로만 확인하고, 브라우저로 결과를 열어도 디자인이 맞는지 판단하지 못한다. 매번 "캡처해서 시안과 비교해"라고 시키는 일은 정해진 동작이므로 스크립트로 만든다. 디자인 페이지와 제품 화면을 캡처해 다른 픽셀을 빨갛게 표시하는 비교 표와 대시보드를 바이브 코딩으로 만들면, AI가 차이가 0이 될 때까지 스스로 수렴한다.

diff를 보여 줘도 계속 헤매는 곳은 대개 구조 문제다. 디자인과 제품이 컴포넌트를 다르게 묶어 두면 CSS만 고쳐서는 맞지 않으므로, 어떤 컴포넌트가 서로 대응하는지부터 맞춘다.

상태 재현 환경

비교하려면 두 화면이 같은 상태여야 한다. 드롭다운이 열렸는지, 사이드바가 접혔는지, 서버가 어떤 데이터·에러를 줬는지가 조합돼 화면이 나온다. 이를 매번 실제 제품에서 만들어 캡처할 수는 없으므로, 제품 컴포넌트를 그대로 쓰면서 데이터와 상태를 바깥에서 주입하는 재현 사이트를 만든다.

flowchart TB
  site["재현 사이트"]
  site --> be["백엔드 응답: 100% 목(MSW 등)으로 재현"]
  site --> fe["FE 내부 상태: 스토어에 dispatch해서 만든다"]
  site --> env["환경·초기 설정: 전부 외부에서 주입"]

화면만 비슷한 별도 컴포넌트를 쓰면 비교 환경에서 맞아도 제품이 맞는지 다시 확인해야 하고 이중 구현이 생긴다. 반드시 제품 코드로 재현한다. 이 환경이 갖춰지면 AI가 시안 → 재현 → 구현 → diff → 수정을 혼자 끝까지 돌리고, 다른 버그를 고칠 때도 그 상황의 UI를 재현해 누락을 찾는다. 시간이 없어 미뤄 두던 목 데이터와 상태 설계라는 정공법을 AI 덕분에 끝까지 할 수 있다. 디자인 시스템 쪽 하네스 설계는 디자인 시스템을 아는 화면 생성 에이전트 설계하기에 있다.

다른 직군과 일하기

수정 범위와 책임 범위를 나눈다

AI는 문제를 해결하려고 다른 영역 코드까지 고친다. FE를 고치라고 했는데 BE 코드가 바뀌고, 그 변경에서 문제가 생긴다. 고칠 수 있는 범위가 넓어져도 책임지는 범위가 저절로 넓어지지는 않는다. 담당자가 모르는 변경은 그 사람이 떠안는다.

다른 영역 파일은 읽고 분석은 하되 수정은 금지한다. 확장자·경로 단위로 지침과 PR 검사에 건다.
원인이 다른 영역에 있으면 담당자에게 전달한다.
반대로 BE가 확인용으로 붙인 FE는 받아서 디자인을 붙이고 유지보수 구조로 정리한다. 누가 만들 수 있는가와 누가 계속 관리하는가는 따로 정한다.

AI가 건드리면 안 되는 영역 전반은 AI 코딩 실무 가드레일에 있다.

일을 누가 맡을지는 맥락으로 정한다

BE는 기능의 의도와 동작을 이미 안다. FE가 같은 기능을 다시 만들려면 그 맥락부터 전달받아야 한다. 화면을 만드는 기술과 시간을 AI가 메워 준다면 그 기능의 맥락을 가장 잘 아는 사람이 화면까지 만드는 편이 자연스럽다. FE는 BE·디자인·기획을 기다리지 않고 MSW로 목 API를 먼저 만들고, 필요한 FE 부품을 미리 마련해 두는 쪽으로 일한다. 이 부품은 다른 직군이 기능을 만들 때 가져다 쓰는 재료가 된다.

전달하는 글은 덜어 낸다

AI가 쓴 분석·보고는 관련 이슈, 수정한 파일·함수, 테스트까지 다 담아 길다. 함께 분석한 사람은 이해해도 과정을 모르는 사람에게는 부담이다.

As-Is / To-Be를 중심에 둔다. 원인, 왜 그렇게 고쳤나, 결과가 어떻게 달라졌나, 확인할 링크·스크린샷.
받는 사람이 그 글로 무엇을 할지 기준으로 고른다. 기획자는 해결 여부와 바뀐 동작, 개발자는 수정 이유와 방법이 필요하다. 상세 구현은 필요할 때 찾아보게 둔다.
받는 쪽이 AI로 요약하면 된다는 생각은 쓰는 쪽이 줄인 비용을 읽는 쪽에 넘기는 일이다. 불필요한 코드가 쌓이면 누군가 정리해야 하듯 글도 같다. 빼는 것도 가독성이다.
잘 쓴 이슈라도 말로 한 번 짚어 주면 맥락 없는 사람이 훨씬 빨리 이해한다.
형식은 스킬로 고정한다.

기록이 대화를 대신하지 못하는 곳

레포 주소와 권한만 주면 동료의 AI가 이슈·코드를 읽어 진행 상황을 알아낸다. 현황 공유는 전보다 쉽다. 그러나 AI가 답을 잘 찾는 것과 무엇을 물어야 할지 아는 것은 다른 문제다.

코드와 이슈에는 결과만 남는다. 아직 고르지 못한 설계, 망설이는 이유, 지금 무엇을 중요하게 보는지는 남지 않는다.
사람끼리 나눠야 할 것은 세부 정보가 아니라 상대가 지금 무엇을 하고 왜 하는가다. 이 출발점이 있으면 궁금한 세부는 AI에게 물으면 된다.
각자 혼자 더 멀리 만들 수 있게 되면서 결과를 넘기는 시점이 늦어진다. 받는 쪽은 결과뿐 아니라 거기까지의 판단을 뒤늦게 따라가야 하고, 의견을 내면 "이미 논의가 끝났다"는 답을 듣는다.
각자의 생산성이 오른 것이 팀 전체의 생산성이 오른 것은 아니다. 만드는 비용은 줄어도 받아서 이해하고 제품에 반영하는 비용은 같은 비율로 줄지 않는다. 부분 최적화를 경계한다.

FE를 얇게: 정본을 바깥에 둔다

코드는 많은데 개발이 나아가지 않고 토큰만 든다면 같은 개념이 여러 형태로 존재하는지 본다.

flowchart LR
  be["BE 세션"] -->|"변환"| fe["FE 세션"]
  fe -->|"결합용 중간 인터페이스"| pa["파이프라인 A"]
  pa --> pb["파이프라인 B"]
  pb --> more["..."]

(각 변환 결과가 누군가에게 다시 정본이 된다)

시기와 기준이 달라 생긴 차이가 실제로 필요한 차이보다 훨씬 많다. 변환 코드는 차이를 유지하는 데만 쓰인다.
맥락에 한계가 있는 AI는 어느 것이 정본인지 몰라 같은 로직을 또 만든다. 사람도 코드가 너무 많아 안 보게 되니, 서로 방치하는 상태가 된다.
버그가 나도 FE 문제인지 BE 문제인지 구분할 수 없다.

해법은 BE와 디자인을 정본으로 삼는 것이다.

대상	원칙
BE	FE 독자 모델·어댑터·중간 레이어를 걷어 내고 BE 인터페이스를 그대로 따른다. 바뀌면 바로 에러가 나서 원인이 어디인지 쉽게 드러난다
디자인	마음에 안 들어도 디자인이 준 컴포넌트·CSS를 최대한 그대로 쓴다. 정리한 컴포넌트는 디자인 레포에 PR로 돌려준다
기획	프로토타입의 기능을 최대한 그대로 반영하고, 모은 부품은 다음 프로토타입의 재료로 제공한다

화면 데이터가 달라 FE 모델이 꼭 필요한 경우는 예외다. 원칙은 "무조건 BE에 맞춘다"가 아니라 "필요 없는 차이를 만들지 않는다"다. AI 시대에 코드를 더 많이 만드는 것은 쉽다. 통합을 책임지는 쪽은 코드를 줄이는 사람이어야 한다. AI는 필요 없는 코드를 많이 만든다.

AI에게 눈을 달아 준다

문제는 대개 화면에서 먼저 보이므로 FE로 들어온다. 원인은 FE, BE, 파이프라인, 변환, 기획 중 어디든 될 수 있다. AI는 해결 능력이 있지만 스스로 문제를 발견하지 못한다. 그래서 발견할 수 있는 환경을 만든다.

통로	효과
런타임 에러·로그 통로(UI, 콘솔, 다운로드)	실행 중 생긴 에러를 AI가 직접 본다. 필요할 때 로그를 찍고 지우는 것도 AI가 한다. 처음부터 모든 로그를 쌓지는 않는다(로그 지옥)
공통 에러 처리 기준	통로가 없으면 AI가 작업마다 토스트, 별도 화면, 콘솔로 제각각 에러 UI를 만든다
모노레포 + 잘 쓴 이슈 + 기획 문서 위치 명시	필요한 맥락을 AI가 직접 찾는다. 사람이 자료를 골라 줄 필요가 없다
디자인 diff, 상태 재현 사이트	화면 문제를 AI가 스스로 재현하고 비교한다

이 통로가 갖춰지면 AI가 QA 이슈를 스스로 판단하고 처리하는 비율이 크게 오른다.

역할의 변화와 남는 질문

FE의 일은 수렴, 통합, 완성도로 모인다. 화면은 예쁜데 기능이 안 되거나, 기능은 되는데 디자인이 엉망이면 둘 다 완성된 제품이 아니다. 그런데 완성도를 책임진다고 모든 것을 고칠 수 있는 것은 아니다. BE·디자인·기획의 결과에 크게 의존하므로, 원인을 찾아 전달하고 기다렸다가 다시 확인하는 일까지가 FE의 작업이 된다.

이 변화에는 아이러니가 있다.

FE를 얇게 만드는 선택이 FE의 일을 줄인다. 복잡성을 없애는 데 경험을 썼더니 복잡성을 다루던 일 자체가 줄어든다. 그렇다고 역할을 지키려 불필요한 복잡함을 남길 수는 없다.
잘 갖춘 환경은 누구의 에이전트든 쓴다. 정본과 관측 통로가 갖춰지면 BE 쪽에서 정기적으로 도는 에이전트가 FE의 일상적인 QA 이슈까지 처리한다. FE는 Ops처럼 다른 사람이 그 위에서 일하는 인프라에 가까워진다.
지금 남은 일을 전문성으로 정의하면 그 일이 자동화될 때마다 다시 설명해야 한다. 리팩터링 → 통합 → 유지보수 순으로 일이 넘어간다.
사람의 개입은 "멈추고 묻기"로 줄어든다. AI가 해결책을 이미 아는 상황에서 사람이 보탠 것은 언제 멈추고 무엇부터 끝낼지 판단한 것이다. AI가 스스로 목적 이탈을 점검하게 되면 이 개입도 줄어든다.

남는 능력은 어색한 모듈 묶음, 유독 오래 걸리는 작업을 알아채는 판단이다. 이 감각은 직접 짜고 잘못 설계해 고생하며 생겼다. AI가 대부분을 쓰게 되면 이 경험을 무엇으로 쌓을지, 리뷰하는 경험이 만드는 경험과 같은지는 열린 질문이다. 직접 뛰는 선수보다 무엇을 맡기고 언제 개입할지 정하는 감독에 가까운 일이지만, 그 성과를 무엇으로 잴지도 아직 정해지지 않았다. 확실한 것은 시간을 아낀 만큼 여유가 생기지는 않는다는 점이다. 미뤄 두던 재현·비교·관측 같은 일이 그 자리를 채운다.

정리

금지 규칙으로 좋은 코드를 강제하지 말고, 먼저 구현하게 한 뒤 내가 고치는 방식을 대화로 뽑아 스킬로 만든다.
이해는 문서가 아니라 구조를 직접 바꾸는 경험에서 생긴다. 맥락은 별도 문서 대신 이슈(계약)와 PR(증거)에 둔다.
디자인 일치는 정확히 옮기라고 반복하지 말고 같은 코드 공유 + 픽셀 diff + 상태 재현 환경으로 AI가 스스로 수렴하게 한다.
BE와 디자인을 정본으로 삼아 FE를 얇게 하고, AI에게 에러·로그·재현 통로를 달아 스스로 문제를 발견하게 한다.
각자의 속도가 팀의 속도는 아니다. 덜어 낸 글과 "지금 무엇을 왜 하는지"를 나누는 대화가 통합 비용을 줄인다.

버그 제보