손가락 골절이 된지 열흘 정도 지났다. 이제 통증은 거의 사라졌고 다 나은 듯한 느낌이 들지만 골절은 무조건 한 달 기브스 해야 한다고 해서 얌전히 하고 있다. 근데 계속 손가락을 못 펴니까 반대로 근육통이 좀 생기는 것 같기도 하고, 가끔 피가 안 통하는 느낌도 들고 그래서 가끔 빼서 씻고 움직여주기는 하는데, 이게 잘하는 짓인지 아닌지 잘 모르겠다.

오른손을 못 쓴 채 열흘 정도 살아보니 두 가지 상반된 느낌이 든다. 생각보다 살만하다는 느낌과 생각보다 불편하다는 느낌. 나는 일상 생활에서 양손을 고르게 쓰려는 노력을 꽤 오래 해왔다. 양치질도 익숙하고 마우스도 큰 불편 없이 쓴다. 의외로 설거지 같은 것도 양손을 반대로 해보면 매우 어색한 느낌이 들지만 이것도 익숙해졌다. 왼손 드리블이나 레이업슛도 그럭저럭, 근거리 점프슛도 넣을 수 있다. 그러다보니 의외로 처음 해본 왼손 젓가락질도 그럭저럭 한 끼 식사를 할 수 있을 정도까지는 금방 익숙해졌다. 그래서, 이렇게도 살 수는 있겠다는 생각이 든다.

이렇게 어려울 것 같은 일들이 의외로 그럭저럭 해결이 되는데, 반대로 예상 못했던 작은 불편들의 개수가 상당히 많다. 그러니까 오른손을 못 쓰면 불편지수 100인 일이 4~6가지 있지 않을까 싶었는데, 반대로 불편지수 20 정도인 일이 20가지 쯤 있는 그런 느낌이다. 그래서 불편함의 총합은 별로 작지 않다.

그러다보니 장애인에 대해 여러 모로 다시 생각하게 된다. 난 어려서부터 장애인이 나오는 미디어를 보기 꺼려했다. 만화고 드라마고 다큐멘터리고 다 싫었다. 왠지 내가 저렇게 되는 상상을 하게 되는데 그게 너무 싫었기 때문이다. 아마 사람들이 장애인을 차별하는 심리의 기저에 이런 심리가 있는 것은 아닐까 싶기도 하다. 그러다가 장애인을 미디어에서 진지하게 바라볼 수 있게 된 것은 리얼 때문이다. 어서오세요 305호를 볼 때 동성애가 뭔지 학습하는 기분으로 봤다면 리얼은 정말 장애인이 된 느낌까지 같이 느끼는 기분인데도 별다른 거부감 없이 몰입할 수 있었다. 장애인이 된다는 것은 죽고 싶을 만큼 몹시도 우울한 일임은 틀림 없지만, 그럼에도 불구하고 울고 웃고 살아갈 수 있다는 것. 그런 메세지를 던져준다.

내가 겪는 이 잠깐 동안의 불편과는 비교도 안되는 불편을 평생 겪어야 하는 사람들이 있다. 그걸 때때로 떠올리게 된다. 그렇다고 내가 갑자기 장애인 봉사활동을 하거나 그러지도 않을 것이고, 길가는 장애인을 동정어린 눈으로 바라보지도 않겠지만, 그냥 그런 생각이 든다. 그 사람들도 하루하루 살아가고 있구나.

이번 추석여행에선 귀찮아서 사진 많이 안 찍었다고 생각했는데 iphoto로 가져와보니 106장. 여러 가지로 힘든 일이 많았던 추석이었지만, 사진들을 보니 힘든 건 잊혀지고 즐거운 일들만 남아서 좋다.

여러 각도로 접해봤던 airbnb를 실제 소비자로 이용해본 첫 경험이기도 했다. 3대가 모여야 하다보니 제법 큰 곳을 예약해야 했는데, 호텔이나 콘도 등은 너무 비싸거나, 아니면 허름한 곳 밖에 없고 해서 에어비앤비를 찾았는데, 50평대, 방 3개에 2박에 50만원인 곳이 있었다. 동백섬 앞의 현대아쿠아팰리스. 위치도 좋고 여러 가지로 최적이라고 생각해서 예약했다.

