Everyday I have the Blues

인생 그래프

양파님 한거 보고 나도 해봤다. 괜히 해봤다. 난 안될꺼야 아마.ㅠㅠ

먼저 한국이름.

이게 뭐니 이게... 난 태어나서 죽을 때 까지 밑바닥 인생인거지...

혹시나 해서 내 영어 이름으로도 한번 해봤는데...

그래 인생의 전성기는 이미 다 지나갔어!!! 어쩌라고!

님들도 해보삼 : http://uremon.com/life_graph/

원문 : http://www.threeriversinstitute.org/blog/?p=348

Kent Beck의 글들은 언제나 저에게 새로운 느낌과 아이디어를 전달해주지만, 그중에서도 꼭 한번 번역해보고 싶었던 글을 올립니다. 문장들은 참 이해하기 쉽고 단순한데, 역시 번역이 원래 그런것인지 한국말로 옮기기가 난해한 것들이 많네요. 제가 이해한대로 임의로 의역한 부분이 상당합니다. 미흡한점이 많으니 지적 부탁드립니다(와서 읽는 사람이 있다면...).

=======================================

  나는 디버거를 설계 도구로 활용한다. 나의 프로그래밍 파트너가 이같은 사실에 가끔 놀라곤 하기에 이 기술(을 설명하는 글)을 써야겠다고 생각했다. 설계를 위해 디버거를 사용하는 것이 효과적인 이유는 애당초 내가 생각했던 것 이상이었다. 디버거는 변화의 여지가 있는 부분들에 대한 범위를 줄여줌으로서 설계를 더욱 효율적으로 만들어준다.


문제(The Problem)

  나와 내 파트너는 책임 할당(responsibility allocation)에 대한 문제로 고민하고 있었다. 객체 A는 B를 가리키고, B는 다시 C를 가리키고 있다. 우리는 B의 일부 로직과 데이터가 실상 B에 속한것이 아님을 확인하고 지난주에 그것들을 C로 옮겼다. 그런데 이는 문제를 해결하기보다 오히려 더 많은 문제를 만들어냈다. 우리는 진정으로 A의 책임(할당 - A가 무엇을 해야 하는가 -)이 필요해졌다.

우리는 수많은 테스트가 실패하는 예상치 못한 상황에서 책임을 이동시키기 시작했다. 내 파트너는 곧바로 A, B, C 세 객체의 코드를 살펴보고 에러를 찾아내기를 원했다. 그 대신 나는 코드에 중단점(breakpoint)을 걸어 예외(exception)이 발생하는 시점의 스택을 살펴볼 것을 제안했고, 그리하여 우리는 문제를 빠르게 발견, 수정할 수 있었다.


흠...(Hmmm...)

  나는 디버거에서 에러를 찾고 그것들을 살펴보는 등의 일을 과거에도 수차례 했었으나 이러한 방법이 어째서 그토록 잘 먹히는지(why it worked so well) 전혀 이해하지 못했다. 다음은 이에 대해 내가 생각한 것들이다. 디버거로부터 제공되는 기본적인 정보는 프로그램의 현재 상태와 프로그램 카운터(Program Counter)이다. 프로그램 카운터는 단지 현재 루틴에서의 위치 뿐만 아니라 호출된 모든 루틴(스택 프레임, 혹은 콜스택)의 위치를 말한다(*).
위 그림에는 그것이 내포하는 수많은 정보가 담겨있다. 각각의 프레임은 이미 실행된, 프로그램 카운터 이전의 히스토리를 보여준다.
만약 우리가 이미 실행된 문장(statement)들에 대해 완전히 추적(trace)한다면, 우리는 시스템 내의 문장들을 이미 실행된 것과 아직 실행되지 않은 것으로 분할 할 수 있을것이다.
효율(Efficiency)

  테스트가 실패할 때마다 우리는 이미 실행된 문장들중의 어딘가를 수정하려고 한다. 이러한 분할은 설계 도구로서의 디버거가 가지는 효율 첫 단계의 시작이다. 전체 시스템, 혹은 시스템의 특수한 부분집합을 보는 것 보다, 디버거는 정확히 어디를 고쳐야 하는가에 대한 중요한 단서를 제공한다. 위 그림의 빨간 영역중의 일부가 바뀌어아먄 할 것이다.

  이러한 분할은 아마도 갑작스런 예외들 속에서(with unexpected exceptions) 테스트를 수정하는 것이 어째서 실패하는 단정문(assertion) 속에서 테스트를 수정하는 것보다 쉽게 느껴지는지를 설명할 것이다. 일반적으로 단정문(assertion)이 실패 했을 때, 코드의 많은 부분이 살펴보아야 할 문제의 한 부분으로 남겨진 채로 모든 테스트가 진행될 것이다. 만약 테스트가 진행되는 중간 예외가 발생한다면 이미 실행된 문장들의 집합은 작을것이고, 때론 아주 작은 부분이 될 수도 있다.

