Ting 이네 Software 이야기

* 서로 잘 모르는 관계에서 어떤 토의를 하거나, 요구사항 등을 받아들일 때, - 예를 들면, 해외 지사에서, 업무에 불편한 점이 없는지, 도와줄 일은 없는 지 등을 조사할 경우 - 는 반드시 아래의 사항들을 먼저 언급하고 시작해야, 서로간 잘못된 의사소통에 따른 비용을 최소화 할 수 있다.

- 이번 토의/회의 의 명확한 목적

ex: 제안을 받아 들여 달라, xxx를 해 달라 등등

- (제안/요구 를 듣는 입장의 경우) 나의 R&R, 할 수 있는 일과 한계 등.

* Software 업계에서 자주 나오는 이야기 중 "Software중에 '보안'을 이야기할 정도로 정말 가치있는 부분은 얼마 되지 않는다"라는 말이 있다. 수많은 좋은 Opensource software가 넘쳐나는데, 회사의 software중 보안이라는 이름으로 권한을 정밀하게 할 가치가 있는 부분은 얼마나 있을까? 너무 넓은 범위, 정밀한 permission체계는 실무자들에게 쓸데없는 Overhead 및 불편함을 만들 가능성이 굉장히 높다.

* 내가 그 사람의 일(작업)을 control할 수 있는 위치가 아니라면, 가능하면, feedback은 긍정적으로 하자.

ex)

Proposal : '이런 이런' 아이디어가 있고, 이렇게 하면 '이런 이런'게 좋아집니다. 어떤가요?

+ 내가 그 사람의 상관(관리자)라면 : 좋으면 -> OK, 나쁘면 -> NO. 만약 idea가 받아 들이기 힘들다면 NO.. etc.

왜냐하면, 그 사람이 하는 일 및 시간을 관리해야 하는 위치이기 때문에, 필요없는 일을 하는 것들 두고 보는 것은 업무에 도움이 되지 않는다.

+ 만약 내가 3자의 입장이라면 : '이런 이런' 점들이 걱정되지만(뭔가 feedback을 원하는 경우이므로, 내가 관심이 있다는 것을 알려 주기위해 feedback은 해 주어야 한다.), 그렇게만 되면 정말 좋겠군요. 꼭 성공하세요.(마지막 feedback은 항상 긍정적이여야 한다. 나는 불가능하다고 생각하지만, 그 사람은 그것을 정말로 해 낼 수 있을지도 모르기 때문이다.)

나랑 관계없는 사람/일 에 굳이 부정적인 feedback을 주어서, 미움을 살 필요는 없다.

* Project에 대한 발표(Presentation)시, Risk에 대한 언급을 포함하고 있지 않다면 그 발표는 문제가 있는 것이다!

무엇이 문제인지도 모르는(고려해 보지 않은) Project description이 제대로 된 것일리 만무하다.

* Project Schedule이 "꼭 해야만 하는 일"로 꽉 차 있다면, Risk에 대해 전혀 고려되어 있지 않다는 것이다!

Project Schedule에 "꼭 해야하지는 않으나, Risk 완화를 위해 필요한 일"을 위한 시간이 포함되어 있어야 한다.

* Project 완료 시간이 너무 촉박하다면, 그 Project는 너무 늦게 시작된 것이다.(해당 사업계획을 잘못 세웠다는 말이다.)

기획/계획 쪽에서도 책임을 져야한다.

많은 회사들이 굴곡을 겪게 된다.

완전히 망하지는 않더라고, 흥(興)했다가 쇠(衰)했다가를 반복하게 마련이다.

사세(社勢)가 안 좋을때는 "좋지 않은 회사"라는 인식때문에 소위 스펙이 좋은 사람들, 다시말하면, 일반적인 회사들이 채용하고 싶어하는 조건을 갖추어서 원하는 회사를 선택할 수 있는 정도의 사람들은 입사를 꺼려하게 된다.

그러나 그 반대의 경우, 즉 사세가 상당히 좋을 때는 "좋은 회사"라는 인식을 가지게 되고, 좋은 사람들이 많이 들어오게 된다.

물론, 회사가 얼마나 잘 되느냐는, 회사에서 어떤 사람들이 일하고 있느냐에 따라 상당부분이 결정된다.

