[2부 7번 수필] 단일 지점 제어
실용주의 프로그래머에서 앤드류 헌터와 데이비드 토머스는 '중복의 해악'이라는 제목으로 DRY(Don't Repeat Yourself)라는 규칙을 강조한다.
모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을만한 표현 양식을 가져야 한다.
헌터와 토머스에 따르면 DRY 원칙은 코딩은 물론이고 코딩과는 전혀 상관없는 여러 문맥(예: 문서화)에서도 나오며, '실용주의 프로그래머' 도구 상자에서 가장 중요한 도구라고 말한다.
'실용주의 프로그래머'를 읽고나서 DRY에 대해 감탄한 분들도 많으셨을텐데... 사실 로버트 L. 글래스 큰형님이 한 걸음 빨랐다. 글래스는 보잉 밀리터리 에어크래프트 사에서 일하는 친구 리 맥로렌의 말을 빌어 '단일 지점 제어'를 강조한다.
단일 지점 제어는 여러 곳에서 해야할 일을 한 곳에서 해결한 후 필요한 곳에서 참조하는 방법이다.
그리고 '단일 지점 제어' 원칙이 소프트웨어 공학의 기본 원리 후보로 추천하고, 프로그래밍 개념을 넘어서 문서와 데이터베이스 설계에도 적용된다는 사실을 언급한다.
때로 '소프트웨어 컨플릭트 2.0이 진부하고 시대에 뒤떨어진 내용을 담고 있다고 말하는 사람을 보게 되는데, 생각이 진부한지 표현이 진부한지 예가 진부한지 너무나도 궁금하다. 핵심은 생각이므로 표현이나 예에 휘둘리지 말자.
"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림
라벨: 단일 지점 제어, 소프트웨어 컨플릭트, 중복, DRY
5 Comments:
-
NUF said...
-
- 일요일, 5월 20, 2007 9:02:00 오전
-
jhrogue said...
-
- 월요일, 5월 21, 2007 6:24:00 오전
-
NUF said...
-
- 화요일, 5월 22, 2007 11:33:00 오전
-
jhrogue said...
-
- 화요일, 5월 22, 2007 5:11:00 오후
-
NUF said...
-
- 화요일, 5월 22, 2007 7:40:00 오후
Home | 댓글 쓰기전 그 책의 생각이 진부하다고는 생각하지 않습니다. 다만 판이 거듭됨에도 불구하고 내용이 발전되는게 아무것도 없다는 사실과, 그 책이 문제제기는 하되 아무런 답의 제시가 없다는 것이 불만일 뿐이죠. 어느정도 경험을 쌓은 엔지니어라면 직감적으로 느끼고 있는 문제점들을 정리했을 뿐, 그 이상의 가치는 찾지 못했습니다. 문제를 제기하는 것은 주변의 툴툴거리길 좋아하는 엔지니어라면 누구라도 할 수 있는게 아닐까요?
더불어 단일지점제어는 그 단일지점이 문제를 일으켰을 경우 그 영향이 모든 시스템으로 확산된다는 문제를 가지고 있기에 개발당시엔 몰라도 운영중에는 심각한 문제가 될 수 있다고 생각합니다. 특히나 현재처럼 여러 시스템이 복잡하게 얽혀서 돌아가는 상황에서는 말이죠. 즉, 개발시엔 단일지점에서 제어를 하더라도, 그것이 운영될 때에는 단일지점이 되지 않게 고려해야 할 것입니다. (운영상의 단일지점을 Singleton Resource라고 표현하는 듯 합니다만..)
1. 문제 제기는 누구라도 할 수 있다고 말씀 주셨는데, 문제 정리와 쟁점 제기에도 격이 있습니다. :)
제가 "대한민국 개발자 희망 보고서"라는 책을 읽어보았는데, 읽는 도중에는 속이 후련하고 뭔가 답이 나오는 듯이 느껴졌지만, 참으로 이상하게도 읽고 나서 거의 한 달이 된 시점에서 기억나는 내용은 단 하나도 없습니다.
반면에 로버트 L. 글래스가 제기한 각종 문제는 계속해서 제 머리 속을 떠나고 있지 않습니다.
반드시 엔지니어에게 답을 제공할 필요는 없다는 생각입니다. 어차피 개발자 마다 상황이 다르므로 정답이란 없을테니까요.
2. 조금 극단적인 예가 될지 모르겠지만, 개발시에는 단일지점에서 제어를 하더라도, 운영될 때는 단일지점이 되지 않게 고려해야 한다면 glibc와 같은 공유 라이브러리 사용은 상상조차 하지 못합니다.
사람의 생명이나 돈을 다루는 mission critical 한 시스템에서는 단일 지점 개념 대신에 중복과 중첩을 허용하는 N 버전 프로그래밍 기법을 사용해야 할지 모르겠지만, 우리가 운영하고 개발하는 일반적인 소프트웨어에서는 특별한 이유가 없다면 단일 지점 운영을 피해야할 경우가 있을까요?
- 박재호 올림
위 책의 1판에 대한 추천 서문에서 도날드 J. 리퍼는 아래와 같이 말하고 있습니다.
'이 책을 많이 좋아하지만 몇가지 문제점도 있습니다. 첫째 책이 너무 깁니다. 저자가 할 말이 많은 탓에, 종종 핵심에 이르기까지 너무 오래 걸립니다. 둘째 책이 너무 짧습니다. 뭔가 해결책이 나올 법한 시점에 이르자마자, 저자는 이야기를 중단하고 독자가 스스로 생각하게 만듭니다.'
제가 하는 얘기가 바로 같은 겁니다. 님이 말씀하시듯 격이 틀린 문제제기인지는 모르지만 문제제기만은 아무나 할 수 있다는 것이 제 이전 글의 요지였지요.
제 경우, 위 책을 읽기 전에도 현업에서 같은 문제들에 대한 고민은 하고 있었고 그게 이 책에도 적혀 있구나.. 하는 정도였지요.
더불어 반드시 엔지니어에게 답을 제시할 필요가 없다는 얘기는 저자의 의도-학계와 실무현장의 협업을 강조하는-와는 상반되는 것 같습니다.
단일지점제어에 대해서는, 전 프로그래밍이 아니라 시스템 설계의 관점에서 말씀드린 것입니다. 실제 기업의 시스템에서는 데이터를 여러 곳에 복사해서 가지고 있는 경우가 많지요. 그게 옳다는 것은 아니지만 해당 데이터가 단일지점이 되는 것을 피하기 위해서인 경우가 많지요. 그 데이터를 관리하는 시스템이 멈추거나 했을 때-그게 계획된 것이던 돌발적인 상황이던- 그 영향을 나머지 모든 시스템이 받아 버리는 것을 피하기 위해서입니다. 각 기업의 시스템 설계자들이 단일지점제어의 장점을 몰라서 그런 설계를 하고 있는게 아니지요. (물론 이 얘기는 위 책에서 말하는 개발중의 얘기가 아니기에 운영중에는.. 이라고 조건을 달아 말씀드렸습니다.)
여기서 얘기를 님이 말씀하신 프로그래밍의 관점으로 옮겨 보지요. 말씀하신 glibc와 같은 라이브러리의 경우, 충분히 검증되고 굉장히 범용적인 라이브러리라 OS와 같은 수준에서 생각해도 될 법합니다. 더불어 정적이지요. 하지만 최근의 어플리케이션 개발 트랜드, 특히나 SOA에서 말하는 서비스-하나의 기능을 하나의 서비스로 제공하고 나머지 모든 시스템이 그 서비스를 이용하는 아키택쳐-를 이용한 프로그램을 작성할 때에 사용중인 서비스가 멈추어져 버린다면 어떻게 될까요? 이 때에 glibc와의 차이는 서비스는 동적이고-즉, 가동중과 정지중이라는 상태를 가지고- 자신의 관리 및 제어 범위 외에 존재할 수 있다는 것입니다.
예를 들면 아마존의 웹 서비스를 이용해 전자상거래를 수행하는 수많은 사이트의 프로그램 안에서, 아마존의 서비스는 하나의 모듈 내지는 컴포넌트로서 사용이 될 것입니다. 그런데 아마존의 웹서비스가 멈춰 버린다면, 또는 버전업이 되면서 인터페이스가 바뀌어 버린다면 그 서비스를 이용하는 수많은 관련기업들의 시스템은 어떻게 대응을 해야 할까요? 따라서 아마존은 단일지점인 그 서비스가 절대 멈추지 않도록 충분한 대비-시스템의 다중화, 대기기의 운용 등-를 해야 합니다. 인터페이스의 신뢰성을 약속해야 하고, 부득이한 변경이 있을 경우엔 기존의 버전과 신버전의 서비스를 동시에 제공해야 하지요. (이런 관점에선 -최근의 프로그래밍 트랜드가 반영되지 않았다는 점- 위 책의 내용은 일부 진부하다고도 할 수 있겠네요.)
그러고 보니 전 님이 말씀하신 미션 크리티컬한 시스템에 대한 얘기를 하고 있군요. (그런데, 요즘에는 어떤 시스템도 다 미션 크리티컬하지 않나요?)
결론적으로, 전 단일지점제어가 안 좋다는게 아니라, 단일지점제어에는 위 책에서 언급하지 않은 문제점도 있으니, -특히나 최근엔 그 문제점이 더 부각되는 환경이 되어가고 있으니- 조심할 건 조심하면서 적용하자는 얘기를 하고 싶었을 뿐입니다.
1. 책에 대한 생각은 독자마다 의견이 다르므로, 제가 특별히 여기에 덧붙여 추가로 말씀드릴 내용은 없습니다. 좋은 의견 감사드립니다.
2. 수민님께서는 돈과 생명이 아주 중요한 시스템을 개발할 경우 운영과정에서 '단일 지점 제어'가 만병통치약이 아니라는 의견을 피력하셨다고 간략하게 정리를 해봅니다.
하지만 '단일 지점 제어'가 최근 프로그래밍 동향과 거리가 멀다는 말씀에는 동감하기 어렵습니다. _운영_ 과정에서 심각한 문제가 될 지언정 _개념적_으로 바라보면 전혀 문제가 되지 않기 때문입니다.
http://www.artima.com/intv/dry.html를 읽어보시면 도움이 될겁니다. 데이브 토마스가 DRY에 대해 사람들이 다소 오해를 하고 있다고 설명하는 글인데, 단일지점제어 역시 유사한 오해를 불러일으킬 가능성이 높다는 생각입니다. 여러분을 위해 본문 일부를 번역해드립니다.
"대다수 사람은 DRY를 '코드를 중복하지 마라'는 의미로 받아들인다. 하지만 DRY의 의도는 그렇게 단순하지 않다. DRY 이면에 숨겨진 사상은 이런 단순함을 넘어선다.
DRY는 모든 시스템 지식 부분이 믿을만하며, 모호하지 않은 표현으로 나타나야 함을 말한다. 뭔가를 개발하는 도중에 지식의 각 부분은 단일하게 표현되어야 한다. 시스템의 지식은 단순히 코드 수준을 넘어서 훨씬 방대하다. 시스템 지식은 데이터베이스 스키마, 테스트 계획, 빌드 시스템, 심지어 문서까지 확장된다."
가장 마지막 문단은 로버트 L 글래스가 소프트웨어 컨플릭트 2.0 번역판 77페이지 마지막 두 문단에 나온 내용과 거의 흡사합니다(로버트 L 글래스도 똑같이 단일 지점 제어를 활용하는 예로 데이터베이스와 문서화를 손꼽습니다). DRY나 단일지점제어는 시스템 운영 관점이 아니라 시스템 표현 관점이라는 사실을 다시 한번 강조하고 싶습니다.
박재호 올림
음? 전 '단일 지점 제어가 최근 프로그래밍 동향과 거리가 멀다'고 한적은 없습니다만...
운영이 아니라 표현의 문제라는 지적은 정확하십시다.