All of Software: 2017

2017년 12월 1일 금요일

한국 회사와 불가리아 회사

필자는 꽤 오래 전에 비슷한 일을 하는 두 회사를 접했다.

두 회사 모두 웹프레임워크를 개발하는 회사였다.

한국 회사는 웹프레임워크를 솔루션 형태로 개발해서 3~5천만원을 받고 약간의 SI를 더해서 한국 회사들을 대상으로 영업을 하고 있었다. 고객 중에는 외국회사도 있었고, 매출을 꽤 일으키고 있었다. 보유 기술 자체는 좋았다. 하지만 기획, 스펙, 설계 같은 것은 제대로 된 것이 없었다. 고객이 생기면 고객의 요구사항대로 만들고 고쳐서 구축해주기 급급했다. 그렇게 여러 프로젝트들이 동시에 진행되고 있었다.

그렇게 회사를 운영하면 곧 망할 것이 확실했지만 워낙 희망에 차 있어서 그렇게 말해줄 수가 없었다. 현재 회사가 눈에 띄지 않는 것으로 보아 없어진 것으로 예상된다.

비슷한 시기에 불가리아 회사에서 개발한 웹프레임워크를 인터넷으로 접하게 되었다. 가격은 약 100만원 수준이었다. 데모 사이트가 너무 잘 구축되어 있어서 내가 필요한 것들이 다 제공되는지 쉽게 확인할 수 있었다. 여러 개발 언어를 지원하며 메뉴얼이 매우 잘 만들어져 있었다. 커스터머 서비스는 온라인으로만 진행이 되었다. 서비스 데스크 시스템이 잘 구축되어 질문을 하면 온라인으로 바로 답변이 왔다. 한국회사의 솔루션에 비해서 가격은 엄청나게 싸지만 성장 가능성은 엄청나 보였다. 직원이 많지도 않지만 이 회사는 곧 세계적인 회사가 될 것이라고 생각했다.

이 회사가 Telerik다. 2014년에 Progress software라는 회사에 2억6천만불(약 3천억) 에 인수되었다.

여기서 조삼모사의 교훈을 다시 생각해본다. 물론 조삼모사도 역량이 있어야 가능하다. 역량이 없다면 조사모삼 밖에는 할 수가 없다.

이 두 회사만의 현상은 아니다. 한국과 외국의 여러 소프트웨어 회사를 대표해서 보는 것 같아서 씁쓸하다.

2017년 9월 19일 화요일

SW회사 '사수 부사수 시스템'의 문제점

우리나라 회사에서 후배를 키우는 가장 흔한 방법은 '사수 부사수 시스템'이다. 필자도 오래 전부터 사수 부사수 시스템을 많이 봐왔고, 지금도 매우 일반적인 방식이다.

이 용어는 군대에서 유래했다. M60 기관총 등 중화기들은 대부분 2명 이상이 운용해야 하고 사수와 부사수가 같이 장비를 다룬다. 영화 속 람보는 M60 기관총을 혼자서 양손에 하나씩 두개를 들고 쐈지만, 원래는 2명이 쏴야 하는 무기다.

이런 사수 부사수 시스템에서는 사수는 주업무를 하고 부사수가 보조 업무를 하며 업무를 익힌다. 1, 2년 후에는 부사수가 사수가 되어 또 다시 부사수를 교육하는 시스템이다.

소프트웨어 회사에서도 비슷한 시스템을 가지고 있는 경우가 많다. 공식적이든 비공식적이든 사수 부사수 시스템을 가지고 있는 소프트웨어 회사에서는 신입개발자가 들어오면 회사에서 사수를 지정해준다. 사수 옆자리나 근처에 자리를 배정하여 사수와 많은 시간을 보내면서 하나씩 업무를 배워나갈 수 있도록 한다. 사수는 부사수에게 개발하고 있는 소프트웨어의 구조부터 기능, 소스코드, 빌드 방법, 업무지식, 회사의 시스템 사용법 등 많은 것을 가르쳐준다.

사수 부사수 시스템이 장점이 없는 것은 아니지만 많은 문제점을 가지고 있다. 어떤 문제를 가지고 있는지 알아보자. 정확하게는 사수 부사수의 문제라기 보다는 후배에게 지식을 전수할 준비가 안되어 있어서 주먹구구식으로 진행되는 사수 부사수 시스템의 문제이다.

● 사수, 즉 선배가 후배 교육에 너무 많은 시간을 소비해야 한다. 후배 교육은 회사 입장에서 투자이기도 하지만 큰 비용이다. 선배는 오랜 기간동안 지속적으로 시간을 빼앗긴다. 후배 교육은 꼭 필요하지만 문제는 시간이 많이 들어간다는 것이다.

● 후배가 제대로 일을 하기까지 교육을 하는데 시간이 너무 많이 걸려서 현장 투입이 늦어진다. 회사마다 개인마다 다르기는 하지만 작게는 몇주부터 몇달이 걸리곤 한다. 부사수는 교육과 훈련을 어느 정도 받기 전까지는 제대로 일을 하기 힘들다.

이때까지는 한사람의 개발자가 들어온 것이 아니고 0.5 또는 0.3 인원이기도 하고, 심지어는 사수의 시간을 너무 많이 빼앗어서 마이너스 인력이 경우도 있다. 즉, 후배가 없을 때보다 전체 개발 기간을 더 지연시키기도 한다.

● 후배가 들어올 때마다 매번 반복적으로 가르쳐야 한다. 부사수가 다시 사수가 되어 후배를 가르치려면 상당한 시간이 걸리기 때문에 여전히 고참 개발자가 교육을 계속 해야 하고 시간 간격을 두고 5명의 개발자가 입사를 하면 교육 시간이 5배 들어간다.

● 사수도 많은 정보를 잊어버려서 제대로 교육을 하기가 쉽지 않다. 사수는 핵심 개발도 하고 교육도 하느라고 바빠서, 개발을 하면서 문서를 제대로 작성할 시간도 없다. 그래서 악순환이 반복된다. 아무리 후배를 교육해도 결국 모든 문제 해결 요청은 고참에게 몰려서 고참은 여전히 더 바쁘다.

● 부사수는 너무 자주 물어보면 사수의 시간을 빼앗는 것 같아 미안해서 잘 물어보지 않게 된다. 뻔뻔한 후배는 궁금한 것이 있을 때마다 잘 물어보겠지만, 사수가 얼마나 바쁜지를 매일 보게 되면 사수의 시간을 빼앗는 것을 미안해하곤 한다. 그래서 일을 그르쳐 문제를 만들고 나중에는 사수의 시간을 더 빼앗곤 한다.

■ 사수-부사수 한계 극복하려면 개발때 분석-설계 제대로 해야

경영자는 그동안 문서가 너무 없어서 이런 일이 벌어진다고 생각하고 기존 소프트웨어의 문서를 만들라고 하는데 이미 개발된 시스템의 문서를 나중에 많는 것은 헛수고다. 문서는 원래 개발 전에 만들어야 제대로 만들 수 있다. 개발 후 만드는 문서는 필요한 정보의 10%나 제대로 적을 수 있을까 의문이다.

