허울뿐인 소프트웨어 개발자 경력 보장

과거 필자가 근무했던 회사에서는 “백발을 휘날리며 개발을 할 수 있는 개발자”를 공개 채용한 적이 있다. 그 당시 수많은 경력직 개발자들이 지원을 했고 개발자로서 경력을 보장받고자 하는 열망을 충분히 알 수 있었다. 필자의 회사는 Technical career path를 확실하게 보장을 하고 있었다. 따라서 관리를 하지 않고 개발자로서 꾸준히 성장할 수 있고 그렇게 성장할 수 있도록 기업 문화와 제도가 뒷받침이 되어 있었다. 또한 대우도 관리자에 절대 뒤지지 않았다.

하지만 필자가 컨설팅을 시작한 이후 접한 수많은 회사들 중에서 제대로 개발자 경력을 보장해주는 곳은 없었다. 가장 큰 이유는 경영자의 이해 부족을 꼽을 수 있다. 개발자 경력 보장에 대한 각 기업들의 현황을 먼저 살펴보면 해결책도 보일 것이다.

우선 대기업 쪽을 살펴보자.

성공한 국내 유수의 대기업들은 HR에 대해서 많은 투자가 이루어지고 있다. 따라서 Career path에 대한 명확한 정책이 존재한다. 하지만 그 속을 들여다보면 문제가 매우 많다.

문제 사례 중 가장 흔한 것이 가장 뛰어난 고참 개발자가 관리자가 될 수 밖에 없는 상황이다. 그냥 오래 개발하다 보면 팀장, 부서장, 본부장이 되어서 조직을 관리하게 되는 것이다.

몇몇 기업은 개발자들이 관리에서 벗어나 꾸준히 개발자로 일할 수 있도록 하고 있지만, 이 또한 문제가 많다. 우선 회사에서 그렇게 개발자로서 성장하여 최고 개발자 위치까지 이른 사례를 찾아보기 어렵기 때문에 개발자들이 따를 Role model이 없다. 따라서 개발자들 스스로도 성장 단계별로 어떤 일을 해야 하는지 알지 못하고 우왕좌왕 하게 된다.

대기업 A사는 개발자의 직군에 Architect라는 직군을 만들고 이를 10여개로 세분화하고 각 직군마다의 R&R을 정하고 있다. Data Architect, System Architect, Application Architect 등 여러가지가 있다. 하지만 R&R이 소프트웨어 개발 현실과는 거리가 멀고 Role도 명확하지 않다. 결국 타이틀에 불과하고 일하는 방식은 주먹구구 방식과 큰 차이가 없다.

소프트웨어를 잘 모르는 HR 전문가나 관리자들이 만든 개발자 Career path는 현실성이 떨어져서 실제 적용이 잘 안된다.

개발자로 꾸준히 일을 하려고 해도 조직의 문화상 너무 많은 보고서 작성, 보고, 회의를 해야 하는 경우도 많다. 개발 일은 장시간 집중을 해서 성과를 낼 수 있는 일이라서 중간에 다른 일이 자주 끼어들면 제대로 일하기 어렵다. 보고를 이렇게 많이 해야 하고 보고서를 만드는데 오랜 시간을 투자해야 하는 이유는 기업의 기반시스템이 부족하여 경영자가 수시로 보고를 받아야 현황을 파악할 수 있기 때문이다.

또한 보고서의 내용보다 형식에 민감한 경영자가 많고 편하게 앉아서 자신이 필요할 때마다 아랫사람이 자세히 보고를 해주기를 원하는 경영자가 많다. 따라서 개발자라고 하더라도 이런 잡무가 많아질 수 밖에 없다.

이런 귀찮은 일들을 대신해줄 중간 관리자를 채용해도 전문성이 부족한 관리자들은 결국 일들을 개발자에게 토스하는데 그친다. 또한 중간 관리자가 일을 더 많이 만들어서 시키기 때문에 더 귀찮게 하는 경우도 있다.

대기업 개발자들과 인터뷰를 해보면 개발을 좋아해서 개발을 꾸준히 하고 싶은 개발자들도 개발 환경의 열악함, 개발자의 낮은 대우 등으로 인해서 현실적으로 관리자의 경력을 택하고 있었다.

