외주로 위치정보를 많이 쓰는 앱의 API 서버를 제작 중이다. 이와 관련해서 요즘 하고 있는 설계 고민들을 적어본다.

데이터베이스 선택

위치정보를 많이 쓴다면 2차원 인덱스를 통해 KNN Query 등의 위치정보 관련 쿼리를 쉽게 할 수 있는 MongoDB가 편하다. 그러니까 MongoDB 하나만 쓰고 RDBMS는 쓰지 말까? 아니면 그냥 Django 모델은 그대로 쓰고, MongoDB는 위치정보 인덱스로만 쓸까? Django 모델의 편리함을 그냥 버리긴 아깝다. 아니면 OpenGIS를 지원하는 PostgreSQL을 쓰면 다 해결되려나? 

고민 끝에 일단 MongoDB를 전면적으로 쓰기로 결정했다. 이미 채팅촌에서 써본 경험이 있었는데 괜찮았고, PostGIS는 사용하기 그리 편하지 않았다. MongoDB를 위치정보 인덱스로만 쓰고 Django 모델을 주로 쓰는 접근법도 해봤는데, 나름 괜찮긴 하지만 조금 더 MongoDB를 깊이 써보고 싶었다.

모델 레이어

MongoDB를 쓰기로 했으니 파이썬에서 어떻게 사용할지를 결정해야 했다. 크게 방법은 세 가지. pymongo를 그대로 쓰는 것, MongoKit, MongoEngine. 셋 다 나쁜 방법은 아니지만, 아무래도 MVC에서 모델 중심으로 가려면 pymongo를 그대로 쓰긴 좀 그렇고 뭔가 wrapping을 하긴 해야 한다. MongoEngine은 저번에 써봤는데, Django model을 닮은 게 그다지 맘에 들진 않았다. MongoDB로 계속 개발을 하려면 아무래도 MongoDB의 쿼리 문법에 익숙해져야 하므로 그걸 그대로 쓰는 게 유익하다. MongoEngine이 Django랑 억지로나마 연동이 되긴 하지만, Admin 연동이 제대로 안되는 이상 별로 큰 이득도 아니다. 그래서 MongoEngine은 시도도 안해보고 MongoKit으로 넘어왔다. 근데 MongoKit도 생각보다 불편하다. 가장 불편한 건 collection을 wrapping해서 관리해주지 않고 들고 다녀야 한다는 것이다. MongoKit에서의 document 생성은 다음처럼 database와 collection을 가져온 다음 거기서 모델 객체를 생성해야 한다.

connection.database.collection.MyDocument()

왜 MyDocument()를 바로 쓰는 걸 지원하지 않는지 이해할 수 없다. database와 collection을 미리 지정해두면 이 둘은 생략할 수 있지만, 그래도 connection에 붙여서 써야 한다. 쿼리도 마찬가지다. 별 거 아닐지 모르지만 그냥 이게 맘에 안 들어서 버리기로 했다. 그래서 그냥 예전에 내가 간단하게 만들어 둔 MongoDB model wrapper를 계속 쓰기로 했다. 이름도 붙였다. MongoDB Model을 줄여서 momo.

스키마 문서화

외주다보니 스키마 문서화가 필요하다. Django 모델로 작성했으면 그냥 django-extensions의 graph_models 써서 다이어그램 넘겨버리면 그만이겠지만, momo는 그런 거 없다. 그리고 MongoDB는 schemaless가 기본이다보니 스키마를 정의하는 일이 부가 작업이 된다. 여기서 고민에 빠졌다. 따로 코드로 스키마를 정의할 필요가 없으니 그냥 수동으로 다이어그램만 그려서 관리할까, 아니면 그래도 스키마가 코드에 정의되는 게 명시성도 좋고 나중에 validation 붙이기도 좋으니 코드에 정의하고 다이어그램은 자동으로 뽑아낼까. 

