IT 경진대회 심사위원이 전하는 주의사항

밑장 빼다 걸리면 손목아지 날아간다

이 내용은 작년에 한 앱 경진대회 심사위원으로 가서 실제로 겪은 일이다. 조별로 자신들이 개발한 앱을 발표하는 자리에서 한 대학원생 개발자가 앱에 대한 설명을 시작하였다.

"저는 개발자입니다. 우리 팀에서 만든 앱은 제가 직접 C#언어를 이용해 만든 웹 서버와 연동하였고, 클라우드 올리고 L4 스위치를 사용해서 20만 동접은 거뜬히 버팁니다."

이 설명을 듣고 다섯 명의 심사위원들이 동시에 어처구니없다는 표정을 지었는데, 대표로 필자가 발표를 진행한 개발자에게 질문하였다.

첫 번째 질문 : 당신이 C#으로 만들었다는 웹 서버가 전 세계에서 사용하고 있는 아파치 서버보다 퍼포먼스가 높은가? 안정성이 뛰어난가? 앱 만들 시간에 웹 서버는 대체 왜 만들었나? 두 번째 질문 : 클라우드에 올린다면서 L4 스위치는 어디에 사용하는가? 세 번째 질문 : 처음부터 20만 동접이 필요한 이유가 무엇인가?

예상대로 세 가지 질문에 하나도 대답하지 못하였다. 웹 서버를 만들어 쓴다는 이야기는 MS 워드를 두고 워드프로세서를 만들어 쓴다거나 포토샵을 놔두고 사진 편집 프로그램을 만들어 쓴다는 이야기나 다름이 없다. 두 번째 질문인 클라우드는 VM을 통해 오토스케일링을 해서 트래픽이 늘어나면 VM숫자를 늘리면 되고, ELB가 제공되기 때문에 L4가 사용될 곳이 없다. 세 번째 질문인 20만 동접이 일어나려면 (인기 앱이라는 가정하에) 아마 안돼도 500~1천만 개의 다운로드가 깔려 있어야 가능한 수치이다. 처음에 앱을 만들어 올리면 1천 개 다운로드하기도 어렵다.

저렇게 설명할 수 있는 이유는 본인이 무지해서 잘 알지도 못하지만 뭔가 주워들은 이야기를 나열하면 실력 있어 보일 거라는 블러핑이거나, 잘 알고 그랬다면 심사위원들이 잘 몰라서 속아 넘어갈 거라는 의도에서 한 것이다. 둘 중 어떤 케이스이건 결론적으로는 심사위원들을 속이려는 것이다.

보통 심사위원들은 5명 이상의 복수로 진행되는데, 이 바닥에서 긴 세월 동안 산전/수전/공중전을 다 겪는 사람들이다. 운 좋고 실력이 있다면 한 두 명은 속일 수 있을지 몰라도 심사위원 전체를 속일 수는 없다. 심지어 이 질문들을 개발자에게 한 필자는 개발자 출신도 아니고 기획자 출신이다. 장담하는데 심사위원들을 한 두 명 속일 수 있는 정도의 실력이라면 자신이 만든 앱이 이미 1천만 개 이상 다운로드되어 이미 돈을 잘 벌고 있는 개발자이거나 국내나 외국의 유수한 IT기업에 스카우트되어 이런 앱 경진대회에 나올 이유가 전혀 없을 것이다.

  

또 다른 한 가지 주의할 점은 너무 IT 트렌드에 뒤쳐진 용어는 사용하지 말아야 한다. 특히 유비쿼터스와 원소스 멀티유즈(One Source Multi Use)를 많이들 사용하는데 IT 업계에서 사라진 지 벌써 10년도 넘은 단어이다. (오직 공공 쪽에서 아직도 U~ 를 사용하기는 한다.)

유비쿼터스의 어원이 분명 MIT에서 나온 단어는 맞는데 실제로 외국업계에서는 처음부터 거의 사용되지 않은 학술용어인데 어쩌다 1990년대 말~2000년대 초 한국의 대학과 관 중심으로 유행하는 바람에 현재에 이르고 있다. 이런 단어들을 사용해서 설명을 하면 학구적으로 보이는 것이 아니라 시대에 뒤떨어져 보인다.

심사위원들이 권위적이어서 잘난 체하는 것을 싫어하는 것이 아니다. 다만 실력이 없는데 잘난 척하거나 아는 척하는 경우 점수가 바닥에 깔리게 된다. 그 실력 차이를 분명하게 알고 있는 사람들이기에 실력 있는 척하는 게 아니라 실력이 있다고 감점당하는 일은 거의 없다. 실제로 똑똑하고 실력 있는 학생들은 오히려 아주 좋아하고 높은 점수를 준다. 채점은 각 심사위원들이 개개인 별로 채점을 하는데 전체 채점이 끝나고 각자 매긴 채점 순위를 비교해 보면 전 심사위원의 채점 결과가 거의 편차가 없다.

물론 이런 심사 시스템에도 약점은 존재한다. 유사한 여러 앱 경진대회나 창업 경진대회가 있고 각 심사위원은 전부 다른 사람들이기에 한 곳에서 수상한 개발자나 팀이 비슷한 아이템을 가지고 여러 곳을 돌아다니면서 수상하는 경우가 있다. 수상팀 역시 여러 번 경진대회 경험을 쌓다 보니 요령도 생기고 심사위원들이 원하는 게 무엇인지 경험적으로 체득하기 때문에 가능한 일이다. 하지만 이런 것도 몇 번 하다 보면 아이템 자체를 바꾸는데 한계가 있고, 같은 심사위원을 다른 대회에서 다시 만나는 수가 있어서 그리 많이 할 수는 없다.

오늘 칼럼은 여러 IT 관련 경진대회에 심사위원으로 평가하면서 느낀 '절대 하지 말아야 할 사항'이다. 나중에 다른 칼럼에서는 IT 관련 경진대회에서 어떻게 하면 좋은 결과를 낼 수 있는지에 대한 이야기를 할 예정이다. 내년에는 많은 창업팀들이 경진대회에서 좋은 결실들을 거둘 수 있기를 기대한다.