중소기업도 크게 다르지는 않다. 개발을 아주 잘 이해하고 있는 경영자가 있는 회사가 아니라면 중소기업도 개발자 경력이 잘 보장 되지 않는다. 중소기업은 인력이 부족하다 보니 직종을 상세히 구분하지 못하고 개발자에게 팀장 또는 PM(Project Manager)일을 맡기게 된다. 그러다 보면 자연스럽게 개발과 관리의 경계가 무너지게 된다.

많은 회사들이 개발자 경력을 보장해야 한다는 사실 자체는 인지를 하고 있는 것 같다. 하지만 이를 문자 그대로 받아 들일 뿐, 진정으로 깨닫고 있지는 않은 것 같다. 현재의 기업문화와 개발 환경을 그대로 두고 개발자 경력 보장이 되기는 어렵다.

개발에 꼭 필요한 기반시스템들이 잘 구축되어서 제대로 쓰여야 한다. 그래서 투명한 개발 환경이 되어야 불필요한 보고와 회의가 대폭 줄어들게 된다. 경영자들도 매번 보고를 받지 말고 대부분의 정보는 시스템을 통해서 확인 할 수 있어야 한다. 기업 문화도 전문성을 존중하는 방향으로 바뀌어야 한다. 또한 관리자는 윗사람이라 상명하복 관계라는 생각도 바뀌어야 한다. 관리면 관리, 개발이면 개발 각각 전문성 있는 일을 하는 것일 뿐이다.

물론 개발자도 바뀌어야 하지만 경영자와 기업이 먼저 바뀌어야 할 것이다. 그래야 개발자 경력 보장이 제대로 정착이 될 수 있을 것이다.

이글은 Tech it!에 기고한 글입니다.

옛날에는 개발을 더 잘했는데

우리나라 많은 회사들은 소규모일 때 상당히 개발을 잘 하는 것처럼 보인다. 짧은 기간에 꽤 멋진 Software를 뚝딱 뚝딱 잘 만들어 낸다. 이러한 제품이 시장에서 통해서 회사가 성장을 하게 되면 그 이후로 이상하게 개발이 점점 더 어려워지게 된다.

옛날에는 고참 두 명이 이정도의 Software를 6개월만에 이렇게 잘 만들어 냈는데, 지금은 팀원이 10명이나 되고 프로젝트 기간도 과거보다 더 줬는데, 제품의 버그는 더 많고, 제품도 옛날보다 형편 없어 보인다고 한다. 점점 개발이 더 어려워지는 이유는 무엇일까?

두번째 시스템을 만드는 것은 첫번째 시스템을 만드는 것보다 훨씬 힘들다.

두번째 시스템은 첫번째 시스템을 유지보수 하면서 만들어야 한다. 첫번째 시스템에 버그가 많거나 커스티마이징 요구가 많아서 소스코드 브랜치라도 몇 개 존재하면 유지보수에 많은 노력이 들어가서 두번째 시스템에 많은 노력을 들이기 어려워 진다.

또한 두번째 시스템은 첫번째 시스템과 호환성을 고려해야 한다.

두번째 시스템은 첫번째 시스템을 사용하던 고객들의 수많은 요구를 수용해야 한다. 첫번째 시스템은 간단 명료한 기능의 매력으로 인해서 많은 사용자들이 사용을 했지만, 이를 사용하던 사용자들은 계속 요구사항을 요구하게 되고 이러한 요구사항을 적절히 조절하여 수용하는 것이 쉬운 일이 아니다.

두번째 시스템 개발에는 많은 개발자가 투입되고 특히 초급 개발자가 많이 투입되곤 한다. 소수의 개발자끼리 개발을 할 때는 커뮤니케이션 문제가 별로 발생하지 않았는데, 개발자 인원이 많아지면 기존의 주먹구구 방식으로 똑같이 개발을 하면 문제가 발생하지 않을 수 없다. 초급 개발자들은 자기 역할을 제대로 못하는 것 같고, 일이 효과적으로 분배가 되지 않아서 결국 소수의 고참 개발자들이 대부분의 개발을 하는 결과를 초래하기도 한다.

