사이냅소프트 강중빈 상무

개발 프로세스도 유행을 탄다. 애자일 방법론 중에서도 스크럼(Scrum)이 대세인 것 같더니 이제는 칸반(Kanban)이 뜬다고 한다. 하지만 소프트웨어(SW) 회사에서 개발 프로세스는 개발 문화를 좌우하는 중요한 요소 중 하나이다. 유행하는 프로세스를 쫓아가다 정작 중요한 개발문화를 제대로 싹틔우지 못하면 곤란하다.

​

그런면에서 웹 문서 솔루션 업체 사이냅소프트는 독특한 개발 방법론과 문화를 만들어 가고 있어 주목된다. 최근 사이냅소프트를 찾아가 지난 8년간 회사가 추구해온 개발 방법에 대한 이야기를 들어봤다.

​

사이냅소프트 강중빈 개발본부 상무는 “동작하는 SW를 만드는 것이 개발 조직의 중요한 모토이며 그런점에서 실용적이고 실제적인 능력을 갖출 수 있는 방식으로 조직을 운영하고 있다”고 설명했다.

​

사이냅소프트 사무실엔 시선 닿는 곳마다 ‘품질은 우리의 자존심’, ‘100% 코드리뷰’, ‘테스트 자동화’라고 적힌 포스트가 붙어있었다. 동작하는 SW를 만들자는 모토가 공허한 구호만은 아닌듯 보였다.

​

사이냅소프트는 국내SW 업체 중 애자일 방법론을 빨리 접한 회사로도 알려져 있다. 회사가 처음 애자일 컨설팅을 받은 건 2007년이다. 애자일에 관심을 갖은 이유도 “품질관리를 잘해보자”라는 생각에서다. 강중빈 상무의 설명에 따르면 2007년 당시엔 대기업에서도 버전관리나 이슈트래킹의 중요성을 잘 모르던 때인데 사이냅소프트는 나름 신문물을 일찍 받아들인 편이다.

​

하지만 지금 사이냅소프트는 내부에서 애자일이라는 용어를 거의 사용하고 있지 않다. 스프린트, 회고, 지속적인통합(CI), 짝프로그래밍 등 애자일에서 사용되는 중요한 프랙티스를 채택하고 있지만 회사 환경에 맞게 적용해 정석적인 애자일 방법과는 거리가 있기 때문이다.

​

사이냅소프트는 남들보다 조금 일찍 애자일 방법론을 접하면서 ‘좋다고 다하는 게 능사는 아니다’라는 교훈을 얻었다고 한다. 회사가 목표로하는 품질관리에 필요한 요소를 적극적으로 받아들이되 원리원칙대로 적용하지 않아야 소화할 수 있다는 걸 일찍 깨달은 것이다.

​

강중빈 상무는 "개발 기법이 잘 차려놓은 코스 요리라면 그것을 소화할 수 있는 것은 각 조직의 상황과 여건에 따라 다르다”며 "‘OO 기법’이라는 프레임 안에 갇히게 된다면 정작 처음의 도입 목적을 잃을 수 있기 때문에 각 개발 조직에 맞게 작게 시도하고 그것을 체화하는 것이 중요하다”고 말했다.

​

이런 이유로 회사는 애자일이라는 틀에 갇히기 보다 상황에 맞는 요소들을 도입해 나름의 체계를 갖추는데 노력을 기울였다. 강 상무는 “매번 동작하는 SW가 주기별로 나오게 한다는 큰 전제”아래 사이냅소프트의 개발 프로세스가 운영되고 있다고 설명했다.

​

사이냅소프트는 개발 주기를 크게 마일스톤 단위로 잡고 사이사이를 스프린트로 나눠 반복적으로 수행하고 있다. B2B 제품을 개발하는 만큼 사업팀이나 전략팀에서 가져오는 요구사항과 개발팀 내부에서 리팩토링 할 사항들을 모아 놓고 스프린트를 시작한다.

​

매일 아침 스탠딩 미팅으로 진행하는 선별회의를 통해 이슈가 할당된다. 개발자들은 자신이 잘할 수 있을 것 같은 이슈를 자발적으로 가져간다. 이슈관리는 지라를 통해하고 있다. 개발자들은 소스버전 관리 툴에서 최신 업데이트된 버전을 받아 작업하고 퇴근 전 커밋한다. 모든 프로젝트가 오픈돼 있기 때문에 누가 어떤 코드를 작성했는지 훤히 볼 수가 있다.

​

하루는 일일회고로 마감한다. 일일회고 때는 선별회의 때 나온 이슈에 대해서도 이야기 하지만 주로 하루 힘들었던 점이나 좋았던 점을 많이 이야기한다. 이런 감성공유를 통해 팀원들 서로가 어떤 도움이 필요한지 자연스럽게 알게 된다고 한다.

​

새벽에는 자동으로 테스트와 빌드가 이뤄진다. 지속적인 통합(CI)를 통해 빠르게 실패를 알아내고 개선하기 위해서다. 제대로 빌드가 되지 않은 것들을 다음날 출근해 신속하게 고치게된다. 품질관리 높이기 위해 CI툴에 정적분석(static analysis) 플러그인도 추가해 사용하고 있다. 코드를 실행시키지 않아도 잠재적인 오류를 찾아내 알려주고 세팅된 코드 컨벤션에 맞지 않은 코드를 짜면 경고 표시를 띄워준다.

​

코드가 프리즈(통합 빌드하기 위한 단계)되면 그 묶음이 품질팀(QA)에 넘어가고 명세대로 잘 만들어졌는지 확인하는 단계를 거친다. QA팀은 얼토당토 않은 실수가 없는지 살펴보는 스모크테스트(새너티 체크)부터 회귀체크테스트까지 다양한 수준의 테스트를 진행한다. 출시가능(Sign off) 여부를 승인하는 일도 QA팀의 일이다.

​

개발팀은 QA팀에서 받은 테스트케이스(TC)와 새로운 요구사항을 바탕으로 다시 이슈를 선별하고 사이클을 반복한다. 테스트와 개발이 맞물려 돌아가는 구조다. 보통 2주단위로 스프린트가 돌아간다.

​

역시 스프린트가 끝날 때마다 스프린트회고를 한다. '예정된 대로 잘 진행됐는지’, '어떻게하면 더 잘 할 수 있는지’에 대해 이야기한다. 물론 마일스톤 회고도 진행한다.

​

사이냅소프트는 지금처럼 잘짜여진 개발 프로세스를 갖추기 위해 상당한 노력을 들였다. 강중빈 상무는 “2007년에 이어 제작년에도 개발 방법론에 대한 컨설팅을 한번 더 받았고 중소기업이지만 도움이 된다면 상용툴도 적극적으로 도입해서 사용하고 있다”고 설명했다.

​

회사는 프로세스안에서 품질을 높이기 위한 방안을 계속 고민하고 있다. 최근엔 동료의 코드리뷰를 받지 않으면 커밋할 수 없게 하는 깃랩(GitLab)이라는 코드리뷰 툴도 활용하고 있다. 강중빈 상무는 “여러가지 사정으로 리뷰를 빼먹을 가능성이 있기 때문에 일종의 강제 리뷰제도로써 동료 리뷰를 강조할 계획”이라고 말했다.

​

너무 잘 짜여진 프로세스가 개발자들에게 업무 부담으로 다가오진 않을까? 강 상무는 선별회의, 코드리뷰, 회고 등을 거치면 문제가 작은 상태일 때 빨리 찾아 해결할 수 있어, 진짜 큰 문제가 터지는 것을 막아준다고 강조했다. 강 상무는 “잘 짜여진 프로세스 때문에 오히려 시원하게 하루를 마감하고 꼭 필요한 야근이 아니면 안하는 문화가 자리 잡았다”고 말했다.

​

아무리 프로세스가 잘 갖춰져 있다해도 구성원들이 따라주지 않으면 아무 소용이 없다. 그런이유에서 사이냅소프트는 배우고 성장하자하는 의지가 강한 개발자를 선호한다. 강중빈 상무는 "면접과정에서 실기면접을 통해 코딩능력뿐만 아니라 문제가 주어졌을 때 해결하는 과정과 태도를 중요하게 본다”고 설명했다.

출처: http://m.zdnet.co.kr/news_view.asp?article_id=20151103100740

이번 달은 SI와 솔루션 개발의 차이에 대해 다섯 가지 분야로 살펴보고 있다. 이번 회는 네 번째 시간으로 개발에 대해 살펴본다. SI도 완성하고 나면 패키지 형태의 소프트웨어로 볼 수 있기 때문에 일부 개발자들은 SI에서 개발하는 소프트웨어도 솔루션이라고 말하기도 한다. 하지만 이전 회에서도 가조했지만, SI와 솔루션 개발은 요구사항을 고객이 주는가 아니면 개발 프로젝트에서 자체적으로 정리하는가 하는 것으로 구분하는 것이 좋다. 솔루션 개발은 개발자에게 솔루션의 기획 단계에 반드시 참여할 것을 요구한다.

개발자가 기획 단계에 참여한다는 것은 많은 의미를 가지고 있다. SI에서 개발자는 거의 모든 것을 고객의 요구사항에 맞추어야 한다. 심지어는 화면 디자인까지 고객에게 확인을 받아야 하기 때문에 개발자는 '요구사항 정의서'에 맞추어 개발만 하면 됐다. 하지만 솔루션 기획에 참여하게 되면 개발자는 이전의 개발 경험과 의견을 충분히 전달 할 수 있고, 솔루션에 대한 많은 공감을 가지고 개발을 시작한다. 따라서 개발자는 코딩만 잘하는 것이 아니라 솔루션을 기획, 평가하는 역할까지 해야 한다. 이처럼 개발자가 직접 기획, 계획, 개발하는 솔루션은 일반적으로 완성도나 만족도가 높게 나타난다.

이번 회에서는 SI와 솔루션의 개발 방향을 살펴보면서 어떻게 다른지 확인하고, SI와 솔루션 개발자의 역할에 대해 살펴본다. 그리고 솔루션 개발에 필요한 자동화 도구에 대해서도 살펴본다.

SI와 솔루션의 개발 방향

