# 조용한 제품을 만드는 메모 > 직접 지원이 조사일 때, 자동화가 자리를 얻을 때, 절제가 작은 제품을 이해하고 신뢰 가능하게 유지하는 방식. Published: 2026-06-02 | Updated: 2026-08-08 Mole for Mac이 출시 약 세 주 만에 작은 매출 이정표를 넘었습니다. 숫자 이야기를 쓰기보다, 그동안 제가 내린 몇 가지 선택을 정리하고 싶습니다. 대부분 현업 엔지니어의 본능과는 반대 방향이고, 그래도 저는 가장 먼저 지키고 싶은 선택들입니다. 직접 제품을 만들고 계시다면, 그중 일부가 우회로를 줄여 줄 수도 있습니다. ## 모든 이메일에 직접 답합니다 출시 이후 지원은 전부 손으로 처리했습니다. 환불, 활성화 초기화, 할인 이후 차액 환불, 평범한 질문까지. 양은 많지 않습니다. 실제로 연락하는 사용자는 전체의 1%에도 훨씬 못 미칩니다. 에이전트를 붙여 반나절이면 자동화할 수도 있었지만, 하지 않았습니다. 이유는 두 가지입니다. 첫째, 지원은 제품이 진실을 말하는 자리입니다. 환불 요청은 왜 실망했는지 알려 줍니다. 어색한 질문은 앱의 어느 부분이 스스로를 설명하지 못하는지 알려 줍니다. 몇 차례 주고받다 보면 사용자가 실제로 원한 것이 드러나고, 그건 처음 물은 것과 다른 경우가 많습니다. 하루부터 자동화를 끼우면, 신호가 가장 필요할 때 그 신호를 잃습니다. 둘째, 모든 케이스를 직접 다루면 유창해집니다. 충분히 반복하면 문제 유형마다 가장 좋은 답을 알게 되고, 질문을 다시 받지 않도록 제품이 흡수해야 할 문제도 알게 됩니다. 양이 늘어 자동화를 도입할 때, 그 자동화는 추측이 아니라 그 유창함을 코드로 담게 됩니다. 자동화의 기준은 티켓 수가 아닙니다. 같은 질문이 반복되고, 답이 안정적이며, 예외를 이해했을 때입니다. 그전까지 messy한 대화가 곧 리서치입니다. 그 지점 이후에는 자동화가 알려진 경로를 처리하고, 특이한 케이스는 사람에게 쉽게 닿도록 하면 됩니다. 지금까지 이 방식은 잘 버티고 있습니다. 마케팅 비용은 쓰지 않았고, 성장은 입소문이며, 환불률은 0.8% 미만입니다. ## 뼈대는 나중에 세워도 됩니다 인프라도 같은 논리입니다. 출시 전에 티켓 시스템, 헬프 데스크, 지식 베이스를 두지 않았습니다. 엔지니어는 지지 구조를 먼저 짓기 쉽습니다. 자신이 잘 만드는 부분이고, AI 덕분에 반나절 일이 되어 더 유혹적이면서도 똑같이 조기 최적화하기 쉽습니다. 그 반나절은 진짜입니다. 아직 필요 없는 시스템을 계속 돌보는 비용도 진짜입니다. 요청이 유실되거나, 응답 시간이 가려지거나, 같은 답이 들쭉날쭉해질 때 시스템을 더하겠습니다. 그 전에는 받은편지함이 더 단순하고 더 많은 정보를 줍니다. ## 무엇을 만들지 않을지 정하기 좋은 제품과 평범한 제품의 차이는, 대부분 거절한 것들에 있습니다. 어떤 기능이 어느 릴리스에 들어갈지, 어떤 요청이 진짜 필요이고 어떤 것은 그렇게 들릴 뿐인지, 그 자체로는 괜찮은 아이디어라도 이 제품에는 맞지 않는 것이 무엇인지. 저는 제안 자체는 좋은 기능을 거절하며 사용자에게 사과한 적이 있습니다. Mac에는 Mole이 하지 말아야 할 멋진 재주가 많습니다. 전부 수락하면 스튜가 되고, 스튜는 유지하기 어렵고 파일 삭제를 맡기기에는 더 신뢰하기 어렵습니다. 제품의 경로를 대략 반년분 머릿속에 둡니다. 각 버전이 무엇을 더하고, 무엇을 빼고, 첫 사용자가 설명 없이도 찾을 수 있도록 어디에 둘지. 흔한 첫 작업에 매뉴얼이 필요하다면, 그 인터페이스는 제가 가장 닿고 싶은 사람들을 실패한 것입니다. 문서화는 깊이, 엣지 케이스, 신뢰를 위해 여전히 중요하지만, 제품의 기본 형태를 구원해 주어서는 안 됩니다. 오래된 면도날이 가장 잘 말합니다. 필요하지 않다면 개체를 더하지 마십시오. 이제는 기능이 로드맵에 오르기 전 세 가지 거부 조건을 둡니다. 사용자가 그 기능에 들어가지 않는 한 상시 타이머, 리스너, 샘플링 비용을 더하지 않습니다. 작은 편의를 위해 특권 헬퍼를 넓히거나 새 권한을 요구하지 않습니다. 차분한 기본값이 모두를 위해 결정할 수 있다면 설정을 추가하지 않습니다. 소프트웨어 전반의 보편 규칙은 아닙니다. 이 제품의 예산입니다. 상주 작업, 특권, 설정은 모두 사용자가 영원히 신뢰해야 하는 표면적의 한 형태입니다.
직접 대화가 사용자 맥락을 유지하다가 반복되는 필요가 제품 적합성, 신뢰와 안전, 자기 설명 게이트를 통과한 뒤에야 고정, 예약 또는 거절되는 제품 결정 루프이며, 조기 자동화는 신호를 잃습니다
직접 대화는 반복되는 필요가 분명해질 때까지 맥락을 지킵니다. 제품 적합성, 신뢰, 자기 설명이 수정, 로드맵 항목, 또는 의도적인 거절을 가릅니다. 좋은 수정은 앞으로 받을 질문을 줄입니다.
## 포지션 Mole의 포지션은 한 문장입니다. Mac을 위한 조용한 관리자. 정리하고, 제거하고, 최적화하고, 분석하고, 지켜보며, 그 외에는 방해하지 않습니다. 야심은 말하기도 단순합니다. 백 명의 Mac 사용자 중 한 명이 Mole을 곁에 둔다면, 정말로 쓸모 있는 도구가 된 것입니다. 최근 시각 장애 사용자들이 쓰기 시작하며 거친 면을 만났고, 그래서 접근성 수정을 새 기능보다 앞당겼습니다. 그분들이 느끼는 앱의 감촉이 기대됩니다. 조용한 관리자는 모두를 위해 조용해야 합니다. ## AI 시대에도 제품을 사람으로 남기기 AI가 이 제품의 많은 부분을 가능하게 했습니다. 사용자를 대신 만나 주지는 않았고, 그래서도 안 된다고 생각합니다. 효율은 이제 사기 쉽습니다. 개발자와 사용자 사이의 감촉과 신뢰는 여전히 대화 한 통씩 쌓아야 합니다. 어쩌면 AI로 만든 제품이 사람 온기를 지키는 방식이 바로 이것일 수 있습니다. 코드는 생성할 수 있어도, 관계는 생성할 수 없습니다. 이것은 제 첫 유료 제품이고, 이 판단 중 일부는 틀릴 수도 있습니다. 저보다 오래 이 길을 걸어 보셨고 제가 어리석은 일을 하고 있다면, 듣고 싶습니다. Mole이 여기까지 온 과정은 더 긴 이야기로, [500줄 셸 스크립트에서 Mac 앱까지](https://mole.fit/ko/blog/the-story-of-mole)에 적어 두었습니다. --- Canonical HTML page: https://mole.fit/ko/blog/notes-on-building-a-quiet-product Blog index for agents: https://mole.fit/ko/blog/llms.txt Site index for agents: https://mole.fit/llms.txt