사업

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

문제명은 카피가 아니라 조직 안에서 예산과 책임자를 만드는 언어다. 기술 부채, 알림 피로, 다크 패턴, 제로 트러스트, 섀도 AI 사례로 보는 문제명 설계법.

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

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

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

이건 단순한 불편이 아니라, 반복해서 비용을 만드는 문제입니다.

그 순간부터 대화가 달라진다. 개인의 예민함이 조직의 리스크가 되고, 막연한 찝찝함이 책임자의 과제가 되고, "나중에 보자"가 "이번 분기에 줄이자"로 바뀐다.

좋은 문제명은 카피가 아니다. 좋은 문제명은 고객 조직 안에서 이동할 수 있는 언어다.

기술 부채는 지저분한 코드를 예산 언어로 바꿨다

개발팀은 오래전부터 오래된 코드 때문에 고생했다. 작은 기능 하나를 고치려고 해도 엉뚱한 곳이 깨지고, 새로 온 개발자는 구조를 이해하지 못하고, 테스트를 붙이려 하면 이미 너무 복잡하다. 하지만 이 상태를 "코드가 지저분해요"라고 말하면 예산이 잘 붙지 않는다.

그 말은 취향처럼 들린다. 완벽주의처럼 들린다. 경영자는 이렇게 묻는다.

"그래도 돌아가잖아요?"

technical debt라는 이름은 이 장면을 바꿨다. Ward Cunningham이 만든 이 은유는 나쁜 코드의 문제를 재무 언어로 번역했다. 지금 빨리 가려고 빌린 시간이 미래 변경 비용의 이자로 돌아온다는 설명이다. Martin Fowler도 이 은유를 설명하면서, 내부 품질 저하 때문에 새 기능을 붙이는 데 추가로 드는 노력을 "이자"로 볼 수 있다고 정리한다.

이름이 붙자 문제는 개발자 불평에서 투자 판단으로 이동했다. 리팩터링, 코드 품질 도구, 아키텍처 리뷰, 테스트 자동화가 "깔끔하게 만들기"가 아니라 미래 변경 비용을 낮추는 일로 설명되기 시작했다.

같은 현실인데 언어가 바뀌자 예산의 방이 생긴 것이다.

알림 피로는 시끄러운 알림을 안전 문제로 바꿨다

alert fatigue도 마찬가지다.

"알림이 너무 많아요"는 불평이다. 하지만 알림 피로는 리스크다. 중요한 신호를 놓치게 만드는 운영 실패다. 병원에서도, 보안 조직에서도, 인프라 팀에서도 이 이름이 붙는 순간 문제의 격이 달라진다.

The Joint Commission은 2013년 병원 의료기기 알람 안전에 대한 Sentinel Event Alert에서 병원 단위로 하루 수천, 병원 전체로는 수만 개의 알람이 울릴 수 있고, 85-99%의 알람은 임상 개입이 필요하지 않은 경우라고 설명했다. 그 결과 임상의가 알람에 둔감해지고 압도되는 상태, 즉 alarm fatigue가 생긴다. 같은 문서는 2009년 1월부터 2012년 6월까지 보고된 98건의 알람 관련 sentinel event 중 80건이 사망으로 이어졌다고 적었다.

이 데이터가 중요한 이유는 숫자 자체보다 프레이밍이다. 알림이 많다는 것은 더 이상 "현장이 바쁘다"가 아니다. 알림 설계, 우선순위, 응답 프로세스, staffing, 교육, 장비 설정의 문제다. 즉 개인이 참아야 할 소음이 아니라 시스템이 줄여야 할 위험이다.

좋은 문제명은 이렇게 책임의 위치를 바꾼다.

다크 패턴은 찝찝한 UX를 규제 가능한 대상으로 만들었다

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

"뭔가 속는 느낌"이었다.

