개발자 좌절의 순간들 '악몽 톱10'

10. 뜻대로 되지 않는 하드웨어 당연한 얘기지만, 소프트웨어가 잘 작동 하려면 어쨌거나 하드웨어가 있어야 한다. 소프트웨어 개발자들은 하드웨어라는 변수를 잘 간과하곤 하지만, 이내 프로그램 제작 및 디버깅 시 하드웨어와 관련된 문제에 맞닥뜨리게 된다. 소프트웨어 엔지니어를 꿈꾸는 이들에게 우선 코드와 소프트웨어의 기반이 되는 하드웨어와 친숙해 지라고 조언하곤 하는 이유다. 개발자 한마디: “데이터베이스의 충돌를 디버깅 해 본 프로그래머라면, 또는 레이드 드라이브가 어째서 고장 난 것이냐는 하소연을 들어 본 프로그래머라면, 하드웨어 문제가 얼마나 짜증나는지 이해할 것이다.” -Steve Borthwick “프로그래머와 하드웨어는 원래 사이가 안 좋다. 모든 문제를 하드웨어 탓으로 돌릴 수는 없기 때문이다.” -익명

9. 하루 종일 앉아 있기 책상 밑에 트레드밀이라도 설치해 둔 게 아닌 이상, 소프트웨어 개발자의 삶은 유산소 운동과는 영 거리가 멀다. 대부분 프로그래머들의 자세는 의자 끄트머리에 걸쳐 앉아 허리를 구부정하게 구부리고 키보드를 두드리거나 컴퓨터 모니터를 뚫어져라 바라보는 모양세로 굳어져 있다. 이렇게 오래 앉아있다 보면 불편한 게 당연하다. 너무 오랜 시간 한 자리에만 앉아 있다 보면 우울해 지기까지 한다. 개발자 한마디: “하루 종일 의자에 앉아 스크린만 쳐다보고 있어서 인지 이제는 몸 여기저기가 아프기 시작한다. 처음엔 허리가, 그 다음엔 목이 아팠고 눈의 피로감과 두통까지 있다. 나도 모르게 다리를 떤다. 노력을 안 해본 건 아니다. 헬스도 다녀 보고, 요가에 기공에, 자전거 타고 출근도 시도해 보았지만 근무시간 외에 따로 시간을 내는 것이 쉽지는 않다. 해 뜰 때 출근해 해 질 때까지 사무실에 틀어 박혀 살아야 한다.” -Mrkus Toman.

8. 디버깅 아무리 정성 들여, 심혈을 기울여 만든 코드일지라도 버그는 있다. 때문에 개발자의 일과 중 상당 부분이 버그를 찾아내 이를 고치는 일에 투자된다. 쉽게 찾아 고칠 수 있는 버그도 있지만 개중에는 혈압 오르게 할 만큼 찾기 힘들고 짜증나는 버그도 있으며 이런 것 때문에 시간을 낭비하게 되게도 한다. 개발자 한마디: “버그를 찾아내는 것 자체도 힘들지만 최악의 경우는 같은 코드임에도 불구하고 어떤 때는 통합 테스트에 통과하고 어떤 때는 못하는 것이다. 코드 어딘가에 음흉하게 숨어 나올 생각을 안 하는 버그들, 이름만 들어도 소름 돋는다!” -Emmanuel Ngwane. “프로그램이 너무 큰 나머지 디버깅을 하다 보면 너무 깊게 파고들게 되어 나중에 가서는 원래 찾고자 했던 버그가 무엇인지 잊어버릴 때도 있다.” -Ayush Bhatnagar. “코드만 수천 줄을 써야 하는 큰 프로젝트 도중에 발생하는 버그. 오죽하면 눈이라도 덜 아프기 위해 디버깅 할 때 프로젝터를 쓰겠는가.” -Isaac Perez. “버그? ‘하이젠버그’ 한마디면 충분하다고 본다.” -Awal Garg.

