[개발자 원칙] 제어할 수 없는 것에 의존하지 않기 (이동욱 향로)

저는 10년이 안 되는 기간 동안 프로그래머로 활동해왔습니다. 이렇게 글을 쓸 기회도 있는 걸 보면 꽤나 운이 좋은 것 같습니다. SI, 인터넷 포털, O2O 스타트업, 에듀테크 등 여러 분야의 소프트웨어 기업에서 근무하면서 팀원, 리드 등의 역할을 하다 보니 고민 상담 기회 도 많았습니다. 취준생이 아닌 현직에서 일을 하는 분들이 저에게 요청한 고민 중에서 자주 등장하는 질문이 있습니다.

“ 일정을 지키고자 버그가 많은 소프트웨어를 출시하는 것이 마음에 들지 않습니다. 어떻게 하면 일정을 연기해서 안정된 소프트웨어를 내는 것이 더 중요하다고 리더들을 설득할 수 있을까요?”

이런 고민에 대해 저는 윈도우 95의 프로그래머 나카지마 사토시의 이 야기를 항상 전달합니다.

“ 프로그래머에게 요구되는 것은 100점이 아닌 80~90점짜리 프로그램을 기한 내에 완성하는 일이다.” 나카지마 사토시, 《오늘, 또 일을 미루고 말았다》 중

이렇게만 답변을 마무리하면 “퀄리티보다 일정이 더 중요한 것인가” 라고 생각이 들 수도 있습니다. 그래서 항상 “일정과 퀄리티는 어느 한쪽 을 포기해야 한다와 같은 시소 관계가 아니라, 어떻게 하면 아무리 급해도항상 80~90점짜리 소프트웨어를 개발할 수 있는지가 중요하다”라는 말을 덧붙입니다.

이 답변은 “그럼 어떻게 하면 항상 80~90점의 소프트웨어를 개발할 수 있나요?”라는 질문을 내포합니다. 빠듯한 일정으로 일이 주어져도 항상 80~90점의 소프트웨어를 출시하는 분들이 있습니다. 옆에서 지켜보면서 그분들의 공통점을 찾아내려고 노력했습니다. 경험과 학습으로 체득된 그분들만의 소프트웨어 원칙을요. 프로그래밍은 수많은 선택의 연속입니다. 일반적으로 A 코드가 더 나을지, B 코드가 더 나을지 고민하면서 적지 않은 시간을 보내게 되는데, 그분들은 A 코드와 B 코드 중 현재 상황에 더 적합한 코드를 판별하는 기준과 원칙이 있어 고민 없이 곧바로 선택합니다.

기준과 원칙에 따라 빠르게 결정을 내리면, 정말 중요한 설계와 선택이 필요할 때 더 깊게 사고할 수 있는 시간을 확보하고 사용하게 됩니다. 그러다 보니 항상 일정과 퀄리티 두 마리 토끼를 잡을 수 있는 것 같습니다.

대니얼 J. 레비틴의 《정리하는 뇌》에서는 머릿속이 정리되면 크게 애쓰지 않아도 좋은 의사결정을 할 수 있다고 이야기합니다. 이 주장을 인용하면 본인만의 원칙을 세워 고민거리의 숫자가 빠르게 줄면 약속된 시간에 약속된 품질의 소프트웨어를 출시할 수 있게 되는 겁니다. 이런 분들과 일하면 자연스레 저의 소프트웨어 원칙도 되돌아보게 됩니다. ‘나는 좋은 원칙을 알고 있는가? 그 원칙들이 무의식적으로도 발현되게 내재화되어 있는가?’ 말이죠.

소프트웨어 개발자 사이에 가장 널리 알려진 원칙으로 DRY, YAGNI, KISS 원칙을 들 수 있을 겁니다.

• DRY(Do not Repeat Yourself) : 똑같은 기능, 코드를 반복하지 마라.
• YAGNI(You Ain’t Gonna Need It) : 그 기능이 필요하기 전까지는 미리 만들지 말라.
• KISS(Keep It Simple Stupid) : 최대한 단순함을 유지하라.

