똑똑한 개발자를 찾기 위한 인터뷰 전략

나는 오랫동안 많은 개발자 인터뷰에 참석했다. 여러 소프트웨어 회사에서 개발자 인터뷰를 어떻게 진행하는지 들을 수 있는 기회가 있었고 회사의 관계자 대신 면접관으로서 기술 인터뷰를 진행한 경험도 많다. 그래서 소프트웨어 업계에서 개발자 인터뷰를 어떻게 하고 있는지 알 수 있는 기회가 있었다. 

우리나라에서 개발자 인터뷰를 어떻게 진행하는지 보면 해당회사와 직접적으로 관련된 경력을 집중적으로물어본다. 구체적으로 무슨 프로젝트를 어떻게 진행했느냐? 무슨 기술을 다뤄 봤느냐? 이런걸 아느냐? 우연히 면접관이 아는 지식과 유사한 경험을 한 개발자는 재수좋게 시원하게 답변을 할 수있다. 또한 개발자는 경력에 대해서는 자신이 한 것이나 동료가 한 것이나 구분하지 않고 과장되게 설명하곤 한다. 

개발자의 역량보다 동일하거나 유사한 분야의 경험을 더 중시하여 개발자를 채용하는 것은 초단기적으로는회사에 급한 불을 끄는데는 도움이 되지만 중장기적으로는 좋은 전략이 아니다. 이는 마치 부품이 고장나서똑같거나 호환되는 부품을 갈아 끼우겠다는 전략과 별반 다를 바가 없다. 

이렇게 동일 경험 개발자를 선호하다보니 경쟁사 개발자를 데려오기도 하고 동종업계 이직금지 서약을 더욱 중요시 하게 되고 논란도 많다.이러다 보니 여러 분야에 손을 대고 있는 대기업은 어느 중소기업에서 개발자가 오더라도 동일 분야라고 주장을 하면 송사에 휘말릴 우려가 있고 개발자의 이직 자유권을 제한하기도 한다. 동일 분야 개발자를 특히 선호하는 이유는 회사의 개발 문화가 낙후되어 있기 때문이다. 

공유가 안되고 협업이 힘들어서 어느 개발자가 오더라도 능력을 발휘하는데 오래 걸린다. 이런 이유로 동일 경험 개발자 위주로 채용하는 현상은 개발자에게 이직의 범위를 축소시키고 기회를 박탈하게 된다. 소프트웨어 개발자는 자신이 일해왔던 분야 뿐만 아니라 거의 모든 분야에서 일할수 있다. 또 그렇게 일해야한다. 

물론 개발자 스스로가 다른 분야에 거부감이 있는 경우도 있지만 이 또한 환경이 그렇게 만든 측면이 크다. 문제는 회사가 문화적으로 프로세스적으로 준비가 되어 있는가이다. 여러 분야의 개발자가 섞이는 것은 개발자에게 기회의 확대외에도 다양한 경험이 창의적인 아이디어와 혁신에 도움이되어 소프트웨어 산업 전반적으로 꼭 필요하다. 

단기적인 부품교체를 하겠다는 생각이 아니라면 개발자를 채용할때 가장 중요한 것은 회사의 미래 개발에필요한 똑똑한 개발자를 뽑는 것이다. 고급 개발자에게 필요한 것은 3가지가있다. 첫째, 소프트웨어 이론 지식이다. 둘째, 공학적인 경험과 개발 문화적인 소양이다. 고참 개발자에게는 중요한 요소다. 셋째, 가장 중요한 논리적인 두뇌와 수학적인 능력, 그리고창의력이다. 

신입 개발자를 채용하는 경우라면 이중에서 세번째만 집중적으로 봐도 된다. 세번째를 확인할 수 있는 방법은 문제해결(Problem solving)능력을 확인할 수 있는 창의적인 질문과 코딩 테스트(Coding Test)다. 이 두가지로 개발자가 얼마나 논리적이고 수학적인 사고를 하는지, 또 창의적인지 확인할 수 있다. 

동일 분야 경험이 전혀 없더라도 회사가 문화적으로 프로세스적으로 준비가 되어 있다면 1, 2개월후에는 동일 경력만 있는 개발자보다 우수한 능력을 보여줄 수 있고 그 성과의 차이는 시간이 흐를수록 점점 벌어지게된다. 이중에서 코딩 테스트에 대해 좀 더 알아보자. 코딩테스트를 하는 회사가 과거보다 많이 늘었다. 하지만 코딩 테스트의 방향을 못잡고 엉뚱하게 진행하는 회사도 있고 코딩 테스트에 거부감을 가지고 있는 개발자들도 있다. 

사실 코딩 테스트를 한다는 것은 개발자에게 긍정적인 신호일 가능성이 더 높다. 개발자의 역량을 제대로 평가할 줄 알고 그 만큼의 대우가 있을 가능성이 더 높다. 가끔 소프트웨어 회사의 코딩 테스트를 보면 나도 통과하기 힘든 것 같은 문제들이 나오기도 한다. 동일분야의 상세한 경험이 없으면 풀 수 없는 문제가 대표적이다. 동일 분야 동일 경력 개발자를 채용하기 위한 방법으로 코딩 테스트를 사용할 뿐이다. 

이런 회사는 단기적으로 부품을 교체하겠다는 생각이라면 상관이 없지만 그렇지 않고 좋은 개발자를 뽑기 위한 목적이라면 잘못된 방법을 사용하고 있는 것이다. 역사를 배운다고 연도나 줄줄이 외워야 하는 것처럼 이런 것을 물어보는 쪽지 시험과 같은 코딩 테스트는 뛰어난 개발자를 놓치기 쉬운, 좋지 않은 방법이다. 

그런데 지금도 이런 문제들을 갖고 개발자를 채용하고 있는 회사들이 꽤 있다. 이런 현상이 벌어지는 이유는 회사에서 고참 개발자들에게 코딩테스트 준비를 하라고 하면 그 동안 암기식 교육에 익숙해서 이런 문제 밖에 못 내고 인사 담당자는 이를 평가할 능력이 없기 때문이다. 코딩 테스트시 집중적으로 봐야하는 것은 개발자의 논리적인 사고 능력과 문제해결 능력, 창의성이다. 

그러기 위해서 특정분야의 지식을 필요로 하는 문제는 삼가는 것이 좋다. 코딩 테스트에는 대략 5가지 방법이 있다. 아래 방법 중 한 두가지를 선택해서 코딩테스트를 진행한다. 

첫째, 온라인 사이트 코딩 테스트다. 지원자가 너무 많은 경우 정말 자격이 안되는 개발자를 거르기 위한 용도로 사용한다. 인터넷을 검색해 보면 이런 서비스를 제공하는 회사가 많이 있다. 지원한 회사에서 지정한사이트에 등록을 하고 자신이 선호하는 개발언어로 주어진 시간동안 코딩을 하면 된다. 

둘째, 24시간에서 며칠이 소요되는 프로젝트 테스트다. 좀더 가능성이 있는 개발자에게는 첫 번째 온라인 사이트를 이용한 코딩 테스트보다 몇 시간 또는 하루 이틀 걸릴 간단한 코딩 숙제를 주고 1~3일안에 온라인으로 제출을 하게 한다. 

이때는 개발자의 논리적인 사고와 창의력도 보고 코딩 스타일도 보게 된다. C사의 경우 이 코딩 테스트에서 95% 이상의 개발자가 탈락을 한다고 한다. 개발자들이 정말로 가고 싶어하는 유명한 회사가 아니고 이름이 잘 알려지지 않은 중소 소프트웨어 회사라 면이 방법을 사용하기 힘들다. 개발자들이 그냥 귀찮아서 포기할 가능성이 높다. 

셋째, 전화 코딩 테스트다. 전화를 이용해서 코딩 테스트를 하는 방법인데 위 방법보다 좀더 많은 것을 볼 수가 있다. 전화를 통해서 지원자와 대화를 하면서 화면을 공유할 수 있는 방법을 통해서 직접 코딩하는 것을 보면서 코딩 테스트를 진행한다. 

