검색어 개발문화에 대한 글을 날짜를 기준으로 정렬하여 표시합니다. 관련순 정렬 모든 글 표시
검색어 개발문화에 대한 글을 날짜를 기준으로 정렬하여 표시합니다. 관련순 정렬 모든 글 표시

2024년 3월 24일 일요일

소프트웨어 국제화는 나중에 적용하면 늦는다 (24)

 잠시 중단했던 소프트웨어 국제화 칼럼을 재개한다.


당장의 소프트웨어 출시가 급하다고 국제화를 고려하지 않고 일단 개발하고 출시를 했다가 나중에 필요 시에 국제화를 적용하려고 하면 안된다. 비용이 너무 많이 들거나 너무 복잡해져서 제품 자체가 망가지기도 한다.

실제로 많은 회사들이 소프트웨어 국제화에 실패해서 비지니스에서도 실패하는 경우가 많다.




처음에는 국내에서만 팔다가 나중에 해외 진출을 하면서 뒤늦게 국제화를 적용하다가 낭패를 본다.
국제화를 적용하려고 했더니 데이터 베이스의 인코딩 등 설정을 바꿀 수 없기도 하고, 기능이나 UI를 대거 바꾸지 않으면 안되기도 한다. 초기부터 국제화를 적용했을 때의 국제화 비용보다 수십배 또는 수백배가 들기도 한다. 또한 수많은 버그를 만들어내곤 한다.

국제화를 적용하기에는 너무 늦어져 국제화 버전을 따로 개발해서 똑같은 소프트웨어가 여러벌이 되기도 하는데, 이는 더 큰 문제가 된다. 돌아올 수 없는 강을 건넌 것과 같다.

우리가 개발할 소프트웨어가 영원히 한국에서만 팔릴 소프트웨어라면 국제화를 적용할 필요가 없다.
한국에서만 팔리는 소프트웨어라도 한국내의 외국인을 위해서 여러 언어를 지원해야 한다면 국제화가 필요하다.
당장은 한국에서만 판매를 하지만 추후 해외에서도 판매할 계획을 1%라도 가지고 있다면 초기부터 국제화를 적용해야 한다.

당장 국제화 기능이 필요한 것은 아니고 추후 필요한 경우라면 국제화 아키텍처만 적용하여 나중에 국제화가 필요할 때 언제든지 적은 비용으로 빠르게 국제화를 적용할 수 있도록 할 수 있다.

간단한 예를 들어보자.

소프트웨어 내에는 날짜, 시간을 처리하는 수많은 모듈들이 있다. 이것을 국제화를 고려하지 않고 개발자들이 알아서 한국어에만 알맞게 개발을 한다면 어떻게 될까?

한국에서는 잘 동작할 것이다. 하지만 영어, 프랑스어 등 외국어를 지원해야 하는 국제화가 필요할 때는 큰 문제가 된다. 날짜를 처리하는 수많은 코드를 찾아다니면서 모두다 고쳐야 한다.

개발자들이 적절히 날짜 함수에 국제화 코드를 적용했다고 하더라도 문제가 된다. 각각 따로 적용한 국제화 코드는 일관성이 떨어져서 날짜를 표시하는 위치마다 다른 형태의 날짜가 표시될 수 있다.

그럼 당장 국제화가 필요하지 않지만 미래를 위해서 국제화 코드를 미리 적용해 놓으려면 어떻게 해야 할까?

날짜, 시간를 처리(입력, 출력)하는 모든 기능을 별도의 국제화 함수(클래스)로 분리를 하는 것이다. 그리고 모든 개발자는 날짜, 시간을 다룰 때는 꼭 이 국제화 함수를 사용하도록 하는 것이다. 이 국제화 날짜, 시간 함수는 현재는 한국어만 지원하지만 추후 필요할 때 언제든지 다양한 언어를 쉽게 지원할 수 있다.

날짜, 시간 처리 함수는 필요한만큼 다양하게 준비해야 한다. 소프트웨어 UI상 필요한 모든 조합을 함수로 만들어 놓아야 한다.

년월일시분초
년월일
시분초

날짜, 시간 함수 관련 추가 내용은 아래 글을 참조한다.

제공된 국제화 함수 외에 다른 형식의 날짜 출력 함수가 필요하면 개별 개발자는 스스로 함수를 만들어서 사용하면 안된다. 국제화 담당 개발자에게 필요한 날짜 출력 함수를 만들어 달라고 요청한 한 후에 그 함수를 써야 한다. 1인 개발이라면 한명의 개발자가 양쪽 역할을 다하면 된다.

국제화 외부 라이브러리가 모든 것을 해결해주지는 않는다. 외부 라이브러리를 이용하더라도, 현재 프로젝트에 맞게 다 커스트마이징해서 일관된 국제화 함수들을 만들어 줘야 한다. 개발자들에게 각자 알아서 국제화 함수를 사용하라고 하면 일관성이 없고 중구난방이 된다.

국제화 함수 인터페이스는 나중에 바뀌지 않도록 잘 정해야 하므로 경험이 많은 고참 개발자가 정하는 것이 좋다.

날짜 외에도 고려해야 할 것은 많다. 아래 그 예를 보자.

번역이 필요한 메시지, 문자 인코딩(Database, File, 통신), 키보드 글자 배치, 폰트 종류, 글자 크기, 숫자 표기, 띄어쓰기, 쉼표, 마침표, 날짜/시간 표기, 썸머타임, 대소문자, 정렬 방법, 화폐, 무게, 부피, 길이, 종이크기, 온도, 주소, 이름, 제도 관련, 문화 관련 색깔/아이콘 등, 소리, 텍스트를 포함한 아이콘, O/X 기호, 문자 입력 방향

국제화 이슈가 있는 것은 개별 개발자가 마음대로 개발하면 안되고, 국제화 라이브러리에 추가한 후에 사용해야 한다. 모든 소프트웨어가 이 모든 항목을 고려해야 하는 것이 아니므로 국제화 이슈가 있을 것 같은 항목을 만나면, 또는 이미 구현을 했어도 나중에 발견하면 국제화 라이브러리로 옮겨야 한다.

소프트웨어의 어떤 부분이 국제화의 영향을 받을지 찾아내는 것도 중요하다. 그래서 국제화 경험이 많은 개발자가 필요하다. 

개발 초기에 소프트웨어 국제화 전문가에게 컨설팅을 받는 것도 좋다. 대충 개발하고 나중에 국제화가 문제 되어서 큰 비용을 지불하는 것보다 훨씬 경제적이다.

국제화 아키텍처를 어떻게 구성해야 하는지는 아래 글을 참조한다. 실제는 이보다 훨씬 복잡하지만 간단한 참조는 될 것이다.

소프트웨어 국제화는 쉽게 생각했다가는 큰코다칠 수 있지만, 초기부터 제대로 적용하면 큰 무기가 될 것이다.

2020년 10월 17일 토요일

비대면 소프트웨어 개발에 가장 중요한 문서는?

 코로나19로 인해 전세계적으로 비대면 업무 방식이 확대되고 있고 소프트웨어 개발도 비대면 개발 방식이 크게 요구되고 있다. 비대면 업무 방식은 업무 효율성 증대와 생산성 향상에 기여를 하기 때문에 코로나19가 아니라도 도입이 필요하다.

글로벌 소프트웨어 회사인 깃랩은 코로나 이전에도 1300명 전직원이 재택근무를 했고, 구글이나 페이스북 같은 글로벌 소프트웨어 회사도 코로나19 이전부터 상당수의 직원이 풀타임 재택 근무를 수행했고, 현재는 재택 근무를 대대적으로 확대하고 있으며 앞으로 전면 재택 근무로 전환하겠다고 하는 회사도 많다. 이렇게 할 수 있는 이유는 이전부터 비대면 개발이 가능한 형태로 일을 해왔기 때문이다.

비대면 소프트웨어 개발을 위해서는 시스템, 프로세스, 문서, 문화 등 여러가지를 갖추고 있어야 한다. 이중에서 문서는 얘기를 해보려고 한다. 소프트웨어를 개발할 때 프로젝트에 따라서 다르지만 여러가지 문서를 작성한다. 이중에서 비대면 개발을 위해서 가장 필요한 문서는 무엇일까?


비대면 개발에 가장 중요한 문서는 스펙


필자가 생각하는 가장 중요한 문서는 “스펙”이다.

“스펙”은 비대면 개발을 위해서만 필요한 것이 아니고 소프트웨어 개발 전체에 가장 핵심적인 문서이다.

과거 80년대 전세계적인 소프트웨어 위기를 극복하기 위해 소프트웨어 공학이 급속히 발전하면서 소프트웨어 프로젝트 성공을 위해서 가장 중요한 요소로 “스펙”을 꼽았다.

2000년 이후 우리나라의 수많은 대기업들이 글로벌 회사로 성장하면서도 소프트웨어 개발의 문제를 겪으면서, 방법론, 프로세스, 고가의 툴 등을 도입하면서 문제를 해결하려고 했으나, 기대만큼 문제를 해결하지 못했고, 몇몇 회사들은 “스펙”의 중요성을 인식하고 “스펙” 작성 역량에 투자를 하고 있다.

많은 회사들이 소프트웨어를 개발할 때 대략의 요구사항을 가지고 개발자들이 밀접히 접촉하여 의논하면서 소프트웨어를 개발한다. “스펙” 문서를 주고, 자신이 담당한 부분을 나눠서 멀리 떨어진 장소에서 일할 수 있는 회사는 그렇게 많지 않다. 이유는 “스펙” 문서를 제대로 작성하지 못하기 때문이다.

애자일이나 스크럼 방식으로 개발을 하는 경우 과거처럼 “스펙” 문서는 필요 없다고도 하는데, 그렇지 않다. 방식만 다를 뿐이지 “스펙”은 필요하다.

