저희는 그 사이에서 너무나 많은 고민을 합니다. 사실 내가 뭘 좋아하는지, 뭘 잘 하는지를 아예 모르는 경우가 태반이죠. 내가 좋아하고 열정을 가졌다고 생각한 무언가가 알고 보니 나한테는 안 맞는 어떤 것이라는 깨닫는 순간이란 어떤 것일까요? 그런 순간이 오면 우린 어떻게 하는게 좋을까요?

오늘은 몇 달간 미루고 미뤘던 웹개발을 그만 두게 된 이야기, 그리고 최종적으로는 개인의 커리어와 직업 선택에 대한 이야기를 조금 나누고자 합니다.

전에 올렸던 회사를 칭찬하는 글이 무색하게도 (굳이 전의 글을 수정하지는 않겠습니다. 제 시점의 변화를 참고하실 수 있는 부분도 있다고 생각합니다),올해 2월경, 저는 많은 고민을 하고 있었습니다. 이미 세번째 이직한 회사였습니다. 일본에 와서 중소기업의 사내 스타트업 같은 팀 내의 풀 스택 개발자로 1년을 채워가던 저는, 처음 팀에 합류 하면서 들었던 ‘조만간 데이터 분석에 관련된 일을 시켜 줄게’ 라는 제안이 희미해질 만큼, 관련된 일은 조금도 하고 있지 않았습니다.
저희 팀의 프로덕트는 당시 예정된 릴리즈일의 5개월이 넘도록 동안 딜레이에 딜레이를 이어가고 있었습니다. 저는 웹의 백엔드를 기본적으로 만지며 때때로 프론트도 하고, 기술 통번역까지 필요하다면 무슨 일이든 하며 팀원으로서 노력하고 있었습니다. 덕분에 웹 개발에 대한 전반적인 지식이나 애자일에 대한 지식, Github 등에도 훨씬 익숙해졌지만 저는 제가 성장했다는 기분이 별로 들지 않았습니다.

내가 좀 더 잘했어야 했던걸까?

입사 후 하루도 맘 편히 쉬는 날 없이 열심히 일했지만 제 실력에 대한 불신은 커져갔고, 즐거움 보다는 불안감과 초조함의 하루하루였습니다.

이제서야 솔직히 털어놓을 수 있는 부분이지만 저는 2016년 처음으로 개발자로서 발을 내딛은 후 한번도 제 손을 거쳐간 제품이 제대로 유저들 사이에서 이용되는 것을 보지 못했습니다. 게으름 피우지 않고 항상 부족함을 느끼며 열심히 노력했지만 왠지 모르게 제가 소속된 회사 혹은 팀은 항상 출시 일이 늦어지거나, 프로젝트가 잘 되지 않거나, 여러가지 이유로 좋은 결과를 보지 못했습니다. 그 이유에는 제가 스타트업 위주로 회사를 다닌 것도 있지만, 그렇다고 해도 저에게는 상당히 고통스러웠습니다.

개발 경험이 전무한, 고작 신입 개발 팀원이 무엇을 얼마나 할 수 있었겠냐고 너그럽게 생각할 수도 있었지만, 주변의 훌륭한 개발자분들을 우러러보다 보니 더 높은 곳에 있는 분들이 공유하는 사례나 지식들을 보면 더더욱 작아지는 저를 느꼈습니다.

이번 회사에서도 애초에 결정 됬던 릴리즈가 개발팀의 문제가 아닌 외부 요인으로 미뤄지고 또 미뤄지면서 저는 다시 불안해지기 시작했습니다. 특히나 그 프로젝트가 끝나면 제가 관심을 가지고 있던 데이터 분석 관련 일을 하기로 했었기 때문에 프로젝트의 끝이 묘연해질수록 불만은 커져갔죠.
나한테 무슨 액운이라도 낀 걸까, 내가 좀 더 뭔가를 했어야 했나 하는 생각까지 들곤 했습니다.

그래도 어쨌든 이 프로젝트만 끝내면 나도 얻는 것이 많을 것이고, 내가 관심있는 분야에도 발을 담글 수 있을 것이라고 생각했습니다.

하지만 열심히만 한다고 불안감이 해소되지는 않았습니다. 나중에 팀에 합류한 열정과 능력 둘다 출중한 개발자 동료를 보면서, 실력이 더 좋은 다른 개발자들을 보면서 저는 자꾸만 이 길이 제 길이 아닌 것 같은 기분이 들었습니다. 그들은 힘겨움 속에서도 즐거워 보이고, 시스템을 개선할 방법을 찾았지만 저는 왠지 모르게 그게 잘 안됬죠. 그건 누구나 그래, 라고 이야기하실지도 모릅니다. 하지만 저는 좋은 개발자, 앞으로 나아가는 개발자의 원동력이 거기에 있다는 것을 어렴풋이 믿기 시작했습니다.

실패와 실수를 두려워하지 않고, 새로운 것을 적용시켜가며 소프트웨어를 완성시켜 나가는 즐거움을 동력원으로 삼는 개발자들.

언젠가부터인가 즐거움보다는 불안감, 열정보다는 공포로 개발을 마주하고 있던 저에게 그 사람들은 따라갈 수 없는 존재로 보였습니다.

Imposter 신드롬에 대해 들어보셨나요?
나는 사실 특정 업무를 할 만큼의 실력이나 지식을 갖추지 못했는데 현재 ‘할 수 있는 척’을 하며 이 일을 하고 있다고 느끼는 현상을 말합니다. 저는 프로그래밍에 있어서 이런 감정을 굉장히 심각하게 느끼는 편이었습니다. 완벽주의가 심한 부분도 있었고, 저의 배경 지식이나 공부가 충분하지 않은 부분도 있었죠.
하지만 비전공자 라는 것을 신경 쓰지 않고 호기심과 열정을 무기로 앞으로 척척 걸어나가는 사람들은 수도 없이 많습니다. 저는 노력은 하고는 있지만 더 노력하지 못한 점에 대해서 계속해서 후회하거나 고통스러워 했습니다. 혼자서 공부해봐도 이해가 안 가는 부분들, 창의적으로 문제 해결 방법을 제시하지 못하는 것에 대해서 과도하게 스트레스를 받았던 것이죠. 제가 시니어가 되어 설계를 하고 후배 개발자를 인도하는 일은 상상하기 힘든 일 이었습니다.

즉, 비전공자여서가 아니라, 저라는 사람의 특성 때문에 더욱 힘들었던게 아닐까 생각해요.

환경이 문제인가 내가 문제인가?

이 시기쯤, 회사에서 불만족스런 일이 연달아 발생하게 되고, 결국 저는 제 스스로에 대해 많은 생각을 하게 됩니다.

내가 진짜로 하고 싶었던 건 뭘까? 많은 기회를 포기하고 뛰어든 개발자로서의 커리어가 점점 버겁고 미래가 보이지 않는 것처럼 느껴지는 이유는 뭘까? 밤이고 낮이고 여유가 날 때마다 고민하게 되었습니다.

그렇게 많은 생각을 하다 보니 깨닫는 부분이 있었습니다.

나는 항상 데이터에 관심이 있었고, 관련된 일을 하고 싶었구나. 그 중에서도 데이터 사이언스보다는 데이터 분석 자체에 관심이 있었구나, 하는 것이었죠. 처음 개발자 커리어를 시작할 때부터 쭉, 제가 제일 즐거워하고 관심있어 한 분야는 데이터 처리, 시각화, 그래프 툴, 테이블 툴 등이었습니다. Raw 한 데이터를 적절하게 클린업해서 시각화 툴에 넣고 데이터의 변화나 다양하게 변하는 그래프를 보는 것이 제일 즐거웠던 저였습니다.

반면 소프트웨어론이나 애플리케이션의 유지보수성, 설계에 대해서는 재미는 있었지만 책임감과 어려움이 무척 무겁게 느껴졌었죠. 워낙 중요한 부분이기에 그렇게 느꼈던 걸지도 모르지만, 저에게는 좋은 소프트웨어를 설계하는 것이 즐거움 보다는 책임감이 무겁게 느껴지는 일이었습니다.

누군가가 저에게 ‘넌 어떤 걸 만들고 싶어?’ 라고 물어볼 때마다 ‘난 데이터를 이용해서..’ 로 시작하는 답이 저의 대답이었습니다. 다른 동료 혹은 친구 개발자들이 모두 난 ‘~한 앱을 만들고 싶어, ~한 웹 플랫폼을 만들고 싶어’ 라고 할 때마다 저 혼자 다른 대답을 하고 있었던 것이죠. 당시에는 뭔가 나 혼자 다른데.. 라는 생각을 했지만 뭐가 다른지 정확히 알 수 없었습니다.

한참을 스스로를 들여다 본 후에야 저는 제가 무엇을 정말로 편안해 하는지 알게 되었습니다. 변화무쌍한 스타트업 환경도 저랑은 잘 안 맞는다는 것도 알게 되었죠. 저는 시간을 두고 철저한 검증을 거쳐 정확한 결과를 내고, 안정적인 과정을 거치는 것을 선호하는 사람이었습니다. 요건 정의가 수도 없이 변하고 새로운 것을 끊임없이 도입하며 시스템에 이상이 생기는 것을 문제가 아닌 개선 가능한 사이클의 일부로 인식하는 것이 저에게는 어렵고 힘든 일이었던 것입니다.

그 때서야 저는, ‘나는 개발을 좋아해. 나는 앞으로도 계속 개발을 하면서 살 거야’ 라고 스스로를 설득하는 것을 그만두게 되었습니다. 마음속 깊은 곳에서 저를 괴롭히던 사실을 제대로 마주하기로 한 것이죠.

여기까지 생각이 도달하자, 저는 제가 더 이상 스타트업 환경에서, 더군다나 개발자로서는 더 이상 즐거워하면서 일을 할 수 없다는 것을 깨닫게 됩니다.

처음 든 생각은 두려움 이었습니다. 벌써 개발자 3년차인데.. 또 커리어 변경을 해도 되는 걸까? 이번엔 내가 만족할 수 있는 길일까? 주변 사람들이 날 안 좋게 보지 않을까?

저는 제 스스로가 개발자로 일하는 것이 너무나 감사하고, 그 빛나는 커뮤니티의 일부라는 것에 자부심을 가지고 있었기 때문에 마음이 무거웠습니다.

하지만 저는 스스로에게 솔직해지는 것이, 지금이라도 내가 나에게 맞는 선택을 하는 것이 올바른 일이라는 것을 알고 있었습니다.

모 아니면 도

저는 곧바로 사표를 내고, 이직 활동에 집중하게 됩니다.
개발자로 일하는 동안 계속 하고 싶었지만 사용할 기회가 많지 않았던 파이썬을 계속해서 공부하며 Data Analyst라는 직무에 닥치는 대로 지원을 했습니다.
전에는 ‘난 안될거야’ 라고 생각하며 두려워했던 대기업에도 모두 지원했습니다. 제 스스로 즐길 수 있다고 생각한 스타트업 환경이 저랑 안 맞는다는 결론에 도달한 이상, 저는 반드시 제 환경을 바꿀 필요가 있었습니다.
오히려 새로 제대로 시작한다는 생각을 하니, 마음을 내려놓게 되어서 도전하는 것도 어렵지 않았습니다. 전에는 내가 내 자신을 모든 것을 갖춘 사람으로서 비춰야 한다는 것에 중압감을 느껴 도전도 할 수 없었지만 이렇게 된 이상, 그런 것은 아무래도 상관 없었죠. 꼭 제 자신을 위해 모든 기회를 사용하고 싶었습니다.

이러다가 이대로 직장을 잃으면 어쩌지 하는 걱정도 있었지만, 그동안 안 쓰고 열심히 모은 돈은 이럴 때 쓰기 위해서 모은 것이라 생각하고 여차하면 다시 유학을 갈 결심을 했습니다. 그만큼 저는 절실했고, 확신이 있었으며, 제 인생을 개선하고 싶은 마음이 컸습니다. 이번이 어쩌면 마지막 좋은 기회일지도 모른다는 것도 느끼고 있었죠.

정말 다행히도 저는 여러 곳에 지원한 후 예전부터 알던 무척 좋아하는 외국계 회사에 데이터 애널리스트라는 직무로 입사하게 되었고, 이번 달이 6개월차가 됩니다.
저는 이제 편안하게, 덜 불안해 하며 자신감을 가지고 즐겁게 일하고 있습니다. 웹개발은 더 이상 하고 있지 않지만, 숫자와 그래프를 많이 보고, 금융 보고서와 리포트를 읽고, 데이터의 패턴을 파악하며 종종 파이썬 스크립트를 써서 자동화를 하거나 데이터를 분석하는, 제가 하고 싶었던, 즐기는 일을 하고 있습니다. 물론, 프로그래머로서 일하면서 쌓은 노하우는 여기서도 너무나 잘 활용하고 있습니다.

이곳에도 저보다 뛰어난 사람들은 많지만, 전에처럼 조바심을 내지 않고 그 사람들이 하는 것을 부담없이 보고 배우되 나는 내 방식대로 업무를 이끌어가는 스스로를 보며, 잘 한 것 같다- 라고 생각하고 있습니다. 조금 우습긴 하지만, 매일같이 ‘오늘도 난 부족해’ 라고 힘들어하는 것을 몇 년 만에 드디어 멈추게 되어 잠도 더 잘 자게 되었습니다.

발전을 멈추게 된 것일까요? 그럴지도 모르고, 아닐지도 모릅니다.
하지만 저는 여전히 제가 하는 일에 최선을 다하고 있고, 다만 스스로를 조금 더 아끼는, 롱 런 하는 방법을 선택하게 되었다고 믿고 싶습니다.

이 글은, 어렵게 개발자 커리어를 시작한 분들에게 실망을 드리고자 쓴 글이 아닙니다. 혹은 개발자로서 고민이 많은 분들에게 다른 일을 찾아보라고 쓴 글도, 안정을 택하라는 뜻으로 쓴 글도 아닙니다.

오히려 그런 분들일 수록 자신을 많이 들여다보고, 대화하고, 스스로에게 좀 더 다정해지기를 바라는 마음에서 쓴 글입니다.

저희는 주변 환경과 수 많은 외부 의견에 영향 받으며 살아갑니다. 하지만 내 스스로를 가장 잘 알고, 나에게 만족과 평화를 찾아 줄 수 있는 사람은 자기 자신 뿐입니다. 그런 기회가 왔을 때 붙잡을 수 있도록 밑거름을 만들어가는 것도 자기 자신이고, 뭔가 잘못됬다고 생각했을 때 오롯이 나에게 집중하여 나에게 최선의 선택을 할 수 있는 것도 자신입니다. 주변의 좋은 사람들과 많은 대화를 나누되, 스스로의 거울을 많이 들여다 보셨으면 하는 바람입니다.

많이 조심스러운 부분은, 저는 제가 이런 변화에 도달할 수 있는 좋은 상황에 있었다는 것을 알고 있다는 부분입니다. 모두에게 항상 이런 행운이 주어지지는 않는다는 것도 알고 있습니다.
또 한 편으로는 개발자로서의 꾸준한 노력에 대한 목소리를 내던 제가 다른 방식을 택한 것에 의아스러움을 느끼는 분들이 계실지도 모른다는 것도 알고 있습니다.

그럼에도 불구하고 뭔가가 잘못됬다거나, 불행함을 느끼면서도 변화가 두려워 선뜻 시도해보지 못하는, 꼭 개발자에 국한된 것이 아닌 모든 분들을 위해 이 글을 썼습니다. 저처럼, ‘어렵게 선택한 길인데 이제와서 아니란 걸 인정하기엔 너무 고통스러워’ 라고 생각하시는 분들께 말이죠.

저도 제 자신이 선택한 길을 다시 바꾸고 제 자신을 받아들이는 과정이 녹록치만은 않았습니다. 하지만 그 끝이 여러분을 조금 더 행복한 곳으로 데려갈 수 있다면, 시도해볼 만한 일이 아닐까 생각합니다.

자신의 커리어, 혹은 모든 고민을 가진 분들께 많은 행운을 빕니다 :)

+추가로, 너무나 오랜만에 미디엄에 글을 올리고 이제서야 전에 글들의 댓글들을 발견하였네요. 죄송합니다ㅠㅠ
이미 너무 늦은 글들이 많아 일일이 다시 댓글을 달아드리기는 어려울 듯 하지만, 지금이라도 궁금하신 점이 있다면 최대한 대답해드리도록 하겠습니다 :)

저는 현재 오즈비젼(オズビジョン-OzVision)이라는 회사에 입사해 있습니다. 입사는 오즈비젼 쪽으로 했으나 실제로는 부속 회사 혹은 자매 회사라 볼 수 있는 폴렛(ポレット-Pollet)에 입사 한 것으로 쳐져서, 폴렛 팀에서 활동 중입니다. 오즈비젼에서는 하피타스(ハピタス)라는 일본 특유의 대형 포인트제도 플랫폼을 주 사업으로 추진하는 반면, 제가 근무중인 폴렛 팀은 각종 포인트를 하나의 카드에 담아 낭비되거나 잊혀지는 각종 포인트들을 모아서 최대한 활용할 수 있게끔 하는 신규 카드 상품을 운영 및 개발합니다.

입사 후 하고 있는 것

회사 전체 사원은 50명이 조금 안되는 수준으로, 계속해서 사람을 뽑고 있어서 빠르게 늘어나고는 있습니다만, 저희 팀은 신규사업 팀이라 사장님을 팀원으로 포함하여 6명 정도로 운영되고 있습니다. 저는 개발자 이자 다양한 언어를 할 수 있는 것을 최대한 살려서 현재는 해외 개발사와 협업 및 논의에서 주력으로 활동합니다.

일주일 대부분의 시간을 미국/파키스탄의 개발자 혹은 비즈니스 관련 팀들과 커뮤니케이션 하는데에 사용하며, 팀 내에 영어를 자유롭게 사용하는 사람이 없기 때문에ㅎㅎ 제가 알게 된 정보들을 빠짐없이 알리는데에 집중하고 있습니다. 틈틈이 개발도 손을 대기는 하지만, 아직은 기존 프로덕트의 내용에 대한 이해도 부족하고 현 상태가 새 프로젝트의 요건 정의 단계이기 때문에, 팀원들과 설계에 집중하고 있습니다.
제가 하고 있는 일의 소개는 이 정도로 하고, 제가 이 회사에 와서 놀랐던 점, 혹은 새로웠던 점 들에 대해서 소개하고자 합니다!

데일리(Yes, DAILY) 미팅

매일 아침 전사적으로 팀마다 돌아가며 새로운 것들을 공유합니다. 이 내용은 전적으로 팀의 자유이며, 대부분 본인들의 팀들의 진척 상황에 대해서 공유 하기는 하지만 다른 내용도 전혀 문제가 없습니다. 이를테면 저희 팀은 오늘 아침 제 동료가 리그레션 테스트, 테스트 자동화, CI 등에 대해서 발표했습니다.

금요일에는 전사적으로 각 팀에 대한 현상태 보고가 있으며, 모든 내용이 투명하게 공개됩니다. 무엇이 잘 되고 있는지, 어떤 것이 잘 안되고 있는지, 이유는 무엇인지 이야기하고 그 자리에서 피드백을 받거나 의견을 받습니다. 어떻게 보면 무시무시한 방법 입니다만(UI개선에 실패하여 대표님이 그자리에서 이거 괜찮은거냐- 라고 묻는 상황도ㅋㅋ) 서로를 탓하기 보다는 개선점에 대하여 이야기하고 좋은 점이 있으면 칭찬하는, 무겁지 않게 건설적으로 이야기를 이끌어가려는 모습이 개인적으로 참 좋았습니다!