구글 드라이브 문서를 통해서 공유하기도 하고 이와 비슷한 공유가 가능한 온라인 편집기를 사용하기도 한다. 또는 스카이프 등 화면을 공유하는 소프트웨어를 이용하기도 한다. 이런 협업 도구를 통해서 코딩하는것을 직접보면서 면접관은 이런 저런 질문을 하고 개발자는 코딩하는 것을 설명하면서 진행한다. 토론식으로 진행도 가능함으로써 코딩 결과만 보는 것보다는 훨씬 많은 것을 파악할 수가 있다. 지역적으로먼거리에 있는 개발자를 검증하기 위해서 사용할 수 있다. 

넷째, 1~3시간 온사이트 테스트다. 지금까지의 방법은 다른 사람의 도움을 일부 받을 수가 있다. 하지만 온사이트 테스트는 확실히 본인만의 실력으로만 진행해야 한다. 이 방법은 인터뷰전에 혼자서 노트북에 직접코딩을 하는 것이다. 1~3시간안에 풀 수 있는 문제를 주고 컴파일 및 실행이 되도록 직접 코딩을 하는 것이다. 인터뷰시에는 코딩한 결과를 설명할 수 있어야 한다. 이런 테스트는 면접자에게 많은 시간과 부담을 주기 때문에 이에 합당하는 면접 비용을 지불하는 것이 좋다. 

다섯째, 면접관과 함께 하는 칠판 코딩 테스트다. 내가 가장 선호하는 방법은 짧은 시간에 진행하는 칠판 코딩 테스트다. 가장 많은 것을 볼 수 있다. 칠판이라는 특성 때문에 문법은 보지 않는다. Pseudo Code(실행되지 않고 로직만 표현한 소스코드)로 작성을 해도 된다. 코딩결과만 보는 것이 아니라 어떻게 진행하는지더 눈여겨 본다. 

개발자가 문제를 정확하게 이해했는지 면접관에게 물어보는 자세도 중요하게 본다. 일부러 질문을 유도하기 위해서 문제에 질문이 필요한 함정을 넣기도 한다. 이를 질문도 없이 일사천리로 코딩을 해나가면 의심을 해봐야 한다. 

코딩을 하면서 중간 중간에 적절하게 설명하는 자세도 아주 중요하다. 그런데 우리나라 개발자들은 설명없이 그냥 써내려가는 경우가 많다. 평상시에 개발하는 방식이 그대로 반영된다. 이때 면접관이 지적하는 것에 대해서 어떻게 대응하는지도 중요하다. 코딩을 다하고 나면 개선점을 가지고 간단한 토론을 하는 것이 좋다. 이렇게 면접관과 상호작용이 잘 되는 개발자는 나중에 개발시에도 공유 및 커뮤니케이션이 잘될 수 있다. 

이렇게 10~30분동안 진행하는 코딩 테스트는 평소 개발의 축소판이고 창의력, 문제 해결 능력, 커뮤니케이션 능력까지도 볼 수 있는 좋은 수단이다. 실제 인터뷰에서 경력은 화려한데 칠판 코딩 테스트에서 탈락하는 경우가 부지기수다. 기본적인 논리적 사고와 수학적인 능력도 없이 본인이 설명하는 수 많은 프로젝트를 수행했고 높은 연봉을 받은 고참 개발자들을 보면 안타깝기 그지 없다. 

누가 설계를 해야하고 누가 프로그래밍을 해야하는지 구체적인 구분도 없이 고참이고 경력이 많다는 이유로 프로젝트의 설계를 주도하고 망쳐와서 정작 경력이 적더라도 똑똑하고 뛰어난 개발자들이 성장의 기회를 놓치게 된다. 개발자에게 진짜로 필요한것이 무엇인지 생각해보자. 

회사에서 진짜 뛰어난 개발자를 구분할 수 있고 그에합당한 대우를 할 수 있을때 우리 주변에 연봉 수억의 개발자들이 바글바글하게 될 것이다. 그래야 뛰어난두뇌를 가진 사람에게 소프트웨어 개발자는 충분히 매력적인 직업이 될 수 있을 것이다. 그쯤되면 소프트웨어 생태계가 더욱 좋아지고 개발자에게는 롤모델도 생기고 개발자에 대한 전반적인 인식과 대우도 더 좋아질 것으로 확신한다.

美 SW 힘은 평등한 호칭 문화에서 생겼다

필자는 지금까지 소프트웨어 조직에는 수평적이고 자율적인 문화가 필요하다고 했다. 하지만 수직적이고 상명하복 식 조직문화를 없애고 평등한 토론에서 오는 창의적이고 효율적인 개발문화를 만들고 싶어도 넘기 힘든 큰 장애물이 있다. 

바로 '직급'을 부르는 호칭이다. 

한국은 아주 옛날부터 이름 대신 직급을 부르는 것이 전통이다. 부장님, 과장님이라고 불러야지 이름을 부르는 행위는 아주 무례한 것이고 조직문화에서는 용납이 안 되는 행위다. 호칭은 오래 이어져 온 전통이며 쉽게 바꾸지 못하는 고착된 문화다. 

직급을 부르는 호칭은 조직에서 상하관계를 명확하게 하고 상명하복 문화에서 쉽게 벗어나지 못하게 하는 강력한 수단이다. 차장과 부장은 권위의 수준이 다르고 차장에서 부장으로 진급했는데 이를 모르고 차장이라고 부르면 기분 나빠하는 사람도 있고 부르는 사람도 민망해진다. 가끔은 오랜만에 만난 옛날 동료의 직급을 몰라서 뭐라고 불러야 할지 애매한 경우도 많다. 

이런 수직적인 조직문화에서는 '대리'와 '부장'이 어떻게 똑같은 관계에서 평등하게 토론을 할 수 있겠는가? 호칭은 사람에 대한 인식과 사고를 지배하고 알게 모르게 행동과 말하는 것을 통제한다. 

부장의 얘기가 틀렸어도 눈치를 보며 쉽게 지적하기 어렵다. 설령 자신의 생각이 맞는다고 확신해도 위계질서를 무시할 수 없고 괜히 얘기했다가 나중에 불이익을 당하지 않을까 걱정하여 자연스럽게 자기 검열을 하게 된다. 그러다 보니 좋은 아이디어가 있어도 괜히 얘기했다가 일만 많아지고 면박이나 받지 않을까 걱정해서 가만히 있게 된다. 그래서 '가만히 있으면 중간이라도 간다'라는 생각이 지배를 하게 된다. 

복잡도가 소프트웨어보다 낮은 산업들, 특히 전통적인 굴뚝산업에서는 상명하복과 위계질서가 더 효율적인 경우도 많다. 하지만 인류 역사상 가장 복잡한 지식산업이라는 소프트웨어 산업에서는 상명하복으로는 효율적인 개발을 하기 어렵다. 자유로운 사고와 창의력과 혁신이 없이는 살아남기 힘든 소프트웨어 산업에서는 무엇보다도 평등한 토론 문화가 필수적이다. 

전통적으로 직급보다 이름을 부르는 미국이 소프트웨어 강국이 되는데 이런 호칭 문화가 일조를 했다고 생각한다. 신입사원이 사장의 이름을 부를 수 있고 자유롭게 의견을 얘기할 수 있는 토론 문화는 어릴 때부터 훈련이 되어 있다. 물론 모든 회사가 다 그렇다는 것은 아니고 사회 전반적인 문화가 그렇다는 것이다. 

필자는 수평조직 문화를 정착하기 위해서 호칭 문화를 획기적으로 바꾼 몇몇 우리나라 회사를 알고 있다. 

A사는 모든 직원이 서로 '영어이름'을 부른다. 서로 존칭은 하지만 극존칭은 사용하지 않는다. 말단 사원이 최고 경영자인 사장에게 그냥 '빌(Bill)' 또는 '스티브(steve)' 이렇게 부른다. 

문서나 회의록을 작성할 때도 "Bill이 이렇게 말했다"라고 작성을 한다.