그렇지만, 그런 문제 뿐만이 아니라, 다양한 원인 - 사람, 환경, 전략 등등 - 소위 '흐름' 이라는 것이 존재하고, 이 흐름에 따라 기업은 상승기와 하강기를 겪게 된다.

그리고, 기업은, 회사에 기여한 업적을 기준으로 보상하므로, 소위 '안 좋은 상황'에 회사에 몸담고 있던 사람들은 '상승기'가 되면, '업적'과 더불어 회사가 어려웠을때, 기여했던 공로 - 아이러니 하게도, 그 중 상당수는, 다른 곳으로 이직할 수 있는 역량이 되지 못해서, 어쩔 수 없이 남아 있던 사람들일 가능성도 무시할 수 없다. - 를 인정받아 승진하게 된다.

자~, 이제 회사는 소위 "좋은 회사"로 인정받는 기간에 접어 들었다. 그리고, 사세가 확장되었으므로 일거리가 많아지고, 사람이 많이 필요하게 되었다.

따라서 신규 사람을 채용하게 되고, 이제는 "좋은 회사"로 인정받기 때문에, 뛰어난 스펙/실력/역량 의 지원자들이 몰리게 된다.

이런 과정을 거치게 되면, 회사의 인력 구조는 제목에서 언급한 바와 같이, 실질적인 역량이 떨어지는 사람이 뛰어난 실력의 신입 입사자들을 관리하는 구조로 만들어지게 된다.

회사의 관점이 아니라, 개인의 관점에서 보면, 어떤 사람이 "나는 왜 이직하는 회사마다 망하거나, 아니면, 회사가 어려워지지?"라고 생각한다면, 그 이유는 십중팔구 그 사람이 소위 "뛰어난 사람"이기 때문일 가능성이 높다.

뛰어난 사람이므로, 이직할 당시 "최고의 회사"에 지원해서 합격할 것이다. 보통 "최고의 회사"라고 칭해지는 곳은 그 회사의 정점에 서 있을 확률이 높다. 즉, 더 좋아지기 보다는 이제 하강기에 접어들 가능성이 높다는 뜻이다.

따라서, 이런식의 이직을 몇차례 경험하게 되면, 앞서 이야기 한 바와 같은 생각을 가지게 되는 것도 무리는 아닐 것이다.

어쨌든... 만약, 내가 생각하고 있는 이런 가정들이 충분히 납득할 만하다면, 이직을 할때, 소위 "최고의 회사"에 들어가는 것 보다는 "성장 가능성"을 보고 입사하는 것이 좋아보인다. 물론... 어떤 회사가.. 흥할것이냐 망할 것이냐는 누구도 알 수 없겠지만.... -_-;

많은 기업들이, 직원들이 업무시간 중에 소위 '잡담'하는 것을 굉장히 싫어 - 일을 안하고 '논다'고 생각하는 듯 하다. - 하는 것 같다.

그래서, 직원들이 휴식할 수 있는 공간을 별로 만들지 않거나, 눈치를 보며 만들더라도 접근성이 어려운 곳에 위치한 경우가 많다.

비록 그것이 '고의적'인 조치는 아니라 할지라도, 직원들의 휴식공간이 회사의 업무공간 배치에 우선순위를 가지가 어렵기 때문에, 결국 접근성이 좋지 않은 곳으로 결정나는 경향도 있을 것이다.

그 원인이 어찌되었던 간에, 휴식공간에 대한 직원들의 접근성에 문제가 있는 경우 어떠한 문제가 발생할까?

직원들의 복지, 만족도 같은 당연하고 일차원적인 영향은, 너무나 당연한 것이므로 따로 이야기 하지 않겠다.

문제는, 직원들이 소위 '잡담'을 하고자 할때, 혹은 짧고, 간단한 업무회의를 하고자 할때 발생한다.

간단한 업무회의라, '회의실'을 따로 잡기에는 좀 무리가  - 회의실은 대부분 항상 부족하기 때문에 막상 예약하려고 해도 사용할 수 있는 곳이 없는 경우가 다반사다. -  - 있으므로, 그냥 업무하는 공간 - 큐비클 - 안에서 이야기 하는 경우가 종종 발생하게 된다.

'잡담'역시, 휴게공간에 가는 것이 귀찮으므로 - 접근성이 떨어진다 - 그냥 큐비클 안에서 이루어지는 경우가 많게 된다.

문제는, '회의'나 '잡담'을 하는 당사자가 아니라, 그 주변 사람들이다.

