구본형 변화경영연구소

연구원

칼럼

연구원들이

  • 불씨
  • 조회 수 958
  • 댓글 수 7
  • 추천 수 0
2018년 4월 29일 18시 05분 등록
개발자의 오만함(Hubris)

"모두가 겁에 질려 몸둘 곳을 몰랐다. 아라크네만 제외하고. 
아라크네는 벌떡 일어났다. 아라크네의 빰은 잠깐 붉게 상기되었다가는 곧 핏기를 잃었다. 새벽의 손길에 붉게 물들었다가 해가 돋으면서 창백해지는 하늘빛 같았다. 아라크네는 제 생각을 굽히지 않았다. 오직 이길 수 있다는 일념으로 제 운명과 맞서려 할 뿐이었다." - 오비디우스 <변신이야기> 中

 이번 주 내내 회사가 시끄러웠다. 얼마전 출하한 제품에서 심각한 문제가 발생했고, 이에 대한 원인을 파악하고 대책을 마련하느라 해당 프로젝트 개발팀원들은 정신없는 한 주를 보냈다. 밝혀진 문제 원인은 단순한 소프트웨어 결함(Software Bug)이었고, 충분히 예방할 수 있는 차원의 문제였다. 최종 테스트에서 걸러지기 어려운 유형의 문제로 유닛 테스트 차원에서 해결되었어야 할 문제였다. 무엇보다도 업그레이드가 불가능한 부트로더(Bootloader)에서 발생한 문제였기에 그 파장이 이만저만 큰 것이 아니였다. 모든 비난의 화살이 해당 소프트웨어 모듈의 개발 담당자에게 쏟아졌다. 해당 개발 담당자의 변명은 이전 프로젝트에서 사용한 코드를 재사용했고, 이전에는 전혀 문제가 없었기 때문에 이런 사고가 발생할지 자신도 예측할 수 없었다는 것이었다. 전적으로 그에게만 잘못이 있다고는 말할 수 없다. 그러나 그는 세상에는 동일한 소프트웨어라는 것은 없다는 사실을 간과했으며, 이는 결정적 패착이자 크나큰 오만이었다.

 그리스 신화 테바이의 왕 암피온의 왕비인 니오베는 세상에 남부러울 것 없는 여인이었다. 그녀는 자신이 소유하고 있는 것들에 매우 큰 자부심을 가지고 있었다. 특히 그녀는 자신이 낳은 일곱 명의 아들과 일곱 명의 딸에 대한 자부심에 도취되어 아폴론,아르테미스 두 남매만 낳은 레토 여신보다 자신이 더 위대한 존재라는 오만함에 사로잡힌다. 과도한 오만함은 신의 분노를 부르는 법이다. 결국 분노에 찬 레토 여신은 아들 아폴론에게 니오베의 모든 자식들을 죽일 것을 명한다. 아폴론이 쏜 화살에 일곱 명의 아들들이 차례로 쓰러져 가는 순간에도 니오베는 아직 살아남은 자식들의 수만큼이나 그 오만함을 버리지 못 한다. 결국 나머지 일곱 명의 딸들마저도 모두 잃게 된 니오베는 슬픔을 견디지 못하고 돌로 변하게 된다.

