진짜 비대면 업무 방식 vs 가짜 비대면 업무 방식

 최근 코로나 19 때문에 비대면 업무 방식으로 전환이 강하게 요구되고 있다. 그러면서 비대면 업무 방식을 많이 추진하고 있는데, 가짜 비대면 업무를 하고 있는 회사도 많다.

비대면 업무 방식은 생산성이 높기 때문에 코로나 19가 아니더라도 도입이 권장된다. 그러면 진짜 비대면 방식으로 일하고 있는지, 가짜 비대면 방식으로 일하고 있는지 9가지 지표로 알아보자. 

툴, 시스템

재택근무를 도와주는 솔루션만 도입했다고 진짜 비대면 업무를 하는 것이 아니다. 

가짜 비대면 업무를 하는 회사는 몇 가지 특징이 있다. 완전한 비대면 업무 방식으로 일하기 위해서 필요한 시스템과 툴을 충분히 도입하지 않아서 여기 저기 구멍이 있는 경우다. 그래서 수시로 메신저나 이메일로 업무를 물어봐 가면서 처리하고 시스템을 따라 업무가 유기적으로 진행되지 않는다. 

또, 부서마다 사용하는 툴이 다른 경우도 있다. 진짜 비대면 업무를 하기 위해서 가장 중요한 시스템이 이슈 관리 시스템인데, 이것을 부서마다 다른 것을 쓰거나 일부 부서만 사용하는 경우다. 그러면 업무 협조 시 상황에 따라서 써야 하는 시스템이 달라서 매우 번거롭고 업무가 물 흐르듯 흐르지 않는다.

하지만 진짜 비대면 업무를 하는 회사는 필요한 시스템과 툴이 촘촘히 잘 구축되어 있고, 서로 연동이 잘 되어 있고, 모든 직원이 동일한 시스템을 쓰며, 내재화가 잘 되어 있다. 그래서 업무가 매끄럽게 흘러가고 한 두개의 대시보드에서 자신의 업무가 다 모니터링 되고, 관리자는 부서의 업무를 한눈에 파악할 수 있도록 되어 있다.

대부분 들어본 시스템과 툴이지만 전사적으로 제대로 구축하여 잘 쓰는 것은 매우 어렵다.

문서 관리

비대면 업무 방식을 주장하면서 문서를 개별 PC에서 작성해서 이메일이나 메신저로 서로 주고받으면서 공유하고, 관리를 하고 있다면 가짜 비대면 업무를 하고 있을 가능성이 높다.

또는 문서 공유 시스템을 쓰기는 하는데, 부서별로 서로 다른 시스템을 사용해서 타부서와 문서를 공유할 때는 이메일이나 메신저 등으로 파일을 전달하는 경우도 있다.

진짜 비대면 업무를 하려면 전사의 모든 문서를 하나의 문서 관리시스템에서 체계적으로 관리하고 있어야 한다. 물론 부서별 업무별로 권한 관리를 잘하여 보안 상으로도 문제가 없어야 한다.

문서의 작성, 협업, 리뷰, 관리, 공유 등 모든 작업이 하나의 시스템으로 관리가 되어야 효율적인 비대면 업무를 할 수 있다. 

문서 작성 역량

비대면 업무를 제대로 하기 위해서는 문서 작성 역량도 매우 중요하다.

문서를 많이 작성해야 한다는 의미는 아니다. 대면 업무 방식에서는 문서의 내용이 부족하면 수시로 옆에서 물어가며 일할 수 있지만 비대면 방식에서는 그렇게 하기 곤란하다.

기획 문서, 스펙 문서, 설계 문서 등 여러 종류의 문서들이 문서만 가지고 충분히 내용을 파악할 수 있어야 한다. 100%는 불가능하지만, 80~90% 문서로 충분히 내용을 전달할 수 있는 역량을 가지고 있어야 한다. 물론 이런 문서도 문서 관리시스템에서 협업과 리뷰를 통해서 만들어지므로 잘 작성될 가능성도 높아진다.

가짜 비대면 업무를 하는 회사는 문서를 가지고 일하기 어려워 일할 때 커뮤니케이션이 너무 많이 필요하다. 그래서 옆에 앉아서 같이 일하기를 원한다. 예를 들어 소프트웨어 회사에서 외주를 줄 때 스펙 문서를 기반으로 외주를 주지 못한다. 대략의 기획 문서를 기반으로 외주를 준 후에 요구대로 소프트웨어가 개발이 잘 안되니 옆에 끼고 설명을 해주거나 나중에 프로젝트 일정이나 품질에 문제가 생기는 것이 다반사다.

진짜 비대면 업무를 하기 위해서는 직원들이 모두 말보다는 문서 위주로 일하기 때문에 문서를 제대로 작성할 수 있는 역량이 필요하다. 그래서 채용 시 글을 잘 쓰는 사람을 뽑기도 하고, 직원들에게 글을 잘 쓰고 문서를 잘 작성하도록 교육할 필요가 있다.

물론, 비대면 업무를 계속 하면서 문서 작성을 계속 하고 리뷰를 거쳐 피드백을 많이 받게 되면 누구나 문서 작성 역량이 조금씩은 향상된다.

보고

진짜 비대면 업무를 하는 회사는 별도의 보고가 많이 줄어든다. 또한 보고를 위한 보고는 보기 어렵다.

별도의 보고가 따로 필요하지 않은 이유는 촘촘하게 커버되는 시스템에서 업무의 진행 상황을 훨씬 더 자세히 파악할 수 있기 때문이다.

직원들도 별도의 시간을 들여서 보고서를 작성하지 않고 본연의 업무에 더 많은 시간을 쏟을 수 있다. 

하지만, 가짜 비대면 업무를 하는 회사는 업무는 업무대로 다하고, 일일보고, 주간보고 등 여러 형태로 보고서를 작성해서 보고를 해야 한다. 보고 방식은 온라인이라 할지라도 낭비요소가 아닐 수 없다. 

관리자는 또 상위 관리자에게 보고를 하기 위해서 직원들의 보고를 취합하여 또 보고를 한다.

보고를 줄이는 것은 진짜 비대면 업무 방식의 증거이자 혜택이다.

화상 회의 빈도

가짜 비대면 업무를 하는 회사는 형식만 비대면이지, 수시로 화상 회의를 실시하여 대면 업무 방식과 별 차이 없이 일한다.

화상 회의는 실제 만나서 얘기하는 것보다는 전달성이 떨어지지만 이동하지 않고 커뮤니케이션을 할 수 있는 장점이 있는 것이다.

하지만 화상 회의를 너무 자주 한다면 차라리 모여서 일하는 것이 더 효율적이다.

회상 회의를 해야 하는 안건이 대부분 이슈 관리 시스템이나 여러 시스템에 온라인으로 등록되고 프로세스를 따라서 처리되며 화상 회의는 꼭 필요할 때 최소화해서 해야 한다. 그래야 진짜 비대면 업무 방식으로 일한다고 할 수 있다.

회상 회의도 비싼 수단이다. 하루의 10~20% 넘는 시간을 화상 회의에 사용하고 있다면 일단 의심을 해보자.

회의 결과 관리

가짜 비대면 업무를 하는 회사는 회의도 자주 하지만 회의 기록이 없거나 회의 결과 해야 할 업무의 추적이 잘 안된다.

그러고는 한참 있다가 “지난 번에 내가 시킨 일 어떻게 되고 있지?”하고 묻는다. 전형적인 대면 업무 방식과 다를 바가 없다.

회의를 자주하는 것과도 관련이 있다. 회의를 계획하에 하지 않고 수시로 소집하기 때문에 회의록도 제대로 남기지 않고 후속 관리도 잘 안된다.

진짜 비대면 업무를 하는 회사에서는 회의 빈도도 적을 뿐만 아니라, 필요한 회의는 미리 계획이 되어 있고 회의 결과가 제대로 정리, 공유되어 있다. 또한 회의 결과로 인해서 해야 할 일은 회사의 온라인 시스템에 등록되어 실시간으로 추적이 된다. 

회의록만 보아도 후속 업무의 처리 현황을 실시간으로 볼 수 있도록 시스템이 구축되어 있기도 하다.

예를 들어 소프트웨어 회사의 경우 유지보수를 위해서 소스코드를 볼 때 특정 소스코드의 한 줄만 보아도 해당 줄을 누가 언제 작성해서 관련된 요청은 언제 누가 했으며, 이와 관련된 회의는 언제 누가 진행했고, 결론은 어떻게 나왔는지 줄줄이 모두 몇번의 클릭으로 추적이 된다. 그래서 누가 와서 유지보수를 해도 소스코드의 역사를 훤히 볼 수가 있다.

메신저 사용

가짜 비대면 업무를 하는 회사는 메신저를 끼고 업무를 한다. 회상 회의까지는 아니지만, 수시로 여러 사람에게 메시지를 날리고 이거 저거를 물어본다. 회상 회의보다는 작지만 비용이 많이 들어가는 일이다. 답변을 하기 위해서는 하던 일을 중단해야 한다. 만약에 집중 업무를 하고 있던 경우라면 다시 집중하는데 필요한 시간까지 최소 30분은 그냥 날아간다. 이런 일이 한 두 건이면 모르겠지만, 메신저를 통해서 메시지가 여기저기서 수시로 쏟아지면, 정작 집중해서 본연의 업무를 할 시간이 부족하다.

