중요한 건 더 좋은 도구를 쓰느냐가 아닌 것 같다.
중요한 건 시스템적 사고를 하느냐, 맥락을 파악하느냐, 역산하여 추론할 수 있느냐, 그리고 이 사고 프레임을 얼마나 일관되게 하느냐인 것 같다.
도구 의존의 함정
더 좋은 모델, 더 좋은 스킬, 플러그인, MCP. 이것들을 적용하기 이전에, 에이전트들의 오케스트레이터인 유저 자신이 더 좋은 사고 프레임을 갖추어야 한다고 생각한다. 어려운 일이다.
이건 AI 에이전트만의 이야기가 아니다. 사업도 마찬가지다.
크몽 외주 300만원 vs 올인원 300만원에서 이야기했듯이, 예쁜 홈페이지라는 "도구"를 갖추는 것과, 비즈니스 설계라는 "사고 프레임"을 갖추는 건 완전히 다른 것이다.
도구는 바꿀 수 있다. 프레임은 쌓아야 한다.
시스템적 사고란
시스템적 사고는 문제를 개별 이벤트가 아니라 구조로 보는 것이다.
"고객 문의가 느리다" → 이건 이벤트다. "문의가 카톡/이메일/전화로 분산되어 있고, 담당자가 1명이고, 각 채널을 수동으로 확인해야 한다" → 이건 구조다.
이벤트에 대응하면 하나만 고친다. 구조를 고치면 전부 바뀐다.
비즈니스 설계 없이 개발하면 벌어지는 일에서 "설계단이 체계가 없고 부실하면 구현단으로도 제대로 못 간다"고 했다. 이것도 같은 이야기다. 구조를 먼저 잡아야 한다.
역산 추론
내가 자주 쓰는 방법은 역산이다.
목표에서 거꾸로 내려오는 것이다. "매출을 올리고 싶다" → "그러려면 전환율을 올려야 한다" → "그러려면 방문자가 행동하게 만들어야 한다" → "그러려면 방문자의 문제를 정확히 짚어야 한다" → "그러려면 페르소나가 정의되어야 한다."
역산하면 지금 당장 해야 할 것이 명확해진다. 순방향으로 가면 "일단 이것도 해보고 저것도 해보자"가 된다. 자원이 분산되고 어디에도 제대로 도달하지 못한다.
일관성
사고 프레임이 좋아도, 일관적이지 않으면 소용없다.
한 번은 역산으로 접근하고, 다음번에는 감으로 접근하고, 그 다음에는 누가 추천해서 따라가고. 이러면 결과물이 들쭉날쭉하다.
좋은 프레임을 갖추는 것보다 어려운 건, 그 프레임을 매번 일관되게 적용하는 것이다. 도구는 바꿔도 된다. 프레임은 흔들리면 안 된다.
studio.bth에 적용하는 방법
studio.bth가 모든 프로젝트에 "비즈니스 설계부터 시작한다"고 하는 건, 이 사고 프레임을 시스템으로 강제하는 것이다.
표준 설계 문서 패키지가 있고, 체크리스트가 있고, 각 단계를 건너뛸 수 없게 만들어놨다. 사람에 의존하면 일관성이 깨진다. 시스템으로 강제해야 매번 같은 품질이 나온다.