아라크네는 리디아 지방의 여인으로 신기에 가까운 베 짜는 실력을 가지고 있었다. 그녀는 자신의 실력이 직물의 수호신인 아테네 여신보다 뛰어나다고 자부하고 있었고, 그녀의 명성은 올림푸스까지 이르게 된다. 자존심이 상한 아테네 여신은 노파로 변신 후 이라크네에게 접근하여 신에게 도전하는 무모함을 뉘우칠 기회를 준다. 하지만 이라크네의 자부심은 단호히 이를 거절했고 마침내 아테네 여신과 이라크네는 베짜기 최고수를 가리기 위한 빅 매치에 돌입한다. 너무나도 뛰어난 실력과 신에 대한 불경스러운 도전은 아테네 여신을 분노하게 만들었고, 승패는 가려지지 않은채 이라크네는 평생 뒷꽁무니에서 실을 뽑아야 하는 운명을 가진 거미로 변하는 저주를 맞이하게 된다.

 두 이야기 모두 극도의 오만함은 신에 의해 처벌 받는다는 결말을 가지고 있다. 하지만 자세히 들여다 보면 두 이야기는 전혀 다른 관점에서 조명될 수 있다. 니오베는 자신의 소유물에 대한 자만심과 오만함을 가지고 있었는데 반해 아라크네는 자신이 가지고 있는 능력 자체에 대한 오만함이 있었다. 니오베의 오만함은 과거와 기득권에 대한 오만함을 상징하며, 역사학자 토인비가 말한 과거의 성공에 대한 우상화의 오류를 나타내는 의미의 휴브리스(Hubris)와 일치한다. 반면 아라크네의 휴브리스는 예술혼이 절정에 달했던 르네상스 시절, 인간의 한계를 뛰어넘어 신에 이르고자 했던 당시 예술가들의 정신과 혼을 상징한다. 신의 경지에 다다르려는 오만함은 과거를 그 기반으로 하지 않는다. 오로지 스스로의 순수한 능력을 발판으로 바로 지금 현현되는 창조의 에너지로부터 니오는 것이다. 

 많은 소프트웨어 개발자들은 그들이 작성한 코드를 자신의 분신처럼 생각하는 경향이 있다. 그래서 타인이 자신들의 코드나 소프트웨어에 대한 문제점을 지적하면 마치 자신이 비난을 받은 것처럼 대응하는 것을 종종 보게 된다. 그럴때 개발자들에게 니오베의 망령이 깃들어 있는 것처럼 보이기도 한다. 사실 이는 비난받아야 할 일은 아니다. <The Psychology of Computer Programming>의 저자인 와인버그(Weinberg)는 개발자는 코드에 자신의 자아(ego)를 투영해서는 안 된다고 말하지만, 이는 쉽지 않은 일이다. 작가에게 있어 그가 쓴 책이 산고의 고통끝에 나온 자식과도 같은 존재이듯이, 개발자들에게 코드나 소프트웨어와 같은 개발 산출물들은 때론 개인의 혼을 담은 예술작품과도 같다. 하지만 책은 작가의 개성이 존중되고 문법이나 논리의 오류가 대세를 그르치지 않지만, 소프트웨어에 있어서 단순한 논리의 오류는 전체의 파멸을 가져온다. 그리고 그 단순한 논리의 오류 - 소프트웨어 버그(Bug)는 개발자의 오만함에서 비롯된다.

오만함은 곳곳에서 나타난다. 가장 큰 오만은 자신이 짠 코드가 오류가 없을 것이라고 가정하는 것이다, 과거의 프로젝트에서 어떠한 문제도 발생하지 않았다는 이유로, 지금 수행하고 있는 프로젝트를 낙관해서는 안 된다. 동일한 소프트웨어를 재사용하는 경우 이런 낙관의 유혹에 걸려들 확률이 크다. 코드 리뷰에 소홀해지고, 안이한 마음으로 유닛 테스트를 건너뛰는 경우가 비일비재해진다. 서로의 암묵적인 동의 하에 규칙과 프로세스는 그 힘을 잃게 된다. 결국 오만함은 게으름과 나태라는 파멸의 씨앗을 낳는다. 지난날의 성공을 아무런 여과장치 없이 현재의 프로젝트에 적용하는 것은 위험하다. 과거의 성공을 우상화함으로써 스스로를 파멸로 이끄는 오만함을 경계해야 한다. 과거에 탐닉하고 현재를 직시하지 못하는 오만함은 복수의 신 네메시스에게 언제나 좋은 먹잇감이라는 것을 잊어서는 안된다.

 개발자의 진정한 휴브리스는 자신의 불완전함에 대한 인식으로부터 출발하여, 신의 완전함을 추구하는 오만으로 나아가야 한다. 경쟁자는 어제의 나 자신이다. 또한 과거 내가 구현했던 코드와 소프트웨어, 그리고 성공적이였던 프로젝트들이다. 과거의 유산들은 결코 현재의 성공을 보증해주지 않는다. 미래에의 도전은 과거의 불완전함을 인정하고, 이를 개선하려는 노력을 필요로 한다. 리팩토링(Refactoring)으로 재사용코드를 포함하여 개발중인 코드를 개선하는 노력을 지속해야 한다. 그 노력은 개인적인 차원이여서는 안되며, 조직문화로부터 비롯된 것으로 이를 가시적으로 보여줄 수 있는 프로세스 또한 존재해야 한다. 프로젝트의 룰과 프로세스는 모두가 합의한 약속이다. 전사 프로세스를 포함한 모든 업무 프로세스는 그 결함이 드러나지 않는 한 완벽하게 존중되어야 한다. 우라가 신이 아닌 이상 코드리뷰, 유닛테스트를 건너뛰려는 오만함은 버리자. 완전한 소프트웨어(100% bug free software)는 지구상에 존재하지 않는다는 것, 신이 아닌 이상 그런 소프트웨어는 만들어낼 수 없다는 것을 인정해야 한다, 인간의 유한성에 대한 자각으로부터 불멸의 예술작품들이 탄생했듯이, 소프트웨어의 태생적 불완전함으로부터 소프트웨어의 완전함이 만들어지는 역설의 과정을 진정으로 깨달아야 할 때다.