메신저의 문제점 중 하나가 기록이 체계적으로 남지 않아서 회사의 정보 자산으로 축적되지 않는 다는 것이다. 

그래서 메신저는 정보 자산과 관련 업무를 위해서 가벼운 용도로만 최소화해서 사용해야 한다.

편리하다고 수시로 메시지를 날리는 것은 대면 업무 방식과 크게 다를 바가 없다. 

업무 만족도

가짜 비대면 업무를 하는 회사는 현재 회사에서 진행하는 비대면 업무 방식에 불만이 많다. 아무래도 과거 대면 방식보다 불편하고 업무 효율성이 떨어지기 때문이다. 원인은 여러가지가 있을 수 있다. 시스템이 충분히 구축되어 있지 않은 채로 강제로 몰아붙일 수도 있고, 역량은 안되는데 과도하게 시스템을 도입한 경우도 있다. 

직원들이 충분히 시스템에 적응하지 못한 경우도 있다.

진짜 비대면 업무를 하려면 추가로 시스템이 필요한지, 직원들의 문서 작성 역량 향상이 필요한지, 시스템 사용 교육이 더 필요한지 회사에 따라서 다를 것이다.

대면 업무 방식으로 오랫동안 일하던 회사가 하루 아침에 완전 비대면 방식으로 전환하기는 어렵다. 인식의 전화, 시스템 사용 적응, 문서 작성 역량 등 필요한 것이 한두개가 아니고 수년 걸리는 일도 있다. 전문가의 도움을 받아서 하나씩 하나씩 꾸준히 추진하는 수밖에 없다.

재택근무 가능 여부

가짜 비대면 업무를 하는 회사는 100% 재택 근무를 하지 못한다. 최근 뉴스에 100% 재택 근무를 하고 있는 미국의 많은 회사를 접한다. 1200명 전원이 회사 사무실 하나 없이 100% 재택 근무를 하는 깃랩도 있고, 구글, 페이스북도 100% 재택근무를 하는 직원이 꽤 많다.

하지만 가짜 비대면 업무를 하는 회사는 일주일에 1~3일 정도 재택근무를 하고 나머지는 회사에 나와서 일해야 한다. 또는 재택근무가 가능한 특수한 직군만 100% 재택 근무가 가능하다. 최근 코로나 때문에 이런 식으로 일부 재택근무를 하는 회사가 있다.

물론 재택근무가 100% 우월한 것은 아니다. 대면 업무 방식은 얼굴 보고 일하면서 팀워크가 증가하는 것도 있고, 생활 리듬에 안정을 주는 것도 있다. 하지만 여기서 얘기하는 것은 필요할 때 재택근무를 할 수 있냐는 것이다.

100% 재택근무가 가능해야 진짜 비대면 업무를 하고 있다고 볼 수 있다. 그런 역량을 가지고 모여서 일하는 것은 회사의 선택이다.

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

비대면 온라인 화상 회의를 효율적으로 하는 방법

코로나 19로 인해서 비대면 업무의 필요성이 대두되면서 회의도 비대면으로 진행해야 하는 요구가 커졌다. 인터넷을 통해 화상 회의를 하는 여러가지 시스템이 있고, 이런 시스템을 이용하면 효율적으로 비대면 회의를 진행할 수 있다. 현재 비대면 온라인 화상 회의 솔루션을 제공하는 회사의 가치는 하늘 높은 줄 모르고 치솟고 있다. 클라우드 기반 회상회의 서비스 회사인 줌(Zoom)은 최근 IBM의 시가 총액을 추월했다. 

코로나 19가 아니더라도 회의를 비대면으로 진행하는 것은 여러가지 장점이 있다. 먼저 비용이 더 적게 든다. 대면 회의는 한자리에 사람들이 모이려면 이동 시간도 필요하고, 넓은 회의 공간도 필요하다. 회의실도 제약이 있어서 원하는 시간에 회의를 못하고 시간을 조정해야 한다. 앞 회의가 늦게 끝나서 기다리느라고 시간을 낭비하기도 한다.  

하지만 온라인 화상 회의는 회의실도 필요 없고, 지구 반대편에 있는 사람과도 시간만 정하면 언제든지 회의를 할 수 있고 업무 효율성 면으로 많은 이익이 있다. 

오랫동안 온라인 화상회의에 익숙해진 회사라면 문제가 없지만 온라인 회의를 처음 도입하는 회사라면 막상 온라인으로 화상 회의를 진행해보면 오프라인 대면 회의와는 다른 점이 많다. 이것을 비교해보고 효율적으로 비대면 회의를 하는 방법을 알아보려고 한다. 

화상 회의의 단점

회상 회의는 인터넷을 통하기 때문에 0.5초~1,2초 정도의 시간 지연 효과가 있다. 내가 말한 후 약 1초 정도 후에 상대방이 듣는다는 의미다. 그래서 서로 얘기를 하다 보면 말이 서로 겹치고 꼬이는 경우가 발생한다. 그래서 대면회의처럼 서로 중간에 말을 끊고 열띤 토론을 하다 가는 뒤죽박죽이 된다. 그래서 화상 회의에서는 말하는 에티켓을 지켜야 한다. 한사람이 너무 오래 말을 하는 것도 좋지 않고, 중간에 말을 끊는 것도 좋지 않다. 한사람이 말을 하고 나서 동시에 두사람이 말을 시작하는 경우도 있다. 그래서 회상 회의 시스템에는 “손들기”기능이 있는 경우도 있다. 이 경우 손을 든 순서대로 발언의 기회를 주기도 한다. 회사에서 화상 회의 때 발언하는 규칙이나 에티켓을 정해서 시행하면 좋다. 

화상 회의를 하다 보면 소리가 울리는 하울링이나 시스템 문제 때문에 중간에 회의가 중단되는 일을 여러 번 겪게 된다. 그래서 가능하면 회상 회의 장비는 좋은 것을 갖추고 네트워크도 충분히 갖추는 것이 좋다. 비용을 조금 아끼려다가 툭하면 회의가 중단되어서 더 큰 비용을 지불하기도 한다.  

화상 회의의 단점 중 하나는 아무래도 대면으로 얘기하는 것보다 전달력이 떨어진다. 미묘한 표정의 변화를 읽기가 어렵고 소리가 100% 깨끗하게 전달되지 않거나 잡음이 좀 섞이기도 해서 대면 회의보다는 떨어진다. 따라서 회의 내용을 명확히 정의하고 안건을 해결하는데 집중하는 것이 좋다.  

화상 회의의 장점

가장 큰 장점은 비용이 적게 든다는 것이다. 회의실이 필요 없고, 한자리에 모일 필요가 없으니 이동 시간이 절약된다. 한 빌딩 안에 있는 사람들이 아니라면 이동 시간은 더욱 절약된다. 해외 지사의 인원이나 재택 근무자와도 이동없이 바로 회의를 할 수 있다. 회상 회의 시스템을 도입하는데 비용이 들기는 하지만 회상 회의를 통한 비용 절약은 비용을 넘어서고도 남는다. 

회의를 녹화 또는 녹음할 수 있기 때문에 나중에 재검토를 할 수도 있고, 비참석자도 회의 내용을 확인할 수 있다. 

화상 회의는 급한 안건으로 긴급하게 회의를 소집할 때 매우 유리하다. 빠르면 10분안에도 서로 다른 곳에 있는 사람들을 모아서 회의를 진행할 수 있다. 대면 회의로는 도저히 할 수 없는 신속함이 가능하다.  

 회상 회의에서 지켜야 할 사항

화상 회의도 편리하다고 아무 때나 마구 진행하면 비싼 비용을 치러야 한다. 미리 스케줄러에 계획을 하고 명확한 아젠다를 정의하고 가능하면 24시간 이전에 공유를 해야 한다. 모든 참석자는 아젠다를 철저히 검토하여 자신의 의견을 정립하여 참석해야 한다. 아젠다에 미리 의견을 첨부하여 회의 시간을 단축할 수 있다. 이것은 고스란히 회의록으로 이전된다. 

온라인 화상 회의도 회의 주도자가 있어야 한다. 그래야 여러 의견 충돌 시 조율을 하고 진행을 원활하게 할 수 있다. 회의는 핵심 이견만 논의하여 신속하게 결론을 내리면 된다. 온라인으로 공유하면 되는 내용을 공유하기 위해서 굳이 회의를 개최할 필요가 없다.  

온라인 회의도 시간을 지켜야 하는 것은 마찬가지다. 3시가 회의라면 적어도 5분전에 시스템에 접속을 해야 한다. 가끔, 문제가 생겨서 접속하는데 시간이 소요되기도 한다. 그래서 5분전에는 접속을 시도해야 회의에 늦지 않을 수 있다. 이래저래 준비하느라고 5분, 10분 늦게 회의를 시작하는 것이 일상화된 회사가 종종 있다. 항상 일찍 접속해서 기다리는 사람은 항상 시간을 낭비하고 회사 입장에서도 큰 손해다. 

