#Cargo Cult Programming
#Trunk Based Development
#Abort Controller
#Life Cycle
Written by Paul
개발, 직장인? or 개발자?나는 어떤 개발자인가?퀄리티란 무엇인가?Cargo Cult Programming이란?실제 예시 ① Trunk Based Development와 체리픽 배포실제 예시 ② AbortController vs Path Based Blocking맺음말
개발, 직장인? or 개발자?
왜 이런 서두로 시작할까 의문이 드실 수 있습니다. 하지만 이 글에서 다룰 **“카고 컬트 프로그래밍(Cargo Cult Programming)”**은 단순한 기술 이야기를 넘어, 개발자의 태도와 직결되는 주제라고 생각하기에 이렇게 시작해보려 합니다.
최근 다양한 개발자들과 협업하며 깨달은 점이 있습니다. 생각보다 많은 개발자들이 서로 다른 관점과 철학을 가지고 있더라는 사실입니다. 그러면서 제 머릿속에 한 가지 의문이 맴돌았습니다.
“과연 개발 철학을 이해하지 못한 채, 직장인으로서의 개발만 하게 된다면 그 생애와 시장가치는 어디까지 이어질까?”
이미 레드오션이 된 개발자 시장에서, 이 질문은 결코 가볍지 않다고 생각합니다.
나는 어떤 개발자인가?
- 단순히 구현을 위해 카고 컬트프로그래밍을 반복하는 **“모방형 직장인 개발자”**인가?
- 아니면 철학과 본질을 이해하며 가치를 추구하는 **“시장가치 있는 개발자”**인가?
이 질문이야말로, 앞으로 개발자로서 어떤 생애를 살 수 있을지를 가르는 기준이 된다고 생각합니다.
퀄리티란 무엇인가?
개발에서 말하는 퀄리티는 사람마다 다르게 해석됩니다.
- 일정보다 개인 욕심을 우선시하며, 내가 원하는 수준까지 구현해야 만족하는 경우
- 일정 내에 코드 품질과 프로덕트 가치를 동시에 챙기며, 영속적 구조를 만들어내는 경우
제가 생각하는 퀄리티의 정의는 이렇습니다.
“눈앞의 문제 해결에만 급급하지 않고, 미래까지 고려하며 지속가능한 방식을 선택하는 것”
반대로, 카고 컬트프로그래밍에 익숙해진 개발자는 도메인 구현에만 멘탈모델이 갇히고, 프레임워크의 철학을 이해하지 못한 채 겉모습만 모방합니다. 그 결과는 필연적으로 레거시 코드입니다.
Cargo Cult Programming이란?
“카고 컬트 프로그래밍”은 맥락과 철학을 이해하지 못한 채 무작정 따라 하는 행위를 의미합니다.
- 유래: 2차 세계대전 후 남태평양 부족이 군용 활주로를 본떠 지었지만, 실제 보급은 오지 않았던 사례
- 특징:
- 이유 없이 프레임워크·패턴을 차용
- 불필요한 복잡성 증가와 유지보수 어려움
- 학습 기회 상실
- 결론:
“본질을 이해하지 않고 겉모습만 흉내 내면, 목적지에는 결코 도달할 수 없다.”
실제 예시 ① Trunk Based Development와 체리픽 배포
Trunk Based Development(TBD)의 원칙은 간단합니다.
- main 브랜치에 머지되는 순간, 즉시 배포 가능한 상태여야 한다.
- main은 언제든 신뢰 가능한 브랜치여야 한다.
하지만 실제 협업에서는 이런 일이 벌어집니다.
A: “내 작업은 이미 main에 들어갔으니까, 체리픽해서 배포할게.”
겉보기에 틀린 말은 아닙니다. 하지만 이는 TBD를 표면만 흉내낸 전형적인 카고 컬트적 행태입니다.
- main은 배포 불가능한 브랜치가 되고
- 체리픽 배포가 일상화되며
- release와 main 간 형상 차이가 벌어지고
- 결국 TBD는 의미를 잃게 됩니다.
즉, 맥락 없는 리뷰와 공유 부재 속에서 도입한 TBD는 단순 유행 따라하기일 뿐이며, 생산성 향상은커녕 혼란만 낳습니다.
실제 예시 ② AbortController vs Path Based Blocking
JavaScript는 네트워크 요청을 취소할 수 있도록 AbortController라는 표준 API를 제공합니다.
이 방식을 사용하면 요청 제어는 명확히 언어가 제공하는 책임에 위임되고, 코드의 응집도와 재사용성이 유지됩니다.
하지만 이를 이해하지 못하면, 종종 다음과 같은 억지 구현이 나옵니다.
언뜻 보면 동작은 합니다. 하지만 이 방식은
- SOLID 원칙 위배 (요청 제어 책임이 fetch 함수에 과도하게 붙음)
- 확장성·재사용성 저하 (path 외 조건에 대응 어려움)
- JS 철학과 괴리 (언어가 제공하는 표준적 해법을 무시)
라는 문제를 낳습니다.
즉, 이는 TBD의 체리픽 배포처럼, “동작만 하면 된다”는 직장인 개발자적 사고가 낳은 카고 컬트 사례입니다.
맺음말
두 사례(TBD, AbortController)가 말해주는 교훈은 단순합니다.
“본질을 이해하지 않고, 겉만 흉내 낸 프로세스와 구현은 결국 레거시만 남긴다.”
개발자는 단순히 직장인으로서 주어진 구현만 하는 존재가 아닙니다.
철학을 이해하고 가치를 추구하는 멘탈모델을 갖출 때, 비로소 시장에서 오래 즐겁게 일할 수 있습니다.
그렇지 않다면 개발자는 직장인으로서의 생애는 이어갈 수 있을지 몰라도, 결국 시장가치는 줄어들고, 남는 것은 레거시뿐일 것입니다.