일요일 아침. 커피가 식어가고 있다.

모든 것이 이미 내 머릿속에 그려져 있었다.

한 번 업로드하면 모든 곳으로 전송되는 플랫폼. 버튼 하나. 마찰 없는 과정. 업로드 파이프라인 (upload pipeline), 큐 (queue), 재시도 로직 (retry logic), 그리고 각 목적지가 확인될 때마다 하나씩 켜지는 작은 초록색 체크 표시들.

단 한 줄의 코드도 작성되지 않았다.

그 문제가 실제로 존재하는지 확인한 사람도 없었다.

당신도 이런 적이 있을 것이다

솔직해지자.

당신은 그것이 정말 만들어질 필요가 있는지 묻기도 전에, 에디터를 열고 빌드를 시작한 적이 있다.

흥분할 때 그런 일이 가장 많이 일어난다. 흥분은 명확함처럼 느껴진다. 틀렸다. 그것은 방향 확인 없는 추진력일 뿐이며, 이 직업에서 가장 비용이 많이 드는 감정이다.

그래서 무언가를 만들기 전에, 일요일 하루를 지루한 버전에 쏟아부었다. 실제 사양 (specifications)을 읽고, 실제 문서 (documentation)를 찾아보고, 내가 가정했던 방식이 아니라 각 플랫폼이 실제로 어떻게 작동하는지 확인했다.

그날은 나의 일요일을 앗아갔다.

하지만 그 덕분에 1년에 가까운 시간을 아꼈다.

조사가 처음으로 말해준 것

안 된다.

당신이 묘사한 것은 구현할 수 없다. 두 곳의 목적지는 최종 사용자의 계정 자격 증명 (account credentials)을 요구한다. 어떤 엔지니어링 (engineering)으로도 그것을 제거할 수 없다. 그것은 기술적인 경계가 아니라 법적인 경계다.

그 사실이 약 10분 동안은 쓰라렸다.

그러고 나서 조사는 훨씬 더 유용한 것을 말해주었고, 이 부분이 바로 취해야 할 대목이다.

이미 무료였던 단계를 최적화하기

해당 카테고리 전체가 내가 가정했던 방식대로 작동하지 않는다.

내 멘탈 모델 (mental model)은 푸시 (Push)였다. 내 시스템이 매번, 영원히 모든 목적지로 파일을 내보내는 방식이다. 그 모델은 큐 (queue), 재시도 시스템 (retry system), 상태 대시보드 (status dashboard), 그리고 약 3개월 분량의 작업량을 만들어낸다.

그것은 풀 (Pull) 방식이다.

모든 목적지는 각자의 일정에 따라 폴링 (polls)을 수행한다. 단 한 번의 연결 이후, 모든 향후 업로드는 나로부터의 호출도, 사용자로부터의 동작도 없이 전파된다. 영원히.

결국 내가 자동화하기 위해 3개월을 쓰려 했던 것은 이미 자동이었다. 그것은 이미 25년 동안 자동이었다.

어렵고, 구축할 가치가 있는 유일한 부분은 일회성 설정(one-time setup)이었다. 정신적으로는 사소한 온보딩 (onboarding)으로 분류해 두었던 부분 말이다.

내 아이디어의 난이도 구배 (difficulty gradient) 전체가 거꾸로 되어 있었다.

한 오후에 두 번 틀리다

완전한 확신을 가지고 말했던 두 가지가 거짓으로 판명되었다. 흥미로운 지점은 오류가 아니라 그 확신이다.

첫째. 한 주요 플랫폼이 전체 인제스션 경로 (ingestion route)를 제거했다고 알려져 있었다. 해당 플랫폼의 자체 문서에는 그것이 작동하며, 작동을 멈춘 적이 없다고 명시되어 있다. 그 믿음은 어디선가 유입되었고, 검증되지 않았으며, 사실로서 반복되었다.

둘째. 또 다른 플랫폼이 주요 콘텐츠 유형에 대한 파트너 인터페이스 (partner interface)를 가지고 있다고 알려져 있었다. 하지만 그것은 완전히 다른 콘텐츠 유형을 위한 것이었다. 그 차이가 통합 계획 (integration plan) 전체를 바꿔 놓는다.

