# 새 기술로 만든 제품을 다시 만들 때 필요한 판단

> 2023-06-26 · Garry Tan · 큐레이션 김태우
> https://challengekim.com/insights/새-기술로-만든-제품을-다시-만들-때-필요한-판단
> 원문: https://www.youtube.com/watch?v=z4xS27VyVMs

## 핵심 요약

- 게리 탄과 브렛 깁슨은 Posterous에서 이메일만 보내면 글을 올릴 수 있는 기능을 만들기 위해 이메일 경로를 분석하고 자체 코드를 작성했다.
- 몇 년 뒤 Posthaven을 만들 때는 같은 기능의 상당 부분을 Mailgun으로 구현할 수 있었다. 한때 필요했던 자체 개발이 계속 최선인 것은 아니었다.
- 두 사람은 AI 도구와 기반 모델이 빠르게 바뀌는 상황에서도 기술 선택의 기준은 사용자가 얻는 경험이라고 봤다.
- 새 문제를 풀 때는 폭넓은 역량을 갖춘 팀이 도움이 되지만, 핵심 기능의 테스트와 실패 가능성 점검도 필요하다고 강조했다.

## 이메일로 글을 올리기 위해 만든 기술

탄과 깁슨은 사친 아가르왈과 함께 만든 Posterous에서 이메일 발신 정보를 바탕으로 사용자를 식별하고, 이메일을 보내면 블로그에 글이 올라가도록 했다. 당시 이 기능을 구현하려면 기존 도구만으로는 부족했다. 팀은 이메일 전송에 쓰는 SMTP 클라이언트의 일부를 직접 작성하고, 이메일이 거친 경로를 분석해 실제 사용자가 보냈을 가능성을 판단했다. 깁슨은 이처럼 전에 없던 기능을 만들 때 공학적 판단이 늘 확정적인 답으로 떨어지지는 않는다고 설명했다.

## 다시 만들 때 달라진 도구

Posterous가 문을 닫은 뒤 두 사람은 Posthaven에서 서비스를 다시 만들었다. 그사이 이메일 처리 도구가 발전해 Mailgun이 필요한 기능의 약 90%를 제공했다는 것이 탄의 설명이다. 과거의 구현 방식을 그대로 반복했다면 불필요한 코드를 만들며 시간을 썼을 수 있었다.

탄은 이 경험을 2023년의 AI 개발과 연결했다. 오픈소스와 API가 발전하고 기반 모델의 성능도 달라지면서, 제품에 필요한 기술 구성은 몇 년은 물론 몇 달 사이에도 바뀔 수 있다는 관찰이다. 그는 기술을 바꾸더라도 사용자가 얻어야 할 경험을 기준으로 삼아야 한다고 말했다.

## AI에서는 결과의 불확실성도 다뤄야 한다

대담에서 깁슨은 대규모 언어 모델의 결과가 매번 같지 않다는 점을 짚었다. 따라서 AI를 제품에 적용하는 초기 개발은 단순히 새 도구를 연결하는 일로 끝나지 않는다. 사용자가 원하는 결과를 내도록 여러 방식을 시험해야 한다는 설명이다. 탄은 필요한 기능을 처음에는 직접 만들더라도, 이후에는 새 도구와 공개 기술을 살피며 구현을 고칠 수 있어야 한다고 봤다.

## 새 문제를 푸는 팀의 점검 방식

탄은 브렛 깁슨이 투자한 Bison Trails의 사례도 소개했다. 공동 창업자 에런 헨쇼에 따르면 초기에는 JavaScript로 화면과 API를 만들면서 Terraform도 다룰 수 있는 범용 개발자가 필요했다. 헨쇼는 시간이 지나 특정 문제를 깊이 해결할 인력을 채용할 수 있게 된다고 설명했다. 그는 초기부터 기본 사례를 다루는 핵심 테스트에 투자했더라면, 당장은 조금 느려져도 이후 개발에는 도움이 됐을 것이라고 돌아봤다.

소행성에서 가치가 높은 광물을 채굴하려는 Astroforge 사례에서는 기술적으로 가능한지, 가능하다면 회사가 사업을 지속할 수 있는 시기에 실현할 수 있는지가 검토 대상이었다. 공동 창업자는 한 어려운 문제에 집중하다 단순한 점검 항목을 지나칠 수 있다고 말했다. 그는 시간에 쫓기더라도 가능한 고장 원인을 하나씩 확인해야 한다고 강조했다.

두 사람이 제시한 기준은 일관된다. 새 기능을 위해 직접 기술을 만들 수 있어야 하고, 더 나은 도구가 생기면 다시 선택할 수 있어야 한다. 그 판단은 도구 자체보다 사용자가 얻는 경험에 맞춰야 한다.

---

원문을 바탕으로 AI 가 한국어로 요약·재구성한 글입니다. 인용·수치는 원문 링크에서 확인해 주세요. [원문 링크](https://www.youtube.com/watch?v=z4xS27VyVMs)