재택근무시 화상회의를 하게 되면 너무 편한 복장으로 접속을 하는 경우도 있는데, 최소한의 예의를 갖추는 복장 정도는 입어주는 것이 좋다. 그리고 나름 조용한 공간도 필요하다. 주변이 너무 시끄러워도 회의에 방해가 되고, 회의 때문에 시끄러워서 주변에서 일하는 사람들에 방해를 주는 것도 조심해야 한다. 

앞에서도 언급했다시피 화상회의는 인터넷 속도의 한계상 지연이 발생할 수밖에 없으므로 상대방의 발언을 경청하는 습관을 들이고 중간에 끼어들지 않도록 하고 자신도 꼭 필요한 말만 간결하게 하는 습관을 들여야 한다. 화상회의를 이렇게 진행하면 업무 효율성이 많이 향상된다. 

회의록을 작성하는 방법

화상 회의를 하면서는 회의록을 실시간으로 작성하기 좋다. 회의가 끝나고 회의록을 따로 작성해서 배포하고 검토하고 수정하고 하는 것은 꽤나 번거롭고, 귀찮은 일이다. 그래서 회의 내용과 다른 회의록이 작성되기도 한다. 회의록은 실시간으로 작성하는 것이 좋은데, 회상 회의 때 회의 진행자가 회의록을 직접 작성하기를 추천한다. 아젠다를 띄워 놓고 직접 수정해가면서 회의록을 작성하면 좋다.  

회의록은 실시간으로 작성해서 모든 참석자가 실시간으로 눈으로 보면서 문구 하나하나 검토해서 의견이 다르면 회의록 수정을 요청해서 이것도 즉석에서 다시 적어야 한다. 회의록을 즉석에서 적고 공유할 수 있는 시스템도 있다. MS 팀즈에는 위키(Wiki)를 통해서 회의록을 실시간 공유할 수 있도록 되어 있다. 또는 화면 공유를 통해서 위키나 회의록 시스템에 실시간 기록할 수 있다. 

회의록을 작성하면서 결정사항, 미결사항, 해야 할 일 등을 태그로 표시를 하고 추후 해야 할 일은 Todo 시스템과 연동이 되도록 하는 것이 좋다. Atlassian의 Confluence의 회의록 시스템은 이런 기능이 잘되어 있다. 

간단한 일은 Todo와 연동하면 되지만 회의 후 해야 할 일이 꽤 큰 일이고 추적이 필요하면 이슈관리시스템과 연동을 하는 것이 좋다. 이렇게 해야 할 일을 등록해 놓고 추적하지 않으면 흐지부지 되는 경우가 많다. 

온라인 화상 회의는 이렇게 회의 준비, 과정, 결과, 후속 조치가 모두 온라인 시스템에 등록되어 회사의 자산이 된다. 그리고 지구상 어디에서든지 접근 가능한 정보가 된다. 온라인 회의가 제대로 정착되면 회사의 생산성이 증가할 수밖에 없다. 또한 비대면 업무로 전환하기 위한 강력한 무기가 된다.

이글은 ZDNet 코리아에 기고한 칼럼입니다.

[Software Spec Series 8] 어떻게 소프트웨어를 빠르게 개발하는가?

소프트웨어는 빠르게 개발하는 것이 매우 중요하다. 소프트웨어 개발 기간이 오래 걸린다면 적절한 시장 진입 시기를 놓칠 수 있다. 소프트웨어 시장 변화는 매우 빨라서 너무 오래 개발을 하면 그동안 시장의 상황이 바뀐다. 경쟁자들은 새로운 제품을 출시하여 우리 회사에서 지금 개발하고 있는 제품이 뒤쳐지곤 한다. 또한 오랜 프로젝트는 개발자와 프로젝트 참여 인원들을 지치게 만든다. 이런 현상이 프로젝트를 더욱 더디게 한다. 프로젝트가 기간이 길어지면 그동안 새로운 요구사항이 추가될 가능성이 높다. 기획자는 변화하는 시장의 상황을 무시할 수가 없기 때문이다. 그래서 프로젝트는 더욱 늘어지고 품질은 떨어진다.

최근의 대부분의 개발 방법론들은 소프트웨어를 빠르게 개발하는 것을 중요시하고 있으며 회사에서도 소프트웨어를 빠르게 개발하기 위한 많은 노력을 들이고 있다. 그럼 어떻게 해야 소프트웨어를 빠르게 개발할 수 있을까? 소프트웨어를 빠르게 개발하기 위해서 고려해야 할 것은 매우 많지만, 여기서는 스펙 관점으로 살펴보려고 한다.

(느린 순차적 개발)

빌딩을 쌓을 때는 1층을 쌓고 2층을 쌓아야 한다. 1층을 쌓기 전에 2층을 쌓는 것은 불가능하다. 조립식 빌딩이라면 얘기가 다르지만 대부분의 빌딩은 순차적으로 쌓아 나간다. 소프트웨어도 이런 방식으로 순차적으로 개발을 해야 한다면 매우 오랜 시간이 걸릴 것이다. 거대한 소프트웨어는 수십년이 걸릴 수도 있다.

하지만 소프트웨어는 빌딩과 같이 1층이 완성되기를 기다렸다가 2층을 만들 필요가 없다. 1층과 2층의 인터페이스만 잘 정하면 따로 만들어서 합치면 된다. 다 만들어서 나중에 합치는 방법도 있지만, 1층과 2층의 뼈대만 만들어 놓고 동시에 만드는 방법을 더 많이 사용한다. 나중에 합치게 되면 합치는 과정에서 문제가 발생하기도 하지만, 처음부터 합쳐 놓고 동시에 만들면 합치는 과정에서 생기는 문제가 줄어든다.

(빠른 병행 개발 - 개발 후 통합)

(빠른 병행 개발 - 통합 후 개발)

이렇게 소프트웨어를 동시에 개발하여 프로젝트 기간을 단축하려면 분석, 설계가 잘 되어 있어야 한다. 특히 컴포넌트를 잘 나누고 인터페이스를 견고하게 정의해야 한다. 인터페이스는 간결하게 정의를 해야 각 모듈 간의 연동이 쉬워진다. 인터페이스는 확고하게 정의를 해야 하며 나중에 함부로 바꾸면 안된다. 물론 한번 정의한 인터페이스가 프로젝트 종료 시까지 변경되지 않으면 가장 좋겠지만 쉬운 일이 아니다. 개발 도중에 인터페이스를 변경하면 처음에 잘 정의한 경우보다 수십배의 변경 비용이 들어간다. 따라서 분석, 설계 시 최대한 노력을 하여 인터페이스가 가능하면 변경되지 않도록 정의를 해야 한다.

프로젝트가 크고 참여 인원이 많을수록 순차적인 개발보다 병렬 개발이 훨씬 좋다. 수십명의 개발자가 참여하는 프로젝트에서 순차적인 개발이란 거의 불가능하다. 수십명의 개발자가 처음부터 잘 통합된 소스코드를 기반으로 병렬로 개발을 해야 프로젝트를 빨리 끝낼 수 있다.

(순차개발과 병행개발의 개발 속도 차이 비교)

인터페이스는 상호간의 약속이다. 클라이언트와 서버 모듈을 병렬 개발할 때 인터페이스는 클라이언트 개발팀과 서버 개발팀의 약속이다. 인터페이스를 확정하면 서로 약속을 한 것이고 서로 헤어져서 따로 개발을 해도 문제가 없을 정도로 신뢰를 할 수 있어야 한다.

프로젝트 기간 내내 인터페이스를 잘 유지하기 위해서는 지속적인 통합이 필요하며 유닛 테스트, 테스트 자동화도 유용하다. 개발자는 자신이 작성한 모듈을 완성한 후에 소스코드관리시스템에 등록하는 것이 아니라 좀더 잦은 주기로 등록을 하여 프로젝트 주기 내내 소스코드가 정상적으로 빌드가 되도록 유지해야 한다. 너무 늦게 통합을 할 경우 많은 문제를 발생시키는 “통합의 지옥”을 맛보게 된다.

커밋은 하나의 기능이 완성이 되었을 때, 전체 클래스 또는 전체 컴포넌트를 모두 구현할 때까지 기다릴 필요가 없다. 하지만 항상 빌드는 되어야 한다. 또한 내가 소스코드를 수정하는 동안 다른 곳을 수정한 동료들의 소스코드와 머지(Merge)가 잘 되어서 제대로 빌드가 되는지 확인을 해야 한다. 보통은 적어도 하루에 한두 번 이상 커밋을 한다. 며칠씩 커밋을 하지 않고 지나가지는 않는다.

지속적인 통합을 위해서는 툴을 사용해도 되고, 직접 스크립트를 작성해서 구축을 해도 된다. 지속적인 통합을 도와주는 툴을 CI툴이라고 하며 Jenkins, Bamboo 등이 있다. CI툴 자체가 중요한 것은 아니지만 CI툴은 지속적인 통합을 조금 쉽게 해준다. 중요한 것은 지속적인 통합 활동을 성실히 하는 것이다.