매일 전사 회의 이후에는 각 팀의 회의가 있습니다. 계획표를 그려놓은 화이트보드 앞에서 각자 본인이 무엇을 했는지, 오늘은 무엇을 할것인지, 잘 안풀리는 일은 없는지에 대해 이야기합니다. 적어도 저희 팀에서 이것은 추궁을 위한 목적이 아니라, 잘 안되고 있다면 왜 그런지, 다른 팀원들이 어떻게 도와줄 수 있는지를 같이 궁리 하기 위한 방법으로 보입니다. 앞에서도 이야기했지만 이렇게 모든것을 투명하게 공개하기 위해서는 서로가 서로를 탓하거나 추궁하는 분위기를 최대한 배제해야 가능하며, 실제로 그렇게 하기 위해 많은 고민을 해 온 것으로 보였습니다.
덕분에 저도 일어능력이 부족하여 모르는 것이 있더라도 솔직하게 털어놓고, 아직은 이런 것은 하기 힘들다든지 하는 것들을 자유롭게 이야기 할 수 있었습니다. 물론 아직도 어려움이 많지만, 팀원들이 귀찮아 하지 않고 같이 어려운 점을 고민해준다는 것은 큰 힘이 되더군요 :)

그 외에도 개발자들을 위한 공유타임이나, 연구회등이 간단히나마 존재합니다.

스프린트 주기와 스크럼 마스터

저희는 2주마다 스프린트 주기가 돌아옵니다. 이 스프린트에 맞는 목표를 달성하기 위해서는 일명 블록커(blocker)라 불릴 수 있는 장애물들을 서로 적극적으로 해결해야합니다. 그렇게 하기 위해서 위와 같이 여러번의 회의를 진행하며, 최대한 빠르게 고여있는 상황을 타개하려 노력합니다. 항상 모든 것을 맞추지는 못하지만, 그래도 목표한 점에 대해서는 거의 달성하게 되더군요. 스크럼 마스터는 이러한 스케쥴 조정, 각 팀원의 상황 확인 등에 집중합니다. 저희 팀 같은 경우에는 매니저님이 PM일도 하랴 스크럼 마스터도 하랴 보통 일이 많은게 아니지만.. 그냥 다들 열심히 하고 있습니다!

백로그(피보탈), 베이스캠프, TPF…

저희 팀은 백로그 관리를 위해 Pivotal Tracker를 사용하며, 팀의 페이스를 번다운 그래프 등을 통해 확인, 일정 유지를 위해 나름 노력합니다.

제가 이곳에 와서 가장 놀랐던 점이라면 일정이 실제로 거의 지켜진다는 것이죠…. 물론 제가 과거에 다니던 회사들이 유독 그렇지 못했던 것일지도 모르지만..ㅎㅎ

여기서는 대부분 일정이 맞춰지더군요. 이게 언제까지 이어질지는 모르겠으나, 다들 자연스럽게 받아들이는 것을 보면 평소에도 이게 보통 이었던게 아닐까 하는 생각이 드네요. 별것 아닐 수도 있지만 전 너무 좋았기에..
그 외에도 베이스캠프나 깃헙 위키 등도 많이 활용하고, TPF라고 해서 좋았던 점, 문제였던 점, 해결책 들을 찾아내는 회의 프레임워크 (네 이젠 회의에도 프레임워크를 쓰는 시대입니다…..) 등, 전반적으로 서로의 생각과 의견을 일치시키기 위한 노력을 열심히 합니다. 이런 회의때는 업무 얘기 외에도 내가 힘들었던 점- 체력적으로 너무 힘들었다든가, 너무 바빠서 분위기가 안 좋았다든가 하는 점도 종합적으로 이야기해서 팀 전체의 분위기가 다운 되지 않도록 합니다.

덕분에 누군가에게는 극도로 맞지 않는 환경일지도 모르겠네요. 저는 이런 부분들을 굉장히 중요하게 생각해왔으므로 맘에 쏙 들었지만, 커뮤니케이션이 피곤하고 집중할 시간이 빼앗기는 것이 싫은 분들은 어려움이 있으리라 생각됩니다ㅠㅠ
그래도 시간은 거의 백프로 맞춰서 끝냅니다. 1시간 짜리 미팅을 2시간동안 하는 그런 일은 존재하지 않습니다.
또 리모트 근무 등이 있으니까 그런 것을 활용해서 집중해서 근무하는 등의 일이 가능하기는 합니다 :)

그 속의 사람들

이러한 모든 것들을 하기 위해서는 결국, 서로의 성향과 마음이 맞지 않으면 불가능합니다. 개발을 아무리 잘하는 사람이라도 혼자 근무하기 좋아하는 사람이라면 여기서는 분명히 잡음이 생길 것이며, 보통 저희 회사는 그런 분들에게는 외주를 주는 식으로 진행 하고는 하더라구요.
그 만큼 커뮤니케이션이 가능한 사람, 남들과는 다른 생각을 가진 사람들을 좋아하는 편입니다. 실제로 다양한 시점을 더 포용하면 더 좋은 상품을 만들 수 있을 것이다! 라는 주의로 해외에서 인재들을 끌어모으는 중이죠.
물론, 회사는 회사입니다. 아무리 서로 이해해주는 분위기이고 친근한 분위기라고 해도 결국은 실적으로 말하게 되니, 야근하는 일도 있고, 힘들어하는 시간 들도 있습니다. 하지만 적어도 그런 부분에 대해서 서로 이야기하고 피드백을 주고받고 할 수 있다는 것 자체가 저 한테는 ‘아 참 잘 왔다’ 싶게 해 주는 부분 이더군요.
저희 팀 뿐만 아니라 꽤나 곳곳에서 직원들이 친구처럼 친하게 지내고 자유롭게 업무에 대한 이야기를 하는 것은, 저로서는 꽤나 고무적인 광경입니다. 저는 경력으로 들어와서 그런게 없지만, 신입들에게는 일반적으로 멘토가 붙고, 처음 적응할 때 어려울 수 있는 부분들을 적극적으로 설명해주고 도와줍니다. 물론 저는 있거나 말거나 제가 궁금한건 물어봐야 직성이 풀리는 성격이기에 아무런 문제가 없었지만요ㅎㅎㅎ

하고싶은 것에 대한 이야기들

저희 회사의 어찌 보면 가장 좋은 점이라고 해야할까요? 주기적으로 본인이 하고 싶은 것은 무엇인지에 대한 확인이 들어옵니다. 저는 웹 개발도 재밌지만 데이터쪽으로 발을 담그고 싶다- 라는 생각을 하고 있던 참이라 그 이야기를 했고(그 동안은 경력이 없으면 아무도 맡겨주지 않았기 때문에..), 대표님께서 너무나 좋아하시며 적극 밀어주시기로 하셨습니다.
물론 앞으로 해봐야 알겠지만, 다른 분들과 이야기 해보니 원래 본인이 하고 싶은것을 할 수 있게끔 하는 노력을 회사 차원에서 많이 기울인다고 하더군요. 저도 그래서 적극적으로 제가 하고 싶은 것들에 대해 어필하고, 제 스스로도 무엇을 하고 싶은지에 대한 고찰을 하려고 합니다.
물론 반대로 말하면 본인이 뭘 하고 싶은지 확실하지 않은 인재에 대해서는 채용을 하지 않는 경향이 있더군요.

그만큼 근무 형태에 대해서도 자유를 부여하려 하는지, 입사 3개월이 지나면 자유롭게 원격 근무가 가능합니다. 집에서 해도 되고, 카페에서 해도 되고, 심지어는 짧게 여행 가서도… 팀원들과 일정 조정만 되면 문제가 없습니다. 그 외에도 일년간 휴일이 22일이니 시간만 맞으면 열흘을 쭉 쉬는 것도 가능하다고 하더군요… 제 매니저님은 매년 해외 여행을 가신다고ㅎㅎ
저도 어서 3개월이 지나서 아침 느지막이 일어나 쉐어하우스에서 느긋하게 리모트 근무를 하는 날을 기다리고 있습니다 :)

다른 사람들에게 저희 회사에 대한 이야기를 하면, 많은 분들이 ‘일본회사같지 않다’ 라는 이야기를 많이 하더군요. 저도 사실 처음에 올때는 긴가민가 했는데, 와보니 저랑 상당히 잘 맞는 회사라 만족 중입니다. 팀원들도 성향이 착한 사람들이라 생활 하기에도 즐겁고, 무엇보다 눈치 보지 않고 하고 싶은 이야기를 할 수 있는 부분은 좋습니다. 물론 사회인으로서 적절한 의견 이어야 하는건 당연 하지만요.
여기에 와서 해외 솔루션 아키텍트나 개발자들과 업무를 볼 일이 많아져서 저의 정체성이나 방향성이 조금 달라 지고는 있습니다. 처음에는 불안하기도 했지만 지금은 긍정적으로 생각하고 있네요. 제 적성이나 재능을 십분 발휘하는 상황이 된 것은 좋은 일이기도 하니까요.

이 부분에 대해서는 다음 기회에 더 자세히 공유하고 싶네요! 그 외에도 제 부족한 시야에는 저희 팀 개발 환경도 상당히 잘 갖춰져있다고 생각되어서, 그것도 또 공유하게 되었으면 합니다.
조만간 글 번역도 재개할 예정입니다. 제가 좋아하는 일이기도 하고, 많은 분들께 도움이 되었으면 하는 마음에서, 꾸준히 하도록 노력하겠습니다!

혹여 저희 회사에 대해 궁금한 점이나, 그 외에도 그냥 일반적으로 일본 환경 등에 대해 궁금하신 분들이 계시면 댓글로 남겨주시면 제가 아는대로 답변 드리 도록 하겠습니다. 참고로 저희 회사 여전히 채용중인걸로 압니다ㅎㅎ

한동안 번역을 주로 해 왔지만, 이번에는 조금 색다르게 많은 분들이 알고 싶어 하실 것 같은 해외 취업, 좁게는 일본 취업에 관해서 이야기 해 보려고 합니다 😀

사실 잘 다니던 회사가 사라지게(..) 되어서 이번 달은 놀게 되었고, 현재는 일본 재류자격 (워크 퍼밋이나 일본에서 일할 자격이라고 보시면 될 것 같습니다) 심사 완료를 기다리고 있는 중입니다. 원래는 회사를 다니며 기다리려고 했으나.. 그냥 기다리는 것이 불안하기도 하고, 그동안의 절차가 머릿속에서 점점 희미해져 가고 있기도 해서 일본행이 99프로 확정된 지금 기록하는 것이 좋을 듯 하네요.

현재 상황

이 글을 통해서 일본으로 취직을 원하시는 분들이 조금이나마 (아마 제 상황이 워낙 특이한 케이스라 도움이 될 지는 모르겠습니다만😓) 힌트를 얻으실 수 있기를 바라는 마음에 적는 글이라, 우선은 제 현재까지의 이력과 상황을 알려드리고자 합니다.

저는 거의 모든 교육과정을 해외에서 보냈고, 대학교도 해외에서 나왔습니다. 그 중간에 일본에서 1년 반 정도 유학 생활을 하기도 했죠.

2015년 귀국 후 전공을 살린 해외영업직으로 취업을 했지만 도저히 마음이 가지 않아 오랫동안 동경해왔던 프로그래머가 되기로 결심, 국비지원 교육을 받고 2016년 5월 개발자로 첫 취업 이래로 쭉 PHP와 자바스크립트를 주로 개발을 해 왔습니다. SI도 해 보고 사내 솔루션도 만들어봤지만 아직 경력이 길다고 할 수는 없습니다.

올해 9월에 일본 리크루팅 회사에서 연락을 받고 면접을 진행 후, 합격하여 입사를 기다리는 중입니다.

연락

처음 연락은 링크드인을 통해서 받았습니다. 일본 헤드헌팅 회사 쪽에서 먼저 “한국에서 면접회를 열기로 한 좋은 기업이 있다” 라는 식으로 영문으로 메일이 왔고, 저는 사실 그동안 한국에서 몇몇 헤드헌팅 회사들과의 경험이 썩 유쾌한 편은 아니었기 때문에 다소 부정적인 시선으로 메일을 읽었습니다.
하지만 당시 회사의 일이 나쁘지는 않아도 더 많은 것을 경험할 수 있는 회사로 가는 것도 경력이 짧은 저에게는 좋은 기회가 아닐까 싶어, 까짓것 면접회니까 한번 가도 경험 삼아 괜찮을거고, 별로면 안가면 되지 싶어서 관심이 있다고 영문으로 답변을 보냈습니다.

면접 준비

연락을 취한 후 곧바로 헤드헌터 쪽에서 연락이 왔고, 이 때 부터는 일어로 소통을 시작했습니다. “이제부터는 일어로 하겠다”라거나 뭐 그런 일언반구 없이 곧바로 일어로 메일이 오기 시작하더군요ㅎㅎ;

스카이프를 통해서 연락을 받아 소개받을 회사에 대한 설명을 듣고, 간단한 면담을 하게 됩니다. 저는 퇴근 후에 시간을 잡아달라 부탁해서 30분 정도 이야기를 나누었습니다. 이 면담에서는 제가 어떤 개발을 해 왔는지와 자기 소개 등을 하고 어떤 회사가 오는지에 대해 듣게 됩니다. 연봉에 대한 이야기도 잠깐 하지요😉

이 과정에서 일어 수준이 어느정도 되는지도 확인하는 듯 했습니다.

그 후 이력서 양식을 보내오는데, 이력서를 꼼꼼히 작성해서 보내면 됩니다.

저는 사실 자격증도 전무하고 일어 능력 자격증도 JLPT N1을 가지고는 있지만 2012년도에 취득한 것이라…😂 보여줄 것이 이력서와 포트폴리오 밖에는 없었습니다.

포트폴리오라고는 해도, 사실 올해 이직 후에 여유가 좀 생기면서 (첫 회사에서는 과도한 업무량으로 그럴 여유가 없었습니다😓) 깃헙에 TIL을 작성하기 시작한 정도이기 때문에 대단한 것은 없었습니다. 다만 스터디를 진행하던 것이나, OSS, Hackerrank 등으로 혼자서 꾸준히 공부를 하던 부분들을 상세히 적어서 제가 가지고 있는 것들을 적극적으로 어필하려고 노력하였습니다. 다행히 이 시점에 TIL을 2달 정도 꾸준히 하고 있었어서, 그게 도움이 되었죠.

추가로 앞으로 갈 회사에서 Symfony 프레임워크 등을 이용한다는 말을 들어서 혼자 AWS EC2에 개발환경을 세팅하고 REST API를 만들기 위한 조사를 해서 정리하고, 예전에 혼자 개발했던 코드들을 정리해서 보여줄 수 있도록 깃헙에 준비 해 두었습니다. 나중에 면접 때 모두 확인했다면서, 긍정적으로 보더군요.

이런 것들을 모두 포함해서 이력서를 보냈고, 바로 면접회에 참가하게 되었습니다.

면접회 방문

최근 일본에 인력이 많이 부족해서인지, IT회사 중 한국을 방문해서 사람을 찾는 회사들이 많이 있는 듯 합니다. 제가 입사할 회사도 그 중 하나였고, 저는 여의도 쪽에서 면접회를 가졌습니다.

오전 신입, 오후 경력자로 나뉘어서 면접을 보게 되는데, 저도 오후에 참여하게 되었습니다. 생각했던 것 보다 많은 분들이 오셨더라구요. 저희는 경력자들이고, 이미 직장이 있는 분들이 다수라서인지 서로 부드러운 분위기였는데 신입분들은 상당히 딱딱한 분위기였다고 합니다.

면접회가 무려 하루 종일 진행되어서, 간단히 설명을 듣고 실제 회사 인사팀과 개발자분들의 회사 설명회가 진행됩니다. 그 후 1차 면접으로 실무진, 인사팀과 함께 면접을 보고 합격자에 한해 2차로 사장님과 스카이프 면접을 보게 되었습니다.

면접에 대해서 말씀드리자면, 생각보다도 개인적인 질문을 많이 물어보더군요. 저희 회사 같은 경우 기술적 부분보다 성격이나 생각을 집요하게 파고드는 질문을 많이 했습니다. 생각나는 질문 항목들은

• 왜 우리 회사인가? (이걸 제일 중요하게 생각한다고 합니다)
• 자신이 살면서 제일 힘들었던 기억에 대해서 이야기 해 보라. (구체적으로 설명할 것을 요구하더군요..)
• 어떠한 개발을 해 왔는지 설명하라.
• 회사에 와서 어떠한 역할을 하고 싶은지 자세히 이야기 해 보라.
• 앞으로 어떤 비젼을 가지고 있는가?

정도네요. 원래 더 많았던 것 같은데 시간이 꽤 지난지라 기억이 잘 나지는 않네요😂

오랜만에 쓰는 일어로 저것들을 상세히 설명하려니 꽤 힘들었습니다. 기술적인 질문은 거의 하지 않더라구요. 제가 듣기로는 일본의 대부분의 회사들이 그렇다고 합니다.

저는 1번 질문의 경우 미리 심사숙고해서 준비를 했는데, 실제로도 꼭 자사 서비스를 가지고 있고 서비스의 규모가 어느 정도 큰 회사로 가고 싶다는 생각을 하고 있었어서 그 점을 강조해서 답변했습니다. 그 이유에 대해서도 미리 많이 생각해 두었어서, 아마 그 부분을 좋게 봐 주지 않았을까 싶어요. 그 외에는 회사가 개발 문화를 중시하고, 협업에 대한 진지한 고민을 하고 있는지에 대한 이야기를 했던 것 같습니다. 정확히 기억이…안나네요😂

여러분도 혹 비슷한 기회가 생기신다면 1번에 대해서는 스스로도 확실히 생각을 해 두시는 것이, 여러분 스스로에게도, 회사에게도 좋을 것이라고 자신 할 수 있습니다!

일본 회사들은 현재 기술도 중요시 하지만 같이 융화될 수 있는 사람인지를 중요하게 본다는 느낌이 들었습니다. 우리나라도 집단을 중요시 하지만, 일본은 집단을 개인보다 훨씬 중요하게 여기는 분위기가 강하죠!
개인적으로 백퍼센트 동의하는 문화는 아니지만, 로마에 가면 로마의 법을 따르는 것이니까요.

그렇게 1차 면접을 한명씩 보고 난 후 곧바로(!) 결과를 발표합니다. 물론 실무진들이 토론을 어느정도 하고 나서요. 재밌는게 거의 서바이벌 식으로 모두의 앞에서 누가 왜 떨어졌는지를 설명해 줍니다.
‘~~씨는 일어 실력이 부족하셔서 떨어지셨습니다. 다른 부분은 스바라시이 하십니다!’
하는 식으로….😅

저는 다른 한분과 둘이 합격했고, 신입분들 중에서는 세 분이 합격해서 총 다섯 명이 최종 면접을 보게 되었습니다.

최종 면접

사장님과의 면접은 한 사람당 무려 45분… 이지만 실제로는 거의 1시간씩 하셨습니다. 1차 발표가 난 시점이 이미 오후 5시 정도였고, 저는 맨 마지막(…) 순서여서 8시? 9시? 쯤에 면접을 시작할 수 있었습니다. 솔직히 너무 지쳐서 긴장할 힘도 없더군요😂