별도 문서화보다는 아무래도 코드에 정의를 하고 싶다. 코드에 정의를 하면 나도 개발을 하면서 계속 참조할 수 있어 이득을 얻기 때문이다. 사실 클라이언트에서 꼭 다이어그램까지 원하는 것은 아니기 때문에 스키마 정의한 문법을 그대로 보내줘도 될 것 같긴 하다. 다만 조금 세련된 문법이면서, 나중에 programmable하게 처리할 수 있는 구조이기만 하면 될 듯.

스키마를 코드에서 정의한다면 MongoKit을 베낄까, MongoEngine을 베낄까도 고민이다. MongoKit이 간결하고 시각적이지만, MongoEngine은 여러 가지 속성을 줄 수 있어서 확장성이 좋다. 문법 정의할 때 파이썬이 인터프리터 언어라는 점도 은근히 귀찮다. 클래스 정의할 때 자신을 참조하게 만들 수가 없기 때문이다. method 안에서는 참조할 수 있지만 클래스 레벨로 정의할 때는 참조할 수가 없어서 Django 모델도 문자열이나 'Self' 같은 문법을 쓴다. 아직 이 부분은 고민 중.

REST API 프레임워크

일단 django를 쓰긴 할 텐데, REST API는 뭘로 만들까? 이전까지는 그냥 내가 만든 djangox-route를 써서 라우팅만 처리하고, JSONResponse 같은 걸 또 붙여서 대충 썼다. PUT, DELETE 따윈 지원하지 않지만 내 프로젝트라면 아마 또 그렇게 할 듯. 하지만 외주다보니 좀더 제대로(?) 만들어야 하고, 또 좀더 널리 알려진 프레임워크를 쓰는 게 좋을 듯 하다. 그래서 django-rest-framework와 tastypie를 비교하기 시작했다.

둘다 예제가 너무 Django model 연동 중심으로 되어 있다. 하지만 난 Django 모델을 안 쓰기로 한지라, 별로 도움이 안된다. 모델을 바꿔 끼우려고 해보니 tastypie는 상속해야 하는 메서드들이 좀 이상하다. get_object_list와 obj_get_list라는 어이 없는 네이밍을 해놨다. 확장하려고 문서를 찾아보니 문서도 좀 부실하다. 그래서 잠깐 django-rest-framework 문서를 더 보는데, 일단 문서가 좀더 풍부하고, browsable api가 있어서 이게 더 편할 것 같았다. View와 Serializer를 API마다 세트로 작성해야하는 것처럼 보여서 조금 꺼려지긴 했지만, 아마도 Serializer는 어떻게든 하나로 할 수 있는 방법이 있겠지. 그래서 일단 django-rest-framework로 왔다. 생각보다 쉽게 연동이 되서 Browserable API에서 JSON으로 POST하고 조회하고 하는 건 잘 된다. 일단 API 작성까지는 이게 괜찮은 것 같다.

그런데 또 하나 중요한 건 API 문서화다. 요즘 REST API는 executable documentation이 대세가 되어가고 있고, django-rest-framework의 Browsable API도 그걸 지원한다. 그런데, 이게 좀 제한적이다. 문서화 기능도 적고, list에 GET 요청을 할 때 파라미터를 줄 수 있는 UI는 없는 것 같아보인다. POST야 그냥 JSON으로만 해도 되서 별 상관은 없지만 필터링 파라미터는 필요한데 아직 어떻게 하는지 모르겠다.

그래서 documenting-your-api라는 문서를 봤더니 자체 Browsable API의 문서화보다 오히려 django-rest-swagger를 추천한다. 이건 swagger integration인데, 이것도 생각보다 쉽게 붙었다. 그런데, 클래스 레벨의 docstring만 파라미터 인식을 하고, 메서드 레벨로는 안되는 것 같다. 한글도 문제가 있는지 에러를 낸다. 하지만, 일단 UI 자체에는 필요한 기능이 다 담겨 있는 것 같다. 일단은 이걸로 좀더 파볼 듯. 처음 원했던 것처럼 손 안대고 코 푸는 건 아직 안되는 것 같다.