7. 부실한 도큐멘테이션 다른 개발자의 코드로 작업하는 일 자체가 쉬운 건 아니지만 적어도 코드에 대한 설명이라도 잘 되어 있다면 괜찮다. 불행히도, 항상 그런 건 아니다. 제대로 된 설명이 없는 코드를 디버깅 하고, 소프트웨어와 통합하는 일은 훨씬 더 많은 시간이 걸린다. 급상승하는 혈압은 덤이다. 개발자 한마디: “설명이 부족한 소프트웨어 작업을 할 때 가장 힘들다. 프로젝트를 넘겨 받는 사람에 대한 배려가 부족하다고 생각한다. 코멘트도 없고, 의미론적으로 부족한 점이 많은데다, 버그와 에러까지 곳곳에서 발견되는 코드를 넘겨받으면 정말 괴롭다.” -Angel Angeles III. “일할 때 힘든 점? 설명도 코멘트도 없는 코드를 받아들 때가 아닐까?” -Abhishek Chauhan. “대부분 프로그래머들이 그렇겠지만, 나 역시 새 코드를 쓰기보다 설명이 불친절한 코드를 고쳐 쓰는데 더 많은 시간을 허비한다.” -Walt Karas.

6. 코드 병합 깃(Git)이나 서브버전(Subversion)같은 소스 코드 컨트롤 시스템은 다수의 개발자들이 한 코드에 동시에 작업할 수 있게 도와주는 유용한 툴이다. 하지만 둘 이상의 개발자가 똑같은 파일이나 루틴을 변경했다거나 하는 이유로 코드 저장소에 코드를 저장하는 시점에 문제가 생길 수 있다. 이 경우 변경 사항을 하나로 병합해야 한다. 이 과정은 간단하게 될 때도 있지만 그렇지 않을 때도 있다. 개발자 한마디: “개인적으로 코드 병합 과정이 불편하다. 나는 이렇게 바꾸고 싶은데, 상대방은 다르게 바꾸고 싶어하는 그런 상황들이 있게 마련이니까. 지금까지는 의견 차를 모두 수용할 수 있는 방법들을 용케 찾아왔지만, 그게 어려운 경우 꽤 어색한 상황이 연출될 수도 있다.” -Jessica Su. “병합 과정에서의 충돌이야말로 개발자의 악몽이다.” -Koustuv Sinha.

5. 비현실적인 기대치 사실 소프트웨어 개발자들은 다들 꽤 똑똑한 사람들이다. 그들의 불행은 여기서 시작된다. 상사, 프로젝트 매니저, 영업 담당자 등 모든 이들이 프로그래머에 대해서 만큼은 비현실적일 정도로 높은 기대치를 갖기 때문이다. 말도 안되게 짧은 시간 안에 말도 안될 정도의 하이 퀄리티 결과물을 내놓을 수 있을 거라 생각하는 것이다. 때문에 오늘도 개발자는 야근을 하고, 코더의 행복 지수는 바닥을 뚫고 하강 중이다. 개발자 한마디: “제일 힘든 일은 내가 마법사가 아니라는 걸, 나도 모르는 게 있다는 걸, 내게 주워진 툴로 한정된 시간 안에 이뤄낼 수 있는 성과물에는 물리적 한계가 있다는 걸 사람들에게 이해시키는 일이다. 게다가 이 모든 것들을 프로그래밍의 프 자도 모르고 알고 싶어 하지도 않는 이들에게 설명해야 한다.” -Mark Miller. “상사가 나와 동료들에 대해 갖는 기대치는 높디 높은데, 현실은 그 기대에 비슷하게라도 부응할 시간이나 자원이 부족하다.” -Kevin Sekin. “프로젝트 매니저와 비즈니스 애널리스트는 클라이언트에게 달을 따다 주겠다고 약속하지만, 그 달을 따기 위해 사다리를 오르는 건 프로그래머들이다.” -Ratnakar Sadasyula. “처음엔 우리가 평범한 대화를 나누고 있는 줄 알았다. 그쪽에서 컴퓨터 과학이 몇 십 년 진보한 후에나 꿈꿀 수 있을 만한 기능을 아무렇지도 않게 요청해 오기 전까지는 말이다.” -Vladislav Zorov.