그리고 중요한 것은, 1차 때 이미 꽤 자세히 물어보는구나.. 싶은 정도를 훨씬 뛰어넘는 강도로 사장님이 질문을 하셨습니다. 모든 말 하나하나를 굉장히 주의 깊게 들으시고, 말의 일관성이 흐트러지는 순간 곧바로 지적해오더군요. 그 전에 면접을 본 신입 분들의 말로 미루어 보아 그런 분임을 조금 파악한 후라서, 저는 최대한 침착하게 일관성을 유지하면서 (솔직하게 말하면 일관성이 유지됩니다😉) 답변을 했습니다. 역시 기술적인 내용은 별로 없고, 내면적으로 굉장히 후벼 파는(?) 질문들을 많이 합니다.

다만 저는 실제로도 상당히솔직하게 대화를 하는 편이고, 제 의견을 스스로 평소에 숙고하는 습관이 있어서 그다지 어렵지 않게 대화를 나눌 수 있었습니다. 다만 일어로 그 많은 대화를 하는게 쉽지 않았을 뿐…😂
한편으로는 지금 서로 다 까놓고 말해야 나중에 일본 가서 후회하며 집에 올 일이 없다 라고 생각하며 가리지 않고 다 터놓고 이야기 했습니다.
덕분에 중간에 ‘너 아까는 ~~라고 말하더니 지금 말한 그 행동이랑은 좀 다르지 않아?’ 라고 물어와도 ‘아아, 그렇지 않아. 아까 말한게 지금도 똑같이 적용 돼. 왜냐하면~’ 하는 식으로 차근차근 답을 할 수 있었죠.

실질적으로 내용은 1차 면접때 한 부분들과 크게 차이 없었습니다. 다만 훨씬 자세하고 상세할 뿐…? 마지막 하고싶은 질문은 미리 준비하시는 것이 좋구요.

면접을 다 마치고 결과 발표가 났을 때는 이미 10시에 가까운 시간이었습니다. 결과는 합격이었고, 신입 두분과 저, 이렇게 세명이 최종 합격하게 되었습니다.

그 후에는 바로 내정서에 싸인을 하고, 이후 메일로 서로 대화하며 입국 관련 절차를 밟게 됩니다. 관련 서류를 준비하면서도 이야기 할 부분들이 있지만… 너무 길어지니 그 부분은 다음번에 더 자세히 다뤄보도록 하죠. 여기서는 면접과 준비에 대한 이야기를 더 해보려 합니다.

*이 기준들은 저의 경험과 짧은 경력을 기반으로 한, 매우 주관적인 기준들임을 알려드립니다.

무엇을 갖춰야 하나요?

우선, 앞서 말씀 드렸다시피 저는 다른 분들과 조금 다른 성장 과정을 보냈어서 직접적인 비교는 어렵다는 것을 상기시켜드리고 싶습니다. 다만, 제 주관적인 생각은 언제 어디서든, 준비된 사람의 퀄리티는 바뀌지 않는다는 것입니다.

해외 취업을 희망하시는 분들이 많으실 것이라고 생각합니다. 특히 우리나라의 IT업계는 열악하다는 인식이 많아 더더욱 그렇지요. 하지만 준비되지 않은 이민과 해외 취업은 안 좋은 결과를 낳을 수도 있습니다. 그리고, 해외든 국내든, 본질적으로 좋은 개발자를 찾는 기준은 크게 변하지 않습니다.

비자가 나오는지 확인하세요.

이게 저한테 제일 큰 걸림돌이 된 부분이었습니다. 일본 취업의 경우, 엔지니어 비자는 비전공자에게는 기본적으로 나오지 않습니다.

1) 10년 이상의 경력을 가지고 있거나
2) 정보처리기사, 혹은 정보처리 산업기사 (혹은 기타 국가자격증 및 일본 현지 자격증)

을 가지고 있어야 합니다. 그렇지 않으면 엔지니어 비자가 나오지 않아요. 다른 자격 비자로 가시게 됩니다. 저도 그런 케이스라서, 우선 취득 조건이 맞는 통번역 비자를 발급받아 관련 업무(어차피 한달 정도는 업무 파악, 그리고 그 외에는 프로젝트 설계 및 해외 엔지니어들과의 개발관련 업무 등)을 잠시 보고, 바로 현지에서 자격증을 딸 예정입니다.

저는 이걸 합격 후에 알았습니다. 사실 이것 때문에 저는 입사를 원치 않는다고 회사에 통보를 했으나, 사측에서 꼭 같이 일해보자고 적극적으로 서포트를 해 주어서 마음을 돌린 케이스입니다. 저는 개발자가 아닌 상태에서 일을 하는 것은 원하지 않았기 때문에 (지금은 쉬지 않고 개발할 때라고 생각하여) 꺼림칙했지만, 많은 이야기를 통해서 서로 해결을 본 상태입니다. 사실 처음부터 이걸 알았으면 지원 자체를 안했을 거라서, 리크루팅 회사하고도 마찰을 꽤 빚기도 했죠😕 비전공자 여러분은 이 조건을 반드시! 확인하시기 바랍니다.

본인이 어떤 개발자가 되고 싶은지 확실히 하세요.

저는 처음 개발자가 되기를 마음 먹으면서, 많은 컨퍼런스와 커뮤니티들을 돌아다녔습니다. 적극적으로 참가할 정도의 붙임성이나 자신감이 없어 대부분 존재감 없이 활동 했지만, 적어도 세상에 얼마나 대단한 분들이 계신지, 그리고 어떤 능력들을 갖추고 계신지는 배울 수 있었죠.

저는 그걸 통해서 제 스스로가 ‘사람들에게 필요한’ 개발자가 되고 싶음을 확실히 했습니다. 그렇게 되기 위해서는 할게 참 많죠. 부족한 컴공 기본 지식도 꾸준히 채워야 하고, 실무 능력도 키워야 하고, 트렌드에 뒤쳐지지 않아야 하고… 저는 그 중에서도 사회적 이슈에 대해서도 관심을 가지고 개발자로서 할 수 있는 일들은 무엇일까 고민하는 것을 중요하게 생각했습니다.

그러다보니 항상 고민이 많았습니다. 어떻게 하면 더 좋은 개발자가 될 수 있을까, 걱정이 많았고, 지금도 많습니다. 그래서 TIL을 시작하고, 컴공 지식을 메울 수 있는 방법들을 찾고, 제 전문성을 기를 수 있는 장기적인 목표들을 물색했습니다. 그러다 보니 개인적으로 소위 잘 만들어진 언어를 하나는 마스터 해야겠다든가, 프레임워크를 파 보아야겠다던가, 장기적으로는 데이터 분석가가 되면 어떨까 하는 생각들을 가지게 되었습니다.

완벽주의 성향이 좀 있어 하나를 끝까지 마치지 않고 자꾸 일을 벌리는 것은 싫어하는 편이라서, 느리더라도 꾸준히 이런 것들을 하려고 노력하는 편입니다.

그리고 제일 중요한! 그것을 사람들에게 보여줄 준비를 해야합니다.
깃헙만큼 좋은 툴도 없죠! 물론 제 깃헙은 아직 보잘 것 없습니다만.. 언젠가는 멋지게 될 날을 기약하고 있습니다. 그렇게 꾸준히 쌓은 지표는 분명히 어떠한 도움이 됩니다.

그리고 그것을 위해 준비한 생각과 물질적인 것들이, 국내,해외를 불문하고 회사들에게 매력 포인트가 될 수 있다고 생각합니다.

앞으로 제가 정한 자잘한 목표들이 그대로 유지되지 않는다고 하더라도, 제가 되고 싶은 커다란 목표는 확실하기 때문에, 잠깐씩 흔들리는 것은 괜찮습니다. 하지만 이런 생각들을 확실하게 상대방에게 전달 할 수 있는 것이, 회사들, 특히 협업과 인성을 중요시 하는 일본 회사 같은 곳들에게는 어필 포인트가 될 수 있습니다.

언어를 준비하세요.

아무리 개발자는 코드로 이야기한다 라고 하더라도, 개발자도 사회인이며 회사의 구성원입니다. 저는 개인적으로 개발자도 최대한 많이 커뮤니케이션을 해야한다고 생각합니다. 기획자와도, 디자이너와도, 많은 대화를 나누는 것이 개발의 방향을 날카롭게 유지하는데에 도움이 된다고 생각합니다. 저를 합격 시켜준 회사의 직원분들도 이러한 저의 생각에는 동의하더군요.

그 만큼 해외에 가시고 싶다면 언어는 필수, 또 필수입니다. 다른 훌륭한 분들이 많았는데도 불구, 언어로 떨어진 분들이 상당히 많았습니다. 그 분들에 비하면 저는 보잘 것 없지만, 적어도 제 생각을 또박또박 일어로 이야기하는데에는 애로사항이 없습니다. 이것은 추가 포인트가 아니라 기본입니다. 아주 유창할 필요는 없지만, 자기 자신을 방어할 수 있는 정도는 되어야 합니다.

오랜 기간 해외에 살았지만 매번 느끼는 것은 해외에서는 아무도 도와줄 수 없습니다. 언어가 안되면 무시 당하고, 오해를 사며, 불리한 위치에 서게 됩니다. 안그래도 서러운 타지 생활, 안전하게 그리고 당당하게 하실 수 있도록 미리 준비하셨으면 하는 바람입니다.

국가보다는 회사를

많은 분들이 특정한 국가, 혹은 특정한 도시에 로망을 품고 해외 취업을 꿈꾸십니다. 하지만 제 개인적인 생각에는 국가보다는 회사가 중요합니다. 아무리 환경이 좋아도, 일터가 별로라면… 사람은 행복하기 어렵습니다.

국내에서 이직할 회사에 대해 꼼꼼히 살펴 보듯, 해외 회사도 꼼꼼히 살펴보셔요. 회사의 연혁, 매출, 사원수, 사내 문화, 연봉 등, 상세히 알아보시고 면접 때에도 당당하게 궁금한 것들을 알아보시기를 추천드립니다. 해외를 가는 것은 간단한 일이 아닙니다.
우리나라보다 안전한 곳도 사실상 그렇게 많지 않고, 사회적으로 보호해 주지도 않습니다.
취업하여 그 나라로 갔을 때 나를 보호해줄 단체는 회사 뿐이라고 보셔도 과언이 아닙니다. 그런 회사를 제대로 알아볼 만큼 알아보고 가도 어찌 될지 모르는데, 그저 나라가 멋져 보인다고 가면 안 좋은 경험을 할 확률이 올라갑니다.

중요한 것은 해외는 세금이 아주 쎈 곳도 많아서, 한국의 연봉과 직접적 비교가 불가능한 곳들도 많습니다. 일본도 당장 2년차부터는 주민세가 발생하여 엄청나게 많은 세금을 떼입니다. 그거 못 돌려받습니다. 모두 고려하셔야 할 사항입니다. 연봉을 올려준다고 무조건 좋은게 아니죠..

저도 국내에서 두개의 회사를 거치면서 장단점을 보게 되었고, 앞으로 갈 회사에는 이 정도는 무조건 있었으면 좋겠다! 하는 생각을 가지게 되었는데요. 저는 회사가 자사 아이템을 가지고 있고, 충분한 인력을 가지고 있는 것을 마지노선으로 선정했고, 그것에 맞추어 이번 회사도 가게 되었습니다.

꼭, 어떤 회사에서, 어떤 일을 하고 싶은지 상상하세요. 나라는 그 이후입니다. 여러분의 로망인 그 나라, 회사는 블랙일 수도 있다는 것을 잊지 마세요.

무경력 비전공자 분들께

마지막으로, 해외취업을 원하시는 무경력 비전공자 분들께 꼭 드리고 싶은 말씀이 있습니다. 앞서 설명 드렸듯, 해외 취업은 핑크빛 희망만 가득한 선택지와는 거리가 있습니다.

여러분이 만약

1) 무경력이고
2) 국비지원 학원이 받은 교육의 전부이며 (MOOC, 온라인 강의 등 포함 전혀 듣지 않았을 때)
3) 개인적인 프로그래밍 호기심이 없고
4) 아직 깃헙 활동을 하는 법을 모르며 어떠한 개인 개발도 해본 적이 없다면

저는 해외 취업을 강하게 말리고 싶습니다. 물론 운과 능력이 좋아 잘 풀리시는 분들도 있을 수 있으니, 무조건 실패할 거라고 말씀드리지는 않겠습니다. 하지만 일반적인 상식선에서 거의 확실하게 만족할 만한 생활을 하시기는 어려울 것이라고 생각합니다.

일본 취업만 당장 보셔도, 파견 업체가 넘쳐나고 좋지 못한 일자리가 넘쳐납니다. 경력이 없고 실력도 아직 미숙한 여러분에게 무료로 해외 취업을 알선 해주는 단체들은 여러분의 안위와 행복한 일자리를 보장해주지 않습니다.

해외로 넘어가는 순간부터 여러분은 완전히 혼자이며, 아직 제대로 알지도 못하는 개발을 해야합니다. 아니, 개발을 못 할 수도 있습니다.

한국의 일명 보도방이라 불리는 경력 뻥튀기 파견은 일본에서 온 것이라고 알고 있습니다. 실력이 부족한 여러분을 달콤한 말로 그쪽으로 데려가, 일본 회사에 착취당하게 하는 인력회사들, 없지 않을 것이라고 봅니다.

개인적으로 아는 동생이 이런 식으로 미국에 취업을 시켜준다는 식의 말로 이미 몇십만원을 날린 것을 본 적이 있습니다. 제가 엄청나게 뜯어 말려서 중간에 포기하기는 했지만, 그 친구가 소개받았다는 회사들, 인터넷에서 대충 검색만 해봐도 어떤 회사인지 각이 나오는 회사들이었습니다. 갔으면 억지로 못하는 개발을 아무렇게나 시키고, 윽박지르고, 온갖 잡일을 시켰겠죠. 집세는 집세대로 날리고, 정신적, 육체적으로 고통받게 됩니다.

해외 취업이라는 달콤한 말에 속아 현실을 부정하지 않으시기를 간곡히 부탁드립니다. 취업은 어디에서 하든 현실입니다. 경력과 실력을 잘 쌓아서 가도 늦지 않습니다. 내 자신은 언제든 스스로 보호할 수 있는 자신감이 어느정도 생길 때 까지, 조금만 더 기다리세요.

이상 연락을 받고 면접을 보고, 합격하기 까지의 짧은 이야기를 해 보았습니다.

무척 개인적인 경험들과 의견들이지만, 무엇보다 이 글로 일본 취업을 원하시는 분들이 조금은 도움이 되셨기를 바라는 마음입니다.

어떤 회사로 가게 되는지에 대해서는, 재류자격이 확실하게 발급되면 (제발 빨리..ㅎ..) 다시 이야기 해 보고자 합니다. 그 때는 비자를 발급받는 절차나, 집 구하기 등도 같이 이야기 할까 싶네요. 아직 1프로의 안될 확률이 있으니..😂

궁금한 점이 더 있으시다면, 댓글로 남겨주세요😊 감사합니다!

*최대한 이해하기 쉽도록 곳곳에 의역이 들어간 점 양해 부탁드립니다. 특히 이번 글은 원글에 문법적, 어감적으로 애매한 부분이 많아 독자의 이해를 최우선으로 하여 의역을 하였음을 알려드립니다.
*도움이 되셨다면 Paul의 원글에 clap 한번씩 부탁드립니다 :)

나는 여태까지 대형 컨퍼런스들을 찾아다니는 것을 좋아하지 않았고, 그런 곳에 가는 것을 중요하게 고려해 주는 회사에도 다녀본 적이 없다.

하지만 지금 나는 AWS의 두 시니어 서버리스 분야 디벨로퍼 어드보케이트(Developer Advocate) 중에 하나로(최근 일하기 시작했다), re:Invent에 참가하여 커뮤니티를 만들고 사람들에게 서버리스에 대해 더 잘 이해할 수 있도록 하는 것이 내 업무 중 하나이다.

그리고 그것이 너무나 즐겁다. 오죽하면 몇몇 사람들은 장난삼아 내가 AWS에서 훨씬 더 오래 일한 줄 알았다고 할 정도이다!

물론, 나는 지금 완전히 지쳤고, 아직도 시차 적응 중이며 이번주에 일어난 일들 중 절반조차 기억해 내기 힘들 지경이다.

벌써부터 기억들이 희미해지고 있기도 해서, 완전히 잊어버리기 전에 re:Invent에서 나온 여러가지 이야기 중 서버리스에 대한 몇 가지 중요한 하이라이트들에 대한 나의 의견을 적어보려 한다.

re:Invent 2017은 서버리스에 있어서도 훌륭한 행사였기 때문이다.

서버리스 하이라이트

이번 행사에서는 서버리스 어플리케이션 리파지토리와 람다의 Go언어 지원 등을 비롯한 여러가지 서버리스 관련 발표들이 있었다. 여기서는 AWS에서 이미 소개되고 있는 동일한 정보를 다시 언급하지는 않을 것이다. 더 알고 싶은 분들은 re:Invent가 있었던 날짜의 AWS 블로그를 살펴보면 된다.

다만 나는 스타트업 CTO라는 이력을 가지고 있으므로, 일반적으로 알려진 것들과는 조금 다른 시각으로 하이라이트들을 선별해 보았다.

카나리(Canary)와 블루/그린 tooling

우리가 작성하는 코드가 더 많은 비즈니스 로직을 반영 할 수록, 실제로 설계한 시스템을 구축하고 유지하는데에 시간과 비용을 절약할 수 있다. 이는 곧 결과적으로는 우리 모두 비즈니스 로직의 대부분을 온디맨드(on-demand) 컴퓨팅 모델에 올려놓게 될 것이라는 뜻이다.

Joshua Mckinnon on Twitter

This is a great ambition #reinvent

그리고 이러한 계획은 람다를 통해서 상당 부분 실현 가능하다.

람다의 카나리 툴(canary tool)과 API Gateway 카나리 툴의 출시로, 여태까지 겪어왔던 람다와 API의 “온/오프” 성질에 얽메이지 않고 새로운 기능들을 배포할 수 있게 되었다.

기본적으로 이 기능들은 트래픽을 예전 시스템에서 새로운 시스템으로 전환시킬 수 있는데, 많은 회사들이 찾는 기능이기도 하다.

내가 CTO였을 때, 가장 어려운 점 중에 하나가 새로운 기능과 버그 픽스들을 현재 프로덕션(실제 서비스) 환경에 배포하는 일이었다. 보통 일을 마무리하는 시간(금요일 처럼)이 아닌 때에 배포를 진행하거나 하는 식으로 이런 상황에 대처하는 것이 고작이었다.

하지만 “지속적인” 통합과 배포가 이루어져야 하는 상황에서는 이런 기존의 방법이 실천하기 어려운 때가 종종 있다. 비즈니스는 매 분, 매 초 단위에서 변화가 일어나고, 적절치 못한 타이밍에 배포를 해야하는 상황들도 일어난다.

이것이 카나리 툴이 꼭 필요한 순간들이다. 람다를 사용할지 말지에 대한 경영적인 고민에 있어서 이번 re:Invent 발표는 서버리스 커뮤니티에게 매우 중요한 것이 아닐 수 없다.

현재 우리는 중요한 비즈니스적 결정을 몇 시간 안에 기술적으로 지원해 낼 수 있는 시대에 살고 있다. 카나리는 새로운 기능들을 보다 더 빠르게 배포하는 것을 가능케 함으로써 의사 결정자들이 새로운 기능들을 더 빠르게 만들고 테스트 할 수 있게끔 해줄 것이다.