또한, 제대로 분석, 설계를 하지 않고 이미 만들어진 소프트웨어는 시간을 아무리 많이 준다고 하더라도 다시 문서로 정리하기 어려운 구조로 되어 있는 경우가 많다. 그래서 악순환이 계속되고 사수 부사수 시스템에서 영원히 벗어나기 어렵게 된다.

이런 사수 부사수 시스템을 계속 유지하는 한 기업은 현재 수준에서 벗어나기 어렵다. 회사를 조금만 키워도 개발 효율성은 점점 떨어져서, 경쟁력 저하를 가져온다. 사수 부사수 시스템을 유지하는 회사에서의 후배에게 정보를 전달하는 방법의 비율을 보면 다음과 같다.

문서/시스템 : 직접 교육/코칭 = 2:8 또는 1:9

즉, 문서나 시스템을 통해서는 10~20% 정도의 정보밖에 전달을 못하고 나머지는 사수가 직접 가르쳐야 한다. 이상적인 비율은 반대가 되어야 한다. 즉, 8:2 정도가 되는 것이 좋다.

대부분의 정보는 문서나 시스템을 통해서 얻어야 하고, 문서를 봐도 잘 모르겠는 정보는 멘토나 선배에게 물어보는 것이 좋다. 이것을 10:0 또는 9:1로 만드는 것은 거의 불가능하다. 오히려 더 비효율적이다.

8:2 정도만 되면 위에서 언급한 문제점의 대부분이 해결된다. 고참 개발자의 시간을 너무 많이 빼앗지 않게 되고, 신규 입사자가 아무리 못해도 마이너스 인력이 되지는 않는다. 스스로 공부를 할 수 있으니 후배의 노력에 따라서 얼마든지 빨리 배울 수도 있다. 또한 입사 후 실전 개발에 투입되는 시간은 훨씬 빨라진다.

그럼 사수 부사수 시스템을 탈피하는 방법은 무엇일까? 분석, 설계를 제대로 해서 개발을 하는 것이다. 말은 참 쉽다. 하지만 실제는 정말 어렵다. 물론 이슈관리시스템이나 위키시스템 등 소프트웨어 회사에 필수적으로 필요한 시스템은 잘 구축되어 있어야 한다.

분석, 설계 문서는 SW를 개발하는데도 필요하면 이 문서들은 나중에서 신입 사원을 교육시키는데도 매우 유용하다. 이런 체계를 갖춘 회사에서는 신입개발자가 입사를 해도 바로 개발에 투입이 가능하다. 물론 개발 능력을 갖춘 신입개발자여야 한다. 개발 능력 자체가 부족하다면 얘기가 안된다. 한사람 몫을 하려면 상당히 시간이 걸리기는 하겠지만 고참을 그렇게 많이 방해하지는 않는다. 궁금한 것이 있으면 문서나 시스템을 통해서 스스로 배울 수도 있고, 설계가 잘 된 시스템에서는 개발을 할 때 알아야 할

정보의 범위가 작다. 자신이 개발해야 할 시스템의 인터페이스와 요구사항만 알면 된다.

대부분의 외부 인터페이스가 잘 정의 되어 있고, 유닛 테스트는 이미 작성이 되어 있는 경우도 많다. 신입 개발자에게 시스템 내부의 하위 설계는 직접 맡기는 경우도 있다. 또는 고참 개발자가 내부 설계까지 해주고 내용만 채우도록 하는 경우도 있다. 시스템이 작은 서브시스템으로 잘 나눠져 있기 때문에 신입 개발자라도 개발에 참여하기 쉽고 문제가 생겨도 전체 시스템에 큰 영향을 주지는 않는다.

물론 이렇게 하려면 분석, 설계를 매우 잘해야 한다. 모든 회사가 성숙도와 역량이 달라서 회사마다 벌어지는 현상은 다르다. 필자는 상당한 성숙도를 가진 회사를 기준으로 설명을 하고 있다. 이우소프트도 그러한 방향을 향해 발전해 가고 있는 진행형이다.

아직 제대로 된 시스템도 구축이 안되어 있고 분석, 설계 문서도 제대로 쓴적이 없는 회사라면 어떻게 할까?한번에 극복할 수는 없다. 새로운 제품부터 분석, 설계를 하나씩 제대로 하는 습관을 들여야 한다. 방법론과는 상관이 없이 분석, 설계를 적절히 제대로 하는 것은 소프트웨어 개발의 기본이다. 이렇게 하나씩 제대로 해나가면 지식정보가 축적되고 점차 사수 부사수 시스템에서 벗어날 수 있을 것이다.

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

2017년 9월 5일 화요일

나쁜 회의가 회사를 망친다

나쁜 회의 문화가 회사를 망친다.

잦은 회의와 장시간 회의 때문에 일 할 시간이 없다고 하소연하는 사람이 많다. 특히, 고참 개발자들에게는 그 폐해가 더 크다. 개발과 회의는 두뇌의 모드가 완전히 달라서 섞어서 하게 되면 개발 효율이 나지 않고, 많은 회의에 끌려 다니다 보면 어느새 개발자로서의 정체성을 잃어버리게 된다. 이런 시간이 지속되면 개발자의 경력에서 벗어나 돌아올 수 없는 어정쩡한 관리자의 길을 걷게 된다.

그럼, 우리 주변에서 흔히 볼 수 있는 회의의 나쁜 증상들을 살펴보자.

“여러분, 회의 좀 합시다.”

상급자의 요구에 의해서 수시로 소집되는 회의 유형이다. 갑자기 소집을 하기 때문에 주제와 내용이 회의 참석자들에게 충분히 공유되지 않고, 참석자들은 각자의 업무 계획이 있었는데 갑작스런 회의 때문에 일정도 틀어지고, 부족한 준비로 회의 진행도 부실하게 된다.

“직급이 깡패.” 회의를 하면서 서로 합리적으로 논의하여 결정을 못하고 상명하복식으로 무조건 윗사람이 결정하는 회의 유형이다. “편하게 얘기들 해보세요”라고는 하지만 편하게 얘기할 수 없고 결국에는 윗사람이 독단적으로 결정한 것을 통보하는 회의가 되곤한다.

“그럼, 네가 한번 해봐." 아이디어를 꺼내면 얘기를 꺼낸 사람이 일을 떠맡는 유형. 그러다 보니 해야할 얘기나 아이디어가 있어도 쉽사리 얘기를 꺼내지 못하게 된다.

“설명 좀 해 줘봐.” 상급자가 모르는 내용이 있거나 업무를 파악하기 위해서 실무자나 팀장들을 소집해서 브리핑을 받는 회의 유형. 업무 내용파악을 위해 수시로 실무자들을 불러서 시간을 낭비한다.

“언제 끝날지 모르는 마라톤 회의.” 어려운 주제를 일단 회의시간에 만나서 끝장을 보려고 진행하는 회의 유형. 사전 의논이나 조율없이 달랑 회의에 참석해서 난상토론을 하면서 몇시간을 훌쩍 넘기는 회의. 그렇게 장시간 회의를 하고 결론을 짓지 못하고 다음에 결정하자고 하기도 한다.

