Gloridea On The Stage

Reverse DNS Lookup은 접속한 클라이언트의 IP를 바탕으로, 그 클라이언트의 hostname을 얻어내는 DNS 질의이다.

일반적인 서비스에서 리얼타임으로 이 Reverse DNS Lookup을 쓸 일은 많지 않다. IP로 로깅하고, 추후 분석 시 Reverse DNS Lookup을 실행하는 것이 더 일반적이다.

DNS 설정이 잘못되거나, 상위 Reverse DNS Resolver Server에 문제가 발생할 경우, 이 단계에서 시간을 소모하여 접속이 느려지는 상황이 발생할 수 있다. 다른 장애 조짐과는 달리, 최초 접속이 심각하게 느리고, 나머지 처리는 정상적인 속도를 보이는 특징이 있다.

MySQL

MySQL이 Reverse DNS Lookup 을 사용하는 상태에서, Reverse DNS Lookup 응답이 늦어지면, 다음과 같은 특징을 보인다.

• connection 생성 자체는 느리나, 쿼리 실행은 빠르다.
  
• show processlist 명령 시 unauthenticated user 가 여럿 보인다.
  

원인은 connection을 받아들일 때 Reverse DNS Lookup을 수행하기 때문이며, 다음과 같이 해결 가능하다. ( 참고 )

• mysql 구동 시 --skip-name-resolve 옵션을 주거나
  
• /etc/my.cnf 에 다음 설정을 추가한다.
  

[mysqld]
skip-name-resolve

Apache

Apache에서는 다음과 같은 사항을 검토한다. ( 참고 )

• HostnameLookups On 으로 설정되어 있을 경우, Off로 설정한다.
  
• Allow / Deny 룰을 도메인 기반으로 설정하지 않는다. (ex. Deny from example.org )
  주의: Deny from none 으로 설정하지 않는다. none은 올바른 지시자가 아니다. ( 참고 )
  
• LogFormat 에 %h 대신 %a 를 사용한다. 황당하게도, %h가 기본 포맷이다.

모종의 설계 - 혹은 회의라도 상관없다 - 를 진행할 때 가장 주의해야 하는 점 중 하나는 '디테일한 사안에 빠져 시간을 소모하지 않아야 한다'는 것이다. 비교적 적은 시간을 들여 큰 방향과 뼈대를 잡아, 전체 흐름이 잘못될 가능성을 줄이는 것이 그 단계의 가장 중요한 미덕이기 때문이다.

그런데 이 얘기를 '디테일한 문제를 다뤄서는 안된다' 로 잘 못 이해하는 경우를 종종 본다. 그러나 디테일을 순간 순간 확인하지 않고 구조를 정의할 수 있을까? 대체로 불가능하다. 디테일은 빈번하게 핵심 제약조건과 섞여 있기 때문이다. 정말로, 악마는 디테일에 숨어 있다. 원론적인 악의는 없다. 지구의 멸망을 도모하는 집단 같은 건 없다.

디테일 속 악마를 착아내는 일은 다분히 경험적이다. 자신이 학습하고 경험한 몇 가지 가능성을 조합하고 순간적으로 연결하여, 대응 가능한 방법을 찾아내고, 그것이 가능할지 여부를 샘플링을 통해 검증한다.

잘 정의된 문제는 연구하기가 쉽기 때문에 많은 연구가 이루어져 있습니다. 하지만 우리가 실생활에서 만나는 대다수의 문제는 잘 정의되지 않은 문제입니다. 사실상 뭔가 만들어 내야 하는 문제, 즉 디자인(설계)이 개입되는 것은 거의 다 제대로 정의될 수 없는 문제입니다.

앞서의 전문가들은 자신이 자주 접하지 않았던 문제, 어려운 문제, 혹은 잘 정의되지 않은 문제를 접하면 접근법을 바꿉니다. 탑다운과 버텀업을, 순방향과 역방향 사고를 섞어 씁니다. 전문가일수록 더욱 그러합니다. 비전문가는 어려운 문제 상황에 대한 인식력이 부족하며 자기의 문제 풀이 전략을 능동적으로 선택하지 못합니다. 오히려 억지로 탑다운, 혹은 바텀업 등 한가지에 집착하려고 합니다.

- 김창준 ( 전문가에 대한 미신 : 협력을 어떻게 할까 )

설계 - 혹은 프로세스일 수도 있다 - 는 결국 이런 디테일을 가지는 각 사항들이 체계를 가지고 서로 연관을 맺게 하는 작업이다. 극단적으로 나누어 이야기 하자면, 설계하기 위해서 구현하는 게 아니라, 구현하기 위해서 설계하는 것이다. 당연히 디테일에 대한 의존성이 존재한다. 특수한 상황일수록 의존성은 더욱 증가한다.

요는, 디테일에 접근하느냐 마느냐가 아니라, 얼마나 작은 접근 비용으로 충분히 신뢰할만한 디테일을 가정할 수 있느냐이다. 이 비용이 지나치게 높아졌을 때 '산으로 갔다' 라고 표현하는 것이다. 산으로 갈 가능성이 있다고 해서 모든 디테일한 논의의 싹을 자르는 일은, 숨어 있는 악마도 같이 떠안겠다는 의지가 될 수밖에 없다.

설계 과정에서 확인해야 하는 디테일 속의 악마는 단지 향후에 일어날 어떤 일의 가능성 정도만을 의미하지는 않는다. 근본적으로 그 일의 가치와, 소요 비용이라는 아주 근본적인 변수와 닿아 있을 때가 훨씬 많다

방송을 보면서, 안되는 영어로 쩔쩔매는 그들을 보며 확실히 안쓰럽긴 했지만, 그게 부끄럽다거나 하지는 않았다. 그게 왜 부끄러워야 하는 건지 잘 이해할 수 없다. 무시당해서? 어느 곳에나 불친절한 사람은 있고, 그 나라 말을 잘 못하면 그런 반응쯤은 어렵잖게 볼 수 있다. 그리고 그런 무시는 무시를 한 사람이 문제이지, 무시를 당한 게 부끄러운 일은 아니다.

만약 촬영 장소가 뉴욕이 아니고 대충 뭐 이라크 바그다드(그냥 문득 떠오른 곳이 바그다드였다. 바그다드에 별 감정은 없다.;; )쯤이었다고 한다면, 그래도 그렇게 부끄러웠을까? 아랍어 몇 마디 하지 못해 쩔쩔매는 모습과, 이라크 방송에 나가서 되지 않는 아랍어로 김치, 불고기 어쩌고 하고 있는 모습이 그렇게 부끄럽게 보였을까? 확언할 수는 없지만, 아마 아니지 않을까.

부끄러움은 자신의 시선을 투사한 결과이다. 그 부끄러움을 느낀 사람 자체가 (대놓고, 혹은 은연중에) 미국, 그리고 영어에 대해 열등감을 품고 있다는 얘기다. 유감스럽게도 한국에서 나고 자라서 그 열등감으로부터 자유로울 수 있는 사람은 거의 없다. 오렌지네 어륀쥐네 하는 논란이 뉴스를 타는 세태만 보아도 분명히 드러난다. 영어가 실용적 의미를 넘어선 '신분' 코드이며 그것이 전달하는 의미보다 어떻게 보여지느냐가 중요하다는 것을 의미한다.

학원이 아닌 곳에서, 영어 외의 다른 외국어에 대해 발음이 구리다고 서로 민망해하는 일을 보기란 쉽지 않다. 중국어 한 두 마디쯤은 누구나 들어서 주워 섬기면서도, 그 황당한 발음이 부끄럽다고 여기지 않는다. 오히려 그 낯섦을 즐긴다. 영어는 그렇지 않다. 자신이 아웃카스트임을 들킬까봐 혀에 버터를 바르려고 필사적이다.