소프트웨어 회사의 경우를 생각해 보자.

소프트웨어는 엄청난 집중력을 요구하는 업무가 많다. 그런데, 이때 주변에서 '회의'를 하거나, '잡담'을 하는 소리때문에 집중하기 어려운 환경이 조성되게 되면, 업무에 차질을 빚게 된다.

100여명이 일하는 공간을 가정해 보면, 그 중 한 곳의 2~3명이라도  이러한 '큐비클 안 회의/잡담'을 하게 되면, 다른 97~98 명은 집중을 요구하는 일을 하기에 대단히 어려운 환경에 처하게 되는 것이다.

그렇다고 해서, '업무 큐비클에서 회의하거나 잡담하지 말라'라는 공문/지시를 하는 방법으로 해결하려고 한다면, 이 또한 흐지부지 될 가능성이 높다.

처음 며칠은 지켜질 수도 있겠지만, 약간만 시간이 지나게 되면, 또 다시 이러한 문제들이 발생하게 된다. 왜냐하면, 근본적으로 이 문제를 '처벌의 대상'으로 보기에 상당한 무리가 따르고, 객관적인 '측정기준' - 처벌을 위한 - 을 만들 수가 없으므로, 지켜지지 않을 것이다.

결국, 직원들의 휴게 공간이 부족 + 접근성의 문제는 전체적으로 보면, 직원들의 업무 효율성과도 직접적인 연관성이 있다.

소위 '직원들이 노는 꼴을 못 본다.'는 회사가, 직원들의 휴게 공간에 대한 접근성을 심하게 떨어뜨리게 되면, 역설적으로 '직원들이 일을 제대로 할 수 없는' 환경을 만들게 되는 것임을 깨달을 필요가 있다.

 자기 개발 서적에서 많이 나오는 이야기 중 하나가. "모든 것을 '자기 탓'으로 돌려라."이다. 그래야 자기 발전이 있고, 문제해결의 실마리가 보이기 때문이다. 문제의 원인을 외부의 탓으로 돌리면, "어쩔 수 없다."는 결론 이외에는 얻을 수 있는 것이 없다.

 이런 관점에서 보면, 국내 정치환경이 나아지기 까지는 앞으로도 많은 시간이 필요한 듯 하다. 

 정치에 불만을 가지는 대부분의 글이 "저 정치인은 이래서 문제고, 저래서 문제고..." 등의 글이다. 즉, 문제의 원인을 "잘못된 정치인" - 외부 - 에서 찾고 있다. 그래서, "정치인은 어쩔 수 없다." 혹은 "정치가 다 그렇지 뭐" 식의 이야기가 나오게 되는 것이다. 위에서 "자기 개발 서적"을 예로 든 내용과 거의 유사한 흐름이다.

정말 문제를 해결하고 싶다면, 원인을 "자기 탓"으로 돌려야 한다. 즉 "내가 왜 저런 정치인에게 표를 줬을까?" 혹은 "왜 저 정치인에 표를 준 많은 사람들 중 한명이라도 더 설득하지 못했던가?" 등의 방식으로...

정치에 대한 불만을 표출하는 글과 말들이, 정치인을 주어로 하지 않고, 자기 자신을 주어로 하는 식으로 변해갈 때, 비로소 우리는 "변화"를 이야기 할 수 있지 않을까?...

Software업계에서 Programming skill 이라는 단어가 많이 사용되고 있는데 비해, 그 정의가 명확하지 않은 것 같다.

아니, 정의가 명확하지 않은게 아니라, 정의를 실체화 하는 방법이 명확치 않다고 해야 하나?

일단 "좋은 코드/소프트웨어"라는 말에 대한 정의는 어느 정도 합의된 실체가 있는 것 같다.

그럼에도 불구하고, 정량적인 측정 기준이 없기 때문에 여전히 관념적인 형태에 머물러 있긴 하지만...

그런데, "좋은 소프트웨어"를 만드는 것 => Programming skill 이 뛰어난 것"이 되지 못하는 이유는 현실적으로, 보통 '시간'으로 대표되는 '비용'이라는 요소가 들어가기 때문이다.

그래서 결국, Programming skill은 "적은 비용으로 좋은 소프트웨어를 만드는 기술"이라고 정의되어 질 수 밖에 없다.