개인적으로 기업들이 카나리를 이용해서 새로운 기능들을 테스트하고 배포하게 되는 것이 무척이나 기대가 된다.

Cloud9 IDE, AWS 그리고 람다 연동(integration)

다른 큰 발표들에 비해서 그다지 눈에 들어오지 않을 수도 있지만, 이것 역시 훌륭한 변화이다.

나는 통합 개발 환경(IDE) 설치를 피하기 위한 수단으로 Cloud9을 한동안 사용해 보았다. 몇 주간 집에 있는 크롬북을 이용해서 개발용 기기로 사용이 가능할지 실험을 해 보았던 것이다.

결과는 만족스러웠다.

Cloud9 덕분이었다.

나는 여기서 Cloud9이 얼마나 좋은지, 혹은 얼마나 빠르게 발전하고 있는지에 대해서 이야기하려고 하는 것이 아니다.

Cloud9상에서 vim 단축키를 어떻게 사용할 수 있는지(오예!)에 대해서 이야기하려는 것도 아니다.

나는 이 도구를 AWS 내에서, 그리고 AWS와 람다에 연동해서 이용할 수 있는 다양한 방법들이야말로 주목해야 할 부분이라고 생각한다.

기존에는 람다 함수를 zip 파일로 압축해서 업로드하면, 코드를 다시 zip 파일로 다운 받아서 압축을 푸는 것 외에는 코드를 리뷰할 방법이 없었다.

이제는 AWS 콘솔에서 zip 파일 안의 내용을 살펴볼 수 있고, Cloud9 IDE를 이용해서 수정 역시 가능하다.

다만 한가지 유의해야 할 점은 이것은 자동화나 CI/CD, Infrastructure as Code (예.SAM/CloudFormation) 등을 필요로 하는 서비스(production) 환경을 구성하기 위한 최적의 방법은 아니다.

그래도 프로토타입을 간단히 만들거나 POC(Proof Of Concept) 단계의 솔루션을 개발 할 때에는 람다 안에 들어있는 IDE가 정말 정말 유용 할 수 있다.

하지만 여태까지는 람다에만 연동 할 수 있었다. 나를 제일 흥분시켰던 부분은 AWS 내의 Cloud9 IDE가 AWS 전체 서비스에 연동되기 시작했다는 것이다.

이번주에 코드스타를 이용해서 클릭 몇 번으로 CI/CD와 Cloud9과 연동된 클라우드 포메이션을 포함한 프로젝트를 세팅하는 시연을 볼 기회가 있었다. 서비스 환경에 최적화된 프로젝트 스타터를 만들고, 순식간에 코딩과 배포를 할 수 있게 된 것이다.

그 뿐만 아니라, 버전 관리 시스템과도 연동이 되어있어서 팀과 혐엽해서 개발하는 데에도 전혀 문제가 없다.

매우 훌륭하지 않은가! 이것에 대해서는 더 자세히 블로깅 하겠지만 우선은 새로운 기능들을 가지고 실험을 해 보기 바란다.

람다와 서버리스가 곧 새로운 생태계이다

또 하나 내가 인상 깊었던 것은, 정말 많은 사람들이 서버리스를 배우고자 한다는 것이었다. 내 동료 직원은 50명 정도를 받을 수 있는 방에 사람들이 들어가기 위해 폭동(물론 이건 심한 과장이지만)에 가까운 대란을 벌였다고 하기도 했다.

더 큰 장소를 제공해도 사람들로 꽉 차기는 마찬가지였다고 한다.

람다는 더 이상 사람들이 이해하기 위해 고전하는 “새로운” 것이 아니다. 람다는 이제 대세이고, 빠르게 발전하고 성장하고 있다.

물론 내 직업이 람다와 서버리스에 대해 열정적으로 전파하는 것이기 때문에 이러한 의견이 편중되지 않았다고는 할 수는 없다. 내 글에서 알 수 있듯이 나는 꽤 오랜 기간 이러한 변화에 많은 관심을 가져왔다.

하지만 그동안 EC2와 로드밸런서, 그리고 VPC만 만져오던 사람들이 이제는 람다, API Gateway, Step Functions, Cognito, DynamoDB 그리고 다른 서버리스 생태계의 여러 요소들에 관심을 가지기 시작했다는 것은 엄연한 사실이다.

서버리스 솔루션을 사용하고 있는 회사들은 비용 면이나 개발 과정에 대해서 놀라울만한 이야기들을 들려주고 있다.

특히 올해 새로이 들려올 이야기들이 기대가 되는데, 많은 부분에서 람다가 주목을 받고 있기 때문이다.

이제 우리는 “서버리스란 무엇인가?”라는 단순한 질문만 하는 단계를 넘어서고 있다.

Mike Roberts on Twitter

@ajaynairthinks @ben11kehoe Now @PaulDJohnston is thinking about Serverless too.

고작 3년 전에 출시된 이 기술을 기반으로 대형 회사들이 대형 솔루션을 개발하고 있다.

생각해보라.

클라우드로 어떻게 옮겨갈 것인가에 대해 고민하던 우리가, 이제는 어떻게 서버리스를 할 것인가로 빠르게 관심을 옮기고 있다.

왜 당신에게 중요한가?

나는 전(前) 스타트업 CTO였고, 서비스 환경의 프로토타입을 만들고, 준비가 다 되기도 전에 배포하고, 뒤늦게 CI/CD 과정을 끼워넣고, 이제는 떠난 주니어 개발자가 1년 전에 만들어놓은 엉성한 버그를 수정하는 등의 문제를 겪는데에 익숙했다.

람다와 서버리스는 이러한 문제들을 완전히 다르게 접근하게 해 주었다. 즉, 새로운 아이디어를 비롯한 비즈니스 결정 사안들을 만족시킬 수 있는 확장성 있는 솔루션을 만들 수 있게 되었다.

확장성 뿐만 아니라 팀 협업, CI/CD, 즉각적인 개발 착수, 변화하는 비즈니스 결정들, 미래지향적 개발 등의 이점을 제공한다.

완벽한 솔루션이란 존재하지 않는다. 하지만 비즈니스적 관점에서 서버리스 접근의 최근 동향을 살펴보면 다른 접근법에 비해서 훨씬 빠르게 시장에 접근하고 새로운 기능들을 개발 할 수 있게 해준다.

어찌 되었든 기술의 주 목적이 비즈니스를 실현하는 데에 있다는 것을 생각하면, 서버리스를 이용해서 여러분의 비즈니스를 보다 더 빠르고 유연하게 만들어보는 것은 어떨까?

그런 이유로 여러분이 서버리스와 re:Invent에 대해서 더 알아야 한다고 생각하였다.

Disclaimer

나는 현재 영국을 기점으로 유럽, 중동 그리고 아프리카를 비롯한 지역에서 AWS의 서버리스 분야 시니어 디벨로퍼 어드보케이트로 일하고 있다.

이 글에서 나타낸 의견은 내 개인의 것이며, 내 고용주의 의견과는 관계 없음을 명시한다.

*최대한 이해하기 쉽도록 곳곳에 의역이 들어간 점 양해 부탁드립니다.
*도움이 되셨다면 Peter의 원글에 clap 한번씩 부탁드립니다 :)

나는 프로그래밍을 독학했다. 그리고 그 때문에 끊임없이 가면 증후군에 시달렸다. 나는 자주 내가 부족하다고 느꼈고, 복잡한 컴퓨터 공학 지식을 이해하기에 불리한 위치에 있다고 생각하고는 한다.

나는 수학을 항상 못했다. 나는 언제나 탄탄한 수학 실력이 곧 프로그래밍 실력과 직결된다고 생각해 왔고, 그렇기 때문에 다른 (수학적 능력을 타고난) 사람들보다 더 열심히 해야 같은 개념을 이해할 수 있다고 믿었다. 이러한 생각들은 내 머릿 속 깊숙히 뿌리박혀 있었고, 그래서 나는 내심 내가 절대로 이진트리 순회(traversing binary search)를 배운다거나, 머지 소트(Mergesort)같은 악몽같은 재귀 패턴은 소화할 수 없을 거라고 느꼈다.

하지만 약간의 노력으로, 내 스스로 놀랄만한 성과를 이루어냈다. 그래서 어떻게 그렇게 했는지, 그리고 실제로 어떤 결과를 이루어 냈는지 공유하고자 한다. 언제나 그렇듯이, 어디선가 컨트리뷰터(contributor)들이 나타날 지도 모르는 것이기 때문에.

알고리즘과 자료구조를 연습하고 배워볼 수 있는 간단한 브라우저 자바스크립트 샌드박스, CS-Playground-React를 소개한다.

가입이 필요 없는 이 인터뷰 준비 앱은, 진행 상황을 자동으로 저장해주고, 막혔을 때는 답을 제공하고, 여러분이 내가 겪었던것 고통을 덜 겪으면서 여행할 수 있도록 다양한 링크(문서, 튜토리얼 등)을 제공한다!

이 앱이 그렇게 혁신적인 것은 아니라는 것을 인정한다. (분명 그렇게 생각하고 있었겠지!) 이런 비슷한 내용들을 브라우저에서 바로 코드를 작성하고 실행시키는 식으로 학습시키는 앱이 많다는 것은 나도 잘 알고 있다.

하지만 CS Playground React는 최대한 간단한 디자인으로, 매우 구체적인 주제에 대해서 파고든다. 또 하나는, 이 앱은 혁신적인 무언가를 위해서 만들어진게 아니다. 이 앱은 내가 이러한 내용들을 즐겁게 학습하기 위해서 택한 하나의 방식이다. 그 도중에 다른 누군가에게 귀중한 자료가 될 수 있다면, 더욱 기쁜 일이다.

이 앱은 아직 작업 중으로, 다루는 내용이나 기능 면에 있어서 아직 다양한 가능성이 열려있다. 그러니 만약 내가 아직 포함하지 않은 멋진 챌린지나 자료구조 같은 것이 있다면, 혹은 더 개선할 만한 부분이 있다고 생각한다면, 서슴치 말고 이슈를 오픈하거나 pull request를 보내줬으면 한다.😊

앱을 직접 확인해보고 싶다면, 지금 당장 여기에서 라이브로 확인해 볼 수 있다(오프라인 캐싱을 위해 서비스 워커를 등록해서 https로도 접속 가능하다)

코드가 궁금하다면, 바로 여기서 확인할 수 있다.

여기서부터는 그냥 좀 지루한 ‘왜’ 와 ‘어떻게’에 대한 이야기이다 :-)

왜 만들었는가

이 앱을 만든 동기는 간단했다: 배우고 싶었고, 그 과정을 좀 더 쉽고 재밌게 만들고 싶었다. 그보다 더 중요한 것은 내가 왜 이 지식들을 습득하고 싶었는가에 대한 이야기일 것이다.

지난 18개월 정도의 시간을 통해, 나는 내가 코딩을 할 수 있다고 자신있게 말할 수 있게 되었다. 하지만 내 자신을 프로그래머라고 부르기에는 머뭇거려지는 부분이 있었다. 내가 코딩을 생업으로 삼고 있지 않아서(실제로 내 직업이 아니다)가 아니라 앞서 말한 가면 증후군 현상 때문이었다. 무언가 만드는 것은 할 수 있다. 하지만 꽤 최근까지도 나는 제대로 된 컴퓨터 공학 지식을 거의 갖추지 못했었다.

컴퓨터 공학 기본 개념들을 배움으로써 나는 내가 조금 더 자신있게 내 자신을 프로그래머라고 느끼는 것은 물론, 다른 사람들도 나를 그렇게 볼 수 있도록 하고자 했다.

최근 IT 업계는 꽤 쉽게 독학으로 공부한 프로그래머들을 받아들이고 있다. 코딩 부트캠프가 여기저기서 생겨나고 있는 실리콘 밸리에서는 더욱 그러하다.

그럼에도 불구하고, 정식으로 컴공 교육을 받지 않은 프로그래머들은 업계에 들어가기 위해 꽤 큰 허들을 넘어야 한다.

이과 대신 문과를 나와서 입은 타격을 조금이라도 줄이기 위해서, 나는 컴공과 대학생 1~2학년들이 배울 만한 개념 몇 가지를 학습하기로 했다. 나는 이것이 내 실용적인 개발 실력을 뒷받침 해주고, 다른 이들이 나를 프로그래머로서 진지하게 받아들이도록 하는데에 도움이 될 것이라고 생각했다.

나는 프로그래밍 인터뷰에 자주 등장하는 주제들을 기준으로 범위를 정했다.

버블 정렬, 선택 정렬, 삽입 정렬, 병합 정렬, 퀵 정렬, 힙 정렬, 스택, 큐, 연결 리스트, 해시 테이블, 이진 탐색 트리.
휴우…

이렇게 나열된 문제들은 나를 상당히 압도했고, 그래서 제대로 도전하는 것을 꽤 오랫동안 미뤄두게 되었다.

하지만 그렇게 패배를 인정할 수는 없었기에 나는 곧 작업을 시작했다. 튜토리얼들을 찾아보고, 모든 문서들을 읽어보며, 수 없이 혼란을 겪으며 매일매일을 보냈다.

시간이 지나자 몇몇 개념들이 자리를 잡기 시작했다. 하지만 몇 가지 문제가 있었다.

1. 지루해지기 시작했다. 문제를 해결하는 것은 즐거운 일이지만, 이진 탐색 트리의 reverseLevelOrder 같은 것을 푸는것은 실제 앱 개발 중에 마주하는 문제와는 비교도 안 될 정도로 재미가 없다.
2. 너무나 오랜 시간이 걸렸다. 하루 종일 (코드를 한줄도 쓰지 않는) 업무를 보기 때문에, 코딩을 할 수 있는 시간은 매우 귀중했다. 내가 여기에 몇 개월을 쏟다보면, 실제로 실무에서 쓰기 좋은 기술들이 녹슬까봐 걱정이 되었다.

컴공 지식을 갖추는건 좋은 일이지만, 현실을 직시해보면, 웹 개발자들은 대부분 무언가를 만들기 위해 고용된다. 이런 지식들을 실제로 웹 개발을 하면서 활용할 기회는 거의 없다시피 한 것이다.

나에게는 이러한 개념들을 배우는 것이 일종의 자존심 문제였고, 포기할 마음이 없었다. 하지만 나의 제일 중요한 목표는 역시 실질적인 웹 개발 기술이었다.

그래서 나는 두가지를 하나로 합치기로 결정했다. 나의 목표를 이루면서 동시에 내 핵심 기술들을 연습할 수 있도록 해주는 간단한 앱을 만드는 것.

내가 생각하기에 무언가를 배우는 가장 좋은 방법은 (그것이 무미건조한 것일수록) 스스로가 좋아하는 것과 연결시키는 것이다. 그렇게 해서 즐겁게 앱을 만드는 것과 동시에, 컨텐츠도 개발하게 되었다.

이 프로젝트에 있어서 알고리즘과 자료구조는 필수적인 요소였다. 당연한 것이, 인터뷰 준비 앱을 만드는데 문제를 채워넣지 않으면 의미가 없으니까!

나는 며칠에 걸쳐 새로운 알고리즘이나 자료구조를 배운 후, 거의 다 이해했다 싶으면 학습 자료들을 취합해서 앱에 추가하였다. 이제 나는 내가 직접 만든 간단한 작업 공간에서 몇번이고 그 내용을 연습할 수 있다. 엄청나지 않은가?!

요점은, 내가 오랫동안 미뤄두었던 것을 즐겁게 배울 수 있는 방법을 찾아냈다는 것이다. 덕분에 내가 기존에 계획했던 목표를 더욱 더 잘 이뤄낼 수 있던 것은 물론이다.

이 앱은 내 스스로를 위해서 만들었지만, 여러분과도 공유하고 싶은 이유가 있다. 누구 한명이라도 CS-Playground-React를 유용하게 사용하게 된다면, 나는 이 커뮤니티에서 내 역할을(혹은 적어도 어떤 부분을) 했다고 느낄 수 있을 것 같다.

많은 프로그래머들이 자신들의 지식과 경험을 무료로 공유하고 댓가로 매우 적은 것을 받거나 혹은 아무것도 바라지 않는다. 이런 오픈 마인드 커뮤니티가 없이 혼자서 코딩을 배운다는 것은 거의 불가능한 일일 것이다.

10년 전만 해도 스스로 학습하기 위한 방법이 지금보다 훨씬 적었었다. 나는 내가 어떤 정보든 쉽게 얻을 수 있는 정보화시대에 살고 있다는 것에 감사하고 있다.

덕분에 내가 이번 여정을 잘 마칠 수 있었고, 이 글을 읽게 될 누군가도 조금 더 쉽게 개발자로서의 길을 걸을 수 있게 되었음을 느꼈으면 좋겠다.

기술 스택 & 방법

이 앱은 리액트와 React-Redux로 만들어졌다(첫번째 버전은 바닐라 JS, CSS 그리고 HTML로 만들었다). 편집기를 브라우저에 추가하기 위해서는 CodeMirror와 React-Codemirror2를 이용하였다.(추가: 기존 React-CodeMirror는 더 이상 관리되고 있지 않고, 리액트의 새로운 버전과도 상성이 좋지 않다. 차기 버전을 만들어준 Scniro의 리파지토리에 별 하나씩 부탁한다)

모의 콘솔

유저가 코드에서 console.log를 호출할 때 마다 redux 액션이 발생하도록 하였다. 이렇게 하면 로그 메세지들을 수집해서 브라우저에 모의 콘솔로 코드의 출력 내용을 보여줄 수 있다 — 개인적으로 꽤 신기하다고 생각한다! 언제든 clearConsole() 명령어로 모의 콘솔의 내용들을 지울 수도 있다.

코드 유지

나는 이 앱을 정말 사용하기 쉬운 앱으로 만들고 싶었다. 그래서 데이터베이스를 만들고 사용자를 로그인 시키는 대신, 진행 상황을 저장하기 위해 더 간단한 방법을 선택했다. Redux는 매 세션의 애플리케이션의 상태를 관리하는데, 나는 세션간에 코드를 유지하기 위해 localStorage를 사용하였다. 앱은 다음 번에 사용자가 방문했을 때 이 정보를 받아오고, Redux에 그 정보를 제공한다. 이렇게 함으로써 마지막으로 했던 위치에서 다시 진행할 수 있다.

만약 어떤 이유로 유저가 진행 상황을 모두 삭제하고 싶다면, 언제든 resetState()를 사용하면 된다. 당신의 코드가 로컬 스토리지에 저장되는 것이 싫다면, 다른 페이지로 이동하기 전에 // DO NOT SAVE 라는 주석을 코드에 남기면 된다. 이렇게 하면 모든 파일에 대해서 코드를 저장하지 않게 된다.

덧붙이자면, 이러한 기능을 가진 Redux-Persist 라는 패키지가 있는 듯 하다 (나는 뒤늦게 알게 되었다). 하지만 유즈케이스가 단순한 상황에서 코드 몇줄로 이러한 기능을 구현하는 것과 NPM 패키지를 설치하는 것 중에 어느게 더 나을까? 나는 매번 전자를 선택할 것이다. 아마 그 쪽이 코드 몇 백 줄과 의존성을 줄일 수 있게 되지 않을까 싶다. 이런 것은 언제나 기브 앤 테이크의 문제이므로, 고도로 최적화된(하지만 무거운) 방법이 간단한 방법보다 나은지는 스스로 선택해야 한다.

조절 가능한 패널(pane)