지속적인 통합을 위해서는 주기적인 빌드가 필수다. Build on commit을 하기도 하고 Daily build를 하기도 한다. 밤에 빌드를 한다고 해서 Nightly build라고 하기도 한다. 프로젝트 기간 내내 Daily build는 실패가 없어야 한다. Daily build가 실패하면 인터페이스가 깨졌거나, 어떤 개발자가 깨진 소스코드를 올렸을 수 있다. 빌드가 깨지면 여러 개발자들이 개발에 차질을 빚게 된다. Daily build가 깨진 것을 브로큰 트리(Broken tree)라고 부르며 즉각 해결을 해야 한다.

거대한 시스템일수록 병렬 개발은 꼭 필요하다. 거대한 시스템의 구조를 얼마나 간결하게 하는지가 설계의 중요 요소다. Architect는 복잡한 시스템을 최대한 간결하고 복잡도를 줄여서 시스템의 개발, 유지보수 효율을 높여야 한다. 병렬 개발을 할 때 어려운 점은 내가 필요로 하는 컴포넌트가 아직 구현이 안되어 있어서 기능을 확인할 수 없다는 것이다.

예를 들어보자. 나는 사용자 관리 화면을 개발하고 있고 getUserList()라는 함수가 필요하다. 나는 사용자 목록을 출력하는 화면을 만들고 있는데 getUserList()를 개발하는 개발자는 아직 이 함수를 구현하지 않은 상태다. 그럼 나는 getUserList() 함수가 개발되기 전까지는 내가 만든 사용자 목록 화면을 테스트 해볼 수가 없다. 그럴 때는 getUserList() 함수에 가짜 코드를 추가하면 된다. 실제로는 DB에 쿼리를 해서 사용자 목록을 가져와야 하지만, 가짜로 Hard coding을 해서 사용자 목록을 넘겨주는 것이다. 물론 이런 가짜코드는 필요에 따라서 언제든지 넣고 뺄 수가 있어야 한다.

C언어로 개발을 한다면 다음과 같은 형태가 될 것이다. 아주 간단한 예를 든다.

#define USE_FAKE
RET getUserList(userdata *pData[], int &num)
{
#ifdef USEFAKE
  // make fake data
  num = 2;
  pData[0]->userid = 1;
  pData[0]->username = “John”;
  pData[1]->userid = 2;
  pData[1]->username = “Tom”;
#else
  // get data from database
#endif
  return RET_SUCCESS;
}

(병행 개발을 위한 소스코드 예)

이와 비슷하게 개발 언어에 따라서 적절한 방법으로 병렬 개발하는 아이디어를 적용하면 된다. 병렬 개발을 위와 같이 각자 서로 다른 모듈을 개발하는 경우도 있고 하나의 모듈을 여러 개발자가 개발하는 경우도 있다.

잘 분석, 설계된 소프트웨어는 이와 같은 방법을 사용하여 병렬 개발을 진행하여 소프트웨어를 빨리 개발할 수 있다.

share with abctech.software

SW회사에는 왜 수평적인 조직문화가 필요한가?

한국 소프트웨어 개발 환경이 이렇게 열악하고 기업의 소프트웨어 경쟁력이 미천한 이유의 핵심은 글로벌 소프트웨어 회사와는 엄청나게 다른 개발문화, 기업문화 때문이라고 생각한다. 그래서 필자는 지속적으로 글로벌 개발 문화를 소개해 왔고 이제는 실제 한국의 소프트웨어 회사에 적용된 사례도 공유하고 있다.

​

이번에는 소프트웨어 회사에 왜 수평적인 조직문화가 꼭 필요한지 설명하려고 한다.

​

한국 대기업을 다니는 외국인 직원이나 외국에 있는 한국 회사에 다니는 외국인들의 한국 회사에 대한 평가는 인터넷에 많이 올라온다. '글래스도어'도 그 중에 하나고 필자는 대기업에서 일하고 있는 외국인 개발자들을 인터뷰하기도 했었다.

​

좋은 얘기도 많지만, 문제를 찾아야 하는 입장에서 문제점으로 지적된 것을 봐야 한다. 그 중에 대표적인 것은 한국 기업은 '군대'와 비슷하다는 것이다. 군대식 상하 조직이 한국 사람들에게는 상당히 자연스러운데 이런 조직 문화는 소프트웨어를 개발하는데 있어서는 심각한 걸림돌이 된다. '까라면 까라'로 대표되는 군대식 상명하복 문화를 가지고는 글로벌 회사들과 경쟁하기 어렵다. 어렵사리 글로벌 시장에 진출하여 세계 상위권에 올라섰다고 하더라도 곪은 문제는 언젠간 터지게 마련이고 나락으로 떨어지는 것은 한 순간이다.

​

소프트웨어는 인류가 만들어 낸 가장 복잡한 지식 산업이다. 물론 상명하복식 조직 문화가 매우 효과적인 산업 분야도 있다. 하지만 창의적인 지식 산업인 소프트웨어 분야에서는 상명하복식으로 성장할 수 있는 데는 한계가 있다.

​

상급자가 모든 것을 알 수는 없다. 경영자도 소프트웨어 개발에 대한 모든 것을 알 수가 없다. 그런데도 경영이나 영업 관점으로 목표를 제시하고 '까라면 까라는 식'으로 일을 추진하면 시한폭탄을 계속 심는 것과 다를 바가 없다. 개발에 1년이 걸릴 프로젝트를 시장 상황 때문에 6개월안에 개발을 하려면 전문가들이 머리를 맞대고 합리적인 단축 방법을 찾을 수도 있다. 하지만 합리적인 해결책은 무시하고 명령식으로 압박을 하면 프로젝트는 어찌어찌 진행이 되지만 중요한 핵심 프로세스들이 생략될 수밖에 없다.

​

코딩은 빼먹을 수가 없으니, 스펙을 대충 정하거나 분석도 하지 않고 코딩을 시작해야 하며, 설계도 없거나 부실하고, QA도 대충할 수 밖에 없다. 어떻게든 결과가 나왔다고 하더라도 출시 후에 더 큰 비용을 치르거나 또 하나의 시한폭탄을 심어 놓은 상황이 된다.

​

이런 일이 벌어지는 이유는 상하관계가 확실하고 윗사람이 거의 생사여탈권에 가까운 평가권과 인사권을 가지고 있고 아랫사람은 윗사람과 특히 최고 경영자의 눈치를 심하게 봐야 하는 기업 문화 때문이다. 이런 조직에서 성장해온 관리자들은 어렵게 획득한 막강한 권한을 내려 놓기는 쉽지 않다. 자신 혼자 내려 놓을 수 있는 것도 아니다. 그래서 기존 조직, 특히 대기업이나 중견기업이 수평적인 조직으로 바뀌는 것은 거의 불가능하다.

​

수평적인 조직이란 모든 직원이 평등하다는 것을 말하는 것이 아니다. 각자 전문가로서 역할을 할 수 있어야 하며, 전문가로서 목소리를 낼 수 있어야 하며, 전문가로서 제시한 의견을 존중 받아야 한다는 의미다. 이때 직급, 나이, 경력은 의미가 없다. 상하 관계가 아닌 전문가로서의 의견이 잘 조율돼서 조직이 할 수 있는 최선의 결정을 내릴 수 있어야 경쟁력을 갖출 수 있다.

​

그럼 필자가 CEO로 있는 이우소프트의 수평적인 조직문화에 대해서 소개를 하겠다.

​

수평적인 조직문화는 다른 모든 조직 문화를 떠받치는 기초와 같다. 자율, 토론, 차근차근, 전문가 존중 등 이우소프트가 지향하는 기업 문화는 상명하복 문화가 철저한 조직에서는 잘 작동하지 않는다. 그래서 수평적인 조직 문화를 정착하기 위해서 많은 노력을 했다.

​

첫째, 모두 영어 이름을 부른다.

​

영어 이름을 부르는 것은 단순히 유행을 따르는 것은 아니다. 호칭은 사람의 생각을 지배하고 존칭과 하대가 섞인 대화에서는 상하 관계가 떠오를 수밖에 없다. 그래서 많은 회사들이 호칭 개혁을 하려고 '~님', '~프로' 등 다양한 시도를 하지만 제대로 정착된 곳이 많지는 않다. 하지만 영어 이름을 부르는 것은 이미 검증된 방법이다. 영어이름을 부르면 직급을 부르지 않아도 되고, 제3자가 보더라도 상하 관계를 읽을 수가 없다.

​

그래서 이우소프트에서는 서로 영어 이름을 부르고 있고 영어 이름을 부를 때 존칭을 사용하는 것은 금지되어 있다. 모든 사람이 서로 존대를 하되 '~께서'라고 부르는 것도 금지되어 있다. 내 영어 이름은 레이몬드(Raymond)인데, "레이몬드께서 그렇게 말씀 하셨습니다."는 금지된 표현이고 "레이몬드가 그렇게 말했습니다."가 허용된 표현이다.

​

직책을 부르는 것도 금지되어 있다. 팀장님, 대표님과 같은 호칭도 부르지 못하도록 되어 있다. 적응하는데 시간이 꽤 걸렸고, 한국 이름을 부르거나 직책을 부르면 1,000원씩 벌금을 내야 하고, 이제는 완전히 정착이 되었다. 그렇게 모인 벌금은 연말에 불우이웃 돕기를 하기로 되어 있다.

​