어느 것도 추측이라고 표시되지 않았다. 둘 다 그 추측을 바탕으로 아키텍처 (architected)가 설계되었을 것이다.

오류 자체는 극복 가능하다. 확인 과정을 건너뛴 확신이 당신에게 비용을 치르게 한다.

관점을 재정립한 세 가지 숫자

세 가지 수치가 지난 한 주간의 공상보다 내 사고에 더 큰 도움을 주었다.

이 카테고리 전체의 밑바탕에 깔린 개방형 프로토콜 (open protocol)은 1999년부터 존재해 왔으며, 2001년부터 이 콘텐츠 유형을 운반해 왔다. 아무도 이를 소유하지 않는다. 세 개의 별개 플랫폼 거물들이 이를 소유하려 시도했으나 실패했다. 내가 경쟁할까 봐 걱정했던 바로 그 기업들 사이에서 정확히 25년 동안 살아남았다.

이 분야에서는 현재 매일 약 485개의 기계 생성 피드 (machine-generated feeds)가 나타난다. 인간이 만든 것보다 새로운 기계 제작 쇼가 더 많다. 이는 호스팅하는 누구에게나 비용 문제이며, 다른 모든 이들에게는 발견 (discovery) 문제이다.

비싼 라이선스 협상이 필요할 것이라고 가정했던 구성 요소는 이중 라이선스 (dual-licensed) 오픈 소스임이 밝혀졌다. 구축 비용은 제로다. 비용은 완전히 다른 곳, 내가 찾아볼 생각을 하지 못했던 곳에 위치한다.

이 중 어느 것도 더 열심히 생각해서 얻은 결과가 아니다. 이 모든 것은 단 하루 동안 1차 자료 (primary sources)를 읽음으로써 얻은 것이다.

나의 실제 의견

리서치 (Research)는 곧 구축 (building)이다. 같은 범주에 속하며, 출력물은 다르고, 새로운 아이디어에 대해 당신이 할 수 있는 그 어떤 것보다 시간당 수익률이 높다.

우리 대부분은 이것이 미루기(procrastination)처럼 느껴지고, 실제적인 위험이 따르기 때문에 이를 건너뛴다.

그 위험이란 바로 당신의 아이디어를 죽이는 것이다.

내 아이디어는 살아남았다. 하지만 내 논리는 살아남지 못했다. 3개월 안에 출시되었을 버전은 기술적으로는 유능했고, 2001년에 이미 스스로 해결되었을 문제를 겨냥하고 있었다.

그것은 사용자들로부터 얻어냈을 것이다. 천천히. 그리고 비싼 대가를 치르며. 출시 후에 말이다.

최근 무엇이 변했는가

10년 전, 이것을 제대로 수행하는 하루란 사양서(specifications) 뭉치를 앞에 두고 앉아, 당신이 최신 버전을 읽고 있기를 바라는 것을 의미했다.

이제는 오후 한때에 12개의 주요 소스(primary sources)가 들어오고, 내 자신의 노트가 나 자신과 두 번 모순되며, 무언가가 커밋(commit)되기 전에 수정 사항이 도착한다.

이 시대가 나를 개인 프로젝트로 더 깊이 밀어 넣었는지에 대한 정직한 답변이 바로 이것이다.

그렇다. 빌딩(building)이 빨라졌기 때문이 아니다.

틀리는 비용이 저렴해졌기 때문이다.

나쁜 아이디어를 테스트하는 데는 예전에 몇 달이 걸렸다. 이제는 대략 일요일 하루 정도면 충분하다.

당신의 차례

틀리는 데 단 하루만 비용이 든다면, 당신이 테스트해보고 싶은 아이디어 하나는 무엇인가?

이것이 유용했다면

나는 성공과 정체(freezes)를 모두 포함하여 이 과정을 공개적으로 진행하며, 주로 LinkedIn과 YouTube에서 활동한다. 공개적으로 빌딩(building in the open)하는 진짜 모습이 당신에게 유용하다면, 그곳에 나의 작업이 있다. X, GitHub에서 나를 찾을 수 있으며, next8n.com에서 작업물을 확인할 수 있다.