Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
이 글은 완벽한 데모나 과장된 마케팅 문구 대신, 제품의 솔직한 한계와 실제 작동 과정을 공개하는 개발 철학을 제시합니다. 오픈 소스 iPhone 자동화 도구 PhoneHands를 예로 들어, CI 실패 기록이나 403 에러 같은 '수습되지 않은 문제'까지도 투명하게 공유하며 신뢰도를 높이는 방법을 설명합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기이번 주 제가 출시한 가장 좋은 것은 기능이 아니었습니다. README에 적힌 문장이었습니다. 'True wireless는 불가능하며, 이 도구는 그렇지 않은 척하지 않는다.'
빌드의 나머지 모든 것—여덟 개의 패키지, 통과하는 테스트 190개, 제대로 찍는 데 두 번이나 걸린 데모 비디오—은 그 문장 옆에서는 아무 가치가 없었을 것입니다. 왜냐하면 현재 업계 표준은 정반대이기 때문입니다. 제품이 할 수 없는 모든 것을 조용히 잘라내고(crop out) 광고처럼 작성된 README 파일을 만드는 것이죠. 저는 이 실험을 반대로 진행하기로 결정했습니다. 한계를 먼저 공개하고, 기능을 나중에 공개하는 것입니다. 무엇이 살아남는지 지켜보겠습니다.
이 프로젝트는 PhoneHands라는 오픈 소스 iPhone 자동화 도구입니다. 하나의 API 엔진과 하나의 디바이스 엔진으로 구성되어 있으며, 이들 사이에서 자동으로 폴백(fallback)합니다. 자르지 않은 상태의 실제 빌드는 다음과 같았습니다:
그리고 README에는 정직함의 코너가 담겨 있습니다: 진정한 무선 연결(true wireless) — 휴대폰을 주머니에 넣고 컴퓨터 근처에 없을 때 — 은 Apple이 iOS에 구축한 벽입니다. 이 저장소의 어떤 소프트웨어도 그 벽을 통과할 수 없으며, 여기의 마케팅 문구 역시 그렇게 주장하지 않습니다. 도구가 무엇을 약속하는지, 그것은 운영상의 극한에서만 약속합니다.
원칙에 메커니즘이 없으면 슬로건일 뿐이기 때문에, 여기 그 작동 방식이 있습니다. MVP가 '완료'로 간주되기 전에, 해당 카테고리의 모든 미해결 문제는 명명되고 닫히거나 명시적으로 인정되어야 했습니다:
여섯 가지 문제, 여섯 가지 답변 또는 정직한 인정입니다. 그 목록이 진정한 결과물입니다. 코드는 단지 이 목록을 심각하게 다루었다는 증거일 뿐입니다.
반대하는 종교는 이렇게 말합니다. '행복한 경로(happy path)'를 배포하고, 별점을 모으고, 누군가 불평할 때 엣지 케이스(edge cases)를 수정하라.' 이것은 빠르게 느껴집니다. 빠르죠. 개발자의 신뢰를 먼저, 그리고 사용자의 신뢰를 나중에 침식시키는 특정한 종류의 기술 부채(technical debt)를 생성하는 것이 바로 그것입니다. 잘라낸 모든 한계는 아직 접수되지 않은 지원 티켓(support ticket)입니다. 영원히 오지 않을 '곧 출시 예정(coming soon)'은 자신의 README 파일에 대한 신뢰를 잃어버린 유지 관리자(maintainer)와 같습니다.
솔직한 버전은 출시 당일에는 느리지만, 그 이후 매일매일 더 빠릅니다. 절대로 무언가를 주장할 필요가 없습니다. 이슈 트래커(issue tracker)는 배신 보고서 대신 버그 보고서로 채워지는데, 이것이 훨씬 더 좋은 종류의 문제입니다. 그리고 아무도 말하지 않는 복리 효과(compounding effect)가 있습니다. 여섯 가지 문제에 대해 솔직하게 이야기하면, 일곱 번째 문제는 다른 누군가가 발견합니다. 왜냐하면 당신은 사용자들에게 그 목록을 찾아보도록 훈련시켰기 때문입니다. 참고로 이름을 확인했는데, 처음 두 후보는 기존 프로젝트와 충돌하여 결국 공개되기 전에 PhoneHands라는 이름으로 변경되었습니다. 정직한 명명(Naming honesty)은 다른 사람의 이름을 가져가지 않는 것에서 시작됩니다.
저는 모두를 위해 구축하기 전에 한 사용자, 즉 저 자신을 위해 구축하고 있습니다. PhoneHands는 제가 이 휴대폰이 무엇을 허용하는지에 대해 스스로에게 거짓말하지 않고 자동화할 필요가 생겼기 때문에 존재합니다. 그 'N-of-one' 규율(discipline)이 이 전체 시리즈를 조직했습니다. 권리를 거부하는 것, 화요일 감사(Tuesday audit), 삭제 규율(deletion discipline), 재무 담당자(treasurer) 등이 그것이며, 여기서 새로운 경계에 도달합니다. 바로 첫 번째 사용자를 QA 부서로 취급하는 빌더 도구입니다. 만약 제가 README를 보고 저 자신의 제약 사항들을 솔직하게 명시된 것을 볼 수 없다면, 그것은 배포되지 않습니다.
저장소는 아직 비공개 상태이며, 마지막 관문인 실제 장치 검증이 남아있습니다. 이 검증에는 제가 아직 해결 중인 하드웨어 예산이 필요합니다. 테스트는 성공적이고(green), 데모는 솔직하며, 한계점은 공개되었습니다. 하지만 모의 통과만으로는 충분하지 않습니다. 실제로 작동하는 휴대폰만이 유일한 승인 기준입니다. 190개의 테스트가 성공했다고 하면서도 '완료되지 않았다'고 말하는 것은, 엔진이 작동하는데도 '무선 기능을 할 수 없다'고 말하는 것과 같은 맥락입니다. 사실상 제품 전체에 관한 이야기입니다. 이 목록 자체가 제품입니다.
따라서 이번 주 프로덕션 환경에서 제가 지키는 규칙은 이렇습니다. 한계점을 명시하지 않고 기능이 출시되는 일은 없습니다. 그 한계점은 해당 기능과 함께, 같은 호흡으로, 동일한 README에 적혀야 합니다. 완벽한 데모는 만들기 쉽지만 믿기에는 비쌉니다. 해결되지 않은 문제 목록은 작성하기 어렵지만 신뢰하기는 저렴합니다.
완벽한 데모 배포를 멈추세요. 솔직한 한계점 배포를 시작하세요. 데모는 덜 흥미로울 것입니다. 하지만 신뢰도는 복리처럼 쌓일 것입니다.