수직적인 조직 문화에서 문서에 사장님을 언급할 때 이름을 그냥 쓰기가 몹시 꺼려진다. '사장님'이라고 써야 할지, '홍길동 사장님'이라고 써야 할지 고민이 된다. 이렇게 주제에 집중하지 못하고 신경을 쓰는 것 자체가 호칭에 지배를 받고 영향을 받고 있다는 증거다. 많은 기업은 문서나 대화에서 최고 경영자의 호칭을 CM 등 직급의 약자나 이름의 이니셜을 쓰기도 한다. 여기에는 최고위층 이름은 직접 언급할 수 없다는 금기도 작용하기도 한다. 조선시대에는 왕의 이름에 들어간 한자는 민간에서는 절대로 쓸 수가 없다. 이만큼 우리는 옛날부터 호칭에 민감하다. 

직원들끼리 영어 이름을 부르는 A사는 조직문화가 사뭇 다르다. 호칭 자체가 모든 것을 평등하게 바꾸는 것은 아니지만 평등한 조직문화를 만드는데 일조한다. 

회의나 토론 시간에 위계질서는 없고 자유롭게 발언하며 면박을 주지 않는다. 사장이나 말단 개발자나 똑같은 위치에서 의견을 얘기한다. 제3자가 이 광경을 보고 있으면 누가 사원이고 과장, 부장인지 알 수가 없다. 각자 자신의 전문성과 경험에 기반 하에 자유롭게 의견을 얘기한다. 이런 환경에서 창의적이고 혁신적인 아이디어가 나온다. 

빠른 의사 결정도 장점이다. 회사가 직급에 의해서 돌아가는 것이 아니라 각자의 역할이 있을 뿐이다. 팀장이 있기는 하지만 모든 사람들이 다 평등하다. 자신이 맡은 일이 있을 뿐이다. 결재도 한 두 단계로 끝난다. 길어야 팀장, 사장, 이렇게 두 단계다. 결재판을 들고 돌아다니면서 결재를 받는 경우도 일부 있지만 많은 경우 구두나 이메일로 승인이 떨어진다. 사전에 시스템이나 이메일로 내용이 충분히 공유가 되어 있어서 최종 결정은 신속하다. 

이런 환경에서는 위에서 시키는 일만 하는 수동적인 직원은 매우 적고 능동적이고 자율적인 문화가 퍼져나간다. 나의 위에 줄줄이 상사들이 있어서 시키는 일을 잘하고 눈치를 봐야 하는 상황이 아니고 자신이 알아서 일해야 하는 분위기가 자리를 잡는다. 성과가 안 좋은 것은 자신의 책임이다. 

물론 호칭만 바꾼다고 이런 문화가 저절로 정착되는 것은 아니다. 경영진의 의지가 가장 중요하다. 호칭을 바꾸려는 목적이 무엇인가? 수평적인 문화를 만들기 위한 것이다. 영어이름을 사용하는 호칭 문화는 수평적인 문화를 만들기 위한 강력한 수단 중 하나다. 

하지만 호칭만 바꾸고 권위의식이 여전하다면 별 효과가 없을 것이다. 권위 의식을 타파하고 상명하복 전통을 없애고 자율적이고 수평적인 문화를 만들기 위해서 다각적으로 노력해야 한다. 호칭문화는 그 시작이 될 수 있다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

여자 개발자가 희망이다

소프트웨어 회사를 포함해서 많은 기업들이 개발자가 부족하다고 아우성이다. 이렇게 개발자가 부족하게 된 이유는 열악한 개발 환경에 따른 뛰어난 개발자들의 이탈과 저급개발자 양산 등 여러 환경, 정책적인 문제가 있지만 여자 개발자에 대한 편견과 차별도 주요한 이유라고 본다. 

여자 개발자에 대하여 여러 가지 편견이 있다. 여자 개발자는 실력이 없다, 책임감이 부족하다, 감정적이다, 언제 그만둘지 모른다는 등이다. 하지만 이러한 편견은 남성 중심적인 사고에 기인한 것이 많고, 그 동안의 개발 환경이 야근강요, 코딩 중심, 무모한 프로젝트와 같은 성격을 띄는 경우가 대부분이어서 전투력 강한 개발자를 선호하다 보니 이런 편견이 생긴 것으로 생각한다. 

필자가 경험한 바로는 여자 개발자들이 공유, 협업 문화에 좀더 잘 적응하고 아키텍트로도 더 뛰어난 경우를 많이 보아왔다. 남자, 여자 누가 더 개발자로서 우수하다고 말하는 것이 아니라 서로 다른 특성이 있으므로 이를 이해할 필요가 있다는 것이다. 

뛰어난 소프트웨어는 다양한 특성을 가진 사람들이 모여서 협업을 하고 그 다양성을 기반으로 창의적인 아이디어가 많이 나와야 탄생할 수 있다.

현재 소프트웨어 업계에 여자 개발자가 절대적으로 부족한 이유는 여러 가지가 있겠지만 일단 누구라도 일하기 힘든 환경이 큰 요인이다. 이런 환경에서 상대적으로 남자들이 더 잘 버티기 때문에 더 많이 남아 있다고 생각한다. 

현재의 기형적인 개발자 성비를 개선하는 것이 소프트웨어 업계에는 꼭 필요한 과제이고 이를 위해서는 누구라도 일하기 좋은 환경을 만드는 것이 우선일 것이다. 그러기 위해서 먼저 여자 개발자에 대한 편견과 차별을 없애야 한다. 

많은 회사들에서 크든 작든 여자 개발자에 대한 차별이 존재한다. 비공식적이지만 급여의 차이도 존재하는 회사도 있다. 승진의 기회도 다르다. 이런 이유는 여자 개발자는 결혼하거나 출산을 하면 결국 그만둘 것이라는 선입관이 존재하기 때문이다. 

소프트웨어 업계에서 여자 임원이 절대적으로 부족한 것을 보면 이런 현상을 알 수 있다. 물론, 남자와 여자가 특성적으로 완전히 동일하다고 말할 수는 없다. 차이가 있고 그러하기 때문에 서로 보완이 된다. 필자의 경험과 교육학적인 여러 도서를 보면 선천적, 후천적인 남녀의 차이는 이런 것들이 있다. 물론 필자의 개인적인 생각도 있으므로 의견이 다를 수도 있다. 

우선 남자 개발자들은 도전정신이 강하고 무모한 자산감도 가진 경우가 많다. 치열한 경쟁에 거부감이 좀더 적고, 상대적으로 체력이 뛰어나서 야근에도 잘 버틴다. 남자 개발자가 좀더 코딩을 잘한다는 의견은 입사 이전에 또는 어렸을 때부터 코딩을 경험할 기회가 좀더 남자에 많기 때문이 아닌가 생각된다. 

이러한 남자들의 특성이 현재의 열악한 개발 환경에 좀더 통할 수 있는 측면이 있는건 사실이다. 무리한 일정에 잦은 야근,  협업은 없고 혼자서 달리는 코딩이 현재 흔하게 볼 수 있는 개발 환경이다. 그리고 요즘은 많이 바뀌고 있지만 부어라 마셔라 회식 문화도 상대적으로 남자들에게 더 적합하다. 

그런 반면 여자 개발자들은 커뮤니케이션과 협업에 더 유리한 특성을 가지고 있다. 서로 경쟁하기보다는 서로 도우려는 특성도 있다. 모두 그렇다는 것이 아니고 평균적으로 좀더 그렇다는 의미다. 

남자들은 모른다고 말하는 것을 꺼려하는 경향이 있다. 그래서 끝까지 도움을 받지 않고 혼자서 해결해 보려고 한다. 하지만 여자들은 초기에 도움을 받아야 할 것을 구분해서 적절한 도움을 받는데 익숙하다. 모른다고 말하는 것에 대해서 자존심의 상처를 덜 받는다. 

이것은 소프트웨어 개발 문화 중 협업의 문화에서 매우 중요한 요소다. 혼자서 엉뚱한 방향으로 내달리지 않고 적절할 때 서로 묻고 의논하고 도와야 제대로 된 방향으로 갈 수 있다. 그런 능력이 상대적으로 여자 개발자에게 더 많이 보인다는 것이 필자의 의견이다. 이런 특성에 기인해서 여자 개발자 중에서 아키텍트로서의 능력이 더 뛰어난 경우를 많이 보았다. 