다같이 모여서 개발을 한다면 수시로 의논하며, 조율하여 개발을 해나갈 수 있지만, 비대면 개발을 한다면 그렇게 할 수 없다. 자신이 개발할 부분이 명확하게 정의가 되어 있어야 서로 떨어져서 개발을 할 수 있다. 하지만 스펙 문서가 없이 개발하거나 대략의 요구사항을 가지고 서로 모여서 조율해가면서 개발하는 방식에 익숙한 대부분의 회사들은 비대면 개발을 할 수가 없다.

그럼 코로나 이전에도 1300명의 전직원이 재택근무를 하고 있는 깃랩이나, 수많은 직원이 집에서 일하고 있었던 구글이나 페이스북은 어떻게 진작에 비대면 개발을 광범위하게 수행하고 있었을까?

시스템, 프로세스, 문화, 문서 등 여러가지 요소가 있지만, 잘 작성한 스펙이 그중에서 중요한 역할을 한다. 코딩은 개발 단계에서 가장 많은 인원이 참여하는 단계다. 많은 개발자가 서로 떨어져서 일할 수 있도록 스펙을 잘 작성해서 공유하기 때문이다.

여기서 문제는 스펙을 잘 작성하는 것이 소프웨어 개발에서 가장 어려운 주제라는 것이다. 국내 많은 기업들이 소프트웨어 개발 역량을 글로벌 수준으로 끌어 올리는데 여전히 어려움을 겪고 있는 이유도 스펙 작성의 어려움이 한 요소로 작용하고 있다.

스펙 문서는 꼼꼼하게 모든 것을 방대하게 작성하는 것이 잘 작성하는 것도 아니고, 간단하게 작은 문서로 작성하는 것이 잘 작성하는 것도 아니다. 방대한 템플릿을 꼼꼼하게 채우는 것이 올바른 방법도 아니다.

스펙의 역할은 여러가지가 있지만, 개발자 관점에서는 스펙 문서를 보고 자신이 개발한 부분을 충분히 구현할 수 있을 정도가 되어야 한다.

잘 작성한 스펙 문서가 어떤 것인지는 칼럼에서 짧게 다룰 수 있는 주제는 아니다. 그래서 여기서 스펙 문서에 대해서는 구체적으로 자세히 설명하지는 않겠다.

거대한 방법론이나 소프트웨어 공학 이론에서도 소프트웨어 스펙을 작성하는 방법을 이론적으로 다루고 있고, 이를 따라하면 방대하고 복잡한 스펙을 작성해야 한다. 하지만 깃랩, 구글, 페이스북이 이런 방식을 따르고 있지 않다. 이론은 이론일뿐, 실전적인 방법으로 스펙을 작성하고 있다. 대부분의 회사는 이런 이론을 따라하다가는 백이면 백 실패한다.

스펙을 작성하는 방법은 피아노와 골프를 배우듯 실전적인 방법을 배워나가야 한다.

10배의 비용과 시간을 들여서 완벽하게 자세한 스펙문서를 작성할 수 있을지는 몰라도 대부분의 실제 프로젝트에서 그런 방법은 쓸모가 없다.

최소 비용으로 효과적으로 스펙을 작성하는 것이 실전적인 방법이다. 


스펙은 목적은 소프트웨어를 최단 시간, 최소 비용으로 개발하기 위한 것


소프트웨어 프로젝트에서 스펙을 잘 작성하는 목적은 소프트웨어를 최단 시간, 최소 비용으로 개발하기 위함이다.

그래서 거대 방법론에서 제안하는 수십가지의 문서를 작성하는 방법은 실전적인 프로젝트에서 효용성이 떨어진다. 많은 회사가 이 방법을 시도했다가 포기하거나 프로세스는 따르지만 정작 소프트웨어 문제를 해결하지 못한 상태가 계속 되곤 한다.

아직도 많은 회사들이 소프트웨어 개발에 문제를 가지고 있다. 대부분의 프로젝트는 계획된 일정에 끝내지 못한다. 그래서 계획된 사업 로드맵에 맞춰 제때 소프트웨어가 출시되지 못해서 많은 사업이 차질을 빚고 있다. 또한 출시된 소프트웨어는 여러가지 문제가 발생하고 유지보수에 어려움을 겪고 있다. 소프트웨어 회사의 사업을 영위하는데 큰 어려움을 주고 있는 것이다.

이러한 소프트웨어 문제를 해결하기 위해서는 소프트웨어 공학에서 언급하는 프로세스, 툴, 품질, 설계, 형상관리 등 여러가지가 다 필요하고 이러한 것들은 충분히 확보가 가능하다.

하지만 가장 근본적이고 어려운 “스펙"을 작성하는 역량을 확보하지만 않으면 넘을 수 없는 벽에 부딪히게 된다. 소프트웨어에 있어서 2류까지는 가능할지 몰라도 1류가 되기는 어렵다.

그래서 나는 기업들이 소프트웨어 문제를 해결하고 구글이나 페이스북과 같은 글로벌 수준의 소프트웨어 개발 역량을 확보하고 싶다면 개발자들이 스펙을 제대로 작성할 수 있는 역량을 확보할 수 있도록 해야 한다고 주장한다. 

스펙은 분석 아키텍트가 혼자서 스펙이라는 문서를 달랑 작성하면 되는 것이 아니다. 스펙을 제대로 작성한다는 것은 회사 전체가 같이 움직이는 것을 말한다. 모든 관련자가 요구사항을 충분히 수집에 협조하고, 여러 전문가가 참여를 하며 작성된 스펙 문서에 대해서 관련자들이 철저히 리뷰를 하고 변경관리도 제대로 해야 한다. 모든 직원들은 스펙 문서를 이해하고 읽고 이에 따라서 일할 수 있어야 하고, 개발자는 스펙 문서를 파악하고 떨어져서 개발을 할 수 있어야 한다. 이러한 관행을 갖추려면 많은 노력과 오랜 시간이 걸린다.

여기서 중요한 것은 방법론, 툴이 아니고 문화, 습관, 인식의 변화다. 또한 이런 것을 이끌려면 경영자의 강력한 의지도 중요하다. 몇년전 국내 S사에서 소프트웨어 역량의 근본적인 해결을 위해 내부에서 분석아키텍트를 양성하기 위한 노력을 시작했는데 이런 활동을 매우 긍정적으로 생각한다. 시간이 오래 걸리겠지만, 꾸준히 노력하면 글로벌 수준의 소프트웨어 역량을 갖추는데 중요한 발판이 될 것으로 생각한다.

대기업보다 움직이기 수월한 스타트업이나 중소기업은 노력여하에 따라서 스펙 작성 역량을 확보하기 더 용이하다. 소프트웨어 1류가 되고 싶다면 스펙에 관심을 가지고 스펙 역량을 확보해야 한다.


2020년 8월 11일 화요일

효율적 비대면 업무를 위해 사용하면 안되는 5가지

 소프트웨어 개발 뿐만 아니라 모든 업무에서 비대면 방식을 지향하고 있는 회사에서 쓰면 안되는 것들이 있다. 흔히 쓰기도 하고 막상 편리하고 익숙하지만 사용하면 할수록 비대면 업무를 방해하는 것들이다. 이런 툴, 시스템, 방식은 투명한 업무, 공유, 추적, 협업에 저해되는 것들이다.

 

미국의 많은 소프트웨어 기업들은 오래 전부터 비대면 업무 방식에 많이 적응해 왔다. 그래서 코로나19로 인해서 어쩔 수 없이 비대면 업무 방식으로 전환을 해야 하는 상황에서 많은 소프트웨어 기업들은 무리 없이 비대면 업무를 적용하고 있다.

 

구글과 페이스북은 대대적인 재택근무를 시행하고 있고, 그 기간을 연장하고 있다. 앞으로도 재택근무를 더욱 늘리고 재택근무 위주로 돌아가는 회사로 전환하려고 하고 있다. 이미 사무실도 하나 없이1,200명의 인원이 재택근무를 하고 있는 GibLab이라는 회사도 있다.

 

하지만 우리나라 회사들은 주중에 하루, 이틀을 재택근무를 시도하거나 아예 시도조차 못하는 회사도 많다. 얼굴을 안보면 일이 안되는 구조를 가지고 있기 때문이다. 재택근무, 비대면 방식으로 업무를 수행하기 위해서는 시스템, 프로세스, 인식, 문화 등의 개혁이 필요하다. 이와는 반대로 주의할 것도 있다.

 

그럼 효율적인 비대면 업무 진행을 위해서 사용하면 안되는 것들을 알아보자.

 

1. 내부 이메일 시스템

 

이메일 시스템은 회사에 꼭 필요하다. 외부 업체와 메일을 주고 받고, 직원들 간에도 업무를 할 때 이메일을 사용 하기도 한다. 하지만 비대면 업무 방식을 가로막는 가장 강력한 방해 요소이기도 하다.

 

결론부터 말하면 내부 직원끼리는 이메일 사용을 금지하는 것이 좋다. 좀더 자세히 말하면 업무 내용이 직원 간에 이메일로 유통되면 안된다. 하지만 대부분의 회사에서 직원간 이메일을 금지하면 큰 반발에 부딪힐 것이다.

 

이메일에는 치명적인 문제가 있다. 직원들 간에 이메일로 업무를 하면 다른 직원과는 공유가 안되고 업무의 추적이 어렵다. 처음에는 둘만 아는 정보였다가 나중에는 두 사람도 잊어버리는 정보가 된다. 퇴사자가 발생할 때도 문제다. 퇴사자 이메일함에 있는 정보는 처치 곤란이다. 실수로 모두 지워 버리기도 한다. 나중에 필요할 수가 있어서 보관을 해 놓아도 찾기도 어렵고, 관리도 어렵다. 업무 정보가 이렇게 흩어지고 관리가 안되면 비대면 업무를 제대로 할 수가 없다.

 