중간에 날짜를 하루씩 뒤로 미루게 되었는데, 에어비앤비는 예약 변경 기능이 없고, 취소하게 되면 에어비앤비 쪽 수수료는 무조건 물어야 해서 그냥 주인이랑 합의 하에 변경했는데 그리 나쁘진 않았지만 에어비앤비가 다소 괘씸하게 느껴졌다. 취소로 인한 손해는 호스트가 보는 거니까 호스트가 수수료를 받으면 이해가 되는데, 호스트가 받지 않는 수수료를 에어비앤비가 받는다는 건 어떤 명분으로 이해할 수 있을까? 독점적 지위를 이용한 횡포라고 생각된다.

막상 도착하니 현대아쿠아팰리스는 주차장이 까다로워서 주인이 옆 아파트의 주차장으로 안내하더니, 자기가 그 아파트에도 방이 있다면서 주차장이 불편하면 바꾸는 게 어떻겠냐고 했다. 방 보고 결정하기로 하고 방을 봤더니 괜찮은 것 같아서 변경. 변경한 곳은 한신 휴플러스.

근데 이게 입주한지 얼마 안되서 그런지 하자가 엄청 많았다. 제일 충격적인 건 첫날 밤 자는데 갑자기 비상벨이 울려서 가봤더니 홈 오토메이션 기기에서 보안 경고벨이 계속 울리는데, 어디가 원인인지를 알려주지 않는다는 것. 경비실에 연락했더니 끄는 방법을 알려준다? 근데 벨이 두 개 중에 하나는 그래도 안 꺼져서 결국 직원이 와서 싱크대 쪽 경고장치의 전원을 뽑아가네? 자주 있는 일인 듯 했다.

근데, 더 충격적인 건 잠시 후에 그 원인이 밝혀지면서부터. 경비 직원이 와 있는 동안 쿵 소리가 한 번 나서 도대체 뭔 일인가 했는데, 그 소리의 원인이 밝혀진 것. 선화가 갑자기 날 불러서 저것 좀 보라고 해서 봤더니 안방 앞 베란다의 위에서 사람 손이 내려와 있었... 그나마 내가 본 건 목장갑 낀 손이어서 뭔가 작업 중이라는 느낌을 받아서 크게 놀라진 않았는데, 그 전에 선화가 목격한 건 사람 머리가 내려와 있는 거였다는;;;

그래서 문을 열고 위를 보니까 사다리가 하나 있는데 거기서 사람이 뭔가를 작업하고 있었다. 불이 났을 때 등을 대비한 비상사다리인데, 그걸 아래위로 뚜껑이 덮고 있는데, 아래쪽 뚜껑이 떨어져서 아까 소리가 난 거였고, 

진지하게 eclipse를 버리고 PyCharm으로 갈아타는 것을 고려 중이다. 일단 개인 프로젝트는 PyCharm으로 갈아탔다. 사실 요즘은 다들 IntelliJ 계열이 더 좋다고 평가하는 분위기지만, 나는 여전히 eclipse의 몇몇 좋은 점들을 버리기 아쉬웠다. 몇 달 전에 규영이랑도 비슷한 이야기를 나눈 적이 있는데, 커피숍에서 만났을 때 규영이는 PyCharm으로 코딩을 하고 있었고 날 보자마자 PyCharm 이야기를 꺼내며 엄청 좋다고 칭찬했다. 그래서 내가 eclipse보다 좋냐고 물었더니, 머뭇머뭇하면서 그건 잘 모르겠다고 대답했다. 나도 딱 그런 느낌이다. 분명 PyCharm의 막강한 기능들이 참 좋은데, eclipse보다 좋은지는 말하기 힘들었다. 그래서 그동안 줄곧 eclipse+pydev 조합을 써왔다.