설령 뛰어난 아키텍트 재능을 가진 개발자가 있다고 하더라도 우리나라와 같은 개발 환경에서는 눈에도 잘 안띄고 실력을 발휘하기도 어렵다. 

여자 개발자들에게는 출산과 육아의 장애물이 존재한다. 우리나라에서는 출산과 육아는 개발 경력의 큰 단절이고 2,3년만 단절되면 현업 복귀가 쉽지 않은 분야이기도 하다. 실력적으로는 현업복귀가 가능해도 기업에서 꺼리는 경우도 많다. 

재택근무로도 무리 없이 일할 수 있지만 재택근무를 그렇게 효과적으로 할 수 있는 회사가 그렇게 많지 않은 것이 안타까운 현실이다. 

현재와 같이 여자 개발자들이 꾸준히 일하기 어려운 환경은 여자들에게만 불리한 것이 아니라 모든 개발자에게 불리하며 이런 특성 때문에 개발이 3D 업무라고 불린다. 

경쟁보다는 협업을 하고 혼자 달리기 보다는 공유, 토론, 의논을 적절히 하는 환경, 무모한 일정에 따른 품질 저하와 그에 따른 야근의 악순환 보다는 합리적인 프로젝트, 재택근무를 해도 개발에 전혀 지장이 없는 프로세스, 시스템 그리고 문화, 이런 환경과 문화가 여자 개발자뿐만 아니라 모두에게 필요하다. 지금같이 여자 개발자들이 살아남기 힘든 환경이 계속된다면 소프트웨어 업계 전체가 살아남기 힘들 것이다. 

이글은 ZDNet Korea에 기고한 칼럼입니다. 

외주 SW 개발의 비극

열악한 소프트웨어 외주 개발 문제는 우리나라에서 소프트웨어가 3D 취급을 받는 주요한 원인 중 하나다. 

'갑을병'으로 이어지는 외주도 모자라 '갑을병정무'까지 3,4단계 외주를 주기도 한다. 하청에 재하청이 이어질수록 열악한 댓가와 무리한 일정 그리고 부정확한 요구사항은 외주 개발을 점점 구렁텅이로 내몰고 있다.
소프트웨어 외주 개발 문제를 얘기하면 할 말이 많은 사람들이 꽤 있을 것이다. 필자는 그 중에서 접해 본 사례를 중심으로 소프트웨어 공학과개발 문화적으로 문제점을 지적해보고자 한다.

A사는 새로운 서비스를 시작하면서 서비스 개발을 야심차게 인도에 외주를 줬다가 큰 낭패를 봤다. 

지금도 왜 인도에 외주를 줬는지 궁금하지만 추측컨데 실리콘밸리 외주 형태를 흉내를 낸 것이 아닌가 생각한다. 그런데 인도 개발사는 개발 완료 후 L사에서 기대한 것과 전혀 다른 것을 전달해왔다. 프로토콜도 완전히 다른 것이고 도저히 서비스에 사용할 수 있는 상황이 아니었다. 

이런 일이 벌어진 가장 큰 이유는 스펙을 제대로 전달하지 않았기 때문이다. 인도 개발사에 전달된 스펙은 간단한 기획서 수준이었고 프로토콜도 제대로 언급하지 않았다. 게다가 인도 개발사가 소프트웨어를 완성해서 전달할 때까지 중간에 제대로 점검을 하지 않았다. 

한국 업체 같으면 억지를 부려서 잔금을 안주면서 다시 개발을 강요 했겠지만 인도 개발사는 계약대로 개발을 했고 억지는 통하지 않았다. 잔금을 안줄 수는 없었다. 결국 인도 개발사가 개발한 소프트웨어는 모두 버리고 다급하게 한국업체를 통해서 다시 개발을 했다. 돈은 돈대로 더 들고 서비스도 뒤죽박죽이 되었다. 

B사는 1년이 넘는 꽤 긴 프로젝트를 제대로 된 스펙도 없이 외주를 주고 고치기를 반복한다. 

외주 개발사에는 핵심 기능을 정리한 한 두 페이지 정도의 요구 사항 문서가 전달된다. 외주 개발사는 전체 프로젝트 기간 중 20~30% 정도 기간 안에 소프트웨어를 만들어 보여줘야 한다. 남은 70~80% 기간은 B사의 요구대로 거의 매일 소프트웨어를 수정하고 보여주기를 반복해야 한다.

외주 개발사는 해당 분야의 전문 회사라 이런 부정확한 요구사항으로도 대충 B사가 원하는 것을 이해해 개발할 수 있었다. 개발사의 PM은 수시로 고객사에 불려가 요구사항 변경 회의를 해야 했고 소프트웨어를 계속 고쳐나가기 때문에 아키텍처를 제대로 유지하기가 어려웠다. 

심지어 막판에 요구사항이 크게 바뀌어서 다 버리고 다시 만드는 일도 발생했다. 외주 개발사는 비용도 과도하게 투입해야 하고 프로젝트 관리를 제대로 하기도 어렵다. 하지만 B사가 가장 큰 고객이므로 시키는 대로 할 수 밖에 없었다. B사는 이런 식으로 프로젝트를 진행하는 것을 아직도 당연하게 생각한다.

C사와 D사는 소프트웨어 개발 외주가 제대로 진행이 안돼 외주사 개발자를 회사 내부에 앉혀 놓고 같이 개발하는 형태로 개발을 한다. 

외주 프로젝트지만 옆에서 같이 개발하지 않으면 제대로 개발이 안되기 때문에 같이 일해야 한다. 옆에 앉혀 놓고 개발한다 뿐이지 개발 방식은 다른 외주와 별반 다를 바가 없다. 요구사항은 계속 변하고 애써 작성한 코드를 버리고 고치기를 반복해야 한다. 

외주사도 이런 방식이 비효율적이라서 원하지 않지만 고객사의 우월한 지위를 꺽을 수가 없고 이렇게 일하다 보니 외주 개발 내용 외에 그냥 직원처럼 부림을 당하는 경우가 많이 발생한다. 

D사는 외주를 줬다가 소스코드가 없어져서 소프트웨어를 버려야 했다. 

D사는 소스코드를 받을 수 없는 외주 계약으로 개발을 했다. 처음 몇 년은 유지보수를 잘 했지만 몇 년 후 외주 개발사는 망해서 없어졌다. 그 과정에서 소스코드가 D사로 제대로 전달되지 않아서 최신 소스코드를 찾을 수 없는 상황이 되었다. 결국 외주 개발한 소프트웨어는 모두 버리고 다시 개발해야 하는 상황이 되었다.

E사는 개발자가 해야 할 개발자 테스트를 외주업체에 맡긴다.

개발자는 열심히 코딩만 하고 옆에 앉아서 외주개발자가 기본적인 개발자 테스트를 해준다. 속된 말로 '따까리'라는 말이 적합하다. 비싼 자사 개발자가 너무 바쁘기 때문에 그렇게 한다고는 하지만 자칫하면 잘못된 개발 습관이 쌓일 수 있다. 

또한 이렇게 해서는 코드 품질을 보장하기 어렵다. 완벽한 로직의 코드인지는 개발자 본인이 가장 잘 확인 할 수 있는데 대충 만들고 발견된 문제만 해결하는 방식이 습관화 될 수도 있다. 개발자는 완벽한 소스코드를 적는데 최선을 다해야 하는데 이런 개발자의 의무를 망각하면 프로그래밍은 기초부터 흔들리게 된다. 

위에서 살펴 볼 수 있듯 외주 문제의 주된 원인은 부실한 스펙이다. 모호한 요구사항 정도로 계약을 하게 되니 중간에 요구사항이 계속 바뀌어도 어쩔 수 없고 프로젝트 종료 기준도 모호하여 담당자 맘에 안들면 잔금을 받기도 어렵다. 소송도 종종 일어나지만 시간도 오래 걸리고 소송을 해도 해결하기 쉽지 않다. 고객이 대기업인 경우 소송을 하기도 쉽지 않다. 스펙을 제대로 적는 것은 소프트웨어를 개발하는데 있어서 가장 어려운 일이기 때문에 한마디로 설명할 수는 없다. 