특히, 신입 사원들은 가장 빨리 적응을 했다. 각자 직급은 나눠져 있기는 하지만 부르지 않기 때문에 서로의 그레이드(Grade)를 잘 모르고 있다. 회사에 외국인 개발자는 점점 늘고 있고, 영어 사용이 늘고 있어서 영어 호칭이 도움이 되고 있다.

​

둘째, 상하 관계로 의사 결정을 하지 않는다.

​

즉, 전문가를 존중한다. 수평적으로 나뉜 역할에 의해서 대부분의 결정을 한다. 소프트웨어 회사에는 수많은 전문 역할이 있다. 소프트웨어 엔지니어(Software Engineer), 소프트웨어 아키텍트(Software Architect), CTO, 프로젝트 매니저(Project Manager), 프로덕트 매니저(Product Manager), 리스크 매니저(Risk Manager), 빌드 엔지니어(Build Engineer), 테크니컬 라이터(Technical writer), 마케터(Marketer), UI 디자이너, QA 엔지니어, 형상 관리자(Configuration Manager) 등 여러 역할이 있다.

​

물론 작은 회사는 한 사람이 여러 역할을 하며 이 모두를 다하기도 한다. 하지만, 회사가 조금만 커져도 역할을 나누며 각각 전문성을 높여 나간다. 그리고 전문가의 의견을 최대한 존중하고 상하 관계로 의사결정의 뒤엎지 않는다. 자신의 전문 역할이 아니라도 의견을 제시할 수는 있고 토론을 할 수는 있지만 무리하게 남의 전문영역에 침범을 하면 안 된다.

​

"전권을 주면 내가 프로젝트를 성공시켜보겠다"라고 말하는 사람들이 있다. 이우소프트에서는 이런 말은 통하지 않는다.

​

제품의 기능을 결정할 때는 세일즈, 마케팅, 개발팀, 경영진의 의견은 대부분 상충된다. 이때 직급의 힘으로 의사 결정을 하지 않는다. 각자 전문가로 역할을 수행하며 논쟁을 하고 경영진은 회사의 비전과 프로젝트의 목표에 알맞게 균형을 맞추고 조율하는 일을 주로 한다. 직원을 채용할 때도 신입이나 주니어 급 직원은 상관없지만 경험이 많은 직원을 채용할 때는 권위의식이 있는지 상명하복에 익숙한지 잘 살핀다.

​

셋째, 허락 받고 일하기 보다는 자율적으로 일한다.

​

상사가 일을 시키고 하급자는 시키는 일을 하는 구조가 아니다. 대부분은 스스로 일을 찾고, 스스로 할 일을 정해서 한다. 물론 시켜서 하는 일도 있다. 하지만 능동적으로 스스로 일을 찾아서 하는 것을 권장하고 있고, 하는 일은 모두 시스템에 등록을 하기 때문에 팀장이나 동료들이 모두 모니터링을 할 수 있다. 가끔 일이 잘못 진행되거나 우선순위 조절에 문제가 생기기도 하지만 모니터링을 하다가 바로 잡아주면 된다.

​

업무의 자율성을 높이기 위해서는 뭔가 잘못되었을 때 처벌을 강조하면 안 된다. 처벌이 강할수록 수동적으로 바뀐다. 그리고 문제가 생겼을 때는 여러 사람의 공동책임이다. 시스템에 일을 너무 늦게 공유를 했거나, 모니터링을 소홀히 했을 수가 있다. 프로세스를 잘못 이해하고 있을 수도 있다. 처벌보다는 원인을 찾아서 개선을 해야 한다. 고의로 잘못을 한 것이 아니라면 직원의 일방적인 책임은 아니다.

​

이런 방식이 허락 받고 일하거나 시키는 것 위주로 일하는 것보다는 훨씬 생산성이 높다. 기본적으로 시키는 일보다는 자신이 선택한 일이 더 재미있고 집중도도 높다. 또한 자율성, 창의성이 향상되므로 업무 효율성은 훨씬 높아진다. 물론 모든 직원이 다 적극적이고 능동적인 것은 아니다. 여러 성격의 직원들이 섞여 있지만, 능동적인 직원들의 발전이 더 빠르다. 시키는 일만을 위주로 회사가 돌아간다면 창의적인 지식산업이 소프트웨어가 노동 산업으로 전락할 수가 있다.

​

이우소프트가 이렇게 수평적인 조직문화를 잘 정착한 데는 이유가 있다. 실리콘밸리에서 20년동안 개발을 한 CTO와 수평적인 문화를 당연하게 받아들이는 경영진이 있어서 가능했다. 오히려 직원들이 수평적인 조직문화에 적응하는데 시간이 걸렸다. 한국 대기업들이 수평적이고 자율적인 문화로 조직문화를 탈바꿈하는 것이 쉽지 않은 이유다. 마음만 먹는다고 바뀌는 것도 아니고 경영진은 여전히 무소불위의 권력을 행사하면서 직원들끼리 수평적인 조직문화를 만들 수는 없다. 문화란 대물림이 되고 바뀌기 매우 어렵기 때문에 외국인을 채용하거나 외국 회사를 흡수 합병해도 그들의 문화는 사라지고 기존의 상명하복 문화에 억지로 적응해야 하는 상황이 벌어진다.

​

수평적인 조직문화는 다른 문화의 기반이 되기 때문에 특히 더 중요하다. 수평적인 조직문화 하에서 공유와 협업이 더 잘되며 전문가로서 캐리어를 꾸준히 유지하기도 쉽다. 사규를 만든다고 되는 것도 아니다. 모두의 생각이 바뀌어야 한다. 경영진들이 먼저 수평적인 조직문화에 완전히 적응을 해야 직원들이 따라 올 수 있다.

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

유니코드 인코딩이 이렇게 복잡하게 된 사연 (9)

유니코드 인코딩의 종류는 UTF-1, UTF-5, UTF-6, UTF-7, UTF-8, UTF-9, UTF-16, UTF-18, UTF-32, UTF-EBCDIC, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE와 같이 다양하다. 지금은 사장된 것들도 있지만 초급 개발자에게는 여간 헷갈리는 것이 아니다. 

애초에 ASCII가 아니고 유니코드를 사용했다면, 특히 4바이트 유니코드를 사용했다면 지금과 같이 수많은 유니코드 인코딩 때문에 헷갈거나 변환을 해야 하는 번거로움은 없었을 것이다. 현재와 고대 문자만 표현한다면 3바이트로도 충분하지만 4바이트가 컴퓨터 연산에 편리하고 먼 미래에 어떻게 될지 모르기 때문에 4바이트가 안전할 것이다.  하지만 뒤늦게 나온 유니코드는 ASCII와 호환성 등 여러 가지 이유로 인해서 수많은 인코딩이 존재한다. 

인류가 유일한 표준 문자세트로 4바이트 유니코드를 사용하고 있다면 영어 문서를 저장하기 위해서 지금의 4배 용량의 저장장치가 필요하다. 지금은 별일 아니지만 과거에는 저장 용량은 매우 큰 이슈였다. 필자가 대학생 때 샀던 PC에는 40만원 주고 산 40MB짜리 그 당시로는 대용량 HDD가 달려 있었다. 지금은 2바이트, 4바이트 유니코드가 있지만 여전히 저장 용량 절약 이슈가 존재한다. 언제가 될지 기약할 수 없지만 모든 시스템과 파일이 4바이트 유니코드 단일 체계를 사용하는 날이 올 것이다. 몇십년 후일지 몇백년 후일지는 모르겠다.

(유니코드 인코딩과 타 인코딩 간의 관계)

그럼 유니코드 관련 주요 인코딩의 특징 및 관계, 사연에 대해서 알아보자. 지금은 거의 쓰지 않는 인코딩은 알 필요가 없다.

1. MBCS (Multi Byte Character Set)

유니코드 인코딩이 아니며 ASCII에서 표현하지 못하는 각국의 문자를 표현하기 위해서 사용하는 수많은 문자세트와 인코딩이다. 보통 1,2바이트를 사용하며 ASCII를 포함한다. 나라별로 로케일별로 제각각 이어서 서로 호환이 안 된다. 아직도 수많은 Application이 유니코드 기반이 아니고 MBCS 기반이며 소프트웨어 국제화의 발목을 잡고 있다. Application이 MBCS 기반이어도 Windows는 내부적으로 유니코드(UCS-2)를 쓰기 때문에 Application과 OS를 오가며 문자열들은 계속 변환이 일어나고 이런 과정에서 예상치 못하게 깨지는 문자들이 나오게 된다. 최근의 새로운 개발 환경이나 플랫폼들은 아예 MBCS를 지원하지 않고 유니코드 Application만 제작할 수 있는 경우도 많다. 이런 환경에서만 개발하는 개발자는 MBCS가 뭔지도 모르고 자연스럽게 유니코드 Application을 만들 것이다.

2. UCS-2 (Unicode Character Set-2)

유니코드 문자세트이며 인코딩이다. Windows는 내부에서 UCS-2를 사용한다. C언어에서는 wchar_t(유니코드문자 자료형)로 표현한다. Unix나 Linux에서는 wchar_t는 UCS-4이다. Unix나 Linux에서는 한 글자에 4바이트이니 주의를 하자. 모든 문자가 깔끔하게 2바이트라서 연산이 매우 빠르다. 100바이트에는 딱 50글자가 들어간다. 하지만 ASCII 문자를 표현하기 위해서 NULL문자가 포함되어 있어서 기존의 char * 자료형에는 담을 수가 없다. 또한 문자열 관련된 수많은 함수를 다시 만들어야 했다. 파일에 그대로 기록할 경우 NULL문자로 인해서 기존의 Application이 텍스트 파일이 아닌 바이너리 파일로 인식하는 문제가 있다. 주로 Application 내부 데이터 용도로 사용한다고 보면 된다.