문제는 앞서 이야기한 것처럼, "좋은 소프트웨어"라는 요소는 정량적인 기준이 없고, 측정방법 또한 모호하다. 그렇지만, '비용'은 객관적이고 명확한 측정 방법을 가진다. 그러다보니, 두 요소 중 '비용'이라는 요소에 더 집중하게 되고, 그것을 기준으로 Programming skill 을 말하는 경우가 많다.

그러다 보니, 극단적으로, "적인 비용으로 소프트웨어를 만드는 기술"이 Programming skill 로 왜곡되어 정의되어 버리게 된다.

(이 경우, 소프트웨어의 품질은 전혀 고려 대상이 아니다.)

실제, 계약에서도, 측정할 수 없는 "좋은 소프트웨어"라는 항목을 계약서에 기술할 수 없으므로, "비용"에 초점이 맞추어 질 수 밖에 없게되고, "적은 비용"이라는 기준을 만족시키는 쪽이 "기술력이 있는 곳"이라는 평가를 받게 되는 기이한 현상이 벌어지게 된다.

이는 계약에서 뿐만아니라, 국내 기업의 업무 형태에서도 쉽게 찾아볼 수 있다 - 물론 모든 기업이 그렇다는 이야기는 아니지만, 대부분(특히 소프트웨어가 주 제품이 아닌 곳들)의 경우 해당될 것이다.

소프트웨어를 만드는데, 연봉이 높은 우수 인력을 사용하는 것은 '과다 비용'으로 받아들이고, 경력이 짧은 미숙한 엔지니어에게 일을 맞겨 소위 "돌아가는 소프트웨어"를 만들어 내는 것을 "잘 했다"고 평가한다. 즉, 소프트웨어의 "품질"은 무시되고, "비용"부분만 고려된 "평가"인 것이다.

이와 같은 현상은 계속 반복된다.

위와 같은 방식으로 만든 소프트웨어는 필연적으로 수많은 문제점(버그)를 내포하게 된다. 이제 이 문제점들을 수정해야 하는데, 이 역시 '비용'만을 고려해서, 미숙한 엔지니어가 처리하게 되고, 수많은 fix-on-fix를 양산하는 악순환을 반복한다.

그러면서, "소프트웨어는 당연히 많은 버그를 내포할 수 밖에 없고, 약간의 수정도 많은 문제점을 동반할 수 밖에 없다."라는 이상한 결론을 내려 버린다.

위의 이야기는 좀 극단적인 측면이 있지만, 국내 현실을 상당히 잘 반영한다고 생각한다.

"소프트웨어의 비용 감소"라는 측면에서 시작된 것이 아니라, 순수하게 "소프트웨어 품질의 정량화"라는 측면에서 시작된, 소프트웨어 관련 연구가 활발하게 이루어 졌다는 이야기는 들어 본적이 없다. 물론, 내가 잘못 알고 있는 것일 수도 있지만...

각설하고... 슬프지만... Programming skill에 대한 가장 현실적인 정의는 "적은 비용으로 소프트웨어를 만들어 내는 기술"이라고 할 수 밖에....

주저리 주저리... 문맥도 안맞고... 내용도 정리가 안되어 있고.. 쩝..

아침에 출근하다가 버스에서 라디오를 듣는데...  우르과이 "호세 무히카"대통령을 언급하면서, 대통령에 대한 존경을 표하는 내용의 방송이 나왔다.

그런데 문득 대한민국은 참 이상한 나라라는 생각이 들었다.

"왜 대통령을 존경하지?"

그때부터, 아래와 같은 생각들이 계속해서 머리에 맴돌았다. (그냥 떠오르는대로 마구 적어 본다...)

내가 보기에는, 대한민국의 많은 국민들이, 나라에서 일어나는 많은 일들의 공과(功過)를 이야기할때, "정치인의 공과(功過)"라는 관점으로 접근하는 것 같다.

박정희 전 대통령의 경우를 예로 들어 보면...

많은 사람들이 '박정희' 전 대통령의 업적 중 하나로, '경제성장'을 말한다.

일단 '박정희' 전 대통령에 대한 다른 평가는 전부 접어두자.

여기서 내가 이야기 하고 싶은 것은, '경제성장'의 업적을 자연스럽게 나라의 최고 통지자에게 돌리는 '이상한' 모습이다.