업무에 해당하는 내용은 절대로 이메일로 공유하면 안된다. 이슈관리시스템을 사용하고, 지식정보는 Wiki 등의 시스템에 정리하여 공유해야 한다. 

 

실제로 직원간 이메일을 완전히 금지한 회사도 처음에는 반발이 심했지만, 몇 개월이 지나 업무 효율이 크게 증가하는 것을 느낀 후에는 과거로 돌아갈 수 없다고 한다. 

 

예외는 외부에서 메일을 받은 경우인데, 이 경우도 해당 메일을 이슈관리시스템에 등록하여 공유하고 추적할 수 있도록 해야 한다. 귀찮지만 꼭 그렇게 해야 한다.

 

2. 개인 메신저, 채팅 

 

기업용 협업 시스템이 아닌 카카오톡 등의 개인 메신저를 사용하면 안된다. 좀더 자세히 말하면 업무 내용이 개인 메신저 시스템을 통해서 공유되고 유통되면 안된다. 공유, 관리, 추적이 안되기 때문이다.  

 

물론 업무 내용이 아닌, 잠깐 보자거나, 점심을 뭐 먹을지 등의 내용은 개인 메신저를 사용해도 된다. 하지만, 업무 관련된 의견을 물어보거나 정보를 공유하는 등의 내용은 기업용 메신저를 사용해야 한다. 급한 것이 아니라면 이슈관리시스템을 사용해야 한다.

 

기업용 메신저는 여러 사람이 볼 수 있고 투명하게 업무가 진행되며 회사의 정보 자산이 된다. 직원들의 감정 소비가 줄어드는 효과도 있다. 개인 메신저는 업무용으로 사용하지 못하도록 공식적으로 금지하는 것이 좋다.

 

3. 온라인화 되지 않은 문서

 

워드, 엑셀 문서들을 개인 PC에 저장해 놓고 완성본만 이메일로 전송하는 방식은 최악이다. 버전 관리도 안되고, 구버전의 잘못된 정보가 유통되기도 하고, 공유도 잘 안된다.

 

회사에서 생산되는 모든 문서는 회사의 공용 문서 관리시스템에 저장해서 관리해야 한다. 요즘은 클라우드에 회사 문서를 저장하는 것이 일반적이다.

 

회사의 모든 문서를 온라인 시스템에서 관리를 하려면 정교한 전략이 필요하다. 공간 및 폴더 구조, 파일 이름 규칙, 권한 설정, 버전 관리 전략 등 수많은 해결 해야할 문제가 있다. 전략을 제대로 세우지 않으면 문서가 온라인에만 있지 뒤죽박죽인 경우도 있다. 그래도 개인 PC에 굴러 다니는 것보다는 훨씬 낫다.

 

퇴근 후 회사의 모든 PC가 불타 없어져도, 정보 자산 관리에는 문제가 없어야 한다. 복구하는데 시간이 걸리겠지만 이런 기준으로 문서를 온라인에 저장하는 전략을 수립하면 부족함이 없다.

 

4. 종이 문서

 

종이를 없애야 비대면으로 업무를 수행할 수 있는 것은 자명하다.

 

위에서 언급한 온라인화 되지 않는 문서와 일맥상통하는 것이다. 워드나 파워포인트로 작성한 문서를 인쇄해서 상급자에게 보고를 하곤 한다. TV 드라마를 보면 결재판에 결제 문서를 넣어서 도장을 받고, 마음에 안 들면 집어 던지기도 하는데, 재미를 위한 연출인지 아직도 종이로 업무를 하는 회사가 많은지는 모르겠다. 종이 문서는 가독성이 뛰어난 장점이 있기는 하나 그 외에 여러 면에서 단점이 많다. 종이 문서를 없애야 업무의 속도가 빨라지고 공유, 추적, 관리에 유리하다. 부수적으로 종이 비용을 절약하는 효과도 있다.

 

5. USB 메모리

 

비대면으로 업무를 수행하려면 인터넷이 연결되는 곳이라면 어디에서나 일을 할 수 있도록 해야 한다. USB 메모리에 파일을 넣어 다니면서 일을 하는 것은 구시대적인 방법이다. 회사의 문서 관리 시스템이나 클라우드에 모든 문서를 저장하고 어디서나 접속하여 업무를 할 수 있어야 한다.

 

또한 USB 메모리는 회사의 보안을 취약하게 만드는 요소이므로 사용하지 않는 것이 좋다.

 

비대면 방식은 코로나19로 인한 필요성도 있지만, 업무 효율성 및 생산성을 높여주는 것과 일맥 상통한다. 비대면 업무 방식으로 전환하려고 하는 회사는 필요한 것을 도입하는 것도 필요하지만, 사용하면 안되는 것을 제거하는 것도 필요하다. 그렇다고 무작정 제거하기보다는 정교한 전략이 필요하다. 없애는 것을 보완할 시스템이 필요하며, 프로세스, 문화, 교육 등에 투자해야 비대면 업무 방식으로 전환하여 기업의 경쟁력을 높일 수 있다.


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

2020년 7월 29일 수요일

비대면 소프트웨어 개발을 위한 핵심 시스템 10가지

비대면으로 소프트웨어를 잘 개발하는 방법은 비대면이 아니라도 일반적으로 소프트웨어를 잘 개발하는 방법과 다르지 않다. 그래서 비대면으로 소프트웨어를 잘 개발하는 방법을 도입하는 것은 의미가 있다.

비대면으로 소프트웨어를 효과적으로 개발하기 위해서는 필수적으로 도입해야 하는 툴, 시스템이 있다. 이 툴 중 대부분은 비단 소프트웨어 개발 뿐만 아니라 회사의 일반 업무에도 필요한 시스템이다. 소프트웨어 회사가 아니라도 관심을 가지고 보자. 툴과 시스템을 도입하는 것은 회사의 문화, 인식, 프로세스를 바꾸는 것보다는 쉽다.

좋은 툴, 시스템을 도입해야 개발 및 업무 효율성이 배가 된다. 툴, 시스템은 오랫동안 진화를 해왔고, 지금도 진화하고 있다. 이것들을 잘 선택하는 것도 실력이다. 워낙 많은 툴, 시스템을 도입해야 하기 때문에 선택도 쉽지는 않다. 그렇다고 잘 도입해서 사용하고 있는 한 회사의 사례를 그대로 따라하는 것도 좋은 것은 아니다. 회사마다 프로젝트의 성격, 규모, 문화, 환경이 다르기 때문이다.

꼭 비싼 툴을 도입하는 것이 좋은 것은 아니다. 그렇다고 무료 툴이 무조건 좋은 것도 아니다. 비싼 툴은 비싼 값을 하지만 기능이 너무 많거나 복잡해서 회사에 따라서는 오히려 과한 경우도 있다. 회사의 규모, 문화, 프로세스에 따라서 적합한 툴의 조합을 잘 선택해야 한다.

툴, 시스템을 도입하는 것은 쉽지만 잘 쓰는 것은 어렵다. 도입만 하고 안쓰거나 형식적으로 쓰는 경우도 많다. 툴만 도입하고 프로세스와 연계를 안하거나 회사의 상황에 너무 과한 툴, 시스템을 도입한 경우에도 정착에 실패할 수 있다.

회사의 기존 프로세스를 잘 적용할 수 있는 시스템을 선택하기 보다는 툴, 시스템의 철학에 맞게 회사의 프로세스와 업무 방식을 바꾸는게 낫다. 업무 방식은 좀더 자율적이고 능동적이어야 하며 수평적으로 바뀌어야 한다. 그래야 비대면 업무가 효율적으로 진행될 뿐만 아니라 생산성도 증가한다.

각 툴, 시스템들은 서로 연결이 되어서 유기적으로 작동한다. 한 회사에서 개발한 여러 툴 세트를 쓰면 연동이 잘 되기는 하지만 그렇다고 한 회사의 툴을 쓰는 것이 무조건 좋은 선택은 아니다. 회사의 프로세스와 잘 엮어서 여러 회사의 툴을 섞어 사용하기도 한다.

그럼 비대면 소프트웨어 개발을 위해서 꼭 도입해야 할 시스템을 알아보자.

1. 문서 공유 시스템


문서들이 직원들의 각자 PC에서 생산되고 이메일을 통해서 돌아다닌다면 보통 혼란스러운 것이 아니다. 문서의 버전을 관리하기도 어렵고, 보관도 어렵다. 문서 공유 시스템을 도입하면 문서의 버전을 철저히 관리하고 적절한 공유, 권한 제어, 외부 전달, 백업이 가능하다. 비용이 들기는 하지만 비용 이상의 생산성 향상을 줄 수 있는 시스템이다.

가장 마음이 드는 기능 중 하나는 검색 기능이다. 시스템마다 차이는 있지만 회사의 수만 개의 문서 중에서 내가 찾는 문서를 간단한 검색을 통해서 몇 초 만에 찾아준다. 문서의 본문까지 모두 찾아주는 시스템도 있으니 매우 편리하다.

몇몇 문서 공유시스템은 PC의 파일 탐색기와 연동하여 편리하게 사용할 수 있도록 해준다.

회사의 문서를 외부 공간인 클라우드에 저장하는 것에 보안 상 우려를 하는 기업도 있지만, 회사 내부에서 여기저기 문서가 굴러다니는 것보다 더 안전할 수 있다.

대표적인 시스템으로는 Dropbox, Apple iCloud, Google Drive, MS Sharepoint, Amazon WorkDocs 등이 있다.

국내 기업으로는 사이버다임사의 문서관리시스템이 있다.

2. 문서 공동 작업/리뷰 시스템


