zsh에서 HOME, END키 쓰기.

zsh이 떠있는 상태에서 아래 2줄 복사해서 붙여넣기

bindkey '^[[H' beginning-of-line
bindkey '^[[F' end-of-line

Screen Shot 2014-04-22 at 10.00.59 PM

바로 사용 가능!

태그 지정됨 , ,

DNSEver 유료화에 대한 사람들의 반응을 보면서..

dnsever

DNSEver가 유료화 되었다고, 다른 서비스로 옮기겠다고 하는 사람들이 있다.
옮긴다고 하는 서비스 또한.. 알고보면 유료인 곳도 있고..
그렇다면 그냥 DNSEver쓰면 안되나..?

가격이 터무니없게 책정이 된다면 문제가 되겠지만
합리적인 가격, 도메인당 고작 월 1,000 포인트 (결제하면 아마 1,100원일듯) 인데..
1,100원인데.. 1,100원이면 편의점에서 과자 하나 살랑말랑한 돈인데..
고작 1,100원때문에 이때까지 은혜를 배푼곳 나몰라라 하고 옮기나?
(자세한 가격 정책은 https://kr.dnsever.com/index.html?selected_menu=productandprice 참고)

이때까지 무료로 사용하면서 고마운 마음을 느낀적 일절 없고
당연한 권리를 누린다고 생각하는 걸까?

사람이 염치가 있어야지 말이야.
이런 행위도 일종의 먹튀라고 생각한다.

너무 공짜, 공짜, 공짜 하지 말고
합당한 가격을 지불하고 구매를 하는 것이 올바른 소비 문화이고, 해당 제품이 발전해 나갈 수 있는 밑천이 되는 것이다.

ps #1
무료로 사용하는 방법이 있긴 한다. DNSEver 서포터즈 프로그램게 가입하는 것인데..
자세한 방법은 https://kr.dnsever.com/index.html?selected_menu=supporters 참고

ps #2
DNSEver 서포터즈 프로그램에 가입할려고 쓴 글 아니다.
내용도 서포터즈 프로그램에 부합하지 않을 뿐더라, 유료 wordpress를 사용하고 있다.

태그 지정됨 , , , ,

스타트업에서는 실리콘벨리의 기업문화를 바라면 안된다.

존경하는 백준이형이 zdnet에 쓴 컬럼 “미국에선 상식인 기업문화가 한국에선 ‘꿈’”이다.
내용이 그리 길지 않으니 한번 읽어보자.

http://www.zdnet.co.kr/column/column_view.asp?artice_id=20140318084319

33가지중 마지막을 제외한 32가지는 스타트업에서도 충분히 할 수 있는 것이므로 패스! (전문은 하단에 첨부)

마지막 항목 “회사를 위해 희생하지 마요. 당신의 삶이 먼저에요.” 에 대해서 말하고 싶다.
캬~ 참 멋지고, 누구나 바라는 아름다운 문화이다.

일과 삶의 균형

헌데 이게 참 딜래마다
이미 성공해서 생사 걱정이 없는 회사라면, 개인의 삶이 먼저라고 말할 여유가 생긴다.
하지만 이런 여유가 없는, 하루하루가 생존을 위한 전쟁을 치루고 있는 스타트업이 개인의 삶이 먼저라는 모토로 운영을 한다면..
과연 그 회사는 살아남을 수 있을까?

스타트업은 때로는 밤을 새야하고, 때로는 선약을 깨야한다.
즉 개인의 삶을 희생해야만 할 때도 있는 것이다.
그렇지 않으면 살아남을 수가 없다.

애니메이션 심슨의 번즈 사장

너무 사장같은 마인드라고 여겨지는가?
“회사가 망하면 이직하면 그만이지!”라고 생각하는가?
이런 생각을 하는 사람이야말로 이기적이고 기생충같은 마인드 아닌가?

내가 사장이라면, 더군다나 스타트업이라면.. 절대 이런 사람 채용하지 않을 것이다.
난 밀집모자 해적단같은 팀을 만들기를 원한다. 아무리 능력이 출중해도 이런 인재는 팀을 와해시키는 썩은 사과에 불과하다.

스타트업에 취직을 하고자 한다면, 고생은 이미 각오를 해야한다.
가장 중요한 것은 재미와 열정이다.
본인이 재미를 느끼지 못한다면, 몰입해서 열정을 불태울 수가 없다.
열정이 없다면 스타트업의 고된 생활을 견딜 수가 없다.
물런, 정도의 차이는 있겠지만. 이런 사항을 미리 숙지를 해야한다.

만약 스타트업인데 엄청난 문화로 현혹하는가?
입사해서 놀고 먹으면 될 것 같은가?
일단 의심부터 하라.

  1. 회사의 재정 상태가 건강한가?
  2. 회사가 돈이 많이 있는가? (더 이상 투자를 받지 않아도 될 만큼)
  3. 정말로 놀고 먹으면 될 것 같은 회사인가?

여기서 한번 더 짚어주고 싶은것은 3번이다.
화려해 보인다고 해서 그것이 전부가 아니다. 자유에는 책임이 따른다는 사실을 잊지 마라.

스타트업에 입사한다는 것은
회사의 뜻과 귀감하고, 나의 뜻을 더하여, 동료와 함께 성장하고, 동료와 함께 성공하는 것이다.
시작은 미약하지만 동료와 함께 창대케 되는 것이 목표여야 한다.

밀집모자 해적단은 처음부터 엄청난 해적단이 아니었고,
루피 혼자만의 힘으로 유명해진 것도 아니다.
동료들 모두 자기몫을 하며 함께 성장해온 것이다.

루피 첫배.

처음엔 냇가에서나 탈법한 배로 시작

써니호

하지만 지금은 없는 기능이 없는? 배를 타고다닌다. 배인데 부스터쓰면 하늘도 막 날라간다 ㅋㅋ


스타트업 문화의 가장 중요한 핵심 키워드는 ‘개인’이 아니라 ‘동료‘ 라는 사실을 잊지 말기 바란다.
 

 

 

<제니퍼소프트에서 하지 말아야 할 33가지>

1. 전화 통화 시에 “지금 어디예요?”, “뭐 하고 있어요” “언제 와요?”라고 묻지 마요. 감시할 의중도 없잖아요.
2.“회의 중인데 좀 있다 전화할게”. 아니거든요~ 가족 전화는 그 어떤 업무보다 우선이에요.
3. 근무 외 시간엔 가급적 전화하지 마요. 사랑을 속삭일 게 아니라면!
4. 퇴근할 때 눈치 보지 마요. 당당하게 퇴근해요.
5. 우르르~ 몰려다니며 같은 시간에 점심 먹지 마요. 같이 점심 먹는 것도 때로는 신경 쓰여요. 시간은 자유롭게. 먹고 싶은 것을 먹어요.
6. 비즈니스 정장을 입기 위해 애쓰지 마요. 편하고 자유롭게 자신의 개성을 맘껏 뽐네요.
7. 출장 후, 초콜릿 사오지 마요. 그거 사기 위해 신경 쓰는 누군가에겐 부담되어요.
8. 회식을 강요하지 마요. 가고 싶은 사람끼리, 자유롭게 놀아요.
9. 타인에게 휘둘리지 마요. 내 인생의 주인공은 나에요.
10. 실패를 두려워하지 마요. 도전은 우리의 것. 책임은 회사 대표의 것이에요.
11. 대충 하지 마요. 디테일이 중요해요.
12. 사무실에서만 일하지 마요. 때론, 카페에서도 일해요.
13. 퇴근 후 일하지 마요. 우리에겐 휴식과 가족과 나눌 사랑이 힘이 되요.
14. 너무 일만 하지 마요. 가끔 놀아도 되요.
15. 회의 중에 침묵하지 마요. 침묵은 부정이래요. 항상 말해줘요.
16. 농담이라도 상대방을 비웃지 마요. 당신은 웃지만 상대방은 상처받아요.
17. 서로에게 반말하지 마요. 항상 서로 존중해요.
18. 형식에 얽매이지 마요. 본질에 집중해요.
19. 슬금슬금 돌아앉지 마요. 함께 나눈 이야기 속에 좋은 아이디어도 창의성도 발현되어요.
20. 혼자 하지 마요. 함께 하면 힘이 되요.
21. 감정 표현을 망설이지 마요. 고마워요! 미안해요! 함께 할까요? 이렇게 표현해요.
22. 구성원이 힘들면 외면하지 마요. 이야기 들어주고 토닥토닥 감싸줘요.
23. 내가 혼자 다했다고 자만하지 마요. 우리 함께 한 일이잖아요.
24. 뒤에서 이야기하지 마요. 눈을 맞추며, 이야기해요.
25. 인상 쓰지 마요. 웃어봐요.
26. 정원에 풀 뽑지 마요. 잡초제거는 회사 대표의 몫이에요.
27. 경쟁하지 마요. 서로 협력해요.
28. 식사 거르지 마요. 꼭! 꼭! 챙겨 먹어요.
29. 자신을 한정 짓고 제한하지 마요. 언제나 오픈 마인드!
30. 억지로 하지 마요. 하고 싶은 일을 하며, 가슴 뛰는 삶을 살아요.
31. 사유와 공부를 게을리 말아요. 공동체의 의무에요.
32. 이것이 끝이라고 생각하지 마요. 계속 고민해요.
33. 회사를 위해 희생하지 마요. 당신의 삶이 먼저에요

태그 지정됨 , , , , , , , , ,

Rails AR 속도 테스트

전 포스팅에 이어 각 케이스별 Benchmark 결과 공유해볼까 한다.
Benchmark 사용법 및 자세한 내용은 아래 링크를 확인하시면 된다.
http://www.ruby-doc.org/stdlib-2.0/libdoc/benchmark/rdoc/Benchmark.html

1. 우리가 흔히 사용하는 100% AR을 사용한 경우.
puts Benchmark.measure{User.limit(100000).to_a;nil}
120.070000 1.790000 121.860000 (122.293380)
총 소모된 시간 약 122초

2. 컨넥션만 AR을 이용한 후 row값을 배열로 받는 경우
puts Benchmark.measure{ActiveRecord::Base.connection().select_rows(‘select * from users limit 100000′);nil}
8.110000 1.560000 9.670000 ( 9.995749)
총 소모된 시간 약 10초

3. 컨넥션만 AR을 이용한 후 row값을 해쉬로 받는 경우 (mysql2만 사용한것과 같은 리턴 타입)
puts Benchmark.measure{ActiveRecord::Base.connection().select(‘select * from users limit 100000′);nil}
8.790000 1.320000 10.110000 ( 10.415056)
총 소모된 시간 약 10초

4. 컨넥션만 AR을 이용한 후 날것(raw)로 받는 경우
Benchmark.measure{ActiveRecord::Base.connection().execute(‘select * from users limit 100000′);nil}
0.160000 0.030000 0.190000 ( 0.501308)
총 소모된 시간 약 0.5초

5. mysql2를 이용한 경우.
puts Benchmark.measure{mysql.query(“select * from users limit 100000″);nil}
0.150000 0.030000 0.180000 ( 0.469528)
총 소모된 시간 약 0.5초

6. mysql2에서 row값을 Array로 받는 경우.
puts Benchmark.measure{mysql.query(“select * from users limit 100000″, as: :array).to_a;nil}
0.140000 0.020000 0.160000 ( 0.474315)
총 소모된 시간 약 0.5초

7. mysql2에서 결과값을 Array로 변환한 경우.
puts Benchmark.measure{mysql.query(“select * from users limit 100000″).to_a;nil}
27.890000 3.050000 30.940000 ( 31.259377)
총 소모된 시간 약 31초

같은 결과값 타입끼리 비교를 해보면

결과값 타입 AR mysql
배열 2. 컨넥션만 AR을 이용한 후 리턴값을 배열로 받는 경우
약 10초
7. mysql2에서 타입을 Array로 요청한 경우.
약 0.5초
해쉬 3. 컨넥션만 AR을 이용한 후 리턴값을 해쉬로 받는 경우
약 10초
5. mysql2를 이용한 경우.
약 0.5초

mysql2의 압도적인 승리다.

사실 4.AR이용 날것(raw)과 5.mysql2의 리턴받는 객체는 똑같다.
둘다 Mysql2::Result를 따라간다.
하지만 4번은 Array로 형변환을 하고, 5번은 Hash로 형변환을 한다는 차이점이 있다.
Screen Shot 2013-06-14 at 10.22.25 PM

태그 지정됨 , , , , , , , , ,

Rails의 AR이 대량의 데이터를 읽어올때 생기는 속도 문제.

DB에는 약 500,000개의 rows가 있다.

A액션을 하게되면
DB에 쿼리를 날리게 되고 약 75,000개의 rows가 return된다.
이 데이터를 가지고 알고리즘을 돌리게 되는데
문제는 고작 75,000개의 데이터를 처리하는데 시간이 너무 오래 걸리는 것이다.
약 80초가 걸리는데 이건 뭔가 문제가 있다.
SELECT 쿼리는 최적화가 되어있는 상태로 문제가 없었다.

도대체 어디서 이렇게 시간을 많이 잡아먹나 확인을 해보니
DB에 쿼리를 날리고 난 후 알고리즘 들어가기 전까지가 엄청나게 많은 시간을 잡아먹는 것이었다.

ActiveRecord가 DB 결과값을 변환하는데 걸린 시간: 약 75초 알고리즘 로직이 돌아간 시간: 약 3.4초

ActiveRecord가 DB 결과값을 변환하는데 걸린 시간: 약 75초
알고리즘 로직이 돌아간 시간: 약 3.4초
총 연산시간: 약 80초

쿼리도 문제없고, 알고리즘도 문제없다.
하지만 둘 사이에 알 수 없는 작업으로 시간이 오래 걸린다면..
의심해볼 건 ORM.. 바로 ActiveRecord(이하 AR)

그래서 과감하게 AR을 버리고 mysql2(gem)만 이용하도록 수정을 했다. (mysql2… mysql을 사용하면 필수적으로 설치하는 그 gem 맞다.)
그랬더니 시간이 급속적으로 향상되었다.

DB 결과값을 변환하는데 걸린 시간: 약 0.3초
알고리즘 로직이 돌아간 시간: 약 0.7초
총 연산시간: 약 1.1초

80초에서 1초로 줄었. 응?
눈을 비비고 다시 한번 확인.
혹시나 싶어서 여러번 A액션 재실행.
헐.. 대박 ㅋㅋ
말도 안되는 성과 도출!
쩔어 쩔어

여기서 주목할 점은 알고리즘부분까지 소모시간이 줄었다는 것이다.
이것 또한 같은 이유로 인함인데
여기서 AR의 동작원리라고 하기엔 좀 거창하지만를 이해할 필요가 있는데
mysql2은 결과값을 해쉬(Hash)로 보관하게 되는데
(엄밀히 따지면 Mysql2::Result에 Hash형태로 각 row가 보관이 된다.)
사실 AR도 mysql2를 이용해서 넘겨받은 해쉬를 AR(데이터 타입)로 변환하게 된다.
알다시피 AR(데이터 타입)에는 각종 모듈 및 헬퍼등 살이 디룩디룩 찌고 다리가 4개인 우르곳이라면
반면 해쉬는 Ruby Core lib 모듈 포함된 녀석으로 아주 앙상하게 마른 뼈밖에 없는 피들스틱이랄까?
(Rails에서 사용하는 해쉬는 포식시켜 스택이 3정도 쌓은 초가스랄까? 뭐래는겨 ㅋㅋㅋ)

결론
결국 AR이 무겁고, 이렇게 무거운 AR을 사용하기 때문에 생기는 이슈인 것이다.
그렇다고 AR이 나쁘다! 구리다! 하자다! 라고 하기엔 어폐가 있다.
Rails는 웹 개발 프래임웍이다. 웹 개발이 목적이고 이를 위해 만들어진 ORM이 AR이다.
이런 AR에게 데이타를 몇 만건씩 가져오는걸 기대하는것 자체가 문제가 있다.
보편적인 웹 서비스에선 몇 만건씩 데이터를 가져오는 일 따위는 일어나지 않을것이니

그러므로 배치성 작업 혹은 많은 량의 데이트를 컨트롤해야 하는 경우에
Rails가 필요 없다면 그냥 Ruby로만 짜는것이 좋고,
Rails를 써야만 한다면 AR사용은 고민해볼 필요가 있다.

덤.
3,500개의 rows를 AR이 변환하는데 걸리는데 1.8초정도 소모가 되었다.
고작 3,500개밖에 안되는데도 약 2초가 소모된다.
소량의 작업에선 속도가 문제가 안되지만..
1,000건이 넘어갈 경우에는 꼭 테스트를 해보길 권장한다.

+ 추가
아직 확인은 못해봤지만.. Sangmin Ryu님의 실서비스 테스트 결과를 보면 속도가 느리지 않다
물런 하드웨어 스펙이 차이가 좀 많이 나는것 같지만.. ㅋㅋ 그걸로 설명하기엔 속도차가 너무 크다.
모델의 덩치와도 관계가 있다고 추측된다.
일단 해당 이슈가 발생한 모델의 필드가 약 50개이고 그 중 10개는 text이다.
뿐만 아니라 메소드 또한 많은데 이 모델의 소스 코드가 약 600줄정도 된다.

AR이 해야할 작업이 많아져서 속도가 느려졌던걸로 판단된다.

+ 추가
AR 속도 테스트

태그 지정됨 , , , , , ,

지난주 헬스장에서 있었던 소소한 에피소드

내가 다니기 시작한 헬스장에는 샌드백이 하나 있어.

사실 이 샌드백 때문에 여기 다니는건데..
트레이너에게 물어보니,
샌드백치면 시끄러우니 사람들 없을때 치라고 말은 하는데, 치지 말라는 눈치

그러다.. 지난주 저녁 개인운동할려고 갔는데..
샌드백이 너무 치고 싶은거야.
그래서 다른 트레이너(알고보니 사장)에게
“지금 이 정도면 손님 없는거냐?, 사실 내가 샌드백을 치고 싶어서 말이야”
했더니 흔쾌히 치라고 한다. 오히려 좀 치라고 한다.
샌드백 치면 그 파이팅(?)이 우리한테도 전해져서 더 열심히 운동하게 된다고 ㅋㅋ

(에피소드는 여기서 끝이 아니고, 이제 시작.)

그러면서 운동하는 한 남자를 가르키며,
“이 친구 발차기가 끝내준다”며 계속 발차기 시범 보여달라고 부추기는거야.

그래서 난 속으로.. 아 태권도 좀 했나보구나. 생각했지.
근데 강력한 로우킥을 선보이더라고.

그래서 난 반가운 마음에 웃으면서
“운동하셨었어요~?”
라고 물어봤는데..
들은척도 안 하고, 트레이너들이랑 웃으며 담소를 나누더군 -ㅅ-;

췟..

안그래도 오랜 만에 샌드백 치는거라.. 자신감 결여되어 있는데..
앞서 시범(?)을 보인 사람이 너무 잘했고, 무시당하기까지 하는 2연타 콤보를 먹으니..
샌드백 칠 용기가 안났지만..
주위 눈치가 “빨리 쳐봐, 구경좀 하자” 이런 느낌? 물런 대놓고 그런건 아니지만..
사실 자격지심일 수 도 있이 ㅋㅋ

암튼 용기내어 로우킥을 넣었는데..
헐.. 대박
샌드백은 가만이 있고. 내 몸이 휘청하더라고..
완전 창피 ㅠ,.ㅠ

그만할까란 생각도 들었지만, 어차피 창피해진거 그냥 하자~ 하며
조금씩 두드렸지.

그러다.. 조금씩 감을 찾고.. 리듬을 조금씩 타면서 샌드백을 패고 있었는데..
사장이 오더니, 저기 글러브 있으니깐 끼고 치라는거야.
그래서 글러브끼고.. 너클과 손목 걱정없이 마음껏 패고 있었지.

그랬더니 아까 날 무시했던 청년이 힐끔힐끔 날 보는거야. ㅋㅋ
그러다 리듬을 어느 정도 되찾았을 때즘 마음먹고 콤비네이션 날리고 훅으로 마무리했는데..
샌드백이 아까 이 청년이 로우킥한 것만큼 날라가는거야..
사실 한참 운동할때는 늘 그래와서 난 새롭지 않았는데
이 청년한테는 신선했나봐.
입을 벌리고 샌드백을 쳐다보고 있더라고
ㅋㅋㅋㅋㅋ

그러다 나중에는 옆에 앉아서 날 보고 있더라고.
왠지 날 기다리는 눈치인 것 같아 잠깐 멈췄더니
내게 먼저 말을 걸더라고.
“운동하셨었어요~?, 타격이 틀리시네요”

ㅋㅋㅋㅋㅋㅋㅋ

불과 몇 분전 내가 했던 말을.. 그대로 돌려들은거지..
좀 짜릿했어 ㅋㅋㅋ

기획자님. 복잡한 기능 요구시 최소한의 테스트 케이스는 작성해주세요

기획자가 복잡한 기능을 글(혹은 문서)로 써왔다.
근데 이 기능을 수식화(알고리즘) 하는 작업은.. 개발자가 해야하는 걸까? 기획자가 해야하는 걸까?

당연히 개발자가 수식화하겠지?
그럼 개발자가 수식화해서 코딩을 했다치자.

실제로 제대로된 결과값이 나오는걸 기획자가 검증할 수 있을까?
결과값이 ‘모’아니면 ‘도’처럼 제한되어 있다면 쉽게 검증하겠지만..
파라미터가 여러개고, 결과값 또한 여러 가지라면?

개발자가 테스트 코드를 작성했다고 하지만,
그건 개발자가 만든 것이다보니 기획자의 의도가 투영이 안되었을 수도 있다.

파라미터 A가 ’1′이고, 파라미터 B가 ‘철수’면
기획자의 의도대로는 ‘꺄~~~ 조인성!!’이 나와야 하지만
실제 작성된 코드로는 ‘송혜교 겁나 이뿌다’가 나올 수도 있다는 얘기.

그 겨울 바람이 분다. 조인성

결국은 기획자가 QA를 해야하는데, 그럼 수식은 기획자가 짜야하는걸까?
그건 아니다.

이때까지(고작 11년 밖에 안되는 짧은 시간이지만) 경험에 비추어 보면,
대부분의 경우 기획자는 그냥 툭 던지고 가버린다.

예를들어 지하철 노선도 프로그램을 만든다고 치자.

기획자는 “‘길찾기’기능 필요해요~”라고 툭 던지고 가고..
개발자는 그냥 열심히 만든다.
열심히..
뚝딱뚝딱..
밤을 새가며
키보드 부셔져라
코딩한다.
그래서 완성했다.

근데 ‘길찾기’ 검증은 어떻게 하지?

‘그걸 기획자가 왜 검증해?’라고 생각했다면
난 되묻고 싶다. ‘당신 기획자 맞습니까?’
제대로 동작하는지 당연히 확인해야지.

소소한것들은 잘도 쪽쪽 찝어서 테스크 생산 해주시는데 (예를들어 버튼이 좌측으로 1px 밀려있다. 응? 이건 디자이넌가? 암튼 뭐 이런것들)
복잡한 기능의 ‘검증’은 그냥 개발자를 믿어버리는(떠밀어버리는)것 같다.
종종 ‘검증’을 아에 잊어버린 것 같다고 느낄 때도 있다.

위에도 썼지만 기능을 기획한 사람이 검증도 할 수 있어야 한다.
옛말에 결자해지라고.. 쿨럭;;

그러므로 ‘이게 좀 복잡한 기능이다~’ 라고 생각이 들면 테스트 케이스를 미리 만드는것이 바람직하다.
만들기 귀찮다고?
그래도 만들어야한다. 우리는 완성도 높은 제품을 만드는 공통 목적을 가진 팀이 아닌가?

개발자 믿는다고?
개발자는 기본적으로 커뮤니케이션 능력이 떨어지는 경우가 많고, 기획서(암호문)를 구독(해독)해서 이해하는 능력도 떨어지는 경우가 많다. (이건에 대해서 별도의 포스팅을 할려고 하는데.. 뭐 봐서)
분명 서로 오해하는 경우가 생긴다.

“개발자를 이해시키면 안되요?” 라고 생각할 수도 있다.
개발자가 이해를 해야 개발에 들어갈 수 있으므로 설명은 당연히 해야하는 것이다.
기획서 휙 떤져주고 가면 안된다.

네비게이션 길찾기 처럼
파라미터와 결과값이 너무 방대한 경우라 하더라도 테스크 케이스는 만드는것이 좋다.
간략하게 본인집과 동사무소가는길, 본인집과 시골집가는길 등등으로 말이다.

만약 테스트 케이스 만들기가 너무 막막하다면
개발자에게 도움을 요청해서 함께 만들어 보는것도 괜찮은 방법이다.

개발시 테스트 케이스가 있다면
개발자는 불안감 없이 개발할 수 있고(검증을 믿을 수 있으니깐)
기획자 또한 빠른 시일내에 제대로 된 프로그램을 받아볼 수 있게 될 것이다.

가장 중요한 것은, 검증은 기획자만 하는게 아니다.
기획자, 디자이너, 개발자 등 팀원 모두가 함께 해야하는 것이다.
소소한 것부터 복잡한 기능까지 모두 함께 하는 것이다.
우리는 완성도 높은 제품을 만드는 공통 목적을 가진 팀이고 거기서 보람을 느끼는 족속들이기 때문이다.

“팀웍이라는게 뭐야?
그저 도와주고, 막아주고 그런걸로 되는거야?”

“그렇게 생각하는 녀석들도 있겠지만 말야,
나에겐 입에 발린 말이라는 생각밖에 안들어.

각자가 자신이 할 수 있는 일을 죽을 각오로 한 뒤에,
‘난 다했다. 다음은 네 차례다. 못하면 죽여버릴거야!’
라고 말할 정도의 기합이 있고서야 비로써 팀웍이라는게 형성되는게 아닐까?

그렇게 생각하면 우리는 각자 한 마리의 외로운 늑대들이라고 해도 괜찮지 않을까?”

- 원피스, 조로와 쵸파의 대화 中

태그 지정됨 , , , , , , ,
팔로우

모든 새 글을 수신함으로 전달 받으세요.

%d bloggers like this: