Bubble-sort with Hungarian ("Csángó") folk dance

nginx가 허용하는 파일 사이즈는 1메가

디폴트가 1메가 입니다 여러분!!!이메가 아님.

그래서 어떻게 고치냐...

client_max_body_size 100m;

이걸로 고쳐집니다..100메가로....

당신의 조직에서 당장 시작해야할 단 한가지의 조직개편

스크럼에는 여러가지 아이디어들이 있는데, 그중에서 가장 효과적인 한가지를 꼽으라 한다면 주저 없이 나는 이것이라 말하겠다.

Feature Team

 대충 설명하자면 이거다. 이게 일반 적인 팀의 구성이다.
편하지 않은가? 마음이 정화되는 것 같고 막.. 정리되어 있다는 느낌도 들고..
우리가 당연하다고 생각하는 조직 구성인데, 이 조직 구성에는 몇가지 치명적 문제가 있다.

1. 커뮤니케이션 로스(loss)
   대장은 개발보스와 개발 보스는 쫄짜들 개개인과 태스크(task)를 주고 받는다. 내가 쫄짜1인데, 로그인 화면을 만들라는 오더가 내려왔다고 치자. 나는 일단 디자인 팀에서 누가 로그인 화면을 만드는지 파악해야하고, 그외 팀중에 DB팀에 가서 누가 데이터 모델을 만드는지 알아야 한다. 자신들의 팀이 괜찮은 팀이라고 착각하는 팀들은 이 "다른팀의 누가"를 중간 보스들이 파악하고 있어서 바로바로 대답해 주는 경우가 많다. 어쨌든 나는 건너건너 누군가와 일을 해 나가야 한다. 자리도 멀리 떨어져 있어서 잡담도 못한다.
2. 개개인은 조직의 일보다, 자신의 일에 집중함
   내 일만 하면 된다. 옆에 쫄짜2가 어떤 일을 하는지 알 필요도 없으며 알아도 내가 해줄 것도 없다. 그저 위에 보스가 최대한 옆에 있는 놈이랑 나랑 비슷한 태스크를 주길 바랄 뿐이다. 당연히 프로젝트가 어떻게 되는지 나는 잘 알지 못한다.
3. 슈퍼맨 리더를 찾을 필요가 있음
   슈퍼맨 리더의 능력이 그 팀의 능력을 좌우한다. 그런 사람을 찾는 것이야 말로 프로젝트를 성공시키는 첩경이다. 찾는거도 일이다. 아니, 너무 힘든 일이다
4. 리더는 결국...
   이 상태에서 리더는 결국 "하얗게 불태웠어.."라고 읖조리며 조직을 나간다. 내 할 일도 많아 죽겠는데 밑에 애들 관리도 해야지 위에 보고도 해야지, 가장 Hot한 영역이기 때문이다.
5. 결국 팀의 시너지 효과는 기대하기 힘들다.

그럼에도 대부분 이런 구성으로 조직을 이끌어 나가는 건, 장점이 있기 때문이다. 그건 바로,

파악하기 쉽다. 그리고 해라고 하는 것만 하면 된다.

이걸로 연결된다. 내가 대장이면, 밑에서 중간 보스들이 들려주는 얘기만 들으면 대충 다 파악된거 같은 기분이 든다. 그리고 더 큰 장점이 있는데, 밑에 사람입장에서는 위에서 해라고 하는 것만 하면 된다는 거다. 인간이 살아가는데 가장 편한 방법이다. 위에서 해라고 하는거 그대로 하고 주는 돈 그대로 받고.. 그 돈 받아서 남들이 하는거 하면서 사는거..

자, 당신이 만약에 경영자라면 여기서 어? 라고 생각해야 한다. 뭐냐고? 아니 당신이 월급을 주는 아랫것들이 편하게 일하고 돈받아 간다는거다. 안그러냐? 더 쥐어짜야지. 어떻게 쥐어 짜냐고? 대부분 이 부분에서 특별한 고민없이 아랫것들을 쥐어짜기 위해 하는 짓이 집에 안보내기인데. 그런 짓을 했다가는 짜봤자 아무것도 안나올거기 때문에 당신(경영자)도 해피할 수 없고, 짜지는 쫄짜들도 어차피 하는 것 똑같은데 집에만 못가기 때문에 불만만 쌓인다. 그럼 어떻게 하느냐.

 

프로덕트 오너와 스크럼 마스트는 무시하고 아래의 팀 구성만 보자. 팀 하나가 하나의 기능을 온전히 만들 수 있는 단위로 되어 있다. 그냥 섞어 놓은 것 아니냐고? 맞다 섞어 놓은 것. 이 구성에서의 장점은