(*역: 창 정도로 번역하려 했으나 패널이 더 직관적인 표현인듯 하여 의역하였습니다)
마지막으로 나는 나의 작업 공간을 더욱 더 유연하고 사용하기 쉽게 하는 기능을 추가하였다. 유저들이 편집기와 콘솔 양쪽의 크기를 모두 조정할 수 있도록 하기 위해서 simpleDrag.js, React refs, 그리고 flexbox를 이용했다.

그럼 읽어준 분들께 감사의 인사를 전하며, Happy hacking!

번역을 마치며

그냥 지나치기에는 너무나 공감이 많이 가는 글이었습니다.
독학이나 다름없는 비전공자에, 문과… 매일매일 ‘나는 너무 부족한 것이 아닐까’ 라고 느끼고 필사적으로 비전공자라는 약점을 매우기 위해 하루하루 뭐라도 더 보려고 노력한 순간들이 스쳐지나갔습니다.

항상 붙잡고 있다가도 ‘실무에 필요한’ 기술들이 뒤떨어질까 시간에 쫓겨 놓게 되었던 알고리즘, 자료구조… 이번 기회에 저도 조금 다른 방식으로 접근해 볼까 하는 생각이 드네요 :) 피터의 글을 읽고 댓글란에서 발견한 이것도 한번씩 보시면 어떨까 싶습니다.

저에게 그랬듯이, 많은 분들께 위로와 힘이 되는 글이었으면 좋겠습니다!

이 글은 Vikash Singh의 Regex was taking 5 days to run. So I built a tool that did it in 15 minutes를 번역한 글입니다. 모든 저작권과 권리는 Vikash에게 있습니다.
*This article is a translated version of Vikash Singh’s article: Regex was taking 5 days to run. So I built a tool that did it in 15 minutes. All rights and credits back to him.

*최대한 이해하기 쉽도록 곳곳에 의역이 들어간 점 양해 부탁드립니다.
*도움이 되셨다면 Vikash의 원글에 clap 한번씩 부탁드립니다 :)

텍스트를 이용한 작업을 할 때, 일반적으로 개발자들은 먼저 데이터를 정리하는 과정을 거치게 된다. 그 중에는 키워드 치환(replace) 등의 작업이 포함되는데, 이를테면 “Javascript”를 “JavaScript” 로 교체하는 작업, 혹은 문서 내에 “JavaScript”라는 단어가 등장하는지를 확인하는 등의 작업들이 포함된다.

이런 식의 데이터 클리닝(Data cleaning) 작업은 대부분의 텍스트를 다루는 대부분의 데이터 사이언스 프로젝트의 대표적인 과정 중 하나이다.

데이터 사이언스는 데이터 클리닝으로 시작된다.

최근 위에서 언급한 작업을 할 기회가 있었다. 나는 Belong.co의 데이터 사이언티스트로 일하고 있고, 내 업무의 반 정도는 자연어 처리이다.

작업할 문서의 corpus(*역: 코퍼스.말뭉치. 자연언어 연구시에 특정한 목적으로 표본을 추출한 결과물)에 Word2Vec 모델을 적용시키자, 동의어(synonym)들이 비슷한 단어로 분류되었다. “Javascripting”이 “JavaScript”와 비슷한 단어로 인식되기 시작한 것이다.

이것을 해결하기 위해서, 나는 모든 동의어들을 표준화된 단어들로 교체하기 위해 정규표현식을 작성하였다. 이를테면 “Javascripting”을 “Javascript”로 교체하도록 작성하였는데, 이걸로 하나의 문제가 해결 되는 대신 다른 문제가 발생했다.

몇몇 사람들은 특정한 문제에 대해
“아 여기엔 정규표현식을 쓰면 되지” 라고 생각한다.
이 사람들은 이제 두가지 문제를 마주하게 된다.

위의 인용문은 이 stack-exchange 질문에서 가져온 것으로, 나에게도 같은 문제가 발생했다.

정규표현식은 백 단위의 키워드에 한해서 빠른 검색(search) 및 치환(replace) 처리를 가능케 한다. 하지만 나의 corpus는 2만개가 넘는 키워드와 3백만개의 문서로 이루어져 있었다.

내 정규표현식을 벤치마킹해본 결과, 한번 실행하는데에 5일이 넘는 시간이 걸릴 것임을 알게 되었다.

이런 경우 자연스럽게 병행(parallel) 실행을 해결책으로 떠올리게 된다. 하지만 몇천만 개의 문서와 몇십만 개의 키워드를 처리해야 하는 상황에서는 가능한 선택지가 아니었다. 뭔가 더 나은 방법이 있을 것이다!
나는 방법을 찾아보기로 했다.

나는 사무실의 동료들과 스택오버플로우에 도움을 청했고, 몇가지 방안을 구할 수 있었다. Vinay Pandey, Suresh Lakshmanan, 그리고 스택오버플로우를 통해 나는 Aho-Corasick이라는 환상적인 알고리즘과 Trie 데이터구조 접근법으로 방향을 잡게 되었다. 기존에 존재하는 해결책이 없을까 싶었지만, 딱히 적절한 것을 찾기가 어려웠다.

그래서 내가 직접 툴을 작성하게 되었고, FlashText가 탄생하게 되었다.

FlashText가 어떻게 작동하는지를 알아보기 전에, 검색에 대해서 얼마나 퍼포먼스가 나오는지를 확인해보도록 하자.

위의 차트는 한개의 문서에 대한 컴파일된 정규표현식(compiled regex)과 FlashText의 비교 차트이다. 키워드 숫자가 증가함에 따라, 정규표현식은 점점 더 오랜 시간이 소요되는 반면, FlashText는 관계없이 처리 속도가 유지된다.

FlashText가 실행 시간을 5일에서 14분으로 줄여주었다!

치환 작업에 대한 FlashText의 처리 소요 시간은 다음과 같다:

벤치마킹에 사용된 코드는 여기에서 볼 수 있고, 결과는 여기에서 볼 수 있다.

FlashText란?

FlashText는 내가 오픈소스로 GitHub에 등록한 파이썬 라이브러리이다. 키워드를 추출하는(extracting) 과정과 대체하는(replacing) 과정 모두에 효율적이다.

FlashText를 이용하기 위해서는 우선 키워드 리스트를 넘겨주어야 한다. 이 리스트는 내부적으로 Trie dictionary 를 생성하는데에 사용된다. 그 후에 문자열과 함께 치환(replace)작업을 할 것인지 검색(search) 작업을 할 것인지를 알려주면 된다.

replace의 경우 치환된 키워드로 새로운 문자열을 생성한다. search의 경우에는 문자열 내에서 발견된 키워드의 리스트를 반환한다. 한번 문자열을 입력하면 이 과정이 일어나는 것이다.

다음은 FlashText를 사용해본 한 행복한 사용자가 한 말이다:

Radim Řehůřek on Twitter

@arnicas 28x faster than a compiled regexp for 1k keywords & ~10k tokens per document. Nice @vi3k6i5! Pure Python too, so prolly lots of room to opt.

FlashText는 어떻게 그렇게 빠른가?

이 부분은 예시를 이용해서 이해하도록 해보자. 우리가 3개의 단어로 이루어진 I like Python이라는 문장과 {Python, Java, J2ee, Ruby}라는 4개의 단어로 이루어진 corpus를 가지고 있다고 가정해보자.

corpus에서 가져온 각 단어가 문장에 존재 하는지 확인하기 위해서는 네번의 시도가 필요하다.

‘Python’이 문장 안에 있는가?
‘Java’가 문장 안에 있는가?
…

corpus가 n개의 단어를 가지고 있다면 n번의 반복(loop)을 거쳐야 한다. 또한 각각의 <단어>가 문장 안에 있는가? 라는 검색 단위에서도 시간이 소요된다. 이것이 정규표현식을 이용하면 발생하는 소요 시간이다.

이러한 첫번째 방법의 반대 방식을 이용하는 또 다른 접근 방법이 있다. 문장의 각 단어에 대해서 corpus에 존재 하는지를 먼저 확인하는 것이다.

‘I’ 가 corpus 안에 있는가?
‘like’ 가 corpus 안에 있는가?
‘python’이 corpus 안에 있는가?

만약 문장이 m개의 단어로 이루어져있다면, m번의 반복(loop)이 필요할 것이다. 이 경우에는 문장에 몇 개의 단어가 있는지에 따라 시간이 소요된다. 또한, <단어>가 corpus 안에 있는가?를 묻는 이 과정이 dictionary를 확인하는 것으로 해결되기 때문에 보다 더 신속하게 이루어질 수 있다.

FlashText 알고리즘은 두번째 접근 방식을 채택했다. Aho-Corasick 알고리즘과 Trie 자료구조에서 영감을 얻은 방법이다.

구체적인 방식은 이렇다:
우선 corpus로 Trie dictionary를 생성한다. 다음과 비슷한 형태가 될 것이다.

시작과 EOT(End of Term *역: 단어의 끝)은 space, period(*역: 마침표)와 new_line 과 같은 구분자를 뜻한다. 키워드는 이와 같은 구분자들이 양쪽에 존재 할 때만 매치가 된다. 이렇게 함으로써 pineapple을 찾는데 apple이 매치되는 상황을 피할 수 있다.

그 다음, 인풋 문자열인 I like Python을 가지고 한글자씩 검색을 한다.

Step 1: <start>I<EOT> 가 딕셔너리 안에 있는가? No
Step 2: <start>like<EOT> 가 딕셔너리 안에 있는가? No
Step 3: <start>Python<EOT> 이 딕셔너리 안에 있는가? Yes

이러한 과정은 글자 단위의 과정이므로, <start>like<EOT>의 경우 <start>l 의 단계에서 바로 건너뛸 수 있다. l은 start와 연결되어있지 않기 때문이다. 이렇게 함으로써 없는 단어들은 매우 빠르게 건너뛸 수 있게 된다.

FlashText 알고리즘은 입력된 문자열인 ‘I like Python’의 각 글자만을 확인한다. 딕셔너리가 백만개의 키워드를 포함하고 있더라도 실행에 소요되는 시간은 영향을 받지 않게 된다. 이것이 FlashText 알고리즘의 힘이다.

그렇다면 언제 FlashText를 이용해야 할까?

간단한 답: 키워드 갯수가 500개 이상일 때.

복잡한 답: 정규표현식은 ^,$,*,\d,.와 같이 FlashText에서는 지원되지 않는 특수문자도 검색할 수 있다. 즉, word\dvc과 같은 단어 조각들을 찾고자 할 때에는 좋은 선택이 아니다. 하지만 word2vec과 같이 완성된 단어를 추출하고자 할 때에는 훌륭한 선택이다.

키워드 검색(search)을 위한 FlashText

키워드 치환(replace)을 위한 FlashText

키워드들을 추출하는 대신 치환하고자 하는 경우도 있을 것이다. 이럴 때에도 데이터 처리 파이프라인 내의 데이터 클리닝 과정으로 활용이 가능하다.

여러분 주변의 누군가가 텍스트 데이터, Entity 인식, 자연어처리, 혹은 Word2vec과 같은 작업을 하고 있다면, 이 글을 그들에게 공유해주기를 바란다.

우리는 이 라이브러리를 정말 잘 사용하고 있고, 다른 사람들에게도 유용하게 쓰일 것이라고 믿는다.

이상 글을 마친다. 여러분의 clap 에 미리 감사한다 😊

This is a review of Udacity course, Client-Server Communication (By Google).

Recently I’ve been getting some extra time, so I decided to do a bit of sprint on Udacity courses that I thought might help me. I’ve been doing some of the courses in Udacity, but never really made a review on them. I decided to make review for each course I finish, since I think I’ll have plenty of time to chase numbers of courses for next few days.

Purpose & Expectation

I took this course in order to fill up my knowledge about HTTP protocol and anything related to it. I had quite a number of experiences with HTTP while working as a web developer, but never really thought they were solid without a proper set of organized knowledge.

My expectation was to learn how does the communication happen between client and the server, in-depth. I was also expecting to see different kinds of HTTP headers introduced, alongside how should I apply the HTTP knowledge I get here for an efficient client-server communication code in my future projects.

Contents

This course offers largely five chapters.

1. HTTP Request/Response Cycle
   Talks about general concepts of HTTP request & response structure (such as method, headers, host, content-length, etc), how to use DevTools to check the HTTP status(briefly) and the JavaScript Fetch method.
   There are quizzes, but it’s not the most detailed stuff.
2. HTTP/1
   Talks about different HTTP verbs, very short introduction of REST, performance issues of HTTP/1(such as how round trips can be repetitive, Head of Line Blocking, etc), and briefly how to use the Netcat command.
3. HTTPS
   Security issues of HTTP, why encryption is needed, how does it happen, alongside TLS, certificate, and the concepts of public key and private key.
4. HTTP/2
   Why did HTTP/2 emerge, how is it different from HTTP1 in terms of connection, security, headers and etc. Also talks about what should be considered when moving into HTTP/2 from HTTP/1, in a brief manner.
5. Security
   I felt like this was the most elaborated chapter. It covers JavaScript Origins issue, mixed content problem, Cross-Origin Fetch, how to do CORS, CSRF, XSS…
   I personally learnt the most from this chapter.

Exercises

I felt like there were plenty of exercises in terms of quantity, but the explanations or the instructions were insufficient. I was often lost even after hearing the exercise instruction carefully, and had to repeat it two or three times. Sometimes I couldn’t do the exercise not because I didn’t know how to do it, but because I was unsure what the question wanted. I could only see what they wanted after I see the answer.

This course provides some custom programs to run as your local server to do the exercises. I felt like this was a good opportunity for those who wanted to touch HTTP at the network level. Neat stuff.

What I know now that I didn’t before

It was a plus for me that I gained more detailed knowledge about security issues around HTTP, especially ones like HTTPS certificates and how it works in the backstage.

I also could relate to the common JavaScript-triggered security issues. I’ve been experiencing them for several times in the past, but never really got to learn comprehensive story behind it.

Overall

I am generally satisfied with this course. I could pick up several concepts that kinda felt like missing links. I did feel like they were too general sometimes. It gives you a good guideline, but if you want a detailed explanation for bits and bytes of Client-Server communication, you’ll have to do some extra research or look for another course. Which to me is fine, since this is a free course.

One more thing, I felt like the instructor talked a bit too fast and occasionally unclear. I think Surma did a great job overall, but just wished he might slow down a bit from time to time(Of course, you can just stop the video and repeat several times — that’s what video tutorials are for!).

I’ll recommend this course for those who want to grab some base flow of HTTP. Won’t take you too long if you have some web backgrounds like I do:)

*최대한 이해하기 쉽도록 곳곳에 의역이 들어간 점 양해 부탁드립니다.
*도움이 되셨다면 Preethi의 원글에 clap 한번씩 부탁드립니다 :)

당신이 프로그래머이거나 IT 관련 일을 한다면, 도커(Docker)에 대해서 들어본 적이 있을 것이다. 애플리케이션을 포장하고, 옮기고, “컨테이너”들 안에서 실행할 수 있게 하는 유용한 툴- 최근 도커가 개발자와 시스템 관리자를 불문하고 관심을 끌어모으고 있는 것을 생각하면 당연한 일이다. 구글이나 VMware, 아마존 같은 거대한 회사들도 관련 서비스를 만들며 이러한 트렌드에 불을 붙이고 있다.

당신이 지금 바로 도커를 사용할 일이 있고 없고를 떠나서, “컨테이너”의 핵심 개념들, 그리고 버추얼 머신(VM)과의 차이에 대해서는 알아 둘 필요가 있다고 생각한다. 인터넷에 도커 사용법에 대한 훌륭한 가이드들은 많이 있지만, 개인적으로 아직 컨테이너란 무엇인가에 대한 초보자들을 위한 설명은 많이 보지 못했다. 이 글이 그 대안 중 하나가 되었으면 하는 바람이다 :)

그렇다면 VM과 컨테이너가 정확히 무엇인지부터 알아보도록 하자.

“컨테이너”와 “VM”은 무엇인가?

컨테이너와 VM은 비슷한 목적을 가지고 있다: 애플리케이션과 그 의존성들(dependencies)을 독립된 단위로 묶어 격리, 어디서든 실행 가능하게 하는 것.

또한, 컨테이너와 VM 모두 물리적 하드웨어의 필요성을 제거하여 컴퓨터의 자원을 에너지 면에서도, 그리고 비용 면에서도 보다 더 효율적으로 사용할 수 있게 해준다.

컨테이너와 VM의 결정적인 차이는 설계의 접근법에 있다. 조금 더 자세히 살펴보도록 하자.

Virtual Machines

VM은 기본적으로 컴퓨터의 에뮬레이션으로, 프로그램을 실제 컴퓨터처럼 실행한다. VM들은 “하이퍼바이저”를 통해 물리적 기계(machine) 위에서 돌아간다. 한편 하이퍼바이저는 호스트 머신이나 베어 메탈(bare metal *역: 소프트웨어가 전혀 담겨있지 않은 하드웨어)” 위에서 실행된다.

용어들이 어려우니, 조금 더 살펴보도록 하자.

하이퍼바이저란 VM이 실행되는 소프트웨어나 펌웨어, 혹은 하드웨어를 뜻한다. 하이퍼바이저들은 호스트 머신이라 불리는 물리적 기계 위에서 돌아가고, 호스트 머신은 VM에 램과 CPU 등의 자원을 제공한다.

이 자원들을 VM들이 분배 받아서 사용하는데, 사용자가 원하는 대로 할당할 수도 있다. 즉, 하나의 VM이 자원을 더 많이 필요로 하는 애플리케이션을 실행시키고 있다면, 같은 호스트 머신에서 돌고 있는 다른 VM들보다 더 많은 자원을 할당할 수도 있다는 뜻이다.

호스트 머신 위에서 하이퍼바이저를 이용하여 돌아가는 VM을 보통 게스트 머신(“guest machine”) 이라고도 부른다. 이 게스트 머신은 보통 그 애플리케이션을 실행하기 위한 모든 것(시스템 바이너리, 라이브러리 등)과 애플리케이션을 포함하며, 가상화된 네트워크 어댑터, 저장소, CPU등의 모든 하드웨어 스택도 포함한다. 즉, 자신 안에 또 하나의 온전한 게스트 운영체제를 가지고 있는 것이다.

내부에서 보면, 게스트 머신은 자신만의 자원을 할당받은, 하나의 독립된 유닛처럼 작동한다. 반면 외부의 시점에서 보면 이것은 호스트 머신의 자원을 다른 VM들과 공유하는 또 하나의 VM임을 알 수 있다.

이처럼 가상 머신은 hosted 하이퍼바이저(hosted hypervisor, *역: 호스트를 가진 하이퍼바이저. 타입 2 하이퍼바이저라고도 하는 듯 합니다), 혹은 bare-metal 하이퍼바이저(*역: 타입 1 하이퍼바이저라고도 불립니다)에 의해서 실행된다. 이 둘에는 중요한 차이가 있다.

첫 번째로, 호스트를 가진 하이퍼바이저는 호스트 머신의 운영체제 위에서 돌아간다. 예를 들어, OSX가 돌아가고 있는 컴퓨터의 VM(VirtualBox나 VMware Workstation 8 등)이 이것의 예시이다. VM은 직접 하드웨어에 접근할 수 없으며, 호스트 OS를 거쳐야 한다(위 예시의 경우에는 맥의 OSX).

Hosted 하이퍼바이저의 이점은 기본 하드웨어가 비교적 덜 중요하다는 것이다. 하이퍼바이저가 아닌 호스트의 OS가 하드웨어 드라이버들을 책임지기 때문에, “하드웨어 호환성”이 더 높다고 볼 수 있다. 다른 한편으로는 하드웨어와 하이퍼바이저 사이에 있는 이 부가적인 단계가 더 많은 리소스 오버헤드를 발생시키며, VM의 퍼포먼스를 떨어뜨릴 수 있다.

