얼마전에 타 벤더에서 제공받은 모듈을 우리쪽 프레임워크에 래핑작업을 했었다.. 아니 아직도 하는 중이다.
보통 라이브러리를 제공하면 archive(*.a)나 shared object(*.so)로 제공하는게 보통인데 오브젝트파일하나 덜렁 준다.
전화해서 archive나 so 제공안해주냐고 물어보니.. 자기네는 그거만 제공하고 그 라이브러리 쓰는 사이트 모두 같은걸 쓰니까 그냥 쓰랜다. 뭐 귀찮아도 빌드할때 한번 더 묶어주면 되니까 상관없는데 문제는 그 다음에 생겼다.

저쪽에서 제공받은 샘플은 잘 돌아가는데 내가 래핑한 api는 동작을 안한다. 내부적으로는 소켓 연결해서 통신하는 방식인데 fd를 아예 못받아 온다

return value = -111

찾아보니 connect refused
도대체 왜 그런지 알 수 없어 한참을 고민하다. 프레임워크 담당 하는 분께 물어보고 같이 원인을 찾아봤다.

새로배운 명령어 ...
truss
이걸로 실행파일을 실행시키면 실행시 커널레벨의 함수들이 콜되는 걸 볼 수 있다. 신기하다.....
truss는 aix에서 strace는 linux, hp는 tuse.. 나머지는 모르겠다.

암튼 저걸로 원인을 찾아보니 소켓에서 fd까지는 잘 받아왔는데 그 다음이 문제였다.
이것도 새로 안건데 우리쪽 미들웨어를 쓸때 다른 라이브러리와 묶을 때 .. 그러니까 벤더쪽에서 제공하는 라이브러리에서 안되는게 있었다. 몇몇개의 시그널들을 캐치하면 이쪽 미들웨어와 충돌이 발생한댄다.
어쨌건 확인해 보니 소켓으로 fd를 받아온 다음에 _sigaction로 14번 시그널(SIGALRM)을 캐치하고 있었다. 미들웨어가 쓰고 있어서 쓰면 안되는 놈중에 하나다.
그런데 fd를 잘 리턴받고(커널단에서) 시그널을 캐치했다고 fail이 나는건 왜인지 모르겠다.(공부 좀 해야것다.)

이걸 피하려면..
1. 저쪽에 우리 미들웨어하고 충돌안나는 라이브러리를 다시 달라고 하던가.
2. 우리쪽에서 데몬으로 짜던가..
3. 다른동네는 대부분 자바로 한대는데 자바로 하던가..

내 입장에서는 1번이 베스트인데.. 되려나 모르겠다
2번은 나중에 문제가 생길 소지가 많다.. 미들웨어에서 제공하는 데몬이면 모를까 생짜로 도는 데몬은 관리도 힘들다. 더구나 제공받은 라이브러리 자체가 그쪽 데몬에 접속하는 클라이언트 라이브러리인데.. 데몬에 접속하는 데몬을 짠다????
3. 우리쪽 업무프로세스를 이렇게 잡은 이상 저걸 바꾸면 그것도 머리아프다.

짬이 안되다 보면 어떤 의사결정을 내릴때 힘을 내지 못하는 경우가 생긴다.
뭐 결국은 능력의 부족인데 저건 아닌데 하면서 결국엔 그 결정을 따르는 일이 있다.
그러다보면 나중에 문제가 생기는 경우가 있는데
이런 원인은 그 문제에 대한 시선의 차이로부터 시작된다.
그럼 무엇이 그런 시선의 차이를 만들까?

개인의 경험?
맡은 업무의 needs?
자신에게 떨어질 일의 양?
전문가적인 직관?
만인이 공감할 상식?
기존의 틀을 깨는 획기적인 해결법?
기타 등등..

이중에 항상 어떤 것이 정답일 수는 없다. 그 상황에 맞는 케이스가 존재할 뿐이다.
그럼 사람들이 항상 상황에 맞는 케이스를 찾는가? 라는 질문에는 누구도 그렇다 라고 대답하지 못할 것이다.

가장 비관적으로 봤을때 자신에게 할당될 일의 양을 고려한 시선으로 문제를 바라본다 하더라도 그게 꼭 오답이 아닐 수도 있다.

또 상식적인 수준에서의 문제 해결방법이 오히려 독이 될 수도 있다.

좀 극단적인 케이스이기는 하지만 그것들이 항상 100%정답이 아닐 수 있다라는 것이다.

이 동네에 있다보니 별별일을 다 겪게 되는데 시간이 지나보니 그때 한사람이 주장하던 의견이 결국엔 맞는 경우가 있었다. 그 사람 이외 관련자 전부가 반대했었고 결국 그 의견은 당시에 받아드려지지 않고 다른 방향으로 처리되었다. 결국엔 그 방식이 문제가 생겨서 그 사람의 의견대로 다 뜯어 고치는 웃지못할 사태가 벌어졌다.

그 사람은 어떻게 되었을까? 그 건 때문은 아니지만 상황이 좋지 않아 사태가 벌어지기전에 다른 직장으로 이직해버려 그 뒤 사정을 모른다.

