Pfizer가 30년 전 놓친 '대박' 아이템, 그리고 우리의 의사결정 로그

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

최근 흥미롭지만, 한편으로는 등골이 서늘해지는 기사를 하나 읽었습니다. 하버드 의대 전 학장인 제프리 플라이어(Jeffrey Flier)가 쓴 회고록이었는데요. 내용은 충격적입니다. 요새 전 세계를 강타하고 있는 비만 치료제 'GLP-1(위고비, 젭바운드 등)'의 초기 연구가 이미 1990년대 초반에 진행되었고, 당시 자금줄을 쥐고 있던 제약 공룡 Pfizer(화이자)가 이를 "가치 없다"고 판단해 프로젝트를 드랍(Drop)했다는 것입니다.

개발자로 치면, 미래의 유니콘이 될 핵심 코어가 담긴 레포지토리(Repository)를 "더 이상 유지보수할 가치가 없다"며 아카이브(Archive) 처리해 버린 셈이죠.

오늘은 이 거대한 '실수'의 이야기를 통해, 우리 기술 조직이 매일 마주하는 '선택과 포기'에 대해 이야기해 보려 합니다.

"그때는 맞고 지금은 틀리다?" 아니, 그 반대일지도

솔직히 말해, 1991년 당시 화이자의 결정권자들을 비난하기는 어렵습니다. 당시 기술 수준이나 시장 상황에서 GLP-1은 주사제라는 한계, 불확실한 부작용, 그리고 당시의 비즈니스 우선순위 등 수많은 '안 되는 이유'가 있었을 겁니다.

우리 개발 현장도 마찬가지입니다.

풀링포레스트 팀에서도 종종 야심 차게 시작했던 POC(Proof of Concept) 프로젝트를 중단하곤 합니다. "서버 비용 대비 효용이 낮다", "지금 우리 인프라로는 감당이 안 된다", "사용자 반응이 미지근하다" 같은 합리적인 이유들 때문이죠.

하지만 화이자의 사례는 우리에게 뼈아픈 질문을 던집니다. "우리가 지금 '레거시' 혹은 '실패작'이라 부르며 폐기하려는 코드가, 사실은 시대를 너무 앞서간 '오버 엔지니어링'이었을 뿐이라면?"

기술적 의사결정의 유통기한

CTO로서 가장 두려운 순간은 기술 스택을 선정하거나 아키텍처를 결정하는 순간이 아닙니다. 오히려 "이 기능은 안 될 것 같으니 뺍시다"라고 결정하는 순간입니다.

화이자는 GLP-1 연구를 포기함으로써 수백조 원의 시장 기회를 날렸습니다. 하지만 그 결정 당시에는 그게 '최적의 리소스 배분'이었을 겁니다. 여기서 우리가 배워야 할 점은, 기술적 의사결정에는 '맥락(Context)'이 가장 중요하다는 것입니다.

코드 한 줄, 커밋 하나에도 그 코드를 작성한 당시의 맥락이 있습니다. 우리가 흔히 '레거시'라고 부르며 뜯어고치고 싶어 하는 코드들도, 사실 3년 전에는 트래픽을 버텨내기 위한 최선의 타협이었을 수 있습니다.

문제는 그 맥락을 기록하지 않고 결과만 남겼을 때 발생합니다.

화이자가 단순히 "이 프로젝트는 실패"라고 결론짓지 않고, "현재 기술로는 상용화가 어렵지만, A와 B 조건이 해결되면 다시 검토해야 함"이라는 로그를 명확히 남겨두었다면 어땠을까요? 아마 30년이 아니라, 10년 뒤에라도 다시 꺼내볼 수 있었을 겁니다.

실패한 브랜치(Branch)도 자산이다

주니어 개발자분들이 자주 하는 실수가 있습니다. 기능 구현에 실패하거나 방향이 바뀌면, 작업하던 브랜치를 그냥 삭제해 버리는 것입니다.

하지만 저는 팀원들에게 항상 강조합니다. "실패한 시도도 기록으로 남겨라. 그게 우리의 기술 부채를 자산으로 바꾸는 유일한 길이다."

풀링포레스트에서는 중요한 기술적 의사결정을 할 때 ADR(Architecture Decision Records)을 작성하려 노력합니다. 왜 이 기술을 선택했는지 뿐만 아니라, 왜 저 기술을 '버렸는지'를 기록하는 것이 핵심입니다.

• Redis를 쓰려다가 왜 Memcached로 선회했는가?

• MSA 전환을 고려하다가 왜 모놀리식 구조를 유지하기로 했는가?

이 '버림의 기록'들이 쌓여야, 훗날 기술적 특이점이 왔을 때 "아, 그때 우리가 비용 문제로 포기했던 그 아키텍처, 지금 클라우드 비용이 내려갔으니 다시 시도해 볼까?"라는 발상으로 이어질 수 있습니다.

마치며: 미래를 위한 인내심

화이자의 사례를 보며 "바보 같다"고 웃어넘길 일이 아닙니다. 우리도 매일 무언가를 선택하고, 무언가를 포기하고 있으니까요. 어쩌면 오늘 여러분이 으로 날려버린 그 코드가 10년 뒤 세상을 바꿀 아이디어였을지도 모릅니다.

물론 모든 아이디어를 끝까지 붙들고 있을 순 없습니다. 리소스는 한정되어 있고, 우리는 생존해야 하니까요. 하지만 적어도 "우리가 무엇을, 왜 포기했는지"에 대한 회고와 기록만큼은 꼼꼼히 챙겼으면 합니다.

기술은 돌고 돕니다. 지금은 폐기된 아이디어가 언젠가 다시 화려하게 부활할 때, 그 기회를 잡는 건 '기억하고 있는 자'의 몫일 테니까요.

오늘도 수많은 선택의 기로에 서 있는 동료 개발자 여러분, 비록 지금 당장 빛을 보지 못하더라도, 여러분의 고민과 시도는 결코 헛되지 않습니다. 그 치열한 고민의 흔적을 잘 남겨두시길 바랍니다.

감사합니다.