“뛰어난 개발자의 머릿속 구석에는 항상 어리석음이 숨어 있다.”
— 아리스토텔레스

풋건(foot-gun)이란, 자신이 스스로 발등을 쏘는 것처럼 좋아 보이지만 장기적으로는 해로운 습관/패턴을 말합니다.
Ken(전 FiscalNote VP of Engineering, 현 Truss CTO)이 5년간 경험하며 뼈저리게 느낀 5가지 대표 풋건을 소개합니다.

---

1. 🤯 똑똑한 코드 vs. 명확한 코드

• “원라이너로 줄여볼까?”
• “여기서 재귀 쓰면 우아하지 않을까?”
• “포인터 연산으로 최적화해보자!”

이런 ‘똑똑해 보이는 코드’는 가독성을 해치고 유지보수 지옥을 만듭니다.
게다가 성능 향상도 대부분 체감 불가. 최적화는 컴파일러가 잘 해주고, API 콜 한 번에 붙는 몇 나노초 절약은 사용자에게 의미 없습니다.

👉 원칙: 읽는 사람이 한 번이라도 멈칫한다면, 차라리 풀어서 쓰는 게 낫다.

---

2. 🗑️ “코드를 버리기”를 두려워함

• 많은 개발자가 기존 코드를 붙잡고 끝없이 핫픽스와 해킹을 덧대며 “프랑켄슈타인 코드”를 만들어냅니다.
• 그러나 코드 초기화 → 재작성은 생각보다 즐겁고 효율적일 때가 많습니다.

👉 원칙: 침몰비용(sunk cost) 에 매몰되지 말 것. “과감히 지우고 다시 시작”할 수 있는 용기 필요.

---

3. 🏗️ 조기 추상화 (Premature Abstraction)

• “앞으로 필요할지도 몰라” 하며 조기에 추상화/공통화를 도입하는 경우.
• 결과적으로 쓸데없이 복잡한 계층만 남습니다.

소프트웨어는 리팩터링 비용이 매우 저렴합니다. 피사의 사탑이나 허블 우주망원경처럼 고치기 힘든 구조물이 아닙니다.

👉 원칙: 지금 당장 필요한 코드만 작성. DRY(Don’t Repeat Yourself) 보다 WET(Write Everything Twice) 가 더 나을 때도 많다.

---

4. 🌐 분산 시스템의 복잡성을 얕잡아봄

• 많은 팀이 조기에 메시지 큐·마이크로서비스를 도입합니다.
• 그런데 정작 겪는 장애들은 대부분 큐 자체 문제:
  • 메시지 중복/재시도 폭주
  • 큐 용량 초과
  • DLQ(dead letter queue) 처리 누락

즉, 새로운 문제를 해결하기보다 문제 영역만 확장한 셈입니다.

👉 원칙: 진짜 필요할 때만 분산 아키텍처 도입. 그 전에는 스레딩·인메모리 큐·병렬화 같은 간단한 해법을 먼저 고려.

---

5. 🙋 도움 요청을 미루는 습관

• 많은 개발자가 끝까지 혼자 해결하려고 함.
• 하지만 가장 큰 학습은 ‘질문 후 대화’ 과정에서 발생합니다.
  • “그거 이미 표준 라이브러리에 있어요.”
  • “이건 더 일반화된 문제의 특수 케이스예요.”
  • “해결책은 이렇고, 관련 개념도 같이 알려줄게요.”

👉 원칙: “스스로 해결 → 공유/토론 → 예상 못한 인사이트 획득”의 루프를 의식적으로 만들 것.

---

✅ 정리

Ken이 꼽은 5대 풋건은 다음과 같습니다:

1. 똑똑한 코드 쓰기 → 명확한 코드로 대체하자.
2. 코드를 버리지 못함 → 과감히 새로 시작하자.
3. 조기 추상화 → 리팩터링이 훨씬 싸다.
4. 분산 시스템을 가볍게 생각함 → 필요할 때만 도입.
5. 질문을 미루기 → 배움의 기회를 놓친다.

---

💡 마무리

이 풋건들은 대부분 “개발자의 자존심”과 연결된 함정입니다.

• 똑똑해 보이고 싶은 마음,
• 쓴 코드에 대한 애착,
• 미리 대비하려는 본능,
• 멋져 보이는 아키텍처의 유혹,
• 혼자서 해결하고 싶은 자존심.

그러나 장기적으로는 단순함·유연함·협업이 더 큰 힘을 발휘합니다.

---

원문 - https://kenkantzer.com/5-software-engineering-foot-guns/