문서 공유 시스템과 접목하여 문서를 공동 작업 및 리뷰할 수 있도록 하는 시스템이다. 여러 사람이 동시에 문서를 작업해도 충돌 없이 같이 작업할 수 있다. 완벽한 문서 공동 작업 솔루션이 나온 것은 그렇게 오래되지 않았다. 불과 수년 전만 해도 상상하기 어려웠던 기능인데, 이제는 일반화 되었다.

문서를 리뷰할 수 있는 기능도 제공한다. 문서 리뷰를 실시하면 여러 관련자가 문서의 곳곳에 자신의 의견을 댓글로 남기면서 토론을 할 수 있다. 그 결과를 문서에 반영하고 다시 리뷰를 진행하는 사이클로 진행된다. 이렇게 문서 온라인 리뷰를 진행하면 관련된 모든 사람의 의견을 꼼꼼히 문서에 반영할 수 있다. 이런 시스템 없이 오프라인으로 문서를 리뷰하고 반영하는 것은 보통 어려운 일이 아니다. 오프라인으로 문서를 작성한 것보다 훨씬 완성도 높은 문서를 작성할 수 있다.

이렇게 문서를 온라인으로 보관하고 공동 작업하고 리뷰하는 프로세스를 적용하고 적응해 나가면 어느덧 비대면 업무 방식에 익숙해져 간다.

대표적인 시스템으로는 MS Office 365, Google Docs, Apple iWork 등이 있다.

3. 요구사항 관리 시스템


소프트웨어를 개발하는데 있어서 가장 중요한 것 하나를 꼽으라면 요구사항을 분석해서 스펙을 작성하는 일이다. 스펙을 문서화 하기 위해서 MS Word로 작성하기도 하고, GoogleDocs, Wiki를 이용하기도 하지만, 전문적인 관리시스템을 사용하기도 한다.

MS Office와 같은 문서 위주의 편집 툴을 사용하여도 소프트웨어 요구사항을 충분히 분석하고, 협업하고, 리뷰할 수 있지만, 전문적인 요구사항 관리 시스템은 조금 더 많은 기능을 제공한다.

요구사항을 수집, 관리, 협업, 리뷰, 버전 관리, 요구사항 추적, 재활용 등에서 좀더 많은 기능 및 편리함을 제공한다. 요구사항 분석 역량을 충분히 갖춘 회사라면 한번 도입해 볼만하다.

대표적인 시스템으로는 Jama, Orcanos, DOORS, ReqSuite, Accompa 등이 있다.

4. 이슈 관리 시스템


이슈 관리 시스템은 소프트웨어 회사만 필요한 시스템이 아니다. 이슈 관리 시스템은 버그 관리 시스템에서 출발하여 점차 진화를 거듭하여 회사의 모든 이슈를 관리하는 시스템으로 성장하였다. 이제는 거의 모든 형태의 회사에 필요한 시스템이 되었다.

이슈 관리 시스템은 단순히 설치해서 사용하는 것 만으로는 그 혜택을 다 볼 수 없다. 회사의 업무 철학과 방식이 바뀌어야 한다. 업무 방식을 지시와 보고 형태에서 자발적 업무와 모니터링 형태로 바뀌어야 한다. 일일이 업무를 지시하고 추후 결과 보고를 받는 형태로 업무를 계속 하면서 그 프로세스를 이슈 관리 시스템에 적용하면 비대면 프로세스로 전환하기도 어렵고, 이슈관리시스템의 철학과는 좀 멀어지고 업무 효율성도 떨어진다.

이슈 관리 시스템이 완전히 정착되면 모든 업무가 투명하게 진행되는 효과가 있다. 투명한 업무 진행을 꺼려하는 조직도 있지만, 적응하고 나면 업무 생상선이 대폭 증가하는 것을 경험할 수 있다.

이슈 관리 시스템을 도입하여 효과를 최대로 보고 비대면 업무를 효율적으로 진행하려면 업무 방식을 바꾸는 것에 많은 노력을 들여야 한다는 것을 명심하자.

대표적인 시스템으로는 Jira, Redmine, Mantis, Bugzilla, Trello 등이 있다.

Jira는 상용 소프트웨어지만 현재 10유저까지는 무료로 제공하고 있어서 스타트업에서 매우 유용하게 쓸 수 있다.

5. 소스코드 관리 시스템


소스코드 관리 시스템을 사용하지 않는 소프트웨어 회사는 거의 없을 것이다. 만약에 특별한 이유로 소스코드 관리 시스템을 사용하고 있지 않다면 꼭 도입을 해야 한다. 특별한 이유라는 것도 소스코드 관리 시스템을 사용하지 못하는 결정적인 이유는 아닐 것이다.

소스코드 관리 시스템은 도입은 쉽지만 제대로 쓰는 것이 만만치는 않다. 브랜치, 머지, 베이스라인, 체크인에 대한 여러가지 규칙을 잘 만들고 지켜야 한다.

소스코드 관리 시스템은 중앙 집중형과 분산형이 있으니 회사의 상황에 맞게 선태하면 된다.

대표적인 시스템으로는 Subversion, Git, Murcurial, Perforce 등이 있다.

설치형, 클라우드 형이 있으며, 클라우드 형으로는 Github, Gitlab, Bitbucket 서비스 등이 있다. 각자 유/무료 정책이 있으니 비교하여 선택하면 된다.

6. CI(지속적인 통합) 시스템


개발자들이 서로 떨어진 장소에서 얼굴 안보고 실시간으로 협업을 하기 위해서는 소스코드가 항상 빌드가 가능한 상태로 유지가 되어야 한다. 소스코드는 매시간, 매분 새로 업데이트가 된다. 그런데, 한 개발자가 빌드가 안되는 상태의 소스코드를 등록하면 개발팀 전체가 개발에 차질이 생긴다. 개발자는 항상 빌드 가능한 소스코드를 등록해야 하며 이 규칙은 매우 엄격하다.

CI(지속적인 통합) 시스템을 이용하면 소스코드를 등록할 때마다 소스코드를 점검하고, 빌드 가능한 상태를 유지하도록 도와준다. 이때 회사의 코딩 규칙 검사, 자동 테스트 등을 수행하며 소스코드의 버그를 줄여주기도 한다.

CI 시스템이 잘 구축되어 있으면 개발자는 자신이 담당한 모듈을 코딩해서 소스코드 관리시스템에 등록하기만 하면 된다. 나머지는 시스템이 알아서 해준다.

대표적인 시스템으로는 Jenkins, Bamboo, Cirble CI, GitLab CI 등이 있다.

7. 코드 리뷰 시스템


코드 리뷰는 온라인, 오프라인으로 진행하며 여러가지 방법이 있지만, 비대면 개발을 위해서는 코드 리뷰 시스템이 필수다. 모여서 코드 리뷰를 할 필요가 없고, 온라인 코드 리뷰 시스템에 코드 리뷰를 등록하면 관련된 수많은 사람이 온라인으로 코드 리뷰를 진행한다. 온라인 코드 리뷰는 오프라인보다 훨씬 많은 사람이 참여할 수 있고, 시간을 많이 절약해준다. 그래서 코드 리뷰를 좀더 활성화하는데 도움을 준다.

회사의 프로세스마다 다른데, 소스코드를 등록한 후에 코드 리뷰를 하기도 하고, 코드 리뷰를 통과한 소스코드만 회사의 메인 소스코드 저장소에 등록하도록 하기도 한다.

코드 리뷰가 활성화 된 회사일수록 개발자가 더 잘 성장한다. 그리고 고참 개발자가 될수록 코드 리뷰에 더 많은 시간을 할애해야 한다. 고참 개발자는 코드 리뷰를 통해서 후배를 양성하기도 하지만, 본인이 성장하는 수단이 되기도 한다.

많은 회사들이 코드 리뷰 도입에 실패하지만, 좋은 온라인 코드 리뷰 시스템을 도입하면 코드 리뷰 정착에 도움이 된다.

대표적인 시스템으로는 Gerrit, Crucible, GitHub, GitLab, Review Board 등이 있다.

8. 지식 공유 시스템


소프트웨어 회사만 필요한 시스템은 아니다. 회사에서 업무를 하다 보면 공유할 수많은 정보, 지식이 생성된다. 지식 공유 시스템이 없다면 이런 정보는 연기처럼 사라지거나 개인의 저장소에 묵히게 된다.
정보를 생산할 때 실시간으로 정보를 정리하여 공유할 시스템이 필요하다. 그래서 지식 공유 시스템은 비대면 개발의 핵심이다.

회사, 제품, 프로젝트, 프로세스 등 여러가지 분야로 잘 나뉘어서 정리된 지식과 정보는 이 사람 저 사람 찾아다니면서 물어보지 않아도 업무를 할 수 있게 해준다. 원격으로 접속 가능한 시스템이므로 지역적인 제약없이 일할 수 있다.

대표적인 지식 공유 시스템은 Wiki와 KMS다. Wiki의 용도는 매우 다양하다. 이를 회의록으로 사용하는 경우도 많고 회의록 기능을 강화한 Wiki 시스템도 있다.

설치형, 클라우드형이 있다. 장단점이 있으니 상황에 맞게 선택해야 한다.

대표적인 Wiki 시스템으로는 Confluence(10유저 무료), Bookstack(무료), Wiki.js(무료) 등이 있다.
KMS는 국내업체인 사이버다임날리지큐브가 제공하고 있다.

9. 화상 회의 시스템


비대면 개발을 하더라도 얼굴을 보고 회의를 해야 할 때도 있다. 재택 근무가 완벽하게 진행되어 모든 업무를 문서와 시스템으로 진행한다고 하더라도, 정서상의 이유와 팀워크 유지를 위해서 얼굴을 보고 얘기를 할 필요도 있다. 또 온라인으로, 문서로 쉽게 답이 안나오는 이슈는 얼굴 보고 논의하는 것이 훨씬 효율적이다. 이럴 때는 웹캠을 이용해서 화상 회의를 실시하는 것이 좋다.