그런 자신의 열등감을 드러나게 한 사람들이 잘못인걸까. 차마 보일까 두려운 흉터처럼 필사적으로 숨겨두고 누가 언급이라도 할세라 전전긍긍 하면서 지내야 하는 걸까. 그리다가 혹여라도 누가 건드리면 버럭 화를 내야 하는 그런 문제일까.

그게 아니라면, 오히려 거기서 느껴진 불편함에서 발견해야 하는 건, 자신이 묵시적으로 영어에 권위를 부여하고, 그것으로부터 부정당할까봐 벌벌 떨고 있다는 사실이 아닐까. 그리고 그런 두려움의 근간에 뭐가 있는지, 좀 더 생각해볼 일이 아닐까.

일단, 오전 발표 전체보다는 발표에 앞서 김창준씨가 Kent Beck을 소개하면서 했던 이야기 중 개인적으로 생각해볼만한 부분이 있었다. "단순성에 대한 집착" 이라는 얘기였는데, "단순한 아이디어를 극단적으로 적용하는 실험"을 언급했다. 내 경우는 트레이드오프에 대한 계산을 상당히 일찍 하는 편이라서, 그러한 무식함(?)으로부터 얻을 수 있는 통찰을 종종 놓치기도 했다. (생계형 프로그래머의 비극일까) 하지만 서비스 코드에 극단적(?) 실험을 하는 것이 바람직한 일이라는 생각은 들지 않는다. 그래서 항상 머릿속으로 충분히 납득할 수 있을때까지 상상해보는데, 역시 현실은 언제나 상상과 다르다. 그 과정에서 많은 것을 배우긴 하지만.

오전의 이야기는 듣다가 잠시 졸아버렸는데, 별 특별한 얘긴 없었다. '자신이 어떻게 하는지를 관찰' 하는 것에 대한 얘기 정도가 주목할만한 내용이었다. 그는 자신이 디자인을 추가할 때 했던 생각들을 카드에 적어놓고 그것을 다시 분류해서 4가지 정도의 디자인 전략으로 정리를 했다고 한다. 이 얘기는 오후에 자세히 다루어졌다.

오후에 발표된 내용들은 오전보다는 나았다. 그 중 개인적인 통찰을 얻은 것들을 정리하면 다음과 같다.

Latency, Throughput, Varience 중 어디에 초점을 맞출 것인가 하는 질문은 나름 유익했다. 어쩌면 당연한 답이기도 한데, 해당 분야의 성숙도나 기회비용에 따라 다르다. 지역 최적이 전체 최적이 아니라는 얘기는 이미 많이 다루어진 바 있다.

바둑의 사례를 들면서 Ambiguity, 즉 모호성을 수용하는 것의 중요함을 이야기했다. 무언가를 어떻게 해야 할지 알 수 없다면, 일단 그대로 두라는 것. 이미 지나치게(?) 하고 있던 부분이라 별 걱정은 되지 않는다. 명료한 디자인은 해결해야 할 문제 집합 속에서 드러나므로 당연한 얘기이기도 하다. 오히려 더 많은 이들에게 중요한 문제는, 모호성 속에서 명쾌하고 간결한 해답이 드러난 시점에 이를 전체 디자인에 반영할 시간을 조직적 합의속에서 어떻게 이끌어낼 수 있을까 하는 부분이 아닐까. 의지를 가진 사람들이 개개인의 노력과 헌신으로 진행하다가 지쳐서 쓰러지는 지점이기도 하다.

디자인에 대한 정의는 아주 명료하고, 곱씹을만했다. 항상 그렇듯 너무나 당연한 단어들의 집합인데, 명료하게 드러난 정의는 역으로 그 정의를 실현하는데 상당한 도움을 주기 때문에 매우 유익하다.

Kent Beck은 디자인을 이렇게 정의했다.
< Beneficially Relating Elements >

결국 Design이란 서로 이익이 되도록 요소들을 관계짓는 것이라는 이야기이다. 디자인상의 고민에 부딪혔을 때, 이 화두를 다시 꺼내들고 곱씹어볼만한 가치는 충분하다는 생각이 들었다.