Bare metal 하이퍼바이저 환경은 위와 같은 퍼포먼스 이슈를 호스트머신의 하드웨어에 직접 설치, 실행함으로써 해결한다. 직접 하드웨어와 접촉하기 때문에 따로 호스트 OS가 필요없다. 이 경우에는 하이퍼바이저가 호스트 머신의 서버에 OS로서 처음 설치되는 것이 된다.

Hosted 하이퍼바이저와는 달리, bare-metal 하이퍼바이저는 자신만의 디바이스 드라이버를 가지고 입출력, 프로세싱, OS 관련 컴포넌트들과 직접 교류하여 처리한다. 이렇게 해서 더 나은 퍼포먼스, 확장성, 그리고 안정성을 가지게 된다. 대신 하이퍼바이저에는 제한된 숫자의 디바이스 드라이브가 설치 될 수 있으므로, 그만큼 하드웨어 호환성이 제한될 수 있다.

하이퍼바이저에 대해 여기까지 읽고 나면, 여러분은 왜 이 “하이퍼바이저”라는 추가적인 단계가 VM과 호스트 머신 사이에 필요한지가 궁금해졌을 것이다.

이는 하이퍼바이저가 VM들이 각자 자신의 가상 운영체제, 즉 게스트 운영체제를 실행하고 관리할 수 있게끔 돕는 중요한 역할과 더불어, 호스트 머신들이 자원들을 VM들에게 분배할 수 있도록 도와주는 일을 하기 때문이다.

위 그림에서 볼 수 있듯이, VM은 가상 하드웨어, 커널(OS 등), 그리고 유저 공간(space)를 포함한다.

컨테이너

하드웨어의 가상화를 제공하는 VM과는 달리, 컨테이너는 유저 공간(user spcae)의 추상화를 통해 운영체제 레벨의 가상화를 제공한다. 이게 무슨 뜻인지는 컨테이너라는 용어를 좀 더 분석해보면 알 수 있다.

비슷한 목적을 가지고 있는 만큼, 컨테이너는 VM과 흡사해 보인다. 컨테이너도 VM처럼 프로세싱을 위한 별도의 공간(private space), 루트 권한, 사설 네트워크, IP 주소, 커스텀 라우트 / iptable 규칙, 파일 시스템 마운트 등의 기능을 갖추고 있다.

하지만 컨테이너는 호스트 시스템의 커널을 다른 컨테이너들과 공유한다는 점에서 크게 차이가 난다.

이 그림에서 볼 수 있듯이, 컨테이너는 유저 공간만을 포함하고, VM에는 포함되는 커널이나 버추얼 하드웨어가 포함되지 않는다. 여러개의 컨테이너가 하나의 호스트 머신에서 돌아갈 수 있도록 각 컨테이너는 자신만의 격리된 유저 공간을 가지고 있다. 즉, 운영체제 단계의 아키텍처를 모든 컨테이너가 공유하고 있는 것이다. 처음부터 새로 생성되는 부분은 bins와 libs 뿐이며, 이것이 컨테이너가 한결 가벼워질 수 있는 이유이다.

도커는 그럼 무슨 역할을 하는가?

도커는 리눅스 컨테이너를 기반으로 하는 오픈소스 프로젝트다. 네임스페이스, 컨트롤 그룹과 같은 리눅스 커널 기능을 이용해서 운영체제 위에 컨테이너들을 생성하는 것이다.

컨테이너는 새로운 개념이 아니다. 구글은 자신들만의 컨테이너 개념을 몇 년째 이용해 왔다. Solaris Zones, BSD jails, LXC를 비롯한 다른 리눅스 컨테이너 기술들도 이미 오랫동안 존재해 왔다.

그렇다면 왜 갑자기 도커가 이목을 끌기 시작한 것일까?

1. 간편한 사용법: 도커는 개발자, 시스템 관리자, 아키텍트 등 누구든지 컨테이너의 이점을 이용해서 손쉽게 이동성 있는 애플리케이션을 생성, 테스트 할 수 있도록 만들어졌다. 누구든 애플리케이션을 자신의 랩탑에서 간단히 패키징하고, 공용 클라우드, 개인용 클라우드, 혹은 bear metal에서 보존된 상태의 애플리케이션을 실행해 볼 수 있도록 해주는 것이다. “한번의 빌드로 어디에서든 실행하자”라는 마법의 주문인 것이다.
2. 속도: 도커는 매우 가볍고 빠르다. 컨테이너는 커널에서 돌아가는 샌드박스화된 환경일 뿐이어서, 더 적은 자원을 소비한다. 매번 하나의 완전한 가상 운영체제를 부팅해야하는 VM과는 달리, 도커 컨테이너는 몇 초면 실행시킬 수 있다.
3. 도커 허브(Hub): 도커 허브는 “도커 이미지들의 앱스토어” 같은 일종의 도커 생태계로, 유저들이 자유롭게 사용할 수 있다. 도커 허브에는 커뮤니티에 의해 생성되어 바로 사용 가능한 수만개의 이미지들이 있고, 아주 쉽게 필요한 이미지를 찾을 수 있을 뿐만 아니라 약간의 수정 혹은 수정 없이 바로 사용할 수 있다.
4. 모듈성(modularity)과 확장성(scalability): 도커는 어플리케이션의 기능들을 각각의 컨테이너들로 쉽게 분리할 수 있도록 해준다. 예를 들어, 여러분이 Postgres 데이터베이스를 하나의 컨테이너에서 돌리고 다른 하나에서는 Redis 서버를, 그리고 또 하나에서는 Node.js앱을 실행시키고 있다고 가정해보자. 도커를 이용하면 이 컨테이너들을 연결하여 애플리케이션을 만들 수 있다. 각각의 컴포넌트에 대해서 따로 업데이트를 하거나 스케일링을 하기 쉬워지는 것이다.

마지막으로, 도커 고래가 싫다 할 사람이 어디 있겠는가? ;)

도커 기본 개념들

도커에 대한 큰 그림은 살펴보았으니, 도커의 기반이 되는 부분들을 하나하나 살펴보도록 하자.

도커 엔진

도커가 실행되는 레이어. 컨테이너, 이미지, 빌드 등을 관리하는 경량 런타임이자 도구로서, 리눅스 시스템에서 돌아가고 다음과 같이 구성되어 있다.

1. 호스트에서 돌아가는 도커 데몬(daemon)
2. 도커 데몬과 통신하여 명령어를 실행하는 도커 클라이언트
3. 도커 데몬과 원격으로 교류하는 REST API

도커 클라이언트

도커 클라이언트는 도커의 엔드 유저(end-user *역: 마지막 단계의 사용자)인 여러분이 사용하는 부분이다. 도커의 UI라고 보면 된다. 예를 들어, 이렇게 실행하면

여러분은 도커 클라이언트에게 명령어를 전달하고, 도커 클라이언트는 받은 명령을 도커 데몬에게로 전달한다.

도커 데몬

도커 데몬은 빌드, 실행, 배포(distribute) 등을 비롯하여 사용자가 도커 클라이언트에게 보낸 명령어를 실행한다. 도커 데몬은 호스트 머신에서 돌아가지만, 유저들이 도커 데몬과 직접적으로 접하는 경우는 없다. 도커 클라이언트도 호스트 머신에서 실행되기는 하지만, 필수적으로 그렇지는 않다. 도커 클라이언트는 다른 머신에 있는 동안에도 호스트 머신에서 돌아가는 도커 데몬과 소통하는 것이 가능하다.

도커파일(Dockerfile)

도커파일은 도커 이미지를 생성할 지시 사항들을 작성하는 파일이다. 예시로는 다음과 같은 항목들이 있을 수 있다.

• RUN apt-get y install some-package: 패키지 설치
• EXPOSE 8000: 포트 노출
• ENV ANT_HOME /usr/local/apache-ant: 환경변수 전달

일단 도커파일을 설정하고 나면, 도커 빌드 커맨드를 통해 이미지를 생성할 수 있다. 다음은 도커파일의 예시이다.

도커 이미지

이미지들은 Docker file의 지시사항을 기준으로 생성하는 read-only 템플릿이다. 이미지는 패키지화된 애플리케이션과 의존성들과 더불어 실행시에 어떤 프로세스를 실행할지를 정의한다.

도커 이미지는 도커파일을 통해서 생성된다. 도커파일 안의 각 지시 항목은 이미지에 새로운 “레이어”로서 이미지에 추가된다. 각 레이어는 이미지 파일 시스템을 구성하고, 새로 추가 되거나 기존 레이어를 교체한다. 도커의 가벼우면서도 강력한 구조의 핵심에는 이 레이어 방식이 있다. 도커는 이것을 실현하기 위해 Union File System을 이용한다.

Union File Systems

도커는 Union File System을 이용해서 이미지를 생성한다. Union File System은 스택으로 쌓을 수 있는 파일 시스템이라고 볼 수 있다. 서로 다른 파일 시스템(브랜치(branch)라고도 알려져있다)의 파일과 디렉토리가 서로 겹쳐져서 하나의 파일 시스템을 구성하게 된다는 뜻이다.

이렇게 중첩되어 있는 브랜치들 중에서 같은 경로를 가지고 있는 디렉토리들의 내용은 하나의 합쳐진 디렉토리로 인식된다. 즉, 각각의 레이어에 따라 별도의 버전을 따로 만들지 않아도 되는 것이다.

그 대신 동일한 자원으로 향하는 포인터를 배정받고, 특정 레이어가 수정된다면 그 때 로컬 카피를 생성, 수정함으로서 원본은 그대로 유지한다.

이렇게 해서 파일시스템이 실제로는 수정될 수 없는데도 writable인것(*역: 수정 가능한 것) 처럼 보여줄 수 있는 것이다. (한마디로 “copy-on-write”(*역: 수정이 일어나면 카피를 생성하는)시스템이다)

레이어드 시스템에는 두가지의 이점이 있다

1. duplication-free(*역:이중화 회피) : 레이어들로 이루어져 있다는 것은 새로운 컨테이너를 시동할때마다 전체 파일을 모두 복사하지 않아도 된다는 뜻과 같다. 즉, 도커 컨테이너들의 인스턴스화를 적은 비용으로 매우 빠르게 할 수 있도록 해 준다.
2. Layer segregation(*역: 레이어 분리) : 하나의 이미지를 변경하면 도커가 그 수정사항을 해당 레이어에만 반영하도록 하기 때문에 변경사항이 더 빠르게 반영된다.

Volumes

볼륨은 컨테이너의 ‘데이터’ 부분으로, 컨테이너 생성시 초기화된다. 볼륨은 컨테이너의 데이터를 유지하고 공유할 수 있도록 한다. 데이터 볼륨은 기본 Union File System과는 별도로, 일반 디렉토리/파일들로 호스트의 파일 시스템에 존재한다. 즉, 컨테이너를 파괴, 수정, 재생성 하더라도 데이터 볼륨은 그대로 유지된다. 볼륨을 수정하고 싶을 때는 직접 수정해야한다 (데이터 볼륨은 여러 대의 컨테이너가 공유, 재사용 할 수 있도 있다).

도커 컨테이너

도커 컨테이너는, 이미 위에서 설명한대로 애플리케이션과 해당 애플리케이션이 실행되기 위해 필요로 하는 모든 것들을 하나로 묶은 것이다. 이는 운영체제, 애플리케이션 코드. 런타임, 시스템도구, 시스템 라이브러리 등을 모두 포함한다. 도커 컨테이너는 도커 이미지로부터 만들어지는데, 이미지들은 read-only이므로 도커는 read-write 파일 시스템을 이 read-only 파일 시스템 위에 얹어서 컨테이너를 생성한다.

또한, 도커는 컨테이너가 로컬호스트와 통신할 수 있도록 네트워크 인터페이스도 생성하고, IP 주소를 컨테이너에 붙인 후, 개발자가 이미지 정의 단계에서 지정한 프로세스에 따라 애플리케이션을 실행한다.

컨테이너를 성공적으로 생성했다면, 이제 부가적인 수정 없이 어느 환경에서든 애플리케이션을 실행할 수 있다.

컨테이너 조금 더 알아보기

휴! 정말 많은 것들을 살펴보았다. 나는 항상 컨테이너가 어떻게 설계된 것인지, 특히 추상적 인프라 경계도 없이 어떻게 구현된 것인지 궁금했다. 많은 문서를 보고 나서야 이해를 하게 되었고, 여러분들에게 설명을 시도해 보려고 한다 :)

“컨테이너”는 사실상 추상적 개념으로, 몇 가지 기능의 집합체가 컨테이너처럼 작동하는 것을 상상할 수 있게끔 만들어진 개념이다. 어떤 기능들이 여기에 포함되는지 빠르게 살펴보자

1) 네임스페이스(Namespaces)

네임스페이스는 컨테이너들이 배경 리눅스 시스템에 대해 인식/접근할 수 있는 것에 제한을 건다. 컨테이너를 실행시키면, 도커가 해당 컨테이너가 사용할 네임스페이스를 생성한다.

도커가 사용하는 네임스페이스에는 몇가지 종류가 있다. 다음은 몇몇 예시이다:

a. NET: 네트워크 스택에 대해 해당 컨테이너가 볼 수 있는 것들을 지정한다. (네트워크 디바이스, IP 주소, 라우팅 테이블, /proc/net 디렉토리, 포트 번호 등)

b. PID: Process ID: PID는 Process ID의 줄임말이다. 어떤 프로세스가 현재 시스템에서 실행되고 있는지 확인하기 위해 ps aux 명령어를 실행시켜본 적이 있다면, PID라는 항목을 본 적이 있을 것이다. PID 네임스페이스는 컨테이너가 보고 교류할 수 있는 프로세스 항목들을 지정한다. 이는 “모든 프로세스들의 조상” 인 PID 1도 포함한다.

c. MNT: 컨테이너에게 시스템의 mount들(*역: 기존의 파일시스템에 부착된 추가 파일 시스템)에 대한 접근 범위를 지정한다. 즉, 서로 다른 마운트 네임스페이스는 파일시스템 계층에 대하여 다른 시야를 갖는다.

d. UTS: UTS는 UNIX Timesharing System의 줄임말이다. 프로세스가 시스템 식별자(system identifier)들을 인식하게 해주는 역할을 하는데, 즉 컨테이너가 호스트 시스템이나 다른 컨테이너들로부터 독립된 호스트명과 NIS 도메인명을 가질 수 있도록 한다.

e. IPC: InterProcess Communication이 줄임말이다. IPC 네임스페이스는 각각의 컨테이너에서 돌아가는 프로세스들의 IPC 리소스들을 격리시켜주는 역할을 한다.

f. USER: 이 네임스페이스는 각각의 컨테이너의 유저들을 서로에게서 분리시키는 역할을 한다. 컨테이너들이 uid(user ID)와 gid(group ID)에 대해 서로 다른 영역을 볼 수 있게 해준다. 결과적으로, 프로세스의 uid와 gid는 유저 네임스의 안과 밖이 서로 다를 수 있다. 이는 하나의 프로세스가 컨테이너 내부의 루트 권한을 희생하지 않고 컨테이너 외부에는 권한이 없는 유저를 가질 수 있도록 해 준다.

도커는 이 네임스페이스들을 사용해서 컨테이너를 격리하고, 새롭게 생성할 수 있도록 해준다. 다음 소개할 기능은 컨트롤 그룹이다.

2) 컨트롤 그룹

컨트롤 그룹(cgroup이라고도 한다)은 각 프로세스들이 어떻게 자원(CPU, 메모리, 디스크 입출력, 네트워크 등)을 사용할 것인지 정하는 리눅스 커널 기능이다. cgroup은 도커 컨테이너가 필요한 자원만 사용하도록 제어한다. 다르게 말하면 필요한 경우에는 컨테이너가 사용할 수 있는 자원의 한도도 지정한다. cgroup은 하나의 컨테이너가 과도하게 많은 자원을 사용하여 시스템이 중단되는 경우도 미리 방지한다.

마지막으로, union file system이 도커가 사용하는 또 다른 기능이다.

3) Isolated Union File System

위의 도커 이미지 부분에서 언급했던 Union File System을 참조하면 된다 :)

이 세가지가 도커 컨테이너를 구성하는 전부이다 (물론 진짜 어려운 부분은 여러 컴포넌트 사이의 상효 작용 등을 어떻게 구현하는가 등의 부분이기는 하다).

도커의 미래: 도커와 VM의 공존

도커가 분명 많은 주목을 받고 있기는 하지만, VM을 위협하는 존재가 될 것 같지는 않다. 컨테이너는 계속해서 더 많은 곳에서 사용되겠지만, VM이 더 필요한 케이스도 많이 있다.

예를 들어, 여러 대의 서버에 여러 개의 애플리케이션을 돌려야 한다면, VM을 쓰는 편이 나을 것이다. 한편 한개의 애플리케이션을 기반으로 한 여러 개의 카피들을 실행해야 할 경우에는 도커가 더 훌륭한 선택지일 것이다.

또한, 컨테이너들이 애플리케이션을 여러개의 기능 위주의 조각들로 나눌 수 있게 해준다는 것은 관리해야 할 부분이 많아진다는 뜻이기도 하다.

보안 문제 역시 도커 컨테이너를 사용할 때 우려되는 부분 중에 하나이다. 컨테이너들은 같은 커널을 공유함으로, 컨테이너 사이에 장벽이 약한 편이다. 또, VM이 호스트 하이퍼바이저에게 hypercall만을 보낼 수 있는 반면, 도커 컨테이너는 호스트 커널에 syscall만을 할 수 있어서 공격에 노출되는 부분이 더 넓어지게 된다. 보안이 굉장히 중요한 경우에는 추상화된 하드웨어로써 완전히 격리되는 VM을 선택하여 서로 영향을 줄 확률을 낮추는 것이 적합할 수 있다.

물론, 보안과 관리 문제들은 컨테이너들이 프로덕션 단계를 여러번 거치고 유저들의 관찰이 쌓이면서 더 개선될 것이다. 컨테이너냐 VM이냐에 대한 이슈는 당장은 매일같이 이 도구들을 사용하는 데브옵스들에게 맡겨두어도 좋을 듯 하다.

마치며

여러분들이 이제는 언젠가 프로젝트에서 필요할지도 모르는 도커에 대한 지식들을 갖추게 되었기를 바란다.

언제나 그랬듯이, 내가 무언가 실수를 했거나 도움이 될 수 있는 방법이 있다면 댓글로 남겨주면 감사하겠다 :)

번역을 마치며

저에게는 낯선 개념이지만 반드시 한번은 짚고 넘어가야 할 개념이라 생각하고 번역해 보았습니다^^; 용어도 쉽지 않고 개념도 녹록치 않아 평소보다 시간도 노력도 많이 들어갔지만 많은 분들께 도움이 되었으면 좋겠네요.
혹 오타나 문제가 발견되었다면 댓글로 남겨주시면 수정하겠습니다.

부족한 번역 읽어주셔서 감사합니다. 도움이 되신 분들은 원글에 한번씩 clap 부탁드립니다 :)

*최대한 이해하기 쉽도록 곳곳에 의역이 들어간 점 양해 부탁드립니다.
*읽기 전에 시리즈의 전편인 이 글을 읽고 오시면 더 좋습니다.

Expert Beginner 되짚어 보기