블로그 / 소프트웨어 개발

요즘 일자리 제안을 받다가 거절하게 되면 꼭 그 뒤로, 구인을 어떻게 하면 좋겠냐는 질문이 이어진다. 그럼 나도 내 딴에 구인 방법에 대한 조언을 이것저것 해준다. 개발자 채용 같은 글도 쓴 바 있고, 나도 구인이라는 과정의 양쪽 입장을 다 꽤 여러 번 겪어봤기 때문에 해줄 수 있는 말이 그래도 좀 있다. 그런데, 요즘 들어 내가 조언해주기 힘든 상황들이 종종 생긴다. 그건 IT가 핵심이 아닌 기업에서 프로그래밍을 이끌어줄 리더를 뽑는 경우다. 나야 뭐 그런 거 상관 안하는 타입이고, 그냥 한국 회사 부적응자라서 취직 안하는 거지만, 나 같은 사람이 오히려 드물고, 대부분의 실력자들은 IT가 중심이 되거나, 혹은 중요한 드라이브가 될 수 있는 일을 원한다. 그러다보니 좋은 사람 뽑으려면 어떻게 해야 하는가에 적절한 조언을 해주기가 어렵다.

그런 분야들은 실제로 실력자들이 거의 가지 않기 때문에 소프트웨어의 품질 수준도 낮은 경우가 많다. 결함률에 있어서는 무한 테스트(?)를 거치기 때문에 오히려 좋은 경우도 있지만, 사용성이라든가, 성능, 확장성 등등이 떨어져서 10년이 넘은 소프트웨어를 그대로 쓰는데, 고칠 수도 없는 상황이 된 경우도 흔하다.

하지만, 그렇다고 포기할 것인가. 그런 회사들도 좋은 개발자를 뽑아야 하지 않겠는가. 나는 IT 회사를 만들 것이지만, 난 우리 회사의 프로그래머 이외의 직군도 모두 최고의 인재로 채워졌으면 좋겠고, 그건 아마 비 IT 회사도 마찬가지일 것이다. 

이런 회사들은 어떤 구인 전략을 취할 수 있을까? 간혹 돈으로 지르는 경우도 보는데, 어느 정도는 효과가 있는 것처럼 보이지만, 충분한 수준은 아닌 것 같다. 아, 물론 돈마저 지르지 않으면 가능성이 아예 없는 것 같긴 하다.

한 가지 금방 떠오르는 건 개발팀 리더에게 높은 의사결정권을 주는 것이다. 개발팀을 알아서 꾸릴 수 있게 하고, 기술 선택 등등 다 자유롭게 하면, 리더급 중에는 그런 재미에 이끌리는 사람이 많을 것이다.

기업 문화도 도움이 될 수 있다. 이를테면 내가 지향하는 실무자 중심주의. 이런 회사들이 어렵게 구한 개발자가 자기들 맘에 안 들면 흔히 "너라도 나가면 안되니까 맞춰주기는 하지만 존나 짜증나" 같은 태도를 보인다. 이런 수준이 아니라 정말로 실무자의 판단을 존중하고, 실무자를 성의있게 설득해나가는 자세가 되어 있는 경영자가 있다면 플러스 요인이 될 수 있을 것이다.

하지만 무엇보다 중요한 건 기술적인 도전 과제가 있느냐가 아닐까 싶다. 해당 기업에서 기술적인 성취를 이루어내고, 또 그 성취를 커뮤니티에 공유할 수 있다면, IT가 중심이냐 아니냐는 아마도 개발자에게 그리 중요한 문제가 아닐지도 모른다. 뛰어난 개발자는 도전 과제를 만날 때 기뻐하고, 과제를 극복해낼 때 성취감을 느끼는 법이니까. 