좀 더 정확히는 아래와 같이 얘기했다.

Design is beneficially relating elements.
Designing is beneficially relating elements.

이 두 문장을 이야기 했습니다. 첫번째에서 beneficially relating은 elements를 꾸며줍니다.
elements가 relating의 주어인 셈이죠. 즉, 결과로서의 디자인은 이로운 관계의 요소들이라는 말입니다. 두번째에서
elements는 relating의 목적어입니다. 과정으로서의 디자인은 요소들을 이롭게 관계 맺는 행위이다 라는 말입니다.

- 김창준님의 Xper group의 토론 내용 답변 중에서

결합과 응집에 대한 얘긴 특별히 새롭지 않으므로 패스.

그 후에 다루어진 것이 이번 발표의 중심 내용인 디자인 추가의 4(+1)가지 전략이다. 디자인을 추가할 때는 다음 4(+1)가지 중 한가지 패턴을 따르게 된다고 한다.

1. Leap - 도약
2. Parallel - 병렬
3. Stepping Stone - 징검다리
4. Simplification - 단순화
5. ( Add it anyway - 어쨌거나 일단 구현하기 )

각각을 설명한 뒤 자신이 최근에 경험했던 4가지 패턴에 해당하는 사례들을 각자 논의해보라고 했다. 그리고 자신이 어떤 디자인을 할 때, 저 네가지 중 어느쪽에 속하는지를 생각하는 연습을 해보라고 했다. (잘 못 들은 게 아니라면) 하지만 잘 납득되지 않는 것이, 저 네가지 전략은 선택한 다음 파악하는 게 아니라, 현실적 요구에 의해 저 네가지 전략 중 하나를 선택하는 것이다.

디자인 패턴을 쓸 때도 이 패턴을 써야지 해서 쓰는 게 아니라, 현실에 존재하는 문제의 여러 측면을 고려한 결과로 어떤 패턴을 쓸지가 결정된다. 그게 순서다. 그럼 자신이 현재 쓰고 있는 패턴을 명확하게 인지해야 한다는 것은 무슨 장점이 있을까? 잘 납득이 가지 않아 쉬는 시간에 회사 분들과 얘기를 하면서, 각각의 패턴이 가지는 Pros/Cons 정도를 다시 검토해볼 수 있다는 정도가 아닐까... 라는 추측을 했지만, 썩 납득이 가는 결론은 아니었다.

그리고, Stepping Stone에 대해서는 주변 여러 사람들이 혼란스러워했다. 아마 메타포가 적절하지 않았던 것이 이유가 아닐가 싶은데, 패턴 사용 조건에 대해서는 이렇게 소개했다.

If

• You can't imagine exactly what you want to build but
  
• You can imagine what would make to the end easier / safer to reach
  

Build a platform from which your goal is easier to reach

그러면서 framework-first 전략의 사례를 다루었다. 간단히 요약하자면, 정확히 뭐가 필요할지는 장담할 수 없지만, 뭔가 필요할거라고 생각되는 것들을 먼저 만들어놓고 일을 하는 패턴을 말한다. (잘 못 이해했나?) 그런데 Stepping Stone이라는 메타포와 이 설명과는 아무래도 좀 괴리가 있지 않나 싶은 생각이 들었다. 징검다리라 하면 한 발자국씩 디뎌 가는 장면을 떠올리게 마련이어서가 아닐까 싶다.

덧1(@2009-09-06 01:58). Stepping Stone은 징검돌, Stepping Stones는 징검다리이다(김창준님의 지적). 안습인 영어실력 덕분에 둘을 분간하지 못하고 이해해버렸다. orz. 곱씹어 생각하면 역시 좀 느낌이 다르긴 하다. 그래도 역시 좀 더 좋은 메타포가 있을거란 생각은 든다. (나만 헷갈렸던 게 아닌지라.)

그리고 마지막 시간에는 리팩토링에 대해서 다루었다.