SI는 고객의 요구사항을 분석하여 아키텍처로 나타낸다. 아키텍처는 소프트웨어를 구성하는 소프트웨어 아키텍처, 시스템을 구성하는 인프라 아키텍처, 그리고 데이터를 구성하는 소프트웨어 아키텍처, 시스템을 구성하는 인프라 아키텍처, 그리고 데이터를 구성하는 데이터 아키텍처를 포함한다. 이 밖에 애플리케이션 아키텍처 등과 같은 다양한 아키텍처들이 더 존재 할 수 있다. 여기서 중요한 포인트는 고객의 요구사항을 아키텍처로 정의한다는 것이다. 고객은 자신이 만들고자 하는 시스템이나 소프트웨어가 어떤 모습인지 대부분 알지 못한다. 따라서 고객이 원하는 모습을 미리 보여줄 필요가 있으며, 이러한 모습을 기준으로 개발을 진행한다. SI 프로젝트에서 가장 중요한 역할은 아키텍처라고 말하는 이유가 바로 여기에 있다.

아키텍처를 크게 고민하지 않던 초기 SI에서는 프로세스, 이벤트, 데이터 모델을 만들어 내고, 이 모델을 기준으로 개발이 진행되었지만 고객이나 개발자도 이해하기 어려웠기 때문에 개발에 적극 활용되지는 못했다. 아키텍처는 고객이나 개발자가 한눈에 보기에 매우 용이했기 때문에 커뮤니케이션이나 개발에 중요한 자료로 활용되었다. <그림 1>은 SI 프로젝트의 개발 방향을 나타낸다. 요구사항을 분석한 후, 해당 내용을 아키텍처를 정의하고 점진적인 개발을 하게 된다.

<그림 1> SI 프로젝트의 개발 방향

<그림 2>는 반복, 점진적인 방법으로 아키텍처를 정의하는 것을 나타내고 있다. 사용자 요구사항을 파악하여 아키텍처 초안을 작성하고, 이를 정리하여 아키텍처를 설계한 후 개발을 하게 된다. 추가 요구사항이 있을 경우 아키텍처를 보완하여 개발한다. 이처럼 SI에서 아키텍처는 개발에 매우 중요한 요소이며, 아키텍처 없이는 개발이 어렵다고 해도 과언이 아니다. 왜냐하면, SI는 요구사항이 처음부터 정해져 있어 요구사항을 모두 반영한 아키텍처를 먼저 정의해 놓아야 고객과 커뮤니케이션도 쉽고 개발 방향도 명확해지기 때문이다.

<그림 2> 반복, 점진적 아키텍처 정의

그리고, SI 개발의 또 다른 특징은 기능의 대부분이 입력, 수정, 조회, 삭제이라는 것이다. SI개발이 3D 업종이라고 얘기하는 이유가 단순 기능의 반복적인 개발이 많기 때문이다. 하지만, 이러한 것은 처음부터 필요에 의해서 시스템이나 소프트웨어를 만드는 SI에서는 어쩔 수 없이 나타나는 현상이다. 솔루션 개발은 이처럼 단순 기능 개발에서 탈피하고자 하는 소프트웨어 개발 회사를 중심으로 발전 되었다.

솔루션은요구사항이 미리 정해진 SI와는 다르게 소프트웨어를 사용하는 사람의 입장을 조사하여 소프트웨어를 정의해 나간다. 솔루션이 '고객'이라고 하지 않고, '사용자'라고 하는 이유도 여기에 있다. 사용자가 직접 요구사항을 전달하는 것이 아니라, 사용자가 무엇이 필요할지 조사하고 고민해서 명확히 정리하는 것이 솔루션의 성공 요인이다. 따라서 솔루션은 사용자 중심으로 개발 방향을 맞춰야 한다. <그림 3>은 솔루션의 사용자 중심 개발 단계를 나타내고 있다.

<그림 3> 솔루션의 사용자 중심 개발 단계

자료: 반준철의 오래가는 UX디자인

솔루션 개발 초기에는 요구사항이 없기 때문에 솔루션은 사용자가 필요한 것이 무엇인지 조사하는 것이 매우 중요하다. <그림 3>을 살펴보면, 사용자 조사 후 인터랙션을 정의하고 프로토타입을 기준으로 개발을 하게 되고, 이를 반복하여 최종 솔루션을 완성하게 된다. 이 때, 사용자 조사에서 나온 결과는 스토리 형태로 정리를 하게 되는데 이 것을 '사용자 스토리'라고 한다. <그림 4>는 XP 프로젝트에서 사용자 스토리 중심으로 개발하는 예를 나타낸 것이다. 사용자 스토리가 요구사항이 되고, 요구사항에 따라 개발 계획을 세운 후 개발을 하게 된다.

<그림 4> 사용자 스토리 중심의 개발(예)

물론, 최근에는 SI 프로젝트에 솔루션을 적용하여 개발하는 경우도 있다. 매번 아무것도 없는 상태에서 개발을 하게 되면 비용과 시간이 너무 많이 소비되기 때문에 필요한 솔루션들을 미리 선정하여 적용한다. 이 때, 적용되는 솔루션은 아키텍처에서 확인 할 수 있도록 아키텍처를 정의한다.

SI와 솔루션 개발 방향의 차이를 정리하면 <표 1>과 같다.

<표 1> SI와 솔루션 개발 방향 비교

SI와 솔루션 개발자의 역할

SI와 솔루션 개발자의 역할은 매우 다르다. 그 중에서도 가장 크게 다른 점은, SI는 5년차 이하의 경력을 가진 팀원이 개발자로 활동하고, 솔루션은 경력과 상관없이 개발자로 활동하는 경우가 많다. 그 이유는, SI는 입력, 수정, 조회, 삭제와 같은 단순 기능 개발이 많기 때문에 경력이 크게 필요하지 않다. 이와 달리, 솔루션은 새로운 기능을 개발하는 경우가 많아 다양한 경력을 요구하는 경우가 많다.

<그림 5>는 SI 프로젝트의 역할자와 역할을 나타낸 것이다. 고객 중심으로 요구사항을 명세화 하고, 이를 바탕으로 분석, 설계자 중심으로 설계를 한다. 그리고 개발자가 개발을 한 후 테스트를 하게 된다.

<그림 5> SI프로젝트의 역할자와 역할

<그림 5>를 자세히 살펴보면, 요구사항은 SI프로젝트 시작 전에 이미 정해져 있고, 설계된 내용은 바꿀 수 없이 개발자에게 전달된다. 또한 개발자는 정해진 개발 툴과 가이드에 따라 개발을 하기 때문에 SI 개바라는 정해진 틀에서 벗어나지 못하는 구조를 가지고 있다. 하지만, SI개발자는 프로젝트를 수행할 때마다 새로운 비즈니스를 접할 수 있기 때문에 다양한 경험을 할 수 있다는 점도 있다.

솔루션 개발자는 모든 솔루션 개발 프로세스에 참여 한다. 사용자 스토리 중심으로 개발을 하기 때문에 사용자 스토리를 파악하는 사용자 조사부터 개발 계획 수립, UX 개발, 소프트웨어 개발, 내부 테스팅, 릴리즈, 사용자 지원 및 피드백 등 모든 프로세스에 참여하고, 경우에 따라 필요한 역할자를 변경해가며 수행한다. 예를 들면, 사용자 조사에서는 마케터, UX 개발에는 UX 개발자, 테그팅에는 테스터 역할을 수행 할 수 있다. 이러한 내용이 <그림 6>에 나타나 있다.

<그림 6> 솔루션 프로젝트의 역할자와 역할

솔루션 개발자는 SI 개발자와는 다르게 다양한 역할과 경험을 할 수 있다는 좋은 점이 있지만, 이러한 역할을 수행하기 위해 다양한 역량을 쌓아야 한다는 부담도 있다. <표 2>는 SI와 솔루션 개발자의 역할을 비교하였다.

<표 2> SI와 솔루션 개발자 역할 비교

솔루션 개발 자동화

S는 소프트웨어의 개발을 수월하게 하기 위해 필요한 기능의 일부 또는 전체를 미리 구현하여 재사용 하도록 프레임워크를 활용하는데, 완성된 후에는 유지보수 외에 개발을 하는 경우는 많지 않기 때문에 프레임워크 활용도가 떨어지는 편이다. 하지만 솔루션의 경우, 완성 후에도 버전 업그레이드를 위해 지속적인 개발이 진행된다. 따라서 한 개의 버전에서 진행되었던 개발, 테스트 등을 다음 버전에서 재사용할 수 있는 것들이 많다. 특히 이러한 재사용을 자동화 한다면 많은 비용과 시간을 절약 할 수 있다. SI보다 솔루션에서 자동화 도구가 많이 사용되는 것이 이러한 이유 때문이다. 이러한 자동화 도구는 솔루션의 최초 버전부터 버전까지 테스트, 빌드, 배포를 동일한 환경에서 제공할 수 있어 높은 완성도와 신뢰도를 얻을 수 있다. 테스트 자동화에 대해서는 공학트렌드 이전 회에서 다룬 바 있어 제외하고, 빌드와 배포 자동화에 대해 알아본다.

빌드 자동화

CI(Continuous Integration)도구는 개발자가 개발한 소스 코드를 모아서 한꺼번에 빌드하는 과정을 특정 시점이 아니라 매일, 매주와 같이 주기적으로 수행함으로써 통합에서 발생하는 오류와 시간을 줄여준다. 애자일의 일종인 XP(Extreme Programming Community)에서 Kent Beack에 의해서 고안된 방법이다. CI 도구는 소스 코드를 관리하면서 소스 코드가 수정될 경우 자동으로 빌드를 수행한다. 이때, 빌드가 이루어지는 시점은 <표 3>과 같이 두 가지로 정리 할 수 있다.

<표 3> CI 도구의 자동 빌드 시점

CI 도구에 대한 프로세스는 <그림 7>과 같다. <그림 7>을 살펴 보면, 개발자는 출근해서 최신 소스 코드를 받아 개발을 수행하고 테스트를 작성한 후, 로컬에서 빌드 및 테스트를 진행한다. 그리고, 필요하다면 테스트 코드의 커버리지 분석과 코드 인스펙션도 추가로 진행한다. 마지막으로 완료된 소스 코드를 소스 관리 시스템에 저장하고 커밋한다. CI도구는 이렇게 작성된 소스 코드를 받아 소스 코드에 내장되어 있는 빌드 스크립트를 실행하여 컴파일 하고, 테스트 서버에 배포한 후 테스트를 수행한다. 필요하다면, 커버리지 분석과 코드 인스펙션을 수행하고 리포트를 생성한다. 모든 과정이 정상적으로 수행되었다면 현재 버전을 저장(소스 태깅)한다.