요컨데, IT 기업 평균보다 높은 급여 + 자율성 + 실무자 중심주의 + 기술적인 도전 과제. 이 정도가 내가 생각하는 답인데, 여전히 부족해보인다.

그래서 이 문서는 일단 미결로 남기며, 답을 구할 때마다 고쳐나갈 예정.

----

블로그 / 소프트웨어 개발

몸값 안 올리기를 처음 읽고 딱 든 생각은, 어, 이거 내 얘기네였다. 작년에 난 이콜레모를 그만두고 카카오에 입사했다가 다시 그만두고 이콜레모로 복귀했다가 또 요기요에서 제의를 받아 요기요에 입사했다. 카카오에 입사한 것은 물론 돈 보다도 기회라는 관점이 더 컸지만, 어쨋든 돈도 중요한 이유였고, 요기요에 입사한 이유는 80%쯤이 돈이다. 그래서 어쨋든 몸값을 좀 올린 셈인데, 그로 인해서 난 일에서의 행복을 상당부분 잃었다. 이콜레모를 할 때도 물론 스트레스 받는 일이 많았고, 업무 강도도 높은 경우가 많았지만 일 자체는 몹시 재미있었고, 대부분의 시간을 행복감을 느끼면서 일했다. 하지만, 카카오에서 일했던 4개월, 그리고 지금 요기요에서의 2개월은 회사에서의 스트레스를 집에까지 가져오고 있다. 카카오를 그만두었던 가장 큰 이유도 회사에서의 스트레스를 계속 집에 가져오다보니 만삭의 아내와 아기에게 나쁜 영향을 미칠 것 같아서였을 정도니까.

사실 내가 그냥 직원으로 일하는 것 자체에서 즐거움을 못 느끼느냐 하면 그런 건 아니었다. 내가 가장 재미있게 일했던 순간을 꼽으라면 NHN에서 창희형, 정환이형과 함께 일했던 시기, 그리고 오픈마루에서 권남님과 일했던 시기를 꼽곤 한다. 이콜레모에서 일할 때만큼은 아니지만, 매일매일 재미있는 일이 가득했다. 물론 그 땐 연봉이 낮았지. 그래서, 몸값 안 올리기의 내용이 내가 겪는 현상에 대한 적절한 분석인 것처럼 보인다.

하 지만, 그럼에도 불구하고 이의를 제기하고 싶은 부분이 몇 가지가 있다. 우선, 많은 사람들이 지적하는 숫자. 현장에는 안 갔기 때문에 모르고, 기사로 먼저 떴던 것에는 4500만원, 그리고 블로그에는 5만~7만5천불로 기술되어 있는데, 이것 때문에 상당한 비판이 나왔다. 그런데, 사실 이건 김창준씨가 제시한 숫자가 아니라 다른 연구 결과를 인용한 것이기 때문에 이걸 가지고 글에 대한 비난을 하는 것은 적절하지 않다. 다만, 내가 아쉽게 느끼는 것은, 그 숫자가 한계효용이 체감하기 시작하는 지점인지, 한계효용이 0에 가까워져 총효용의 증가가 없는 지점인지가 명확하게 명시되지 않았다는 것이다. 다음 부분을 보면 총효용 자체의 증가가 멈추는 지점인 것처럼 보인다.

그 뿐만 아니라 몸 값이 일정 숫자 이상 오르면 더 이상 행복이 유의미하게 늘지 않는다는 연구 결과[3]도 있습니다. 연구에 따라 다르기는 한데, 5만불에서 7.5만불 사이로 볼 수 있습니다.