extract 와 inline은 항상 역이 존재하므로, 어느 방향으로도 리팩토링 할 수 있어야 한다. 풀어헤쳐서 다시 엮는 과정을 거칠 수 있다. (이 얘기는 좀 뒤에 나왔다.)

변경할 부분을 먼저 고립시켜야 한다. 사실, 구체적인 테크닉으로서는 가장 유용했다. 변경할 라인이 있을 경우, 먼저 그 부분을 extract method를 한 뒤, (그러면 전후관계가 정리되고, 변경 범위가 고립된다) 해당 부분을 수정하고 그 다음에 다시 inlining 할 것인지 말 것인지를 결정한다.

그리고 가장 중요한 원칙 "어려운 변경은 하지 않는다". 이건 확실히 지킬만한 가치가 있다는 생각이 들었다.

그 외에, "객체의 field들은 동일한 수명주기를 가져야 한다. 그렇지 않은 field가 존재한다면 bad smell로 볼 수 있고, 그 field는 다른 곳에 있어야 하는 것이 아닌가 생각해볼 필요가 있다"는 얘기도 유익했다.

감상.
소문난 잔치에 갔다가 굶어죽을 뻔 했다. 오전 9시부터 저녁 5시까지면 책을 2권은 읽을 수 있는 시간이다. (뭐 그렇다고 그 시간을 주면 책을 읽느냐... 라고 하면 그건 음;; )

감상2.
전날 저녁에 Kent Beck과의 만남이라는 모임이 있었는데, 외쿡인 모셔놓고 재롱잔치 한 것 같아서 맘이 심히 불편했다. 뻔히 어떤 대답이 나올지 알 것 같은 얘기들과, 그나마도 연극이라는 형식을 취하는 바람에 심각히 전달력을 잃어버렸다. 덕분에 뻔한 주제와 뻔한 대답이 반복되었다.

너무 뻔한 얘기 시리즈.

배운 것은 익혀야 쓸 수 있다. 프로그래밍 언어 문법을 배운다고 소프트웨어를 개발할 수 있는 것이 아니다. 수많은 날들을 고민으로 지새야 비로소 소프트웨어 비스무리한거라도 만들게 된다. 세상에 그렇지 않은 것은 없다. 그래서 '학습(學習)'이라 한다. '습'을 배제하고 '그런 것이 있구나 '정도의 지식으로 헤쳐나갈수 있는 전문 분야는 없다. 그러므로 익힘은 배움의 전체 주기에서 선택이 아니라 필수이다.

지식 노동 조직은 이 학습에 굉장한 노력과 비용을 들인다. 지식 노동자의 지적 역량이 경쟁력을 본질적으로 좌우하기 때문이다. 그 역량에 따라 '더 새롭고 더 좋은 결과물을 더 빠른 시간에 더 좋은 품질로' 만들어낼 수 있다. 단점이 거의 없는 - 굳이 단점이라면 이직 가능성이 높아지는 정도? - 거의 유일한 개선 방법이다. 다른 모든 장치들은 이것보다 훨씬 많은 부작용을 가진다.

그럼에도 불구하고 많은 지식 노동 조직은 '학'에만 집중하고 '습'을 놓친다. '학'씩이나 시켜줬으면 됐지 '습'은 알아서 해야 하는 것 아니냐고. 회사는 학교가 아니라고. 그렇게 말하지 않는 조직도 '습'을 위한 섬세한 절차를 갖춘 곳은 많지 않다. 하지만 본질은 '습'에 있다.

학과 습의 괴리는 자존심에까지 영향을 미치게 된다. 배우되 쓰지 못한 것은 단지 익힘이 부족할 뿐이었을지도 모르지만, 배운 사람의 정서에는 배워놓고도 쓰지 못한 것으로 각인되고, 그런 경험이 반복되면 배움 자체가 현실과는 유리된 부담스러운 그 무엇이 된다. 그럴 때 사람은 자신의 정서적 안정을 위해 배워야 할 내용의 가치를 다시 셈한다. 그리고 자신의 옛 기억 속에서 비슷한 무엇을 더듬어 '그거 옛날에 해봤는데 별 소용이 없어'라고 답해준다.

