어제 쓰려다 빼먹은 얘기.
킹왕짱 아름다운 알고리즘을 적용한 엄청나게 멋진 프로젝트를 진행하고 있고 완성이 코 앞이라 치자. 나는 그 프로젝트의 핵심 코드를 작성했다. 뿌듯하다. 자랑스럽다.
그런데 멀티스레드 버그가 있어서 1/1000확률로 오동작을 일으킨다.
크래시하는게 아니고 그야말로 오동작을 한다.
여기에 낮은 확률로 heap corruption까지 발생하고 있다면 그야말로 화장실에 휴지가 없는데 물까지 안내려가는 격이다.
….식은 땀이 난다.
경험있는 프로그래머라면 이 상황이 얼마나 지랄같은지 감이 올것이다.
게임 클라이언트라면 그나마 다행인데 온라인 게임 서버라거나 신뢰성이 필요한 DB관련 제품이라든가 하면 미치고 환장할 노릇인거다.
차라리 크래시하면 버그 잡기라도 수월하지. 죽지도 않고 어디선가 오류가 누적되고 있다.
경영자는 대수롭게 생각지 않을 것이다. 항상 발생하는 문제는 아니니까 일단 홍보도 할 수 있고 계약도 따낼수 있다고 생각할것이다.
하지만 이 버그를 잡지 못하면 프로젝트가 망할수도 있다.
이대로 출시하고 이 소프트웨어제품을 많은 사람들이 사용하게 된다면 적어도 1000명에 한명은 문제를 겪게 될것이고 시간이 흐를수록 이 제품과 회사에 대한 불신으로 연결될 것이다.
얼마나 대단한 알고리즘을 적용했던지, 99%의 코드가 그야말로 완벽하다고 자부할만한 코드인지 그런건 중요치 않다.
그 버그 하나 못잡으면 이 프로젝트는 쓰레기가 된다. 출시하고 망하든지 출시도 못할것이다.
내가 이 얘길 왜 하냐면…
많은 프로젝트 리더나 경영자들이 너무 거시적으로만 생각하는 경향이 있다. 여기엔 뭐가 좋고 저기엔 뭐가 좋고 하는 기술들을 착착 붙여서 제품을 만드면 짜잔~ 하고 아름다운 소프트웨어 제품이 나오…면 좋겠지만 안그런 상황이 많다.
문제점을 해결하기 위해서 우주왕복선의 볼트 하나까지 완전 분해해서 원인을 밝혀야하는 상황이 올 수 있다는 얘기다. 의외로 그런 상황은 흔하게 있다. 위에 언급한 버그를 잡기 위해서는 하드웨어에 아주 밀접한 레벨까지 내려가서 어셈코드 한줄까지 싹 뒤집어 엎어서 확인해야 할지도 모른다.
그런데 너무들 안일하게 생각한다.
월급을 받는 프로그래머들이 있다.
그들이 버그를 잡을 것이다.
시간이 지나면 버그는 잡힐것이다.
당신이 고용한 프로그래머는 그 버그를 잡을 역량이 없을지도 모른다.
시간이 지나도 못잡을수도 있다.
요행이든 실력이든 버그를 잡았을땐 이미 당신 프로젝트는 휴지가 된 상황일수도 있다.
스택 오버런 버그 하나만으로 수십억 들어간 온라인 게임이 그냥 휴지 되는 경우가 진짜 있다니까?
물론 MS나 구글이나 애플에는 볼트 하나까지 뜯어서 원인을 밝힐 수 있는 인력과 프로세스가 준비되어있다. 그런 굴지의 회사들 말고 스타트업에서 중견업체 사이에 걸치는 조직들은 어떨까?
구글의 면접대비 책을 읽는것도 좋겠지만. 실제 프로젝트에서 저런 지랄같은 상황을 마주했을때 문제를 처리할 수 있는 역량을 키우는 것이 중요하다고 생각한다. 어셈코드 한줄까지 뜯어봐야할 상황에도 쫄지 않는 강철같은 멘탈과 실제로 대응할 수 있는 기술력이 필요하다.
마치 저격수처럼…
끈기있게 마지막 버그 하나까지 처리해서 제품을 내놓는 끈기와 기술이 중요하다고 말하고 싶다.
그렇게 할 수 있는 사람들이 조직에 꼭 필요하다고 말하고 싶다.
그런데 현실은 별로 그렇지 못하다. 미쿡이라면 모르겠지만 기반기술 인프라가 전혀없고 컨텐츠 위주인 한국의 IT산업이라면 더더욱 그런 인력들이 없다.
이런저런 기술 붙여다가 그럴싸하게 화면에 뭔가 띄워놓기만 하면 ‘우와~ 실력있네~’ 라고 판단하는 분위기가 싫다.
SNS상에서 프로그래머들의 능력을 서로 저울질하거나 심지어 회사 면접 자리에서도 기껏 보는거라곤 면접대비용 책에 나오는 문제를 외웠는지, 남의 기술 잘 갖다붙이는지 보는게 고작이라 그래가지고 볼트 하나까지 분해할 상황에서 어찌 대처하려는지 모르겠다.
뭐…내 얘기 공감하실 분들 얼마 없으리라 예상.
그냥 내 생각이고 사소한 불만이다. 업계 짜증나서 하는 헛소리.
yuchi's development 