마찰은 기능이다 — AI가 낮춘 제작 비용과 판단의 공백

Emil Kowalski의 글 Friction as a Feature는 제품이 줄이려 하는 **마찰(friction)**을 다른 각도에서 바라본다. 마찰은 느리고, 비효율적이며, 번거롭다. 그래서 제품은 오랫동안 마찰을 제거하는 방향으로 발전해 왔다. 하지만 제작 과정의 마찰에는 우리가 놓치기 쉬운 두 번째 역할이 있었다. 무엇을 만들기 전에 한 번 더 생각하게 만드는 문턱이었다.

이 글은 AI를 쓰지 말자거나 과거의 느린 제작 과정을 되살리자는 주장이 아니다. AI가 낮춘 제작 비용을 그대로 누리되, 그 비용이 우연히 담당했던 판단 기능을 제품과 팀의 과정 안에 다시 설계해야 한다는 제안이다.

마찰은 왜 나쁜 말이 되었나

사용자 경험에서 마찰을 줄이는 일은 대체로 옳다. 결제 단계의 불필요한 입력, 앱이 반응하기 전의 긴 대기, 무엇을 눌러야 할지 알 수 없는 화면은 사용자의 목표를 방해한다. 제품이 이런 마찰을 없애면 사용자는 더 빠르고 자신 있게 일을 끝낼 수 있다.

문제는 모든 마찰을 같은 종류로 취급할 때 생긴다. 사용자의 행동을 막는 마찰과 제작자의 판단을 돕는 마찰은 다르다. 전자는 줄여야 하지만, 후자는 사라질 때 품질 필터도 함께 약해질 수 있다.

Kowalski가 말하는 핵심은 두 번째 열을 첫 번째 열과 함께 없애지 말자는 데 있다. 마찰은 불편함이기만 한 것이 아니라, 때로는 판단을 발생시키는 비용이기도 했다.

제작 비용은 보이지 않는 품질 필터였다

AI 이전에는 코드를 쓰는 일이 비쌌다. 아이디어를 실제 앱으로 만들려면 API를 조사하고, 라이브러리를 연결하고, 오류를 고치고, 운영 환경에 배포해야 했다. 이 비용이 품질을 보장한 것은 아니다. 다만 아무 아이디어나 바로 구현하지는 못하게 했다.

제작에 시간이 걸리면 사람은 자연스럽게 질문한다.

• 이 문제가 정말 중요한가?
• 지금 이 기능을 만들어야 하는가?
• 이 아이디어에 며칠을 쓸 가치가 있는가?

이 질문에 대한 답이 명확하지 않으면 구현을 시작하기가 어려웠다. 다시 말해 제작 비용은 아이디어가 살아남기 위해 통과해야 하는 문턱이었다.

AI는 이 문턱을 크게 낮췄다. 이제 아이디어가 몇 분 안에 앱이나 화면으로 바뀔 수 있다. 이는 분명한 이점이다. 구현 전에 상상만 하던 대안을 실제로 만들어 비교할 수 있고, 작은 실험을 더 많이 할 수 있다. 원문도 값싼 제작이 사고의 한 방식이 될 수 있다는 점은 인정한다.

다만 프로토타입을 만드는 일과 아이디어를 검증하는 일은 다르다. A와 B를 모두 만들 수 있다는 사실은 A와 B 중 하나가 가치 있다는 증거가 아니다.

AI는 만들기와 검증을 혼동하게 한다

제작 비용이 거의 없어지면 두 가지 유혹이 생긴다. 첫째, 검증이 끝나지 않은 아이디어도 계속 만들 수 있다. 둘째, 결과물이 존재한다는 사실을 수요가 있다는 증거처럼 받아들이기 쉽다.

원문이 지적하는 바이브 코딩 앱과 UI 라이브러리의 문제도 여기에 있다. 문제는 AI가 만들었다는 사실 자체가 아니다. 무엇을 위해 만들어졌는지, 어떤 제약을 고려했는지, 어떤 선택을 거쳐 지금의 형태가 되었는지가 보이지 않는다는 점이다. 결과물은 작동할 수 있지만, 설계된 느낌보다 그냥 존재하는 느낌을 준다.

좋은 결과물에는 대개 선택의 흔적이 있다. 누구를 위한 것인지, 무엇을 하지 않기로 했는지, 어떤 예외를 우선했는지, 어떤 불편을 감수했는지가 형태에 남는다. 이런 선택이 없으면 표면은 매끈해도 결과물은 비어 보인다.

이 구분은 AI가 만든 결과물을 평가할 때 특히 중요하다. 사람이 만들었는지 AI가 만들었는지를 맞히는 일보다, 결과물이 명확한 문제와 기준을 통과했는지를 확인하는 일이 더 중요하다. 출처보다 의도와 검증 가능성이 품질을 가른다.

마찰이 사라지면 결과물이 비어 보이는 이유

Kowalski의 표현을 빌리면 마찰이 사라진 뒤 남는 것은 출력물뿐이다. 만드는 과정에서 고민하고, 비교하고, 버리고, 다시 선택하는 단계가 약해지면 결과물에 맥락이 남지 않는다. 그래서 비슷한 화면과 컴포넌트가 늘어나도 서로 다른 문제를 해결한다는 느낌을 주지 못한다.