<그림 7> CI도구 프로세스

자료: BEA Systems Korea의 Hudson을 이용한 빌드와 테스트의 자동화

이렇게 빌드 자동화가 종료될 때, 만약 실패인 경우에는 이전 버전으로 롤백하고, 성공한 경우에는 커버리지 분석 결과나 테스트 결과를 분석해서 테스트를 수정하거나 보강하도록 한다.

배포 자동화

이번에는 배포 자동화에 대해 알아본다. 몇 개 안되는 서버에 배포한다면 수동이라도 가능하겠지만, 여러 환경의 수십 대 이상의 서버에 배포해야 한다면 수동으로는 어렵다. 그래서 CI도구로 빌드를 완료한 후, CD(Continuous Deployment)도구를 이용해 <그림 8>과 같이 배포를 자동화 한다. 그리고, CD도구는 <표 4>와 같이 세 가지 형태로 나눌 수 있다.

<그림 8> CD도구를 활용한 배포 자동화

자료: BEA Systems Korea의 Hudson을 이용한 빌드와 테스트의 자동화

<표 4> CI 도구의 자동 빌드 시점

배포 자동화 도구인 Capistrano에서는 배포 시 고민해야 할 사항으로 <표 5>와 같이 네 가지를 가이드 하고 있다. 최근의 솔루션 트렌드는 신속하고 적기에 서비스를 오픈해야 살아남을 정도로 너무나 많으 제품이 쏟아지고 있다. 소프트웨어 개발도 사람이 하는 것이기 때문에 언제나 오류가 나타날 수 있다. 따라서 검증된 자동화 도구를 사용하여 빠른 배포 주기를 유지하고 오류가 발생했을 때 자동으로 대처할 수 있도록 해야 한다.

<표 5> 자동화 배포 시 고민해야 할 사항

소프트웨어를 만드는데 가장 중요한 것은 최초에 의도한 형태로 만드는 것이다. SI프로젝트에서는 고객의 변심이나 개발자들의 소프트웨어에 대한 공감 부족으로 프로젝트가 진행되면서 많이 변해 가는 것이 사실이다. 하지만 솔루션의 경우 최초에 의도한 바가 개발이 완료될 때까지 유지되는 경우가 많다. 개발 초기에 솔루션에 대한 공감대를 형성하였고 폭포수 모델을 기초로 한 기존의 개발 프로세스보다는 커뮤니케이션 위주의 프로세스가 많이 강조되고 있기 때문이다.

이번 회에서는 SI와 솔루션 개발에 대한 차이에 대해 살펴보았고, 이를 기준으로 개발자의 역할을 알아보았다. 그리고 솔루션을 효율적으로 유지 관리 할 수 있는 자동화 도구에 대해서도 알아보았다.

SI개발이 줄어들고 솔루션 개발이 증가하는 것은 최근 변화하는 소프트웨어 사용자 환경의 변화로 볼 수 있다. 또한 앞으로 이러한 현상이 더 심화될 것으로 보인다. 소프트웨어 개발자가 지금 시점에 준비해야 할 것은 새로운 개발 환경의 코딩 기술이 아니라 사용자가 원하는 것을 솔루션에 잘 반영하는 트레이닝을 해야 할 것이다. 솔루션이 SI 와 가장 다른 점은 개발자가 소프트웨어의 기획에 참여하고, 이를 소프트웨어에 잘 반영해야 하는 역할과 책임이 있다는 것이다.

출처: http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000033093&currPage=&searchPrefaceId=&titOrder=&writeOrder=&regDtOrder=&searchCondition=TOT&searchKeyword=

이대론 대한민국 미래없다

유사 인증 두세 개 받아야 공기관 납품…중소기업은 괴롭다

‘유사 인증’이 남발되면서 인증제도가 본래의 도입 취지와 달리 기업의 부담이 되고 있다는 지적이 나온다. 사진은 카시트 안전 인증시험 장면. 한경DB

중소기업 제품의 품질 향상과 판로 확대를 돕기 위해 도입된 인증제도가 기업 경영의 큰 걸림돌로 변질됐다는 지적이 나오고 있다. 비슷한 인증을 중복해서 받아야 하고 매년 인증 사용료를 내야 하는 등 관련 부담이 커지면서다.

인증은 제품이나 서비스가 일정 조건을 충족했다는 것을 증명해주는 제도다. 의무 인증과 임의 인증으로 나뉜다. 국민의 안전과 직결된 의무 인증과 달리 임의 인증은 강제성이 없다. 하지만 해당 인증을 취득하지 않으면 공공 조달시장에 진입하기 어렵기 때문에 이 시장이 주요 판매처인 중소기업에는 사실상 강제 인증에 가깝다. 

○중복 인증으로 부담 증가 

인증제도 자체는 기업 경쟁력 제고 등 순기능이 적지 않다. 하지만 ‘유사 인증’의 남발로 초래된 ‘과잉 인증’은 또 하나의 규제가 될 우려가 높다. 국가기술표준원에 따르면 임의 인증 건수는 2005년 51건에서 올해 130건으로 두 배 이상으로 증가했다. 지난 5월 중소기업중앙회가 인증 취득 경험이 있는 중소기업 510개를 조사한 결과 이 기업들은 평균 10.0개의 인증을 보유하고 있다고 답했다. 또 관련 비용으로 연간 3000여만원을 지출하는 것으로 조사됐다.

예컨대 중소 소프트웨어 개발업체인 A사는 지난 4월 행정자치부의 ‘행정업무용 소프트웨어 인증’을 받는 데 시험비 150만원을 썼다. 공공 조달시장에 제품을 팔기 위해서는 정부전자조달시스템인 ‘나라장터’에 등록해야 하는데, 이를 위해 해당 인증이 필요하기 때문이다. 하지만 한 달 뒤에 비슷한 내용의 인증인 미래창조과학부의 ‘소프트웨어 품질 인증’을 받는 데 350만원을 추가로 냈다. 해당 인증을 받으면 공공기관이 다른 제품보다 우선 선택해야 하는 ‘우선구매제도’의 혜택을 받을 수 있기 때문이다.

감사원에 따르면 2010년 1월부터 지난해 10월까지 ‘행정업무용 소프트웨어 인증’을 받은 제품 184개 중 26.1%인 48개가 ‘소프트웨어 품질 인증’도 받은 것으로 나타났다. 

이외에도 환경부의 ‘탄소성적표지 인증’과 ‘환경성적표지 인증’, 농림축산식품부의 ‘술 품질 인증’과 ‘전통식품 품질인증’, 산업통상자원부의 ‘항공우주분야 성능검사 및 품질검사 인증’, 국토교통부의 ‘항공기 등 형식증명 및 기술표준품 형식승인’ 등도 시험 항목과 통과 기준이 비슷한 중복 인증으로 꼽힌다. 김문겸 숭실대 벤처중소기업학과 교수는 “사실상 똑같은 인증이 수두룩하고 차이가 크지 않은 인증도 많아 기업의 부담이 되고 있다”며 “인증제도를 전면 개편해야 한다”고 말했다. 

○매년 사용료 지급하기도 

과도한 인증 비용도 중소기업의 부담이다. 대부분 유효기간이 2~5년에 불과해 정기적으로 인증 비용이 발생한다. 같은 원료로 만들고 성능도 같지만 모양이 다르다는 이유로 인증을 따로 받는 경우도 있다. 조명기구 제조업체 관계자는 “고효율 기자재 인증을 통과한 조명기구에 구매업체의 요구로 5㎝ 조금 넘는 각도조절장치를 추가했는데 인증을 다시 받으라고 해서 200만원을 추가로 냈다”고 말했다. 

건축자재의 하나인 고무발포단열재도 원료는 같지만 제품의 크기가 다양해 수백 개의 파생 제품마다 인증 수수료가 부과된다. 예컨대 환경표지 인증은 변형된 제품 품목당 5만원을 내야 한다. 또 한 번 인증받으면 유효 기간이 끝날 때까지 매년 사용료도 내야 한다. 사용료는 연간 최대 1100만원이다.

사무용 가구 제조업체 관계자는 “보통 중소업체의 영업이익이 매출의 5% 수준인데 환경인증을 받고 유지하기 위한 비용만 매출 대비 최고 3%에 달해 연구개발비용을 늘리지 못하고 있다”고 말했다.

■ 인증제도 

인증은 제품과 서비스 등이 특정 요건을 충족시켰는지를 정부가 정한 시험기관이 보증하는 제도다. 전기용품 안전 인증 등 국민의 안전, 보건 등과 관련한 의무 인증은 반드시 취득해야 한다. 반면 신기술 인증 등 임의 인증은 강제성이 없다. 하지만 취득하면 공공 조달시장에서 우선구매 대상에 포함되는 등 혜택을 준다.

김주완 기자 kjwan@hankyung.com

출처: http://www.hankyung.com/news/app/newsview.php?aid=2015103080341

불과 얼마 전까지만 해도 소프트웨어는 기관이나 기업에서 필요에 의해 만들어지는 경우가 대부분이었다. 컨설팅이 고객에게 시스템의 필요성을 전달하고 고객은 필요한 예산을 확보한 후 SI(System Integration) 프로젝트로 이어지는 흐름이었다. 하지만 최근에는 어느 정도 구축이 완료된 상태인 ICT의 투자 필요성이 많이 줄어들었고 오픈 플랫폼, 클라우드와 같은 다양한 ICT 기술이 나타나면서 SI 사업은 예전보다는 많이 줄어들고 있는 추세다.

이와는 반대로, 모바일 디바이스와 같은 개인용 기기가 늘어나면서 불특정 다수가 사용하는 솔루션 소프트웨어가 증가 추세에 있다. 솔루션 소프트웨어는 고객이 미리 정해져 있지 않기 때문에 소프트웨어를 개발하는 프로세스나 방법이 SI와는 다소 상이한 편이다. SI는 고객의 요구사항을 파악하고 분석하는데 많은 시간을 할애하지만 솔루션은 개발과 딜리버리, 그리고 업그레이드 등에 많은 시간을 할애한다. 다수의 사용자가 원하는 소프트웨어를 개발하고 오랫동안 사용될 수 있도록 서비스하고 업그레이드를 해야 하기 때문이다.