Harry Brignull이 밀어낸 dark patterns, 지금은 더 넓게 deceptive patterns라고도 부르는 이 이름은 그 찝찝함을 설계된 조작으로 바꿨다. Deceptive Patterns 사이트는 이들을 사용자가 원하지 않은 행동을 하게 만들거나 해로운 결정을 하도록 유도하는 앱, 웹사이트, AI 시스템의 기능으로 설명한다.

이 이름이 붙자 문제는 개인 감상에서 소비자 보호, UX 윤리, 규제, 감사의 언어로 이동했다. 전에는 "디자인이 좀 별로다"였던 것이 이제는 "사용자를 오도하는 패턴인가"라는 질문이 됐다.

이름은 현상을 고발 가능한 단위로 만든다.

제로 트러스트는 보안의 적을 다시 정했다

zero trust도 강한 문제명이다.

예전 보안의 기본값은 내부망을 믿는 것이었다. 회사 네트워크 안에 있으면 어느 정도 안전하다고 봤다. 그런데 클라우드, SaaS, 원격근무, 모바일, 협력사 접근이 늘어나면서 "안쪽은 믿어도 된다"는 전제가 흔들렸다.

NIST SP 800-207은 제로 트러스트를 정적 네트워크 경계 중심의 방어에서 사용자, 자산, 리소스 중심으로 이동하는 보안 패러다임이라고 설명한다. 그리고 네트워크 위치나 자산 소유 여부만으로 암묵적 신뢰를 주지 않는다고 정리한다.

이 이름의 힘은 솔루션 목록이 아니라 전제 공격에 있다. 문제는 해커가 밖에 있다는 것이 아니라, "안쪽은 믿어도 된다"는 믿음 자체라는 식으로 현실을 다시 자른다. 그래서 ID, 접근 제어, 디바이스 posture, 네트워크 세분화, 정책 엔진, 감사 로그가 하나의 예산 언어 아래 묶인다.

좋은 문제명은 도구 여러 개를 하나의 운영 원칙으로 모은다.

섀도 AI는 직원의 편법을 거버넌스 공백으로 바꿨다

AI 시대에는 이 원리가 더 중요해진다.

직원들이 개인 계정으로 ChatGPT, Claude, Perplexity, 각종 자동화 도구를 쓰는 현상은 처음엔 잡담처럼 들린다.

"요즘 다들 쓰지 뭐."

하지만 shadow AI라고 부르는 순간 이야기가 달라진다. 이건 단순한 생산성 꼼수가 아니라 보안, 컴플라이언스, 데이터 거버넌스, 교육, 구매 정책의 문제다.

Microsoft와 LinkedIn의 2024 Work Trend Index는 지식 노동자 사이에서 생성형 AI 사용이 빠르게 늘었고, AI 사용자 중 78%가 자기 AI 도구를 업무에 가져오고 있다고 보고했다. 이 보고서는 이런 흐름이 전략적 AI 활용의 이점을 놓치게 하고 회사 데이터를 위험에 놓을 수 있다고 봤다.

여기서도 이름이 핵심이다. "직원이 몰래 AI를 씁니다"는 관리자의 짜증이다. "섀도 AI가 고객 데이터와 내부 문서를 승인되지 않은 모델로 흘려보낼 수 있습니다"는 경영 의제다.

이름이 붙기 전에는 개인의 편법이지만, 이름이 붙은 뒤에는 조직의 통제 공백이다.

FinOps는 클라우드 비용을 협업 구조로 바꿨다

문제명은 꼭 공포만 팔 필요는 없다. 더 좋은 운영 방식을 여는 이름도 있다.

FinOps가 그렇다. 클라우드 비용은 오래전부터 문제였다. 엔지니어는 속도를 원하고, 재무팀은 예측 가능성을 원하고, 사업팀은 제품 성장을 원한다. 예전 언어로는 이 문제가 "클라우드 비용 절감"처럼 들리기 쉽다. 그러면 논의가 금방 줄이기, 막기, 승인받기로 흐른다.

