온라인에서 kenny(https://www.facebook.com/kenny.me)로로) 활동하고 있는 친구와 주고 받은 OOP 관련 이야기를 공유해 본다. 다른 이들에게도 느끼는 바가 있을 것이라 생각하기 때문에... kenny의 허락을 받지 않고 공개하는데 이해하리라 생각한다.

• OOP라면... 최대한 DB 사용을 미루는게 좋은 방법이 될 듯 합니다. 술자리에서 여러번 이야기 했지만, DB 사용 시점 부터 개발자 머리 속 데이터 구조가 Excel Worksheet 형태로 고정되는걸 너무 많이 봐서요.
• 제가 클럽베닛에서 개발자 뽑을 때 사용하려고 했던 방법이, 우리 소스 코드 중에 리펙토링 못하고 있는 코드를 직접 보여주고, "어디가 이상한지?" 를 대답하게 하는 거였어요. "이상한거 같은데..." 까지만 나와도 합격. 좋은 소스코드에 대한 감을 길러주긴 굉장히 어려운 일이거든요. 계속 뭔가 이상하다 라는 느낌을 받을 수 있게 스스로 물어보는 습관을 들일 수 있으면 좋아 보입니다. 그 습관이 잡히고 나야 Cyclomatic Complexity 같은 걸 이해 할 수 있거든요. Software Matric(http://en.wikipedia.org/wiki/Software_metric ) 같은게 왜 나왔는지도 이해 할 수 있고요.
• 사실... 좀 미묘한 이야기긴 하지만, *nix 계열만 잘 다뤄도(이게 어려운 일이지만요) OOP 혹은 프로그램 구조화에 대한 기본적인 감은 잡을 수 있다고 봅니다. 예전부터 좀 의아하게 생각했던게, cat sample.txt | less 혹은 cat sample.txt | grep "sample" 같은건 잘 쓰면서, 코드는 왜 저렇게 연결되게 짜질 않을까... 였거든요. *nix 쪽 도구들이 전체적으로, pipe 하나로 엵어서 하나의 프로그램 처럼 유기적으로 돌아가기 때문에 Shell 등으로 자동화 하기 편하거든요. STDOUT/STDIN 을 Redirect 시키는 기법 따위가 중요한게 아니라, 정말 잘 하는 것 하나만 하는 프로그램을 만들고, 그런 프로그램들이 얽혀서 돌아가게 하는 부분은 개발 본질에도 잘 맞아 있는걸로 보입니다. 특히, 이후에 SIGNAL 부분을 이해하면, 서버 프로그래밍 할 때 큰 도움이 됩니다. Rails 쪽에서 최근에 많이 사용하는 Unicorn 같은 서버 프로그램을 보면 굉장히 잘 만들어 놨거든요. http://unicorn.bogomips.org/SIGNALS.html 대표적인게 Unicorn 에서 쓰는 SIGNAL 인데, 보시면 아시겠지만 서버 상태를 전체적으로 SIGNAL로 관리할 수 있게 되어 있어요. (그것도 *nix 표준에 최대한 가까운 형태로요) 따라서, *nix 에 익숙한 관리자들은 편안하게 kill -HUP master_pid 와 같은 형태로 Downtime 없이 배포가 가능합니다.

*nix 관련된 이야기를 좀 풀어서 해 볼께요.

이게 다, Doug Mcllroy 라는 사람이 시작한 일이에요. 50년 전에 저 사람이 끝내주는 발상을 해 냈죠.

Doug Mcllroy는 64년도에 AT&T Bell 연구소에서 Multics 라는 프로젝트를 진행 중이었어요. 이 프로젝트가 이후에 Unix로 발전하게 됩니다.

64년 10월 11일, Doug Mcllroy는 메모를 하나 남기는데, 다음과 같습니다.

10 - Summary--what's most important.

To put my strongest concerns into a nutshell:

1. We should have some ways of connecting programs like garden hose--screw in another segment when it becomes when it becomes necessary to massage data in another way. This is the way of IO also.
2. Our loader should be able to do link-loading and controlled establishment.
3. Our library filling scheme should allow for rather general indexing, responsibility, generations, data path switching.
4. It should be possible to get private system components (all routines are system components) for buggering around with.

M. D. Mcllroy October 11, 1964

(프로그래밍史에 중요한 부분이라 원문 전체를 적었습니다)

신기할 정도로 정확하고 중요한 예측이었어요. 이 네가지 항목이 결국 컴퓨터 프로그래밍을 완전히 바꿔 놓았습니다. Multics 프로젝트가 끝나고, Doug Mcllroy는 Unix 프로젝트에 참여하게 됩니다. 이때 Doug Mcllroy와 함께 작업하신 분들이 모두 프로그래밍 영역에 큰 기여를 하신 분들 입니다.

• Doug Mcllroy : Unix 파이프라인, spell, diff, sort, join, graph, speak, tr 등의 Unix 명령어 개발자
• Ken Thompson : B 언어(C언어에 직접적인 영향), UTF-8 등을 개발
• Dennis Ritchie : C언어 개발자. K&R 스타일에서 R은 이 분을 의미합니다.
• Brian Kerninghan : AWK, The C Programming Language 책이 이 분이 쓰신겁니다. K&R 스타일, AWK의 K는 모두 이 분 이름입니다.
• Michael E. (Mike) Lesk : 컴파일러 개발에 쓰이는 Lex 개발, Portable I/O Library(이게 이후에 C에 있는 stdio.h 가 됩니다.) C언어 전처리기 개발.
• Joseph F. Ossanna : Unix 용 troff 명령어 개발.

한분 한분이 모두 큰 영향을 끼치신 분들이라 일단 소개 해 봤어요. 다시 원래 이야기로 돌아갑니다.

1번 항목이 직접적으로 Unix Pipeline이 되었습니다. 파이프라인(|)이 나와서, 다음과 같은 작업을 할 수 있게 되었어요.

tail -5000 access.log | awk '{print $4}' | sort | uniq -c

access.log 파일의 마지막 5000줄을 가져와서, 4번째 필드만 추출, 정렬 한 다음에 몇번씩 나오는지를 표시합니다. 출력은 다음과 같이 되죠.

  3 [27/Dec/2012:13:27:23
  2 [27/Dec/2012:13:27:24
 11 [27/Dec/2012:13:27:25
 34 [27/Dec/2012:13:27:26
  5 [27/Dec/2012:13:27:27
  7 [27/Dec/2012:13:27:28
 10 [27/Dec/2012:13:27:29
  2 [27/Dec/2012:13:27:30
  1 [27/Dec/2012:13:27:31

이전까지는, 이런식으로 데이터를 넘긴다는 개념이 없었어요. 그러니 뭔가 하나를 만들면, 파일도 읽을 수 있어야 하고, 4번째 필드를 추출 할 수도 있어야 하고, 정렬도 해야 하고, Counting 도 하는 프로그램을 만들어야 했죠.

Mcllroy가 세운 Garden Hose Analogy로 인해 이런 작업이 가능해 졌습니다. 이제 tail 은 파일만 빨리, 잘 읽으면 되고, awk 는 필드 추출 역할만 잘 하면 되고, sort 는 넘어오는걸 정렬만, uniq 는 Counting / 여러번 나오는 것을 하나로 합치는 역할만 잘 하면 됩니다.

1964년에 나온 이 개념은, 이후로 모든 프로그래밍, 프로그램에 영향을 주게 됩니다. 설명하기 쉽게 한국어로 하면, "한 번에 한 가지 일만, 단 제대로."가 되고, 이는 SRP(Single Responsibility Principle)에도 영향을 끼치게 됩니다.

이런 주제에 대한 상세한 소개 및 Ruby 코드 Refactoring 예제가 http://blog.codeclimate.com/blog/2012/11/28/your-objects-the-unix-way/ 에 나와 있어요. 한번 읽어보실 만한 문서라고 생각합니다.

2번 항목이 확장되어서, Dynamic Linking 개념으로 나아갔고, 이를 활용한 결과가 Unix 계열의 .so(Shared Object), Windows 계열의 .dll(Dynamic Linking Library 약자입니다.)입니다.

3번 항목은 결국 검색으로 발전했다고 볼 수 있고요. (비약이 좀 있습니다만. ㅎㅎ)

4번 항목은 (과장되게 말하면) Free Software Movement 쪽으로도 볼 수 있고, 몇몇은 "How can I test this seemingly monolithic program against the sin routine I've just written and want to test?"로 해석하기도 합니다.

결국은 현재 프로그래머들 모두 Mcllroy가 제시했던 사상으로 일한다고 볼 수 있죠.