“회의는 회의.” 회의에서 나온 결론이나 업무들이 추적이 안되는 유형, 회의는 열심히 하는데 그 뒤에 어떻게 처리가 되는지 추적이 잘 안되는 경우가 많다. 이를 확인하기 위해서 다시 회의를 소집하기도 한다. 또한, 회의에서 결정된 사항들이 제대로 기록되고 관리가 안돼서 나중에 회의 참석자들끼리 회의 내용에 대해서 다툼을 하기도 한다.

이외에도 비효율적인 회의 유형은 다 나열 할 수 없을 만큼 많다. 많은 회사에서 중간 관리자, 고참 개발자들은 회의에 불려다니느라고 낮에는 일을 못하고 어쩔 수 없이 밤에 일을 하고 있다. 그러다 보면 고참 개발자들은 개발할 시간이 점점 부족해져서 결국에는 개발과는 멀어지게 된다. 회사 입장서는 중요한 개발 자원을 잃게 되는 것이다.

이우소프트에서는 5,6년에 걸쳐서 회의 문화 개선을 위해서 노력을 해왔고, 이제는 어느 정도 정착이 되어가고 있다. 이를 몇가지만 간단히 소개하려고 한다.

■ 가능하면 짧게…최소 24시간 전에 아젠다 공지

첫째, 가급적 회의는 하지 않는다.

회의의 관행을 바꾸는 가장 중요한 요소다. 불필요하거나 다른 것으로 대체 가능한 회의는 최대한 줄여야 한다. 회의의 비용은 상상 이상으로 엄청나다. 회의를 하면서 소모하는 비용도 크지만, 기회 비용은 그보다 더 크다. 무조건 회의는 1/10로 줄인다는 생각으로 시작하자. 진행하는 일을 모두 온라인 시스템으로 공유하면, 회의는 획기적으로 줄일 수 있다. 정보 공유, 업무 진행상황 확인, 업무 지시 등과 관련된 거의 모든 회의는 할 필요가 없고 온라인 시스템을 통하면 된다. 꼭 필요할 때만 회의를 통해서 논의를 하면 회의를 최소화할 수 있다.

둘째, 최소 24시간 전에 상세한 Agenda와 함께 회의를 초청한다.

그래도 회의를 하는 것이 효율적일 때는 미리 회의를 초청한다. 이때 상세한 Agenda를 공유하고 발표자료나 참고자료는 미리 같이 배포를 해서 참석자들이 완전히 숙지를 하고 들어올 수 있게 한다. 덜렁덜렁 내용도 모르고 회의에 참석하는 것은 금기다. 회의 시간에 자료를 발표하거나 낭독하는 것은 시간 낭비다. 이렇게 하면 회의 때문에 업무에 지장을 초래하는 일이 줄어들고 회의 시간도 짧아진다.

피치 못하게 급작스럽게 소집되는 회의도 시스템을 통해서 Agenda와 회의 자료를 등록 후 회의를 소집한다.

셋째, 회의시간은 가능하면 짧게 한다.

보통 30분을 넘기지 않도록 하고 길어야 1시간을 넘기지 않도록 한다. 그러기 위해서 회의 참석자들은 회의 주제와 내용을 사전에 모두 파악하고 빠른 결론을 내기 위해서 노력을 한다. 모두 회의에 집중해야 하며, 중간에 전화를 받거나 잠깐 나갔다 오는 행동은 금지되어 있다.

넷째, 회의록은 실시간으로 작성한다.

가급적 회의록은 회의를 하면서 동시에 작성한다. 작성되고 있는 회의록은 회의 참석자 모두가 볼 수 있게 해서 즉석에서 수정하도록 한다. 또한 회의록에는 2가지가 꼭 적힌다. 결정사항과 “Action Items”다. 회의에서 어떠한 결론을 냈는지는 별도의 항목에 정리를 하고 회의 이후에 해야 할 일들은 “Action Items”로 따로 정리한다. 회의 참석자들은 실시간으로 내용을 확인해서 동의를 해야 한다. “Action Items”에는 꼭 담당자와 Due date를 지정한다. 회의 후에 바로 이슈관리시스템에 Task를 생성해서 모든 관련자들이 실시간으로 “Action Items”의 진행을 추적할 수 있도록 한다.

다섯째, 회의록은 전직원에게 공유된다.

회의록은 회의 참석자 외에도 전직원에게 공유하는 것이 좋다. 회의록 공유는 성숙된 공유 문화의 중요한 요소다. 실시간으로 공유된 회의록에는 누구나 회의 내용에 질문을 하거나 의견을 줄 수가 있다. 또한 회의 내용이 모두에게 공유가 되면서 업무는 투명하게 진행이 된다. 정보는 독점을 할 때보다 공유를 할 때 더 큰 힘을 발휘한다. 이우소프트는 회의록을 위키시스템을 통해서 작성하고 있다. 따라서 모든 회의록은 손쉽게 검색이 가능하여 회의 내용에 대한 다툼이 없다. 해야 할 일은 이슈관리시스템과 연계돼서 회의와 관련된 모든 업무가 추적된다.

회의는 매우 중요하다. 잘하면 약이 되고 잘못하면 독이 된다. 회의 문화의 변화는 회의 이전에 정보 공유 시스템을 통한 공유 문화가 우선되어야 한다. 그래야 회의가 줄어들면서 회의 문화가 개선되기 시작한다.

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

2017년 8월 19일 토요일

소프트웨어 스펙은 왜 쓰기 어려운가?

스펙을 잘 쓰는 것은 소프트웨어 프로젝트를 성공하기 위한 가장 중요한 요소중 하나라는 것은 이미 수차례 강조한 얘기다.

스펙을 적절히 제대로 작성하지 않았다는 얘기는 건설에서 설계도를 제대로 만들지 않고 건설을 하는 것과 같이 소프트웨어 프로젝트에서도 여러가지 문제를 야기시킨다.

프로젝트가 종료 일정을 지키지 못할 가능성이 높다.
소프트웨어 아키텍쳐가 엉망이 될 가능성이 높다.
소프트웨어 품질을 보장하기 어렵다.
개발자들이 야근에 내몰려 혹사를 당하기 쉽다.
개발에 관련된 지식 축적이 어렵다.
추후 요구사항이 변경되어도 소프트웨어에 어떠한 파급효과가 있는지 예측하기 어렵다.
업그레이드 프로젝트를 효과적으로 진행하기 어렵다.

실제로 많은 회사들에서는 소프트웨어 스펙을 잘 쓰기 위해서 많은 투자를 한다. 그럼에도 왜 스펙을 잘 쓰기 어려운가? 또한 개발자들이 분석 설계를 잘 할 수 있는 뛰어난 아키텍트로 성장이 잘 안되는가?

많은 개발자들은 독학을 통해서 뛰어난 프로그래머가 되기도 한다. 하지만 왜 스펙 작성은 독학으로 잘 안되는가? 스펙은 프로그래밍보다 훨씬 많은 측면으로 분석을 해야 하고 복잡하기 때문이다. 스펙 작성은 골프와 피아노에 비견되곤 한다. 그래서 스펙 작성을 골프와 피아노에 비교를 해보았다.

