소프트웨어 개발 종사자들은 훌륭한 사람들입니다. 대부분의 종사자들은 자신의 소프트웨어가 사람들에게 인정 받기를 원합니다. 필요하다면 기꺼이 밤샘 작업을 하며, 실제로 연장근무를 많이 하기로 명성이 자자합니다. 누구도 자신이 밤새워 완성한 소프트웨어에 대한 불평불만이 게시판을 가득 채우기를 원치 않습니다. 그러나 소프트웨어 개발 종사자들의 아낌없는 노력에도 불구하고, 프로젝트가 실패하거나 업무가 엉망진창 되기는 쉬운 것 같습니다.
소프트웨어 개발은 마리오가 데이지 공주를 구출하는 것에 비유할 수 있습니다. 데이지 공주에게 가기 위해서는 수많은 징검다리를 건너고, 쿠파스를 물리쳐야 합니다. 매 순간 게임오버가 될 수도 있습니다. 소프트웨어 개발은 오히려 더 어렵다고 해야 하는데, 게임과는 달리 위험이 다가오고 있음을 눈으로 볼 수 없기 때문이죠.
위험이란?
이 글은 함정과 위험을 다룹니다. 여기서 말하는 위험이란 무엇일까요? 컨설턴트들은 위기 관리에 대해 알쏭달쏭한 이야기를 늘어놓기도 합니다만, 저는 애송이 개발자일 뿐입니다. 저는 위험에 대해 간단한 정의를 내립니다. 업무와 제 자신의 정신건강을 엉망진창으로 꼬이게 만들고, 제 시간에 퇴근하지 못하게 할 수 있는 모든 것이 위험입니다. 누군가 회원정보 테이블을 드랍하는 것, 치질에 걸린 동료의 업무를 대신 하는 것, 빨리 퇴근하고 싶은 마음에 대충 소스코드를 커밋해서 큰 소동을 일으키는 것을 생각해볼 수 있습니다. 여기서 위험은 불필요한 권한 부여, 치질, 빨리 퇴근하고 싶은 마음 등이 될 수 있습니다.
험프티 덤프티
앨리스:
바닥에 앉는 게 더 안전하지 않을까요?…중략
험프티 덤프티:
물론 나는 그렇게 생각하지 않아. 그래도 만일 내가 떨어지면, 그럴 리는 없지만, 그래도 만일 내가 떨어지면……….중략
바로 그 순간 아작하고 요란하게 부서지는 소리가 숲을 온통 뒤흔들었기 때문이다.
거울 나라의 앨리스 중
험프티 덤프티와 앨리스가 나눈 대화는 재미있습니다. 목과 허리를 구분할 수 없는 우스꽝스러운 달걀 인간의 모습을 상상하다 보면 웃음이 절로 나오죠. 하지만 실제 세계의 소프트웨어 개발자, 바로 우리 자신이 험프티 덤프티라는 사실을 깨닫게 되면 꼭 재밌지만은 않습니다. 위의 대화를 살짝 바꿔보겠습니다.
개발자:
Lazy 개발사가 XML 레코드 분석 라이브러리를 제때 제공하지 못하면 어떻게 하죠?매니저:
물론 나는 그런 일이 벌어질 거라 생각하지 않아……
어디에선가 많이 들어본 대화 같습니다. 저는 이 같은 대화를 백만스물한개 정도는 거뜬히 생각해낼 수 있을 것 같습니다.
무시하기
험프티 덤프티는 앨리스의 경고를 무시했습니다. 험프티 덤프티는 그럴 리는 없지만
이라고 말하지만, 한편으로는 떨어질 수도 있다는 것을 알고 있었습니다. 그럼에도 예상되는 재앙을 무시함으로써 위험을 피해나갈 수 있는 양 행동했습니다. 눈을 가리면 사람이 사라졌다고 생각하는 갓난아기 같습니다. 사용자가 네트워크에 연결되어 있지 않은 PC에서 메신저를 사용하면, 윈도우가 5분간 먹통이 된다고 해보죠. 물론 요즘 같은 시대에 인터넷에 연결되어 있지 않은 컴퓨터를 사용하는 사람은 없을 거야.
라며 무시하고 제품을 출시할 수도 있습니다. 출시하고 일주일도 안 돼서 고객의 항의전화에 시달리는 위험을 감수해야 하겠지만 말입니다.
위험 회피 메커니즘
험프티 덤프티는 운이 좋았습니다. 비록 조언을 무시함으로써 재앙을 맞이하긴 했지만, 적어도 그에겐 조언자가 있었습니다. 아무도 위험을 지적하지 않는 경우도 많습니다. 그러나 위험요소에 대해 언급하는 이가 없을 때조차도, 구성원 중 한 사람 정도는 문제가 발생할 수 있다는 사실을 알기 마련입니다. 누군가는 석연치 않은 기운을 느끼고 있을 겁니다. 하지만 그 느낌이 강할수록, 더더욱 본능의 경고를 무시하고자 하는 유혹이 고개를 들게 됩니다. 위험의 정도가 클수록 자신이 위험을 통제할 수 없으리라는 불안감도 크기 때문입니다.
사람에게는 최악의 사태를 본능적으로 생각하지 않으려는 경향이 있는 것 같습니다. 오늘 퇴근하는 길에 재수없게도 음주운전 차량에 치일 수도 있다던가, 어느날 갑자기 한반도가 환태평양 지진대에 편입되어 집이 무너질 수도 있다는 걱정을 하는 사람은 많지 않습니다. 그런 일이 벌어질 가능성이 낮은데다가 ‘나’의 힘이 미치지 않는 영역이라고 느끼기 때문이겠죠. 그래서 다섯번 부르면 나타난다는 ‘캔디맨’의 이름 마냥, 언급하는 것조차 터부시 되기도 합니다.
하지만 통제가 불가능해 보이는 위험에 대해 고민하는 것은 그 나름대로의 가치가 있습니다. 앞으로 살펴보겠지만 처음 생각과는 달리 통제가 가능한 경우가 대부분이기 때문입니다. 설사 소수에 속하는 사례와 마주치더라도 시간낭비는 아닙니다. 최소한 그 위험이 실현되지 않았을 때, 신과 자신의 행운에 감사하는 마음을 갖게 될 것입니다.
위험 감지하기
위험 회피 메카니즘을 구성하는 나사 하나만 깰 수 있다면 위험을 감지할 수 있습니다. 우선 그래도 만일 내가 떨어지면,
의 뒷이야기를 이어가 보겠습니다. 그래도 만일 내가 떨어지면, 달걀 몸뚱아리가 산산조각 나겠지.
, 데이터베이스가 오프라인되면, 중요한 요청이 유실되겠지.
일단 말이라는 형태로 위험을 정의하면, 생각의 봇물이 터지기 마련입니다. 연약한 달걀의 몸이 깨지지 않기 위해 담장에서 내려올 수도 있고, 달걀 껍질을 티타늄으로 코팅할 수도 있을 겁니다. 데이터베이스를 클러스터링으로 구성할 수도 있고, 메시지 큐에 임시로 요청을 저장할 수도 있겠죠.
팀 단위로 일할 때라도 각자 주어진 업무가 있기 마련입니다. 일을 나눠서 하게 되면, 자신의 업무는 스스로가 책임지게 됩니다. 그러나 역할과 책임의 멍에를 진다는 것이 다른 사람의 도움을 받지 말라는 뜻은 아닙니다. 관련 업무의 경험이 있거나, 신뢰할 수 있는 팀원에게 도움을 요청해 봅시다. 자판기에서 음료수 캔을 뽑아서 잠시 잡담을 나눕니다. 그것만으로도 회의라는 형식이 주는 딱딱함에서 벗어나서 약간은 자유로운 사고가 가능해질 수 있습니다. 자신의 업무를 설명하고, 도움을 요청할 때입니다. 제가 놓치고 있는 게 있나요?
팁: 여러분 주위의 회의론자를 한명쯤 포섭해 놓으세요. 의지만 있다면 하늘의 별도 딸 수 있다고 믿는 사람은 이런 작업에 적합하지 않습니다. 온라인 게임 서버가 가끔 죽을 수 있다는 위험에 대해 회의론자는 클러스터링 구축을 제안할 것입니다. 반면 지나치게 진취적인 사람은 365일 온라인 상태로 있을 수 있는 서버를 만들라고 할 겁니다.
캔디맨
조엘 왈:
NIH 신드롬은 팀이 스스로 개발하지 않은 기술을 거부하는 현상을 뜻하는 말입니다.
조엘처럼 NIH(참조 1)의 열렬한 옹호자일지라도 외부 컴퍼넌트를 사용할 수밖에 없는 경우는 있습니다. 온라인 결제시스템을 구축해야 하는데, 은행측에서 보안상의 이유로 프로토콜을 공개할 수 없다고 해보죠. 게다가 C#용 컴퍼넌트는 새로 개발을 해야 한다고 합니다. 약 2개월 정도의 시간이 필요하다고 합니다. 이 결제시스템은 매우 중요해서 반드시 3개월 내에 납품을 해야 합니다. 구현 및 테스트 등에는 1개월밖에 주어지지 않았는데, 언제나 그렇듯이 충분한 시간은 아닙니다. 이쯤에서 다시 험프티 덤프티와 앨리스의 대화를 엿들어보죠.
앨리스:
컴퍼넌트가 제때 넘어오지 않으면 어떻게 하죠?험프티 덤프티:
물론 나는 그런 일이 벌어질 거라 생각하지 않아.
캔디맨 퇴치하기
영화에서는 공포에 대처하는 세가지 유형의 인물이 등장합니다. 캔디맨으로부터 도망치려다 죽는 사람, 캔디맨에게 맞서다가 죽는 사람, 그리고 살아 남는 주인공. 운이 좋으면 죽임을 당하기 전에 주인공이 캔디맨을 물리칠지도 모르겠습니다. 하지만 대부분의 도망자는 성공하지 못합니다. 살아 남는 사람보다 죽는 사람이 많아야 공포영화라고 할 수 있기 때문인지도 모르겠습니다. 성공하는 프로젝트의 주인공이 되어 살아 남으려면, 캔디맨이 아무리 두렵더라도 맞서야 합니다. 그리고 캔디맨을 향해 칼을 휘두르는 것이 아니라, 캔디맨의 누구인지부터 조사해서 약점을 찾아야 합니다
다시 온라인 결제시스템 문제로 돌아가보겠습니다.. 은행의 개발이 지연되면 프로젝트가 무너지는 것을 지켜보고만 있어야 할까요? ‘위험 감지하기 기법’을 사용해보세요. 저는 몇 가지 검토할만한 대응방법을 떠올릴 수 있습니다.
-
은행측 개발자를 회유합니다. 설에 참치통조림세트를 보낼 수도 있을 겁니다. 예산이 충분치 않더라도 생일에 맞춰 축하메시지를 휴대폰으로 보내는 수고 정도는 할 수 있겠죠. 우리의 관심을 그들에게 지속적으로, 그리고 약간은 우회적으로 보여줄 방법은 많습니다.
-
여러분이 말단 개발자이고, 어떤 영향력도 발휘할 수 없다고 생각해봅시다. 그래도 발가락 하나 꿈틀거릴 공간은 남아 있습니다. 일주일에 한번 정도 은행측에 연락을 취해서 얼마나 진척됐는지 확인할 수 있을 겁니다. 매번 확인된 사항을 관리자에게 보고합니다. 이제 일정지연 문제는 관리자의 책임이 됩니다. 윗사람만 업무나 책임을 위임할 수 있는 것은 아니지 않습니까?
-
온라인결제시스템이 전체 솔루션의 일부분이라면 어떨까요? 최종사용자의 양해를 구할 수 있을 겁니다. 만약 일정지연이 발생하면, 온라인결제시스템을 제외한 나머지 솔루션부터 제공하게끔 협의할 수도 있겠죠.
여러분은 더 좋은 대안을 생각해낼 수 있습니다.
잘해보려고 한 건데
브레인스토밍을 통해 수백가지의 발생 가능한 위험을 분류하고 정리했습니다. 그리고 예비책과 사후대비책을 모두 마련했습니다. 이제 모든 일이 매끄럽게 흘러가리라 예측합니다. 만에 하나 사건이 발생하더라도 예측 범위에 들 것입니다.
정말 그럴까요? 세상 일이 그렇게 쉬우면 저는 벌써 빌 게이츠급 부자가 되어 있었을 겁니다. 제가 최근에 읽은 대체 뭐가 문제야?
라는 책에서는 이렇게 말하더군요. 각각의 해결안은 다음 문제의 근원이다.
온라인 서점 ‘늪지대’의 개발자인 앨리스양은 출근하자마자 달갑지 않은 메일 한통을 읽게 됩니다. 고객이 결제한 물품 정보가 ‘늪지대’의 결제 데이터베이스(Oracle)에 기록되어 있는데, 배송센터의 데이터베이스(MSSQL)에는 없는 경우가 발견됐다고 합니다. 부리나케 원인을 조사해보니, 결제정보 업데이트와 배송정보 업데이트의 원자화가 이뤄지지 않고 있습니다. 개별적인 트랜잭션을 사용하다보니 결제정보가 업데이트되고 난 후, 배송정보 업데이트가 실패해도 처음에 갱신된 결제정보는 롤백되지 않습니다. COM+의 분산트랜잭션 서비스를 사용해서 문제해결에 나서기로 합니다. 다행스럽게도 퇴근하기 전에 문제가 된 부분을 수정할 수 있었고, 앨리스양은 만족합니다.
저녁 늦은 시간에 전화벨이 울립니다. 이제 막 잠자리에 들려고 하는데, 짜증이 납니다. 귀찮은 마음도 잠시일 뿐, 오늘 수정한 페이지에 문제가 있다고 합니다. 서둘러 로그를 살펴봤지만 COM+에 대해 경험이 많지 않아서인지 도무지 원인분석이 되지 않습니다. 하는 수 없이 소스관리시스템에서 이전 소스코드를 내려 받아서 임시 조치합니다.
결론
세상 일이 뜻대로만 되지는 않습니다. 특히 소프트웨어 개발은 변수가 많아서 예상이 빗나가기 마련입니다. 일주일이면 충분할 줄 알았는데, 예상치 않은 버그가 발생합니다. 처음에는 Dropdown 방식이면 된다더니 나중에 마음을 바꿔서 라디오 버튼으로 바꿔달라고 합니다. 어떤 사람들은 위험 자체가 발생하지 않도록 철저하게 통제할 있다고 말합니다. 무척이나 낙천적인 마음가짐이고, 그런 태도가 세일즈에는 도움이 될지도 모르겠습니다. 그러나 온라인 결제시스템의 예처럼 통제가 거의 불가능한 경우가 있습니다. 뿐만 아니라 해결안 자체가 문제의 원인이 되기도 합니다.
한가지만은 분명합니다. 위험의 존재를 인정하고 이를 적극적으로 통제하려고 할 때만, 더 큰 실패를 방지할 수 있습니다. 적어도 눈 가리고 불덩이 속으로 돌진하는 어리석음만은 피할 수 있을 것입니다.