화상 회의는 주기적인 프로젝트 회의로 진행하기도 하고, 이슈가 있을 때 비정기적으로 실시하기도 한다.

회상 회의는 1:1 뿐만 아니라 여러 명이 동시에 회의를 할 수도 있다. 여러 명이 원활히 화상 회의를 하기 위해서는 빠른 인터넷도 필수다. 화상 회의는 일반 회의와 마찬가지로 용건만 짧게 빠르게 진행해야 한다.

화상 회의 시스템은 부가 기능으로 녹화, 화면 공유, 화이트 보드, 그룹 스케줄러 기능을 제공하기도 한다.

대표적인 시스템으로는 Teams, Skype Business, Google Meet(hangout), Zoom 등이 있다.

10. 협업 시스템


협업을 위한 여러가지 기능을 한꺼번에 넣어 놓은 종합 선물세트다. 소프트웨어 회사 뿐만 아니라 모든 형태의 회사에 비대면 업무를 효율적으로 진행하기 위해서 필요한 시스템이다.

기본적으로 팀 관리, 채팅, 파일관리 등이 기본 기능이지만 화상 회의, Wiki 등 위에서 언급한 여러가지 툴 중 일부를 포함하고 있는 경우도 많다.

비대면 업무 필요성이 증가할수록 도입하는 기업이 늘 것으로 생각된다.

대표적인 시스템으로는 Teams, Slack, Swit, 잔디, 라인웍스 등이 있다.

이상 10가지의 시스템을 알아봤는데, 이런 시스템을 모두 사용한다고 완벽하게 비대면으로 소프트웨어를 개발할 수 있는 것은 아니다. 또한 모두 비대면으로 소프트웨어를 개발해야 더 생산성이 높은 것은 아니다. 시스템을 잘 활용하여 개발과 업무를 진행하면 비대면 비율이 높아질 수 있다. 그 자체가 개발 및 업무 생산성이 높아지는 것과 일맥상통한다.

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

2020년 7월 10일 금요일

코로나19 시대에 비대면 소프트웨어 개발이 필수

코로나19가 우리의 일상을 바꾸고 일하는 방식도 변화 시키고 있다. 그러면서 여러 분야에서 직접 만나지 않고 일을 하는 비대면 방식으로의 업무 방식을 도입할 수 밖에서 없게 되었다.

이러한 비대면으로 일하는 방식은 소프트웨어 개발에 있어서 긍정적인 측면이 있다. 비대면 방식의 개발이 글로벌 수준의 소프트웨어 개발 방식과 일맥상통한다. 또한 비대면 방식은 소프트웨어 개발 비용의 감소와 효율적인 개발과도 맞닿아 있다. 그동안은 이런 비대면 방식의 개발이 많은 기업에서 도입이 어려웠다. 그동안 해오던 방식을 바꾸기 쉽지 않는 것이 한 이유인데, 이제는 필수적으로 비대면 방식을 도입해야 한다. 따라서 비대면 방식이 소프트웨어 개발에 어떠한 영향이 있는지 짚어보고자 한다.

그럼 소프트웨어를 비대면 방식으로 개발해야 하는 가장 큰 이유는 무엇일까?

개발 비용이 적게 들기 때문이다.


가장 큰 이유는 개발 비용이 적게 들기 때문이다. 믿기 어렵겠지만, 사실이다. 프로젝트가 점점 커지고, 복잡해지고, 유지보수까지 감안하면 그 비용의 차이는 점점 커진다. 

좀더 나아가 비대면 개발 방식을 재택 근무까지 확장하면 회사 입장에서는 거주지에 상관없이 개발자를 채용하는 이득이 있고, 꼭 하루 8시간 일하는 개발자를 채용할 필요도 없고, 개발자 채용이 훨씬 유연해진다. 또한 사무실 임대비용도 감소하여 많은 장점이 생긴다.

직원 입장에서도 개발 외의 시간을 덜 뺏기게 되어 업무 집중도가 높아지고, 감정 소모가 감소하는 장점이 있다. 전체적으로 개발 생산성도 향상된다. 하루 4시간 밖에 일하지 못하는 개발자에게도 취업의 기회가 생기고, 생활의 질도 올라갈 것이다. 

사회적으로는 회사들이 몰려있는 수도권의 집값도 떨어지는 효과도 생길 것이다. 회사, 직원, 사회 모두가 이익이 된다.

문제는 얼굴을 보지 않고 일을 할 수 있냐는 것이다. 게다가 일을 열심히 하고 있는지 믿을 수 있냐는 것이다.

이제부터 사례를 비교해보고 어떻게 해야 비대면 방식으로 소프트웨어를 개발할 수 있는지 알아보자.

먼저, 미국의 경우를 보자.

미국에서는 이미 약 20%의 개발자는 재택근무를 하고 있다.


미국에서는 이미 약 20%의 개발자는 재택근무를 하고 있다. 대부분의 회사에서 개발자로 입사를 하면 재택근무를 선택할 수 있는 옵션이 있다. 코로나19 이후 재택근무는 훨씬 더 증가하고 있다. 즉, 미국에서는 이미 비대면으로 개발하는 방식에 익숙해져 있고, 비대면 개발에 별 문제가 없다.

미국에는 비정규직 포함 1200명의 직원이 모두 재택근무를 하고 있는 소프트웨어 회사가 있다. 바로 GitLab이다. GitLab의 모든 프로세스는 온라인으로 진행할 수 있도록 되어 있고, 문서를 통해서 개발이 이루어진다. GitLab은 급속도로 성장하고 있다.

Facebook은 개발자가 입사한 첫날 버그를 고친다. 이렇게 고친 버그는 전세계 서비스 된다. 개발자가 입사를 하면 버그관리시스템에서 버그를 할당해주고, 개발자는 온라인으로 주어진 정보를 바탕으로 소스코드를 내려 받고, 수정 후, 온라인으로 코드리뷰를 받고 소스코드를 등록한다. 한 사무실에 있는 동료들의 얼굴을 볼 수 있지만, 얼굴을 보지 않아도 일하는 방식은 똑같다.

최근 실리콘밸리의 소프트웨어 회사들은 대대적인 재택근무를 선언하고 있다. Facebook은 향후 5~10년에 걸쳐 직원 절반이 영원히 원격근무를 할 것이라고 한다. 이로 인해서 실리콘밸리 집값도 떨어지고 있다고 한다.

하지만 국내의 회사들은 전면적인 재택근무는 엄두를 내지 못하고 있다. 특정 직군만 재택근무를 시행하거나 일주일에 며칠만 재택근무를 시도하곤 한다. 아예 비대면으로는 일을 하기 어려운 상황이다.

그럼 우리나라 회사의 사례를 살펴보자.

스펙 문서를 보고 개발자가 개발을 못한다.


A사는 공공 프로젝트를 위주로 사업하던 회사다. 공공 프로젝트에서 업무를 분석하는 것은 가장 중요한 일이다. 그래서 업무 분석가가 핵심이다. 업무 분석가가 소프트웨어 스펙을 작성해서 개발자에게 넘겨주면 문서를 보고 개발하는 것이 목표였지만, 실제는 업무 분석가가 개발 기간 내내 옆에서 기능을 설명해줘야 했다. 업무 분석가는 프로젝트가 끝날 때까지 프로젝트에 묶여서 다른 프로젝트를 수행할 수가 없다. 회사 입장에는 수주할 수 있는 프로젝트가 줄어 들기 때문에 손해가 아닐 수 없었다. 하지만, 몇 년을 노력해도 스펙 문서를 전달해서 개발자들이 스펙 문서를 보고 개발한다는 목표는 달성하지 못했다.

B사는 신입 개발자가 입사를 하면 사수를 정해주고 이거 저거 가르쳐줘야 하는 것이 많다. 신입개발자는 최소 한달은 되어서 실제 개발에 투입이 될 수 있다. 사수인 고참 개발자도 시간을 많이 빼앗기고, 신입개발자도 월급 값을 하려면 시간이 오래 걸린다. 개발자가 입사할 때마다 이런 일은 반복된다. 신입 개발자에게 문서를 전달해주고 알아서 개발을 하게 하고 싶지만, 고참 개발자는 이를 위해서 문서를 따로 만들 시간이 없다.

왜 대면 개발이 문제인가? 대면으로 밖에 개발을 못하면 진짜 문제인가?

대면 위주로 개발하면 초기에는 뭔가 더 효율적인 것 같지만, 효율은 점점 떨어진다. 시간이 흐를수록 더 많은 개발자가 필요하고 초기 개발자가 유지보수에 더 매달려야 하고, 업그레이드 할수록 개발 비용이 증가한다. 

비대면 개발은 시스템, 문서 위주로 개발이 진행되기 때문에 자연스럽게 기록이 남고 혼선이 줄어들며 유지보수 준비가 된다. 

위기가 곧 기회


일본의 수출규제가 우리 부품 산업이 자립도를 높였듯이 위기가 곧 기회가 될 수 있다. 어쩔 수 없이 바뀌어야 하겠지만, 한국인의 저력과 맞물려서 소프트웨어 개발 역량이 몇 단계 업그레이드 될지도 모른다. 그러기 위해서 방법을 알아야겠다.

비대면 소프트웨어 개발을 하기 위해서는 크게 3가지가 필요하다.

첫째, 비대면 개발을 위한 시스템, 툴이 준비되어야 한다.