소프트웨어를 직접 개발하지 않고 외주 개발을 하는 주된 이유는 다음과 같다. 직접 개발할 수는 있는데 내부 인력이 부족할 때와 특정 요소기술을 내부에서 보유하고 있지 않을 경우다. 내부에서 개발할 수 없을 만큼 잘 모를 때는 외주를 주기도 어렵다. 모르는 상태에서 대충 외주를 주면 원하는 결과를 얻기도 어렵고 분쟁이 일어나기 쉽다. 

기술력이 뛰어나거나 전문 기술을 가지고 있는 외주 개발사와 협업을 잘하는 것은 소프트웨어 생태계를 만드는데 아주 중요하다. 제대로 외주를 주기 위해서는 고객도 스펙을 제대로 적을 수 있을 만큼 잘 알아야 한다. 

부품 업체 다 망하고 나면 자동차 회사도 망하듯이 수많은 전문 소프트웨어 회사들이 망하고 나면 우리나라 소프트웨어 업계도 망하는 것이당연한 수순이다. 대만이 자전거 산업에서 세계를 호령하는 이유는 자전거 부품회사와 꾸준히 상생을 해와서 대만에는 뛰어난 자전거 부품회사가 많기 때문이다. 그에 비해서 생산비 절감에만 몰두한 우리나라 자전거 산업은 전세계 자전거 산업에서 명함도 못 내밀고 있다. 이미 많은 중소 소프트웨어 회사들이 사라졌거나 고사 상태인 지금 자전거 산업과 비슷한 미래가 예상되는 것은 안타까운 일이 아닐 수 없다. 

이제 와서 말로만 베풀듯이 상생이라고 외치는 것은 들을 때마다 거북하고 막상 그 내용도 해결책의 핵심은 아니다. 우리나라에서 소프트웨어 개발이 3D라는 인식에서 벗어나라면 이런 열악한 외주 환경이 바뀌지 않으면 안된다. 

이글은 ZDNet Korea에 기고한 칼럼입니다.

SW를 을로 취급하는 하드웨어의 무지

필자는 펌웨어를 개발하는 등 하드웨어 팀과 같이 일하는 소프트웨어 개발자를 자주 만난다. 그런데 많은 개발자들이 하드웨어 팀과 일하기 힘들다고 하소연한다. 

회사에서 하드웨어에 더 집중하고 투자하며 소프트웨어는 보조로 생각한다고 말한다. 그렇지 않은 회사도 있지만 많은 회사들이 하드웨어를 더 중요하게 생각하고 소프트웨어는 하드웨어의 부수적인 역할로 생각하곤 한다. 

'소프트웨어' 하면 흔히 데스크톱 소프트웨어나 게임, 모바일앱을 생각한다. 하지만 이런 순수 소프트웨어, 즉 하드웨어에 종속적이지 않은 소프트웨어 비중은 일반인이 생각하는 것만큼 크지 않다. 반대로 하드웨어와 밀접한 관련이 있는 소프트웨어 비중은 의외로 크다.

자동차의 예를 들면 현재 최고급 차량의 생산 원가에서 소프트웨어가 차지하는 비중은 50%에 육박하고 있다. 그리고 2020년이 되면 고가 차량을 넘어 전체 자동차 생산 원가에서 소프트웨어 비중이 50%가 될 것이란 전망도 있다.

과거에 하드웨어로 수행하던 기능이 점점 소프트웨어로 대체되고 있고 그러면서 과거에는 불가능했던 기능이 실현 가능해져서 하드웨어 발전에도 큰 도움이 되고 있다. 

이런 소프트웨어를 펌웨어, 임베디드 소프트웨어라고 한다. 하드웨어와 간접적으로 관련 있는 소프트웨어까지 합치면 그 비율은 어마어마하다. 

이렇게 하드웨어에서도 소프트웨어 비중이 점점 증가하고 있고 하드웨어 자체 성능에도 소프트웨어가 많은 기여를 하고 있는데 이를 다른 측면으로 보면 조만간 하드웨어 경쟁력도 소프트웨어 역량이 좌지우지 하게 될 것이라는 얘기다. 그렇게 될 날이 몇년 남지 않았다. 

즉, 간단하게 얘기해서 앞으로는 소프트웨어를 잘해야 자동차도 잘 만들 수 있다는 얘기다. 

우리나라는 선진국보다 늦게 산업화되었지만 몇몇 분야에서 선진국을 따라잡았거나 앞질렀다. 자동차, 반도체, 선박, 휴대전화, 가전, 디스플레이, 플랜트 등이 그것이다. 하지만 소프트웨어 분야는 소프트웨어 선진국과 비교하여 아직 멀었다고 많은 사람들이 평가하고 있다. 그런데 이제 몇 년 후가 되면 소프트웨어 역량이 하드웨어 경쟁력을 판가름한다니 발등에 떨어진 불이 아닐 수 없다. 

우리나라는 임베디드 소프트웨어 분야에선 선진국에 더욱 뒤졌다.  이런 상황이 지속되면 그나마 따라잡고 앞지른 분야까지 내놔야 할 상황이 될 것이다. 

실제 성공한 하드웨어 중심인 회사에서 소프트웨어를 개발하는 방식을 보면 문제가 많다. 하드웨어 개발팀이 우위를 가지고 소프트웨어 팀은 시키는 대로 개발하는 방식인 경우가 많은데 그런 사례를 한번 살펴보자. 

A사는 하드웨어가 이미 설계된 상태에서 소프트웨어는 거기에 맞춰서 개발해야 한다. 

소프트웨어 개발팀 관점으로 봤을 때 하드웨어 설계에 문제가 있어도 소프트웨어가 우회 방법을 찾든지 해서 재주껏 해결해야 한다. 하드웨어 설계에 소프트웨어 개발자가 제대로 참여를 못해 이런 비효율적인 상황이 벌어진다. 그러나 A사는 하드웨어는 변경이 어렵지만 소프트웨어는 얼마든지 마음대로 변경할 수 있으니 소프트웨어를 하드웨어에 맞춰 개발하고 문제를 해결해야 한다고 한다. 

버그가 발견되면 무조건 소프트웨어 개발팀에서 문제의 원인을 찾아야 하고 하드웨어 문제도 소프트웨어 개발팀에서 해결해야 한다. 그러다보니 문제가 발생하면 욕은 소프트웨어 개발자들이 먹는다. 

기획 단계부터 소프트웨어 개발팀의 의견을 들을 기회조차 없다. 서로 다른 생각을 가진 사람들의 의견이 잘 모아질 때 창의적인 아이디어가 나오는데 하드웨어 중심적인 개발에서는 획기적이고 창의적인 아이디어가 나오지도 않는다.

B사는 모든 개발 일정이 하드웨어에 맞춰져 있다. 하드웨어 개발팀은 소프트웨어 개발팀과 개발 일정을 논의하지도 않는다. 이미 단계 별로 하드웨어 개발 및 양산 일정이 정해져 있으니 소프트웨어는 각 단계 별로 어떤 것은 1주일 어떤 단계에선 3주 안에 하드웨어에 필요한 소프트웨어를 무조건 만들어내야 한다. 

소프트웨어 개발팀은 인터페이스를 맞추거나 에뮬레이터를 통해서 미리 개발을 하고 싶지만 미리 정보를 제공 받지 못해 하드웨어 일정에 맞추느라고 항상 야근에 시달린다. 하드웨어 부서 일정이 바뀌면 소프트웨어 개발 일정도 틀어져서 일정을 조율하기가 매우 어렵다. 

C사는 소프트웨어 개발 프로세스도 하드웨어 개발 프로세스에 맞춰져 있다. 