박 전 대통령의 역할이 전혀 없었다는 말을 하는건 아니다. 그건 누구도 알 수 없는 부분이다. 엄청난 기여를 했을 수도 있고, 전혀 기여하지 않았을 수도 있다. 혹은 오히려 방해가 되었을지도 모를 일이다.

그런데, 이상하게도 상당수의 국민들이 '경제성장'이라는 업적을 그냥 단순하게 '대통령'의 업적으로 이야기한다.

왜 그럴까? 그냥 단순한 '국민성'인건가? 아니면, 책임 회피? 모르겠다.

그렇지만, 내 생각은 이렇다.

박 전 대통령의 '경제성장'에 대한 공과(功過)는 논란의 여지가 있으나, 한가지 100% 확실한 것은 '경제성장'의 주역은 그 시대를 살았던 '대한민국 국민'이라는 것이다. 즉, 한강의 기적은 '최고 통치자의 업적'이 아니라, '대한민국 국민의 업적'으로 받아들여져야 한다.

다시 "호세 무히카" 대통령에 대한 이야기로 돌아가보면...

우리가 존경해야할 상대는 "호세 무히카" 대통령이 아니라, 그 사람을 대통령으로 선출한 "현재의 우르과이 유권자"가 되어야 하다.

대한민국에 과연 "호세 무히카"같은 사람이 없을까?

그럴리 없다. 어딘가 분명히 더 훌륭한 분이 계실 것이다.

그렇지만, 대한민국 유권자는 그런 사람을 대통령으로 선출하지 않았다.

"등록된 후보 중에 그런 사람이 없지 않냐?"라는 이야기를 한다면, "대한민국 유권자가, 그런 사람이 '등록하면 당선될 수 있다.'라는 희망을 가질 수 있는 정도의 수준인가?"라고 되묻고 싶다.

정리하면... 우리는 훌륭한 정치인을 칭찬하기 보다는, 그런 정치인을 알아보고 선택한 것을 자축해야 하며, 나쁜 정치인을 비난하기 보다는, 그런 정치인을 선택한 것을 반성해야 한다. 시대의 '공(功)'과 '과(過)'는 정치인의 몫이 아니라, 그 시대를 사는 국민들의 몫이다. 적어도, 민주주의 국가에서는...

 소프트웨어가 커지다 보면, 자연스럽게 OOP개념들을 집어 넣을 수 밖에 없고 - 그렇지 않으면, SW 유지보수가 거의 불가능 하다. - 각 컴포넌트/모듈들을 독립적으로 구현하기 위해서 고민하게 된다.

 각 모듈이나 컴포넌트가 독립적일수록 재사용성이 높아지고 모듈간 의존도가 줄어들게 된다.

 그런데, 문제는 이렇게 서로 독립적으로 만들다 보면, error value들 역시 독립적으로 선언해야 하게 되는데, 이게... 좀... 거시기 하다.

예를 들어, 모듈 A, B, C가 있을 때, A -> B -> C 이런식으로 C가 B를 reference하고, B가 A를 reference하는 경우, C와 B는 각각 내부 구현을 숨기기 위해서, B와 A의 error value를 노출 시킬 수 없게 된다. 따라서, B는 A의 error value를 B자신의 value로 mapping해야 하고, C또한, 이렇게 mapping된 B의 value를 다시 C자신의 value로 mapping해야 하게 된다.

 쩝... overhead의 chain effect라 불릴만 하다.

그래서 많이 하는 방법이, 상당히 자주 사용되는 error value는 global하게 공통적으로 정의하고 - ex. invalid parameter, out of memory 등등 - 세부적인 것들에 대해서는 모듈 specific하게 정의하는 것이다.

예를 들면...

common_error.h

enum {

COMMON_ERR_01 = 0,

COMMON_ERR_02,

...

LIMIT_COMMON_ERR,

CUSTOM_ERR_BASE_OFFSET,

};

module1.h

enum {

MODULE1_ERR_01 = CUSTOM_ERR_BASE_OFFSET,

MODULE1_ERR_02,

...

};

module2.h