SI와 솔루션 소프트웨어의 차이를 좀 더 체계적으로 확인하여 소프트웨어 개발에 도움을 주고자 이번 달에는 SI와 솔루션 개발의 차이를 아키텍처, UX, 테스트, 그리고 개발 관점으로 알아보고자 하며, 이번 회에서는 아키텍처 관점으로 차이점을 살펴보기로 한다. 먼저, SI의 아키텍처와 솔루션 아키텍처의 구성과 역할에 어떤 차이가 있는지 알아보고, 두 아키텍처의 설계 프로세스를 비교하여 차이점을 살펴보기로 한다.

아키텍처 구성과 역할의 차이

아키텍처 구성의 차이

사전에서 정의하는 아키텍처란 컴퓨터 시스템의 컴포넌트를 배치하고 통합하는 방식으로 나타나 있고, IEEE에서는 시스템을 구성하는 요소를 식별, 정의하고 그들 간의 관계를 설정해 놓은 기본적인 구조체, 그리고 설계와 전개에 대한 가이드 원칙으로 나타나 있다. 아키텍처는 다양한 의미로 해석되고 활용되지만 한마디로 요약하면 “시스템의 구조체”라는 것이다. 시스템을 만들기 위한 기본적인 요소를 비즈니스, 애플리케이션, 데이터, 기술로 나누어 구성한다. 이러한 4개의 구성을 계획자, 분석자, 설계자, 개발자의 관점으로 살펴본다면 <그림 1>과 같이 나타낼 수 있다.

SI는 고객의 요구사항에 맞춰 시스템을 구성하기 때문에 시스템 개발 초기에 기술적으로 시스템의 큰 그림을 그리는 성향이 강하다. SI는 시스템의 뼈대를 만들고 그에 맞춰 살을 붙여가는 것을 고객에게 보여주면서 완성해야 하기 때문이다. 솔루션은 고객의 요구사항을 전달받기보다 프로젝트 팀에서 사용자가 원하는 것을 자체적으로 파악하는 경우가 많기 때문에 소프트웨어를 개발하는 자체에 더 초점이 맞춰져 있다.

이러한 이유로, <그림 1>을 살펴보면 SI는 세부 기술과 관련된 데이터, 기술 아키텍처에 집중하는 성향이 강하고, 솔루션은 비즈니스, 애플리케이션에 집중하는 성향이 강하다. 이해관계자 관점에서 본다면, 전사적인 모델을 구축하는 계획자, 분석자는 SI 개발에서 더 많은 역할을 하고, 직접적으로 소프트웨어 개발을 하는 설계자, 개발자는 솔루션 개발에서 더 많은 역할을 한다.

아키텍처 역할의 차이

앞에서 살펴본 것처럼 아키텍처의 가장 큰 역할은 고객, 프로젝트 팀원과 같은 이해관계자들 간의 의사소통 수단이다. 특히 SI 프로젝트 초기에는 시스템의 실체가 없기 때문에 시스템의 뼈대를 보여주는 아키텍처의 중요성은 매우 높다. 또한 SI에서 아키텍처는 프로젝트를 성공시키기 위해 필요한 기술적인 접근방법, 프로젝트 위험을 최소화하기 위한 기준과 가이드 등을 제시하여 이해관계자의 의사결정과 프로젝트 관리계획을 수립하는데 가장 중요한 역할을 한다. 아래는 SI에서 아키텍처의 역할을 정리한 내용이다.

• 이해관계자 간의 의사소통 수단

• 기술적으로 집중해야 할 사항을 결정

• 시스템의 초기 설계 결정의 기준과 가이드 제공

• 프로젝트에서 일어나는 기술적인 문제점을 최소화

• 재사용 가능한 추상화 모델 수립

SI에서 아키텍처는 위에서 보는 것처럼 만들고자 하는 시스템에 대한 의사소통과 의사결정을 위한 추상화 모델의 역할이라고 할 수 있지만, 솔루션에서 아키텍처는 불특정 다수가 사용하는 소프트웨어를 설계하고 개발하는 원칙과 개발 후 배포, 기능 추가, 업그레이드에 유연하게 대처하는 모델을 수립하는 역할이라고 볼 수 있다. 아키텍처의 구성 별 역할을 <표 1>과 같이 정리하였다.

<표 1> 솔루션 아키텍처의 역할

위와 같이 솔루션에서 아키텍처는 누가, 언제, 어떻게 사용하더라도 유연하게 대처하는 모델을 수립하는 것이 가장 중요하다. 또한 대개 완성 후 개발이 종료되는 SI와는 다르게 솔루션은 배포, 기능 추가, 업그레이드에 대한 전략이 반드시 필요하고, 관리 측면에서는 소프트웨어의 버전을 관리하는 버저닝(Versioning) 전략도 고려해야 한다.

SI 아키텍처와 솔루션 아키텍처 비교

앞에서 살펴본 것처럼, SI는 고객이 요구하는 소프트웨어이고 솔루션은 구체적인 목표가 없는 상태에서 필요에 의해 만들어지는 소프트웨어이기 때문에 SI 아키텍처와 솔루션 아키텍처는 무슨 소프트웨어를 만들 것인지 목적이 다르다. 따라서 구성되는 아키텍처의 특징도 <표 2>와 같이 다르게 나타난다.

<표 2> SI 아키텍처와 솔루션 아키텍처의 특징

<표 2>를 살펴보면, SI 아키텍처는 기술적인 요소가 반드시 포함되고 그에 따라 개발이 진행된다. 하지만, 솔루션 아키텍처는 설계와 개발이 진행되면서 아키텍처가 서서히 정의되기 때문에 기술적인 요소가 아예 포함되지 않을 수도 있다.

또한 두가지 아키텍처의 근본적인 목표는 비즈니스 요구사항을 만족하는 소프트웨어를 만들기 위한 요소들과 그 관계를 정의한 것이다. 따라서 비즈니스를 분석하여 정의하는 프로세스가 두가지 아키텍처에서 모두 존재하게 되는데, 여기서 SI 아키텍처와 솔루션 아키텍처의 가장 큰 차이점이 나타난다. SI 아키텍처는 비즈니스 요구사항을 기술로 해석한 후 필요한 요소들을 정의하여 소프트웨어를 개발하는 것이고, 솔루션 아키텍처는 비즈니스 요구사항을 그 자체로 해석한 후 소프트웨어를 개발한다. 아키텍처는 개발이 진행되면서 최종 완성된다. SI 아키텍처에 요구사항이 제대로 반영되었는지 고객들이 검증하기 어려웠던 것은 기술로 정의된 요인이 크다. <그림 2>는 SI 아키텍처를 정의하는 것을 나타내고 있다.

<그림 2> SI 아키텍처 설계 프로세스

<그림 2>를 살펴보면, 비즈니스 아키텍처 수립 후에 애플리케이션, 기술, 데이터 아키텍처가 정의되는 것을 볼 수 있다. 하지만 내부의 아키텍처 정의 내용들이 모두 기술적으로 정의되고 있다. 기술 요소로 구성된 SI 아키텍처는 설계자나 개발자들이 해석하고 활용하기는 좋으나 추상적인 비즈니스를 기술적인 아키텍처로 옮기기에는 다소 무리가 있다. 이러한 이유로, SI에서는 비즈니스와 기술을 연결해주는 부분을 해결하고자 엔터프라이즈 아키텍처(EA, Enterprise Architecture)를 적용하였지만 크게 호응을 얻지는 못했다.

<그림 3>은 솔루션 아키텍처 설계 프로세스를 나타내고 있다. 비즈니스 전략과 목적을 통해 비즈니스 모델을 만들고 엔터프라이즈 아키텍처를 거쳐 비즈니스 프로세스와 비즈니스 시스템, 그리고 솔루션 아키텍처를 만들고 있다.

<그림 3> 솔루션 아키텍처 설계 프로세스

자료: Alan McSweeney의 Structured Approach to Solution Architecture

솔루션 아키텍처의 근본적인 목적은 <그림 4>에서 보는 것처럼 비즈니스 모델에서 요구되는 요구사항을 효율적이고 명확하게 파악하여 비즈니스 시스템을 정의하고, 이를 소프트웨어로 만들어 딜리버리 하도록 하는 것이다. 비즈니스 모델을 비즈니스 시스템으로 정의하기 위해 엔터프라이즈 아키텍처를 활용한다. 일반적으로 TOGAF를 많이 사용하며, TOGAF는 하단을 참조한다. 여기까지는 SI와 유사하다고 볼 수 있다.

<그림 4> 솔루션 아키텍처 설계의 근본적인 목적

자료: Alan McSweeney의 Structured Approach to Solution Architecture

<그림 5>는 비즈니스 요구사항과 아키텍처 기준을 기반으로 솔루션 아키텍처를 정의하고, 이를 솔루션으로 딜리버리하는 것을 나타내고 있다. 이처럼 비즈니스 요구사항 자체를 아키텍처에 반영하고, 이를 바탕으로 원하는 소프트웨어를 딜리버리 하는 것이 솔루션 아키텍처의 장점이라고 볼 수 있다. 다만, 이러한 비즈니스를 반영하기 위해 설계자와 개발자도 비즈니스에 대한 많은 경험과 지식이 요구된다.

<그림 5> 솔루션 딜리버리를 위한 아키텍처 설계

자료: Alan McSweeney의 Structured Approach to Solution Architecture

아키텍처는 만들고자 하는 소프트웨어를 미리 살펴보면서 필요한 요소들을 큰 그림으로 나타내는 것이다. 그리고 소프트웨어를 분석, 설계, 개발하면서 원래의 의도대로 만들고 있는지 비교해보는 기준을 나타내기도 한다. 지금까지 살펴본 바와 같이 SI와 솔루션 아키텍처는 만들어지는 목적과 시점이 다소 다르다. SI의 아키텍처는 고객이 요구하는 환경에 맞게 구성해야 하고, 솔루션 아키텍처는 소프트웨어가 구동하는데 가장 이상적인 환경을 가정하여 구성한다.