두번째 시스템은 아키텍쳐를 전면 개편하기도 한다. 첫번째 시스템을 개발해 놓고 계속 유지보수를 하면서 사용자의 요구사항을 하나씩 추가해 나가기 시작하면 기존의 아키텍쳐로는 한계라고 불평을 자주 하게 된다. 특히, 첫번째 시스템을 개발했던 개발자들이 퇴사한 상태라면 더욱 더 첫번째 시스템을 비난한다. 그러면서 두번째 시스템에는 완전히 새로운 아키텍쳐를 적용하곤 하는데, 그동안 엄청나게 많은 노력을 들인 첫번째 시스템을 버리고 기능도 몇 배로 많아진 두번째 시스템에 완전히 새로운 아키텍쳐를 적용하면 첫번째 시스템이 시장에서 안정화되면서 겪었던 시간과 노력의 몇 배를 다시 투입해야 한다. 이런 경우 프로젝트가 지연되기 일쑤이고, 출시 후에도 많은 버그와 고객의 불평으로 상당기간 고생을 하게 된다.

그럼, 어떻게 해야 과거처럼 개발을 착착 해낼 수 있을까요?

조직이 커졌다면 당연히 시스템과 프로세스가 바뀌어야 한다. 과거에 소수 인원이 개발할 때는 주먹구구식으로 개발을 했어도 문제가 없는 것처럼 보이지만, 사실은 문제가 똑같이 있었는데, 워낙 인원이 적으니 서로 의견을 활발하게 주고 받으면서 문제를 해결해 온 것이다. 인원이 조금만 늘어도 이런 행운은 기대할 수 없다. 조직에 걸맞는 시스템, 프로세스를 적용해서 체계적으로 개발을 해야 한다.

첫번째 시스템도 이런 과정을 거쳐서 체계적으로 개발이 되었다면, 두번째 시스템 개발자들에게 비난을 덜 들을 수 있었을 것이다. 두번째 시스템 개발자들이 완전 새로 개발하려는 이유 중 하나가 첫번째 시스템에 대한 문서가 쓸만한 것이 없고, 아키텍처가 뒤죽박죽이라서 개선을 못하고 버리려고 하는 것이다.

회사가 켜졌을 때 문제 해결 차원에서 시스템과 프로세스를 갖출 것이 아니라, 1,2명이 회사를 시작하더라도 체계적으로 개발하는 것이 가장 좋은 방법이다.

이미 첫번째 시스템은 점점 뒤죽박죽이 되어가고 조직은 엉망이라면 시스템과 프로세스를 갖추는 일이 먼저 필요하다.

문서 작성 시 가장 중요한 것은 "이것"

소프트웨어를 체계적으로 개발해 보겠다고 맘을 먹으면 가장 먼저 하는 것이 "문서작성"이다.

문서의 개수와 종류와 상관없이 문서작성 시 가장 중요한 것은 무엇일까?

사람마다 다르게 생각하겠지만, 내가 생각하기에 가장 중요한 것은 "눈높이 맞추기"이다.

문서의 "눈높이 맞추기"란 의외로 매우 어렵다.

첫째, 문서의 독자가 누구인지 파악해야 한다.

소프트웨어를 개발할 때 만드는 대표적인 문서들은 MRD(기획), SRS(분석), SDS(설계) 를 들 수 있다.

각 문서마다 독자가 다르다. 심지어는 하나의 문서에서도 각 장마다 독자가 다르기 때문에 각 문서를 읽을 독자의 눈높이 맞추는 것이 쉽지는 않다.

둘째, 독자를 파악했다면 해당 독자에게 문서를 통해서 전달해야 할 내용과 독자가 프로젝트에서의 역할이 무엇인지 생각해야 한다. 그렇게 해서 독자에게 필요한 내용을 전달해야 한다. 

더 많은 내용 또는 부족한 내용을 전달할 경우 문서로서의 가치가 떨어진다.

셋째, 독자의 눈높이에 맞는 용어를 사용해야 한다. 경영자가 읽어야 문서라면 경영자가 이해하는 용어로 적어야 한다. 영업부서가 봐야 하는 부분이라면 영업이 이해할 수 없는 전문용어를 써서는 안된다.

더불어 문서를 작성할 때 문서의 서두에 문서의 독자와 읽는 방법에 대해서 설명을 해주는 것이 좋다. 특히 각 장마다 독자와 읽는 방법을 설명해주면 문서를 읽는 사람은 그 안내에서 따라서 가장 효율적으로 문서를 읽을 수 있다.

"옳은 문서"가 좋은 것이 아니고 "읽기 좋은 문서"가 좋은 것이다. 맞는 내용이라고 하더라도 어렵게 작성했거나, 너무 많이 작성했다면 비효율적인 문서 작성을 하고 있는 것이다.