하 지만 5~7.5만이란 숫자는 한계효용이 0이 되는 지점으로 보이진 않는다. 저 정도면 기본적인 욕구들이 어느 정도 충족되는 시점이니 한계효용이 체감하기 시작하는 지점이 아닐까 싶다. 물론 연구의 기준에 따라 다르고 저는 그 연구를 모르지만, 보통 사람들이 느끼기에 충분한 금액은 결코 아니니 비난에 휩싸일 수 밖에. 만약 그 연구가 한계효용이 체감하는 지점을 말한 거였다면 단순히 그걸 명확히 하는 것만으로도 비난이 많이 줄지 않았을까 싶다. 아, 물론 그 연구가 실제로 한계효용이 0인 지점이라는 얘기였으면 더 심한 비난을 받았을 수도...

여튼, 이게 첫번째 아쉬움이었고, 두번째 아쉬운 점은, 실제로 연봉을 잘 주는 회사가 더 좋은 회사일 가능성이 높다는 점을 간과했다는 것이다. 아, 물론 여기에 대한 데이터는 갖고 있지 않지만, 대체로 다들 비슷하게 느끼는 것 같다. 연봉이라는 게 회사가 직원을 생각하는 마음이기도 하니, 연봉을 많이 주는 회사는 다른 점에서도 직원에 대한 배려가 더 많은 게 보통이다. 내가 카카오와 요기요 모두 행복하지 않게 일했다고는 하나, 객관적으로 따져서 여기보다 좋은 회사는 한국에 별로 없을 거다. 당연히 그 이하의 보수를 제시했던 곳에 안 간 아쉬움 같은 건 손톱 만큼도 느끼지 않는다. 어차피 오너십을 공유하지 않고 직원으로 일하는 이상 근원적인 차이는 없다고 보면 연봉이 좋은 곳이 대체로 다른 것들도 좋다. 그래서 여전히 연봉 많이 주는 곳으로 이직하는 것은 현명한 선택이다.

세번째 아쉬움도 비슷한 맥락인데, 나도 기본적으로 성공해야 행복한 게 아니라 행복해야 성공한다는 관점에 동의한다. 하지만 그게 월급쟁이일 때는 아니다. 어떻게 보면 이것도 기본적 귀인오류일 수 있다고 본다. 성공이라는 건 개인의 역량도 중요하지만 그에 못지 않게 좋은 기회라는 게 필요하다. 그런데 그냥 월급쟁이로 변변치 않은 회사에 다니면 그 안에서 행복하게 일한다 해도 성공으로 이어질 가능성은 희박하다. 그보다 잘 나가는 회사에 들어갔을 때 성공에 올라타는 것이 훨씬 확률이 높을 것이다. 자신이 스스로 기회를 만들 수 있는 일, 그러니까 창업을 한다거나, 스타트업에 합류한다거나, 주식 투자를 열심히 한다거나 하는 일이라면 개인의 역량이 조금 더 중요하겠지만, 월급쟁이는 어떤 기회를 맞느냐가 더 결정적이고, 기회를 잘 찾아서 올라타는 것도 중요하다. 그런 면에서 적절한 이직 역시 중요하다.

물론 폭넓은 모집단으로 통계를 내면 경향성이 발견될 것이다. 이를테면 1만명 쯤 조사를 하면 그 중에 행복하게 일하는 사람이 아닌 사람보다 평균적으로 더 높은 성공을 거뒀을 것이다. 그런데, 내 옆에 성공한 월급쟁이 친구는 행복하게 일한 친구이기보다는 운 좋게 기회를 잡은 친구일 것이다. 이른바, 빌 게이츠가 선술집에 들어가면 선술집에 있는 사람들의 평균 연봉이 대폭 오르는 효과다.

그래서 행복이 일반적으로 성공에 선행한다고 말하는 것이 옳은 이야기이긴 하지만, 월급쟁이인 나한테 딱히 도움이 되는 이야기는 아닐 수 있다는 것이다.

네번째로, 인생의 행복은 일 바깥에도 있다. 수입이 늘어서 설령 회사에서 좀 행복이 줄었다고 해도 가족과의 삶에서 행복이 는다면 그 총합은 어떻게 되는 것일까? 언젠가 트위터에서 누군가 이런 말을 한 적이 있다.