(아마 이러한 분할은 빠른 디버깅에서의 unit test의 가치를 설명하는데 도움을 줄 것 같다. 만약 테스트가 전체 시스템의 일부분만을 실행한다면, 결함을 그 일부분으로부터 격리시키는 것이 전체 시스템으로부터 격리시키는 것보다 훨씬 쉽기 때문이다.)

  설계 도구로서 디버거를 사용하는 것이 가지는 효율의 두 번째는 대부분의 시간 소요가 변화가 필요한 스택의 어떤 루틴에서 발생한다는 관찰로부터 온 것이다. (안타깝게도) 나는 이에대한 어떤 데이타(통계자료)를 가진것이 없고, 더하여 나의 모호한 관찰("오, 또 스택에서 어떤 루틴을 수정하고 있어")로부터 온 것이다. 만약 어떤 루틴이 바뀌어아 할 가능성이 그 루틴이 스택 위에 있느냐 아니냐에 강하게 영향을 받는다면(*), 문제의 코드를 찾아내는(*) 합리적인 전략은 단지 스택따라 올라가는 것이다. 나는 일반적으로 이것을 디버깅 초반에, 일반적으로 내 파트너보다 훨씬 먼저 진행한다.

  디버거에서 나타나는 에러들에 대해 대응하는 몇가지 기교들을 알고있다면 효율을 더 증대시킬 수 있다. 대부분의 문제는 로직을 스택의 위 아래로 이동시킴으로 해결된다. 따라서 디버거 안에서 설계를 선택하는 것은 고쳐져야 하는 부분을 줄이고, 변화의 가능성, 또한 스택에서 변화가 필요한 위치와 그 변화 자체의 결합도를 줄임으로서 이득을 준다.


결론(Conclusion)

  내가 여기서 설명한 과정들은 언뜻 그저 "디버깅"으로 보일 수 있다. 그러나 위 내용들의 목표가 프로그램 내 요소들간의 관계 개선을 증진시키는데 있기 때문에 이것은 설계의 한 과정이다. 어떤 수정이 객체간의 경계를 연결시킨다면, 비록 그것들이 같은 스택 위에 존재하는 객체들이라 해도 당신은 설계에 관한 어떤 결정을 해야한다. 매우 드문 경우이지만 만약 문제가 스택 위에 있지 않다면(*) 요구되는 설계의 변화량은 상당할 것이다. 특히, 어떤 만족되지 않은 임의의 의존관계를 가지고 있다면("아, 이 코드는 이거보다 전에 호출했어야 했는데...") 당신은 호출되지 않은 객체(previously-uninvoked objects)를 포함하여 코드의 제어 흐름(flow of control)을 근본적으로 수정해야 할 것이다. 당장의 목표는 코드의 결점을 제거하는 것일 지라도, 이차적인 목표는 설계를 강화시키는 것이기 때문이다.

... ing...

* 역주: 실제 프로그램 카운터는 그저 현재 위치(정확히는 다음 실행할 instruction의 위치)만을 저장한다. Kent는 디버거가 제공하는 고수준의 정보에 대해 프로그램 카운터로 통칭한 것 같다.
* 모든 프로그램 코드는 결국 런타임에 어떤 스택 프레임 위에 존재하게 될 것이다. 이에 대한 Kent의 의도를 이해하지 못하겠다.
* 원문은 finding offending code이다. Kent도 코드에 문제가 있으면 화나고 짜증나긴 한가보다.
* 문제가 하나의 스택 프레임이 아니라 여러 스택 프레임 사이에 걸쳐있는 겅우를 말하는 것으로 보인다.