그럼 그때 그 의견에 반대했던 사람들은 바보였던건가? 나름 IT 짬밥 10여년 이상 경력자들이고 프로젝트도 수십번 이상 했던 양반들과 고객사 직원도 업무경력 20년이 다되가는 고참들이었다.

소프트웨어 공학에서 말하는 리스크라고 하는건 아마도 이런 것들을 리스크라고 하는 듯 하다. (물론 일정 및 범위, 기간, 공수 산정의 리스크도 있지만..)

그럼 원점으로 돌아가서 처음에 의견을 제시한 그 사람이 이런 사태가 벌어지지 않게 하려면 어떻게 해야하나?
자신의 의견이 맞다고 증명을 해야 하는데 그 의견이라는 것 자체가 위에서 언급한 문제에 대한 시선의 원인(?) 중 하나라는 것이다. 이런식으로 간다면 결국엔 그 의견도 정답인지 아닌지는 모른다는 것이다.

좀 괘변이긴 하지만 결국 닭이 먼저냐 달걀이 먼저냐 같은 문제이기도 하다.

가장 중요한 것은 이런 물고 물리는 악순환의 고리를 끊어내야만 한다. 결국은 뻔한 이야기다..

결론은.. 지지말자. 지지 않도록 무장(?)하자. 자신의 의견을 철저하게 객관적으로 검증부터 하자. 그리고 나서 우겨라...(ㅋㅋㅋ) 그럼 니가 생각하는게 맞다.

ps. 혹시나 이거 보고..(볼 사람도 없지만) 그러는 당신은 얼마나 잘났소? 라고 물어보시면 전 할말 없습니다..... 아직 하산하려면 멀었습니다.

Pragmatic Thinking & Learning - Refactor Your Wetware / 앤디 헌트 / 위키북스

출퇴근시간에 지하철에서 볼만한 책을 고르러 갔다가 앤디 헌트와 김창준씨 이름만 보고 앞에 두어 페이지만 보고 덜컥 사버린 책..

실용주의 프로그래머를 다시한번 본지 얼마 안되었는데 이번 책은 개발에 대한 테크니컬한 조언보다는 어떻게 하면 잠자고 있는 뇌를 활성화 하는가가 더 초점에 맞추어져 있다.

비단 개발자 뿐만 아니라 일반인들이 봐도 크게 무리 없는 내용으로 구성되어 있다.

읽어본 결론은...
한 두어번 더 읽어봐야 한다. + 이건 읽는걸로 끝나는 책이 아니다.(물론 모든 책들이 다 그렇지만)

책에서 인상 깊은 내용들

- 항상 문맥(context)을 고려하라. 어떤 문제에 당면했을때 그 문제뿐만 아니라 그 주위의 상황, 상태, 연관 된 것들도 같이 고려해야 한다.

- 인간의 뇌는 좌뇌, 우뇌 여기서는 L모드 R모드로 동작하는데 대다수의 사람들이 R모드를 제대로 활용하지 못한다. R모드는 비선형, 직관과 관련된 영역.. 아 몇마디로 설명하기 힘들다. L모드는 선형적이고 계산적이다.

- R모드를 활성화 하기 위해서는 자기 자신의 내면을 관찰하는 습관을 길러야 한다.. 명상이 그런 방법 중 하나다.

- 띄엄띄엄 봐서 앞의 내용은 좀 가물가물하지만 드라이퍼스 모델이나 모델에서 제시하는 전문가의 정의 등도 꼭 기억할만한 내용이다.

- R모드의 뇌는 인간이 자각하기전(L모드로)에 인지한다. 그리고 R모드가 비선형적으로 이를 처리한다.
이런 것들을 R모드에서 L모드로 이끌어내는 것이 중요하다.

- R모드로 인지된 정보들은 어느정도의 숙성이 필요하다.(??) 책에서는 이대로 이야기한 것 같진 않은거 같은데 어느정도 시간이 지나고 생각해보니 인지된 정보의 숙성이 필요한듯 하다. 그리고 그런 숙성을 진행시키는게 명상과 같은 일이다. 명상 어려운게 아니다. 의식적으로 숨쉬고 자신의 몸을 의식적으로 인지하면 그게 명상이다.

- L모드의 유휴수다루프를 줄여라. 오늘 점심 뭐 먹을까. 이런 생각들을 줄여야 된다.

- 뭔가 작업할 때는 먼저 손으로 그려라. 키보드로 글을 두드리는 것과 손으로 글을 쓰는 것과는 차이가 크다. 손으로 글만 쓰지말고 그림을 그려라. 마인드맵같은..

- 쓰는거보다 좋은게 소리내어서 읽어봐라.

- 아침에 한가한 시간에 아무생각없이 뭔가를 적어봐라. R모드에 잠재되어 있는 정보들을 끄집어내는 훈련이다.

- 이런 것들을 습관화 하라. 책에서는 3주만 꾸준히 하면 적응된다고 한다.(물론 계속 하겠다는 의지도 필요)

결론은..
실천해라!!