"읽기 좋은 문서"를 작성하기 위한 노력은 꾸준히 계속되어야 한다. 한두해 걸릴 일이 아니기 때문이다.

Template과 Sample의 함정

소프트웨어 개발 프로세스나 방법론에 관심을 가지게 되면 Template과 Sample에 눈이 가게 된다.

소프트웨어를 체계적으로 개발해 보겠다는 생각을 하면 가장 먼저 "문서"를 만들어야 겠다는 생각을 하게 된다.

그러면서 자연스럽게 선진 Software 회사에서는 어떻게 문서를 만드는지 관심을 가지게 된다.

그래서 인터넷에서 이런 저런 Template을 찾아서 시도를 해보지만 대부분은 만족스러운 성과를 내지 못한다.

가끔은 세계적인 방법론에서 제시하는 수십가지 복잡한 Template를 가져다가 내용채우기를 시도하다 오히려 더 비효율적으로 변하기도 한다.

우리는 흔히 남이 잘 작성해 놓은 Sample이나 Template를 몇개 보면 그대로 따라할 수 있을 것으로 생각하는 경향이 있다. 

이 방법은 코딩에서는 꽤 효과가 있었다. 하지만 문서작성은 코드 작성보다는 복잡한 이슈들이 있다. 문서에는 문장하나하나가 글자 그대로 써있는 것보다 많은 과정과 노력을 들여서 탄생한 것이다. 따라서 결과물만 보고 그 정도 수준의 문서를 만들어 낼 수는 없다.

Template과 Sample을 보고 따라하는 것이 이를 보지 않은 것보다 못한 경우가 많다. 예를 따라하다보면 전체를 보지 못하고 흉내내는 것에 불과하게 된다.

따라서, Template과 Sample을 오히려 보지 않는 것이 좋고 보더라도 따라할 생각보다는 그 구성은 어떻게 되는지 분석하고 자신의 회사에 맞게 고민을 해보는 것이 좋다.

Template보다는 내용을 적는 방법과 리뷰하는 방법을 익히는 것이 더 중요하다. 제대로 배운다고 하더라도 Template의 진의를 파악하고 제대로 문서를 작성하는데는 꽤 오랜 시간이 필요하다.

Template과 Sample의 함정에 빠지지 말고 핵심이 무엇인지 파악하자.

한 SI회사의 프로세스에 대한 오해

필자는 업계의 여러 사람과 얘기할 기회가 많다.

최근에 한 대형 SI회사의 한 PM과 얘기를 한 적이 있는데 프로세스 상의 큰 문제가 있었고, 실제 프로젝트팀에서는 잘못된 프로세스로 인해서 어려움을 겪고 있었다.

SI회사의 오랜 바람 중의 하나가 "공정분리"이다. 즉, 분석/설계/구현을 분리해서 프로젝트를 진행하는 것이다.

"공정분리"가 되지 않은 상태에서는 분석/설계/구현이 뒤엉켜서 개발을 진행한다.

"공정분리"는 분석을 잘해서 설계자에게 넘겨주면, 설계자는 설계를 잘해서 개발자에게 넘겨주고 개발자들은 설계서 그대로 코딩만 하면 되도록 하려는 것이다.

최근 해외 프로젝트가 증가하면서 분석/설계/구현을 뒤엉켜서 진행할 경우 코딩하는 개발자까지 해외 파견을 해야 한다. 그래서 공정분리는 점점 필수가 되었다.

그래서 진행한 것이 해외에서 "분석/설계"를 잘 해서 넘겨주면 국내에서는 개발자들은 그대로 "구현"만 하면 되도록 하는 프로세스를 만든 것이다.

실제로 이 프로세스는 잘 작동하지 않고 있다고 한다. 그동안 해오던 방법과 역량이 분석/설계를 해도 "구현"은 이와 상관없이 알아서 진행하고 모르면 분석가에게 물어가면서 코딩하던 수준이었다. 이런 상황에서 이 프로세스가 잘 작동할리가 만무하다.

이렇게 공정을 분리하려면 "분석/설계" vs "구현" 보다는 "분석" vs "설계/구현"이 더 낫다.

설계가 구현에 좀더 가깝고, 잘된 분석서를 가지고 충분히 "설계/구현"을 할 수 있기 때문이다.