1. 자연스럽게 다른 종류의 팀원들과 대화를 할 수 있다.
   개발자와 개발자는 그냥 놔둬도 둘이서 잘논다. 디자이너와 디자이너도 그냥 놔두면 둘이서 짝짜꿍한다. 그럼에도 그들을 붙여놓음으로 인해 조직은 벽이 생긴다. 일부러 섞음으로 구성원들이 커뮤니케이션을 좀더 다양한 방법으로 할 수 있게 된다.
2. 팀 하나가 하나의 기능을 온전히 구현할 수 있다.
   이제 로그인 화면을 만드는데 쫄짜1이 여기 저기 돌아다닐 필요가 없다. 팀 하나가 하나의 기능을 완전히 구현할 수 있는 구성이 되어 있다.
3. 팀들간, 같은 종류의 구성원들이 문제를 해결해 나간다.
   팀1과 팀2,3에 속해있는 디자이너 들은 정기적인 미팅을 통해 자신들의 팀에서 일어난 일들을 공유하고, 자신들만의 해결책을 생각한다. 그리고 자신들의 팀으로 돌아가 그걸 실행한다.

물론, 이런 팀을 구성하고 운영해 나가는 건 힘들다. 그런데 자신들의 조직이 좀 더 빠르고, 효율적으로 움직이길 원한다면 그만한 노력은 해야 한다. 

(쓰다가 막판에 오니 해야할일이 생각나서..급하게 접습니다...기회되면 또 편집하겠습니다. )

git 에서 리모트 리포지토리를 로컬로 덮어쓰기

실서버 소스를 약간 수정한 뒤 git pull을 했더니, conflict가 일어나서 패닉상태가 되었을때.. 이 두 커멘트면 해결이 가능하다.

$ git fetch origin
$ git reset --hard origin/master

참고로 인터넷상에, git pull 커멘드를 이용해 강제로 pull을 받는 방법이 소개되어 있는데, pull은 git fetch와 git merge origin/master를 동시에 해주는 커멘드로써, 로컬에서 소스와 merge할 일이 없으면 되도록이면 쓰지 않는게 좋다.

git 에서 특정 파일을 되돌리기

특정파일을 되돌리고 싶을때 쓰는 커멘드

$ git log filepath
commit 1234512345
Author: ********
Date:   Mon Mar 21 22:24:08 2016 +0900

$ git checkout 1234512345 filepath

더 이상 설명은 필요 없겠죠??

한글url이 브라우저에 따라서 엑세스가 안될때..

지금 개발하고 있는 사이트에서, 한글파일명의 파일을 AWS s3를 통해 서비스한다.

그런데 크롬으로 접속을 하면 다운로드가 되는데 사파리에서는 안되는 현상이 발생..

원인은, 크롬에서는 알아서 조합형으로 인코딩해주는데 반해서, 사파리에서는 완성형으로 인코딩하는데서 오는 '것 같다'..

암튼 주소를

window.encodeURI(input)

해주는것으로 해결.

야근은 독이다.

 나는 일주일에 100시간 넘게 일하는데 넌 80시간 언저리잖아. 지금보다 더 일하라는 소린 안할테니까 좀 참고 일해주라

아주 비겁한 말인데, 많은 창업자들과 리더들이 아랫사람들에게 저런 생각을 가지고 있다. 나도 일하니 너도 일해야 하고 그래야 우리가 더 빨리 성공할 것이며 더 많은 것을 이룰 것이다. 실제로 그럴까?

일반적인 조직에서의 일...

우선, 일반적인 상하관계가 있는 조직에서 리더들이 한다는 야근과 아랫것들이 하는 야근은 성격이 틀리다. 가장 큰 차이점은 자의에 의해서 하느냐 타의에 의해서 하느냐이다. 리더들이 매일 남들보다 열심히 일을 한다해도 그들은 그들 자신의 태스크를 자신이 정하고, 스케쥴 역시 자신이 관리한다. 그러므로, 특별한 날에 일을 잠시 접어두고 애인과 데이트를 할 수도 있고 스케쥴 대로 해내지 못했을때 자신에게 관대하다. 왜, 자기가 했으니까 이유따위는 이미 준비되어 있다.
아랫것들은 다르다. 우선 자신이 원하지도 않은 태스크 할당받고 동의하지 않은 스케쥴을 강요받는다. 온 스케쥴대로 진행되면 진행되는대로 리더는 태스크의 볼륨이 남들에 비해서 적으니 조정해야 한다며 늘리고,  맞추지 못하면 죄인이 되어, 제대로 된 이유를 찾아내어 설명하고 리더가 고개를 끄덕여야 비로소 면죄받는다.
이런 상황에서 단순하게 리더가 조금 더 오래 일한다고 아랫것들보다 더 고통받는다고 볼 수 있을까.