소프트웨어 스펙 작성	골프	피아노	효과
책을 보고 스스로 공부해서 스펙을 적는다.	골프 잘치는 책을 보고 혼자서 연습한다.	피아노 교본을 보고 혼자서 연습한다.	역효과
강연을 듣고 필요성을 절감해서 스펙을 적는다.	타이거 우즈 특강 모임에서 깨달은 바가 있다.	피아노 잘치는 법이라는 강연을 듣는다.	미미한 효과
인터넷에서 좋다는 Template을 구해서 각 항목을 채운다.	좋다는 골프채를 구매해서 골프를 친다.	좋은 피아노를 사서 열심히 연습한다.	미미한 효과 또는 역효과
일하면서 뛰어난 선배들이 작성한 스펙을 본다.	골프 연습장에 골프를 잘치는 프로가 많아서 수시로 골프 치는 것을 볼 수 있다.	피아노 교습소에 뛰어난 피아니스트가 있어서 연주를 수시로 볼 수 있다.	좋은 환경
스스로 스펙을 작성하고 뛰어난 아키텍트 선배의 리뷰를 받는다.	골프 코치에게 골프를 배우고 연습을 반복한다.	피아노 선생님에게 피아노 치는 것을 배우고 연습을 반복한다.	발전 가능성이 높은 환경
수년간 지속적으로 스스로 스펙을 작성하고 뛰어난 아키텍트 선배의 리뷰를 받는다.	수년간 실전 골프를 치면서 지속적으로 골프 코치에게 스윙을 교정받고 배운다.	수년간 피아노를 치면서 지속적으로 선생님에게 피아노 치는 것을 배운다.	발전 가능성이 가장 높은 방법
본인 스스로도 타 프로젝트의 수많은 스펙의 리뷰에 참여한다.	후배들의 골프 스윙도 봐주면서 이론적으로도 지식을 쌓는다.	후배들이 피아노를 치는 것을 봐주면서 조언을 해준다.	발전 가능성이 가장 높은 방법

이쯤 설명하면 많은 회사들이 왜 스펙을 잘 작성하기 어려운지 이해가 될 것이다.

개인관점으로 보면 좋은 환경을 갖춘 곳에서 일하는 것이 가장 좋다고 할 수 있다. 회사입장에서는 회사를 좋은 환경으로 만들고 좋은 관행을 만들어야 한다. 그럼 회사가 가져야 할 좋은 관행이란 무엇이 있을까?

뛰어난 아키텍트를 여러명 보유한다.
작은 프로젝트라도 스펙을 제대로 작성하고 개발하는 문화를 만든다.
철저한 정보 공유, 투명한 개발 환경
경영진을 비롯하여 많은 프로젝트 관련자들이 스펙을 충분히 리뷰한다.

그럼 반대로 이를 저해하는 나쁜 관행들은 무엇이 있을까?

빠르게 개발한다는 명목하게 주먹구구식 개발을 신봉한다.
원칙보다 기법에 현혹되어 여러 방법론을 기웃거린다.
복잡한 프로세스가 문제를 해결해 줄것으로 맹신하고 강요한다.
코딩이 가장 중요하다고 생각한다.
작성된 스펙에 관심들이 없어서 리뷰에 소홀하다가 개발 후에 부담없이 변경을 요구한다.
상명하복의 조직문화

이런 문화에서는 뛰어난 아키텍트가 있다고 하더라도 무용지물일 뿐이다. 회사는 좋은 관행을 만들어가고 개인들은 좋은 습관을 가지도록 노력할 때 수년 후에는 스펙을 제대로 작성할 수 있는 역량을 갖추고 소프트웨어 개발 역량이 글로벌 회사들과 경쟁할 중요한 기초 역량을 갖추어 가고 있다고 할 수 있다.

share with abctech.software

2017년 8월 13일 일요일

핵심은 아키텍트다

우리나라에는 뛰어난 프로그래머가 참 많다. 우리나라에서 연봉 4천만원 받는 개발자의 능력과 하는 일을 보고 외국의 억대 연봉 개발자가 입이 떡 벌어졌다는 우스개 소리가 인터넷에 떠돌고 있다. 전혀 근거가 없는 얘기는 아니다. 우리나라에서는 개발자가 많은 분야의 일을 해야 하고 밤을 지새면서 엄청난 양의 일을 소화하곤 하기 때문에 일단 많이 배우고 매우 빠르고 숙달되어 있다.

하지만 이것도 잠깐이다. 세월이 흘러 10년차, 20년차 개발자가 되고 나면 외국의 억대 연봉을 받았던 개발자와 비교해서 분석, 설계 역량에서 많이 뒤떨어지게 된다. 결국 연봉 값을 하게 된다. 이는 개발자들의 기본적인 재능이 아니라 환경차이 때문에 벌어지는 일이다.

우리나라에서는 빨리빨리 문화, 상명하복 문화를 비롯해서 여러가지 환경 때문에 아무리 좋은 프로세스를 도입한다고 해도 개발자들에게 분석, 설계 역량이 차근차근 축적이 되어서 10년, 20년 후에 뛰어난 아키텍트로 성장하기가 매우 어렵다.

[사진=Pixabay]

그럼에도 불구하고 우리나라에서는 아키텍트라는 단어에 많이 집착한다. 소프트웨어업계에 아키텍트가 부족하여 발전이 안된다고 하기도 하고, 너도나도 회사에서 아키텍트라는 타이틀을 만들어 남발하기도 한다. 이렇게 아키텍트에 집착하는 것은 여전히 뛰어난 아키텍트가 많이 없어 그에 따른 갈증이 있기 때문으로 해석된다.

이런 현상은 비단 소프트웨어 업계만의 문제는 아니다. 우리나라는 여러 산업분야에서 선진국을 빠르게 따라 잡으면서 실행력은 앞서기도 한다. 하지만 시스템 설계 능력은 겉모습을 보고 따라잡을 수 있는 것이 아니다. 선배에서 후배로 여러 세대를 거치면서 축적된 경험과 노하우가 전승되어 와야 하는 것이라서 우리끼리 독학으로 따라잡을 수는 없는 것이 당연하다.

■ 비즈니스 이해해야 좋은 아키텍처 나와

소프트웨어 아키텍트는 어떤 사람을 말하는 것인가?

한마디로 정의하면 소프트웨어 시스템을 설계하는 사람이다. 소프트웨어 시스템을 작은 모듈까지 축소하면 대부분의 개발자들은 아키텍트이기도 하지만 이슈가 되는 것은 상당히 커다란 시스템을 설계할 수 있는 능력을 가진 사람이 아키텍트다.

누구나 하기도 하고 누구나 잘할 수 있을 것 같은 소프트웨어 분석 설계가 어려운 이유는 아키텍트는 일반 개발자 또는 프로그래머와는 완전히 다른 역량을 요구하기 때문이다.