FinOps Foundation은 FinOps를 기술의 비즈니스 가치를 극대화하고, 데이터 기반 의사결정을 가능하게 하며, 엔지니어링·재무·비즈니스 팀의 협업을 통해 재무 책임성을 만드는 운영 프레임워크이자 문화적 실천으로 설명한다.

좋은 이름 하나가 "비용 줄이기"를 "속도, 비용, 품질 사이의 trade-off를 함께 결정하는 운영 모델"로 넓힌다. 그래서 FinOps는 도구 카테고리만 만든 것이 아니라 역할, 회의, 지표, 인증, 플레이북, 커뮤니티를 만들었다.

문제명은 시장을 만들 때도 강하지만, 운영 방식을 제도화할 때도 강하다.

이름은 포장이 아니라 현실을 자르는 방식이다

이 사례들의 공통점은 단순하다.

사람들은 이미 불편함을 겪고 있었다.

오래된 코드는 이미 느렸다. 병원 알람은 이미 너무 많았다. 이상한 UX는 이미 사용자를 속이고 있었다. 내부망 신뢰 모델은 이미 낡고 있었다. 직원들은 이미 개인 AI 도구를 쓰고 있었다. 클라우드 비용은 이미 여기저기 새고 있었다.

하지만 이름이 없으면 불편함은 조직 안에서 이동하지 못한다.

언어가 없으면 담당자가 없다. 담당자가 없으면 회의가 없다. 회의가 없으면 예산이 없다. 예산이 없으면 시장도 없다.

그래서 좋은 사업은 솔루션을 먼저 만드는 게임이 아니다. 고객이 이미 겪고 있지만 아직 제대로 부르지 못하는 상태를 찾아낸다. 그리고 그 상태를 고객이 자기 입으로 말할 수 있는 문제명으로 고정한다.

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

좋은 문제명은 네 가지 일을 한다

좋은 문제명은 예쁘지 않아도 된다. 하지만 네 가지 기능은 해야 한다.

1. 흩어진 증상을 하나로 묶는다

고객은 보통 문제를 구조로 말하지 않는다. 장면으로 말한다.

"결재는 됐는데 아무도 다음 액션을 안 해요."
"AI를 쓰긴 쓰는데 결과물이 매번 달라요."
"고객이 좋다고는 하는데 내부 공유에서 멈춰요."
"알림은 많은데 진짜 중요한 게 뭔지 모르겠어요."

좋은 문제명은 이런 장면들을 하나의 패턴으로 묶는다. 묶여야 반복성이 보인다. 반복성이 보여야 해결할 가치가 생긴다.

2. 방치 비용을 말하게 한다

문제명은 "이게 불편하다"에서 멈추면 약하다. "그래서 무엇이 손실되는가"까지 끌고 가야 한다.

기술 부채는 변경 속도의 이자를 말한다. 알림 피로는 중요한 신호를 놓치는 위험을 말한다. 섀도 AI는 데이터 유출과 통제 공백을 말한다. FinOps는 기술 투자 가치와 재무 책임성을 말한다.

좋은 문제명은 고통을 비용으로 번역한다.

3. 책임자와 회의를 만든다

조직은 이름으로 움직인다. 이름이 있어야 누가 책임질지 정할 수 있다. 이 문제가 보안팀의 일인지, 운영팀의 일인지, 제품팀의 일인지, 재무팀의 일인지, 대표의 일인지가 보인다.

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

4. 해결 카테고리를 열어준다

문제명이 강하면 고객은 특정 기능보다 해결 방향을 먼저 이해한다.

"AI 자동화 도구"는 너무 넓다. "승인되지 않은 AI 사용이 고객 데이터를 새게 만드는 섀도 AI를 줄입니다"는 다르다.

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

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

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

나쁜 문제명은 두 방향으로 망한다

문제명에도 실패가 있다.

하나는 너무 넓은 이름이다. "생산성 문제", "AI 전환 문제", "마케팅 문제", "고객 경험 문제"처럼 거의 모든 것을 담을 수 있는 이름은 아무것도 자르지 못한다. 이런 말은 회의에서 고개를 끄덕이게는 하지만 결정을 만들지 못한다.