바톤 받았어요 >.< 기쁨기쁨 - 외국생활이란

  바통을 넘겨받았다. 마치 릴레이 포스팅인듯한 그런 느낌? 블로그 한지는 꽤 됐는데 이젠 이런거도 해보는구나. 여튼간에 매우 부담되는 숙제이지만 그래도 이런거 넘겨주신 양파님께 감사드리면서...

  뭐 나에 대해서 알만한 사람들은 다 알겠지만 나는 IT업계에 종사한다. 그리고 그중에서도 흔히 '개발자'라고 불리는 소프트웨어 엔지니어다. 바통을 넘겨받을 때에는 '직장업무'라는 타이틀로 넘겨받았는데, 그게 '어떤 일을 하는가'에 대한건지 '직장생활이 어떠한가'에 대한것인지 애매모호 한 느낌이어서 두가지로 나눠서 다 써보련다.

  첫째로, 나는 어떤일을 하는가.

  뭐 쉽게말하면 소프트웨어 개발을 한다. 그중에서도 리눅스 소프트웨어 개발을 하고, 또 다시 축소시키면 임베디드 리눅스 시스템에서의 미들웨어 개발이 주 업무다. 하는 일은 이정도로 잡으면 크게 벗어나지 않고, 그중에서도 가장 주력으로 하는일이 무엇이냐... 를 묻는다면 멀티미디어 프레임워크와 사운드서버 개발이다. 팀 내에서는 그냥 쉽게 멀티미디어 3종세트(인코더, 플레이어 프레임워크, 사운드서버)라고 한다.

  모든 분야가 각각 나름의 어려움을 가지고 있겠지만, 멀티미디어를 하면서 유독 느끼는 어려움이 있다. 그것은 바로 unittest가 어렵다는 것. 일반적으로 내가 좋아하는 소프트웨어 개발의 흐름은 TDD를 따른다. 테스트 작성 - 테스트 통과 - 리팩토링. 물론 부분부분에 대해 어느정도의 테스트를 병행하고는 있지만, 다루는 데이터의 특성상 기대값을 설정하기가 매우 힘들다. 테스트를 하려면 일단 기본적으로, input과 기대되는 output이 결정이 되어야 하는데 이것이 힘든게 멀티미디어가 아닌가 싶다.

  또한 멀티미디어 프레임워크의 특성상 하드웨어와 직접 통신해야 하는 경우가 종종 있다. 하드웨어 코덱을 사용한다던가, 프레임버퍼를 컨트롤 한다던가 하는 문제다. 사실 이런 하드웨어와의 통신은 매우 간단하다. 리눅스의 디바이스 관리 구조가 매우 훌륭하기 때문이다. 그러나 문제는 역시나 테스트. 하드웨어가 주는 값을 믿을 수 밖에 없고, 또한 내가 하드웨어에 넘겨주는 값을 정상적으로 처리하리라고 믿어야 한다.

  이런 테스트가 힘든 부분에서 문제가 생길 때, 정말 골치가 아프다. 막말로 화면에 영상을 뿌려주는데 화질에 문제가 있다면, 내가 잘 넘겨줬는데 디바이스 드라이버가 처리를 잘 못하는 것인지, 아니면 내가 하드웨어에 전달하는 데이터가 잘못되어 그런것인지 알 도리가 없다. 하드웨어로부터 전달받는 데이타, 또는 하드웨어로 전달하는 데이타 모두 사람이 읽어낼 수 없는 raw 데이타들이기 때문이다.

  실례로 가장 골때렸던 문제를 생각해보면 이렇다. 어떤 mp3음원이 내게 전달되고 이슈 리포트로 "중간에 치익~ 하는 잡음이 약하게 들립니다" 라는게 올라온다. 이제부터 디버깅의 삽을 들고서 삽질에 삽질을 거듭해 지구 반대편으로 뚫고 나오는 일만 남은거다. 

  두번째로 직장 생활에 대해서 간단하게 이야기를 하련다. 솔직히 우리회사는 그냥저냥 무난한 편이다. 악의근원 T사 처럼 엔지니어들의 골수를 뽑아먹는 악덕기업도 아니고, 그렇다고 정시 출퇴근이 보장되는 훌륭한 업무환경도 아니다. 사실 직장생활에 있어서 가장 싫어하는 것중에 하나가, 할 일이 없는데 눈치상 하게되는 야근이다. 이 부분은 회사 내에서도 팀별로 차이가 좀 있는거 같은데, 우리팀은 이런게 약간 없지않다.

  그저 일반적으로 말하면 이렇다. 물론 어떤 프로젝트를 하고있느냐에 따라, 같은 프로젝트에서도 상황에 따라 생활이 많이 달라진다. 지금의 생활을 말하자면... 좀... 그렇다. 어찌보면 메니지먼트가 잘못된 프로젝트의 전형을 보여주고 있기에 더욱 그런거같다. 억분에 요새는 하루하루 12시전에 퇴근하는 날이 별로 없는거같고, 당연하다시피 주말 출근을 한다. 뭐 늘상 이랬던게 아니기에(사실 나는 이 프로젝트에 긴급 투입된거라 이 생활 시작한지 얼마 안됐다), 이번일만 지나가면 나아지겠지 하면서 버티고 있다.

  사실 직장생활에 대해서 언급할 때는 조심해야 할 사항들이 많아서, 좀 고민해가면서 썼다. 여튼간에 이런 어려운 숙제를 내주신 양파님께 감사를...

  제 블로그는 마땅한 고정 방문자가 없다보니 바통을 넘길 사람이 없군요...