좋은 아키텍처는 비즈니스에 대한 이해에서 나온다. 대부분은 현재뿐만 아니라 미래 비즈니스 전략도 잘 알아야 한다. 또한 기술적으로도 상당 수준이어야 한다. 업무에 빠삭한 도메인전문가(업무전문가)와는 또 다르다. 문서로 소프트웨어 스펙이나 설계서를 작성할 수 있어야 하고 다른 사람이 이 문서를 보고 소프트웨어를 개발 할 수 있어야 한다. 의외로 이런 역량을 고루 갖추고 있는 뛰어난 소프트웨어 아키텍트는 흔하지 않다.

우리나라는 도메인 전문가가 나름 그 역할을 하고 있다. 업무는 모르는 것이 없이 잘 알지만 분석, 설계 역량은 떨어지고 문서로 스펙과 설계를 작성해서 다른 사람에게 일을 시키지 못하기 때문에 옆에 붙어서 설명을 너무 많이 해줘야 하고, 개발 도중 문제가 생길 때마다 해박한 업무 지식으로 문제를 해결해 나간다. 물론 개발 효율성은 떨어질 수 밖에서 없다.

왜 소프트웨어 회사에 뛰어난 아키텍트가 필요한가?

개발자 3~4명이 진행하는 소규모 프로젝트는 어떻게 개발을 하든지 소프트웨어 개발이 가능하다. 각 개발자들의 프로그래밍 역량이 뛰어나다면 매우 훌륭한 소프트웨어도 만들 수 있다. 하지만 규모가 점점 커지면 개별 프로그래머들의 역량이 뛰어나다고 성공적으로 소프트웨어를 만들기는 어렵다.

개발 복잡도는 소프트웨어 규모에 기하급수로 비례해서 복잡해진다. 또한, 어찌어찌 소프트웨어 개발에 성공을 했다고 하더라도 몇 년 안에 더 큰 문제가 나타난다.

설계가 제대로 되지 않은 소프트웨어는 업그레이드를 할수록 아키텍처가 복잡해지고 곧 유지보수가 새로 개발하는 것보다 어려운 시점이 오게 된다. 물론 회사에 뛰어난 아키텍트가 있는 경우에도 프로젝트

일정이나 복잡한 프로세스에 밀려서 아키텍처를 소홀히 하곤 한다. 그 대가는 미래에 꼭 몇배로 치르게 되어 있다.

■ "국내엔 축적된 노하우 계승해줄 선배들 부족"

그럼, 왜 우리나라에는 소프트웨어 아키텍트가 부족한가?

빨리 빨리 개발 문화부터 상명하복 조직 문화 등 간접적인 원인도 너무나 많지만 가장 큰 원인은 축적된 아키텍처링 노하우를 계승 시켜줄 선배들이 부족하기 때문이다. 그러다 보니 개발 기술은 발달을 하는데 커다란 소프트웨어 시스템을 설계해서 수십, 수백명이 체계적으로 일을 나눠서 문서를 보고 개발을 하는 경험을 해볼 환경이 거의 없다.

소프트웨어 설계에 관련된 좋은 책은 많지만 골프 책이 아무리 많다고 골프 코치가 없으면 소용이 없다. 프로그래밍은 코치가 없어도 책을 보고 배울 수 있는 분야다. 하지만 분석과 설계는 코치 없이 배우는 것이 불가능하다. 또한, 몇 개월 가지고는 부족하다. 수년간 같이 일하면서 노하우를 전승 받아야 한다.

아키텍트를 양성하기 위해서 회사들은 어떤 노력들을 하고 있는가?

대학에서 요구공학이나 소프트웨어 아키텍처 디자인 관련된 강좌 코스에 직원들을 보내기도 하고, 강사를 초빙해서 강의를 듣기도 한다. 물론 다 도움이 되는 일이지만 기대만큼 빠른 성과가 나지는 않는다. 시험을 통해서 아키텍트 양성 후보를 선발하기도 한다. 알고리즘 시험을 보기도 하는데 그런 방법은 고참 개발자는 아키텍트 후보가 된다는 이상한 공식이 성립하기도 한다.

이렇게 자생적으로 소프트웨어 아키텍트를 양성하기 위해서 피나는 노력을 하지만 기대만큼 단기간에 성과가 나고 있지 않다. 물론

수십년 동안 노력을 한다면 분명히 성과가 있겠지만, 수십년을 기다릴 만큼 인내심을 가진 회사는 거의 없다. 결국 제도와 프로세스로 강제화를 하지만 이 문제는 그렇게 해결이 되지 않는다. 오히려 방해가 된다.

그럼 아키텍트는 어떻게 양성해야 하는가?

교육도 좋고 뛰어난 아키텍트를 영입하는 것도 좋은 방법이다. 하지만 가장 좋은 것은 좋은 관행들을 지속적으로 유지하는 것이다.

■ 아키텍트를 양성하는 세 가지 방법

첫째, 소프트웨어를 개발할 때 분석, 설계를 제대로 해서 진행하는 것이다. 물론 문서로 제대로 작성하고 서로 리뷰하고 진행해야 한다. 이런 경험들이 축적되어야 한다. 급하다고 빨리 코딩부터 시작하는 경우가 있는데 그러면 프로젝트는 더 오래 걸리고 노하우가 축적되지 않는다. 물론 학습비용이 필요하기 때문에 처음에는 코딩부터 빨리 시작하는 것이 더 빨리 개발하는 방법일 수도 있다. 하지만 시간이 흐를수록 프로젝트는 더 오래 걸릴 것이다.

둘째, 아키텍트 그룹을 운영하는 것이다. 보통은 가상 조직으로서 Technical Steering Committee나 Architect Group과 같은 이름을 가진다. 회사의 중요한 기술적인 이슈를 논의하고 결정하는 위원회이며 분석, 설계 문서를 집중적으로 리뷰하기도 한다. 아키텍트 후보로 선발된 인원은 이 조직에 참여하여 수년간의 훈련을 받으면 자연스럽게 아키텍트로 성장하게 된다.

셋째, 아키텍트 후보를 선발하는 것이다. 앞으로 아키텍트로 성장할 가능성이 높은 개발자를 후보로 선발하여 수년간 훈련을 시켜야 한다. 물론, 아키텍트는 우수하고 일반 프로그래머는 우수하지 않다는 것이 아니다. 성향이 다를 뿐이다. 그리고 성향에 따라서 적합한 일이 좀 다를 뿐이다. 아키텍트로 성장하려면 다음과 같은 성향이나 소질이 있어야 한다. 글을 잘 쓰고, 다른 사람의 얘기를 잘 들어주고, 창의력이 좋고, 분석적으로 사고를 하고, 정보를 잘 조직화하고, 꼼꼼하며, 논리적인 사고를 하고, 문제의 핵심을 잘 찾고, 인내심이 좋아야 한다. 이를 모두 만족하는 사람은 없지만 몇가지가 일치하면 후보로 선발하여 키워야 한다.

막상 얘기를 해보면 회사에 꼭 필요한 아키텍트를 키우는 데는 기가 막힌 방법이 없다. 골프를 잘 배워서 잘 치는데 기가 막힌 방법이 없는 것과 같다. 물론 잘못 배워서 잘못치는 방법은 부지기수로 많다. 좋은 환경에서 뛰어난 선배들이 좋은 관행을 유지하며 꾸준히 후배들을 가르쳐 주는 것이 가장 보편적인 방법이다. 이렇게 실무를 통해서 배우는 것이 학교에서 수업을 배우는 것보다 몇십배 더 많은 것을 배울 수 있다.