4. 다른 개발자가 내 코드를 망칠 때 각기 다른 개발자들이 쓴 코드가 함께 쓰이는 것은 그리 드문 일이 아니다. 소프트웨어나 서드파티 라이브러리, 툴, 애플리케이션 등, 어떤 작업을 할 때에도 여러 명의 개발자가 쓴 코드를 함께 쓰게 된다. 그러나 불행히도 그 과정에서 누군가는, 급한 와중에 정신이 없어서, 아니면 커뮤니케이션이 잘 되지 않아서, 혹은 단순히 부주의함 때문에 다른 프로그래머의 코드를 망치는 일이 발생하곤 하는데, 그렇게 되면 팽팽한 신경전과 스트레스, 짜증은 덤으로 따라온다. 개발자 한마디: “개인적으로 최악의 경험은 함께 작업하던 사람이 나에게 말도 하지 않고 멋대로 라이브러리를 바꿔버렸을 때였다. 최악의 경우 액세스 할 수 없는 라이브러리에서 코드가 충돌되는 일까지 생길 수 있었다.” -Sheri Fresonke Harper. “다른 사람이 자신의 코드를 변경하는 바람에 내 코드가 이상해질 때. 심지어는 코드가 완전히 없어져 버리거나 다른 파일에 가있기도 하다.” -Jessica Su. “테스트도 해보지 않았거나 테스트 결과를 무시한 누군가가, 상의도 없이 전체 시스템에 변화를 주는 바람에 불과 며칠 전 해 놓은 일을 다시 해야만 할 때. 그리고 내가 듣게 되는 첫 마디가 ‘코드가 깨졌어’ 일 때.” -Simon Hayes.

3. 이 직업에 대한 오해의 순간 소프트웨어 개발자의 수도 많아지고 있고, 생활의 많은 부분을 소프트웨어가 차지하고 있음에도 불구하고 아직도 많은 사람들은 소프트웨어 개발자가 무엇을 하는지 잘 모른다. 테크놀로지에 대해 잘 모르는 사람들이 볼 때 개발자들은 그저 ‘기술자’ 들일 뿐이며 소프트웨어 기술자든 하드웨어 기술자든 크게 차이가 없다고 생각한다. 이처럼 소프트웨어 개발자라는 직업에 대한 무지와 오해, 특히 친구나 가족들의 오해는 개발자를 슬프게 한다. 개발자 한마디:“사람들은 프로그래머가 컴퓨터로 일하는 사람이니, 컴퓨터를 고칠 줄도 알 거라고 생각하는 것 같다. 젠슨 버튼이 F1 자동차를 운전한다고 해서 그 차를 조립, 수리할 줄도 안다는 건 아닌데도 말이다.” -Steve Borthwick. “내가 코드를 써서 월급 받는 건 맞지만, 프린터는 고칠 줄 모른다. 왜 첨부파일이 안 열리는지, 왜 노트북이 부팅이 안 되는지도 나는 모른다. 아 물론, 밥이나 술이라도 한끼 사주면서 물어본다면 생각이 날 지도 모르겠다.” -Phil Johnson. “나는 해적판 OS나 기타 다른 소프트웨어를 설치해주는 사람이 아니다.” -Anbalagan Jeyabalachandran. “우리 가족, 친구들은 내가 컴퓨터와 관련된 건 뭐든지 다 고칠 수 있다고 생각한다. 하드웨어든, 소프트웨어든 말이다. 거기서 못한다고 한마디라도 했다간, 다음과 같은 핀잔을 듣게 된다. ‘DVD-ROM도 못 고치면 그게 어떻게 소프트웨어 엔지니어야?’라고.” -Jazib Babar. “내가 진짜 무슨 일을 하는지 아는 사람은 100명중 한두 명 될까다.” -Yasin Peksen.