지난 포스팅에서 나는 “Expert Beginner”라는 용어를 자신의 테두리가 곧 전체의 테두리라고 굳게 믿고, 지역적 최고점에 도달한 후 배움을 멈춘 개발자들을 표현하기 위해 사용했다. Expert Beginner들은 큰 그림을 볼 수 있을 정도의 역량이 없으므로, 자신들이 expert(*역: 전문가) 가 아니라는 사실을 자각하지 못한다. 즉, 자신들이 여태까지 노출되었던 환경이 곧 전체이자 유일한 방법이라고 생각할 정도로 시야가 좁다는 뜻이다.
예를 들어, 자바를 사용해 보지도 않고 욕하는 C# 개발자나 NoSQL의 등장을 그저 한순간의 유행이라고 치부하는 MySQL DBA 같은 사람들이 여기에 포함된다. 단순히 특정한 기술을 싫어하거나 사용해보지 않았다고 해서 Expert Beginner가 되는것은 아니다. “내 기술 세트 안에 들어있지 않거나 내가 경험해보지 않은거라면, 딱히 값어치 있는게 아니다” 라고 결론 짓는 자기중심적인 마인드를 말하는 것이다.

또 다른 Expert Beginner의 특징은 일반적으로 그들이 소프트웨어 집단 내에서 어느 정도의 권위나 영향력을 가진 위치에 올라 있다는 것이다. 지난 글에서, 나는 Expert Beginner라는 용어를 만든 근거를 이번 글에서 더 설명하기 위해 미뤄두었다.

Advanced Beginner라는 용어는 초심자들 중에서도 조금 더 성숙한 수준에 있다 라고 이해할 수 있는 반면, Expert Beginner는 단어 뜻 그대로의 의미이기도 하면서 동시에 고의적으로 아이러니함을 담아 만들어낸 용어이다. 실제로 초심자로서의 연습을 많이 했기 때문에 그런 면에서는 말 그대로 전문가(expert)이지만, 보통 expert라는 말은 진심으로 스스로가 전문가라고 생각해서 사용하거나, 혹은 그 사람보다 지식이 부족한 매니저나 주변 동료들이 불러주는 명칭이기 때문이다.
대표적인 예를 들어보자. IT 계열이 아닌 작은 회사의 “tech guy(*역: 컴퓨터와 IT에 밝은 사람 정도로 해석할 수 있습니다)”가 있다고 치자. 그는 “컴퓨터를 꽤 하는” 사람이고, 회사가 성장함에 따라 IT 기술이 필요해져서 프로그래머가 된다. 컴퓨터를 잘 다루는 파워 유저에서 개발자가 된 그는, 자신이 기대했던 것 보다 더 많은 기술을 습득하고, 자신의 제한된, 그리고 제대로 교육받은 적 없는 능력에 대해 자신감을 가지게 된다.
같은 일을 하는 동료도 없으니 그의 기술을 평가할 수 있는 사람은 나 자신과 IT 지식 없이 “어쨌든 되기는 하는것 같애, 아마도” 라는 칭찬을 해주는 사람들 뿐이다. 그는 장님들만 있는 거리의 외눈박이이며, 굉장히 현실적이고 동시에 불운하게도, 지역적(local) 전문가이다. 이 예시의 등장인물은 Expert Beginner가 되기에 매우 좋은 조건들을 갖추고 있다. 쉽게 성공할 수 있고, 요구되는 기준이 낮으며, 진짜 전문가들은 존재하지 않고, 경쟁도 없으며, 외부와의 교류도 없다.

한 부분에서 발생한 부패가…

지금까지 Expert Beginner에 대한 많은 이야기를 했다. 그들이 발생하는 시점, 특징, 마음가짐, 그리고 비교적 공감 가능한 그들의 허위적인, 혹은 적어도 이해는 가는 세계관까지. 하지만 그렇다고 해서 어떻게 내가 기존에 주장했듯이, Expert Beginner들이 소프트웨어 집단의 전문성을 좀먹고 퇴화시킨다는 걸까?

이것을 설명하기 위해서 다시 나의 조금 지루한 볼링 이야기로 돌아가 보려고 하니, 질렸어도 조금만 참아주기를 부탁한다. 내 첫번째 포스팅을 읽지 못한 분들은 그 글로 가서 두번째 부분을 읽고 오는것이 좋을 것이다.

볼링장들의 매출이 선수들이 얼마나 볼링을 잘 치는가에 달려 있다고 가정해보자. 나는 자그마한, 스타트업 볼링장이 있는 동네에서 살고 있다. 소프트웨어 개발자로서 직장을 찾지 못한 나는, 동네 볼링장에서 볼링이나 쳐 보기로 한다. 나나 그들이나 내가 뭘 하고 있는지는 잘 모르지만, 내가 거기서 볼링을 치기 시작한 후로, 자세가 우스꽝스럽긴 해도 나의 실력이 빠르게 느는것을 발견한다. 평균점은 올라가고, 볼링장은 돈을 벌고, 모든게 완벽하다. 이윤과 성공적 커리어 앞에서 누가 불만이 있겠는가!

내 평균이 150을 웃돌고 나의 성장세에 끝이란 없을 것 처럼 보일 때 쯤, 볼링장은 조금 더 확장해서 몇몇 초보 선수들을 영입하여 내 밑에서 일하게 하기로 결정한다. 그들의 첫 출근 날, 나는 어떻게 공을 드는지를 보여주고, 어떻게 나처럼 걷는지를 가르친다. 그들이 엄지와 손가락 구멍들은 어디에 쓰는거냐고 물어보면, 나는 그냥 “아 그건 신경쓰지마. 여기선 그거 안 써.’ 라고 대답해 준다. 열심히 하는 모습을 보이기 위해 신입들은 내 말을 그대로 따르고, 내가 그랬듯 점수가 오르기 시작한다. 나는 160 언저리에서 서서히 정체기를 맞이하고 있는데도.

시간이 지나고, 그들 대부분은 내 식대로 하는 것에 만족한다. 하지만 몇몇은 의지가 충만하여 여유 시간에 연습을 따로 하기 시작한다. 그들은 책을 읽고, 볼링 기술에 대한 방송도 시청한다. 그러던 어느 날, 그들이 나에게 “TV에서는 손가락을 공 안에 넣고 쳐서 엄청 높은 점수를 내던데요. 200 이상요!” 라고 말한다.
그들은 내가 자신들 만큼이나 성장에 관심이 있기를 기대하지만, 나는 이렇게 반응하고 그들은 풀이 죽고 만다.
“아냐. 여기선 그렇게 안 해. 나는 너희들이 태어나기 전부터 볼링을 했고, 내가 어떻게 하고 있는지는 내가 제일 잘 알아… 그리고, TV에서 나오는 걸 다 믿으면 안돼.”
그렇게 나는 내가 볼링장에서 더 오래 일했으니, 나에게 결정권이 있다는 것을 그들에게 상기시킴으로써 집단의 혁신을 빠르고 확실하게 제거한다. 이것은 보편적으로 사용되는 완벽히 불합리한 추론으로, 대화를 불만족으로 끝맺음 짓는 방법이다.

이 시점에서, 열정적인 선수들 중 절반은 “공 안에 손가락을 넣는” 방법을 포기하고, 절반은 다른 볼링장에서 퇴근 후에 만나 조용히 연습을 한다. 시간이 지나 그들의 점수는 내 점수를 제치고, 그들은 이 접근법이 더 우수하다는 것을 객관적으로 증명했으니 변화를 일으킬 수 있다고 믿게 된다. 하지만 내가 화를 내며 그들의 성과는 그저 꼼수일 뿐이며, 나도 한번은 205점을 낸 적이 있다고 한바탕 설교를 하고 나자 그들은 남은 동료들을 두고 사라진다. 그들은 나의 꽉 막힌, 역행하는 볼링장을 떠나, 고작 고집 때문에 저급한 방법을 선택하지는 않는 곳으로 떠나게 된다.

볼링장은 가장 높은 점수를 내는 선수들을 다른 볼링장이 아닌, Expert Beginner에게 빼앗겼다.

…전체를 오염시킨다

떠나지 않은 볼링선수들은 두가지 흥미로운 교훈을 얻게 된다.
첫번째는 그들이 자신의 차례를 기다리면, 실제 능력과 상관없이 무조건적인 권력을 얻게 된다는 것. 두번째는 이 볼링장에서는 그저 그런 상태로 있어도 괜찮거나, 심지어는 더 좋을 수도 있다는 것이다.
그래서 새로운 선수들이 고용되었을 때, 회사의 ‘라인’을 유지하고 본인들의 차례를 기다리기 위해서 그들의 과거 경험 그대로 신입들에게 나쁜 방법을 강권하는 것에 동참한다. Expert Beginner는 자신의 행동과 본보기로 새로운 Expert Beginner들을 만들어내고 이는 곧 Expert Beginnerism의 문화를 생성하는 것이다.

또 하나의 흥미로운 전개는 채용 프로세스에 미치는 영향이다. 수석 Expert Beginner로서, 나는 배운게 있다. 열정 넘치는 어린 신입들을 만나기 싫은 나는, 채용 프로세스를 그저 그런 “팀 플레이어”들을 모집하는 방향으로 바꾼다. 뜬구름 잡는 “손가락에 공을 넣기” 같은 소리나 해서 나의 위치를 위협하지 않을 팀 플레이어들. 자, 여기서 여러분은 생각할 것이다. 그걸 깨달았다는 것은 기존에 이야기 했던 Expert Beginner의 “큰 그림을 보지 못한다” 라는 전제가 깨진 것 아닌가? 그렇지 않다.

이 채용 결정은 명시적인 행동이라기보다 무의식, 혹은 합리화에 가깝다. “나보다 더 나은 사람들은 채용하지 않겠다” 가 아니라 “이 사람들은 나의 ‘고정관념을 깨는’, 또한 ‘전문적인’ 방법들과는 어울리지 않아” 라고 생각하는 것이다. 심지어, 나는 나의 Expert Beginnerism에 너무 빠져버려서 Competent 혹은 Expert 수준의 작업과 무능한 수준의 작업을 구분할 정도의 지식도 갖추지 못하여, 이 둘을 혼동할 가능성 마저 있다.(조금 더 설명해 보자면 “볼링 면접”시에 나는 결과가 아닌 자세에만 집중하여 220점을 낸 선수가 내 자세랑은 다르다는 이유로 나쁜 선수라고 생각할 수 있다)

이렇게 함으로써, 나는 나의 새로운 Expert Beginner 중위들을 포함한 모두에게 이런 문화를 강화하게 된다.

이제 볼링장은 고득점을 내던 선수들을 Expert Beginner 패거리들에게 빼앗기게 된다. 또한 이것은 브루스 웹스터(Bruce Webster)가 말하던 “사해 효과”(Dead Sea Effect)가 완성, 실현되는 단계임을 알 수 있다.

현실로 돌아와서

볼링장 이야기는 그렇다 쳐도, 이 이야기가 실제 소프트웨어 개발 환경에 적용 가능할까? 꽤 간단히 가능하다.
자동화 테스팅의 부재. 거대한 함수나 클래스들. 수 많은 복사-붙이기 코딩. 오래 되었거나 적절치 못한 툴 사용. 프로세스들. 예를 들자면 끝이 없지만, 중요한 것은 부족한 지식으로 점철된 치명적인 문화를 가진 사람들이 힘 있는 위치에 있다는 것이다. 자신들이 무엇을 모르는지 자각하지 못하고, 전문가인 본인들이 모르는 것은 알 필요가 없다는 생각- 이것은 재능있고 열정적인 사람들을 떠나게 하거나 혹은 그저 그런 집단에 합류하게 만드는 유해한 문화이다.

여러분은 이것이 그저 개개인의 문제이고, 부서들이 무례하고 고집센 무능한 사람들에게 책임을 맡기면서 발생하는 일이라고 생각할 수 있지만, 나는 조금 더 심오한 문제라고 생각한다. 이 Expert Beginner들은 사실은 인격적인 문제가 없을 수도 있다. 나는 이것이 외부와 격리된 환경, 낮은 기대치, 그리고 실제로 효율성 산출이 불가능한 그저 그런 수행능력에 대한 꾸준한 보상이 만들어낸 자연스러운 결과라고 생각한다.
거기다, 우리 산업의 특성에 대해 한번 생각해볼 필요가 있다. 릴리즈 일정이 늦어지고, 버그는 많고, 예산까지 초과 했을 때에 따로 릴리즈 팀을 운영하는 회사를 몇번이나 보았는가? 제대로 관리하기가 너무나 힘든 애플리케이션을 포기하고, 처음부터 다시 작성(결국 똑같은 사이클을 언젠가는 반복할걸 알면서)하는 팀은?
마치 작동할 것처럼 보였지만 결국엔 지면에서 떨어지자 멈춰버리고, 추락하는 로켓을 만들고 나서도 승급을 하는 로켓 기술자들 마냥, 그들은 그렇게 하고도 승급을 하고 포상을 받는다.
“뭐, 좀 제대로 안되기는 했어 존스. 그렇지만 너도 이걸 통해 많이 배웠을테니까, 너를 수석 로켓 기술자로 승급시키고 두번째 버전의 설계를 맡기도록 하지. 우리의 록스타, 당신에게 말야!”
이 상황에서 존스가 자신이 마이다스 왕이라고 생각하는 건 놀라운 일도 아니다.

기본적으로 사람들의 소프트웨어에 대한 기대치는 로켓에 비해 훨씬 낮기 때문에, 우리 업계에서는 이런 일이 용인되는 것이다. 나는 여기서 우리 업계가 완전히 바뀌어야 한다고 불평하고자 하는 것이 아니다. 다만, 외부 피드백과 우리 자신의 인식에 따라 얼마나 쉽게 실제 배운 것보다 많이 알고 있다고 생각하게 될 수 있는지를 설명하려고 하는 것이다.

정체하지 않고 진전하는 문화 만들기

단순하게 표현하자면 자만심을 가진 사람들이, 어떻게 하나의 집단을 만들어내고 동시에 망가뜨리는지에 대해 이야기 해 보았다. 이번에는 이러한 사태를 최대한 방지할 수 있는 비교적 간단한 방법들을 제시해 보려고 한다.

첫째로, Expert Beginner의 덫에 빠지지 않기 위해서 제일 중요한 것은 자기 자신의 들뜬 감정을 믿지 않는 것이다. 자신이 한 것에 대해서 적절한 자신감을 가지되, 이성적인 주장 혹은 증거 없이 자신의 학습이 완성 되었다거나, 나는 직급이나 연차가 이 정도 되었으니 질문을 받을 필요가 없다거나 하는 식의 생각을 지양해야 한다. 건강한 겸손함과 지속적으로 성장하기 위한 노력을 겸비하고, 객관적 수치들을 주관적인 고려사항들보다 우선순위에 둔다면 Expert Beginner로부터 충분히 거리를 둘 수 있을 것이다.

소프트웨어 집단으로서 이 현상을 막기 위한 방법도 몇가지 리스트로 만들어 보았다.

1. 팀 멤버들에게 최대한 자유롭게 상상할 수 있는 기회를 주고, 그들이 발견한 방법을 직접 보여줄 수 있도록 독려하라 (성공보다는 실패에서 배우는게 많음을 기억하자).
2. 새로운 언어, 접근법, 프레임워크, 패턴, 스타일 등을 학습하는 것에 대한 인센티브를 제공하라
3. 특정 주장이 더 낫다고 평가하거나 수용할 때, 절대로 그 사람의 연차를 근거로 삼지 말아라.
4. 외부의 의견을 사내에 강제적으로 주입받을 수 있는 정책을 만들어라 (점심시간을 이용한 네트워킹, 월간 트레이닝, 감사 등)
5. 가능하다면 논쟁이나 의견 충돌이 있을 때 직급이나 투표 등의 주관적 기준이 아닌 좀 더 객관적인 기준으로 해결하라.
6. “증명하는 문화(culture of proof)”를 만들어라. 실제 레퍼런스, 통계, 사실 등이 확인되지 않으면 그 의견은 없는 것이나 다름 없다.
7. 주기적으로 주니어와 시니어를 아우르는 설문을 진행하라. 그들의 강점과, 강점의 갯수만큼 자신이 모르는 것, 혹은 알고 싶은 것에 대한 것을 작성하도록 하라. 이것은 사전에 직원들이 (특히 오래된 직원들이) 자신이 “모든 것을 다 안다”라고 생각하게 되는 분위기를 미연에 방지하기 위해서이다.

이 리스트는 우선적으로는 매니저와 팀 리더들을 위한 것이지만, 팀 멤버들도 충분히 이러한 변화를 일으킬 수 있다. 차이점은 한쪽은 바로 실행에 옮길 수 있고, 다른 쪽은 관리자들을 설득해야 한다는 점이다. 가능하다면, 몸소 실천해서 보여줌으로써 주도 해보라. 만약 이것이 모두 소용이 없다면, 내 개인적인 생각으로는 이미 가망이 없는 것이니 가능성이 있는 곳으로 떠나기 바란다.
보편적으로는 팀원 누구든-제일 시니어이거나 최고 경력자라 할지라도- “모르겠다” 라는 답변을 할 수 있는 문화를 만드는 것이 Expert Beginner 들로 인한 집단의 부패를 방지하기 위한 중요한 방책이다. Expert Beginner는 절대로 “모르겠다”라는 답을 하지 않는다. 이는 곧 기술을 배우고 있는 사람과 자신이 이미 알건 다 안다고 생각하는 사람 사이의 중요한 차이이다.

당신의 그룹이 성장하고 있지 않다면, 부패하고 있는 것이다.

이 시리즈는 “성장의 정체는 어떻게 합리화되는가: Expert Beginner의 언어”(How Stagnation is Justified: Language of the Expert Beginner) 에서 계속된다.

추가: E-Book이 출시되었다. 출판사의 웹사이트에 방문하면 책을 다양한 매체로 접할 수 있을 것이다.

번역을 마치며

이전 글을 올리고 난 후 너무나 많은 분들이 좋아해 주셔서, 저도 한번 Erik의 속편을 읽어보게 되었습니다.
저도 전에는 속편까지 읽지는 않았던 터라, 이번이 처음이었는데 1편만큼이나 흥미로운 이야기들이었고, 워낙 흡입력이 뛰어나 금방 번역으로 옮기게 되었습니다.
전편이 각종 학술적 이론을 기반으로 한 꼼꼼한 분석이 주였다면 이번 글은 이야기 위주의, 그리고 훨씬 신랄한(^^;) 글이다 싶습니다.
그럼에도 불구하고, 저는 Erik이 의도하고자 하는, 즉 개개인의 책임이 없다고 할 수는 없으나 구조적 문제를 반드시 생각해 봐야 한다는 점에 상당히 공감하였고, 감명을 받았습니다. Erik의 글은 약 4년 전 쯤에 쓰여진 것으로 보이므로 지금은 상황이 나아진 회사들도 많을거라고 생각합니다만, 본질에 대한 것들은 변하기 쉽지 않으니까요.

전편이 그러했듯, 많은 분들이 이번 편도 즐겁게 읽어보시고 기회가 되신다면 Erik의 E-book도 한번씩 살펴보시면 어떨까 싶네요!

*Erik은 속편의 번역도 진행해도 되겠냐는 저의 질문에 흔쾌히 시리즈 전체를 번역하라고 해 주었습니다 :)
Erik에게 감사의 말을 전하며, 시리즈의 마지막 편인 “성장의 정체는 어떻게 합리화되는가: Expert Beginner의 언어”(How Stagnation is Justified: Language of the Expert Beginner)도 밀린 기술 번역을 한 후에 추후 진행하고자 합니다.부족함이 많은 번역글을 읽어주셔서 감사합니다!