조급하다고 되는 것도 아니고, 프로세스로 강제화 한다고 되는 것도 아니다. 뛰어난 소프트웨어 아키텍트를 여러 명 보유하는 것은 회사의 미래를 결정짓는 결정적인 요소이기 때문에 무시할 수도 없다. 꾸준한 투자를 해야 한다.

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

2017년 8월 9일 수요일

소프트웨어 프로젝트는 왜 실패하는가?

우리는 주변에서 실패한 소프트웨어 프로젝트를 보는 것이 그리 어려운 일은 아니다. 프로젝트의 규모가 커지고 기간이 길어지며 많은 인원이 투입될수록 프로젝트 실패 확률은 증가한다.

프로젝트 성공을 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패했는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

약속된 일정 내에 제품 또는 서비스를 출시 못했다.
소프트웨어가 시장에서 요구되는 품질을 충족하지 못했다. (요구사항, 성능, 안정성, 사용성 등)
프로젝트에 꼭 필요한 기술 개발에 실패했다.
아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
프로젝트에 계획된 예산보다 많은 비용을 지출했다.
프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자.

고객의 요구사항을 충분히 파악하지 못함
제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당부분의 시간을 소모하여 개발 기간이 부족하게 됨
스펙/설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 함
작성된 스펙을 관련자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발함
프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어짐
변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 함
상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작함. 나중에 잘못된 코드를 고치느라고 시간이 더 소요됨
충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕함
일정관리를 대충 해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못함
리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패함
프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 함
프로젝트 팀원들의 팀웍에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트는 산으로 감
도입한 외부 필수 기술이 기대처럼 동작하지 않는다.
테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못함
회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해짐

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 간단히 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인을 “스펙"이라고 생각한다.

다른 영역도 중요한 것이 사실이지만 스펙을 적는 것은 소프트웨어를 개발하는데 가장 중요하면서 가장 어렵다. 스펙을 적는 것을 “분석” 또는 “분석/설계”라고 한다. 설계가 여기에 왜 포함되었는지 의아한 사람도 있을 텐데, 분석 시에 상위 설계의 상당부분이 포함이 되는 경우가 많고 프로젝트에 따라서 다르지만 분석과 설계는 그 경계가 모호하기 때문에 같이 다루는 경우가 많다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가면서 소프트웨어가 무사히 완성을 하기도 한다. 소수의 경험이 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 개발을 잘하기도 한다. 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 테스트 문서도 전달하기도 한다.

소규모 프로젝트에서의 성공의 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사들에서는 이런 함정에 종종 빠진다. 개발은 문서대로 되지도 않을 뿐만 아니라 수시로 바뀌는 요구사항을 문서가 너무 많아서 문서에 반영도 제대로 못한다.

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 관련자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 말짱 공염불일 뿐이다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다.

이 방대한 얘기를 짧은 글로 어떻게 소개할 수 있을지 걱정은 되지만, 개발자가 어떻게 하면 소프트웨어 분석, 설계 역량을 가질 수 있으며 회사는 어떻게 그런 역량을 축적할 수 있는지 다음에 몇 개의 글을 통해서 조금 더 자세히 얘기를 해보고자 한다.

share with abctech.software

2017년 6월 26일 월요일

소프트웨어 회사에서 '공유'가 진짜 어려운 이유

많은 사람들이 소프트웨어 회사에서 가장 중요한 기업 문화 중 하나로 '공유 문화'를 꼽는다. 비단 소프트웨어 회사만의 이슈는 아닐 것이다.

공유에 문화라는 이름이 붙으려면 구성원 대부분이 자연스럽고 일상적으로 정보를 공유해야 한다. 공유가 중요한 이유는 소프트웨어 개발은 집단지성이 작동해야 하는 대규모 지식 산업이기 때문이다. 정보와 지식이 한사람의 머리 속에 머무르지 않고 시스템에 저장되고 효율적으로 관리되어야 비로소 경쟁력을 가질 수 있다.

소수의 슈퍼 개발자가 주도해서 성공한 소프트웨어 회사들이 벽을 못 넘는 이유 중 하나도 '공유문화' 부족이라고 볼 수 있다.

많은 회사들이 “공유문화”를 정착시키기 위해서 당근과 채찍을 동원하지만 제대로 된 '공유문화'를 가지고 있는 회사가 그렇게 많지는 않다. 필자가 경영을 하고 있는 이우소프트도 아직 완벽하지는 않지만 '공유문화' 정착을 위해서 5~6년간 치열한 노력을 해오고 있다.

직원들에게 “공유를 잘하자”라고 말하는 것은 “착하게 살자”라는 정도밖에 들리지 않는다. '공유 문화'가 정착되지 않은 회사에서는 직원들 자율에 맡겨 놔도 '공유 문화'가 정착되기는 어렵고, 프로세스로 강제화해서는 더욱 어렵다.

'공유 문화' 정착이 어려운 이유는 '죄수 딜레마'와 같다. 또한 '교차로 꼬리 물기'와 비슷하다. 교차로에서 신호가 끊겼는데도 바짝 따라붙으면 이로 인해서 다른 방향의 차들은 소통이 안되고 연속으로 차들이 꼬리 물기를 해서 교차로가 꽉 막힌다. 교차로 꼬리 물기를 해결하고 교차로에서 가장 많은 차들이 통과되는 비법은 모든 차들이 꼬리 물기를 하지 않는 것이다.

하지만, 아무리 캠페인을 해도 '교차로 꼬리 물기'가 사라지지 않는 이유는 모두다 규칙을 잘 지키면 서로 혜택을 누릴 수 있지만 누구는 지키고 누구는 지키지 않는 상황에서는 규칙을 지키는 사람이 더 손해를 보기 때문이다. 규칙을 지키지 않아서 이익을 보는 사람은 계속 이익을 보고 규칙을 지켜서 손해를 보는 사람은 계속 손해를 본다면 사람들은 자연스럽게 규칙을 지키지 않는 쪽으로 넘어온다.

게다가 '공유를 하지 않는 행동'은 '교차로 꼬리 물기'처럼 눈에 잘 보이지는 않는다. 제대로 공유를 안해도 공유를 안하고 있다는 사실을 완전히 눈치채기는 쉽지 않다.

또한, 자신이 알고 있는 정보를 모두에게 공유하는 것은 자신이 없어도 회사가 돌아간다는 의미로 해석이 되어 매우 불안한 일이 아닐 수 없다. 그래서 어쩔 수 없이 꼭 공유해야 하는 소량의 정보만 공유를 하고 핵심 지식 정보는 공유를 안하기도 한다.

'공유 문화'에 대해서 서로 얘기를 해도 생각하는 정도가 달라서 잘하고 있는 것인지 개선할 것이 많이 필요한지 판단하기는 매우 어렵다. 그래서 필자가 간단한 평가표를 만들었다. 10점 만점에 8점이상이면 공유 문화가 매우 잘 정착된 회사라고 생각된다. 그 이하라면 심각하게 '공유 문화' 개선에 대해서 생각해봐야겠다. 평가방법은 아래 각 항목당 1점으로 계산하면 된다.