여기서 또 오해가 있는 것이 설계를 잘해서 넘겨주면 그대로 코딩만 하면 될 줄 아는 것이다. 현실에서는 이렇게 잘 진행되지 않는다. 이렇게 하기 위해서는 설계를 너무 자세히 적어야 하고 실제 구현시 많은 문제를 발견하게 된다.

더 좋은 방법은 설계는 꼭 필요한 만큼만하고 구현에 적당한 자유도를 주는 것이다. 

이렇게 제대로 "공정분리"를 하기 위해서 대전제가 하나 있다. 

바로 "분석"역량이 뛰어나야 한다는 것이다. 뛰어난 분석가를 많이 보유하고 있어야 한다.

현재의 분석역량은 기껏해야 "기능"분석과 약간의 "비기능"을 분석하는데 그치고 있다. 분석이 무엇인지 짧은 글에 일일이 설명하기는 어렵지만 분석은 이보다 훨씬 크고 어려운 일이다. 비즈니스전략도 포함해야 하고, 설계도 일부 포함한다. 

필자의 생각으로는 이 SI회사는 당분간 프로세스의 시행착오를 좀더 겪을 것으로 생각된다. 잘못된 프로세스를 바로 잡는데 시간이 걸릴 것이고, 분석역량을 끌어 올리는 일에 시간이 좀더 걸릴 것이다.

시행착오를 겪는 시간은 짧을수록 좋다.

무늬만 개발자

우리나라에서 소프트웨어를 개발한지 10년이 넘은 개발자 중에서 진짜 개발자는 생각보다 적다. 15년쯤 지나면 자신은 스스로를 개발자라고 생각할지 몰라도 진짜 개발자인 경우는 급격히 줄어든다. 대부분은 개발과 관리의 경계에서 애매한 포지셔닝을 하다가 다시는 개발로 돌아오지 못하곤 한다.

그럼에도 자신은 개발자라고 착각을 하는 경우가 많다. 또는 자신을 Architect라고 우기기도 한다.

선임급 개발자를 채용하기 위해서 인터뷰를 하면 이런 "개발자가 아닌 무늬만 개발자"를 자주 볼 수 있다.

매일 수많은 회의에 쫓겨 다니고, 온갖 보고서를 만들고, 수시로 경영진에게 보고하고, 팀원들 관리하고 평가하느라고 시간을 다 보내면서, 스스로는 개발에 관해서 아는 것은 많다고 생각해서 개발할 때마다 간섭하고 스스로 뛰어난 Architect라고 생각한다.

이런 사람들은 개발을 좀 안다고 해도 절대로 개발자가 아니다. 개발과 관리의 차이에 대한 개념도 희미한 상태이다. 대부분은 개발자로 다시 돌아갈 수 없는 상태이다.

절대로 "개발"과 "관리" 둘 다 잘할 수는 없다.

우리나라 대부분의 기업에서 본부장, 부문장, 부서장쯤 되면 이러한 상태에 이르게 된다.  그래도 팀장급에서는 개발자의 모습을 아직도 간직하고 있는 경우가 종종 있다.

하지만 팀장급 이상으로 올라가게 되면 개발자이고 싶은 관리자가 되게 된다. 물론 외형적으로도 완전히 관리자를 선언한 사람도 있겠지만, 여전히 개발자이고 싶은 사람들도 매우 많다.

이렇게 되는 결정적인 이유는 경영자의 개발조직 관리에 대한 오해에서 비롯된다. 경영자는 개발조직을 관리하는 관리자는 개발을 매우 잘 알아야 하기 때문에 가장 뛰어난 개발자들이 관리를 하는 것이 옳다고 생각한다. 그래서 경험 많은 선임 개발자들에게 본부장, 부문장, 부서장을 맡기곤 한다.

개발조직을 관리하는 관리자는 개발에 대해서 개발자만큼 잘 알 필요가 없다. 개발자가 개발에 대해서 아는 정도와 관리자가 알아야 하는 정도는 엄청나게 다르다. 그런데 경영자는 이 둘을 같은 것으로 착각하곤 한다.

개발을 잘하는 개발자는 관리는 전혀 하지 않고 개발에 몰두할 때 가장 높은 가치를 창출한다. 경영자의 착각 속에 개발자는 점점 잘 하지도 못하는 관리 일에 치중하게 된다. 자연스럽게 회사는 개발 파워를 잃게 된다. 그럼 남는 것은 정치적인 경쟁밖에 없게 된다. 불쌍한 개발자들이다.