3. UTF-8 (Unicode Transformation Format-8)

유니코드 중에서 가장 널리 쓰이는 인코딩이다. 1~6바이트를 사용한다. BMP만 표현한다면 4바이트까지만 사용하면 된다. 특히 파일저장, 데이터 전송 등에 많이 사용한다. UTF-8의 가장 큰 장점은 위 그림에서도 보이듯이 ASCII, ISO8859-1과 호환된다는 것이다. 즉, UTF-8 문서를 처리하는 소프트웨어는 ASCII와 ISO-8859 문서를 변환 없이 그대로 처리할 수 있다. 반대로 UTF-8 인코딩으로 저장한 문서가 과거 미국이나 독일 Application에서 읽힌다. 물론 지원하지 않는 문자는 깨져서 보일 것이지만 열리기는 할 것이다. 미국과 유럽, 특히 영어권에 매우 유리한 인코딩이다. 이는 UTF-8이 가장 널리 쓰이는 이유이기도 하다.

영어로 된 문서를 저장할 때 용량이 매우 작다. 하지만 한국어(한글)는 한 글자당 3바이트로 용량이 낭비된다. 이또한 UTF-8이 인기있는 이유중 하나다.

그 외에도 UTF-8은 여러 장점이 있다. 데이터를 중간부터 보더라도 몇 바이트만 보면 UTF-8 인코딩인지 알 수 있고 데이터 손실도 거의 없다. UTF-8 데이터 구조는 처음부터 이런 장점을 가지도록 설계가 되어 있는데 이를 설계한 사람의 천재성을 엿볼 수 있다.

또 하나의 장점은 문자열 중간에 NULL(0x00)문자가 나오지 않는다는 것이다. 따라서 파일에 저장해도 바이너리 파일로 인식하는 오류가 없고, C언어와 같이 Null terminated string의 자료형에 담을 수가 있다. 이는 하위호환성에서는 큰 장점이 된다.

단점으로는 가변 바이트를 사용하여 글자 개수를 세려면 한 글자씩 개수를 세야 하는 등의 연산 오버헤드가 있다.

4. UTF-16 (Unicode Transformation Format-16)

유니코드 컨소시엄에서 제안한 인코딩이다. UCS-2와 거의 동일하기 때문에 혼동해서 사용하는 경우가 많다. 하지만 UTF-16은 가변 길이이기 때문에 2바이트 고정 길이를 지칭한 경우라면 UCS-2를 말하는 것을 UTF-16이라고 잘못 부르는 것이다. 최초의 UTF-16은 UCS-2와 동일 했기 때문에 그 잔재가 아직도 남아 있는 것 같다.

Java에서는 문자열의 인코딩에 기본적으로 UTF-16(BE)를 사용한다. Java로 개발을 할 때도 문자 인코딩을 제대로 이해하고 있어야 깨지지 않고 제대로 처리를 할 수 있다.

5. UTF-32 (Unicode Transformation Format-32)

4바이트로 고정된 UCS-4와 동일한 인코딩이다. (현재까지는) 모든 문자들이 UTF-32로 통일된다면 인코딩 변환이 필요 없는 세상이 올 것이다. 하지만 저장 공간 낭비가 심해서 인류가 저장 용량에서 완전히 해방되는 날이 되기 전까지는 유일한 표준이 되기는 어려울 것이다. 또한 UTF-8과는 다르게 데이터를 중간부터 보면 어디가 글자의 시작인지 알 수가 없는 단점이 있다.

이 외에도 수많은 유니코드 인코딩이 생겨났지만 거의 사장되다시피 했다.

Byte Order와 BOM 이슈는 나중에 다루도록 하겠다. 

국제화를 이해하기 위한 기초를 다루다 보니 여러 회가 지났는데 다음부터는 본격적인 내용과 기초를 교대로 다뤄볼까 한다.

이 글은 네이버 포스트에 게재할 글입니다.

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 

1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코드로 통일되는 시기가 올 수도 있겠지만 아직까지는 한국어만 해도 여러 문자세트와 인코딩이 공존을 하고 있고 소프트웨어 개발자에게는 여간 귀찮은 일이 아닐 수 없다. 이에 대해서 잘 알고 있고 경험이 많은 개발자라면 별 문제가 없지만 한국어 문자세트와 인코딩에 대해서 조금 헷갈리는 경우라면 소프트웨어를 개발하면서 수많은 지뢰를 만나게 된다. 그나마 한국어는 중국이나 일본에 비해서는 문자세트와 인코딩의 표준화가 잘되어 있어서 훨씬 수월한 편이라고 할 수 있다.

이제 유니코드가 대세라고 Application을 유니코드를 지원하도록 만든다고 다 해결되는 것은 아니다. 네트워크를 통해서 다른 시스템과 통신을 할 때 다른 인코딩을 사용할 수도 있고, 파일로 저장할 때 다른 형식을 써야 할 때도 많다. 왜냐하면 아직도 수많은 시스템이 유니코드를 지원하지 않고 있고, 우리는 그런 시스템과도 연동을 해야 하기 때문이다.

데이터베이스의 인코딩을 어떤 것을 선택할지도 큰 이슈다. 지금은 누구나 유니코드의 인코딩을 선택하지만 몇 년 전까지만 해도 EUC-KR이나 다른 인코딩을 선택하기도 했다. 이런 경우 시스템의 국제화를 추진하게 되면 심각한 문제에 봉착하게 된다. 데이터베이스 이슈는 추후 별도로 다루도록 하겠다.

우리는 Application을 개발하면서 외부 라이브러리를 사용하기도 한다. 그런데 외부 라이브러리가 유니코드 기반이 아닌 경우도 많다. 그럴 때는 라이브러리를 사용하기 위해서 문자열을 변환해야 하는 복잡한 문제에 봉착하기도 한다. 상황에 따라 다르지만 유니코드와 여러 가지 인코딩이 공존하는 세상에서 개발해야 하는 개발자들은 이런 문제를 겪기도 하고 해결해야 한다는 것을 알아야 한다.

그래서 현재 한국어를 표현하기 위해서 사용되고 있는 문자세트와 인코딩에 대해서 간단하게 집고 가려고 한다. 물론 문자가 깨지는 경우에 이를 해결하는 데는 경험이 훨씬 중요하다. 하지만 문자세트와 인코딩의 지식은 기본으로 필요하다.

(한국어 문자세트와 인코딩 포함 관계)

1. KSC 5601 (문자세트)

한국산업규격 한국어문자집합이다. 공식 명칭은 KS X 1001이다. 1974년 처음 제정되었고 2004년에 마지막 개정이 있었다. 2바이트 부호체계이며 8,836문자를 규정하고 있다. 한글, 숫자, 특수문자, 한자, 로마자, 그리스문자, 키릴문자 등으로 구성되어 있다. 

한글 2,350자와 한자 4,888자를 정의하고 있는데 실제 사용하는 한글과 한자에 비해서는 턱없이 부족한 문제가 있다.

2. EUC-KR (인코딩)

문자세트는 실제 컴퓨터에서 사용하는 코드는 아니다. 컴퓨터에서는 인코딩을 사용하며 EUC-KR은 널리 사용되는 한국어 인코딩 중 하나다. KSC 5601을 그대로 포함하고 있으며 영어 영역은 ASCII를 사용한다. 정확하게는 KS X 1003인데 ASCII라고 알고 있어도 무방하다. EUC-KR은 KSC 5601이 가지고 있는 문제를 그대로 가지고 있다.

3. ISO-2022-KR (인코딩)

지금은 쓸 이유도 없는 인코딩이지만 하위 호환 때문에 가끔 만나게 된다. ISO2022는 원래 둘 이상의 문자집합을 한꺼번에 표현하기 위한 국제 규약이었는데 여기에 한국어를 추가했다. 지금은 상상이 잘 안되지만 과거에는 Email을 전송할 때 7bit로만 전송하던 시절이 있었다. ISO-2022-KR은 8bit를 사용하는 KSC 5601 문자를 7bit로 전환해서 Email를 전송할 수 있게 하였다. 그럼으로써 ISO-2022-KR을 지원하는 Email 클라이언트에서 한국어 Email을 볼 수 있게 되었다. 코드 중간에 0x0e 문자를 만나면 이제부터 한국어라는 뜻이고 0x0f를 만나면 영어로 간주를 한다. 

지금은 Email을 8bit로 전송할 수도 있고, Base64로 인코딩해서 보내는 방법도 있어서 ISO-2022-KR은 쓸 이유가 점점 없어지고 있다. 또한, Email을 아예 유니코드(UTF-8)로 보내는 비율이 점점 늘고 있다. 유니코드로 Email을 보낸다는 의미는 내가 보낸 Email이 전세계 어디서나 문제없이 볼 수 있다는 의미다. 물론 Email 클라이언트가 유니코드를 지원해야 하며 유니코드 폰트가 존재해야 한다. 아직은 모든 시스템이 유니코드의 모든 문자의 폰트를 포함하고 있지 못하다. 이 이슈는 추후 폰트 관련 글에서 따로 다루겠다.

