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

존경하는 백준이형이 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 밀려있다. 응? 이건 디자이넌가? 암튼 뭐 이런것들)
복잡한 기능의 ‘검증’은 그냥 개발자를 믿어버리는(떠밀어버리는)것 같다.
종종 ‘검증’을 아에 잊어버린 것 같다고 느낄 때도 있다.

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

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

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

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

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

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

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

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

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

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

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

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

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

Javascript로 링크 및 AJAX구현시 Fallback Link를 제공해야 하는 이유

f1e4ccf2bb4122e22aba7f35653d5494

Javascript로 행해지는 Action의 결과물이 서버(Server)로 요청(Request)하는 행위라면 Fallback Link를 함께 제공해주는것이 안전하다.

서버로 요청한다는것은, 단순히 UI를 위한 스크립트가 아니라는 말이다.
즉 페이지 이동 하거나, 값을 전송하기 위함인데
필자는 단순히 UI변경하는것보다, 서버로 값을 전송하는게 더 비중있는 일이라고 생각한다.
그 이유는 대다수의 경우 서버로 값을 전송하는것이 Action의 Goal인 경우가 많기 때문이다.
그러므로 난 Fallback Link를 제공해야 한다고 주장하는 것이다.

예를들어
로그인 버튼을 누를시 Javascript를 이용해 서버에 값을 전송하는 환경이라고 하자.
근데 어떠한 이유에 의해서 Javascript가 동작을 안한다면
이 유저는 로그인을 할 수 없게 되는것이다.

자, 그럼 Fallback Link는 무엇이냐?
아주 간단하다. javascript로 동작하는 a태그의 href에 유효한 url을 입력하는 것이다.
그러므로 Click 이벤트가 일어나는 모든것은 Clickable한 객체로 마크업을 하는것이 바람직하다.

Fallback Link는 언제 동작하는것이냐?
이것 또한 간단하다. Javascript가 동작하지 않는 상황을 대비하는것이다.

근데 솔직히 말하면 브라우저가 자바스크립트를 지원하지 않아서, 자바스크립트가 미구동되는 경우는 거의 없다.
하지만 자바스크립트 문법 에러가 나서 동작하지 않는 경우는 꽤 있으므로, 이에 대한 대비로 봐도 된다.
뭐 사실 갖다붙이면 여러가지 이유가 있겠지만..
결론적으로 말하면 자바스크립트 미구동에 대비하는걸로 인해 생기는 부수적인 효과들이다.

돌아와서 Fallback Link제공의 간단한 예를들면

<a onclick="like('comment', 1)" href="#">Like</a>

이렇게 된걸 아래와 같이 수정하는것이다.

<a href="/like" data-action="like" data-content-type="comment" data-content-id="1">Lik</a>

$("a[data-action='like']").click(function(e) {
    # do something
});

단순히 Fallback url을 제공했다고 끝나는게 아닌다.
해당 url이 실제로 동작을 해야 한다.

서버단에서 요청된 Header정보를 보고 Ajax인지 아닌지 판단하고,
여부에 따라서 응답을 달리 해주는 작업을 해줘야 한다.

무슨말인고하니,
보통의 경우 Ajax 응답만 작업했을것이고, 해당 코드는 아래와 같을것이다.

$("a[data-action='like'][data-content-type='comment'][data-content-id='1']").addClass("selected")

하지만, url을 타고 요청이 왔을 경우 유저는 하얀 화면 혹은 위 JS코드가 출력된(?) 화면을 보게 될 것이다.
이럴경우를 대비해야 한다는것이다.

기획단에서 어떤 페이지로 렌딩(Landing)할 것 인지, 먼저 정한 다음
해당 페이지를 렌더링(Rendering) 혹은 리다이렉트(ReDirect)해주면 된다.

Rails에서는 그냥 몇글자 추가해주면 되지만..
보편적인(?) PHP로 예를들면