근데 요즘은 eclipse의 몇몇 문제들이 점점 참기 힘들다. 맥에서 단어 단위 이동이 이상한 것부터 시작해서 아직도 리소스 찾기에서 * / 같은 문자를 섞어 써야 하는 거라든지, 앞뒤로 네비게이션할 때 히스토리가 꼬인다든지, 아주 기본적인 기능들의 동작이 이상하다. 내가 eclipse를 쓰기 시작한 게 2001년이니 12년이 된 셈인데, 2005년 즈음까지만 해도 eclipse는 늘 다음 버전이 기대되고 기다려지는 소프트웨어였다. 하지만 그 뛰어난 프로그래머들이 모였다는 eclipse foundation도 소프트웨어 위기를 겪는 건지 점점 품질에 문제가 생기기 시작했고, 다른 IDE에서 지원되는 기능을 흡수하는 속도도 매우 느려졌다. 성능도 점점 느려져서 이제 다음 버전엔 뭘 망가뜨릴지 걱정되는 상황까지 왔다.

이제 아쉽지만 eclipse를 떠나보내야 할 시점인 것 같다. 안녕, eclipse~

한 일주일 페이스북에 투덜거리고 나서 이제 입 다물고 월급쟁이 모드로 일하려고 했는데, 오늘은 너무 빡쳐서 글 싸지른다.

오늘 오전에 있었던 일이다. 여긴 JIRA 티켓 단위로 deploy를 하는데, 오늘은 내가 작업한 티켓 하나와 다른 동료가 작업한 티켓 하나를 내가 묶어서 deploy하기로 했었다. 그런데 1티켓당 1브랜치가 원칙이기 때문에 두 개의 브랜치를 merge해야 하고, 프로세스상 merge해야 하는 브랜치가 3개 더 있다. 그래서 merge하는 과정에서 QA 단계에 있는 브랜치도 같이 merge된 채로 deploy를 하고 말았다. 다행히 같이 QA 중이던 브랜치는 서비스에 아무 영향을 주지 않는 브랜치였다. 티켓 상황을 구체적으로 서술하면 이렇다.

• A : Ready to deploy. 간헐적인 주문 거래 오류를 막는 패치
• B : Ready to deploy. 간단한 데이터 마이그레이션 스크립트
• C : In QA, 서비스에는 영향 없을 것으로 추정됨. 10분 이내에 확인 가능.

A + B만 deploy 해야 하는데 A + B + C를 deploy한 것이다. C가 실 서비스에 영향이 없을 듯 하니 난 당연히 확인만 하고 넘어가면 되는 줄 알았다. Working software가 무엇보다 중요한 것 아니겠는가

그렇지만 위에서 내려진 결정은 달랐다. C는 프로세스를 따르지 않았으므로, 규정에 따라 rollback 하고, 오후에 다시 A + B만다시 deploy 하라는 것. Blue Green Deployment를 하기 때문에 rollback이쉬우므로 rollback은 그냥 해도 좋지만 이미 deploy 가능 시간이 지났으므로, 다음 deploy 가능 시간대에 하라는 것이다.(여기는 deploy 가능 시간이 10시 반 이전, 3시 ~ 4시 반 사이) 

하지만 제 아무리 이전 코드가 그대로 있어서 link만 바꾸면 된다고 해도 rollback이 100% 안전한 경우는 웹 서비스에는 존재하지 않는다. 당연히 rollback에도 risk가 존재하며, C가 가진 risk에 비해 작다고 하기 어렵다. 실제로도 이 의사 결정을 내리는 동안 C는 아무 문제를 일으키지 않았지만, rollback은 migration 문제를 일으켰다.

애자일 팀이라면 이 정도의 상황이면 당연히 C를 빠르게 검증하려고 들 것이다. 검증을 통과하면 제일 좋은 상황이고, 문제가 생기더라도 그 문제의 종류에 따라 대처할 것이다. 문제가 작으면 quick fix로 해결할 것이고, 문제가 크면 아마도 위의 결정처럼 일단 rollback한 후 즉시 A + B를 다시 deploy할 것이다. 하지만 애자일 팀이라면 아마도 deploy 시간에 제약이 크지 않을 것이므로 즉시 수정 deploy가 나갈 것이다.

그래서 난 그 결정에 잠시 저항했지만, 의사결정권자를 비롯한 팀원들 모두의 의견이 거의 일치했다. 이미 요기는 그런 문화가 정착해 있고, 내가 이교도다. risk를 감수하고 빠르게 전진하기보다, risk의 최소화를 가장 중요하게 생각한다. 하지만 그렇다고 정말 risk가 최소화되고 있느냐 하면 그런 것도 아니다. 내가 일한지 불과 3주인데 벌써 크고 작은 장애를 네 번 경험했고, 앱이 죽는 경우, 웹 주문이 안되는 경우 등의 대형 장애도 발생했다. PHP 쓰는 회사도 이 정도 장애는 안 난다.