나의, 혹은 당신의 회사..

아침 10시에 출근한다. 우리는 스타트업이다. 우리에게 룰따윈 없다. 그래서 남들은 9시에 출근하는데 우리는 10시에 출근하도록 했다. 10시가 되면 하나둘씩 사람들이 온다. 잡담 좀 하다 10시 반쯤 되면 각자 모니터를 들여다보기 시작하고 11시 반쯤 되면 밥을 먹으러 간다. 그렇게 오전은 끝이 난다.
오후가 되어 일을 하기 시작하는데, 빨리해야겠다는 생각 따윈 없다. 빨리 하든 늦게 하든 퇴근 시간은 밤 11시 이후다. 아직 10시간이나 남았다. 시간은 많다. 그렇게 대충대충 시간은 간다. 아니 소비해야 한다.

문제점

가장 큰 문제점은, 왜 야근을 해야하는가에 대한 동의가 없다. 아침 출근할때부터 그날이 야근이라는 걸 안다. 전쟁을 시작할때 이미 패배할 것 알고 시작하는 것과 같다. 만들고 싶은 어플을 만드는 것과, 리더가 다들 피곤하니 이제 집에 갑시다, 할때까지 어플을 만든다고 했을 때 어느 쪽이 생산성이 나을까. 후자가 갯수는 더 많을 수는 있겠지만 품질 역시 나을 수 있을까. 아니, 저런 식의 조직이 유지는 될 수 있을까.

그럼 야근은 무조건 해서는 안되는 것인가

앞서 언급한 '일반적인 조직'은, 사실 대기업과 중소기업 그리고 스타트업에서 조차 많이 보이는 조직 형태다. 상하관계가 명확하고, 구성원들 대부분은 리더가 분배한 태스크들을 완수해 나간다. 전통적인 산업의 그것에 근거하여, 강한 리더가 구성원들을 이끌어 나가고 지시하는 것이 우월한 조직이 되는 지름길이라고 믿는 것이다. 그래서 스타트업이라 할지라도, 괜찮은 리더를 찾으려고 하고, "관리능력"이 있는 자를 고용하려 노력한다. Under the control을 지향한다.

사실, 야근을 생산적인 야근으로 바꾸는, 아니 일 자체를 좀더 생산적으로 바꾸는 단 한가지 방법은 이 구조를 없애는 것이다. 구성원들 각자가 주체적으로 행동해야 한다. 프로덕트에 대한 구상도 구성원들 전체가 하고, 계획도 구성원들 전체가 하고, 생산도 구성원들 전체가 한다. 세부 태스크는 모든 구성원이 달려들어 리스트업하고 스케쥴은 구성원들이 각자가 납득하는 방법으로 이뤄진다. 야근은, 스스로가 원해서 해야한다. 당신이 프라모델 조립을 좋아한다고 치자. 당신에게 있어서, 프라모델 조립을 좋아하지 않는 이가 3일 걸리는 조립따위, 하루, 아니 반나절만에 조립하는 건 일도 아니다. 두가지 의미가 있다. 시간도 그만큼 걸리지 않는다, 그리고 말그대로 "일"이 아니다. 스스로 원해서 하는 거니까.

급진적인 생각이 아니냐고? 아니 그럼, 프로그래밍 한줄 못 쓰는 리더, 혹은 기획자가 던져주는 스케쥴은 그럼 얼마나 이상적인가? 스타트업에는 괜찮은 능력과 거기에 의욕까지 가진 인재가 오는 경우가 많다. 그런이들을 관리하기 시작하면 아웃풋은 리더의 역량, 딱 그만큼 밖에 얻을 수 없다. (물론 당신의 조직에 스티브 잡스나 마크 저커버그 같은 인물이 있다면, 그들에게 그냥 붙어가라. 그게 답이다.)

일반적인 조직이라면, 야근은 독이고, 일상적인 일은 그냥 "보통"이다. 보통 조직에서 혁신을 얻으려면 조직을 개편하는 방법 밖에 없다. 구성원들에게 독을 퍼먹이며 혁신을 강요하지 말라. 병만 든다.

다음번엔 스크럼에 대해서 쓰겠습니다.