이렇게 관리자화 된 개발자들은 이직도 곤란하게 된다. 동일한 분야가 아니라면 이직을 해도 회사에 도움이 별로 안된다. 다른 분야로 이직을 한다면 관리 능력이 중요한데 사실 관리는 전문 관리자보다 훨씬 못하기 때문이다. 이미 전문 개발자는 아니기 때문에 다른 분야에서 개발자로서 활약하기도 어렵다. 정말 어중간한 위치기 된다.

결국 그 회사에서 관리자의 길을 걷거나 선택할 옵션이 별로 없게 된다.

물론 개발자 본인이 스스로 이런 선택을 하지 않았지만 결국 이런 결과에 이르는 것이 우리나라 개발자들의 안타까운 현실이다.

개발자가 원하고 실력이 된다면 은퇴할 때까지 개발자의 경력이 보장되는 외국의 상황은 부러울 따름이다.

2008/12/03 - [개발조직] - 우리나라 소프트웨어 회사에는 Technical career path가 없다.

주변의 환경을 무시하고 스스로 개발자로 계속 살아남는 다면 대단한 결심이 필요할 것이다.

하지만 결국 이런 개발자들이 언젠가는 대우를 받을 수 있을 것이다. (당장은 글쎄 …)

그런 환경을 만들고 싶다.

이글은 Tech it!에 기고한 글입니다.

공유와 강제

소프트웨어 회사에서 꼭 필요한 개발문화 한가지를 꼽으라면 주저없이 "공유" 문화를 꼽는다.

"공유"의 문화야 말로 소프트웨어 회사를 가장 효율적으로 만들고 프로젝트를 효과적으로 진행할 수 있도록 하며 개발자들의 역량을 향상시키는 결정적인 문화이다.

"공유"의 문화가 잘 정착된 회사에서는 자연스럽게 문서화를 하며 시스템에 기록을 하고 소스코드에 주석을 남기고 필요한 리뷰를 진행한다.

하지만 공유의 문화가 부족한 회사에서는 자발적으로 공유의 활동이 잘 이루어지지 않는다.

물론 공유의 문화가 부족한 곳에서도 선도적인 개발자들이 공유의 문화를 정착하기 위해서 노력하고 있지만 역부족인 경우가 많다.

그 이유는 다른 개발자들의 협조를 이끌어내기가 어렵기 때문이다.

모든 사람이 다 공유를 하고 있는 상황이 아니라면 공유하는 사람만 손해를 보게 된다.

공유를 위해서 시간과 노력을 조금이라도 더 들였다. 하지만 공유를 하지 않는 사람들은 다른 사람이 공유한 결실은 얻으면서 자신의 것은 공유를 하지 않는다.

바빠서 그러기도 하고,

아직 습관이 안되서 그렇기도 하고,

귀찮아서 그러기도 하고,

공유하면 손해라고 생각하는 경우도 있다.

공유의 문화가 팽배한 회사는 서로 공유하는 것이 서로 이익이라고 몸으로 느끼고 있어서 자발적으로 자연스럽게 공유를 한다.

그럼 어떻게 공유의 문화를 정착할 수 있을까?

공유의 문화가 정착되기 전에는 회사의 규칙으로 강제화 해야 한다.

물론 너무 심하게 강제를 하면 반발하여 실패하기 쉽다.

너무 목표를 높게 잡아도 대부분 실패한다.

장기적인 계획을 하지고 단계적으로 시행해 나가야 한다.

첫번째가 이슈(버그)관리시스템을 적극적으로 사용하는 것이다. 모든 이슈와 버그는 시스템으로 모으고 최대한 메일과 전화를 줄이는 것이 그 시작이다.

두번째는 스펙을 작성하는 것이다. 스펙을 처음부터 제대로 쓰기는 어렵지만, 일단 프로젝트를 시작할 때 스펙문서를 작성하는 것을 규칙으로 두고 써보는 것이 좋다. 차츰 나아질 것이다.

세번쨰는 스펙을 리뷰하는 것이다. 스펙을 적고 리뷰를 해보면 그동안 얼마나 서로 모르고 프로젝트를 했다는 것이 조금씩 드러날 것이다.

이렇게 단계적으로 공유를 위한 제도를 강제로 적용하면 어느새 공유가 당연한 것으로 받아들여지는 때가 올것이다.