연봉이 두 배 오르면 두 배 행복해질 것 같죠? 그렇지 않습니다. 열 배쯤 행복해집니다.

빌어먹을 트위터는 검색이 잘 안되서 못 찾겠지만, 여튼 대충 저런 글이었고, 난 꽤 공감했다. 물론 이건 아마도 돈이 없을 때도 행복한 사람들 이야기일 거다. 난 선화랑 연애하기 시작하면서 정말 전에 느끼지 못했던 행복감들을 느끼면서 행복의 절정이라고 생각했는데, 결혼하면서 좀더 행복해졌고, 아파트를 지르면서 좀더 행복해졌고, 차를 몰고 다니면서 더 행복해졌고, 또 아기가 태어나면서 더 행복해졌다. 이 과정에 돈이 기여한 바는 결코 작지 않다.

마지막으로, 연봉을 올리기 위해 이직하는 행위는 사회적으로 유익하다. 나는 아직도 우리나라의 노사 관계가 사측으로 심하게 기울어져 있다고 보며, 노동자들이 더 적극적으로 자신의 권리를 주장해야 개선될 거라고 생각한다. 권리를 위한 투쟁은 민주시민의 권리이자 의무이고, 내가 더 많은 연봉을 받기 위해 노력하는 것은 나 뿐 아니라 다른 노동자들에게도 도움이 되는 일이다. 특히 경력 많고 실력 있는 사람들이 낮은 연봉으로 일하는 것은 후배들에게 엄청난 민폐가 된다. 이것이 내가 이콜레모에서 자기 연봉을 자기가 정하되, 스스로 충분히 만족할 만큼의 연봉을 부르도록 유도했던 이유 중 하나다. (첨언으로 살짝 자랑하자면, 이콜레모 멤버들이 다들 그 때는 스스로 만족할 만한 연봉을 불렀다고 했는데, 이콜레모가 해체된 지금 모두 그 때보다 훨씬 많은 연봉을 받고 있다.)

블로그

내가 오픈마루를 다니던 시기 즈음, 개발자 커뮤니티의 주요 이슈는 즐겁게 일하는 회사를 만들어가는 것, 생산적으로 일하는 방법을 찾아가는 것이었던 것 같다. 그래서 구글 같은 회사가 이상으로 떠올랐고, 많은 회사가 구글을 닮으려고 노력했다.

그런데, 최근 몇년 간은 그런 이야기가 쏙 들어가고 스타트업과 성공이 키워드가 되었다. 스타트업으로 성공하려면 죽어라 일하는 것 쯤은 감수해야지. 구글이라고 다 좋은 줄 아냐. 대박 나서 돈 벌면 다 해결돼. 이상과 현실은 달라. 뭐 이런 분위기랄까.

스타트업 성공 사례도 제법 많아졌다. 소위 exit을 경험한 창업자들도 많아졌고, 대기업이 새로운 분야에서 성공을 일궈내기도 했다. 스타트업의 성공이라는 관점에서는 한국도 제법 실리콘 밸리를 따라가기 시작한 것이다.

하지만, 여전히 한국에는 구글이나 페이스북처럼 존경 받는 IT 회사가 없다. 대학생들에게 선망의 대상인 회사들은 있지만, 소위 말하는 탑 클래스의 개발자들이 선망하는 회사는 보이지 않는다. 개발자들 모임에 나가서 이야기를 나누다보면 성공 가도를 달리는 회사에 다니는 개발자들도 그다지 좋은 이야기를 늘어놓지 않는다. 가장 많이 들리는 이야기는 스톡옵션이나 지분 계약이 만료되는 1~2년 후에 다시 나와서 창업하겠다는 이야기. 왜일까. 일의 재미로 따지면 무에서 성공을 이끌어내는 것 못지 않게, 중견 기업을 성장시켜서 글로벌 기업들과 경쟁해가는 것도 신나는 일일 텐데.

