꼭 그래야만 하는 이유.
얼마전 IT 인력 채용에 관한 컨설팅(?) 같은 것들을 해드린 적이 있습니다. 사람을 뽑는 것, 그리고 기존의 가용 인력들과 커뮤니케이션 하는 것 들에 관한 것이 컨설팅의 주요 이슈였습니다.
마침 이 글을 보니 몇가지 생각나는 점이 있어서 정리해 봅니다.
컨설팅을 해드렸던(몇가지 이야기를 들어드리고 의견 제시 해드린 게 전부였지만?..) 팀장님의 의견을 요약해보면 이런겁니다.
IT 바닥에 Coder는 많은데 처음부터 Software를 Design할 Programmer는 적은 것 같다.
사실 Coder를 거치지 않는 Programmer, Architect는 존재하지 않는다고 봐도 무방합니다. 기본적인 Code에 대한 이해를 가지지 않고 그 일을 한다는 건(현실에서 ‘종종’ 있는 일입니다만..) 배재하고 이야기 해보겠습니다.
Coder와 Programmer, Architect의 차이는 뭘까요? 남들 모르는 몇가지 알고리즘을 더 아는 것? 남들 모르는 지식 몇가지를 더 알고 있는 것? 그런 사소한 차이는 같은 Coder,Programmer 사이에 비일비재한 일입니다. 그런 것들로 Coder, Programmer, Architect 는 구분되지 않습니다.
그럼 (나름)구분 할 방법은 무엇일까요? 아니 사람들은 대체!! 어떤 기준으로 너는 Coder, 나는 Programmer! 이런 이야기를 하는 걸까요? 사실 저도 잘 모르겠습니다만… 위의 컨설팅 과정 중에 나온 여러가지 이야기들과 그간의 사람들과 대화를 나누며 격어본 경험들에 비추어 (여러가지로 표현가능하지만) 문제 인식의 차이라고 표현하고 싶습니다.
작으마한 회사에서 업무를 볼 때 일입니다. 운영중인 웹 사이트(이걸 하나의 큰 Software로 보겠습니다.)중 일부 서비스에 접근이 되지 않는다고 운영팀에서 연락이 왔습니다. 제 밑에 있는 Coder(급의 업무를 하고 계신)분은 IDC로 달려갈 준비를 하셨고, 팀장님은 장애보고서를 쓸 준비를 하셨죠. 이제 나름 Programmer급 업무를 하시는 분들은 신나게(?) 문제점을 찾아봅니다. 지금까지 Update한 Code부터 Server의 상태 점검, Network의 Traffic까지 쭈욱 흩어보았습니다. 결론은 Login Server가 구형이라 부하를 견디지 못하고 Shutdown이 되어서 Login기능과 관련된 대부분의 기능이 동작하지 않게 되었습니다. 오래 운영된 (제대로는…아니더라도) 대형 사이트라면 한번즈음 있을 법한 일이기도 합니다. 하지만 여기서 문제를 인식하는 서로의 태도는 꽤나 큰 차이가 있었습니다. 여러분이라면 어떻게 이 문제를 해결하시겠습니까? 한동안은 Server를 주기적으로 Rebooting 시켰습니다.(헉!) 그래도 문제가 해결되지 않자 Login Server의 각 Module을 최적화 시켜 다시 Restart 했습니다. 그런다고 해결되면 이야기가 재미없죠. 최종안은 Server 장비를 (나름) 최신의 장비로 교체했습니다. 그 후론 Login Server가 죽는 일이 거의(가끔 SSL코드 문제로 죽는 걸 제외하면..) 발생하지 않았습니다.
여기서 저는 인식의 차이를 느꼈습니다. Server를 주기적으로 Rebooting거나, 각 부분을 최적화 시키는 일은 Coder의 인식 수준이라고 생각합니다. 당장 직면한 문제를 해결해야 하는 것이죠. Server 장비를 바꾼 건 Programmer의 인식수준입니다. 사실은 Login 방식을 바꾸거나 관련된 Code를 안전하게 Refactoring하는 것도 하나의 안건이였습니다만…, System의 한계(문제)점을 인지하고 그 구조를 고쳐야 한다는 관점에서 문제를 인식하는 것입니다. 그럼 Architect의 관점은? Login Process 자체를 분석해 보고, 더 나은 기술과 현 시점에서 가능한가장 효과/효율적인 방법에 대해 생각하려고 하지 않을까요?(사실 이건 제가 Architect 급이 아니라 명확히 이야기 하긴 힘듭니다만 비지니스 로직, 마케팅 관점 어쩌구 하는 것보다는 솔직한게 좋자나요?) 저런 사태(?)를 몇 번(아이고~) 격다보니 같은 팀의 구성원들 간에도 분명한 인식 차이가 있었습니다.
이런 인식의 차이를 인지하고 나니 각 팀원들의 업무태도에 대해서 조금씩 이해가 되기 시작했습니다. 왜 저 분은 일을 저렇게 할까, 저 문제에서 중요한 건 그게 아닌 것 같은데… 라는 생각과 함께 스스로도 되돌아보게 되었습니다.(참 잘못하고 있는게 많더군요.)
이런 인식의 차이는 서로간의 의사소통, 개인적인 노력등으로 어느정도 좁혀지긴 했습니다. 그럼 저런 인식의 차이를 만들어 내는 것은 도대체 무엇일까요? 이런 인식의 차이를 줄이기 위해 팀원들 끼리 이런 저런 이야기를 나누는 도중 서로가 결론 낸 것은 기본기였습니다.
그럼 IT에 있어 기본기란 뭔가? 전산을 모두가 전공해야 하나? 그런건 아닙니다. 저도 전산 전공인데 기본기가….형편없어서 많이 고생했습니다. 하지만 전산학 커리큘럼에 있는 내용들은 기본기로 삼아야 할 내용이 아닐까 생각합니다. 도무지 이딴걸 왜 하는지 모를 것 같은 과목들, 프로그래밍 언어 다시 한번 실습하는 것만으로 느껴지는 Data Structure, Algorithm, 잠 오기만 하는 Database, 단순 암기만 하게되는 Software 공학과 Programming Language, 실전에선 써먹지도 못할 것 같은 Object Oriented, 난 Programming만 할껀데 이런건 왜 배우나 싶은 System Architect, 생각만해도 토나오는 OS와 Compiler. 이런 것들에 대한 광범위한 지식 습득과 끊임없는 공부가 기본기를 만들어 내는 것 같습니다.(너무 당연하다 싶은 말만 하는 것 같군요..)
생각해보면 이런 Coder와 Programmer, Architect간의 괴리가 발생하게 된 근본원인은 뭘까요? 아마도 한국 IT업계의 구조적인 문제(말도 안되는 일정, 기획자가 대충 던져주는 설계, 그나마도 ‘갑’님께서 원하시면 자주 바뀌는 망할 놈의 설계, 가르쳐주지는 않고 어떻게든 해내라고 닥달하는 풍토) 탓으로만 돌려도 괜찮은 걸까요?
아까 맨위의 컨설팅 이야기로 돌아가서,
왜 Programmer가 Design을 먼저하지 않고 Coding을 먼저하는 걸까?
라는 질문을 팀장님께서 저에게 던지셨을 때, 저 또한 당연히(그리고 습관적으로) 한국 IT업계의 구조적인 문제 어쩌구저쩌구~를 이야기 했습니다. 그리고 그런 인식 차이를 위해 서로 의사소통하는 방법 몇가지를 제안해 드렸습니다.
하지만 그 전에 개발자(저도 포함) 스스로에게 한 번 물어보는 건 어떨까요?