이번 회에서는 SI와 솔루션 아키텍처를 구성하는 방법과 역할, 그리고 두 아키텍처에 대한 차이점을 비교해보면서 장단점을 살펴보았다. 모바일 디바이스의 증가 추세로 볼 때, 불특정 다수가 사용하는 솔루션 형태의 소프트웨어가 점점 증가할 것으로 보인다. 지금까지 안정화된 많은 SI 아키텍처의 특징과 구성을 잘 파악하여 지속적으로 늘어나는 솔루션 아키텍처를 효율적으로 구성할 수 있도록 해야 할 것이다. 솔루션 아키텍처는 기하급수적으로 늘어나는 솔루션들의 개발 방향을 알려줄 것이다.

출처: http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000032170&currPage=&searchPrefaceId=&titOrder=&writeOrder=&regDtOrder=&searchCondition=TOT&searchKeyword=

최근 중국의 경기둔화, 유럽의 경제불안 등 글로벌 경제가 위축되고 있는 가운데, 우리 경제도 잠재성장률 3%대 하락과 체감 실업률 11%대 진입 등 저성장, 고실업 구조로 깊은 고민에 빠져 있다. 그동안 경제성장에 주도적 역할을 했던 정보통신기술(ICT)산업 분야의 경제성장 기여율 역시 가파르게 하락하고 있다. 

글로벌 경제위기 이후 이러한 저성장 기조가 장기화되면서 샤오미, 화웨이 등 중국 제조업이 세계시장에서 애플, 삼성과 각축을 벌이며 추격을 하고 있고, 엔저에 힘입은 일본 기업의 재부상과 가상현실, 사물인터넷(IoT), 핀테크 등 다양한 ICT를 기반으로 한 기기 및 서비스의 등장으로 인해 날로 치열해지는 산업 경쟁에서 중요한 변곡점을 지나고 있다. 이를 타개하고 새로운 국가 성장동력을 발굴하기 위해 ICT산업의 경쟁력 복원이 무엇보다 중요한 시점이라 할 수 있다. 

우리나라 ICT산업은 반도체, 휴대폰, 컴퓨터 부품 등 제조 분야에서 선도적인 제품을 선보이는 등 그간 한국 경제를 받치는 든든한 버팀목이었고, 향후에도 우리나라의 지속적인 경제성장 잠재력을 담보할 중요한 산업이라는 것에 대해 이의를 제기하는 사람은 없을 것이다. 특히 창의성과 아이디어로 새로운 비즈니스 모델 구현을 가능하게 하는 소프트웨어(SW)산업의 육성은 한국의 미래를 책임질 대표적인 성장동력으로 꼽힌다. 

SW산업의 육성을 위해 정부는 지난해 7월 민관 합동으로 SW가 혁신과 성장 가치 창출의 중심이 되는 SW 중심사회 실현 전략을 마련하였고, 올해는 SW 중심사회로의 성과 확산 및 이행을 가속화하기 위해 초·중등 교육과정에서 SW 교육의 기본 틀을 마련하고, 대학 SW 교육의 혁신을 가속화하는 추진계획을 발표하였다. 

SW산업에 관심을 집중하기 시작한 것은 또 다른 긍정적 효과를 기대할 만하다. 정부 차원의 SW산업 육성을 통한 스타트업 지원과 글로벌 시장 진출에 대한 지원이 활성화되면, 더 많은 젊은이들이 도전을 통해 글로벌 소프트웨어 시장에서 성공을 거둘 기회도 늘어날 것으로 보인다. 

마침 10월 5일부터 전 세계 SW 전문가들이 한자리에 모여 SW 교육, 일자리, 인공지능, 빅데이터 시스템 등 다양한 학문·기술적 이슈에 대해 열띤 토론을 펼칠 `제23회 2015 세계컴퓨터총회(WCC)`가 대전에서 개최된다. 

아울러 `2016 ICT산업전망콘퍼런스`도 함께 개최되어 K-ICT 전략의 분야별 현안을 되새겨 보고, 국내외 ICT산업의 발전 방향 등에 관하여 국내외 전문가들과 한곳에 모여 다양한 논의를 할 예정이다. 특히 최근 주목받고 있는 인공지능을 통한 ICT 혁신, 미래 기술 등 우리나라 ICT산업의 미래를 고민하는 자리가 될 것으로 기대된다. 또한 ICT 융합 기반의 새로운 비즈니스에 관한 다양한 사례 발표는 국내 스타트업들에 다양한 간접 경험을 할 수 있는 좋은 기회가 될 것이다. 

이번 콘퍼런스는 우리나라 과학기술지식의 창출 및 확산, 연구개발의 요람인 대전시에서 개최된다. 이는 ICT의 혁신과 발전이 필요한 지금 시점에서 창조경제혁신의 기반 도시 형성에 중요한 역할을 할 것으로 기대한다. 

ICT산업은 다른 산업과 융합해 새로운 가치를 만들기도 하고, 산업과 산업을 잇는 중요한 연결고리 역할도 한다. 그러나 ICT 융합을 통한 산업화는 정부 지원만으로는 시장 활성화가 어렵다. 따라서 ICT가 다양한 산업 분야와의 소통과 융합을 통해 새로운 경제 활력소가 되길 바라며 수요자와 기업의 적극적인 참여는 물론 국민 모두가 ICT산업의 가치와 흐름을 놓치지 않고 지속적인 관심을 가지고 참여하는 자세가 필요하다. 

[이상홍 정보통신기술진흥센터 센터장]

출처: http://news.mk.co.kr/newsRead.php?year=2015&no=919662

소프트웨어(SW)가 산업혁신을 이끌고 있다. 농축산 등 전통산업을 고부가 가치화하고 자동차·조선·국방·항공 등 주력 산업 고도화 중심에 SW가 있다. 2012년 기준 글로벌 SW시장은 1조3000억달러 규모로 성장했다. 자동차의 1.5배, 반도체의 4배, 휴대폰·반도체·자동차 시장을 합한 규모와 맞먹는 대규모 시장을 형성했다. 

세계 SW산업의 비약적 성장 배경에는 클라우드·빅데이터·사물인터넷(IoT)·인공지능·임베디드SW 등 핵심기술이 있다. 우리나라는 핵심기술 확보전에서 한발 뒤처져 있다. 한국산업기술평가관리원(KEIT)에 따르면 국내 SW기술은 미국 대비 운용체계(OS)가 3.27년, 빅데이터 2.63년, 기초기술과 최신 기술 전반에 걸쳐 2년 이상 격차가 있는 것으로 나타났다. 기술 수준도 미국 대비 평균 73.5%다. 

산업적 측면에서도 우리나라 전체 SW업체 중 45%가 매출액 10억원 미만 중소 업체로 영세성을 면치 못하고 있다. 2013년 시장조사업체인 IDC 자료에 의하면 패키지 SW 분야 세계 500대 기업 중 국내 기업은 4개에 불과해 글로벌 경쟁력 또한 취약한 것으로 나타났다. 

어디서부터 이런 큰 차이가 벌어진 것일까. 이를 극복할 수 있는 방안은 없는 것일까. 해답을 얻기 위해서는 ‘SW강국’ 미국을 살필 필요가 있다. 빠른 속도로 바뀌는 IT산업에서 미국은 SW패권을 장악하고 있으면서도 수십년간 그 지위를 잃지 않고 있다. 미국의 성공 비결은 국내 SW산업에 해법이 될 수 있다.

◇SW산업 메카 미국 

성공한 SW기업은 모두 미국에 있다 해도 과언이 아니다. 일반인에게도 널리 알려진 마이크로소프트, IBM, 오라클, 구글, 애플 등 유수 기업이 미국에 포진해 있다. 

미국은 세계 SW산업 ‘메카’로 불린다. 운용체계(OS), 데이터베이스, 보안, 그래픽 분야에서 선두를 달리며 글로벌 표준을 이끈다. 클라우드, 빅데이터, 오픈소스 등 새로운 분야를 주도한다.

SW 모든 분야에서 시장을 주도하는 미국의 힘은 통계에서 잘 드러난다.

글로벌 시장조사업체 가트너가 세계 소프트웨어 기업 매출 순위를 집계한 결과 상위 10개 기업 중 9개가 미국 기업으로 나타났다. 

마이크로소프트, 오라클, IBM이 나란히 1, 2, 3위를 차지했다. 독일 기업용 SW 전문 기업 SAP가 4위에 랭크돼 미국 외 기업으로는 유일하게 상위 톱10 기업에 이름을 올렸다.

이 외 세계적 보안 회사인 시만텍, 데이터 관리 및 저장 전문 업체 EMC, 가상화 분야 1위 VM웨어 등이 이름을 올려 미국 SW 기업의 저력을 보였다. 

미국 SW 경쟁력은 국내 연구기관의 분석에서도 확인된다. 

과학기술정책연구원에 따르면 미국은 세계 패키지 SW 시장 점유율 1위(2012년 기준)다. 세계 패키지 SW 시장 81%를 점유하고 있는 주요 350개 업체 가운데 216개 업체가 미국 기업이다. 총매출은 2239억달러로, 세계 패키지 SW시장에서 65.35%를 차지한다. 2위 독일(6.48%), 3위 일본(2.56%)를 압도하는 수치다. 

IT서비스 시장에서도 미국은 독주했다. 세계 IT서비스 시장 72.3%를 점유하고 있는 주요 338개 업체를 조사한 결과, 미국 68개 기업이 총 3421억달러 매출(2012년 기준)을 거둬 37.8% 점유율로 세계 최고를 기록했다. 이 역시 각각 2, 3위인 일본(11.7%), 인도(4.9%)를 멀찌감치 따돌리는 규모다.

우리나라는 IT서비스 시장에서 세계 상위 기업 중 12개 기업이 활동, 약 200억달러 매출규모로 세계 7위 수준이나, 매출 총액 기준 점유율이 1.3%로 매우 낮았다. 

매출 상위 100대 SW기업 순위에서도 미국이 절대 다수를 차지했다. 과학기술정책연구원 분석에 따르면 세계 패키지 SW시장에서 매출기준 100위권 기업 수는 국가별로 미국이 70개로 가장 많았다. 미국에 이어 독일(6), 영국(5), 일본(4), 캐나다(2), 프랑스(2), 네덜란드(2), 러시아(2) 등이었다. 상위 100대 기업에 우리나라 기업은 포함되지 않았다. 

IT서비스 시장에서도 상위 100위권에는 미국 기업이 가장 많다. 미국(44), 일본(17), 인도(8), 프랑스(6), 영국(6), 독일(4), 한국(3), 스페인(2), 캐나다(2), 스위스(1) 등이다.

