시니어 개발자가 전하는 소프트웨어 개발 철학

소프트웨어 개발은 단순히 코드를 작성하는 것이 아니라, 오랜 경험을 통해 다듬어진 철학과 원칙이 필요합니다. 최근 한 회사에서 시니어 개발자들이 자신만의 개발 철학을 공유하는 시간을 가졌고, 이에 대한 생각을 정리해 보고자 합니다.

---

🚨 무분별한 전면 재개발(ground-up rewrite)을 피하라

코드를 처음부터 다시 작성하는 전면 재개발은 매력적이지만, 대개 위험합니다.

이런 상황이 오기 전에 미리 신호를 감지하고 대응해야 합니다.
⚠️ 위험 신호:
✅ 누적되는 기술 부채
✅ 작은 변경도 어려운 코드 구조
✅ 문서화 및 주석 작성의 어려움
✅ 신규 개발자의 온보딩 문제
✅ 코드베이스를 완전히 이해하는 사람의 감소
✅ 원인을 알 수 없는 버그

💡 해결책:

• 새로운 기능 개발(확장)과 코드 정리(통합)를 번갈아가며 진행
• 코드의 복잡성을 지속적으로 줄이는 노력

물론 전면 재개발이 유일한 해결책일 수도 있지만, 이러한 상황 자체를 만들지 않는 것이 가장 중요합니다.

---

⏳ 50%의 시간 내에 90% 완성하라

"개발의 첫 90%가 전체 시간의 90%를 차지하고, 나머지 10%가 또 다른 90%를 차지한다."

✅ 코드 작성 후 동작하는 상태가 되었다면 절반만 끝난 것이다.
✅ 유지보수성, 예외 처리, 테스트, 문서화 등이 추가로 필요하다.
✅ 이를 고려하지 않으면 조잡한 코드가 남고, 결국 제품의 품질이 떨어진다.

🚀 계획적인 시간 관리를 통해 이러한 문제를 대비하고, 예상보다 여유가 생긴다면 기술 부채를 줄이는 데 활용하라.

---

🤖 좋은 개발 습관을 자동화하라

새로운 개발 규칙을 사람의 기억력에 의존해서 적용하려 하면 실패할 가능성이 높다.

✅ 비효율적인 방법

• 매번 회의에서 공지
• 이메일, 문서, README 업데이트
• 지속적인 피드백과 코드 리뷰

✅ 효율적인 방법 (자동화)

• 코드 내 자동 검사 도입 (예: 린트, 스타일 가이드, CI/CD)
• 필수 규칙을 자동으로 체크하는 테스트 추가
• 위반 시 코드 실행이 중단되도록 설정

🚀 반복적인 수작업 대신 자동화된 프로세스를 도입하여 코드 품질을 유지하라.

---

⚠️ 예외적인 상황을 고려하라 (Pathological Data)

"잘 작동하는 일반적인 경우(Golden Path)는 중요하지 않다. 개발자의 진짜 일은 예외 처리를 고민하는 것이다."

✅ API 요청이 실패하거나 응답 속도가 극도로 느린 경우?
✅ 데이터가 예상보다 지나치게 많거나 부족한 경우?
✅ 입력값이 비정상적으로 길거나 특수 문자를 포함한 경우?

💡 예외 처리를 철저히 설계하면 시스템의 안정성이 올라간다.

---

🎯 더 단순한 해결책을 찾아라

"체스에서 좋은 수가 보이면, 더 좋은 수가 있는지 한 번 더 찾아라."

✅ 첫 번째로 떠오른 코드가 최선이 아닐 수 있다.
✅ 시간이 허락된다면 한 번 더 개선해보라.
✅ 코드가 짧고 간결할수록 유지보수가 쉬워진다.

---

🧪 테스트하기 쉬운 코드를 작성하라

테스트하기 어려운 코드 = 구조적으로 문제가 있는 코드

✅ 명확한 인터페이스 정의
✅ 최소한의 부작용(Side Effect) 유지
✅ 작은 단위로 코드 분리

💡 코드가 단순할수록 테스트가 쉬워지고, 버그 발생 가능성이 줄어든다.

---

🔍 코드가 명확하게 이해될 수 있도록 작성하라

"코드가 '우연히' 올바르게 동작하는 것처럼 보이면 위험하다."

✅ 코드가 올바르게 동작하는 것만으로는 충분하지 않다.
✅ 코드가 누가 봐도 직관적으로 이해될 수 있어야 한다.
✅ 보안 문제도 마찬가지로, 지금은 안전해 보여도 환경이 바뀌면 취약점이 될 수 있다.

💡 명확한 코드 구조를 유지하여 유지보수성을 극대화하라.

---

🔥 마무리

소프트웨어 개발은 단순한 코드 작성이 아니라, 지속 가능한 코드와 시스템을 만드는 과정입니다.

💡 핵심 요약:

• 전면 재개발을 피하고 기술 부채를 관리하라.
• 50%의 시간 내에 90%를 완성하고, 마무리를 철저히 하라.
• 개발 습관과 코드 품질을 자동화하라.
• 예외 처리를 철저히 고려하라.
• 더 단순한 해결책을 고민하라.
• 테스트 가능한 구조를 유지하라.
• 명확하고 직관적인 코드를 작성하라.

 

원본

 

Developer philosophy @ Things Of Interest