과거에는 하드웨어를 개발할 때 한 두명의 개발자가 밤세워가며 펌웨어를 만들어주는 방식이었다. 하지만 지금은 소프트웨어 개발자가 엄청나게 늘었다. 그런데도 하드웨어 개발 프로세스에 소프트웨어를 끼워 넣는 방식은 그대로다. 

하드웨어 개발 프로세스에는 있지만 소프트웨어에는 없는 것도 있고 물론 그 반대도 있다. 소프트웨어는 알파, 베타 단계가 있지만 하드웨어는 그렇게 고쳐 나가지 않는다. 하드웨어 개발 프로세스에 억지로 소프트웨어 개발을 끼워 맞추다 보니 매우 비효율적으로 되어 있다. 용어들도 상이해서 이해하기 어렵다. 

지금은 소프트웨어 개발자들도 적응해서 프로세스를 따르고 있지만 여전히 문제가 많은 프로세스임은 명백하다. 

D사의 경우 소프트웨어 기술 책임자가 하드웨어 출신이다. 

이같은 상황은 업계에 안고 있는 가장 큰 문제이기도 하다. 소프트웨어 분야는  전문가가 아니면 정말 이해하기 어렵다. 콜라를 팔던 경영자가 TV 파는 회사의 경영자가 될 수는 있다. 하지만 비즈니스를 아무리 잘 하던 사람도 소프트웨어 조직의 기술 책임자가 될 수는 없다. 불가능하다. 

그런데 많은 회사들의 소프트웨어 부문 CTO(Chief Technical Officer)가 소프트웨어 전문가가 아니거나 CTO가 아예 없는 경우도 많다. 하드웨어 출신이 소프트웨어를 맡기도 하고 소프트웨어 출신이라고 해도 중간에 관리자로 넘어가서 이제는 소프트웨어 엔지니어가 아닌 사람이 CTO를 맡기도 한다. 

경영자에게 불도저 같은 추진력을 요구하는 회사에서 소프트웨어 전문가인 경영자들은 추진력이 부족한 것처럼 보여 많이 밀려 났고 이제는 소프트웨어 조직도 전혀 다른 분야 출신의 불도저 같은 사람이 맡는 경우도 많다. 

그런 경영자들이 추진하는 정책이라고는 고작 끊임없는 야근이다. 단기적인 성과는 날 수 있지만 아키텍처는 엉망이고 개발자들은 지치고 개발 문화는 엉망이 되었다. 소프트웨어는 소프트웨어 전문가가 맡아야 한다. 

기적적인 하드웨어에서의 성공을 회상하며 소프트웨어도 거기에 끼워 맞추려고 하면 큰 착오다. 하드웨어에서 성공했다고 그 방식으로 소프트웨어를 조금만 더 잘하면 될 것 같은 착각에 빠지기도 한다. 소프트웨어는 스타트업을 제외하고는 한두명의 천재가 밤을 세워서 잘 할 수 있는 분야가 아니다. 소프트웨어가 하드웨어의 부속이라는 생각에서 벗어나야 한다. 오히려 소프트웨어가 중심이 되는 시대가 오고 있다. 

그나마 그 동안 이룩했던 우위를 잃지 않으려면 소프트웨어가 '을'의 자리에서 벗어나 하드웨어와 동등한 관계가 만들어져야 한다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

한국 SW가 해외에서 힘 못쓰는 이유

01/02/03은 몇년 몇월 며칠일까? 

우리나라 사람들은 2001년 2월 3일로 읽지만 미국사람들은 2003년 1월 2일로 읽는다. 이것이 다 일까? 호주사람들은 2003년 2월 1일로 읽는다. 이렇듯 나라마다 날짜를 쓰는 방식이 다를 뿐만 아니라 번역, 날짜, 숫자, 화폐, 단수/복수, 어순, 쓰기 방향, 키보드배치, 폰트, 띄어쓰기 여부, 쉼표, 온도, 문장정렬, 이름, 주소, 색깔의 의미, 섬머타임, 종이 크기 등 지역, 언어별로 다른 것들은 수천가지에 이른다. 

이렇게 나라마다 언어마다 다른 특성을 소프트웨어도 각각 다르게 지원해야 한다. 이를 소프트웨어 국제화와 지역화라고 부른다. 하지만 많은 우리나라 소프트웨어는 제대로 된 국제화 전략 없이 개발돼 해외에서 외면받는 일이 많다. 

그 중에는 적당히 넘어갈 수 있는 것도 있지만 많은 항목들이 버그로 보고 된다. 어설프게 개발된 소프트웨어는 고쳐도 고쳐도 끝이 없다. 일단 국제화에 대한 이해를 돕기 위해서 꼭 알아야 할 용어를 알아보자.

첫 번째는 국제화(Internationalization)다. 영어 줄임말로 i18n이라고 한다. ‘i’와 ‘n’사이에 18글자의 알파벳이 있다. 단어가 워낙 길어 이렇게 짧게 줄여서 얘기한다. 소프트웨어를 여러 나라 언어를 지원하기 쉬운 구조로 만드는 것이다. 국제화가 잘된 소프트웨어는 쉽게 여러 나라 언어를 지원할 수 있다. 

두 번째는 지역화(Localization)다. 줄여서 L10n이라고 한다. 소프트웨어를 특정 지역의 언어를 지원하도록 만드는 것이다. 예를 들면 중국어나 일본어를 지원하는 것이다.

소프트웨어 국제화라고 하면 누구나 알 것 같은 용어지만 기술적으로 자세히 들어가면 그렇게 간단하지는 않다. 많은 회사들이 소프트웨어 국제화에 대한 정교한 전략 없이 일단 소프트웨어를 개발해 놓고 국내에서 반응이 좋으면 번역을 해서 해외에 팔면 된다고 생각한다. 국제화를 미리 대비한다고 해도 국제화에 대한 부족한 지식과 경험으로 실제 해외 판매 시 많은 문제를 겪는다.

소프트웨어를 개발해서 많은 나라에 팔기 위한 전략과 기술은 수십 년간 발전해 왔는데, 많은 개발자나 경영자들은 단순히 메뉴 정도만 번역하면 되는 정도로 이해를 하고 국제화에는 별로 투자를 하지 않는다. 우리나라에 소프트웨어 국제화 전문가가 턱없이 부족한 것도 큰 문제다. 

개발자가 수천명인 대기업부터 1인 스타트업까지 우리나라 소프트웨어 회사 중에서 국제화를 제대로 알고  적용하고 있는 회사는 거의 없다고 보면 된다. 문제는 대부분 국제화가 그렇게 어려운 지, 무엇을 해야 하는지 잘 모른다는 것이다. 

의욕만 가지고 되는 것은 아니다. 방대한 지식과 경험이 필요하다. 비주얼스튜디오나 엑스코드(XCode) 등 각 개발 툴에서 제공하는 기본적인 국제화 방법은 그야말로 기초 중에 기초이며 이것만 이용해서 대규모 상업용 소프트웨어의 국제화를 완성할 수는 없다. 그런 것들은 마트의 시식코너 같은 것인데 이것이 전부인줄 알면 오산이다. 

우리가 흔히 알고 있는 글로벌 소프트웨어들은 국제화가 매우 잘 되어 있고 지역화를 통해서 수십, 수백개의 언어를 지원한다. 기술적으로는 지역과 언어를 합친 로케일(locale)을 지원한다고 한다. 

소프트웨어를 처음 개발할 때부터 국제화를 제대로 적용하면 개발비용이 5%만 더 들어간다. 추후 지역화 비용은 각 언어별로 1~2%정도만 더 쓰면 된다.

제품마다 비율은 다르지만 대충 이해를 돕기 위해서 설명하면 그 정도다. 여러 언어를 지원하더라도 개발자들이 특별히 해줘야 할 것은 거의 없고 대부분의 프로세스는 자동화된다. 국제화가 잘 된 소프트웨어는 추가로 몇 개의 언어를 지원하더라도 큰 비용과 시간이 들지 않는다.

하지만 급하다고 또는 무지 때문에 국제화에 대한 전략 없이 그냥 소프트웨어를 개발하면 처음에는 5% 절약은 되겠지만 나중에 여러 언어를 지원하려고 할 때 수십 ~수백배 비용이 더 들어가게 된다. 시간이 흐를수록 비용도 점점 늘어난다. 