우리나라 기업 중에는 삼성SDS(33위), LG CNS(48위), SK C&C(74위)가 이름을 올렸지만 글로벌 기업과 격차가 크다. 

◇미국 SW산업 성공 배경은 

미국에서 수많은 SW기업이 탄생하고 성장하는 힘은 어디에 있을까. 인재, 정책, 자본 등 복합적인 이유가 있겠지만 미국은 정부 주도의 산업 육성이 아닌 민간 중심 SW 발전이 이뤄진다는 점에서 기초가 탄탄하다. 특히 민간 중심의 발전에서 빼놓을 수 없는 것이 바로 도전적이고 창의적인 문화가 꼽힌다.

미국 캘리포니아주 마운틴뷰에 위치한 기업용 스토리지 업체인 ‘퓨어스토리지’. 2009년 설립한 이 회사는 기관투자자들로부터 선기업공개(Pre-IPO) 자금으로 1억5000만달러를 투자 받았다. 실리콘밸리 스타트업 중에서도 1회 투자금으로는 최고 수준이다. 데이터를 하드디스크 대비 6분의 1 수준으로 줄여 저장하는 중복제거 및 압축 기술을 인정받았다. 

퓨어스토리지의 이런 차별화된 기술은 기업 문화에서 나왔다. 마케팅·구매부서 사람들도 언제든지 엔지니어링부서에 와서 제품 아이디어를 낸다. 

설립자이자 최고기술책임자(CTO)인 존 코즈는 “내부 미팅은 빨리 만나서 이야기할 수 있어야 한다. 개인에게 방해가 되더라도 많이 모여 논의하는 게 더 생산적이다. 이것이 우리만의 ‘오픈 컬처’”라고 소개했다.

퓨어스토리지 본사엔 최고경영자(CEO)와 CTO를 위한 공간이 없다. 사무실 중간, 다른 직원과 맞붙은 책상 하나가 전부다. 다양한 경험을 가진 직원들이 한데 뭉쳐 융합된 힘을 내기 위해서다.

존 코즈 CTO는 “지금 일하는 사람들 모두가 전에 몰랐던 사이”라며 “‘에벌루션 DNA’ 즉, 다른 문화가 더 많은 창의력을 창출한다고 믿는다”고 말했다. 

실리콘밸리 SW 기업들은 창의적 인재를 중시한다. 정답을 찾기보다 문제 해결 능력을 요구한다. 직원 채용 때부터 프로그래밍 능력을 테스트하기보다 지원자의 문제 인식 및 해결 능력 등을 우선 검증하는 식이다.

실제로 구글은 직원 채용 시 ‘자연대수 e를 풀어서 쓸 때 처음 발견되는 10자리의 소수.com’이라는 언뜻 보기에 이해하기 힘든 광고를 낸 적 있다. ‘구글’이 보이지 않는 다소 황당한 수수께끼였지만 정답은 특정 웹사이트 주소였고 이를 풀어낸 사람만이 이 광고가 구글의 채용 과정이었다는 것을 알게 됐다.

이승훈 LG경제연구원 책임연구원은 “구글은 일반인이 무심코 지나칠 만한 상황에서 호기심을 가지고 문제를 인식하며 적극적으로 해결하려는 인재를 발견하기 위해 이러한 시도를 했던 것”이라며 “주어진 문제의 답을 빨리 찾는 것을 중시하는 국내 기업과 달리 문제 해결 과정에서 독창성과 창의성을 평가하는 실리콘밸리 기업이 다른 점”이라고 말했다. 

창의적 문화만으로 실리콘밸리, 나아가 미국 SW산업이 발전 가능했던 것은 아니다. 정책적 지원과 인재 양성, 투자가 복합적으로 어우러진 결과다. 

실리콘밸리는 현재 세계에서 가장 성공적인 SW지역으로 통하지만 오히려 하드웨어(HW) 중심의 산업이 태동하던 곳이었다. 초기 실리콘밸리는 미국 국방부에서 연구개발 과제를 의뢰 받아 성공 기틀을 마련할 수 있었다. 국방부 개발 과제는 실리콘밸리가 스탠퍼드나 UC버클리로부터 젊은 과학 인재를 유치할 수 있는 기반을 제공한 셈이었다. 

무엇보다 인재 양성이 뒷받침됐다. 스탠퍼드대가 큰 역할을 했다. 1940~1960년대까지 스탠퍼드대 학장을 지낸 프레드릭 터만은 2차 대전 후 캘리포니아만 지역 인재들이 동부 해안 쪽 대기업으로 유출되는 것에 고심하고 있었다. 그는 학교와 인접한 지역의 여유 토지를 이용해 수익을 올릴 수 있는 기회를 모색했다. 이에 동부 큰 기업 지사를 스탠퍼드 인근으로 유치하고, 스탠퍼드 우수 인재를 기업에 공급했다. 조기 채용된 학생들의 지속적인 교육을 위한 산학 협력 프로그램도 만들었다. 

우수 인재가 사회에 진출하면서 기술 혁신을 이끌었고 실리콘밸리를 HW에서 SW 중심으로 바꿔 놓았다. 실리콘밸리 고용 인력은 미국 전체 SW 인력 10%에 육박한다는 통계도 있다.

정부기관의 정책적 지원도 빼놓을 수 없다. 벤처캐피털 업체들이 위험을 감당할 수 있도록 유한 책임 파트너십을 허용하는 규제 등의 적절한 조화가 이뤄졌다. 적극적인 주식 시장의 이용, 기업 투명성 제고를 위한 재무정보공개, 정치적 안정 등과 같은 비즈니스 환경도 한몫했다. 벤처투자자들이 감수해야 할 투자 위험을 완화시켰던 것이다. 

문제를 새롭게 발견하고 정의할 수 있는 능력을 갖춘 인재를 선발하기 위한 채용 과정, 끊임 없이 혁신적인 시도를 통해 문제를 해결해 가는 문화 그리고 이를 구현하는 시스템의 조화가 미국을 SW 강국으로 만드는 원천으로 요약된다. 

<2014년 세계 SW 기업 매출 및 시장 점유율 (단위:100만달러) / 자료:가트너 2015년 5월>

출처: http://www.etnews.com/20150914000090

 

야근하는 김슬기 매니저입니다!  오늘은 안드로이드 앱 개발 입문 강사진 인터뷰도 보여드리고, 소프트웨어 테스팅 클래스 수강생 인터뷰도 보여드리네요. 날이 갈 수록 패스트캠퍼스의 후기가 풍부해지는 듯 하여 참 뿌듯하고 기분이 좋은 밤입니다.

 슬기매니저 : 네 저도 다시 한 번 반가워요. QA와 CS를 동시에 담당하고 계시다니, 굉장히 세심하신 성격이신가봐요  어떻게 이 강의를 알게되셨고 수강을 결심하게 되셨나요?

 슬기매니저 : 제가 열심히 만든 페이스북 광고 컨텐츠를 보고 들어오셨군요  현재 재직중인 회사에서 QA는 어떻게 하고 계신가요?

 슬기매니저 : 많은 도움이 되셨다니 기뻐요  마지막으로 강사님, 캠퍼스에 하고싶은 말씀을 자유롭게 부탁드립니다.

  보고 궁금한 점 있으면 김슬기 매니저에게 바로 묻기!
  02-501-4362, skkim@fastcampus.co.kr  

http://www.fastcampus.co.kr/dev_class_swtesting

소프트웨어 테스팅 클래스

www.fastcampus.co.kr

지금까지 테스팅은 '테스터들만 하는 것', '공들여 개발해뒀는데 괜히 태클 거는 것' 이라고 생각하시던 분들이 많을텐데..(이런 이야기를 들을 때 마다 가슴이 아픕니당  ) 사실은 그렇지 않다는 점!
고객을 떠나지 않도록 잡아두고, 내가 만든 서비스에 대한 좋은 첫인상을 남기기 위해서는 절대 무시할 수 없는 분야라는 점!

 

출처: http://blog.naver.com/fastcampus/220449207339

김진형 SW정책연구소장, 공공 발주 모델 다양화 주장

공공 정보화 사업에 대기업 참여 제한을 골자로 하는 SW진흥법을 개정은 SW업계에서 쉽게 꺼내기 힘든 예민한 이슈다. 주무 부처인 미래창조과학부는 개정 논의 자체를 불편해 하고, 개정을 둘러싼 대기업과 중견 IT서비스 업체, 그리고 중소 SW업체들 간 이해관계도 첨예하게 엇갈려 있다. 파고들면 대기업 간 속마음도 각양각색이다.분위기가 이렇다 보니 SW산업진흥법에 대한 속마음을 털어놓기가 쉽지 않다. 괜히 말했다가 뜨거운 논쟁의 불쏘시개가 될 수도 있는 것이 지금의 분위기다.

​

그럼에도 개정을 둘러싼 논란은 알게 모르게 물밑에서 확산 중이다.

​

한국경영정보학회(회장 이호근 연세대 교수)는 8월초 '소프트웨어산업진흥법 개정 실효성 연구 발표회'를 갖고 대기업 참여를 제안한 법 개정 이후 중견 중소 SW업체들의 생산성은 오히려 악화됐다고 주장했다. 이에 대해 SW산업협회 관계자는 "현상만 보면 SW생태계 상황은 예전에도 나빴고 지금도 그런데, 이게 대기업 참여 제한 때문에 나빠진 것이냐에 대해서는 구별할 필요가 있다"고 맞불을 놨다. 이 관계자는 또 "법개정 때부터 1~2년 사이에서 효과가 나올 거라고 기대하지 않았던 만큼, 긍정적인 방향으로 갈 수 있는 방안에 대해 얘기해야 한다"고 강조했다.

​

논란은 점점 커지는 양상이다. 최근 새정치민주연합 주승용 의원은 대기업은 물론 중견 IT서비스 업체도 공공 사업을 못하게 해야 한다는 내용을 담은 법안까지 내놨다. 이같은 상황에서 다양한 SW산업 현안들에 대해 공개적으로 발언해온 소프트웨어정책연구소 김진형 소장의 의견을 묻지 않을 수 없다. 그를 만나 SW산업진흥법 개정에 대한 생각을 물었다.

​