내가 지금 이 순간 회사에서 없어져도 내가 하던 일은 즉시 누군가가 이어받아서 문제없이 진행된다.
어제 회사에 있었던 크고 작은 모든 회의의 회의록이 시스템에 등록되어 있고 누구나 열람이 가능하다.
모든 개발자들(직원)이 서로 다른 나라에서 뿔뿔이 흩어져 있어도 지장없이 일할 수 있다.
나는 회사 Email 시스템에 저장된 모든 Email이 지금 즉시 사라져도 일하는데 전혀 지장이 없다.
나는 지금 이 순간 시스템을 열어서 나의 팀, 부서 모든 인원이 하고 있는 일과 그 통계를 1분안에 알 수 있다.
나는 공유를 위해서 별도로 문서를 작성하지는 않는다. 일을 하다 보면 필요한 문서는 자연스럽게 생성된다.
나를 비롯한 모든 직원에게 회사의 99% 이상의 정보가 실시간으로 공유된다. 공유가 안되는 정보는 극소수에 불과하다.
내가 지금 하고 있는 모든 일은 시스템에 등록되어 있고 계획, 진행상황, 결과가 실시간으로 기록된다.
필요한 정보를 찾기 위해서 이 파일, 저 파일 뒤질 필요 없어 몇개의 검색어로 몇 분 안에 원하는 정보를 찾을 수 있다.
상급관리자나 경영진에게 보고를 하기 위해서 일을 하는 것과는 별도로 PPT를 이용해서 보고서를 만드는 일은 거의 없다.

필자의 회사도 5~6년 전에는 0점에 가까웠지만 꾸준한 노력 끝에 지금은 8~9점으로 평가할 수 있다. 증상에 따라서 처방이 다르기는 하지만 필자가 경험한 몇가지 공유 문화 개선 방법을 제시하고자 한다.

이슈관리시스템, Wiki 등 공유와 협업을 위한 최소한의 시스템을 구축하고 내제화해야 한다. 수단 없이 문화를 이룩하기는 매우 어렵다.
전화나 구두로 논의하고 지시하는 것은 가급적 삼가해야 한다. 메신저도 마찬가지다. 그런 방식은 공유도 안되고 추적도 안된다. 구두로 지시한 것도 시스템에 등록하고 업무를 진행해야 한다. 예외가 있어서는 안된다.
이메일은 안쓰는 것이 좋다. 과거에는 이메일이 업무 혁신의 선두에 있었다면 이제는 골치 덩어리다. 이메일을 정보 보관 수단으로 사용하기 때문에 문제인 것이다. 이메일을 금지하면 자연스럽게 정보는 공유 시스템에 저장된다. 파격적이지만 이우소프트에서는 직원간 이메일이 금지되어 있다. 이메일은 외부용이다.
회의는 10%로 축소해야 한다. 회의가 많은 것은 공유가 잘 안되고 있다는 증거다. 회의를 통제하면 어쩔 수 없이 시스템을 통해서 의논을 하게 된다. 회의는 꼭 필요할 때만 해야 한다.
보고서는 최소화 해야 한다. 지금의 90%는 폐지한다는 생각을 해보자. 보고서가 많다는 것은 공유가 잘 안되고 있다는 증거다. 경영진도 모든 구성원과 동일한 입장에서 시스템을 통해서 공유를 받고 꼭 필요한 경우에만 보고를 받는 것이 좋다.
수평적 사고가 필요하다. 상하 조직 구조에 따른 정보 쏠림 현상을 방지해야 한다. 경영자라고 정보 특별 대우가 없다. 누구에게나 모든 정보가 공유되어야 하며, 의견도 마음껏 개진할 수 있어야 한다.
“공유”를 위해 프로세스를 강제화하기 보다는 인식 전환을 위해서 더 힘써야 한다. 강제적인 추진은 부작용만 부른다. 적절한 강제 조치도 필요하지만 마인드를 바꾸는데 더 힘써야 한다.
정보의 홍수를 경계해야 한다. 정보가 너무 많으면 방관자가 될 수도 있으므로 필수 관련자를 잘 구분하여 필수 인원이 방관자가 되지 않도록 해야 한다. 너무 많은 정보가 쏟아지만 정보는 쓰레기가 된다. 수많은 정보 중에서 자신이 추적, 관여할 정보들을 추리고 체계적으로 볼 수 있는 시스템이 필요하다.
공유를 위해서 정보를 생성하는 것도 중요하지만 내용이 바뀌면 업데이트하고 자연스럽게 흩어진 정보를 모으고 정리하며, 적절히 삭제하는 것도 중요하다. 이런 노력을 들여야 공유의 효율성이 올라가고 잘못된 정보로 인한 문제를 방지한다. 이런 활동을 조직내에 심기 위해서는 끊임없는 코칭이 필요하다.
공유 문화가 어느 정도 수준에 오르면 효율적인 글쓰기가 얼마나 중요한지 알게 될 것이다. 직원들을 뽑을 때 지식이 많은 직원도 좋지만 글도 잘 쓰는 직원을 뽑아야 한다. 개발자도 예외는 아니다. 감동을 주는 글을 적어야 한다는 것이 아니고 자신의 생각을 정확하게 전달할 수 있도록 짧고 명료하게 글을 쓸 수 있는 능력이 필요하다.

이 글을 보면 비법을 공개했다고 회사 관계자들은 걱정할지 모르겠지만 비법은 별것이 없다. 골프를 잘 치는 방법은 책에 모두 나와 있지만 끊임없이 제대로 노력을 해야 골프를 잘 칠 수 있다. 다같이 노력해서 대한민국에 좋은 공유문화를 가진 회사가 많아지면 좋겠다.

문화는 '집단의 습관'이다. 구성원들끼리 더이상 공유하라는 얘기를 안할 때 “문화”가 된 것이다. 한번 자유를 맛 본 사람들은 자유를 박탈당한 환경에서 살기 어렵듯이 진정한 공유 문화를 맛보고 나면 과거로 돌아가는 것은 거의 불가능하다. “공유”가 숨쉬는 것처럼 자연스러워질 때 비로서 글로벌 회사들과 경쟁을 한다고 명함을 내밀 수 있을 것이다.

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

2017년 6월 6일 화요일

이우소프트에 대한 오해와 진실

가끔은 “이우소프트가 개발자에게 그렇게 좋은 회사라면서요?”라는 말을 종종 듣는다. 이 말은 맞기도 하고 틀리기도 하다.

입사지원자에게 듣기도 하고 지인들에게 듣기도 한다. 몇몇 얘기를 듣고 과도하게 확대해석하기도 하고 오해하기도 한다. 모든 현상이 그렇듯이 몇줄의 글을 통해서 상황을 정확히 설명하기란 매우 어렵다. 하지만 내 블로그의 글을 보고 많은 개발자들이 이우소프트에 지원을 하기 때문에 좀더 정확한 설명이 필요하다.