*최대한 이해하기 쉽도록 곳곳에 의역이 들어간 점 양해 부탁드립니다.
*글 내에서 등장하는 드레이퍼스가 제시한 모델의 다섯가지 단계는 본 뜻을 보존하기 위해 영문을 유지하였습니다.
+ 후속편이 번역되었습니다.

사해를 넘어서: 좋은 소프트웨어 집단이 변질될 때

최근에, 기술력이 뛰어난 대부분의 프로그래머들이 직장에서 어떤 것을 원하고 그것이 주어지지 않았을 때 떠나게 되는 이유를 “가장 뛰어난 개발자들을 지키는 법”이라는 제목으로 포스팅을 했고, 꽤 좋은 반응을 얻었다. 오늘은 개발자 개개인의 개발자로서의 여정 보다는 특정한 단체 내에서의 소프트웨어 집단에 대해서 이야기 해 보려 한다. 작성하다보니 글이 조금 길어져서 두 편으로 나눌 예정이고, 이 글은 그 첫번째 파트이다.

앞서 언급했던 글에서 나는 브루스 웹스터의 “사해 효과”를 이용해서, 가장 뛰어난 개발자들이 곧 제일 잘 나가는 개발자들이며, 그들은 상황이 조금 안 좋아지면 바로 더 좋은 곳을 찾아 떠나게 된다는 것을 설명했다. 반대로, 제일 재능이 없는 개발자들은 다른 회사들에게 자신을 어필하기 힘들기 때문에 그대로 머무는 경우가 많다. 이것은 우리가 흔히 마주치는 “어마어마하게 대단한 최고의 선임 아키텍트”라는 별명의, 고액의 연봉을 받는, 영향력도 많은, 하지만 실제로 실력은 별로 없어보이는 사람들을 이해하는데에 중요한 요소이다. 하지만 한편으로 이는 아직 개인 단계의 분석이다. 이 접근법은 낮은 질의 개발 그룹이 발생하는 이유를 그런 사람들로만 구성되어있어서 라고 밖에는 설명하지 못한다(혹은 상황이 극도로 나빠져서 이러한 부류의 사람들이 다른 사람들을 모두 쫓아내버렸다거나).

나는 소프트웨어 그룹을 망치는 데에는 외부 요소가 아닌, 집단에서 발생하는 독특한 역학관계가 존재한다고 믿는다. 물론 앞서 언급한 브루스의 사해 효과가 기본적으로 이러한 결과를 발생시키는 촉매제이자 결과라는 것을 부정할 수는 없지만, 개인적으로는 집단 전체를 무능력하게 만드는 데에는 단순한 외부적 문제 외에 어떠한 특별한 요소가 더 있다고 생각한다. 어떻게 하나의 소프트웨어 집단이 유해한 문화와 장애에 빠지게 되는지는 다음 포스팅에서 설명하고, 이번 글에서는 어떻게 개인이 영속적으로 안주하게 되면서도 높은 보상을 받게 되는지를 설명하려 한다.

볼링 배우기

앞서 말한 것들을 알아보기 전에, 나의 볼링의 역사를 들려주고자 한다. 농담이 아니고 정말로.

나는 꽤 운동을 좋아하는 편이다. 자라나면서 나는 어떤 스포츠에서든 적어도 상위 1/3에 속하고는 했다. 모든 방면에서 에이스였지만, 최고인 적은 없었던 것이다. 이러한 과거는 나를 큰 노력 없이도 어느 정도의 실력과 더불어 조금 부적절하다고 볼 수 있을 정도의 자신감을 가지게 했고, 볼링에서도 마찬가지였다.

대부분의 사람들은 볼링을 할 때 엄지와 두개의 손가락을 공에 넣고, 조심스럽게 공이 넓게 커브를 돌아 중앙으로 굴러가게끔 던진다. 그것을 익힐 만큼의 인내심이 없었던 나는 공에 손가락을 하나도 넣지 않고, 팔꿈치를 돌려서 비슷하게 그 스킬을 흉내낼 수 있었다. 멋져 보이지는 않았지만, 꽤 잘 먹혔다.

이 기술은 꽤나 효과가 좋아서, 내가 퇴근 후 리그에 취미로 참가하기 시작하자 평균점이 상당히 높아졌다. 물론 리그 내 최고 수준은 아니었다. 내 매니저를 포함한 몇몇 사람들은 170에서 200 사이의 평균 점수를 냈기 때문이다. 하지만 나는 몇 개월만에 130,140을 금방 넘어서 160 안팎의 점수를 낼 수 있었다. 썩 나쁘지 않았다.

하지만 이상한 일이 생겼다. 성장이 멈춘 것이다. 160 정도에서 벽에 부딪쳤다. 나는 내 예전 매니저에게 어떻게 하면 더 성장할 수 있을지를 물어봤고, 그는 내게 매우 흥미로운 이야기를 해줬다. 요약하자면 이런 내용이었다:

그런 식으로 볼링은 하는 동안은 무슨 수를 써도 실력이 늘지 않을거야. 이미 한계에 다다른거지. 실력을 더 높이고 싶다면, 제대로 볼링하는 법을 배워야해. 다른 공을 사용해서, 다른 방법으로 던지고, 어른답게 제대로 손가락을 공에 집어넣어야 한다고. 그렇게 하면 지금보다 훨씬 실력이 떨어질거고, 그게 제일 견디기 어려울거야. 다시 지금의 점수를 내기 위해서는 아마 꽤 오랜 시간이 걸리겠지.

나는 한동안 이것을 부정했지만, 내 정체된 실력에 곧 질려버렸고 (나는 개인적으로 장인의 수준에 도달하지 않고서는 못 견디는 성격이 있다) 더 어려운 길을 택했다. 나는 볼링공을 새로 사고, 알맞게 구멍을 낸 후 제대로 볼링을 치기 시작했다. 아이러니하게도 나는 그 직장을 곧 그만두었고, 그 후로 8번 정도밖에 더 볼링을 치지 않았지만, 뭐 인생이 다 그런것 아니겠는가. 이제는 볼링장에 가게 되어도, 볼링화를 빌리거나 내 손가락에 맞는 공을 찾아다닐 필요가 없다.

드레이퍼스, 가시적 성과와 성장의 구속

1980년, 드레이퍼스라는 성을 가진 형제가 기술 습득의 이론(model of skill acquisition) 이라는 것을 발표했고, 이는 학습과 그 과정, 그리고 연습 방법 등의 토론에 있어 상당한 영향을 끼쳤다. 후에 그들은 이 논문을 기반으로 한 책을 발표했고, 위키피디아에서 볼 수 있듯이 이 이론을 조금 더 현대에 맞춰 바꾸어 재구성하였다. 이 이론에 따르면 기술을 습득하는데에는 5가지 단계가 있다- Novice(*역:초심자), Advanced Beginner(*역:숙련된 초심자), Competent(*역:실력을 갖춤), Proficient(*역:능숙함), 그리고 Expert(*역:전문가). 이것을 설명하는데에 책 한권을 써야 했을 정도이니 복잡한 내막이 있지만, 요점은 무언가를 배울 때 사람은 “큰 그림을 보지 못하고 정해진 규칙만 따라가기” 에서 시작해서 “직감적으로 규칙 전반을 넘어선 큰 그림을 볼 수 있는 상태”에 도달하게 된다는 것이다.

혹자는 이를 보고 가라테에서 승급하거나 돈이 벌리는 원리와 같이, 노력과 실력 사이에는 직선 관계가 존재한다고 생각할 수 있다. 하지만 실제로는 감정과 마음가짐이라는 요소가 있어 좀 다르게 나타난다. 특정한 기술을 배우기 시작하는 시점에서는 누구나 완전히 무능하며, 이 때 짜증을 느끼게 된다. 또한 누군가가 가르쳐주는 것을 곧이곧대로 따라하는 동안 (혹은 드레이퍼스가 말하듯이 아기처럼 다른사람들의 행동을 어리숙하게 따라하는 동안) 답답한 감정을 겪게 된다. 하지만 한동안 이렇게 완전한 초기 과정을 겪고 나면, 연습을 통해 스스로 스킬을 익힐 수 있게 되고, 신이 난 학습자는 “낮은 곳에 달린 열매”들을 열심히 따며 빠르게 성장하게 된다.
하지만 그 열매들이 모두 바닥난 후에는 지속 불가능할 정도로 빨랐던 성장 속도가 점점 느려지게 되고, 차차 성장하는 것이 어려워지기 시작한다. 이것을 표현하는 그래프를 한번 그려보았다(이 그래프를 그리는데는 부끄럽게도 매우 오래 걸렸는데, 보통 사람들처럼 그냥 그림판으로 그리면 될 것을 나는 logistic 1/(1 + e^-x) 함수를 굳이 플롯으로 찍어 그리느라고 헛고생을 했다).

이것은 실제로 내가 볼링을 배울 때 전혀 못하는 수준에서 어느정도 가능하게 될 때 까지의 성장곡선과 매우 흡사하다. 나는 competence의 수준까지 도달할 때 까지는 빠르게 성장했지만, 곧 완전히 기세가 꺾였다. 나의 경우, 내 상태를 개선하거나 계속해서 노력하기에는 다른일로 너무 바빴기 때문에 성장이 지역적 최고점에 도달한 후에는 완전히 멈춰버렸다.
이러한 현상을 나는 이 글의 문맥상 “성장의 구속”(arrested development)라고 부르고자 한다 (같은 이름의 다른 개념이 심리학에서 존재한다는 것은 알고 있지만 편의상 여기서는 이런 의미로 이해를 부탁한다). 기술 습득에 있어서, 보통 학습자는 두가지 이유로 성장의 구속으로 인한 기술 능력 정체에 이르게 된다. 첫번째는 재능의 벽에 부딫치는 것이고, 두번째는 자발적으로 의미있는 성장을 하려는 시도를 멈추고자 하는 마음가짐이다.

이제부터 나올 내용에 대해서 첫번째 가능성은 무시하고,(대부분의 전문 프로그래머들은 competence 단계나 그 전 단계에서 재능의 부족을 느낄 가능성이 적다) 더 흥미롭고 구체적인 두번째 경우에 집중해 보도록 하자 — 이미 전문가의 위치에 도달했으니, 더 이상의 성장은 불가능하다고 느끼는, 즉 성장에 대한 자발적인 거부. 이것이 곧 내가 “Expert Beginner”(*역:전문적 초심자)라고 명명하고자 하는, 기술 습득에 있어 끝없이 안주하는 단계의 입문 과정이다.

The Expert Beginner

드레이퍼스 모델을 다시 한번 떠올려보면, 큰 그림은 전혀 보지 못하고 정해진 규칙에만 집착하는 단계에서 직관적으로 모든것을 파악하게 되는 단계까지의 패턴이 있다는 것을 알 수 있다. Expert Beginner 단계는 학습자가 큰 그림을 보지 못하는 단계 중에서 가장 마지막에 있다. 즉, 다르게 말하면 학습자는 자신이 Expert라고 착각할 수 있는 단계인 것이다. Competent 단계의 학습자는 자신을 Expert라고 생각하기에는 너무 많은 것을 알고 있다. 즉, 자신이 부족한 부분이 무엇인지를 알고 있는 것이다.
Advanced Beginner의 단계에서는 이것이 불가능한데, Dunning-Kruger 효과에 따르면 Advanced Beginner들은 “기술이 없는(unskilled)” 쪽에 가까우므로, “내가 이해할 수 없으면, 분명 쉬운걸꺼야” 라는 생각에 쉽게 사로잡히게 된다.

Advanced Beginner들은 결국 양갈래길에 놓이게 된다. 하나는 Competent로 나아가서 큰 그림을 보고 자신이 어디에 있는지를 자각하는 것이고, 하나는 자신들이 이미 Expert로 졸업했다고 생각하여 Expert Beginner에 속하게 되는 것이다. 당장은 그렇게 나빠 보이지 않을 수 있다.
다시 한번 나의 볼링 경험으로 돌아가서 내가 그 골목의 최고가 되었었다고 상상해보자. 처음에야 잘 못했겠지만, 따기 쉬운 열매들을 신나게 따며 빠르게 실력을 키워갔을 것이다. Dunning-Kruger 법칙에도 불구하고, 나는 스스로의 성장이 꽤 빨랐던 점을 감안하여 내가 볼링에 꽤 재능이 있다고 결론내렸을 수 있다. 그리고 한 걸음 더 나아가 내가 볼링 스킬의 정점에 올랐다고 꽤 합리적으로 (혹은 꽤 오만하게) 결론내렸을 수도 있다. 왜냐하면 주변에는 나보다 잘 하는 사람이 없으니까, 분명 내가 어떤 경지에 오른것이 아닐까, 라는 생각을 하게 되는 것이다.

이것의 가장 큰 문제는, 몇가지의 꼭 틀렸다고 볼 수는 없는 추론들이 나를 거짓된 성취감에 이르게 했고, 결국 나를 더 나은 성장으로부터 멀어지게 했다는 것이다. 볼링을 계속 하면서 나는 내 자신에 대한 긍정적 평가를 서서히 논리적 오류에 활용하게 된다. “나는 전문가야. 전문가는 뭐든 잘 하게 되어있고, 지금 하는 것도 모두 제대로 하고 있어” (논리적 오류에 대해서 조금 더 설명을 보태자면, 이것은 순환론, 혹은 선결문제 요구의 오류이다).

위의 그림은 드레이퍼스 모델에 기반한 상태들의 흐름을 표현하고 있다. 각 단계에서 학습자는 다음 단계로 넘어가거나 혹은 현 단계에 그대로 머물 수 있다(Novice나 Advanced Beginner는 내 생각에 그 단계에 그리 오래 머물 수 없으므로 제외하고). 다른 점이라면, 내가 이 그림에 Expert Beginner를 추가했다는 것이다.

성장을 위해서는 스스로가 아직 배울 것이 많고, 아직 목표에 도달하지 않았다는 사실을 스스로 인지해야 하므로 Expert Beginner는 더 이상 어떠한 진전도 이룰 수 없다. Expert Beginner 는 Advanced Beginner의 조금 더 위, 그렇지만 Competence보다는 조금 더 낮은 단계에 위치한다. 이것은 본인의 현 상태의 모순에 대해서 인지할 정도의 능력은 없지만, 반대로 Beginner로서 굉장히 많은 ‘연습’을 했으므로 Advanced Beginner보다는 조금 더 우위에 있기 때문이다. 만약 “10년의 경험인가 아니면 같은 경험을 10년동안 한것인가” 라는 말을 들어본 적이 있다면, Expert Beginner는 후자의 정점이다. Expert Beginner는 매주 똑같은 볼링 기술과 습관을 이용하면서 300점중에 160점을 따는 데에 달인이 되었다. 이것은 그가 160점이 최고의 점수라고 생각하고 있기 때문이다.

소프트웨어 업계의 Expert Beginner들

소프트웨어는, 당연하게도, 볼링과는 다르다. 볼링에서는 몇분 간격으로 피드백이 돌아오지만, 소프트웨어는 수 개월, 혹은 수년에 걸쳐 피드백이 돌아오는 경우가 많다. 여기서 내가 말하는 소프트웨어의 피드백이란 컴파일링이나 유닛 테스트 등이 아니라 프로젝트 단위를 말하는 것이다. 하나의 프로젝트를 진행하면서 개발자는 코딩, 소스코드 관리, 수정, 테스트, 그리고 이전의 디자인과 설계 등을 유지보수 하는 경험을 하게 된다. 만약 이 모든 과정을, 개발자가 운이 좋아 6개월 안에 모두 경험했다고 친다면 5년 후에는 10건 남짓의 애플리케이션 개발 경험을 가지게 된다 (이는 평균치로, 누군가는 이 기간동안 하나에 매진해 있을 수도 있고 누군가는 여러개를 할 수도 있다).

이는 곧 소프트웨어 개발자가 빠르게 성장하는 기간 (Advaned Beginner의 기간)이 몇주가 아닌 몇 년일 확률이 높다는 뜻이다. 그리고 이 기간동안 소프트웨어 개발자들은 이직과 승진을 거듭하게 된다. 빠르게 기술을 습득해 나가면서 소프트웨어 개발자 1 이나 소프트웨어 개발자 2를 거쳐 “주니어”(*역: 원래 Associate이나 주니어로 의역), “시니어”, 그리고 “리드” 혹은 “아키텍트”, 또는 “총책임”(Principal)이라는 직급을 넘나들 것이다. 즉 Dunning-Kruger의 법칙과 Advanced Beginner로서의 역경을 거치면서 전문가를 연상시키는 직급을 부여받고, 헤드헌터들로부터 “rock star”(*다크호스와 비슷한 어감) 혹은 “닌자” 등의 별명도 얻게 될 것이다. 이런 상황에서 이들이 Expert Beginner 단계로 자연스럽게 입장하는 것을 막을 수 있는 유일한 방법은 피어리뷰(peer review)와 개발자 커뮤니티와의 교류 뿐이다.

하지만 Advanced Beginner가 더 큰 커뮤니티와의 교류에 관심이 없고, 주변 동료들과도 별로 교류하지 않는다면 어떻게 될까? Daily WTF 사이트는 이런 예시들로 넘쳐 흐른다. 언제든 그렇듯이 다른 사람의 탓을 하면 손쉽게 인지부조화를 해소하고 현 상황에서 도피할 수 있기 때문에, 그들 역시 남탓으로 상황을 해결하려 한다. 이미 Expert 레벨에 도달하였으며, 더 이상 올라갈 곳이 없다고 생각하는 것이다. 그들은 이로서 Expert Beginner가 되고, 하나의 집단에서 오랫동안 안주하면서 높은 연봉을 받을 준비를 마친다. 주변 사람은 물론 그들 스스로도 그들이 훨씬 더 많은 것을 할 수 있다는 사실을 모르기 때문이다.

이번 글을 마치며

이렇게 Expert Beginner의 등장에 대한 이야기, 즉 그들이 어디서 나타나고 왜 성장을 멈추는지에 대해 탐구해 보았다. 이 시리즈의 다음 편에서는, 한명 이상의 Expert Beginner들이 모였을 때 어떻게 다른 재능있는 구성원들이 있음에도 불구하고 하나의 집단을 퇴행시키고 내부적으로 부패하게 하는지에 대한 이야기를 해 보도록 하겠다.

번역을 마치고

제가 이 글을 읽은 것은 작년 가을 쯤이었습니다. 매일같이 야근에 시달리고 하루하루가 벅차던 그 때 이 글을 읽고 다시 한번 마음을 추스렸던 기억이 나서, 오랜만에 글을 읽으며 번역해 보았습니다.
저에게는 나태해지려 할 때 마다 머릿속에 “Expert Beginner”라는 단어로 경종을 울리게 해주는 중요한 글이라, 작가님의 허락을 받고 번역해 보았습니다. 민감할 수도 있는 내용이여서 다양하게 받아들여질 것이라 생각합니다만, 저를 채찍질 하는 글이 되었듯이 다른 분들께도 도움이 되었으면 좋겠습니다. 학문적 단어가 많아 제 기준으로 이해하기 쉽게 의역이 많았음을 다시 한번 알려드립니다.
이 글은 2편으로 나뉘어져 작성되었지만, 속편은 아직 번역할 계획이 없습니다. 혹 요청이 많거나 제가 여유가 된다면 속편도 번역하도록 하겠습니다 :)
+ 번역 되었습니다. 링크를 확인해주세요 :)