"SW산업진흥법 개정을 둘러싼 논의의 틀이 너무 좁아요. 대기업 참여시키고 말고를 넘어 SI 중심의 용역에 집중된 발주 구조를 확 뜯어 고치는 것에 대한 논의가 필요합니다. 이렇게 해야 공공 IT서비스 질을 개선하고 생태계에도 긍정적인 영향을 미칠 수 있다고 봐요."

김진형 소장은 대기업 참여에 초점이 맞춰진 SW산업진흥법 개정 논의에는 반대한다는 입장을 분명히 했다. 그렇다고 이대로 두자는 쪽에도 부정적이다. 대기업이 빠져서 그런지는 알 수 없으나 대기업 참여 제한 이후 SW생태계 상황이 더 나빠졌다는 것에는 동의한다는 이유에서다. 김 소장은 상황이 이러니 무턱대고 옛날로 돌아가자고 하는 것도 비현실적이라고 못밖았다.

​

"IT환경이 급변하고 있습니다. 정부에서 IT를 도입하는 프로세스는 그동안 내부에서 직접 개발하는 이른바 인하우스(In house), 이후 용역을 주는 SI 개발 형태로 발전했다가 요즘은 이미 개발된 패키지 SW를 쓰거나 클라우드 서비스를 이용하는 쪽으로 진화하고 있어요. 특히 큰 변화가 클라우드입니다. 그런데도 한국 공공 발주는 여전히 용역 기반 SI가 대부분입니다. 정부가 SW를 소유하고 책임도 지는거죠. 이건 글로벌 IT트렌드와는 거리가 멉니다. 영국은 정부를 위한 SW마켓플레이스까지 있어요. 민관 합작으로 만든 겁니다. 대기업 참여 제한은 기업 크기에 기반한 참여 규제론인데, 이걸로는 생태계 혁신이 없다고 봐요. 새로운 패러다임을 만들어야 합니다.

​

결국 용역 중심 SI구조를 넘어 정부 사업 발주 모델을 다양화하는 것이 핵심이라는 얘기다.

​

"정부는 IT가 필요하면 요구사항을 제대로 제시하는 것이 중요하지, 굳이 모든 것을 소유할 필요가 있을까요? 필요하면 서비스도 빌려 쓸 수 있엉야죠. 용역 구축은 프로젝트가 끝나면 혁신해야겠다는 동기도 사라집니다. 국토부 콜택시 서비스를 보세요. 카카오 택시보다 잘 나갈 수 있을까요?"

​

국토교통부는 2013년부터 60억원의 예산을 투입해 콜택시 통합관리 사업을 추진 중이다. 전국적으로 1200여개에 달하는 콜택시 번호를 '1333'으로 통합·운영하고, 모바일 애플리케이션(앱)을 개발하는 사업이다. 김진형 소장은 정부 IT사업이 이런식으로 진행되면 곤란한다고 강조한다. 혼자해서도 잘하면 상관이 없다. 그러나 현실은 그렇지 않다.

​

민간 서비스들과 수준 차이가 점점 벌어지면서 이대로 가다간 공공 웹서비스가 사람들이 쓰지 않는 외로운 섬과 같은 존재로 전락할 것이란 우려가 커지고 있다. 김진형 소장이 대안으로 정부의 변화를 요구하는 이유다.

​

정부 주도형 용역 외에 어떤 발주 모델이 있을까? 구축식 용역 외에도 임대, 위탁 용역, 임대형 민간 투자 사업인 BTL(Build-Transfer-Lease), 민간 자본투자, 조인트벤처 등 다양한 모델이 나와 있다. 정부 상황과 사업 성격에 따라 적합한 모델을 활용해야 한다는 게 김 소장의 생각이다. 특히 그는 BTL을 주목했다.

​

BTL은 민간 자본으로 IT시스템을 만들고 정부는 그걸 임대해 쓰는 방식이다.

​

"BTL의 경우 부족한 정부 재정은 물론 혁신 측면에서도 유용할 수 있습니다. 영국은 이미 이렇게 하고 있고 미국도 관련 법이 통과됐어요. 강조하고 싶은건 SW생태계 발전을 위해 정부가 바뀌어야 한다는 겁니다. SW를 소유만 하려하지 말고 라이선스해서 쓰거나 필요하다면 민간 자본을 투자받을 수도 있어요. 정부 주도형 발주 모델을 벗어나 민간 참여형 서비스 모델에 대한 고민이 필요한 상황이에요. 구축 중심의 계약 방식으로는 한계가 있습니다. 임대나 위탁이 혁신 측면에선 잠재력이 상대적으로 커요."

​

민간 참여 서비스 모델은 자연스럽게 대기업 참여 이슈로 이어질 수 밖에 없다. 민간 참여 서비스 모델을 추진할만한 회사는 현실적으로 대기업 뿐이기 때문이다. 김진형 소장은 조심스럽게 현행 SW산업진흥법에 명시된 참여 제한의 조건을 바꾸는 것에 대해서는 고민할 필요가 있다는 입장을 보였다. 대기업 참여 시 중소 기업과의 상생을 요구하는 방안도 추진해 볼만 하다고 했다.

​

한국SW정책연구소는 현재 민간 참여 서비스 기반 발주 모델에 대한 보고서를 준비중이다. 10월초 초안을 내놓고 10월말에는 토론회도 열 계획이다.

출처: http://www.zdnet.co.kr/news/news_view.asp?artice_id=20150918112826&from=Mobile

Matthew Heusser | CIO

T 전문 기고가이자 컨설턴트인 필자에게 최근 몇몇 독자들이 질문해온 바가 있다. 컨설턴트라는 직업을 가지게 된 경로와 그 과정에서 터득한 교훈은 무엇인지에 대해 말해달라는 것이다.

사실 이는 컨설턴트 입장에서 대답하기 꺼려지는 질문이다. 고객이 아닌 컨설턴트에게 초점이 맞춰지면 뭔가 잘못되기 시작하는 경향이 있기 때문이다. 또 조언을 위한 조언을 하게 되고, 때론 듣는 사람에게 가짜 '약장수'처럼 여겨지는 경우도 발생하곤 한다.

하지만 소프트웨어 테스팅 컨퍼런스 애틀란타(Software Testing Conference Atlanta) 참석자들이 “박스 체커(Box-checker)에서 믿을 수 있는 조언자(Trusted Advisor)”가 되는 방법을 물어왔을 때, 이야기를 공유할 필요성을 느꼈다. 필자의 경험을 바탕으로 두 역할의 차이, 직장에서 인식을 바꾸는 방법에 대해 정리한다.


Credit: Vector Open Stock

역할과 인식, 현실
1900년대, 회사를 운영했던 사람들은 직종을 여러 단순한 업무의 직종들로 쪼갬으로써 쉽게 분업 경영을 할 수 있었다. 쉽게 예측할 수 있는 일(업무), 낮은 임금이 특징인 방식이다.

맥도날드와 월마트, 포드 자동차 등은 프레드릭 테일러(Fredick Winslow Taylor)의 <과학적 관리법(The Principles of Scientific Management)>이라는 저서에 뿌리를 두고 있는 이 개념은 '일과 노동자의 분리(Separating the worker from the work)'에 초점을 맞추고 있다.

그러나 모두 알고 있듯, 이 개념은 IT에는 적용되지 않는다. 딱 봐도 적용되지 않는다. 대다수 기업들은 구체적이고 특정적인 전문성과 경력을 갖춘 사람을 찾아 채용한다.

예를 들어 설명하면, ‘PostGres’를 이용한 ‘Ruby on Rails’에 3-5년의 경력을 갖춘 사람들을 찾는다. 여기에 그치지 않고, 특정 리눅스 버전과 자바스크립트 라이브러리를 요구사항으로 제시하기도 한다. 아주 엄격하게 기술적 역량과 전문성을 요구하고 있는 것이다. 경력이 많을 수록 직종 유연성은 더 떨어지게 된다.

다른 종류의 전문성들도 있다. 흠 없는 코드, 디자인 패턴, 기술적인 문제점(Debt)에 대한 인식 등은 모든 프로그래밍 언어에 적용되는 전문성이다. 이 밖에 일종의 경향성도 참고해야 한다. 예를 들어, 유지관리를 전문으로 하는 프로그래머들에게 신제품 개발을 맡기면 실패할 확률이 높다. 역으로 코드베이스를 유지 관리한 경험이 없는 프로그래머들에게 유지관리를 맡기면 문제가 발생할 수 있다. 좋은 코드를 분별해내는 전문성이 요구되기 때문이다.

이러한 요소들은 간단히 리스트로 제시할 수 없는 지식들이며, 피즈버즈(FizzBuzz) 같은 간단한 프로그래밍 훈련으로 해결될 문제 역시 아니다.

이러한 상황을 인식하고 있는가? 추진 방향과 요구사항에서 불확실한 부분, 그냥 방치되고 있는 문제들을 알고 있는가? 그렇다면 다음 단계, 즉 컨설턴트로 변신할 준비가 된 것이다.

필자에게는 10년 전 다음 단계로 나갈 사건이 발생했었다. 당시 재직하고 있던 보험 회사의 한 관리자는 화이트보드에 큰 붉은 글씨로 '자신의 역할을 알아야 한다 - 자신의 역할이 되어라!'라는 글을 남겼다.

그 관리자가 이런 글을 썼을 때, 필자는 그 자리에 있지 않았다. 그 관리자가 무슨 말을 하려는 것인지 확실히 알 수 없었다. 나는 펜을 들어 작은 글씨로 "또는, 프로젝트에 필요한 부분을 파악하고 그것을 실행하라"라고 적었다.

당시 팀에는 방향타 역할을 해줄 인물이 필요했다. 앞서 언급한 능력을 보유하고 부족한 점이 무엇인지 파악해 이를 메울 인물이 필요했던 것이다 필자는 한 명의 직원에 불과했지만 컨설팅을 공부하기 시작했다.

컨설턴트가 실제 하는 일
컨설턴트가 하는 업무는 무엇일까? <컨설팅의 비밀 : 대체 뭐가 문제야(Secrets of Consulting: A Guide to Giving and Getting Advice Successfully)>라는 서적의 소제목에 힌트가 있다. 고객에게 차이를 가져올 수 있는 조언을 제시하고, 이를 실천하도록 만드는 것이다. 또는 최소한 수수료에 버금가는 가치를 창조시켜야 한다.

'클라이언트에게 솔루션을 소개할 수는 있지만, 이를 이행하도록 강제할 수는 없다'는 말은 사실이다. 그러나 자신이 제시한 솔루션을 따르는 사람이 없다면 컨설턴트로 오래 살아남기 힘들다.