if(!empty($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') {
    // Ajax Process
}
else {
    // Page Redirect
}

이 정도?
PHP 코드 출처: http://davidwalsh.name/detect-ajax

사실 이런 내용은
Graceful Degradation, Unobtrusive Javascript
같은 방법론들이 얘기하는것과 일맥상통하기도 한다.

개발자에게 이런 질문(부탁) 하지마! 제발! 쫌!

본 포스팅은
반말로 작성되어 있습니다.
그리고 개발자 입장으로 편중된 글로 다소 싸가지없게공격적입니다.
그렇다고 맹목적으로 기획자와 디자이너를 까고자 하는 글은 아닙니다.
이 글의 쓴 의도는 기획자와 디자이너가 개발자를 이해하게 되고, 결론적으로 더 완성도 높은 프로덕트를 낼 수 있는데 도움이 되었으면 하는 마음에 쓴 글입니다.

서비스 오픈 할려는데 서버 구축 비용 얼마나 들어?


우녀: 이게 CPU에요?
중남: ㅋㅋㅋ
좌남: 뭐?
출처: http://article.joinsmsn.com/news/article/article.asp?total_id=3436698&cloc=

그럼 난 되묻고 싶다.

  • 평균적으로 한 페이지당 트래픽 얼마나 소모되?
  • 예상하는 UV는?

이 질문에 답할 수 없어?
그럼 그 만큼 서비스 준비를 안 했다는 반증이야.

시장 예측도 안 하고 무슨 서비스를 오픈해.
“일단 오픈부터 하고 보자”라고?
그래 린(lean)하게 가는건 좋아. 근데 이건 린하게 하는게 아니야.

서비스를 빨리 오픈하고자 하는 성급함 때문에
마땅히 준비해야 할 걸 준비 안한거야.

예상 유저수와 백단(서버)에서 어떤 프로세스가 돌아가는지 알아야
서버 스펙과 라인(트래픽)을 정하지.
그냥 서버 나와라 뚝딱 하면, 뚝딱 나오는거 같지? ㅋㅋ

위 질문은 마치 가정주부한테
“상하수도 공사하는데 비용 얼마나 들어?”
라고 밑도 끝도 없이 앞뒤 다 짤라먹고 질문하는거나 마찬가지야.
아니 가정주부가 그런걸 어떻게 알어 -_-;

얘기가 산으로 갔는데 돌아와서..

일단 개발자는 서버구축을 하는 사람이 아냐.
서버구축을 하는 분들이 있어. 우리는 이들을 SE라고 불러.

규모가 작은 회사는 어쩔 수 없이 개발자가 서버 구축도 하겠지만.
우리가 흔히 말하는 개발자의 일은 “소프트웨어 개발”이야.
그런 개발자에게 서버 구축 비용에 대해 물어본다?
근데 트래픽에 대한 준비도 안되어 있다?

그렇다면 이 질문을 한 기획자는 제대로 된 기획자가 아냐.
개발자가 무슨 일 하는지도 모르는데.. 그게 기획자야?
아 그래 그래. 개발자랑 친해서 그냥 참고나 할려고 물어본 거라고?

근데 말이야. 내가 위에 적은 2가지 질문있지.
그거에 대해서 스스로 답할 수 있다면 말이야.
그냥 본인이 직접 호스팅업체 홈페이지가서 견적 뽑아봐.
홈페이지 가면 다 나와있어. 괜히 개발자 괴롭히지 말고 말이야.
확실하게 알고 싶으면 홈페이지 잘 찾아보면 전화번호나 메일 주소가 있거든.
거기에다가 위에 적은 항목들을 말해주면, 그 쪽에서 스펙이랑 라인은 알아서 추천해줌과 동시에 비용도 알려줄꺼야.

사실 우리들도 위 적은 정보들을 이용해서 각 업체 홈페이지들에 접속해서 알아보는거야.

프린터(인터넷)가 안되는데 어떻게 해?

아직까지 이런 기획자, 디자이너 심지어 개발자중에도 있더라.
개발자가 프린터 AS기사님이니?

토너(잉크)가 떨어졌는지, 용지가 떨어졌는지, 종이가 씹혔느지
직접 확인해봐. 그리고 직접 해결해볼려고 좀 해봐.

프린터가 안 잡혀?
프린터 제조사 홈페이지 가면 Driver있거든? 그거 다운받고 설치해

지들은 왕족이고, 개발자는 무슨 하인이냐?
문제만 생기면 다 개발자한테 부탁해.
개발은 언제 하라고?

본인들이 알아서 문제 해결할려고 노력이라도 해봐.
해보고 해보고 해봐도 안되면 그때 도움 요청해.
그리고 도움 요청할때 그냥 도와줘요! 하지 말고.

  • 어떻게 했더니 문제가 생겼다
  • 이러이러한 시도들을 했다
  • 원인은 xx인거 같다.

등등의 정보를 알려줘.
그래야 개발자든 아니든 도움을 받은 사람이 “아 이사람이 이 문제를 해결할려고 노력했구나”라고 생각하고 도와주고, 똑같은 작업 두번 반복 안 하게 되자나.

아.. 이렇게 반문하는 사람이 있을꺼야.
“쉽게 빨리 해결해 줄 수 있는 사람이 있는데, 그 사람한테 부탁해서 빨리 해결하는게 좋지 않냐? 그래야 시간도 아끼고”
그래.. 너의 시간은 소중하고 남의 시간은 안소중하냐?

개발자들은 몰입해서 코딩을 하는데..
하찮은 부탁 때문에 몰입이 깨지고,
그로인해 스트레스 받고,
짜증나지만 이런걸로 짜증내면 속좁은 사람으로 보일까봐 짜증도 못내고..
기껏 해결해줬더니, 또 다른거 해결해 달라고 하질 않나,
고맙다는 말이라도 들을 수 있을라나,
그렇게 더러운 기분으로 일할려고 자리에 앉으면 바로 일이 되겠니?
더군다가 다시 몰입하는게 쉬운 일도 아냐.

가장 지혜로운 해결책은, 각 회사마다 각종 기자재 관리하는 팀이 있을꺼야.
예를들면 총무팀? 이런곳에 문의해.
작은 회사라서 그런거 없다고? 그럼 본인이 해결할려고 노력 좀 해줬으면 좋겠어.

무능한 개발자로 만드는 질문들.

1_(2)

기술에 대한 이해도가 전혀 없이 질문을 하는 경우가 더러 있어.
그럼 개발자들은 대부분 짜증썩인 부정적 대답을 할 수밖에 없다~

“그거 못해요”, “못만들어요” 라는 말만 하게 되기 때문에
개발자의 자존감도 낮아지고.. 주변의 눈치를 보게 되.
무능한 개발자로 낙인 찍히면 누가 좋아하겠어?

“저 개발자한테 물어보면 맨날 안된데, 실력이 떨어지는거 아냐?”
이런 소문 돌까봐 속으로는 끙끙거릴 수도 있다는 말이야.

하지만 우리같이 순진한(?) 엔지니어들은
“기술에 대한 이해도 없이.. 터무니 없는걸 가져와서 만들어 달라고 하는거야!!”
라고 윽박지르거나 자신의 입장을 피력하지 못하는 경우가 대다수야.
왜냐고? 위에 적었자나.. 멍청순진해서 그래 ㅋㅋ

암튼 이런식으로 서로에 대한 감정의 골만 깊어지게 되면
결국 크게 한번 터져 걷잡을 수 없는 파국으로 치닫고 둘은 결혼해서 행복하게 살았습니다.
응? 뭐 암튼 그렇다는거야. 요지는 알겠지?

사람마다 다르겠지만 대다수의 개발자가 그래.
못믿겠다고? 그럼 이때까지 일한 개발자들을 떠올리며 생각해봐.
곰곰히 생각해봤는데 아냐? 그럼 우수한 개발자와 일하고 있는거야.
감사의 마음을 담아서 커피나 한잔 사줘봐봐 ㅋ
개발자들은 대다수 공돌이들이라 커뮤니케이션 능력이 딸리거든
당신은 축복받은거야.

결론은.
기획 및 디자이너들이여 제발 기술에 대해 이해를 하고 기획하고 그림을 그려라!

최소한의 기술은 좀 익히자.

응?

그래. 얘기 나온 김에 좀 더 해보자.
한 자동차 디자이너가 있어.
이 디자이너가 겁니 예술적으로 쌈빡하게 차를 디자인 했어.

그런데 이 사람의 디자인대로 차를 만들면..
엔진 놓을 곳이 없고, 사람은 운전자 한명도 간신히 타며, 에어로다이네믹은 전혀 고려가 안된 차량이 된다면…
이 사람을 디자이너라고 할 수 있을까?
그래 예술가라고 할 수 있을지는 몰라도, 산업 디자이너는 절대 아니라고 생각해.

자동차 디자이너가 LSD의 작동원리와 세팅법, 서스펜션의 bar와 스프링 장력의 관계 등등 같은건 몰라도 되.
하지만 자동차를 디자인하기 위해서 최소한으로 알아야 할 것들이 있는것 아니겠어?
예를들면 FF, FR, MR, RR, 쿠페, 세단 뭐 이런거? (주변에 자동차 디자이너가 없어서 적절한 예인지 모르겠지만..)

웹도 마찬가지야. 최소한으로 알아야 할 것들이 있어.

javascript 바라지도 않어.
html, css코드 작성은 아니더라도 원리 정도는 이해해줘.
코드를 읽을 줄 알면 더 좋지만 여기까지도 안바래.(적어도 나의 경우엔 말이지)
inspector같은 툴도 자유자재로 사용할 줄 알고 말이야.

이 정도도 힘들어? 그럼 개발자 그만 괴롭히고 다른 직업 찾아봐줬으면 좋겠어.

사실 이것들 말고도 수없이 많어. 알고 있지? ㅋㅋㅋ
하지만 이 정도만 할께.
뭐 소스들이 계속 모이면 시즌2로 돌아올 수도 있지만, 안그랬으면 좋겠어.

아무튼, 제발 우리한테 이런 무리한 요구는 하지 말아줘!!

우리는 톰 크루즈도 아니고, 톰 크루즈가 되고픈 마음도 없어!