이 원칙들이 저에게 가장 중요한 원칙들일까요? 주변에 있는 뛰어난 프로그래머들을 보면서 저 스스로를 한 번 생각해보게 되었습니다. “나는 평소에 어떤 원칙을 가지고 소프트웨어를 개발하는가? 수많은 원칙 중에서 내가 가장 좋아하는 원칙은 무엇인가?” 이 질문에 대답을 하자니 어떻게 대답해야 하는지 상당히 망설여집니다. 왜냐하면 소프트웨어 개발이 하나의 원칙으로 이루어지지 않기 때문입니다. 그간 듣고, 배운 다양한 원칙과 기준 중에서 어느 것 하나가 최우선이 되어서 개발한 적이 없었고, 지금도 마찬가지입니다. 언급한 DRY, YAGNI, KISS 원칙 역시 꾸준히 적용하고 당연하게 사용하지만 제가 가장 애정하는 원칙은 아닙니다.

앞서 말씀드렸듯이 소프트웨어 개발이 단 하나의 ‘원칙’만으로 이루어지는 것이 아니므로 원칙 간에 순위를 매길 수는 없다고 생각합니다. 그렇지만 가장 자주 활용하는 원칙을 뽑아볼 수 있지는 않을까 생각해봅니다.

인프랩이라는 조직에 합류하고 Node.js를 처음으로 프로덕션 레벨에서 사용하게 되었습니다. 지금 생각해보면 당시의 저는 Node.js에 대한 숙련도가 낮을 때임에도 불구하고 당연하게 적용한 원칙들이 있었습니다. “언어와 프레임워크가 다르더라도 동일하게 적용될 거다”라는 확신이 있던 것 같습니다. 코드와 시스템 설계에 대해 깊게 고민을 할 때 종종 떠올리는 원칙이 있는가 하면, 깊은 고민 없이 무의식 상태에서도 당연하게 적용되는 원칙이 있었던 겁니다.

무의식적으로 쓰는 혹은 애정하는 원칙은 여럿이 있지만, 그중에서도 제가 가장 애정하는 원칙은 “제어할 수 없는 것에 의존하지 않기”입니다. 이 원칙을 《실용주의 프로그래머》에서 처음 알게 되었습니다.

“ 현실 세계의 변화와 설계 사이의 결합도를 줄여야 한다. 전화번호를 식별자로 사용하는가? 자신의 힘으로 제어할 수 없는 속성에 의존하지 말라”《실용주의 프로그래머》 중

자신이 제어할 수 없는 현실 세계 속성을 사용하는 경우를 알아봅시다. 예를 들어 주민등록 번호를 데이터베이스 테이블의 PKPrimary Key로 사용하는 경우입니다. 주민등록번호는 대한민국이라는 국가에서 발행한 유일값이므로 신뢰할 수 있지 않겠나라고 주장할 수 있겠지만, 실제로 주민등록번호를 사용하려면 한 번의 변화와 크나큰 제약을 고려해야 합니다.

• 변환 : 1975년 주민등록번호 체계가 변경되었습니다.
• 제약 : 2014년 주민등록번호 무분별한 수집이 금지되었습니다.

2014년에 법으로 주민등록번호의 무분별한 수집이 금지되면서, 그간 주민등록번호를 주요 키로 사용하던 시스템들은 비즈니스 로직 구현을 뒤로 하고 주민등록번호와의 의존성을 끊는 시스템 업데이트를 먼저 진행할 수밖에 없었습니다. 절대 변하지 않을 것이라 믿고 의존했던 속성이었지만, 제어할 수 없는 외부의 속성이었기에 이런 일이 발생한 겁니다. PK를 직접 만든 키(Key)로 설정했다면, 법이 바뀌어도 큰 수고를 들이지 않고 변화에 대응할 수 있었을 겁니다. 이처럼 제어할 수 없는 것에 의존하면 변화에 민감한, 흔들리기 쉬운 소프트웨어가 됩니다. 반대로 프로그래

머는 설계를 하는 데 있어 외부에 의존하는 영역을 줄일수록 큰 변화에도 쉽게 흔들리지 않는 견고한 소프트웨어를 개발할 수 있습니다.

이제까지 현실 세계의 속성과 소프트웨어 간 의존 관계를 이야기해보았습니다. 추가로 제가 이 원칙을 사용한 사례 3가지를 이제부터 3차례에 나누어 살펴보겠습니다.

1. 코드 설계에 적용하기
2. 이직에 적용하기
3. 조직과 매니징에 적용하기

다음 글에서 다시 만나뵙겠습니다. 긴 글을 읽어주셔서 감사드립니다.