컨설팅 직무를 얻고 수행하기 위해서는 무언가를 개선하고 싶어하는 회사가 있어야 한다.

필자는 당시 재직했던 보험 회사에서 내부 컨설팅 업무를 스스로 시작했다. 일상 업무를 진행하며 동시에 프로젝트 관리 업무도 담당했다. 당시 회사에는 일상 업무와 목표(Goal)를 분리시킨 평가 체계가 많았다. 나는 이 부분을 이점으로 활용했다. 목표를 작은 컨설팅 프로젝트로 이용한 것이다. 그러다 상사와 업무 범위를 논의할 기회를 갖게 됐다. 이때 상사와 '경계선'과 '기대'에 대해 합의했고, 필자가 하는 일을 계속 공유하기로 했다.

내부 컨설턴트 업무를 시작하는 이에게 좋은 출발점이 될 수 있는 것이 갭 분석이다. 갭 분석(Gap Analysis)은 흔한 컨설팅 업무 중 하나로 일상 업무를 담당하는 직원 입장에서도 쉽게 수행할 수 있다.

다음으로 필요한 것은 조직의 니즈다. 조직이 필요로 할 때 컨설턴트 업무를 해야 한다. 조직 재편으로 관리자가 바뀐 상황을 가정하자. 새 관리자는 늦어도 첫 연간 실적 평가에서 자신의 성과를 입증해 보이기 원할 것이다. 그렇다면 갭 분석 실시를 제안해볼 만하다. 새 관리자의 장기 비전, 현재 팀이 운영되는 방식, 그리고 갭(공백 또는 차이)을 찾아, 이를 해결할 방법을 제안하는 것이다.

새 관리자는 이 시기에 귀를 기울일 동기가 부여되어 있다. 만약 문제점을 말하면, 이를 개선하겠다고 말할 것이다.

부서가 바뀌었을 때, 이를 제안할 수도 있다. 예를 들어, 유닉스 관리 부서에서 윈도우 부서로 옮겼다고 가정하자. 모든 사람이 당신을 새로운 사람으로 인정할 것이다. 당신에게 배울 점이 있다고 생각할 것이다. 이를 이용해 기존 업무 문서를 분석해 비교하자고 요청한다.

그러면 직원들이 업무에 대해 알아야 할 '갭'을 찾게 된다. 기존 관리자와 직원들이 일을 잘못하고 있다는 의미는 아니다. 일하는 방식을 컨설턴트의 방식으로 기록하지 않았다는 의미일 뿐이다. 분석을 마쳤으면, 다른 분야에도 이를 적용한다. 프로세스를 적용하는데 그쳐서는 안 된다. 도전하고, 개선할 부분을 지적한다.

새로운 일을 시작했을 때도 이를 적용할 수 있다. 새로운 시각을 가졌음을 강조한다. 그리고 팀의 장기 비전을 묻고, 개선할 부분을 찾는 분석을 실시한다.

컨설팅 업무들
다시 갭 분석을 설명하겠다. 갭 분석의 출발점은 목표와 최종 상태를 파악하는 것이다. 다시 말해, 기업이 도달하고 싶은 장소를 묻는 것이다. 이를 출발점으로 삼아, 현재 상태를 조사하고 간극을 찾아낸다.

필자는 통상 갭과 함께 개선을 위해 필요한 부분을 제안한다. 참고로 필자의 컨설팅 기업 엑셀론 디벨롭먼트(Excelon Development)는 고객들이 컨설턴트의 도움 없이 스스로 해야 할 몇 가지가 있다는 점을 제시하는데 만전을 기한다. 또 기업의 목표 달성에 도움이 될 서비스 '메뉴'를 제시한다.

내부 컨설턴트로 역할하면서 이런 일을 할 수 있다. 그러면 갭을 메울 역할을 맡게 될 확률이 높다.

갭 분석에 흔히 사용하는 도구 중 하나는 Strength(강점), Weakness(약점), Opportunity(기회), Threat(위협)으로 구성된 SWOT 분석이다. 강점과 약점은 내부 요소이고, 기회와 위협은 외부 요소이다. 참고로 이는 팀 수준에서만 수행해야 하는 분석이 아니다. 예를 들어, 우리는 조직 내부와 외부에서 기회와 위협을 분석했으며, 조직 외부의 산업 트렌드를 리스트로 정리했다.

필자는 독립하기까지 알찬 3년을 보냈다. 첫 회사는 소셜, 웹 기반 회사인 소셜텍스트(Socialtext)로 온라인 커뮤니티 활동에 관여해야 했다. 소셜텍스트는 직원을 내부 컨설턴트로 취급한다. 직원들에게는 이에 맞게 책임과 권한이 주어진다. 벤처 자본의 투자를 받은 신생 창업 회사였기 때문에 매 분기 실적 보고에 따른 결과가 따랐다. 해고를 당하거나 '축배'를 들 수 있었다는 의미이다. 회사는 우리가 현재 상태를 계속 인식할 수 있도록 도움을 줬다. 그러나 매 분기 초는 힘든 시기였다.

필자는 소셜텍스트에서 일 하면서 불확실성과 위험에 대한 인내력을 터득했다. 컨설턴트가 될 준비를 할 좋은 기회였다. 포트폴리오 매니지먼트 앤 스트래티지(Portfolio Management and Strategy)에서 컨설팅을 하고 있는 동료인 아담 유레트 또한 유사한 이야기를 했다. 그는 퍼시픽(Pacific)에서 3년간 일하면서 적은 소득으로 장기간 일하는 방법을 터득했고, 이는 컨설턴트 삶을 준비하는데 도움이 됐다고 말했다.

직원 컨설턴트로 근무하면서 터득한 마지막 교훈은 고객에게 초점을 맞추는 것이다.

초점은 고객
스스로를 외부의 인물로 생각하기 쉽다. 다른 사람을 위해 보고서와 분석 자료를 개발하는 사람이다. 그리고 점심 식사 동안 이렇게 자신과 자신의 일을 설명하기 시작한다. 이는 그럴듯해 보이지만, 동시에 함정이다.

컨설턴트는 고객의 '상태'를 개선하는 직종이다. 자신이 아닌 고객이다. 자신에 초점이 맞춰지면 대화에서 이상한 일이 발생하기 시작한다. 뭔가를 놓치기 시작한다.

더 나쁜 것은 변화가 발생하지 않는다. 고객의 상태가 개선되지 않는다. 사람들이 컨설턴트가 매일 무슨 일을 하는지 의심을 갖기 시작한다. 이야기 하는 것? 이야기하고, 보고서를 쓰는 것이 업무인가?

고객(상사, 프로젝트 팀, 동료 등)이 원하는 것을 파악한다. 그리고 이들이 이를 성취하도록 돕는다.

일을 잘 했는데 소외되는 경험을 알 것이다. 도와준 사람들은 큰 성과를 일궈냈지만, 자신은 이를 인정받지 못하는 상황이다. 그러나 이는 나쁜 일이 아니다. 좋은 일이다. 스스로를 칭찬하라. 그리고 진짜 컨설턴트가 됐음을 자랑스러워하라. 당신의 조언이 활용된 것이다. 계속 그렇게 평판을 쌓으면 새로운 일이 주어질 것이다.

고객에게 듣기 싫은 소리를 해야 하는 상황도 발생한다. 타협하자는 유혹에 빠질 수도 있다. 당신이 생각하기에 가장 필요한 과업 대신 다른 과업을 제시하는 것이다. 그러나 진정한 컨설턴트는 일을 거절하거나, 프레임을 바꿀 수 있어야 한다. 물론 이로 인해 일을 못 얻을 수도 있다.

내부 컨설턴트이기 때문에 선택권이 없다고 생각할지 모르겠다. 그러나 자신은 수용할 수 없는 부분이라고 단언할 수 있는 방법이 있다. 어쩌면 일자리나 인간 관계에 위험이 초래될지 모르겠다. 그러나 주어진 상황을 수동적으로 받아들이기만 하면 안 된다는 점을 학습해야 한다. 이는 커리어 성장의 밑거름이다.

리차드 바크(Richard Bach)는 <환상(Illusions)>이라는 책에서 "항상 우리 잘못이 아니라고 생각해 책임을 지지 않는다. 그런데 책임을 지지 않으면, 항상 그 책임의 희생자가 되는 법이다"고 말했다.

1단계는 자신의 업무 프로세스를 책임지는 것이다. 이를 출발점으로 조언을 제공하기까지 큰 시간이 걸리지 않는다. 사람들은 당신을 내부 컨설턴트라고 생각할 것이다. 굳이 직함을 바꿔 달 필요가 없다.

다음 단계
필자는 또 기술직 직원이나 조직 내 성장을 넘어서는 3번째 방식을 가르키고 싶다. 플레이어/코치, '콘트랙터 플러스(Contractor plus)'로 지칭할 수 있다. 직원 보수 분석 분야에서 일하는 친구는 코디네이터, 관리자, '내부 컨설턴트'라고 지칭한다. 표현이야 어떻든, 전체를 탐구해 통찰력을 제시하고, 장점과 단점, 상쇄되는 부분에 대해 조언하고, 아이디어가 실현되기까지 지원하는 역할이다. 자신의 현 직책과 일상 업무를 유지하면서 이렇게 할 수 있다. 프로세스 내부가 아닌 프로세스 너머에서 일하는 방식이다.

자신의 일상 업무에 추가해 이를 시작해보자. 다음 변화를 위한 출발점이다. 더 야심 찬 목표를 갖고 있다면, 그리고 모든 사람들이 팀원이자 컨설턴트로 업무에 변화를 가져오기 희망할 때 좋은 방법이다. 딴 내부 업무와의 균형을 잡는데 위험이 따르며 또 인식 측면에서 위험이 초래될 수 있다.

마지막으로 컨설턴트로의 변신을 위해 참고할 만한 4가지 간단한 질문이 있다. 지금 당장 당신의 프로젝트에 필요한 것은 무엇인가? 무엇을 할 것인가? 어떻게 진행되고 있는가? 마지막으로 다음은 무엇인가?

* Matthew Heusser는 엑셀론 디벨롭먼트 수석 컨설턴트다. ciokr@idg.co.kr 

출처: http://www.ciokorea.com/news/26605