4. CP949 (인코딩)

마이크로소프트에서 사용하는 한국어 코드페이지다. 원래는 KSC5601을 표현하는 코드페이지였으나 KSC5601에 없는 한글 문자가 많아서 8822자의 현대한글을 추가하였다. 이렇게 문자를 새로 추가하다 보니 한국어 코드의 순서가 가나다 순서와는 다르게 뒤죽박죽이 되는 문제가 있다. 하지만 EUC-KR에서는 표현할 수 없는 많은 문자를 표현 할 수 있다. Windows에서 파일로 “똠방각하”를 저장할 때 ANSI 형식 선택해도 KSC5601에 없는 “똠”라를 저장할 수 있는 이유는 Windows는 EUC-KR 대신 CP949를 선택하기 때문이다. 따라서 CP949의 모든 문자를 EUC-KR 인코딩으로 변환할 수는 없다. 이런 변환 과정을 거치면 몇몇 글자는 깨질 수가 있다. OS에 따라서 한국어 문자가 깨지는 상황이 발생했을 때 OS가 어떠한 인코딩을 사용하는지 살펴볼 필요가 있다.

지금은 위 4가지가 아니라면 거의 유니코드일 것이다. 유니코드에 대해서는 추후 자세히 다룰 것이다.

한국의 개발자는 쓸데없이 바쁘다

한국의 개발자들은 항상 바쁘다. 소프트웨어 개발을 하느라고 바쁜 것이 아니라 쓸데없는 일에 바쁜 것이 문제다. 회사마다 차이는 있지만 많은 회사에서 개발자들은 본연의 개발 업무보다 불필요한 다른 일에 바빠서 정작 본연의 임무인 개발에 투자하는 시간이 얼마 안되는 경우가 많다. 여기서 개발이라 함은 코딩뿐만 아니라, 분석, 설계, 리뷰 등 개발에 필요한 일련의 활동을 모두 말한다.

한국 회사들의 소프트웨어 개발 생산성이 상대적으로 선진 소프트웨어 회사보다 낮은 이유 중 하나는 개발자들이 개발에 전념하지 못하는 환경 때문이다. 

개발자는 고참이 될수록 개발에 집중하지 못하고 다른 일 때문에 바빠진다. 어느 회사의 고참 개발자들은 낮 시간에는 코딩을 한 줄도 못하고 남들 퇴근 후에 개발 일을 한다. 낮에는 이 회의, 저 회의 많이 끌려 다니기 때문에 집중해서 개발 관련 일을 할 수 없어 낮시간은 아예 포기하고 밤에 개발을 한다는 것이다.

코딩, 분석, 설계 관련된 모든 일은 대단히 집중력이 필요하기 때문에 중간에 다른 일로 방해를 받으면 다시 집중하기 매우 어렵다. 하루 종일 방해 받지 않고 집중해서 일할 수 있는 환경은 매우 중요하다. 

하지만 경영자들은 개발자도 시장을 잘 알아야 한다고 말하며 고객을 직접 만나게 하고, 시장 관련 회의에 참석하게 한다. 여러 경영 회의, 전략 회의에도 개발자들을 끌고 다닌다. 그러다보니 개발자들은 보고서도 작성해야 하고 보고 회의도 참석해야 한다.

고참 개발자일수록 이런 회의에 더 많이 불려 다니게 된다. 어쩔 때는 회의에서 꿔다 놓은 보릿자루 마냥 앉아 있기만 하면서 “왜 이런 회의를 참석해야 하나” 한탄을 하지만 회사 요구 때문에 빠지기도 눈치가 보여서 그냥 참석을 하는 경우가 많다. 물론 개발자도 시장, 고객, 경영 등 여러 분야에 대해 알아야 한다. 아키텍트나 팀장인 경우 더 잘 알아야 한다. 문제는 시간의 효율적인 활용이다. 이런 회의에 다 불려 다닌다고 더 잘아는 것은 아니다. 문서로 공유해도 되는 내용을 장시간 회의에 앉아서 시간을 허비하는 경우가 많다.

개발자들은 평가, 교육 활동으로도 많은 시간을 빼앗긴다.  필요한 일들이기는 하지만 너무 많은 시간을 빼앗기는 것이 문제다. 회사 교육담당자는 개발자들에게 교육을 많이 시켜서 도움을 주고 싶어하지만 일괄교육, 집체교육, 의무교육은 개발자들의 개발업무를 방해하는 요소다. 리더 교육을 열심히 한다고 팀장이 뛰어난 리더가 되는 건 아니다. 필요 없는 교육은 아니지만 얼마나 효율적인지는 생각해봐야 한다. 기업에서는 교육보다 실무 자체로 배우는 것이 더 중요하다. 

회의를 많이 하는 회사일수록 커뮤니케이션이 잘 안되고 누가 뭘 하는지 잘 모르는 경우가 많다. 회의가 과도하게 많다는 것은 공유와 협업이 잘 안되고 있다는 반증이기도 하다. 대기업에서 개발자가 더 일하기 힘든 이유가 여기에 있다. 대기업은 회사마다 다르지만 기본적으로 회의도 많고 프로세스도 복잡하다. 정작 진짜 개발하는 시간은 몇시간 안된다. 

그럼에도 대기업이 돌아가는 이유는 우수한 인력과 여유 인력, 자본이 풍부하기 때문이다. 50% 퍼포먼스만 발휘해도 회사는 굴러간다. 이런 비효율이 회사가 잘 될 때는 문제가 안되지만, 어려울때는 큰 약점이 된다. 
그런데 중견기업 중에는 이런 대기업 형태를 따라하는 회사들이 꽤 많다. 회사가 커지다보니 관리의 필요성이 증가해 개발자들의 시간을 점점 빼앗는 것이다. 그러다보면 대기업의 장점인 관리 부문에도 만족하지 못하고 기존의 민첩하고 효율적인 개발 방식도 점점 잃게 된다. 

기본적으로 이렇게 회사에서 개발자들이 개발에 집중하지 못하게 방해를 하는 이유는 개발자를 믿지 못하기 때문이다. 심지어는 초등학생 취급하는 경우도 있다. 개발자들이 알아서 자율적으로 제대로 일할 것이라고 믿지 못하기 때문에 결과는 점점 효율성이 떨어지는 것이다. 

원칙적으로는 개발자는 거의 개발만 해야 한다. 숫자로 얘기를 하면 95% 이상의 시간은 개발에 전념할 수 있도록 해야 한다. 분석, 설계, 리뷰, 코딩 등 개발 활동에 쏟아야 한다. 중간에 방해를 하지 않도록 프로세스, 시스템이 최대한 뒷받침을 해야한다. 

대부분의 회사에서 회의는 10분의 1 정도로 줄여야 한다. 조금이라도 관련이 있는 사람은 잔뜩 불러서 하는 대규모 회의는 특히 삼가 해야 한다. 괜히 일상적으로 모여서 하는 대규모 회의도 줄여야 한다. 필요한 사람 몇명만 불러서 사안 별로 회의를 하면 된다.그렇다고 개발자가 고객, 시장, 전략을 몰라도 된다는 것은 아니다. 시간을 최대한 효율적으로 활용해서 최소 시간을 투자해서 공유를 할 수 있어야 한다. 개발자의 시간은 비싸다. 

실제로 개발자가 하루에 개발에 몇시간을 사용하는지 조사를 해보자. 80% 미만이면 심각하게 생각해야 한다. 그런 개발자는 개발을 포기하고 전문 관리자가 되는 것이 낫다. 그렇지 않다면 무엇인 문제인지 찾아서 문제를 제거하고 개발자들이 개발에 집중할 수 있도록 해줘야 한다. 이슈관리시스템을 제대로 활용하면 불필요한 회의는 많이 줄일 수 있고, 회의를 하더라도 시간을 단축할 수 있다. 회의를 줄이고 효율적으로 하는 방법은 여러가지가 있지만 다음과 같은 원칙을 지키는 것이 좋다. 

대규모 회의보다는 소규모 회의를 하고, 공유는 시스템으로 하고 의사결정이 필요할 때만 회의를 한다. 회의 전에 내용을 미리 공유해서 짧은 시간에 의사결정을 해야 한다. 회의 내용은 관련자 모두에게 즉각 공유해야 한다. 

소프트웨어 개발 경쟁력에서 핵심은 개발자다. 개발자가 많은 시간 개발에 집중할 수 있도록 하는 것은 소프트웨어 경쟁력 향상에서 가장 중요한 일이다. 이렇게 하면서도 공유, 커뮤니케이션에 문제가 없을 수 있도록 하는 것이 개발 문화, 프로세스, 기반 시스템의 역할이다.

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

구멍가게 될텐가? 글로벌 SW기업 될텐가?

나는 소프트웨어 스타트업 및 중소기업 관계자를 자주 만난다. 주로 소프트웨어 개발이나 마케팅 전략에 대해서 얘기를 한다. 최근에도 몇몇 기업의 대표를 만났다. 