개발자에서 창업가로 변신한 사람들은 확실히 성공을 더 중시하는 경향을 보이지만, 스타트업에 참여하고 있으면서도 스스로의 정체성을 창업가보다 개발자로 정의하고 있는 사람들은 성공 자체보다 일하는 즐거움을 더 중시하는 것 같다. 뛰어난 개발자들이 스타트업을 선호하는 이유도 대박 성공을 내고 싶어서라기보다 더 자유로운 문화에서 일할 가능성이 높기 때문인 것 같고.

그게 꼭 개발만 하고 싶다는 것과는 또 다른 이야기인 것 같다. 내가 인정하는 개발자들은 대부분 개발 뿐 아니라 내가 개발한 제품이 소비자에게 어떤 유용을 주는가에도 관심이 많았고, 개발 실력도 뛰어나지만 UX, 데이터분석, 디자인, 수익 모델, 마케팅 등 다양한 분야를 공부하고 있고, 실제 지식도 다른 분야에서 수년간 일한 사람 못지 않은 경우가 많다. 그들이 원하는 것은 좋은 제품을 만들고 소비자에게 전달하는 과정, 그걸 즐겁게 하고 싶다는 것이다. 그걸 즐겁게 하지 못한다면 설령 성공 가도를 달리고 있는 기업이라 할지라도 크게 매력을 느끼지 못한다.

물론 창업자들은 대개 성공 그 자체만으로도 커다란 즐거움을 느낀다. 성공의 즐거움은 단지 돈에서 오는 것이 아니다. 뭔가 해내고 있다는 느낌, 그 느낌은 무엇과도 바꿀 수 없는 것이다. 문제는, 창업자들이 그런 성공 가도를 달리더라도 그들이 뒤늦게 채용한 직원들까지 그 즐거움을 공유하지는 않는다는 것이다. 회사가 매달 두 배씩 성장하더라도 자신이 매일 만져야 하는 코드가 PHP라면 괴로워하는 개발자들이 많다. 물론 개발자들만의 이야기는 아니다. 내가 경험한 회사 중에 스타트업의 역사를 새로 쓴 모 회사는 매주 10명을 뽑으면 1명이 남는 부서도 있었고, 부서장 책상 위에 사표가 수북이 쌓여 있는 부서도 있었다. 그들은 회사가 성장하는지 몰라서 나갔을까?

이것은 성공한 창업가들이 흔히 빠지는 함정이다. 자신은 늘 재미있고 열심히 일했으니까, 자기 회사는 즐겁게 일하는 문화를 가진 회사라고 생각한다. 그러다보니 뒤늦게 채용한 직원들이 자기처럼 열심히 일하지 않으면 그걸 그 직원의 문제라고 생각하고, 그 직원에게는 자기만큼의 지분도, 권한도 없다는 사실은 생각하지 않는다. 자신들은 원래부터 무슨 일이든 어떤 상황이든 일을 즐기는 타입이며, 오너십이라는 게 사람 개개인의 특성 같은 거라고 생각한다. 기본적 귀인 오류다. 아직 내가 아는 범위에서는 이 함정에 빠지지 않은 창업가가 없었다.

그러다보니 성공한 회사는 생겨나도 구글 같은 회사는 나타나지 않는다. 구글이나 페이스북 같은 회사에 뛰어난 개발자들이 몰리는 것은 창업자가 아닌 사람들도 즐겁게 일할 수 있는 문화에 대해 이해하고 있기 때문이다. 그냥 회사에서 재미있고 신나는 이벤트를 열어준다고 되는 게 아니다. 일 자체가 즐거워야 하는 것이다.