IP *.215.110.24

프로필 이미지
2018.04.29 22:06:12 *.48.44.227

큰 성공을 한 사람만 오만에 빠지는게 아닙디다. 작은 일에서도 자기도 모르는 사이에 상대에게 오만한 태도를 갖는 경우가

얼마나 많은지 몰라요.  참... 성공해도 탈, 실패해도 탈, 밍밍해도 탈, 인생이란 매 순간이 살얼음판 딛는 것 같지요

프로필 이미지
2018.05.02 12:07:59 *.103.3.17

옳은 말씀이십니다!

프로필 이미지
2018.05.01 09:57:36 *.130.115.78
여전히 수퍼 개발자를 꿈꾸는 이들을 위한 마지막 조언? ^^

'책은 작가의 개성이 존중되고 문법이나 논리의 오류가 대세를 그르치지 않지만, 소프트웨어에 있어서 단순한 논리의 오류는 전체의 파멸을 가져온다.'

우리의 포루투스가 수퍼개발자를 너머 작가를 꿈꾸게 된 이유?
프로필 이미지
2018.05.02 12:19:48 *.103.3.17

좋은 조언을 주기 위한 습작 조언 같은 거지요 ㅋㅋ

프로필 이미지
2018.05.02 12:07:24 *.235.100.95

개발자로서의 삶을 살다 잠시 쉬는 중에  다시 관련 글을 보니 속 없이 좋네요 ㅎㅎ

부트로더쪽이라면 효율성보다는 안정성을 더 추구하는 경향이 있고

리뷰시 보수적으로 접근하기에 기존 코드의 재사용율이 높다고 나름 생각합니다.

저 버그를 유발하신분의 억울한 마음도 이해가 되고 그로인해 고생하신 분들의 분노도 이해가 되는 글이네요~~

다만 버그를 발생시키신 분께 직접적인 비난보다는 격려나 오히려 칭찬을 해주면 어떨까 하고 생각해봅니다~^^


덧 : 회사안에서의 알상과 그리스 로마 신화의 내용을 적절하게 연결해주셔서 한호흡에 좌악 읽었습니다^^

프로필 이미지
2018.05.02 12:17:00 *.103.3.17

네, 맞는 말씀입니다. 사실 비난은 아무런 도움이 안되겠지요. 그 친구 아무렇지 않게 회사 잘 다니고 있습니다 ㅋㅋ

지기(知己)를 찾아 머물게 된 변경연에서 같은 업에 계신 분의 댓글을 보니 너무나 반갑네요^^

프로필 이미지
2018.05.02 15:07:36 *.179.207.34
오만함은 누구든 경계해야하는 마음인 것 같아요~
덧글 입력박스
유동형 덧글모듈