대부분의 기업들은 국내 시장에만 머무르지 않고 해외로 진출해서 글로벌 기업으로 성장하기를 원하고 있다. 한 두명이 시작해서 세계적인 회사가 된 뉴스를 보면 우리도 그렇게 될 수 있다는 꿈을 가지게 된다. 그러기 위해서 국내에서 일단 인지도를 쌓고 고객을 확보하여 캐시카우를 만든 후에 이를 기반으로 해외 진출한다는 전략을 가지고 있는 경우가 많다. 

하지만 이런 전략은 계획대로 되지 않는 경우가 많다. 그냥 국내 시장에서 허덕대다가 그저그런 기업으로 남거나 문을 닫는다. 

물론 처음부터 해외시장은 거들떠도 보지 않고 국내 시장에서만 승부를 보는 전략도 있고 분야에 따라서 나쁜 전략도 아니다. 국내 소프트웨어 시장이 세계 시장의 2~3%에 불과하지만 지역특성이 강한 분야도 있어서 효과적인 전략이 될 수도 있다. 

하지만 국내를 발판으로 해외로 나가보자는 전략이 잘 먹혀 들어가지 않는 이유를 알아보자. 

A사는 기업용 서비스를 개발하는 회사인데 처음부터 글로벌 서비스를 목표로 시작을 한 회사다. 충분한 자본을 가지고 시작하지 않았기 때문에 먼저 돈을 벌어야 했다. 그래서 국내에서 몇몇 기업과 계약을 맺어 서비스를 제공했고, 상당 기간 고객들이 원하는 기능에 매달리느라고 글로벌 서비스에 필요한 준비를 별로 하지 못했다.

글로벌 서비스는 모든 프로세스가 완전히 자동화 되어 사람의 수동 개입이 거의 없어야 하는데 국내 고객에 대응을 하다 보니 상당 부분 사람의 노력이 들어가야 하는 반자동 서비스가 되었다. 지금은 고객이 100배로 늘어도 큰일이며 시스템의 구조를 바꾸려면 추가로 개발을 매우 많이 해야 한다. 이미 개발해 놓은 것이 많으므로 시스템 복잡도는 점점 증가하게 되었고, 이 모든 것이 미래 개발의 큰 부담이 되고 있다. 

B사는 기업용 웹 솔루션을 만드는 스타트업이다. 국내 시장에서는 어느 정도 인지도를 쌓았다. 그리고 정부 지원을 받아서 해외 진출을 하기 위해 글로벌 버전을 새로 개발하고 있다. 

국내에서 영업이 꽤 잘되어서 매출액이 급격히 늘었다. 하지만 국내 기업을 지원하느라고 개발자를 많이 채용해야 했다. 그러다 보니 많은 개발자의 월급을 주려면 상당한 매출을 계속 일으켜야 했다. 그렇게 계속 국내 고객을 발굴하고 기업들의 요구사항에 매달리다보니 처음에 계획했던 글로벌 솔루션에 투자할 시간이 점점 줄어들었다. 국내 고객이 캐시카우라서 포기할 수도 없고, 이를 위해서 많은 개발자는 계속 필요하고 이런 고리에서 빠져 나올 수가 없다. 

C사는 유럽의 작은 나라 소프트웨어 회사다. 지원수는 30명 정도지만 전세계 수많은 고객을 가진 글로벌 기업이다. 이 회사의 솔루션은 매우 단순하다. 비즈니스 전략도 단순하다. 구매도 온라인으로 이루어지고 모든 정보는 인터넷에 공개가 되어 있다. 고객지원도 온라인으로만 이루어진다. 서비스데스크 시스템을 통해서 기술문의나 사용문의를 처리하고 있다. 

고객이 전세계에 흩어져 있어서 지원을 요청한다고 방문을 할 수도 없고, 전화 지원도 언어 장벽 때문에 어렵다. 따라서 제품에 대한 문서화가 잘 되어 있고, 모든 지원은 자동화된 프로세스가 잘 구축되어 있다. 그래서 적은 개발 인원과 지원 인력으로 수많은 고객을 지원하는 것이 가능하다. 

글로벌 기업이 목표인 회사에게 국내 시장은 우선 공략 전략은 자칫 빠지기 쉬운 함정이 될 수 있다. 지역이 국내라서, 국내 고객들이 괴팍해서 그렇다는 것은 아니다. 로컬 비즈니스 전략으로 고객별 커스터마이징과 오프라인 지원에 매달리는 전략이 문제라는 것이다. 일단 이런 전략으로 시작한 기업은 '개미 지옥'에 빠진 기업과 같다. 처음에는 이렇게 돈을 번 후 멋지게 빠져나가서 성장을 하고 싶지만, 일단 발을 들여 놓으면 처음에 생각한 것과 다르게 점점 더 깊게 빠져 들어가는 '개미 지옥'이 된다. 

기술적으로도 로컬 제품을 먼저 만들었다가 글로벌 제품으로 성장하는 것은 매우 어렵다. 서비스도 마찬가지다. 패러다임을 완전히 달리 해야 하는 것이라서 처음부터 글로벌 시장을 타깃으로 한 제품을 만들지 않으면 어렵다. 

글로벌 제품의 특성은 다음과 같아야 한다. 

첫째, 소프트웨어 국제화가 잘 되어 있어야 한다. 

소프트웨어 국제화란 여러 언어와 국가를 지원할 수 있는 구조로 만든다는 것인데 국제화 전문가의 도움 없이 제대로 국제화를 하기란 거의 불가능하다. 10년 이상의 소프트웨어 국제화 경험이 있어야만 제대로 국제화를 할 수 있다. 

소프트웨어는 처음에 개발을 시작할 때부터 국제를 하는 것이 가장 좋다.국제화가 안된 소프트웨어도 처음에 영어를 기반으로 개발한 소프트웨어는 나중에 국제화가 용이하지만 그렇지 않은 경우 국제화가 힘들어진다. 또한 영어로 개발된 제품은 국제화를 하지 않아도 영어를 받아들이는 전세계 모든 회사에 판매를 할 수가 있다. 

소프트웨어 자체는 훌륭하지만 국제화에 발목 잡혀서 실패한 회사가 꽤 된다. 번역이 잘 못되거나 해당 국가의 문화나 표기 방법을 고려하지 않거나 개발 비용이 너무 과도하게 들어가서 실패를 하게 된다. 

둘째, 유지보수와 고객지원이 용이하며 거의 온라인으로 지원할 수 있도록 해야 한다. 물론 소프트웨어 품질이 높아서 장애와 지원요청이 별로 없어야 한다. 소프트웨어 장애 시 몇 번의 클릭으로 장애 리포트를 전송할 수 있도록 하고, 개발사에서는 자동으로 분석할 수 있는 시스템이 잘 구축되어 있어야 한다. 고객과는 온라인으로 소통하며 모든 이력은 데이터베이스에 기록되어서 미래의 고객 지원에 활용된다. 

요즘은 고객끼리 정보를 공유하는 서비스를 제공해서 고객지원에 들이는 노력을 더욱 절약하는 기업들이 있다. 

셋째, 기업 내부적으로는 개발에 필요한 문서가 잘 작성되어 있고, 고객에게는 충분한 정보를 문서로 제공한다. 개발 시에 꼭 필요한 문서를 충분히 잘 작성하므로 고객에게 제공되는 사용자 매뉴얼, 기술 백서 등의 문서가 자연스럽게 잘 만들어진다. 그래서 고객들은 문서를 통해서 충분히 정보를 제공 받으므로 지원 요청이 줄어든다. 물론 고객에게 정보를 제공하기 위해서 처음부터 문서화를 잘하는 것이 아니다. 개발 시에 필요한 문서를 제대로 만드는 것이 가장 빨리 개발하는 방법이기 때문에 문서를 잘 적는 것이다. 

넷째, 개별 고객의 요구사항에 흔들리지 않고 개발사가 제품의 로드맵을 주도한다. 고객의 요구사항에 귀를 기울이지만 전체를 파악하는데 노력을 하고 한 고객이 원하는 것에는 휘둘리지 않는다. 이 때문에 잃게 되는 10%의 고객보다는 나머지 90%의 고객을 유지하는데 집중한다. 따라서 소프트웨어를 급하게 개발하지도 않는다. 

다섯째, 고객이 아무리 많아도 소스코드는 한벌인 경우가 많다. 국내 소프트웨어 회사들이 가장 많이 빠지는 함정이 슈퍼 고객을 지원하기 위해서 소스코드가 갈라지거나 국제화를 위해서 별도로 개발을 하는 것이다. 눈앞의 이득만 쫓다가 수십배의 손해를 보는 경우가 허다하다. 

글로벌 회사를 계획했지만 캐시카우를 만들기 위해서 로컬 비즈니스와 커스트마이징 또는 SI를 해야 밖에 없는 상황이 있을 수도 있다. 하지만 이런 전략은 "개미 지옥"과 같다는 것을 명심하자. 절대로 빠져오지 못할 만큼 깊게 빠지지는 말아야 한다. 정신을 똑바로 차리고 있지만 않으면 영원히 못 빠져 나온다. 

가장 좋은 방법은 마약에 빠지지 말고 처음부터 글로벌 전략을 펼치는 것이다.

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