그냥 읽고 지나가려다가, 너무 마음에 들어서 번역해서 블로그에 남겨둡니다.
개발자의 철학
2025-02-03 | qntm
놀랍게도, 지금도 여전히 주니어 개발자들이 존재합니다.
몇 주 전에 회사에서 시니어 개발자들(저 포함)이 각자 약 5분씩 자신의 소프트웨어 개발 철학에 대해 이야기하는 자리가 있었습니다. 우리의 경험을 주니어 개발자들과 공유하자는 취지였습니다.
그 세션 이후, 제 생각을 글로 정리하고 좀 더 자세히 다뤄보는 것이 가치 있을 것 같다고 느꼈습니다. 그래서 이렇게 글을 씁니다.
이 글은 조금 잡다한 내용을 포함하고 있으며, 제가 소프트웨어를 개발하는 방식을 포괄적으로 탐구하는 것은 아닙니다. 또한, 이미 시니어 개발자라면 여기 있는 내용을 익히 알고 있을 수도 있고, 동의하지 않을 수도 있습니다. 소프트웨어 개발은 유명하게도 주관적인 분야이니까요. 댓글에서 뵙겠습니다.
전면적인 코드 리팩토링이 매력적으로 보이는 상황을 절대 만들지 마라
완전히 새롭게 코드를 다시 짜는 전면적인 리팩토링(ground-up rewrite)은 매력적으로 보이지만, 매우 위험한 선택이라는 점이 일반적으로 잘 알려져 있습니다. 이에 대한 표준적인 조언은 "절대 하지 마라" 입니다. 하지만 저는 한 걸음 물러서서 이 문제를 더 깊이 들여다보고 싶습니다.
전면적인 리팩토링이 필요해 보이는 시점에 도달했다면, 이미 피할 수 있었던 실수들이 쌓였다는 뜻입니다. 이런 상황은 멀리서도 감지할 수 있으며, 적극적으로 피해야 합니다.
경고 신호:
- 기술 부채가 점점 쌓이고 있다.
- 단순한 코드 변경조차 점점 더 어려워지고 있다.
- 코드 문서화(주석 포함)가 어려워지고 있다.
- 새로운 개발자를 온보딩하기 힘들어지고 있다.
- 특정 코드 영역을 이해하는 사람이 점점 줄어들고 있다.
- 아무도 이해하지 못하는 버그가 생긴다.
이러한 복잡성의 증가는 반드시 저지해야 합니다. 새로운 기능을 추가하는 확장 단계와 기존 코드를 정리하는 정리 단계를 번갈아가며 진행하세요.
물론, 전면적인 리팩토링이 성공할 수도 있습니다. 기존 코드의 기술 부채가 너무 커서 유지하는 것이 더 나쁜 선택일 수도 있습니다. 혹은, 둘 다 답이 아닌 경우도 있습니다. 프로젝트 자체가 실패할 운명일 수도 있고, 결국 어떤 방식으로 죽을 것인지를 선택하는 문제일 수도 있습니다.
중요한 점은, 이런 위험이 애초에 피할 수 있는 상황이라는 것입니다.
주어진 시간의 50% 안에 90%를 완성하라
소프트웨어 개발에서 자주 인용되는 유명한 격언이 있습니다. 사실 이 말이 개발 외의 다른 분야에서 유래했을 수도 있겠네요:
"작업의 첫 90%는 전체 시간의 90%를 차지한다. 마지막 10%는 나머지 90%의 시간을 차지한다."
이 말은 농담 같지만, 엄청나게 정확한 사실입니다. 그리고 이 문제를 인지하고 있다면, 이에 맞게 일정을 조정할 수도 있습니다.
코드를 한 번 작성하고 동작하게 만드는 데에는 일정 시간이 걸립니다. 하지만 이 시점에서 겨우 절반을 끝냈다고 생각해야 합니다.
나머지 절반은 다음과 같습니다:
- 코드 정리 및 유지보수성 확보
- 엣지 케이스 및 예외 처리
- 단위 테스트, 통합 테스트, 사용자 테스트
- "마지막 순간"에 들어오는 추가 기능 요청
- 성능 개선, 운영/서비스 안정화
- 문서화
이런 것들은 건너뛸 수도 있지만, 그렇게 하면 결국 형편없는 기능이 나오고 맙니다. 그리고 "나중에 제대로 마무리하겠다"고 생각해도, 아무도 나중에 돌아와서 마무리하지 않습니다.
그리고, 코드 작성을 진행하면서도 예상치 못한 장애물을 마주할 가능성이 큽니다. 이러한 장애물을 최대한 빨리 찾아내는 것이 좋습니다.
만약 예상보다 빨리 끝났다면?
그럼 프로세스를 개선하거나 기술 부채를 청산하세요! (위에서 설명한 내용을 다시 참조하세요.)
좋은 습관을 자동화하라
프로젝트에서 개발자들이 특정한 규칙을 반드시 지켜야 할 때가 있습니다.
- 새로운 모범 사례(best practice)
- 새롭게 적용해야 하는 필수 도구
- 모든 소스 파일에 추가해야 하는 헤더
- 특정 API(내부 또는 외부)를 더 이상 사용하지 않기로 결정한 경우
이런 변경을 개발자들에게 전파하는 방법은 두 가지가 있습니다:
-
직접 홍보하기:
- 회의나 스크럼에서 공지
- 이메일, 위키, README, PR 템플릿 등에 문서화
- 반복적으로 상기시키기
- 모든 코드 변경 사항을 수동으로 검토하며 피드백하기
-
자동화하기:
- 새 가이드라인을 따르지 않으면 테스트가 자동으로 실패하도록 설정
- 모든 코드에 적용할 수 없다면 점진적으로 적용할 수 있도록 래칫(ratchet)을 추가
- 자동 수정 기능을 추가
물론 모든 규칙을 자동화할 수 있는 것은 아닙니다. 또한, 지나치게 엄격한 규칙을 추가하면 오히려 불편을 초래할 수도 있습니다. 하지만, "이거 또 까먹었네. 꼭 지켜주세요!"라고 계속 말해야 하는 상황이 반복된다면, 자동화를 고려해야 합니다.
비정상적인 데이터에 대해 생각하라
누구나 정상적인 데이터가 잘 동작하는지 확인하는 데 집중합니다. 하지만 엣지 케이스가 개발자의 진짜 일입니다.
- 요청이 실패하면?
- 응답이 한 시간 동안 한 바이트씩 전송된다면?
- 테이블에 100만 개, 10억 개의 행이 있다면?
- 문자열에
/가 포함되어 있다면? 공백이 있다면? 1MB 길이라면?
"이 문자열은 절대 비어 있을 수 없습니다"라고 말하는 걸 믿지 않습니다.
더 간단한 방법이 있을 것이다
시간을 제대로 관리했다면(위 참조), 이제 돌아가서 개선할 수 있는지 검토할 시간이 있습니다.
시간이 없으면 "이렇게 긴 글을 써서 죄송합니다. 시간이 부족해서 더 짧게 쓰지 못했습니다." 라는 글을 쓰게 될 것입니다.
테스트 가능하게 코드를 작성하라
- 명확한 인터페이스를 유지하라.
- 부작용(side-effect)을 최소화하라.
- 테스트하기 어려운 코드라면, 코드 구조 자체가 잘못되었을 가능성이 크다.
코드는 ‘증명될 수 있는’ 수준을 넘어서, ‘명백하게’ 올바르게 보일 것
일부 코드들은 우연히 잘 동작하는 것처럼 보일 때가 있습니다. 왜냐하면, 다른 코드들이 특정한 방식으로 작성되어 있어서 문제를 막고 있기 때문입니다. 하지만, 이렇게 하면 다른 코드를 수정할 때 위험이 커집니다.
이것은 보안과 관련된 경우 특히 더 위험합니다. 지금은 안전해 보이지만, 향후 코드가 변경될 때 취약점이 생길 수 있습니다.
마지막으로 한 가지 더 추가하려 했는데, 지금 기억이 안 나네요.
<끝>
마지막 한 가지는 '이렇게 까먹을 수 있으니 어디든 기록해둬라' 아닐까요? ㅎㅎ