enum {

MODULE2_ERR_01 = CUSTOM_ERR_BASE_OFFSET,

MODULE2_ERR_02,

...

};

 음... 꽤나 괜찮은 해결책으로 보인다. 아니, 현재까지 생각으로는 현실적으로 가장 좋은 해결책으로 보인다.

 그렇지만, 여전히 몇 가지 문제점이 존재한다. 먼저, error value의 return type을 그냥 int 를 사용해야 하는데 - 공통된 error value의 type을 정의할 수 없다 - constant value는 inline으로 코드에 삽입되기 때문에, debugging시에 썩 좋지 못하다는 문제가 있다. 또한, return type이 그냥 int 라 code readability도 썩 좋지 못하다.  또한, global common error code가 module내에서 사용되므로, 이 모듈을 전혀 다른 SW에 porting할때, common error 부분을 해당 SW에 맞게 수정을 가해야 하는 문제도 있다.

 그렇지만, overhead와 재사용성 양쪽을 균형있게 고려한, 충분히 훌륭한 방법임에는 틀림없다.

음...

 혹시 다른 좋은 아이디어가 떠 오르면... 다시 posting하기로 하고...

‎"유투브에서 동영상을 다운로드하는 앱들이 인터넷을 찾아보면 널렸는데 왜 마켓에는 없을까..."라는 의문에서... "구글이 자기들 이익을 위해서 그렇게 했다..." 라고 생각했었는데... 오늘 다시 한 번 곱씹어 보니 다른 결론을 내렸다.

유투브의 동영상의 소유권은 구글에 있지 않고, 업로더에 있다고 알고 있다.
그리고 유투브는 소유권자의 동의를 얻어 그 동영상을 스트리밍 서비스 하는 것이고...

구글이 자신들의 이익때문에 그러는게 아니라, 컨텐츠 소유권자의 권익 보호를 위해서 그러는거다... 라는 긍정적인 방향에서도 볼 수 있겠다....

한편, T-store에 Tubemate(유투브 다운로드 앱)가 버젓이 올라와 있는 건 SKT는 유투브와 전혀 관계없기 때문에 '수단'을 제공할 때 생길 수 있는 어떠한 제약도 없기 때문이 아닐까?

뭐 나름 주저리 주저리 이런 결론도 가능하다.. 라고 생각했다는...ㅋㅋ - 물론 아무런 근거도 없는 나 혼자만의 생각... ^^

뭐.. 여러가지 SW Branch 정책들이 있을텐데... (하나의 branch에 전부 때려 잡아 넣고 개발하는 회사라면... 쩝 뭐 특별히 할 말 없다)

보통의 경우 SW branch는 아래와 같은 형태를 가진다.

                               +------------------------------ sub branch
                              /
---------+-------------------+-------------------------------------- main branch
          \
           +------------------------------------ sub branch

기본적인 형태는 같지만, 정책적인 측면으로 보면 크게 두 가지로 분류할 수 있다.

1. 큰 main branch 정책

- main branch가 기능 구현의 주요 작업 공간이 되는 방법.

- main branch 가장 자주 update된다.

- feature이 대부분 main branch에서 개발되므로, 다른 외부 project branch의 개수가 적은 편이다.

2. 작은 main branch 정책

- sub-branch가 기능 구현의 주요 작업 공간이 되는 방법.

- main branch가 가장 뜸하게 update되고 엄격하게 관리된다.

- feature들을 main branch와는 별도로, 서로 다른 project branch로 관리한다.

위의 두 가지 모두 기본적인 업무 방식은 같다.

1. 특정 시점에서 main branch에서 branch out

2. 필요한 새로운 feature들을 구현하거나, 다른 feature branch로 부터 가져오고, stability를 향상시킴

3. software release

4. 필요한 patch들을 main branch에 다시 merge함.

그렇지만, 위와 같이 서로 다른 방식의 정책을 적용하다보면, branch의 특성이 서로 달라진다.

1. 큰 main branch 정책

- main branch는 feature위주로 관리된다.

- main branch는 거의 모든 feature들을 가진다.(feature들의 super-set)

- main branch가 가장 많은 버그를 가진다.

- main branch의 코드 size가 sub branch에 비해 크다.

- 보통 branch out의 기준은 feature가 된다. 즉, 특정 feature가 available한 시점을 기준으로 main branch로 부터 branch out한다.

장점 : Integration에서 발생가능한 문제들이 main branch에서 충분히 다루어진 상태이므로, sub branch에서 이 문제에 대한 risk가 적다.

단점 : main branch의 stability관리가 어렵다. 그래서, sub branch에서 stability를 위한 비용이 크다.

2. 작은 main branch 정책

- main branch는 stability위주로 관리된다.

- main branch는 최소한의 feature만을 가진다.

- main branch의 stability가 가장 뛰어나다.

