이름 없는 문제는 팔리지 않는다

문제에 이름이 붙는 순간, 불편함은 비용이 되고 비용은 시장이 된다.

사람은 대부분의 불편함에 적응한다. 코드가 지저분한 것도, 알림이 너무 많은 것도, 직원들이 승인받지 않은 도구를 쓰는 것도 처음에는 그냥 "원래 일이 그렇지" 정도로 지나간다. 짜증은 나지만 예산은 안 붙는다. 불편하지만 회의 안건은 안 된다. 모두가 알고 있지만 아무도 책임지지 않는다.

그러다 누군가 이름을 붙인다.

technical debt.

그 순간 "코드가 좀 지저분하다"는 개발자의 취향 문제가 아니게 된다. 미래의 변경 속도에 이자가 붙는다는 말이 된다. 오늘 빨리 가려고 빌린 시간이 내일의 비용으로 돌아온다는 설명이 된다. 이름이 붙자마자 CTO가 말할 수 있고, PM이 일정에 반영할 수 있고, CEO가 투자 판단에 넣을 수 있다.

같은 현실인데 언어가 바뀌자 예산의 언어가 된다.

alert fatigue도 마찬가지다.

"알림이 너무 많아요"는 불평이다. 하지만 alert fatigue는 리스크다. 중요한 경보를 놓치게 만드는 운영 실패다. 병원에서도, 보안 조직에서도, 인프라 팀에서도 이 이름이 붙는 순간 문제의 격이 달라진다. 직원이 예민한 게 아니라 시스템이 사람의 주의력을 망가뜨리고 있는 것이다.

shadow AI라는 말도 그렇다.

직원들이 몰래 ChatGPT를 쓴다는 말은 처음엔 잡담처럼 들린다. "요즘 다들 쓰지 뭐." 그런데 shadow AI라고 부르는 순간 이건 보안, 컴플라이언스, 데이터 거버넌스 문제가 된다. 회사가 승인하지 않은 AI 도구 안으로 고객 정보와 내부 문서가 흘러갈 수 있다는 뜻이 된다. 이름이 붙기 전에는 개인의 편법이지만, 이름이 붙은 뒤에는 조직의 통제 공백이다.

좋은 사업은 여기서 시작한다.

솔루션을 먼저 만드는 게 아니다. 고객이 이미 겪고 있지만 아직 제대로 부르지 못하는 상태를 찾아낸다. 그리고 그 상태에 이름을 붙인다.

이름은 단순한 포장이 아니다. 이름은 현실을 자르는 방식이다. 같은 현상도 어떻게 부르느냐에 따라 짜증이 되기도 하고, 손실이 되기도 하고, 리스크가 되기도 하고, 시장이 되기도 한다.

dark patterns라는 말이 나오기 전에도 사람들은 이상한 UX를 겪고 있었다. 탈퇴 버튼은 숨어 있고, 결제 취소는 복잡하고, 동의 버튼은 크게 보이고 거절 버튼은 작게 보였다. 사용자는 찝찝했지만 설명하기 어려웠다. "뭔가 속는 느낌"이었다.

그런데 dark patterns라는 이름이 붙자, 그 찝찝함은 설계된 조작이 됐다. 소비자 보호, 규제, 감사, UX 윤리의 언어가 됐다.

zero trust도 비슷하다.

예전 보안의 기본값은 내부망을 믿는 것이었다. 회사 네트워크 안에 있으면 어느 정도 안전하다고 봤다. 그런데 zero trust는 그 전제를 뒤집었다. 문제는 해커가 밖에 있다는 게 아니라, "안쪽은 믿어도 된다"는 믿음 자체라는 식으로 현실을 다시 명명했다. 그래서 보안 제품도, 조직 구조도, 접근 권한 설계도 바뀌었다.

이런 이름들은 유행어가 아니다.

잘 붙은 이름은 고객의 머릿속에서 흩어져 있던 경험을 한 덩어리로 묶는다.

"아, 우리가 겪는 게 이거였구나."

이 문장이 나오는 순간 영업은 쉬워진다. 고객을 설득할 필요가 줄어든다. 이미 겪고 있던 현실에 라벨이 붙었기 때문이다. 좋은 문제명은 새로운 욕망을 발명하지 않는다. 이미 있던 고통을 구매 가능한 문제로 바꾼다.

그래서 창업자는 "무슨 솔루션을 만들까"보다 먼저 "고객이 아직 뭐라고 부르지 못하고 있나"를 봐야 한다.

고객은 문제를 모르는 게 아니다. 겪고 있다. 다만 언어가 없어서 조직 안에서 이동하지 못한다. 언어가 없으면 담당자가 없다. 담당자가 없으면 예산이 없다. 예산이 없으면 시장이 없다.

AI 시대에는 이 차이가 더 커진다.

솔루션을 만드는 비용은 계속 내려간다. 예전에는 제품을 만드는 데 팀과 시간과 돈이 많이 들었다. 이제는 혼자서도 프로토타입을 만들고, 자동화를 붙이고, 랜딩페이지를 만들고, 데모를 찍을 수 있다. 실행이 싸지면 실행 자체는 차별점이 덜 된다.

그때 남는 것은 문제를 보는 눈이다.

누가 더 빨리 만드는가보다, 누가 더 정확히 이름 붙이는가가 중요해진다.

"AI로 업무 자동화합니다"는 너무 넓다. "승인되지 않은 AI 사용이 고객 데이터를 새게 만드는 문제를 막습니다"는 다르다.

"알림을 정리합니다"와 "중요 경보를 놓치게 만드는 alert fatigue를 줄입니다"도 다르다.

"코드를 리팩터링합니다"와 "technical debt의 이자를 줄입니다"도 다르다.

사람은 솔루션을 사는 것처럼 보이지만, 실제로는 자기 문제가 제대로 정의됐다는 확신을 산다.

좋은 이름은 고객에게 거울을 들이민다.

좋은 문제 정의는 고객 대신 회의실에 들어간다.

좋은 카테고리는 예산 항목이 된다.

그러니까 사업은 "내가 팔고 싶은 것"을 멋지게 설명하는 게임이 아니다. 고객이 이미 겪고 있는 현실을 더 정확한 언어로 잡아내는 게임이다.

이름 없는 불편함은 참는다.

이름 붙은 문제는 해결한다.

그리고 해결해야 하는 문제에만 돈이 붙는다.