2. 시간 부족 다른 모든 것들이 그렇듯, 좋은 소프트웨어 역시 만드는 데 시간이 걸린다. 그러나, 역시 다른 모든 경우에도 그렇듯, 상사나 클라이언트는 이상적 솔루션이 나올 때까지 기다려주지 않는다. 때문에 소프트웨어 개발자들은 언제나 결과물을 내놓기 위해 쫓기게 되고, 형편 없는 핵, 코드 설명 부족 등 여러 가지 문제를 발생시키게 되며, 이런 문제들은 향후에 또 다른 문제들을 낳게 되어 결국 그 코드를 사용해야 하는 프로그래머들까지 괴롭게 한다. 개발자 한마디: “마음 같아선 정말 정성을 들여 일하고 싶다. 그렇지만 그보다는 빠른 시간 안에, 친숙한 결과물을 내놓기를 바라는 압박을 받는다. 물론 그렇게 해야만 할 때도 있지만, 지금 프로그래밍 및 비즈니스 문화 자체가 너무 그쪽으로 치우쳐 있는 건 아닌가 생각할 때도 있다.” -Tikhon Jelvis. “시간에 쫓기는 게 가장 힘들다. 스스로도 잘 쓰지 못한 코드란 걸 알면서도, 더 세련되게 할 수 있었음에도 어쩔 수 없이 시간에 쫓겨 사용하게 되는 코드가 있다.” -Gene Sewell. “내가 하는 일이 훌륭한 프로그래밍과는 거리가 멀다는 걸 알면서도 퀄리티보다 속도가 중요하기 때문에 결국 상대방이 원하는 대로 해줘야 할 때 힘들다.” -Jose Palala. “참 이상한 일이다. 급하게 만든 조잡한 솔루션을 계속해서 바로잡는데 쓸 시간과 돈을 차라리 처음부터 제대로 솔루션을 만드는 데 쓸 수도 있지 않을까?” -Romi Awasthy.

1. 다른 개발자의 코드로 작업 개발자라면 다른 사람이 쓴 코드로도 작업을 해야 한다. 전임자에게 받은 레거시 코드이건, 써드 파티 API이건, 아니면 컨설턴트가 쓴 코드이건, 어쨌든 누군가가 쓴 코드를 수정하고, 통합하는 일은 피할 수 없다. 그리고 당연한 말이지만, 그 작업은 가뜩이나 모자란 개발자의 머리를 또 쥐어 뜯게 만들 것이다. 개발자 한마디:“다른 사람이 쓴 코드를 읽고, 디버그 하고, 고치는 것이 가장 힘들다. 특히 전임자가 회사를 떠났고 아무런 정보나 언급도 없이 그 사람의 코드를 내가 받았을 때는 정말 힘들다.” -Ratnakar Sadasyula “아무런 코멘트도 없는 코드 수천 줄을 해독하려 애써 봤는가?” -Simon Zhu. “컨설턴트가 쓴 끔찍한 코드 때문에 고생한 적도 있었다.” -Joe Samson. “써드파티 API도 만만치 않다. 써드파티 API를 사용하다 보면 문제가 있거나 새 기능이 필요할 때가 있는데 해당 문제를 고칠 수 있는 소스가 없는 경우 API 저자에게 부탁하고 선처를 바랄 수밖에 없다.” -Kevin Sekin. “언어 및 프레임워크 버그가 제일 짜증난다. 며칠 동안 머리를 쥐어 뜯으며 코드에 무슨 문제가 있는가 고민했는데, 결국 언어나 프레임워크상의 버그 때문임이 발견될 때 말이다.” -John Paul Alcala. “코드 쓰는 역량이 미숙한 사람이 써 놓은 코드로 작업을 해야 할 때 정말 괴롭다.” -Nani Tatiana Isobel.