다른 하나는 너무 멋있는 이름이다. 고객이 자기 입으로 말하기 민망한 조어, 내부 팀만 이해하는 은어, 컨설팅 슬라이드처럼 들리는 말은 퍼지지 않는다. 좋은 문제명은 똑똑해 보이는 말이 아니라 고객이 훔쳐 쓰고 싶어지는 말이다.

좋은 이름은 새로워야 하지만 낯설기만 해서는 안 된다. 익숙한 장면을 더 정확하게 잡아야 한다.

AI 시대에는 문제명이 더 중요해진다

AI가 바꾸는 것은 제품 제작 비용이다. 예전에는 프로토타입 하나를 만드는 데 팀과 시간과 돈이 많이 들었다. 이제는 혼자서도 랜딩페이지를 만들고, 데모를 찍고, 자동화를 붙이고, 코드 초안을 만들고, 고객별 제안서를 뽑을 수 있다.

실행이 싸지면 실행 자체는 차별점이 덜 된다.

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

누가 더 빨리 만드는가보다, 누가 더 정확히 이름 붙이는가가 중요해진다. AI로 누구나 솔루션을 만들 수 있다면, 고객이 아직 부르지 못하는 문제를 먼저 발견하고, 그 문제를 고객 조직 안에서 이동 가능한 언어로 만드는 사람이 앞선다.

이것은 마케팅 문장 하나의 문제가 아니다. 제품 전략의 시작점이다. 어떤 문제명을 잡느냐에 따라 기능 우선순위, 랜딩페이지, 세일즈 자료, 콘텐츠, 가격표, 고객 인터뷰 질문, 성공 사례의 모양이 달라진다.

제품은 문제명의 증거가 되어야 한다.

문제명을 만들 때 던질 질문

창업자와 마케터가 "무슨 솔루션을 만들까"보다 먼저 봐야 할 것은 고객의 아직 이름 없는 반복 장면이다. 아래 질문으로 시작하면 된다.

고객이 반복해서 겪지만 "원래 그런 것"으로 넘기는 장면은 무엇인가?
그 장면이 방치되면 시간, 돈, 리스크, 신뢰, 속도 중 무엇이 손실되는가?
이 문제를 고객 조직 안에서 처음 말할 사람은 누구인가?
그 사람이 상사에게 가져갈 수 있는 한 문장은 무엇인가?
기존 대안은 왜 이 문제를 정확히 해결하지 못하는가?
이름을 들은 고객이 "아, 우리가 겪는 게 이거였구나"라고 말할 수 있는가?
그 이름 아래 사례, 체크리스트, 진단, 템플릿, 도구, 서비스가 붙을 수 있는가?

이 질문에 답하지 못하면 아직 오퍼를 만들 때가 아닐 수 있다. 고객의 고통은 있을지 몰라도 구매 가능한 문제로 굳지 않았기 때문이다.

문제명 캔버스

한 장으로 정리하면 이렇게 쓸 수 있다.

반복 장면: 고객이 실제로 겪는 구체적 상황
흐릿한 말: 지금 고객이 대충 부르는 표현
방치 비용: 해결하지 않으면 생기는 손실
책임자: 이 문제를 조직 안에서 들고 갈 사람
문제명: 고객이 자기 입으로 말할 수 있는 이름
예산 문장: 왜 지금 돈을 써야 하는지 설명하는 한 문장
증거: 사례, 데이터, 전후 비교, 진단 결과
출구: 이 문제에서 빠져나가기 위해 사야 할 제품, 서비스, 템플릿, 운영 루틴

문제명이 강해지면 카피가 쉬워진다. 카피가 쉬워지는 이유는 문장이 좋아져서가 아니다. 팔아야 할 현실이 선명해졌기 때문이다.

끝내 이름 붙은 문제에만 돈이 붙는다

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

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

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

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

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

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

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