작은 툴부터 시스템까지 10~20여가지의 시스템이 도입되어서 내재화되어야 한다. 많은 것 같지만 적응해서 사용하다 보면 하나하나 필수적인 것이고 이것들 없이는 개발을 못할 것 같은 생각이 들것이다. 여러 회사를 살펴본 필자의 경험에 의하면 비대면 개발 프로세스를 위한 시스템, 툴을 촘촘히 전부 도입하고 있는 회사는 드물다. 일부 시스템만 사용하고 있어서 프로세스 중간중간 비대면 프로세스가 끊어지는 경우가 많다. 필수 시스템 중 몇가지만 예로 들면 문서관리시스템, 지식관리시스템, 소스코드관리시스템, 이슈관리시스템, CI시스템, 코드리뷰시스템 등이다. 추후 하나씩 자세히 알아보려고 한다. 이렇게 비대면 프로세스가 끊어지면 지속적으로 비대면 개발을 할 수 없고, 중간중간 얼굴을 보고 일하지 않으면 안된다.

둘째, 문서작성 역량이다.

단순히 워드 문서 같은 것을 말하는 것은 아니다. 온라인 시스템을 사용하려면 모든 것을 다 적어야 한다. 말로 하는 커뮤니케이션보다 글로 적는 커뮤니케이션에 익숙해져야 하고, 문서를 통해서 의사를 전달하고 문서를 보고 개발할 수 있는 수준의 문서를 작성할 수 있어야 한다. 그렇다고 자세하게 적는 것이 능사는 아니다. 최소한으로 문서를 적는 것이 더 중요하다. 이런 역설적인 말을 이해해야 한다. 개발에 관련된 문서는 많다. 기획문서, 스펙문서, 백서, 설계문서, 테스트 관련 문서 등 여러 문서를 온라인 프로세스를 통해서 작성하고 리뷰하고 확정하고 변경 관리를 해야 한다. 

셋째, 개발 문화다.

그중 대표적인 것이 수평 문화다. 온라인으로 비대면 개발을 하면 업무가 수평적으로 진행된다. 프로젝트에서 자신의 역할이 존재할 뿐이고 수직 관계가 없어져야 한다. 그래야 제대로 개발이 된다. 온라인에서도 수직관계가 여전히 존재한다면 일이 잘 진행 안될 것이다. 각자 자신이 맡은 일을 전문적으로 처리하는 것이다. 연공서열, 장유유서, 상명하복 이런 것들이 점점 희박해지고, 전문성이 강조되는 문화로 바뀌어 나가야 한다. 얼굴 안보고 일하면 이런 문화가 바뀔 가능성이 더 높아진다.

코로나19는 우리에게만 닥친 것이 아니다. 전세계가 동일한 환경에 처했다. 전세계가 비대면 방식으로 업무를 바꾸고 있고, 우리가 조금이라도 더 빨리 적응해 나가야 한다. 승부는 2,3년 안에 나게 되었다. 여기서 뒤쳐지면 따라잡기 어렵다.

비대면 방식이 소프트웨어 개발은 이제 선택이 아니고 필수가 되어가고 있다. 오늘은 비대면 방식의 개발에 대해서 간단히 소개만 했는데, 앞으로 하나씩 자세히 소개를 할까 한다. 하루아침에 습득할 수 있는 것은 아니지만, 차근차근 알고 익혀 나가는 것이 가장 빠른 길 일 것이다. 

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



2020년 2월 2일 일요일

[Software Spec Series 5] 스펙을 제대로 작성하지 않으면

소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 “1:10:100 rule"이다. 성숙한 개발 문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고 작은 많은 소프트웨어 회사 임직원들은 그 의미를 모르거나 알고 있어도 단어의 의미로만 알고 있고 진정으로 깨우치고 있지는 못하다. 소프트웨어를 개발하면서 발생하는 많은 비효율과 문제들이 바로 여기서 출발하는 것이다.

그 1:10:100 rule을 설명한 그래프가 아래에 있다.

(스펙 1:10:100 규칙 그래프)

스펙을 작성할 때 요구사항을 바꾸면 “1"이라는 비용이 들지만 고객에게 전달된 다음에 바뀌면 수백배의 비용이 들어간다. 요구사항이든 설계든 한단계 뒤에서 고치게 될 경우 2~5배의 비용이 들어가서 단계를 거치고 시간이 흐를수록 수정 비용은 기하급수로 증가를 한다. 따라서 기획이 제대로 되어야 하고 분석 설계가 적절하게 잘되어야 한다. 한창 개발 중에 기획이 바뀌거나 요구사항이 바뀌면 그 수정 비용은 엄청나다는 것을 알아야 한다.

개발자들은 기획에서 정확한 요구사항을 주지 않는다거나 나중에 요구사항을 바꾼다고 불평이 많다. 불평은 하지만 그것을 현실로 받아들이고 스스로 이를 개선하려는 노력은 별로 하지 않는다. 오히려 상황이 그러니 분석, 설계를 제대로 하지 않고 대충 개발하다가 나중에 바꿔달라고 하면 또 대충 받아들여서 바꿔주고 이런 악순환을 반복하곤 한다.

기능에 따라서는 나중에 고쳐도 비용이 크지 않은 것도 있지만, 비용이 수백배 들어가는 것도 있다. 특히 아키텍처에 관련된 것이나, 비기능적인 요소는 나중에 수정할 경우 상상할 수 없는 비용이 들어간다.

이런 것을 극복하기 위해서 여러 방법론이 나오기도 하고 한때 Agile이 각광을 받았지만, 이런 방법론이나 기법으로는 이를 해결할 수는 없다. 정공법 외에는 방법이 없다. 기획을 제대로 하고 분석 설계를 효율적이고 적절하게 하면 된다. 또한 그 과정에서 모든 이해관계자가 책임을 지고 검토를 해서 문제가 없게 해야 하면 나중에 딴소리를 하거나 바꿔달라고 하면 안된다. 정말 중요한 변경 요청이 아니면 다음 버전으로 미루는 것이 좋은 전략이다.

share with abctech.software

2019년 12월 26일 목요일

[Software Spec Series 2] 소프트웨어 프로젝트 실패의 원인