일단 이우소프트는 “개발자가 일하기 좋은 회사”를 만드는 것이 목적인 회사는 아니다.

이우소프트의 비전은 “글로벌 경쟁력을 갖추고 세계 1등의 Software를 만들어 내는 것”이다. 거의 모든 것은 여기에 맞춰져 있다. 이를 위해 행해지는 것들이 개발자에게 좋을 수도 있고 나쁠 수도 있다. 또한 어떤 개발자에게는 좋은 것이 어떤 개발자에게는 나쁜 것이 될 수도 있다.

퇴근 후 개인 시간이 거의 보장된다.

퇴근 후 개인 시간을 보장해야 하는 이유는 생산선 향상 때문이다. 어차피 하루 8시간 이상은 몰입이 어렵다. 또한 퇴근 후에 영어, 운동, 신기술습득, 문화활동 등 장기적으로 성장하기 위한 활동을 해야한다. 그리고 야근이 없다는 오해도 있는데 야근은 있다. 최대한 합리적으로 프로젝트를 진행하려고 하지만 야근에 내몰리는 경우도 종종 있다. 또한 자발적으로 야근을 하는 개발자도 있다.

개발일정은 개발자가 정한다.

기본적으로 맞다. 하지만 여유로운 개발일정을 정하는 것은 절대 아니다. 프로젝트마다 일정의 중요도가 다르기 때문에 프로젝트마다 다른 기준에 따라서 일정이 정해진다. 개발자가 산정한 일정을 가장 우선시하지만 가끔은 고정된 일정에 개발자가 맞춰야 할 때도 있다. 이때는 합리적으로 조정하려고 노력한다. 부족한 일정만큼 개발자를 더 투입하거나, 외주를 투입하거나, 기능을 축소하거나, 단계별로 기능을 제공하거나, QA를 더 투입하거나, 상용 라이브러리를 구매하는등 여러 수단을 동원한다. 스펙을 철저히 쓰고 그렇게 합리적으로 진행하더라도 예상치 못한 Task가 추가로 생기는 등의 변수로 인해서 어려움에 봉착하기도 한다. 이를 해결하기 위해서 PM(Project Manager)과 TL(Technical Leader)은 머리를 맞대고 해결책을 고민한다. 최대한 합리적으로 계획을 세우고 해결책을 수립해도 프로젝트에는 어려움이 닥친다. PM과 TL은 노하우를 쌓아서 이런 상황을 최소화 해나가고 있다.

개발자 캐리어는 확실히 보장한다.

개발자는 확실히 개발만 하게 한다. 그래야 효율성이 높기 때문이다. 전문 PM이 별도로 있어서 관리는 PM이 전담한다. PM 또한 대단한 전문성을 요구한다. 개발자에게는 개발만 요구하기 때문에 개발자로서 확실한 실력을 보여줘야 한다. 끊임없이 공부하고 노력해서 연차에 걸맞는 실력을 보여줘야 한다. 그렇지 않으면 신입 개발자들에게 밀리는 일이 발생한다. 사람들과의 관계와 공력으로 버티는 개발자들은 살아남기 힘든 환경이다. 야근이 별로 없다고 하더라도 퇴근 후에 해야 할 공부가 많다. 개발자는 평생 공부해야 한다고 하지만 성향에 따라서는 쉬운 일이 아니다. 나조차도 종종 고3때보다 공부를 더 하는 것 아닌가 생각할 때가 있다.

모든 것을 공유해야 한다.

공유하지 않는 것은 거의 없다고 보면 된다. 오늘 내가 한 모든 것이 온라인 시스템을 통해서 공개되고 공유된다고 보면 된다. 서로 만나서 말로 논의하고 끝나는 경우가 없다. 10분짜리 회의라도 Wiki 시스템에 기록이 남고 ITS(Issue tracker system)을 통해서 모든 이슈(버그, 개선, 신기능, Task 등)는 시스템에 기록되고 온라인으로 논의한다. 개발외에도 모든 업무가 온라인을 통해서 진행된다. 모든 직원이 당장 떨어져서 일해도 전혀 어려움이 없는 상황이다. 글로 적는 습관과 실력이 없는 사람들은 보통 곤역스러운 일이 아니다.

이것은 회사에게는 큰 장점이다. 직원이 하나 갑자기 빠져나가도 회사는 문제 없이 돌아간다. 하지만 개발자에게는 좋기도 하고 나쁘기도 하다. 열심히 일한 개발자는 자신이 과거해 해놓은 일에 발목을 잡혀서 새로운 일을 못하지 않는다. 언제든지 다른 사람들에게 유지보수를 맡기도 새로운 일을 할 수 있다. 하지만 의도치 않게 자신의 지식과 정보를 숨겨서 이를 자신의 존재가치로 삼는 개발자에게는 아주 안좋은 환경이다. 이런 회사는 개발자가 중요한 자산이기도 하지만 Risk가 되기도 한다.

자연스럽게 모든 정보를 시스템에 남기는 형태로 일하는 것은 습관이 되기 전에는 매우 곤역스러운 일이다. 따라서 모든 개발자에게 꼭 좋은 환경이라고 볼 수는 없다.

개발을 위한 신입사원 교육이 없다.

신입사원 교육이 있기는 하지만 회사의 일반에 관련된 내용이고 개발을 하기 위한 신입사원 교육이 없다. 이는 좋기도 하고 나쁘기도 하다. 신입사원은 입사하자마자 이슈(버그, 신기능, 개선 등)를 할당 받기 때문에 알아서 개발을 해야 한다. 단, 시스템에 거의 모든 정보가 있기 때문에 정보를 찾아가면서 개발을 해야 하고 멘토나 팀장이 가끔 가이드를 해준다. 하지만 옆에 끼고 가르치는 것은 없다. 고참들은 신입사원이 많이 들어와도 이들을 가르치기 위해서 시간을 빼앗기지 않는다. 신입들은 아무도 가르쳐주는 사람이 없어서 막막하겠지만 시스템을 검색해보면 필요한 정보가 거의 다 있기 때문에 본인의 능력여하에 따라서 훨씬 빨리 배울 수 있다. 또한 자연스럽게 본인들도 공유하는 습관을 가지게 된다.

이렇게 어떤 개발자에게는 좋은 환경이기도 하고 어떤 개발자에게는 매우 나쁜 환경이 되기도 한다. 하지만 이런 과정을 통해서 모든 프로젝트는 일정을 지키며 개발자들의 생산성은 매우 높다. 개발자는 글로벌 회사의 개발자들과 다를바 없는 수준으로 꾸준히 회사와 같이 성장할 수 있도록 노력하고 있다.

막연히 좋은 점만 상상을 했다면 이우소프트는 그런 모습은 아니다. 회사가 글로벌 회사들과 경쟁하는 것이 목표이며 이를 위해 필요한 모습을 갖추고 있을 뿐이다. 성향이나 적성이 일치하다면 좋은 환경이지만 그렇지 않다면 적응하기가 쉽지 않다. 물론 신입개발자들은 대체로 적응을 잘한다. 백지에는 무엇이든지 잘 써지기 때문이다.