바깥에서는 그토록 정보에 목말라하며 배움과 깨달음을 찾아 헤맸던 그들이 이제 그 젖과 꿀까지는 아니더라도 쌀밥에 고깃국 정도는 항시 제공되는 그 땅에서 배움을 배척하는 이상한 광경은, 어쩌면 반복되는 좌절 속에서 그려지는 당연한 풍경화일지도 모른다. 더 슬픈 광경은, 그렇게 꿈에 닿지 못해 좌절하는 이들에게 공포라는 채찍을 사정없이 내리치는 광경이다. 명백한 퇴행이다.

--

많은 지식 노동 조직은 또한 학습을 위한 조직을 꾸린다. 일부 조직은 최고학습책임자라는 직책을 두면서까지 학습을 조직의 주요 과제로 삼는다. 그러나 이 또한 경계의 단절이 무섭다. '학'으로 얻을 수 있는 것은 심지어는 아웃소싱을 해도 된다. 그러나 조직에 있어서 '습'은 문화이며, 습관이며, 무형의 것이다. 익혀야 할 암묵지들은 말단 조직에서 태어나고, 그 안에서 자라고 , 유통되고, 그 자리에서 나이를 먹는다. 다분히 지역적이다. 파티션을 넘어, 층을 건너, UTP케이블을 타고 좀처럼 이동하지 않는다. 게다가 환경에 민감해서, 전체 조직이 '습'을 증발시키는 문화를 가지면 제아무리 '학'을 부어 넣어도 절대 결과는 나오지 않는다. 다만 예외적으로 일에 중독된 천리마 영웅이 하나나 둘 정도 탄생할 뿐이다.

'습'은 감각적 경험이 목적이다. 감각적으로 경험할 수 없다면 그 어느것도 이해할 수 없다. 클래스 덩어리의 느낌. 데이터의 흐르는 느낌. 인터랙션이 퍼지는 느낌. 언어의 명료한 울림. 이것을 비록 자신의 언어로 분명하게 표현해낼 수는 없어도, 느낌 자체가 없는 것은 아니다. 잘 짠 코드 앞에서 감탄하며 쾌감을 느끼는 한편으로 흥분하고 또 초조해 하는 것은, 지적 활동의 본질이 감각의 문제임을 너무나 동물적으로 증명해준다.

그러나 감각을 길들이는데는 시간이 필요하다. 그리고 또 섬세하게 설계된 익힘의 절차가 필요하다. 그 절차의 질에 따라 감각이 길드는데 드는 시간은 천차만별이 된다. 같은 시간을 들인다면 길들여진 감각의 급이 다를 수밖에 없다.

더 큰 비극은, 육체적 감각이 이미 스트레스로 포화 상태라면 '습'을 위한 감각 수용 기관은 모두 닫혀버린다는 것이다. 제아무리 재미있는 TV프로그램이 있어도 졸리면 자야 하는 것과 별반 다르지 않다. 통증이 생산성을 떨어뜨리는 것과도 같은 이치이다. 이런 상태를 이겨내려면 강한 정신 집중이 필요하지만, 사람의 정신력은 절대 무한정하지 않다.

--

그래서 어쩌라고? 라고 하면, 본질을 꿰뚫는 해법을 말하기에는 경험과 지식이 너무 일천하다. 다만, 배움뿐만 아니라 익힘을 위한 섬세한 장치와 문화가 필요하고, 익힘은 지역성이 강한 존재이기 때문에 익힘을 위한 장치를 매번 고심해서 디자인해야 한다는 정도는 얘기할 수 있을 듯하다.

그런 디자인이 어렵다면, 그나마 가장 좋은 해법은 '자유롭게 무언가를 하도록 내버려두는 시간을 주는 것'일지도 모른다. (물론 그런 시간은 시간이 지나면 반드시 변질되므로, 적절히 저어줄 필요가 있다.)