한국에는 그런 회사가 없다고 결론 내리는 개발자들도 주위에 점점 늘어나고 있다. 아예 해외로 나가는 사람도 많아졌고, 원격으로 외국 회사와 일하는 개발자들도 많아졌다. 나도 그런 생각을 안해본 건 아니지만 아직은 한국에 더 기대를 걸어보고 싶다. 한국에도 이런 회사가 있다고 자랑할 만한, 내가 안심하고 사람을 추천해줄 수 있는 그런 회사가 조금씩 생겨났으면 좋겠다.

블로그

오늘은 이유식 강의를 듣고 왔다. 산후조리원에서 공짜로 해주는 거라고 해서 갔는데, 갔더니 강사가 두 명이다. 한 명은 이유식 강사인 듯 한데, 한 명은 샐러드 마스터라는 주방 세트 판매원인지 계속 냄비 자랑이다. 2시간이 넘는 긴 시간 동안의 수업이었지만 영양가 있는 내용은 30분도 안될 정도의 분량. 수강생들 먹을 식사도 즉석에서 요리를 해주면서 계속 샐러드 마스터 자랑을 해대는데 이게 대체 이유식과 무슨 상관이 있는 건지.

뭐, 동영상 보려면 광고부터 봐야 하는 시대니까, 이거 광고하려고 이유식 강의 공짜로 해주는 거겠지 싶어 참고 듣긴 들었다. 수강생이 나랑 선화, 그리고 무려 45세의 초산 아줌마였는데, 그 아줌마는 이미 그 샐러드 마스터를 구입한 상태다보니 그거 이야기로 많이 새서 유튜브 광고보다는 훨씬 길었지만;;

근데, 계속 보니까 그 냄비들이 좋긴 좋았다. 나도 나름 한식 요리는 이것저것 많이 해보다보니 조금은 볼 줄 아는데, 즉석에서 요리되는 과정을 보니 정말 좋은 건 인정하겠더라. 그래서 가격을 물어봤는데 세트 구성에 따라 다르댄다. 그 전부터 계속 사람들이 스토케 산다고 190만원씩 주면서 이 냄비 세트 비싸다고 하는 걸 이해를 못하겠다는 식의 이야기를 해서, 아 일단 100만원은 넘겠구나 싶었는데, 일반적으로 세트 구성하면 얼마냐니까 무려 5~600만원이라는!! 아까 받은 카탈로그를 펼쳐보니까 풀 세트는 무려 1천만원! 선화가 1천만원에 놀라고 있으니까, 완전 풀세트는 1400만원이라는 코멘트를 해준다. 끄아아악!

1400만원이면 경차 풀옵을 살 수 있는 돈인데;; 물론 그들의 논리는 타고 다니는 차가 중요하냐 니 입으로 처먹는 게 중요하냐 뭐 이런 것이고, 생각보다 많은 주부들이 그 논리에 당하고 있는 모양이다. 사실 이 냄비들의 장점은 음식의 품질보다는 음식을 만드는데 들어가는 노력을 줄여주는 것이지만, 일단 입으로 들어가는 거라고 하면 뭔가 중요하고 돈 좀 들여야 할 것 같은 느낌을 준다. 중금속이 전혀 안 나오고 어쩌고 하는 소리를 해대지만, 3만원짜리 냄비로 평생 밥 해먹고 별 탈 없는 사람이 많은 걸 보면 3만원 짜리에서 나오는 중금속의 양도 임계치를 넘지 않는 건 확실할 텐데 말이다.

여튼, 우린 동영상 때문에 광고는 참고 봐주지만, 광고를 클릭할 생각은 없었고, 다소 강제 클릭되긴 했지만 구매버튼까지 누를 생각은 더더욱 없었다. 그래서 용감한 선화는 앞에 강사가 말하고 있는 중인데 "이제 끝난 거죠?" 하고는 총총총. 난 말 못했는데...

뭐, 그래도 이유식에 대한 소소한 정보들은 얻었고, 밥도 얻어 먹었고 해서 광고본 값은 하고 온 듯.

블로그