물론 나라별 고객의 요구를 무시하면 되지만 그러면 제품 품질은 형편없이 떨어지게 된다. 사례에 따라서 비용 부담의 편차는 다르지만 허술한 국제화에 대한 전략이 미치는 폐해는 엄청나다. 많은 회사들이 어설프게 여러 언어를 지원하다가 포기하거나 결국 실패한 사례는 셀 수 없이 많다. 

그렇지만 소프트웨어 국제화를 처음부터 제대로 적용하기는 쉽지 않다. 소프트웨어 국제화 시 고려해야 할 것이 수백 가지인데 일반 개발자들은 대부분은 들어본 적도 없는 것들이며 들어 봤어도 어떻게 해야 할지 막막한 것들이다. 

소프트웨어 국제화는 관습, 문화적인 것도 이해를 해야 하지만 기술적인 것도 매우 중요하다. 국제화를 위한 수많은 기술이 수십 년간 연구되어 왔는데 이를 다 이해하는 것만도 전문가가 아닌 사람들에게는 벅찬 일이다. 그래서 소프트웨어 국제화 전문가가 필요한 것이다. 

그럼 우리나라 회사들은 어떻게 국제화에 실패했는지 실제 사례를 알아보자.

E사는 초기에 한국어만 지원하도록 소프트웨어를 개발했다. 그런데 일본어 버전이 필요할 때 한국어 버전을 복사해서 번역을 할 경우 한 달이면 일본어 버전을 만들 수 있고 나름대로 국제화를 적용하려면 두 달이 걸린다는 개발자들의 의견에 경영진은 빠른 개발을 선택했다.

한국어와 일본어 버전은 소스코드가 갈라졌고, 매번 개발 시마다 양쪽 소스코드에 각각 기능을 적용했다. 두 소스코드는 점점 달라졌다. 이제는 너무 달라져서 두 소스코드를 다시 합치는 것이 불가능하며 그런 식으로 중국어 버전까지 나오다보니 비효율적인 개발에 따른 고통을 겪고 있다. 

S사는 웹서비스 회사다. 처음에는 국내 사용자만을 대상으로 하는 서비스였는데 몇 년전 해외에도 서비스를 오픈 하려고 했다. 하지만 처음에 서비스를 시작할 때 별 계획 없이 데이터베이스에 자료를 한국어(EUC-KR)로 입력해 놓았다.

전세계 모든 언어를 지원하려면 유니코드로 저장해야 한다. 글로벌 서비스를 위해서 데이터를 유니코드로 변환하려고 했는데 데이터베이스만 변환한다고 될 일은 아니었다. 얽혀 있는 것이 너무 많고 소스코드를 너무 많이 바꿔야 했다. 엄두가 나지 않아 결국 데이터베이스 변환 계획은 포기했다. 

C사는 국내 서비스를 해외 서비스로 확장하기 위해서 해외 버전을 별도로 개발했다. S사와 마찬가지로 별도 개발하는 것이 더 빨리 개발할 수 있는 상황이었다. 

문제는 해외 서비스 오픈 후에 발생했다. 이중으로 작업을 하다가 팀을 나눠서 각각의 서비스를 따로 개발하기 시작했다. 개발은 점점 비효율적으로 변해갔다. 그러느라고 해외 서비스는 제대로 개발도 못하는 상황이 벌어졌다.

A사는 나름대로 연구를 해서 국제화 기능을 구현했다. 각 언어의 메시지를 데이터베이스에 넣어 관리를 하는 방식으로 구현했다. 개발자는 코딩을 하다가 메뉴 등 메시지를 하나 추가하려면 많은 일을 해야해서 부담스럽다. 

메시지를 추가하려면 먼저 엑셀에 해당 메시지를 추가해야 하는데 다른 개발자가 동시 수정하면 충돌이 일어나는 일이 자주 발생했다. 그래서 메시지 관리 담당자를 따로 정해서 관리했다. 그러다보니 관리부담만 늘고 개발자들은 매번 담당자에게 요청하느라 매우 불편해졌다. 

국가별 날짜포맷도 연구해서 직접 개발을 했다. 국제화에 많은 노력을 투자했음에도 A사는 해외 고객들로부터 계속 수많은 국제화 관련 버그를 보고 받고 있다. 

I사도 국제화에 많은 노력을 기울였다. E사 제품은 한국어의 특징을 살려서 제품 유저인터페이스(UI)가 상당히 조밀하다. 한국어는 단어 길이가 짧은 것들이 많다보니 메뉴, 옵션 화면 등을 상당히 빽빽하게 구성됐다.

이런 화면을 영어, 독일어로 변환하다 보니 언어별로 메시지 길이가 천차만별이라서 화면 구성에 애를 먹었다. 결국에 화면을 언어별로 다르게 디자인했는데 그렇게 개발한 후로 개발할 때마다 언어별 화면을 튜닝 하느라고 많은 비용이 들어가고 있다. 

N사는 언어별로 번역을 해서 소프트웨어를 여러 나라에 팔고 있다. 그런데 번역이 잘못되었다는 버그를 많이 보고 받았다. “A의 B”를 변역 해야 했고 A와 B는 다른 단어로 대체 가능한 문장이었다. 

그런데 영어로 번역을 하니 “A of B”처럼 어순이 뒤바뀌어 의미가 달라져 버렸다. 그리고 “사과 2개”를 영어로 번역을 하니 “2 apple”과 같이 복수 처리가 안되었다. 복수 지원을 위해서 복수 메시지 함수를 만들었는데 언어마다 단수, 복수 체계가 다르다는 것을 몰랐다. 지금도 구조적인 번역 오류에 대한 보고는 계속 되고 있다. 

이렇게 여러 실패 사례를 알아 봤는데, 안타까운 것은 지금도 소프트웨어 국제화의 필요성을 인식 못하고 이와 같은 일들이 계속 벌어지고 있다. 해외에 소프트웨어를 팔 계획을 가지고 있고 영원히 영어만 지원하는 소프트웨어를 만들 것이 아니라면 국제화 전문가의 도움을 받아야 한다. 

회사 내부에서 1, 2년만에 전문가를 키우기도 쉽지 않다. 소프트웨어마다 필요한 국제화 수준이 다르기는 하지만 지금처럼 소프트웨어 국제화를 쉽게 생각하다가는 좋은 소프트웨어가 국경과 문화의 장벽에 막혀서 실패하는 일은 계속 될 것이다. 

글로벌 소프트웨어를 개발하는 있어서 소프트웨어 국제화는 선택이 아닌 필수요소임을 알아야 한다. 

이글은 ZDNet Korea에 기고한 칼럼입니다.

고객이 SW를 망친다

우리나라는 고객이 소프트웨어와 개발사를 망치는 경우가 많다. 외국 소프트웨어 회사와는 다른 잣대로 우리 소프트웨어 회사를 대하는 이중성 때문에 우리나라 소프트웨어 회사는 더욱 어려움을 겪는다. 물론 이런 현상이 꼭 고객 탓만은 아니다. 

우리나라 소프트웨어 회사들이 미래는 생각하지 않고 당장 눈앞의 이익만 쫓다 보니 고객들은 여기에 길들여진 측면도 있다.

이렇게 고객이 소프트웨어 환경을 망치고 있는 실제 사례들을 알아보자. 

A사 고객들은 참을성이 없다. 

소프트웨어에 버그가 발견되면 당장 고쳐달라고 막무가내 식으로 요구한다. A사는 팩키지 소프트웨어를 만들기 때문에 개별 고객의 요구사항을 다 들어주지는 않는다. 하지만 이렇게 무리한 요구를 하는 고객이 많기 때문에 당장 고쳐주지 않을 수 없다. 

이렇게 계획되지 않는 급한 수정을 핫픽스(Hotfix)라고 한다. A사는 특정 몇몇 고객 때문에 핫픽스를 과도하게 많이 만드느라 계획된 개발 일정에 지장이 생겼고 소스코드도 지저분해졌다. 

