|
|
구리구리쑝쑝 2008/03/29 02:18
오랫만에 잡담 포스팅.
어딘가 웹을 허부작대다가
"자기 일 다 끝났다고 분위기 파악 못하고 노는 개발자넘은 재섭다" 라는 내용의 글을 봤다.
뭐 그 사람의 의도는 그게 아니었다고 생각되나. 확실히 작년 1년동안 나의 특성이 변질된건지. 머리 속에서 버럭! *$#^*#(!!!! 하고 폭발이 있었다.
대충 이런 내용의 생각들. "내 일 끝났어도 다른 사람이 일 못끝냈다고 일요일->월요일로 넘어가는 새벽 네시반까지 일해야 되는거냐!" 라든지. "애당초 못끝낼 일을 오케이하라고 시킨/오케이 한 누군가가 잘못이지!" 라든지. 그 밖에 꿀렁꿀렁.
뭐 저런 건 지극히 극단적인 경우일지도 모르지만.
지금도 약간은 적용되는 논리.
아는 사람은 알다시피 쉉은 현재 서비스 개발(이라고 쓰고 개발겸 영자라고 읽는다) 노릇을 하고 있는데. 요새의 고민거리(?)라고 한다면. "어떻게 하면 AS를 줄이고 탱자탱자 놀 것인가?" 이다.
짧은 시간이지만 영자를 하면서, "이건 이렇게 하면 내가 더 놀 수 있겠구나." "이런 툴을 만들면 난 더 땡땡이 칠 수 있겠구나." 이런 생각 하면서 영자 한 두달 정도 공부도 하고, 툴도 만들고, 코드도 다듬고 해서. 실제로 처음에 수동작업으로 처리했을 때보다 AS처리가 적어도 30%는 감소한 것 같다. 뭐 별로 대단하고 어려운 일을 한 건 아니다만(나를 아는 사람은 내가 어렵고 아름다운 일을 하기엔 한없이 허당이란 걸 잘 안다ㅠㅠ), 아주 간단한 일들만 해도 이렇게까진 할 수 있더라..
30% 감소한 시간동안 놀기도 하고, 다른 공부들도 했지만 별 죄책감은 없다.
만약 내가. "우주 성실맨이 되어야지. 남이 귀차나 하는 일도 내가 다 해야지!!" 라든지 "야근따위 백만번 해도 상관업써 무조건 열씨미!" 라는 생각을 품었다면. 저렇게 잔머리 굴리고 더 관리하기 편한 방법을 모색하고 그랬을까나. 완전 무식쟁이처럼 영자노릇을 하면서 나는 성장하고 있구나 하는 말도 안되는 망상으로 므흣해했겠지.
고로 지금은. "개발(과운영) 역량의 발전은 61%의 귀찮음과 29%의 책임감, 9.5%의 외계통신, 42%의 지겨운 일을 재밌는 일로 만들기, 34%의 전력토끼로 이루어진다" 주의인지라.
코웍이 정말 중요하긴 중요하지만. 그게 "니가 좀 느리면 내가 니꺼까지 다 떠맡아서 몇날 며칠 밤새서라도 해줄께"의 의미는 아닌데... 싶다.
서로가 서로의 줄주리타가 되어서 도와주고. 그 결과 달 한명은 주룩주룩 야근할 일을 한달 모두모두 칼퇴근으로 해낼 수 있으면, 거기까지가 아니어도 그 한명이 일주일 정도만 야근할 수 있도록 도와주면. 그게 킹왕짱이 아닌가나. 이렇게 만들기도 무지무지 어려운데!. 놀지도 말라는거냐!.
그렇다고 성실함은 아무 쓸모도 없다는 얘기는 아니고. 다른 도메인의 성실함이 필요한듯.
눈치 보느라 못놀고. 눈치 보느라 말도 안되는 얘기에 반박도 몬하고. 눈치 보느라 없는 야근 지어내서 잠못자고. 아무리 재밌는 일이라도 생존권을 침해하면 재미있을 리가 없다. 전력으로 시러한다 ㅡㅡ.
ps: 머 내가 10년 넘게 이 업계에서 일하면 가치관이 바뀔지도 모르겠지만. 허당 초보일 때 쉉은 이렇게 생각했습니다 하고 남겨놔야지.
Trackback 0
:
Trackback Address :: http://lunetica.net/trackback/5
하얀건종이꺼먼건글씨 2008/03/04 00:22
Ship it! 은 개발 프로젝트 수행 단계, Release it은 개발이 끝나고 라이브가 진행중인 단계에 도움이 될만한 책이라고 널리(?) 알려져 있다. 근데 난 어찌 순서가 좀 거꾸로 된듯 싶은게, Release it을 먼저 (빌려)읽은 후 이 책을 봤다(...).
Release it 같은경우 번역 문제도 그랬지만(참고로, r모님 말씀대로 Release it 같이 좋지 않은 번역서는 정말 번역서 질의 향상을 위해서라도 사서 보아선 안된다고 생각한다.), 특정 분야를 어느 정도 잘 알고 있지 않으면 원서로 보아도 많이 힘들 것으로 생각된다.
반면!. ship it은 개발자에게도 좋은 참고/재밌는 이야깃거리가 될 뿐더러(개발자는 한번 두번 세번, 사과를 그려가며 읽어도 재밌다), 개발자와 같이 일해야 하는 비개발자들도 한번 거들떠 보면 더불어 살아가는 데 좋을 듯한 책이다. 다른 실용주의 개발 책들과 달리, 실험해 볼 수 있는 실제적인 방법들을 비교적 소상히(?) 소개하고 있다. 난 특히 다음과 같은 소재들이 마음에 들었다(스포일러이므로 볼 사람만 보시오).
===몇가지 소재들===
- 코드 리뷰
정말정말정말정말 필요하다고 생각. 개슈든 버리버리 개발자든 옆에 줄주리타가 있으면 큰 힘이 되는 것이 자명하다.
"페어프로그래밍"도 "눈이 네 개일 때 더 버그도 잘 잡고 일도 빨라지고 둘의 이해도도 완벽해진다"라는 배경에서 출발했지만, 나의 경우 사람에 따라 지나치게 긴장해서 체력이 급강하 되고 머리가 잘 안풀리는 문제 또한 있었다. 특히 상사의 경우, 시험감독이 뻔히 보고 있는 앞에서 덜덜덜 거리며 문제를 푸는 느낌이랄까;-;;..
반면 현실적으로 부딪히는 문제는, 많은 회사의 개발자가 자기 일만으로 헐떡헐떡 거려 남의 코드를 볼 마음과 시간의 여유가 없을 때가 많다는 것. 이 여유를 만들어주고 리뷰를 귀찮다고 생각하지 않게 만드는 게 제일 허들.
- 일일 회의
매일매일 한다는 사실보다는, "모든 구성원이 말을 하게 만들어야 한다" 라는 점이 특히 공감이 간다. 한국 사회의 특성인지, 연구실이고 회사고 모임의 장으로부터 조금씩은 수직적으로 일을 하는 성향이 다들 배여 있고, 회의도 위에서부터 잔소리 듣는 시간이 되기 쉽다. 모두가 자신의 일에 대해 꿍얼꿍얼 말을 열기 시작하면, 자연스레 위아래/수평적으로 의사소통이 될 여지가 많다. "적당한 폴링"을 자연스럽게 하는 효과도 있을 듯.
그나마 제시한 회의 형태와 가장 유사했던 게 대학원 때 일주일에 한번 진행했던 "팀미팅"이다. 물론 "교수님과 나 사이의 일방적인 보고 활동"에 가까웠다는 건 좀 아쉬웠어도, 내가 뭘 하고 있는지 내가 설명하면서 스스로가 정리되고, 남이 대충 뭘 하는지도 꿍쳐 들을 수 있는 게 좋았다. 개슈 선배들에게 조언도 많이 들을 수 있었고..
일일 회의가 문제가 될 만한 게 있다면, "쓸데없는 회의는 하지 않는다"를 주장하는 개발자들도 많다는 것. 사실 그것도 그들 입장에선 맞는 말이긴 하다. "쓸데 있는 회의"를 만들어 시간낭비라고 생각하지 않게 하는 게 중요하겠지. 뭐 "매일매일"이라는 건 실제 도입했을 때 얼마나 효과가 있을지 궁금하다 정도?
- 테스트 주도 개발
말할 필요도 없이 멋지구리!!.
업종 전환 전 '임베디드 스러운' 일들을 잠시 할 때는 테스트 시나리오는 끝도 한도 없이 있고, 손으로 하지 않으면 테스트할 수 없는 기능들이 많아 머리가 아팠다("핸드폰을 켜고 새 동영상 업로드를 3건 시도하고, 3건 째가 올라가는 중에 갑자기 배터리를 손으로 뺀뒤, 다시 핸드폰을 켜본다"라는 시나리오는 로봇을 만들지 않는 이상 사람이 할 수밖에 없다. "전원을 끈다"와 "배터리를 뺀다"는 저언혀 이 세계에서 다른 개념이므로 ㅠㅠ). 이렇게 고생스러운 분야이기에 오히려 "테스트 할 수 있는" 시나리오는 모두 빡세게 테스트 하는 습관들이 좀 된다 싶은 기업들이라면 박혀있는 듯. 테스트 가능한 아이들을 완벽히 통과시키면 그만큼 "고생스러운 테스트"에서 "괴로운 디버깅"을 할 가능성도 줄어든다는 것을 몸으로 알고 있기 때문이다(뭐 물론 무식한 회사들이 없는 건 아니다==.). 각종 시뮬레이터와 에뮬레이터, CAD 툴들에 대해서도 수없이 많은 논문과 방법론들(반 이상은 다시는 안쓰일지도 모를)이 나오는 이유도 이것 때문이겠지.
요새는 또 다른 이유로 여러 가지 머리가 지끈지끈 아픈데, 업종전환(?)을 한 분야의 테스트가 참말로 "광활하기" 때문이다. 그러나 이쪽은 머리를 잘 쓰면 훨씬 편하게 살 수 있을 여지가 있어보여 끙차끙차 중. 임베디드 쪽이 나무 구멍에다 작대기를 사흘 밤낮으로 비벼대며 불을 피울 수밖에 없는 쪽이라면 이 곳은 무려 부싯돌이 있는 느낌이랄까!!!. 가짜 객체라든지도 얼마든지 적용이 가능한 분야라니!! 이쪽에 관련한 끙차끙차 고민거리들은 추후 가끔 포스팅에 보일지도 모르겠다.
이 책의 "Test Driven"은 다른 실용주의 책과는 좀 달리 "손에서 상상할 수 있는 레벨"이라는 게 재미있다.
위의 스포일러도 호기심이 가지만, 정말 공감했던 부분은 Co-work의 중요성이다. 개발자 동료가 또라이라도, 덕후라도, 히스테리 노처녀라도, 혹은 히키코모리라도 이에 굴하지 않고 팀웍을 다지고 모두들 똑똑해지는 게 얼마나 중요한 일인지 강조하는 게 참 맘에 들었다. 아쉽게도 그건 현실에서 백만톤 정도 힘든 일이긴 하지만. 처음부터 어긋난 만남이라는 게 얼마나 무서운지. 일터가 평화로울지 전쟁터가 될지는 이미 구성원에서 XX% 정해진다고 난 믿는다. 아무리 좋은 프로세스/도구가 있어도 사람들이 고집스럽게 이를 무시하고 막나가거나 배째는 경우 결말은 "nice boat"임이 뻔히 보이는 것을(머엉).
대부분의 한국 회사(뿐만 아니라 외국에 있는 회사들도 어느 정도 그렇다고 들었지만,)는 수직적인 성향이 강하여 아래로부터 멋지구리하다고 생각하는 팀웍들을 실험해 볼 여지가 그닥 많지는 않다고 본다. 그래도 지금 버리버리 개발자 레벨일 때 이리저리 "어떻게 하면 정신줄 놓는 일을 덜 만들 수 있을까", "어떻게 하면 일을 확 줄여서 빈둥빈둥 일해도 월급 잘 받아 먹으며 살 수 있나" 잔머리 굴려보고 뚝딱뚝딱 해보는 건 정신/육체 건강에 꽤 도움이 될 듯.
Trackback 0
:
Trackback Address :: http://lunetica.net/trackback/4
하얀건종이꺼먼건글씨 2008/03/02 02:06
나의 이 책에 대한 전반적 느낌은. "노인과 바다" 틱하며 그것보다 난해하다는 것.
그것도 내가 너무나 힘들어하는 영어책으로 읽었기에 죽는 줄 알았으나 ㅡㅡ, 반 강제력을 이용해 겨우겨우 끝냈다(...). 아마 서점에서 내가 좋아서 이 책을 집어들진 않았을 거다. 절대로 ==. 영어책을 읽다가 무슨 얘긴지 당최 모르겠어서 서점에 가 번역서를 집어들었는데, 번역이 오역인건지 원래 어려운 말이 맞는 건지 더 헷갈리고 말아서 결국 오티엘 선언. 모종의 모임에서 꾸역꾸역 자세히 설명을 들어 먹어야 겨우 "아~~"할 수 있었다 ==.
여튼 뭐 쉽게 말하자면. "한 인도 소년의 태평양 표류, 자아찾기 대모험 + 호랑이와 인간의 합체놀이 분신술 쑈쑈쑈" 라고 할 수 있겠다.
원래 난 이런 류의 안드로메다행 책을 싫어하지는 않는 편인데, 이번엔 영어책이라 알레르기가 난 건지, 힌두교/이슬람교 및 종교에 대한 전반적인 견해가 전혀 안맞아서 그런건지, 배경이 판타지도 아닌 것이 현실 세계도 아닌것이 두리뭉실해서 그런지. 그닥 많이 맘에 들진 않았다 ㅡㅡ;;.
지금부터는 앞서 언급한 모종의 모임에서 나왔던 이야기들과 나름 들었던 생각들에 대해 이야기를 할텐데, 이건 100% 스포일러 무차별 폭격이므로 책을 앞으로 볼 계획인데 김새기 싫다면 보지 마셈.
===실컷스포일러당하기=== 1. 책의 첫인상 표지가 반질반질하고 새파란 색이 시원해서 좋았다. 표지의 느낌이 맘에 들었기에 배 위에 어떤 소말리아 애같이 생긴 남자애와 호랑이가 둥둥 떠있는 건 미처 발견하지 못한듯. 표지 뒤를 관찰하니, "어떤 애가 450파운드짜리 벵골 호랭이, 상어랑 태평양을 여행하는 얘기야. 열라 많이 팔렸어!!" 이런 얘기가 주절주절 쓰여 있다. 이 문구가 이 책 속에서 그렇게 "리얼한" 의미를 가진 건지 전혀 몰랐다. 그냥 뭐 호랑이랑 오랑우탄이랑 뭐시기랑 자아찾기 바다여행같은 걸 하나보다 라고 생각했지. 인도 사람은 원래 그런 거 좋아할 거 같잖아. 그러니까, 이상한 나라의 앨리스처럼? 동화느낌이랄까. 나름 어려운 책이라니까 소피의 세계처럼 짐승들이랑 이상한 얘기를 주절거리려나 하는 생각도 들고. 이런 인상이었기에 책의 내용은 충격 대반전이었다. 2. 책 속의 현실 간단히 말하면, 이건 동화가 아니라 "현실에 기반한" 뻥이었다(원래 소설은 다 뻥이니까). 같이 표류한 호랑이는 정말 말도 안통하고 사람잡아먹는 호랑이였고, 상어도 정말 영화 "죠스"에 나오는 그런 상어였다. 파이 어린이는 책이 끝날 때까지 계속 "무서워 덜덜덜"을 하고 있어야 했다. 물론 중간에 어려운 책답게 파이 어린이 정신이 세 개로 분열했음을 암시하는 대목들도 있고, 끝부분에 "너는 뭐냐 진실은 뭐냐" 이런 현학적이고 난해한 대화들도 나온다. 뭐 이런 건 좀 심각하다 싶은 책이나 영화에선 흔히 갖다 쓰는 컨셉이잖아. 그러나 다른 어려운 철학책들과 다른 점이 있다면, "충분히 상상할 수 있는, 있음직한 상황과 공포"라는 거랄까. 판타지틱한 세계가 배경이 아니라는 것. 성실함이 있다면 이 책 속의 상황을 좀더 자세히 정리하겠지만, 귀찮으므로 패스 ㅡㅡ. 3. plot 이 책의 plot 은 크게 세 부분이라고 한다. Part 1, 2, 3으로 나뉘어져 있는데. 그 각각이 하나의 plot이라고 보면 된다.
- Part 1 : 캐릭터, 종교 관념, 짐승들 등 이 책의 배경에 대한 사전 답사
- Part 2 : Castaway life (A)
- human --> animal 로 변질(?)해 가는 Pi의 변천사(한마디로 야생라이프).
- 다른 생물들과 어떤 관계를 맺으며 살아가는지.
- Part 3 : Castaway life (B)
- animal --> human으로의 복귀(?)
- "혼자됨"
여기에 16살 짜리 소년이 어떻게 부모님 없이 홀로서기 하는지 성장드라마 컨셉 추가. 4. 흥미로운 개념들
- "alpha male" vs "omega male"
보통 우리는 "alpha"는 시작, "omega"는 끝을 의미한다고 많이 알고 있다. 이와 유사하게, alpha male과 omega male은 서로 반대의 의미이다. 간단히 말하면 alpha male은 "leader", omega male은 "follower"이라고 할 수 있겠다.
이 이야기에서 파이와 호랑이 리차드 파커는, 타고 있던 배가 침몰하고 이러저러하다 달랑 둘만 남아 오랜 시간을 표류한다. 이 시간 속에 파이와 리차드 파커의 관계는 다음과 같이 변한다.
- 초기 : 파이는 리차드파커가 무서워요. 여차하면 도망갈래!! 하고 피난처(?)를 만든다
- 중반 : 동물원 가정(?)에서 자란 파이는 "내가 살려면 별수 없이 호랑이를 길들여야돼"라고 생각하기 시작하고, 살기 위해 별수 없이 길들이기를 시작한다.
- 말기(?) : 파이는 능히 호랑이를 컨트롤 할 수 있게 된다. 무려 나중엔 서커스 재주넘기도 시킨다(머엉).
보통 사람 보통 정신이면 당최 애시당초 잡아먹혔을 텐데 갱장한데~!! 라는 소감은 일단 제껴두고(...).
즉 파이는 이런 과정들을 통해 점점 리차드 파커 호랭이를 "omega male", 자신을 "alpha male"로 각인시켜간다. 물론 나중에 헷갈리는 대화들을 보면 파이는 리차드 파커를 자기 자신이라고도 생각한 것 같고, 인생의 위기를 같이 헤쳐나간 친구라고도 생각한 듯 싶다. 단순히 주종관계는 아닌거지. 내가 파이를 "alpha male"이라고 생각하지 않은 이유도 그거다. 그 또한 결국 외로움 때문에 호랑이를 떨궈내지 못한 거잖아? 게다가 호랑이는 그를 alpha male이라고 전혀 인식하지 않고 있다. 그가 진정한 alpha male이었다면, 호랑이의 영역을 마구 들어가도 호랑이는 깨갱 날 잡아잡수 했을텐데, 파이는 소심하게 경계선에서 어물쩍어물쩍하고 있었을 뿐.
- And so goes it with God.
기적적으로 살아남은 파이가 일본에서 조사나온 양반들에게 어떻게 살아남았는지를 들려준다. 처음에 얼룩말, 하이에나, 오랑우탄, 호랑이가 있었고, 얼룩말, 하이에나, 오랑우탄은 죽어버려(긴 이야기라 설명 생략;) 호랑이랑 자신이 남았고, 어떤 일들이 있었고.. 이런 이야기들.
그러나 당연하겠지만 그 양반들은 이야기를 믿지 못하고, 그런 짐승 나오는 얘기 말고 배가 왜 침몰했지 그런 얘기를 해주세요 하고 조른다. 파이는 "아 짐승 없는 얘기요?" 하면서 하이에나를 요리사로, 얼룩말을 항해사로, 오랑우탄을 엄마로, 호랑이를 자기 자신으로 transformation 해버린 버전을 들려준다ㅡㅡ;.
짐승 버전과 사람 버전중에 어느 버전이 진짜같냐고 물으니, 일본 양반들이 "짐승 버전이 그럴 듯 하구나" 라고 답한다(솔직히 나는 사람 버전도 너무 리얼해서 이넘 정말 미친 게 맞구나라고 생각했다. 항해사의 다리를 요리사가 찢어버리고 요리사가 엄마를 죽여버리고 ㅡㅡ;;).
아마 일본인 양반들은 둘다 말도 안된다고 생각하지만 어쩔수 없이 비위를 맞춰 줘야 하니 그런 말을 했을 게야. 여튼 그 답에 이어서 파이는 이 말을 꺼낸다.
"And so goes it with God."
이게 당최 무슨 뜻인지 몰라서 "God knows it"과 비슷한 뜻일 거라 추측하고, "이게 진짜랍시고 파이가 말하는거냐, 아니면 표류생활동안 정신이 헷가닥해서 얘기를 몇백 페이지동안 마구 지어낸 거냐?"하고 헷갈려 했는데,
원래 뜻은 인도에서 하는 인사인 "인샬라"라고. "If God is with me..." or "If God is willing..."이랑 비슷한 뜻이라 한다. 즉, 파이 자신은 표류 동안 벌어진 모든 이야기가 진실이라는 걸 확신하고 있었다는 것. "신이 날 보고 있었다면, 내 말이 진실이라는 걸 다 알고 있었을 게야." 이 정도라고 하겠다.
(흠.. 근데 일본인들이 보고서에 "그는 정말 호랑이를 조련했어!!"라고 쓴건 뭐였을까. 결국 믿게 된거였을까나.)
- delusional
"망상의"라는 뜻이다. "delirium"은 "delusion"의 동의어(그런데 스티브샘은 이걸 "미친 imagination"이라고 설명하더라 푸핫 ;-;ㅋ).
5. 대반전. 이 이야기는 다 쌩뻥이라고 한다(작가가 지어낸). 작가가 파이 파텔을 인터뷰하는 식의 장면이 있었기에 혹시나 했으나 ㅡㅡ;;. "작가는 인도 여행을 다녀왔다" 만 유일하게 진실인 부분이란다. 소설은 소설이지 뭐. 여튼 작가들은 갱장하다. 이렇게 말도 안되는 이야기를 이렇게나 자세하고 있어보이는 설정으로 지어내다니. 특히 표류중에 들어갔던 사람 잡아먹는 섬은 흠좀무 ;-;. 무슨 천공의섬 에스카플로네 이런것도 아니고.
끝으로 잡설.
알라딘을 뒤지다 보니 일러스트 판이 있다는 걸 발견했다. 한국어판도 있는듯.
흠.. 이 책 구명보트의 구조, 섬의 구조.. 이런 게 이해되지 않으면 책 절반 이상을 날리게 된다(한국말로 봐도 어렵다. tarpaulin이었던가? 번역본 들춰 봤을 때 "방수포"라고 하던데. 뱃사람도 아닌데 그게 뭔지 어케 아라 ㅡㅡ;;). 일러스트판에는 그런 배 구조나 상황같은게 좀 자세히 들어있을까? 뭐 사진 않겠지만.
Trackback 0
:
Trackback Address :: http://lunetica.net/trackback/3
안드로메다마을 2008/03/01 00:40
이 글의 주제는 참으로 기본적이고도 중요하고 어려운, 내 8년 코딩 인생 "디버깅 쌈질 로그"의 78.675%를 차지하는 memory access violation이다. 포인터를 몇번 써본 개발자라면 척하고 다들 아는, 예를 들면 이런 슬픈 이야기이다.
--- 안드로메다 마을에 사는 순이는 C언어로 된 동물의 숲 소스를 만지작 하고 있었습니다. 인사말을 여러개 정해서 하나씩 써먹고 싶어서, 인사를 하는 부분을 살짝 고쳤지요. 다음과 같이 포인터를 선언하고 인사말을 여러 개 채웠답니다.
char** hi; hi[0]="안녕하세요?"; hi[1]="왓썹맨~"; hi[2]="이 폐인아!!!"; hi[3]="공부나 하시지?";
print_hello_message(hi[random()]);
맨날 "안녕하세요?"만 하다가 다양한 레파토리를 확보한 순이는 신이 났어요. 컴파일 해서 다시 마을 문을 열고, 들어가 마구마구 휘젓고 다니기 시작했습니다. 패트라한테도 인사하고, 럭키한테도 인사하고, 못생긴 짠돌 너굴이한테 인사할 때마다 매번 다른 말을 할수 있는거에요!! 킹왕짱!. 드디어 이 마을에서 가장 동숲폐인부자인 룬님이 멀리서 오고 계세요. 어서 인사를 해서 잘보여야 돈을 주겠지요?
인사하자 고고!! 무브무브!! 하고 룬님을 향해 한발짝 발걸음을 옮기는 순간.
눈 앞에 빨간게 번쩍.
마을에 핵폭탄이 터져 안드로메다 마을 사람들은 모두 죽고 말았답니다. 빵!!!
(끛) ---
- 안드로메다 마을은 왜 멸망했을까?
이야기에 나오는 코드를 뚫어져라 보면 답이 나온다(...). 알고 보면 굉장히 단순한 문제이면서, 늘 실수를 하게 되는 부분이다. 메모리 할당을 잊어버리는 경우 뿐만이 아니라, 보통 다음과 같은 아찔한 일들을 많이 저지른다.
- 10개 원소를 가지는 배열이라고 해놓고 11번째 원소에다가 뭘 쓰셈! 이라고 한다.
- 할당하지 않은 메모리 영역을 free하라고 시킨다.
- 포인터 변수에 접근하다가 기존에 할당해 놓은 전역 변수의 주소값을 마구 침공한다.
- define된 상수값을 바꾸려고 시도한다.
- 시한폭탄의 무서움
리눅스나 윈도우나, 어느 운영체제에서든, 경험적으로 저런 나쁜짓을 한 경우 100% 확실히 그 시점에 "빵!!"이라고 알려주지는 못한다. 심지어 운이 좋은 경우 죽을 때까지 이게 나쁜짓을 한 거였다는 걸 모르고 지나갈 수도 있다. 이 경우보다 조금 더 운이 좋은 경우는 특정 상황에서 "빵!!"이라고 터지는 것이 반복되는 경우. 이 경우 이 상황에서부터 짚어나가면 문제가 어디 있는지 언젠가는(...) 알아낼 수 있다.
위의 순이의 경우는 가장 비참하고도 어려운 케이스. 분명히 나쁜 애는 인삿말 루틴인데, 걸어갈 때 마을이 멸망했다. 그것도 그 전에 막 돌아다닐 땐 괜찮았는데!. 나쁜 짓을 저지른 부분과 아무 상관없는 동작에서 랜덤하게 "빵!!"이 터지는 것이다.
- 어떻게 고쳐!!!
디버깅도 참 비참해진다. 필자는 보통 다음과 같은 방법을 쓴다. 그러나 이것도 머신에 따라, OS에 따라, 디버깅 쌈질을 하는 시각에 따라 메모리가 할당되는 위치가 변경되면 대략 난감해지는 것이긴 하다ㅠㅠ.
- 줄주리타 도와주세요 ㅠㅠ.
코드 검토 헬프를 요청할 추가 뇌를 확보하여 옆에 앉혀놓고 확인을 받는다.
- 디버거 신공
gdb(임베디드 환경에서는 armsd같은 임베디드 컴파일러)로 각종 변수들의 16진수 주소값ㅡㅡ들을 마구 추적하여 메모리 값들중 어떤 값이 언제 별나라로 가버리는지 알아내는 방법을 쓴다.
- 디버거가 없으면!
그저 하염없이 "이 코드가 맞는걸까!!"를 외치며 해결될 때까지 머리를 쥐어 뜯거나 printf 신공을 쓴다(일반론이지요).
- 애초에 이런 재앙이 일어나기 전에 되도록 많은 머신, 다양한 OS환경에서 실험하여 폭탄 탐지율을 높인다(보통 사실상 힘든 힘든 경우가 많지만 가능하면..쩝).
임베디드에선- 볼사람만 보세용
- 자원이 풍족한 보통 컴퓨터/서버 환경에서는 듣기 힘든 번외편 - 임베디드.
이는 비단 C언어 뿐 아니라, 어느 코딩질에서도 결국 피해갈 수 없는 이야기이다. 특히 "임베디드"라는 말이 들어가는 순간 이 이야기는 초특급 납량 특집 일일 시트콤이 되는데, 그 이유는 이 업계 일이 가지는 네 가지 특성 때문이다.
- 주소 관리의 많은 부분을 assembly 등을 사용하여 직접 해야 한다. 비교적 high level인 C/JAVA 코드로 짠 application 중에도 성능상의 문제로 assembly가 난입한다.
- 우리에게 주어진 땅이 컴퓨터에 비해 너무너무너무 작아서 잘못된 메모리 할당의 경우 충돌이 일어날 확률이 더더욱 높아진다. 무려 메모리 할당/해제 측면에서 비교적 편리하다고 하는 JAVA도 예외가 될 수 없다.
- 작은 곳에서 빨리 돌아야 하고, 코드도 작아야 하기 때문에 우리가 흔히 말하는 "아름다운 구조"가 쉽지 않다. 16진수 주소가 하드코딩되어 이리 저리 날아다니는 막장 누더기 코드가 심심찮게 생산된다. 예를 들어 memory mapped I/O는 쓸 때는 편하네 해피해피이지만 버그 터지면 ㅠㅠ.
- 각 application, OS 영역에서 접근 가능/불가능한 주소 영역이 명확하지 않다. 심지어 abort/interrupt handler조차 조금만 노력하면(?) 전부 이상한 아이들로 overwrite 해버릴 수 있다(...).
임베디드에서(시뮬레이터라면 더욱) 이 문제 관련하여 자주 만나는 귀신은 "스택이 무럭무럭 자라나요" 귀신이다. 스택이 높이높이 자라는 경우 가끔 변수 영역도 모자라 코드가 올라가 있는 메모리의 일부를 덮어 써버리기도 하는데, 어떤 럭셔리 디버깅 툴이라도 이렇게 되면 하루이틀 밤을 새도 못고치는 경우가 태반이다.
어느 루틴을 지나는 순간 코드메모리 위치의 0번째 주소에 있는 assembly function(예를 들면 jmp <초기화 주소>;)이 이상하게 탈바꿈해 버린다(jmp <쓰레기주소>; 가 연속된다든지). 코드가 변질되었다는 사실 조차 눈치채기 힘들 뿐더러, 코드가 사라진 시점 조차 찾아내기가 너무너무너무 어렵다. 코드가 부분적으로 없어도 그 코드에 접근을 안하면 시스템은 잘 굴러가기 때문이다(...).
그저 스택을 많이 쓰고 있을 뿐 임베디드가 아닌 메모리가 많고 많은 컴퓨터에서는 아무 하자가 없는 코드인걸!.
여기서 디버깅 툴조차 쓸 수 없는 환경(예를 들면 손납땜한 보드에 부트로더를 손으로 짜 넣고 OS를 포팅해야 하는 경우)이면 정말 다 때려치고 팝핀과 다리찢기를 열씨미 연마하여 춤선생님으로 진로를 변경하고 싶어진다 ㅡㅡ;.
하지만 우리는 졸업을 해야 된다거나, 먹고 살아야 한다는 목표가 있기에, 다음과 같은 사항을 명심하며 하루하루 견뎌 나간다.
- 일반 컴퓨터에서 시뮬레이션 가능한 코드는 행여나 자만치 말고 절대 컴퓨터에서 먼저 검증한다.
일반 환경에서 검증된 코드가 임베디드 환경에 올라간 순간 토하기 시작한다면, 95%는 메모리 침공이다.
- 보드 / 실제 기기에 코드를 올려야 할 경우 그 보드 / 기기에 시뮬레이터가 딸려 있는 경우라면 절대 시뮬레이터에서 철저히 검증한다.
- 시뮬레이터에서 안돌고 기기에서 제대로 동작했다고 해서 그게 영원히 해피엔딩은 아니다. 시뮬레이터에 명확한 버그가 있는 경우가 간혹 발견되는데, 버그 리포팅을 하면 신나서 고쳐주는 곳"도" 있다(머엉).
- 맨땅 헤딩은 절대 피한다!. "적어도 Multi ICE와 ADS(RVDS)는 질러야 해요!"라는 지름신의 메시지를 늘 전파하도록.
- 가능하다면 메모리 권한 설정을 최대한 활용한다.
- 코드같이 날아가면 안되는 아이들이 ROM과 같은 쓰기 불가능한 곳에 위치한다면 럭키~!. 아니라면 자기 손으로 abort handler를 만드는 것 추천.
- armulator와 같은 시뮬레이터의 경우 메모리 주소 영역 별로 권한을 설정해 둘 수 있다. 코드메모리 같은 경우는 딱히 사연이 없으면 절대 쓰기 불가로 설정해 둘것!. 설정법은 흔히 사용하는 ARM cpu의 경우 종류에 따라 약간 천차만별이다.
- 참고로, 영역별 쓰기 금지가 있어도 걸어둘 수 없는 상황도 무려 존재한다!. 이 쪽의 이런 저런 재밌는 이야기는 다음에 하고 싶어지면 포스팅 예정.
- 뭔가 이상하다고 하면 일단 stack size를 살펴 본다.
mp3 나 동영상 플레이어라든지, image viewer의 경우 자칫하면 stack size가 버퍼링 할 프레임 때문에 몇 기가가 넘어간다. stack size나 stack pointer가 평소 친근한 숫자와 다르다면 스택귀신이 출현했을 가능성 대폭 증가!.
지금은 디버깅 쌈질 로그가 뇌에 8년어치 쌓여있는 상태라, 대략 이런 경우의 50.32% 정도는 대충 이러이러하겠네라고 금방 찾아나갈 수 있지만, 위의 순이 이야기에 나오는 것 같은 랜덤 폭탄은 여전히 무서운 이야기이다. 한번 멸망한 마을은 이전으로 돌아갈 수 없다(...).
이 폭탄들을 어떻게 하면 개발자들이 쉽게 찾아내고 안전하게 제거할 수 있을까 하는 문제는 고민해 볼만 한 것 같다. 메모리 공간을 꼼꼼하게 체크하는 메커니즘을 디버거에서만 고안해도 선량한 프로그래머의 철야 질주가 좀 덜하지 않을까나.
그러나 완벽하지 않은 데는 다 나름의 이유들이 있는 걸 알기에 ㅠㅠ. OS나 컴파일러가 이래서 외계분야인 거지.
"남의 집 땅은 밟지 마세요" 라는 팻말보다는, 남의 집 땅을 밟는 순간 삐요삐요가 울리며 "꼼짝마"를 외치는 코딩 사회를 난 원한다고!!!.
ps: 한참 신나게 포스팅을 하다가 컴퓨터씨가 다운되는 바람에 다 날리고(쉤), 의욕이 30%로 줄어 내용의 의도와 성실함도 30%로 줄었다.ㅡㅡ;;
Trackback 0
:
Trackback Address :: http://lunetica.net/trackback/2
|