여기서 말하는 품질은 시각적 장식이나 복잡한 애니메이션만을 뜻하지 않는다. 다음과 같은 질문에 답할 수 있는 상태에 가깝다.

• 이 기능이 존재해야 하는 이유는 무엇인가?
• 이 결과가 충분하다고 판단한 근거는 무엇인가?
• 사용자가 실패할 때 제품은 무엇을 알려주는가?
• 어떤 증거가 나오면 이 기능을 줄이거나 없앨 것인가?

이 질문에 답하는 과정은 느릴 수 있다. 그러나 이 느림이 결과물의 목표와 경계를 선명하게 한다. 마찰은 최종 사용자에게 떠넘기는 장애물이 아니라, 제작자가 결정을 내리도록 돕는 내부 장치가 될 수 있다.

기능으로서 마찰을 다시 설계하는 법

과거의 제작 비용을 그대로 복원할 필요는 없다. AI가 후보를 빠르게 만들 수 있다는 장점은 유지하면서, 후보를 채택하는 과정에 판단의 문턱을 넣으면 된다. 실무에서는 다음과 같은 방식으로 시작할 수 있다.

1. 만들기 전에 문제를 한 문장으로 고정한다. 누가 어떤 상황에서 무엇을 해결하려는지 적는다. 문제 정의가 흔들린 채 화면부터 만들면 후보의 개수만 늘어난다.
2. 후보와 채택을 분리한다. AI에게 여러 안을 만들게 할 수 있지만, 각 안을 비교할 기준과 최종 책임자를 정한다. 많이 만든 사실은 채택 사유가 아니다.
3. 작동 여부와 가치 여부를 따로 확인한다. 테스트 통과, 렌더링 성공, 배포 가능성은 기술적 조건이다. 사용자가 필요로 하는지, 반복해서 쓰는지는 별도의 증거가 필요하다.
4. 검증 지점을 작업 흐름에 넣는다. 실제 사용자 관찰, 인터뷰, 사용 로그, 실패 사례 중 적절한 증거를 정하고 다음 제작 단계로 넘어가기 전에 확인한다.
5. 중단 조건을 먼저 쓴다. 어떤 반응이나 수치가 나오면 기능을 축소하거나 버릴지 정한다. 시작 조건만 있고 중단 조건이 없으면 낮은 비용이 무한한 범위 확장으로 이어진다.

이 과정은 AI를 느리게 만드는 장치가 아니다. 오히려 값싼 제작을 값싼 학습으로 바꾸는 장치다. 후보를 만드는 속도는 유지하되, 무엇을 현실에 남길지 결정하는 속도와 기준을 관리한다.

팀이 측정해야 할 것은 생성량만이 아니다

AI 도입 뒤 팀이 코드 줄 수, 생성한 화면 수, 출시한 기능 수만 측정하면 제작 비용이 낮아진 효과만 보게 된다. 그 지표는 무엇을 만들지 말아야 했는지 알려주지 않는다.

팀은 다음과 같은 신호도 기록할 필요가 있다.

• 만들기 전에 중단된 아이디어의 비율
• 실제 사용자 증거를 확인한 뒤 수정되거나 폐기된 기능
• 기능을 채택한 기준과 책임자
• 출시 후 어떤 가정이 틀렸는지 알게 된 시점
• 만들지 않기로 한 결정이 막아낸 비용과 위험

이런 기록을 성과 경쟁으로 만들면 또 다른 형식주의가 된다. 목적은 사람을 더 많이 검토하게 만드는 것이 아니라, 제작과 판단이 서로 다른 활동이라는 사실을 조직이 잊지 않게 하는 데 있다.

결국 필요한 것은 생산 단계의 마찰은 낮추고, 판단 단계의 마찰은 의식적으로 보존하는 구조다. AI가 초안을 빠르게 만들수록 팀은 오히려 기준, 증거, 책임, 중단 조건을 더 분명히 해야 한다.

결론 및 시사점

한 줄 결론: AI가 제작 비용을 없앨수록, 좋은 제품을 만드는 팀은 마찰을 제거하는 데서 멈추지 않고 판단을 지키는 마찰을 다시 설계해야 한다.

Emil Kowalski의 글은 마찰을 무조건 되돌리자는 주장이 아니다. 사용자의 목표를 방해하는 불편은 계속 줄여야 한다. 대신 제작자가 무엇을 만들지 선택하고, 결과를 검증하고, 틀린 방향을 버리게 만드는 문턱까지 없애면 안 된다는 뜻이다.

AI는 가능한 결과의 수를 폭발적으로 늘린다. 그만큼 희소해지는 것은 제작 능력이 아니라 선택 기준과 검증 능력이다. AI를 잘 쓰는 제품과 팀은 가장 많은 것을 만든 곳이 아니라, 무엇을 만들지 않았고 왜 남은 결과물을 선택했는지 설명할 수 있는 곳이다.