하지만 A사 고객들도 외국 소프트웨어를 사용하면서는 그런 무리한 요구를 하지 않는다. 외국 소프트웨어 회사들은 대부분 그런 요구는 들어주지도 않기 때문이다. 

B사는 소프트웨어 버그로 인해서 개발자가 고객사에 방문 사과를 한적이 있다. 

B사 고객들은 소프트웨어 버그가 발견되면 개발자를 죄인 취급한다. 가끔은 심각한 버그가 발생하면 개발자의 방문사과를 요구한다. 이런 말도 안되는 요구에 B사는 상황을 쉽게 모면해 보려고 개발자에게 고객을 방문해서 사과할 것을 지시했다. 

개발자는 어쩔 수 없이 사과 방문을 했고 개발자로서 회의를 느꼈다. 사실 버그 없는 소프트웨어는 없고 버그가 개발자만의 책임도 아니다. 개발에 참여한 모든 사람의 공동 책임인데 아직도 버그의 모든 책임은 개발자에게 있다고 생각을 하는 경향이 있다. 

자동차를 타면서 문제가 발생하면 자동차 만든 사람이 와서 사과를 하라고 하는 경우는 없다. 개발자에게 버그에 대한 사과를 요구하는 일은 대한민국에서만 벌어지는 현상이 아닐까? 

C사는 개발자들이 고객 옆에서 개발을 해야 한다. 

C사는 솔루션 회사다. 자사 솔루션을 이용해서 고객 요구대로 커스트마이징해서 개발을 해준다. 그런데 주로 고객들은 자사 담당자 옆자리에서 개발을 할 것을 요구한다. 사실 개발자들은 다니는 회사에서 개발하는 것이 훨씬 더 효율적이다. 여러 동료의 도움을 받을 수도 있고 환경도 더 좋다. 

그런데 고객이 방문해서 개발을 할 것을 강력하게 요청하기 때문에 어쩔 수가 없다. 스펙도 정하지 않고 옆에 앉혀 놓고 이러쿵저러쿵내키는대로 요구사항을 말하면서 소프트웨어를 개발한다. 요구사항이 많이 바뀌어서 지우고 다시 만들기를 수없이 반복했다. 

물론 외국 경쟁회사는 이런 요구에 콧방귀도 안뀌기 때문에 C사는 이런 방문 개발 방식을 강점으로 내세워서 국내 시장에서 상당한 성공을 이뤄냈다. 하지만 성장은 한계에 다다랐고 과거의 방식을 버려야 더 점프를 할 수 있다는 것을 알아도 방식을 바꾸기에는 너무 늦어버렸다. 고객보다도 개발자들이 이 방식에 익숙해져서 내부 개발문화를 바꾸지 못하는 것이 더 큰 걸림돌이 되고 있다. 

D사도 고객사에 방문해서 개발을 해야 한다. 

하지만 이유가 약간 다르다. 고객이 보안을 너무 강조하다 보니까 고객사에 방문해서 개발할 수 밖에 없다. 고객사에서 아무것도 가지고 나올 수 없다. 개발은 모두 고객사에서 해야 하고 고객사를 나올 때는 몸밖에 빠져나올 수 밖에 없다. 사실 이 회사도 외국 소프트웨어 회사와는 이렇게 일하지 않는다. 고객의 이중성은 여기서도 드러난다. 

E사는 유지보수 비용을 제대로 받지 못했다. 

E사는 솔루션 회사인데 납품 후에도 지속적인 유지보수 비용이 들어간다. 버그 수정 및 기능 개선이 꾸준히 이루어진다. 하지만 고객은 무상 유지보수를 요구해서 유지보수 비용을 제대로 받지 못한다. 심지어는 버그를 고치는데 왜 돈을 받냐는 주장을 하기도 한다. 

E사의 고객들도 외국의 소프트웨어를 쓸 때는 군말 없이 유지보수 비용을 지불한다. 외국 소프트웨어를 쓸 때는 패키지 소프트웨어라 하더라도 워런티 계약을 따로 한다. 워런티 비용은 소프트웨어마다 다르지만 매년 소프트웨어 구매 비용의 10%~50%를 지불한다. 

1년간 아무런 요청을 하지 않아도 비용은 지불해야 한다. 3년간 워런티 계약을 하지 않다가 4년째 문제가 발생해서 지원을 요청하려면 4년치 워런티 비용을 모두 지불해야 한다. 이렇게 외국의 소프트웨어 회사에는 유지보수 비용을 지불하지만 대한민국의 소프트웨어 회사에는 매우 인색한 것이 현실이다. 

F사 고객이 말도 안되는 문서를 수십 종 요구한다. 

F사는 SI회사다. 대부분은 실제 소프트웨어 개발에 꼭 필요한 문서는 아니다. 단지 고객이 제시하는 방법론에서 필요한 문서일 뿐이다. F사는 실제로는 고객 프로세스대로 소프트웨어를 개발하지도 않는다. 그런 식으로는 소프트웨어를 주어진 시간에 개발할 수 없기 때문이다. 

개발은 그냥 평소대로 하면서 문서만 추가로 따로 만든다. 문서를 반복적으로 만들어내다보니 너무 번거로워서 나중에는 문서를 자동으로 생성하는 프로그램을 만들기도 했다. 이렇게 만들어진 문서는 프로젝트 도중에도 프로젝트 후에도 아무도 보지 않는다. 

그냥 검수를 통과하기 위한 조건일 뿐이고 검수 시에도 소프트웨어와 문서가 일치하는지 확인할 방법도 없다. F사는 고객의 이러한 과도한 문서 요구에 프로젝트 비용이 훨씬 많이 들어가고 정작 개발할 시간이 줄어 들고 있다고 하소연을 하고 있다. 

G사는 패키지를 수정해달라는 고객의 요구로 인해서 회사가 어려워졌다. 

G사 고객들은 패키지 소프트웨어를 바꿔달라는 요구가 많다. G사도 이런 고객의 요구사항에 빠르게 대응하다 보니 소스코드가 여러 벌이 생겼다. 소스코드도 그냥 복사를 해서 고객별로 관리를 해서 시간이 흐를수록 개발 속도는 점점 늦어졌다. 기능 하나를 수정해도 여러 벌의 소스코드에 적용을 해야 했다. 

이렇게 소스코드를 통합(Merge)하는 시간이 점점 길어졌고 나중에는 개발하는 시간보다 소스코드 통합에 더 많은 시간이 소요되었다. 결국 G사는 문을 닫았다. 이는 고객 탓만은 아니고 눈앞의 이익만 쫓는 G사의 무분별한 단기 대응도 문제였다. 

요즘 정부도 민간도 소프트웨어 환경을 개선해보고자 많은 노력을 기울이고 있지만 정작 돈을 내고 있는 고객들은 바뀌지 않고 있다. 물론 고객만의 탓은 아니다. 수십 년간 우리나라 개발회사들에 길들여진 것뿐이다. 

이렇게 소프트웨어 환경이 망가지면 결국 고객들도 손해를 본다. 우리나라 소프트웨어 회사들이 많이 망가지고 나면 제대로 쓸만한 국산 소프트웨어가 줄어들고 울며 겨자먹기 식으로 비싸고 문화도 잘 맞지 않는 외국의 소프트웨어를 써야 한다. 

법으로 바꿀 수 있는 것은 바꿔야 한다. 사실 별 뾰족한 답도 없는 문제지만 결국 고객을 바꾸는 것은 개발사들이다. 계획적인 개발을 하려고 해도 경쟁사에서 고객 밀착형 서비스를 한다고 하면 경쟁에서 밀리고 만다. 

결국 이런 소프트웨어 품질보다 노예식 개발을 장점으로 내세우는 전략은 모두를 다 망치는 일이라는 것을 인식하자. 특히 시장을 주도하는 선두 주자들부터 소프트웨어 환경을 건전하게 바꾸어 나가면 고객의 우리나라 소프트웨어에 대한 이중적인 인식을 바꾸는 것이 불가능하지는 않을 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.