얼마 전에 있었던 앱 죽는 장애도 10분 안에 죽는 것을 막을 수 있고, 15분 안에 수정 패치까지 할 수 있는 문제였지만, 복잡한 프로세스를 따르느라 1시간도 넘게 걸렸다. risk를 최소화하기 위해 프로세스를 도입했지만, 정작 그 프로세스를 지키느라 risk가 올라가고 있는 것이다.

그런데 정말 날 더 충격 속에 빠뜨린 것은, 이런 상황에 이의를 제기하는 사람이 아무도 없다는 것이다. 티켓 하나 개발해서 deploy하기까지의 프로세스를 상세히 서술하면 무려 15단계에 이른다. 티켓을 만들지 않은 일은 하면 안된다. pip_requirements 파일 하나 고치려면 새로운 티켓 만들고 브랜치 생성한 다음 staging에서 테스트하고 QA 거쳐서 deploy하고, 그래야 다시 master에 merge된다. 그게 귀찮아서 그냥 다른 티켓 브랜치에 섞여서 가면, 그 브랜치가 QA 거쳐서 deploy되기 전까지 다른 브랜치에선 그 작은 pip_requirements 변경 사항 하나가 반영이 안된다. 수동으로 다시 브랜치 찾아서 merge해 와야 한다. 이러니 오래된 작은 문제점들이 굉장히 많다. 그래서 내가 가끔 너무 복잡하다고 말하면 "복잡한가요?"라고 되묻는다. 단순히 위의 누군가가 이런 관료주의를 지향해서가 아니라 직원들 대부분이 이런 관료주의를 지지하고 있다.

뭔가 문제가 발생하면 재발 방지책을 항상 찾는다. 여기까진 좋다. 하지만 Five Why 등을 통해서 근본 원인을 찾아들어가는 것이 아니라 1차원적인 해결책만 찾는다. 그러니 문제가 하나 발생하면, 그 문제를 막기 위한 프로세스를 하나 추가한다. 이런 과정이 반복되면서 점점 프로세스가 비대해져 왔을 것이다. 프로세스가 복잡한 회사들도 처음부터 그랬던 회사는 거의 없다. 대부분 전형적인 갈라파고스형 진화 과정을 거친다.

그래서, 내가 어떻게 바꾸는 건 불가능하다. 한 명이라도 동조자가 있어야 할 텐데, 정말 그 한 명이 없다. 정말 월급쟁이 모드로 전환해야 하나. 고민이 깊어간다.

육아 정보 위키를 만드는 것이 생각보다 어렵다. 채워넣어야 할 데이터의 양이 너무 많은 것이다. 그냥 돈을 쓰면 쉽게 해결할 수 있을 것도 같지만, 또 위키스럽게 구조화를 하려면 내 노력이 들어가야 한다. 지난 주에 오픈을 하긴 했지만 아직은 크게 의미가 있진 않다. 이 컨텐츠를 어떻게 채울 수 있을지를 좀더 진지하게 고민해야 할 듯 하다.

내 블로그도 좀 리팩토링을 하려고 했는데 생각보다 어려웠다. 일단 개인 블로그다보니 위키보다 블로그 형식이 더 적합하다. 사실 내 블로그는 위키여야할 이유가 거의 없다. 단순히 가장 좋은 위키 편집기로 충분한 건지도 모른다. 일단은 내 블로그에 내가 담고 싶은 모든 내용을 완벽하게 담아내는 것만 해도 상당히 어려운 목표일 것 같다.

이콜레모 개발자 위키는 그럭저럭 만족스럽다. 내 지식들을 꾸준히 정리해가기도 좋고.

그래서, 일단 이번 주 목표는 다음 두 가지

• 내 블로그에 내가 담고 싶은 내용과 구조를 완벽하게 소화할 수 있도록 만들기
• 육아 정보 데이터 입력 방안 마련하기