우리 주변에서 실패한 소프트웨어 프로젝트를 보는 것은 어려운 일이 아니다. 프로젝트를 성공하는 방법을 배우기 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패하는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.
  • 약속된 일정 내에 제품 또는 서비스를 출시하지 못했다.
  • 소프트웨어가 요구되는 품질을 충족하지 못했다. (기능 요구사항, 성능, 안정성, 사용성, 확장성 등)
  • 프로젝트에 꼭 필요한 기술 개발에 실패했다. 
  • 아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
  • 프로젝트에 계획된 예산보다 많은 비용을 지출했다.
  • 프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.
          직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자.


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


          이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인은 “스펙”이다. 가장 많은 원인이 스펙과 관련이 있다. 또한 소프트웨어 버그의 절반 이상은 스펙으로부터 발생한다고 알려져 있다.

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

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

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

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

          좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 소프트웨어 프로젝트 성공은 어렵다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다. 꾸준히 투자하는 방법 외에 기가 막힌 방법은 없다.

          share with abctech.software

          2019년 12월 25일 수요일

          [Software Spec Series 1] 머릿말

          소프트웨어 프로젝트에서 가장 중요한 것은 스펙을 작성하는 일이다. 가장 어려운 것도 스펙을 작성하는 일이다.

          프레드릭 브룩스는 이렇게 말했다. "소프트웨어 개발에 있어서 가장 어려운 일은 개발 자체가 아니라, 무엇을 개발할지 결정하는 일이다." 이 말은 과거에도 유효했고, 현재도 유효하고, 미래에도 유효하다.

          소프트웨어 프로그래머는 인공지능으로 대체될 가능성이 매우 높은 직업이다. 하지만 소프트웨어 스펙을 작성하는 분석 아키텍트는 인공지능으로 대체될 가능성이 가장 낮은 직업 중 하나다. 아무리 인공지능이 발전을 해도 스펙을 대신 작성해주는 세상이 올 가능성은 거의 없다. 그래서 스펙을 작성하는 일은 어렵지만 더욱 가치가 있다.

          스펙을 잘 쓰는 방법을 정립해 놓은 것을 요구공학(Requirement engineering)이라고 한다.

          공학이라고 하면 왠지 이론적인 것으로 생각된다. 하지만 공학은 실전에 비롯되었다. 과학을 현실에 적용하면서 과학과 현실의 간극을 메꿔주는 것이 공학이며 현실에서 벌어진 문제를 해결하면서 공학은 발전을 해 나간다. 즉, 이론적인 뒷받침도 있지만 공학은 실전이 먼저다. 요구공학도 이론적인 연구가 많이 되어 있지만 실전을 기반으로 발전되어 왔다. 하지만 현대의 요구공학은 이론적인 연구도 상당히 많이 더해져서 내용이 상당히 방대해졌다.

          이런 방대한 요구공학 이론을 보고 왠만한 소프트웨어 회사에서 배우고 따라한 다는 것은 거의 불가능하다. 피아노 백과사전을 보고 피아노를 배우는 것과 비슷할 것이다. 아직 소프트웨어 공학이 내재화 되지 않은 소프트웨어 회사에서 요구공학 이론을 적용하는 것은 의미 없는 몸부림이다. 그렇게 한다면 오히려 주먹구구식 개발보다 효율이 떨어지는 것은 시간 문제다. 실제 우리나라의 많은 소프트웨어 회사들이 겪고 있는 문제다.

          요구공학 즉, 스펙을 잘 작성하는 방법은 가르칠 수는 있는데, 배울 수는 없다. 무슨 뚱딴지 같은 소리인가 할 것이다. 하지만 이를 다른 분야의 예를 들면 바로 이해가 된다. 피아노를 잘 치는 방법을 가르칠 수는 있어도 그렇게 배워서는 피아노를 잘 칠 수 없다. 골프를 잘 치는 방법을 가르칠 수는 있어도 그렇게 해서는 골프를 잘 칠 수 없다. 가르치는 것이 의미는 있지만 피아노를 잘 치고, 골프를 잘 치려면 훈련을 해야 한다. 1,2년이 아니고 수년 이상 훈련을 하면서 코칭을 해야 비로소 피아노를 잘 치고, 골프를 잘 칠 수 있다. 코딩을 배우는 것과는 매우 다르다.

          그래서 요구공학 책은 많아도, 책을 보고 배워서 스펙을 작성해도 실력이 잘 늘지 않는다. 특히나 이론에 아주 충실한 책들은 아무리 좋은 책이라고 하더라도 현실에 적용하기는 더욱 어렵다. 회사 경영진들은 대부분 매우 조급하다. 꾸준히 투자하고 훈련하면 10년 걸릴 일을 1,2년 안에 성과를 내려고 한다. 피아노 1,2년 안에 늘 수 있는 실력에 한계가 있듯이 스펙을 작성하는 것도 그렇게 빨리 성과가 나지는 않는다. 서두르다가는 오히려 역효과만 난다. 그래서 많은 회사에서 스펙 작성 역량 확보에 실패한다. 그리고 해봤더니 안되더라. 요구공학은 엉터리라고 한다. 피아노 1,2년 연습하고 쇼팽의 곡을 못 친다고 실망하는 것과 비슷하다.

          스펙을 잘 작성하기 위해서는 실전에 따른 노하우의 축적이 필요하다. 노하우 백과사전을 만들어서 봐도 배울 수는 없다. 노하우는 스스로 현실에서 익히는 것이다. 그래서 경험이 중요하다. 단, 잘못된 방법으로 시도한 경험으로는 좋은 노하우 축적이 안된다. 오히려 왜곡된 생각이 쌓인다. 그래서 좋은 코치가 필요하다. 코치와 같이 실전 프로젝트를 수행하면서 스펙을 직접 써보고, 피드백을 받아야 한다. 피아노, 골프 모두 같은 방식으로 배운다. 스펙을 작성하는데 있어서 일반적인 코치는 회사의 고참 개발자, 경력이 많은 분석 아키텍트다. 하지만 우리나라 소프트웨어 회사에서는 그런 역량이 있는 선배를 찾아보기 힘든 것이 현실이다. 그래서 코칭을 제대로 받을 수가 없다.

          스펙을 작성하는 기법만 알아서는 스펙을 잘 쓸 수 없다. 개발 문화, 관행, 습관, 프로세스, 원리, 원칙을 알고 접근해야 한다. 앞으로 시리즈 글에서 스펙을 잘 작성하는데 필요한 모든 분야를 다룰 것이다.

          운동은 원리를 몰라도 코치가 가르쳐주는 대로 무조건 반복 훈련을 해도 성과를 내고 경지에 오를 수도 있다. 하지만 소프트웨어 개발은 원리를 모르고 기계적으로 따라해서는 제대로 발전하기 어렵다. 오히려 엉뚱한 함정에 빠져서 고치기 힘든 나쁜 습관이 몸에 베일 수 있다. 그래서 원리를 아는 것도 배우 중요하다. 그래서 앞으로 원리를 이해하는데 도움이 되는 많은 얘기를 할 것이다.

          소프트웨어 개발은 “적절히”가 매우 중요하다. “적절히”를 제대로 이해하는데 10년, 20년 걸린다. 피아노, 골프도 마찬가지다. 처음부터 완벽하게 이해하려는 것은 욕심이다. 시행착오를 거치면서 원리를 하나씩 깨우칠 때 “적절히” 하는 노하우를 하나씩 터득할 수 있다. 이 시리즈를 통해서 노하우를 터득해 나가보자.

          share with abctech.software

          2018년 4월 20일 금요일

          프로세스가 개발 문화를 이기기 어려운 이유

          우리나라의 많은 기업들은 글로벌 수준의 소프트웨어 개발 역량 확보에 실패했다. 10년 전쯤부터는 막대한 자본을 투입해서 개발자 확보 및 소프트웨어 개발에 투자를 하더니 이제는 소프트웨어는 실패했다는 자성을 하고 있다. 돈과 사람을 아무리 투자해도 10년이라는 단기간(?) 내에는 글로벌 수준의 소프트웨어 개발 역량 확보는 쉽지 않다.

          많은 기업들이 소프트웨어 개발 역량 확보를 위해서 주로 선택한 방법은 세계적인 방법론과 프로세스의 도입, 직원들에 대한 교육이다. 글로벌 소프트웨어 회사들이 하는 방식과 비슷하게 프로세스를 따르고 문서를 만들고 개발 환경도 비슷하게 갖추었다. 카페 같은 환경도 만들어서 자유롭게 일할 수 있도록 한 회사도 있다. 하지만 그 결과 그럭저럭 소프트웨어 프로젝트의 결과는 나왔으나 소프트웨어 개발은 더 비효율적으로 바뀌었다. 이유는 무엇일까?

          감당할 수 없는 수준의 프로세스는 오히려 독이 된다. 10년이라는 짧은 시간에 아직 역량이나 문화가 성숙되지 않은 상황에서 도입한 과도한 프로세스는 소프트웨어를 효율적으로 개발하게 하기 보다는 프로세스가 주인이 되어서 효율성은 되려 떨어지게 되었다. 이런 과정에서 문제가 생기면 이를 해결하기 위해서 프로세스는 더욱 복잡해져만 갔다. 모든 회사가 그런 것은 아니지만 많은 회사가 걸어온 길이다.

          소프트웨어를 가장 효율적으로 개발하는 방법은 프로세스에 상관없이 가장 적절한 과정으로 그냥 개발하는 것이다. 그 적절한 과정이라는 것은 성숙된 개발 문화 속에서는 자연스럽게 선택이 된다. 하지만 회사들은 이런 애매모호한 방법을 선택할 수는 없다.  이런 방법은 이미 개발자들의 역량이 충분히 확보가 되고 성숙된 개발 문화를 갖췄을 때만 가능하다. 그래서 많은 회사들은 이런 애매하고 어려운 개발 문화 발전 보다는 명백하고 따라하기 쉬워 보이는 개발 프로세스 정교화에 집중해왔다. 그결과 큰 사고는 줄어들었지만 과거에 주먹구구식으로 개발을 할 때보다 오히려 개발 효율성은 훨씬 떨어졌다. 가끔은 프로세스의 구멍 때문에 큰 사고가 나기도 한다.

          프로세스를 아무리 잘 정해도 효율적인 개발 과정을 정의하기 어려운 이유는 뭘까? 아래 대화를 보자. 수십년간 소프트웨어 실전적으로 개발을 해온 전문가에게 질문을 하면 아래와 같이 답을 할 것이다.

          Q. 모든 소스코드는 코드리뷰를 다 해야 하나요?
          A. 아니요, 그때 그때 달라요.

          Q. 코드리뷰에 꼭 포함해야 하는 필수 리뷰어는 누구 인가요?
          A. 그때 그때 달라요.

          Q. 스펙은 꼭 작성해야 합니까?
          A. 그때 그때 달라요.

          Q. 스펙을 작성할 때 가장 중요한 부분은 어디 인가요?
          A. 그때 그때 달라요.

          Q. 설계서는 꼭 작성해야 하나요?
          A. 그때 그때 달라요.

          Q. 효율적으로 설계서를 작성하는 방법은 무엇인가요?
          A. 그때 그때 달라요?

          Q. 매번 경우마다 다른데 개발 프로세스는 어떻게 정하죠?
          A. 그래서 프로세스를 너무 자세히 정하면 안됩니다. 최소한으로 정하고 개발자들의 판단을 믿어야 합니다.

          Q. 대기업은 그래서 프로세스 테일러링을 통해서 프로젝트마다 적절히 프로세스를 간소화해서 산출물도 줄이는 등 개발 프로세스를 효율적으로 적용하려고 노력하고 있습니다.
          A. 이 또한 하다하다 안되니까 형식적으로 진행하는 겁니다. 심지어는 개발을 잘 모르는 사람들이 테일러링하기도 합니다.

          Q. 알아서 하라고 하면 과거처럼 스펙도 없고, 공유도 안하고 주먹구구식으로 하지 않을까요?
          A. 그렇기 때문에 역량과 문화가 중요합니다. 문화가 아무리 좋아도 역량이 안되면 공염불입니다.

          일반적으로 프로세스는 복잡할수록 손해다. 문제만 없다면 프로세스가 없는 것이 제일 좋다. 문제가 있기 때문에 최소한의 제약을 가하는 것이다. 개발 문화의 성숙도가 높을수록 프로세스는 간단하다. 

          하지만 왜 이렇게 프로세스에 목을 맬까? 프로세스 도입은 쉽고, 개발문화 변화는 어렵기 때문이다. 골프채를 바꾸는 것은 쉬워도, 몸에 완전히 베어버린 골프 스윙을 바꾸는 것은 엄청나게 어렵다. 한사람의 생각과 행동을 바꾸기도 어려운데 전직원을 바꾸는 것은 정말 어렵다.

          프로세스는 최소화로 정의하고 성숙된 개발문화를 만들어 가는데 집중하는 것이 좋다. 둘은 보완 관계이기도 하지만, 앙숙관계이기도 해서 프로세스를 너무 강조하는 환경에서는 개발문화를 발전시키기가 어렵다.

          개발 문화에는 정보/지식 공유, 스펙 작성, 수평적인 조직, 전문가주의, 경력 보장, 상호 리뷰, 자율, 문서 작성 등 수많은 것들이 있다. 일일이 나열할 수는 없지만 일하는 속에서 이런 것들이 구성원들에게 자연스럽게 스며들도록 제도, 프로세스를 정의하고 독하게 추진을 해야 한다. 그래야 개발문화가 조금씩 바뀌어 나간다.


          이렇게 개발문화와 프로세스가 잘 조화를 이룰 때 소프트웨어 개발 역량이 세계적인 수준이 될 수 있다. 개발에 문제가 있다고 복잡한 프로세스를 도입해서 단기적으로 해결해보려는 시도는 장기적으로는 대부분 실패할 것이다. 

          이글은 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]
          [사진=Pixabay]
          그럼에도 불구하고 우리나라에서는 아키텍트라는 단어에 많이 집착한다. 소프트웨어업계에 아키텍트가 부족하여 발전이 안된다고 하기도 하고, 너도나도 회사에서 아키텍트라는 타이틀을 만들어 남발하기도 한다. 이렇게 아키텍트에 집착하는 것은 여전히 뛰어난 아키텍트가 많이 없어 그에 따른 갈증이 있기 때문으로 해석된다.
          이런 현상은 비단 소프트웨어 업계만의 문제는 아니다. 우리나라는 여러 산업분야에서 선진국을 빠르게 따라 잡으면서 실행력은 앞서기도 한다. 하지만 시스템 설계 능력은 겉모습을 보고 따라잡을 수 있는 것이 아니다. 선배에서 후배로 여러 세대를 거치면서 축적된 경험과 노하우가 전승되어 와야 하는 것이라서 우리끼리 독학으로 따라잡을 수는 없는 것이 당연하다.
          ■ 비즈니스 이해해야 좋은 아키텍처 나와
          소프트웨어 아키텍트는 어떤 사람을 말하는 것인가?
          한마디로 정의하면 소프트웨어 시스템을 설계하는 사람이다. 소프트웨어 시스템을 작은 모듈까지 축소하면 대부분의 개발자들은 아키텍트이기도 하지만 이슈가 되는 것은 상당히 커다란 시스템을 설계할 수 있는 능력을 가진 사람이 아키텍트다.
          누구나 하기도 하고 누구나 잘할 수 있을 것 같은 소프트웨어 분석 설계가 어려운 이유는 아키텍트는 일반 개발자 또는 프로그래머와는 완전히 다른 역량을 요구하기 때문이다.
          좋은 아키텍처는 비즈니스에 대한 이해에서 나온다. 대부분은 현재뿐만 아니라 미래 비즈니스 전략도 잘 알아야 한다. 또한 기술적으로도 상당 수준이어야 한다. 업무에 빠삭한 도메인전문가(업무전문가)와는 또 다르다. 문서로 소프트웨어 스펙이나 설계서를 작성할 수 있어야 하고 다른 사람이 이 문서를 보고 소프트웨어를 개발 할 수 있어야 한다. 의외로 이런 역량을 고루 갖추고 있는 뛰어난 소프트웨어 아키텍트는 흔하지 않다.
          우리나라는 도메인 전문가가 나름 그 역할을 하고 있다. 업무는 모르는 것이 없이 잘 알지만 분석, 설계 역량은 떨어지고 문서로 스펙과 설계를 작성해서 다른 사람에게 일을 시키지 못하기 때문에 옆에 붙어서 설명을 너무 많이 해줘야 하고, 개발 도중 문제가 생길 때마다 해박한 업무 지식으로 문제를 해결해 나간다. 물론 개발 효율성은 떨어질 수 밖에서 없다.
          왜 소프트웨어 회사에 뛰어난 아키텍트가 필요한가?
          개발자 3~4명이 진행하는 소규모 프로젝트는 어떻게 개발을 하든지 소프트웨어 개발이 가능하다. 각 개발자들의 프로그래밍 역량이 뛰어나다면 매우 훌륭한 소프트웨어도 만들 수 있다. 하지만 규모가 점점 커지면 개별 프로그래머들의 역량이 뛰어나다고 성공적으로 소프트웨어를 만들기는 어렵다.
          개발 복잡도는 소프트웨어 규모에 기하급수로 비례해서 복잡해진다. 또한, 어찌어찌 소프트웨어 개발에 성공을 했다고 하더라도 몇 년 안에 더 큰 문제가 나타난다.
          설계가 제대로 되지 않은 소프트웨어는 업그레이드를 할수록 아키텍처가 복잡해지고 곧 유지보수가 새로 개발하는 것보다 어려운 시점이 오게 된다. 물론 회사에 뛰어난 아키텍트가 있는 경우에도 프로젝트
          일정이나 복잡한 프로세스에 밀려서 아키텍처를 소홀히 하곤 한다. 그 대가는 미래에 꼭 몇배로 치르게 되어 있다.
          ■ "국내엔 축적된 노하우 계승해줄 선배들 부족"
          그럼, 왜 우리나라에는 소프트웨어 아키텍트가 부족한가?
          빨리 빨리 개발 문화부터 상명하복 조직 문화 등 간접적인 원인도 너무나 많지만 가장 큰 원인은 축적된 아키텍처링 노하우를 계승 시켜줄 선배들이 부족하기 때문이다. 그러다 보니 개발 기술은 발달을 하는데 커다란 소프트웨어 시스템을 설계해서 수십, 수백명이 체계적으로 일을 나눠서 문서를 보고 개발을 하는 경험을 해볼 환경이 거의 없다.
          소프트웨어 설계에 관련된 좋은 책은 많지만 골프 책이 아무리 많다고 골프 코치가 없으면 소용이 없다. 프로그래밍은 코치가 없어도 책을 보고 배울 수 있는 분야다. 하지만 분석과 설계는 코치 없이 배우는 것이 불가능하다. 또한, 몇 개월 가지고는 부족하다. 수년간 같이 일하면서 노하우를 전승 받아야 한다.
          아키텍트를 양성하기 위해서 회사들은 어떤 노력들을 하고 있는가?
          대학에서 요구공학이나 소프트웨어 아키텍처 디자인 관련된 강좌 코스에 직원들을 보내기도 하고, 강사를 초빙해서 강의를 듣기도 한다. 물론 다 도움이 되는 일이지만 기대만큼 빠른 성과가 나지는 않는다. 시험을 통해서 아키텍트 양성 후보를 선발하기도 한다. 알고리즘 시험을 보기도 하는데 그런 방법은 고참 개발자는 아키텍트 후보가 된다는 이상한 공식이 성립하기도 한다.
          이렇게 자생적으로 소프트웨어 아키텍트를 양성하기 위해서 피나는 노력을 하지만 기대만큼 단기간에 성과가 나고 있지 않다. 물론
          수십년 동안 노력을 한다면 분명히 성과가 있겠지만, 수십년을 기다릴 만큼 인내심을 가진 회사는 거의 없다. 결국 제도와 프로세스로 강제화를 하지만 이 문제는 그렇게 해결이 되지 않는다. 오히려 방해가 된다.
          그럼 아키텍트는 어떻게 양성해야 하는가?
          교육도 좋고 뛰어난 아키텍트를 영입하는 것도 좋은 방법이다. 하지만 가장 좋은 것은 좋은 관행들을 지속적으로 유지하는 것이다.

          ■ 아키텍트를 양성하는 세 가지 방법
          첫째, 소프트웨어를 개발할 때 분석, 설계를 제대로 해서 진행하는 것이다. 물론 문서로 제대로 작성하고 서로 리뷰하고 진행해야 한다. 이런 경험들이 축적되어야 한다. 급하다고 빨리 코딩부터 시작하는 경우가 있는데 그러면 프로젝트는 더 오래 걸리고 노하우가 축적되지 않는다. 물론 학습비용이 필요하기 때문에 처음에는 코딩부터 빨리 시작하는 것이 더 빨리 개발하는 방법일 수도 있다. 하지만 시간이 흐를수록 프로젝트는 더 오래 걸릴 것이다.
          둘째, 아키텍트 그룹을 운영하는 것이다. 보통은 가상 조직으로서 Technical Steering Committee나 Architect Group과 같은 이름을 가진다. 회사의 중요한 기술적인 이슈를 논의하고 결정하는 위원회이며 분석, 설계 문서를 집중적으로 리뷰하기도 한다. 아키텍트 후보로 선발된 인원은 이 조직에 참여하여 수년간의 훈련을 받으면 자연스럽게 아키텍트로 성장하게 된다.
          셋째, 아키텍트 후보를 선발하는 것이다. 앞으로 아키텍트로 성장할 가능성이 높은 개발자를 후보로 선발하여 수년간 훈련을 시켜야 한다. 물론, 아키텍트는 우수하고 일반 프로그래머는 우수하지 않다는 것이 아니다. 성향이 다를 뿐이다. 그리고 성향에 따라서 적합한 일이 좀 다를 뿐이다. 아키텍트로 성장하려면 다음과 같은 성향이나 소질이 있어야 한다. 글을 잘 쓰고, 다른 사람의 얘기를 잘 들어주고, 창의력이 좋고, 분석적으로 사고를 하고, 정보를 잘 조직화하고, 꼼꼼하며, 논리적인 사고를 하고, 문제의 핵심을 잘 찾고, 인내심이 좋아야 한다. 이를 모두 만족하는 사람은 없지만 몇가지가 일치하면 후보로 선발하여 키워야 한다.
          막상 얘기를 해보면 회사에 꼭 필요한 아키텍트를 키우는 데는 기가 막힌 방법이 없다. 골프를 잘 배워서 잘 치는데 기가 막힌 방법이 없는 것과 같다. 물론 잘못 배워서 잘못치는 방법은 부지기수로 많다. 좋은 환경에서 뛰어난 선배들이 좋은 관행을 유지하며 꾸준히 후배들을 가르쳐 주는 것이 가장 보편적인 방법이다. 이렇게 실무를 통해서 배우는 것이 학교에서 수업을 배우는 것보다 몇십배 더 많은 것을 배울 수 있다.
          조급하다고 되는 것도 아니고, 프로세스로 강제화 한다고 되는 것도 아니다. 뛰어난 소프트웨어 아키텍트를 여러 명 보유하는 것은 회사의 미래를 결정짓는 결정적인 요소이기 때문에 무시할 수도 없다. 꾸준한 투자를 해야 한다.

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