- branch out의 기준은 feature보다는 stability가 된다.

장점 : main branch의 stability가 충분히 좋으므로, sub branch에서 stability문제가 발생하더라도, main branch를 기준으로한 debugging이 가능하므로, 적은 비용으로 sub branch의 stability를 유지할 수 있다.

단점 : integration에 따른 문제들이 충분히 드러난 상황이 아니므로, sub branch에서 이것과 관련된 많은 문제들이 나올 수 있다.

branch 정책을 결정할 때는 위의 두 가지 요소를 충분히 고려할 필요가 있다.

stability에 대한 비용 vs. integration에 대한 비용

그리고 거기에 따라, branch 정책을 정할 필요가 있다.

개인적으로 봤을 때, 대부분의 경우, stability를 위한 비용이 integration비용에 비해 상당히 비싸다.

따라서, 작은 main branch정책이 더 좋은 것 같은데.... 

어지간한 규모가 있는 회사라면, 이유나 목적이야 어떻든 공식적으로는 직원들의 역량 강화라는 명목으로 교육을 실시하는 경우가 많다. 하루짜리 단일성 교육부터 8시간 4~5일짜리 장기교육까지... 가격도 어마어마하다.

그런데 그런 교육의 효과는 어떠한가? 그만한 값어치를 하는가? 교육을 받는 당사자의 생각도 중요하지만, 돈을 들여 교육을 실시한 회사의 입장은 어떤가? 직원들을 일주일간 업무에서 빼고, 비싼 강의료를 지불하면서까지 실시한 교육의 그만한 가치가 있다고 생각하는가?

대부분의 경우 만족스럽지 못할 것이다. 왜 그럴까?

아래는 전부 내 개인적인 생각으로 어떠한 근거도 뒷받침할 자료도 없다. -_-;

과거 학생 때를 돌이켜 보면, 공부에서 가장 중요한 것은 예습/복습이다. 회사에서 실시하는 교육도 그 연장선상에 있다고 본다.

보통 회사에서 실시하는 교육자체가 직무관련 교육인 경우가 많기때문에 어느정도 예습의 효과는 있다고 본다. - 물론, 교육의 커리큘럼을 따라서 제대로 예습한다면 더 좋겠지만...

그런데 문제는 '복습'이 전혀 이루어 지지 않는 다는 것이다.

1주일 교육이라면, 그 교육이 끝난 뒤에는 바로 업무에 복귀하게 되고, 일반적으로 회사에서 수행하는 없무는 교육받은 내용과 어느 정도 거리가 있기 마련이기 때문에 교육기간 동안 습득한 내용을 자기 것으로 만들 시간이 거의 없다.

복습의 효과에 대해서는 이미 수많은 검증된 연구결과들이 있다. 복습을 전혀 하지 않는 것과 어느 정도 복습을 하는 것은 교육의 효과와 더불어 내용을 기억하는 기간에 엄청난 차이를 가져온다.

그래서 난, 회사가 어차피 직원들을 교육시키는데 비용을 투자하기로 결정했다면, 약간의 비용 - 직원들이 업무 외의 일을 할 수 있는 추가적인 시간 - 을 더 투자해서 '강의'를 통한 교육에 이어서 교육의 내용을 소위 '복습'할 수 있는 공식적인 기간을 주는 것이 필요하다고 본다.

물론, 회사에서 하는 일이니 측정가능한 '성과'는 있어야 할 것이다.

그것이 세미나의 형태가 되었건 아니면, 잘 정리된 문서가 되었건, 아니면 교육의 내용을 기반으로한 간단한 소프트웨어 툴이 되었건, 자신이 습득한 내용을 정리하고 적용해 볼 수 있는 시간을 공식적으로 주고 또 장려할때, 교육의 성과가 극대화 될 것이라고 본다.

구체적으로 예를 들어보면, 하루 8시간 5일 교육을 가정하면, 이후 일주일 - 5 업무일 - 은 '복습'의 시간으로 할애해서, 피 교육생들이 교육시간에 배웠던 것들을 이것저것 실습해보고 적용해 보도록 하는 것이다...

쩝... 전부 내 개인적인 생각들이였다... 교육 들을때만 고개를 끄덕이고, 끝나고 일주일만 지나면, 뭘 들었는지조차 기억에서 희미해지는 그런 비효율적인 교육들을 보면서 답답한 마음에 끄적여 본다...