오픈소스에 한걸음 더: 2018 오픈소스 개발자 이야기를 다녀와서

KakaoTalk_Photo_2018-07-07-20-57-06
한국 마이크로소프트

지난 6월 30일 토요일, OSS 개발자 포럼의 주최로 ‘2018 오픈소스 개발자 이야기’라는 주제의 세미나가 한국 마이크로소프트에서 열려 참석했다. 인프라 엔지니어로 일하던 시절, 개발자로 일하기를 열망하며 퇴근후 틈틈이 웹을 공부하고 ‘구글은 SKY를 모른다’, ‘오픈소스 소프트웨어 아키텍쳐’와 같은 책을 읽었었다. 그때만 해도 오픈소스에 대해 어렴풋이 알고있었는데 이런 책들을 통해, 그리고 뭔지 모르면서도 GitHub Explore를 기웃거렸던 경험을 통해 오픈소스에 대한 이해를 키워갔다. 그러면서 참 설레었다. 나도 언젠가 누군가에게 도움이 될 수 있는 소프트웨어를 만들고 싶다는 생각을 했다.

몇년이 지나 나는 지금 Frontend Engineer로 재미있게 일하고 있고, 오픈소스를 더 많이 사용하고, 더 많이 듣고 접하고 있다. 그럼에도 여전히 내가 어떻게 오픈소스에 기여할 수 있고, 오픈소스 소프트웨어를 만든다는 것은 어떤 의미이고, 이것으로 어떤 영향을 미칠 수 있는지 등 오픈소스를 아우르는 전반적인 것에 대해서는 이해가 많이 부족하다. 딱 이럴때 2018 오픈소스 개발자 이야기라는 매력적인 주제의 세미나가 Facebook을 훑던 중 눈에 들어와 바로 결제했다. 오후 1시부터 5시간이 넘는 시간동안 보고 느낀 것이 많았는데 이것에 대해서 정리해보고자 한다. 시작하기 전에, 정말.. 안타깝게도 세미나 당일 이천에서 11시에 출발해서 올라왔는데 교통이 너무 혼잡해 종민님의 발표부터 듣게되어 여기부터 후기를 작성하고자 한다. 정규님 죄송합니다..

김종민님의 ‘Elastic에서 Remote로 일하기’

Elastic에 대해서는 ElasticSearch를 여기저기서 많이 듣고 관련 오프라인 강의 세션도 몇번 들으면서 조금 알고있던 차였다. 종민님이 쓰신 ElasticSearch 책도 갖고있어서 종민님에 대해서도 조금 알고있었다. 제목에서 알 수 있듯이 종민님의 발표는 Elastic에서 원격으로 일하는 것의 다양한 면을 담고있었다. 언젠가 원격근무를 하고싶은 나에게 유익하고 재밌었던 시간이었다.

스크린샷 2018-07-06 오후 10.39.57

Elastic은 ElasticSearch이었던 사명에서 Search를 빼 현재의 이름이 되었다고 한다. 그래서 종민님의 말씀대로 구글에서 Elastic을 검색해보면 진성(?) ‘Elastic’ 말고도 고무줄 같은 것이 잔뜩 나온다..(피식했다) 발표를 들으며 깨달았던 것, 재밌었던 포인트들이 몇가지 있는데 이를 위주로 이야기 해야겠다.

Elastic이 돈을 버는 방법

오픈소스로 일군 회사는 대체 어떻게 수익을 내는지 궁금했었다. 소프트웨어를 파는 것은 아닐텐데 그럼 컨설팅이나 교육으로 버는 건가? 그러기엔 조금 적지 않을까? 라고 자문했었다. 알고보니 반은 맞고 반은 틀렸었다. 교육과 컨설팅이 있는 것은 맞지만 이외에도 기술지원과 유료 사용자 기능이 있었다. 기술지원은 지원하는 범위와 지원 시간에 따라서 가격이 책정되는듯 하다. Elastic에서 정기적으로 메일이 오는데 여태 자세히는 읽어보지 않았었다. 돌이켜보니 Subscription에 대한 내용과 기술지원에 대한 내용이 많았던 것 같다. 유료 사용자 기능은 뭔지 잘 모르겠지만 최근 ELK 이외에 Beats와 X-Pack 같은 전에 보지 못했던 제품군들이 눈에 띄었는데 당연히 유료 사용자라면 이런 추가적인 강력한 기능들이 제공되지 않을까 추측해보았다.

Elastic은 현재 약 800명의 직원이 있는데 Elastic의 제품을 사용하는 기업의 수에 비해 조금 적은 것은 아닌가하는 생각이 들었다. 기업의 종류와 국가도 매우 다양할텐데 직원이 그에 맞게 적절히 포진해 있는 것도 상당히 어려운 일이라고 느꼈다. 오픈소스 회사를 세워 수익을 어떻게 내는지 궁금했는데 조금 더 구체적으로 알 수 있었다.

원격으로 근무한다는 것

원격으로 근무하는 것이 어떤 것인지에 대해서 그간 여러 글들이나 세미나, Automattic에서 근무하시는 태곤님의 이야기를 통해 들었었는데 종합적인 장단점은 이런 것 같다.

우선 고정적으로 이동하는 시간이 사라지므로 시간적으로 더 여유가 있다. 이런 시간을 연단위로 계산하면 꽤 나올 것이다. 나의 경우, 하루 평균 출퇴근을 1시간으로 잡고 워킹데이를 200일로 잡으면 벌써 200시간이 나온다. 200시간이면 아주 많은 시간이다. 1시간이 넘는 경우가 대다수일 것이라 생각하면 정말 큰 장점으로 다가오지 않을까싶다. 다음으로, 개인이 가장 집중도가 높은 시간에 자율적으로 일할 수 있다. 낮이든 밤이든 본인이 가장 편한 시간에 일할 수 있다. 그리고 당연히 편하게 있을 수 있다.

그렇지만 이에 못지 않은 단점들도 존재하는데, 대표적으로 회의가 있다. 크고 작은 회의들을 Skype나 Zoom같은 툴을 이용해 진행할텐데 이게 생각보다 불편한 점들이 있다. 누군가 말을 하고 있으면 순간 interrupt 하기도 어렵고 순간순간 즉흥적으로 말하기도 어렵다. 화질 및 음질이 좋지 않을 수도 있어서 집중이 조금 어려울 수 있다. 그리고 아무래도 원격으로 근무하면 혼자 일하는 경우가 대부분이어서 회사 동료들과의 물리적이고 인간적인 소통이 결여된다. 얼굴을 보고 웃으며 이야기하기도 어렵고, 같이 식사나 맥주 한잔 하는 것도 없다.

종민님이 말하셨던 장단점도 이것과 크게 다르지 않았던 것 같다. 다만 단점에서 한가지 새로 배운 사실이 있는데, 동료들과 물리적으로 함께 일한다면 캐주얼한 대화를 가끔 하게 되는데 의외로 그것에서 배우는 점이 많다는 점이다. 생각해보니 정말 그런 경우가 많았던 것 같다. 요새 이런 이슈가 있었는데~, 이런 공부하고 있는데 이런 모임이 있더라~ 부터 시작해서 기술적인 이야기도 많이 나눴던 기억이 있다. 그러니 원격으로 일한다면 이런 부분을 놓치게 되는 셈이니 이것도 단점으로 작용하게 되는 것이다.

그리고 원격으로 일을 한다는 것은 필히 나에 대한 이해가 수반되어야 한다는 것을 느꼈다. 원격으로 일하고자 한다면 이렇게 일하는 것의 장점은 최대한 살리고 단점은 최대한 보완해야 할 것이다. 먼저 내가 혼자 대화없이 오랫동안 일을 할 수 있는지부터 알아야할 것이고, 없어진 이동시간을 어떻게 활용할 것인지, 나는 어느 시간대에 일하면 가장 능률이 좋은지, 일을 밀도있게 집중해서 단번에 끝내는 것 혹은 여유있게 천천히 하는 것 중 어떤 것이 내게 편한지 등 나 스스로에 대해 이해해야 하는 것이 많다. 그리고 동료들과의 인간적인 소통도 어떻게 보완할 것인지도 생각해봐야 한다. 참 ‘원격으로 근무한다는 것’이라는 짧은 한 문장에 많은 내용이 함축되어 있는 것 같다.

전에는 몰랐던 다양한 Software Engineer 직군들

Software Engineer 안에서도 다양한 직군들이 있는 것을 보고 놀랐다. Solution Architect, Developer, Infra Engineer는 알고 있었는데 Community Engineer, Support Engineer, Education Engineer라는 직군은 처음 알았다. 이름을 보고 어떤 일을 하는지 감이 오기는 했는데 그걸 알고나니까 일을 더 다양하게 할 수 있다는 것을 깨달았다. 내가 어떤 일을 잘 하고 좋아하는지 이해하고 있다면 그것에 맞춰서 이런 직군들을 선택해볼 수 있겠다는 생각을 했다. 가령, 전에는 단순히 Software Engineer라면 항상 기술을 다루고 만드는 일에만 관련이 있을 거라고 생각했는데 이제보니 나는 기술 자체를 만들고 활용하는 것보다는 이 기술을 다른 엔지니어들에게 잘 전달하고 이것으로 무얼 할 수 있는지 설명하기를 더 잘 하고 좋아한다면 Community Engineer나 Support Engineer를 하는 것이 좋을 수도 있을 것이다. 물론 아직 정확히 이 직군들이 어떻게 다른지는 잘 모른다. 전에는 단순히 알고있던 것을 이번 기회를 통해 좀더 자세히 알게되었고 나도 지금은 만들고 활용하는 것만 해왔는데 내가 잘 할 수 있는 것이 무엇인지 다시 한번 생각해봐야겠다.

변정훈님의 ‘오픈소스 생태계 일원으로서의 개발자’

개발자가 아니었을때 혼자 공부하면서 모르는 것을 찾아보면 변정훈님의 블로그가 매번 나와서 많이 참고하고 댓글도 달았었는데 눈앞에서 직접 뵙고나니 감회가 무척 새로웠다. 아웃사이더님이라니!

이 슬라이드 쇼에는 JavaScript가 필요합니다.

아직도 기억나는 것이, 당시에 git stash와 remote branch를 찾아보고 있었는데 사진처럼 동일한 블로그가 계속 나와 git 관련 글들은 정훈님의 블로그를 많이 참고했다.

정훈님은 오픈소스 생태계를 어떻게 바라보고 기여하는지에 대해 이야기 해주셨다. 근데 GitHub 티셔츠를 정말 좋아하시는 것 같다.

우리는 이미 오픈소스 생태계 안에서 살고있다

나는 지금껏 어떻게 하면 오픈소스 생태계에 입문할 수 있을까, 아직 부족한 게 너무 많은데 어떻게 기여할 수 있을까라고 생각해왔었다. 그런데 정훈님이 이미 우리는 모두 오픈소스 생태계 안에서 살고있다고 하는 것이 아닌가. 놀랐다. 그간 나는 오픈소스와는 관계가 아직은 먼 사람이고 어떻게 하면 발을 담을 수 있을까라고 단순하게만 생각하면서 계속 오픈소스에 관심을 두는 것을 망설였던 것 같다. 허나 이미 안에 들어와있고 이 생태계를 활용하면서 살고있다는 것을 깨닫게 되니 마음이 한결 가벼워졌다. 너무 딱딱하게 생각해왔었는데 이번을 계기로 내가 자주 사용하는 라이브러리들부터 되돌아보고 싶다는 생각을 했다. 가령, 내가 가장 많이 사용하는 API에 대한 Docs는 어떠한지, 설명이 추가되면 좋지는 않을지, 현재의 모습은 어떤 과정을 거쳐 이루게 된 것인지, 현재 가장 이슈가 많은 부분이 어느 것인지 등에 대해 먼저 살펴보면 재미있을 것 같다는 생각을 했다.

어떤 프로젝트를 하나 선택해서 시작한다기 보다는 조금씩 천천히 빠지게 되는 것

이 문장도 위 단락과 깊이 연결되어 있는 것 같다. 정훈님의 발표를 듣고 위에서와 같이 생각을 다시 해보게 되었는데 아래와 같은 흐름으로 생각이 바뀌게 되었다.

  • 내가 어떻게 오픈소스에 기여할 수 있을까? 잘 모르겠다. 아직은 아닌것 같은데..
  • 나중에 하게된다면 어떤 프로젝트를 선택해서 기여하면 좋을까? 잘 모르겠다.
  • 그런데 이미 내가 이 생태계 안에서 살고있다고? 아 내가 이미 도움을 크게 받고 있구나. 그렇다면 내가 지금 자주 쓰고있는 것들에 무엇이 있었지?
  • 아 내가 A라는 라이브러리의 B라는 API를 자주 쓰는구나. 이게 어떻게 동작하는지 한번 살펴보면 어떨까? Docs를 이렇게 보충하면 어떨까?…

전에는 무얼 하나 선택해서 시작해야 한다는 생각이 강해서 그런지 그것에서 오는 왠지 모를 압박감이 있어서 선뜻 선택하지 못했고 그래서 Docs나 코드 한번 살펴보지 않았었다. 그런데 이렇게 생각이 바뀌게 되니 정훈님의 말씀처럼 내 주위를 먼저 둘러보고 그것에 자연스럽게 관심을 갖게되어 천천히 기여하는 흐름이 훨씬 자연스럽다는 생각을 했다.

그리고 기여는 꼭 코드만으로 하는 것은 아니라는 말이 기억에 남았다. 이렇게 자연스럽게 관심을 갖고, 오탈자가 있으면 고쳐주고, 불필요한 개행이나 문법 오류가 있으면 고쳐주는 등의 문서화 그리고 이슈 리포팅 등의 다양한 활동이 모두 이 오픈소스를 더 낫게 만드는데 도움이 된다는 것을 깨달았다.

이력서를 받다보면 GitHub 활동을 꾸준히 하는 사람이 드물어서 아쉽다

위와 같은 말씀도 하셨는데 생각보다 활동하는 사람의 비중이 적어서 놀랐다. 그래도 지원하는 사람 중 절반은 되지 않을까 생각했었는데 꾸준히 활동하는 것이 중요하다는 것을 다시 한번 느꼈다. 대단한 것을 만드는 게 아니더라도 GitHub에 꾸준히 무언가를 올리며 활동을 한다는 것은 적어도 내가 무엇에 관심이 있는지, 어떤 언어 및 기술을 사용하는지, 얼마나 꾸준히 하고있는지 등에 대해 나타내는 것이니 안한다고 해를 입진 않겠지만 다른 개발자들과 교류하고 구직할 때에도 도움이 되지 않을까? Interviewer의 입장에서도 문장 뿐인 이력서만 보는 것보다는 GitHub 활동과 코드를 직접 볼 수 있다면 Interviewee에게 있어서는 더 잘 어필할 수 있는 좋은 도구가 되지 않을까한다.

송태웅님의 ‘해외 오픈소스 컨퍼런스 발표와 참여’

스크린샷 2018-07-07 오후 5.55.12

태웅님은 Linux Foundation – OSSEU17에 스피커로 참여하신 경험에 대해 이야기 해주셨는데 비록 같은 분야가 아니라서 구체적인 것은 잘 모르지만 그럼에도 느낀 것이 많았다.

꼭 Professional level이어야만 하는 것은 아니다

아직 국내 컨퍼런스에서 발표할 생각도 해보지 못했던 나로서는 해외 컨퍼런스에서 발표한다는 것은 대단하고 멀게만 느껴졌다. 태웅님의 발표에서 기억나는 것 중 하나는 이런 해외 오픈소스 서밋 및 컨퍼런스에서 스피커로 참여하는 것이 꼭 전문가 수준이어야만 하는 것은 아니라는 점이다. 여전히 스피커로 나서는 것 자체가 도전적인 과제이지만 어떤 프로젝트를 진행하면서 겪었던 문제, 이슈, 해결 및 대처 방법 등에 대한 경험 그리고 그 과정에서 느끼고 배운 것을 공유하는 자리가 될 수도 있다는 점을 알게되었다. 여기까지 생각이 미치니 틈틈이 생각하고 기록하는 습관이 중요하다는 생각이 들었다. 만약 올해 말 혹은 내년 초에 있을 서밋에 스피커로 참여하고자 한다면 무슨 프로젝트를 진행했는지, 어떤 문제점들이 있었는지, 그것을 어떻게 받아들이고 해결했는지, 무엇을 배우고 깨달았는지, 비하인드 스토리는 없었는지 등을 적어도 기억을 하고 어떤 주제로 이야기를 풀어나갈지 정리할 수 있어야하기 때문이다.

영어는 여전히 중요하다

후배들에게 영어를 매일같이 하라고 말하고 다닐만큼 직업의 종류에 상관없이 영어가 얼마나 중요한지 잘 이해하고 있었는데 태웅님처럼 해외 서밋에 스피커로 나가 영어로 자신의 경험을 전달하고 질문을 주고받으며 다른 개발자들과 잘 이야기하기 위해선 영어를 잘 해야한다는 생각을 색다른 느낌으로 다시 하게 되었다. 구글 검색에서 찾을 수 있는 좋은 글과 문서들이 대부분 영어로 되어있기 때문에 영어를 잘 하면 좋다는 말은 이제는 흔하지만 만약 내가 당장 다음달에 유럽에서 영어로 발표를 해야한다면 느낌이 어떨까? 질문도 오고 중간에 쉬면서 다른 사람들과 이야기도 해야할텐데 상상하는 것만으로도 벌써 떨린다. 물론 이것이 꼭 영어 때문이라기 보다는 발표를 한다는 점에서 떨리는 것도 있을 것이다. 이런 색다른 관점에서 생각해보니 영어는 정말.. 여전히 중요하다.

김영근님의 ‘파이썬, 파이콘, 파이썬소프트웨어재단’

영근님은 파이썬 커뮤니티가 파이콘 등을 통해서 교류하고 성장하는 과정에 대해서 이야기 해주셨는데 중간중간 너무 웃겨서 몇번을 웃었는지 모르겠다. 문장의 호흡이 짧은데 툭툭 개그를 치시는게 정말 웃겼다. 그러면서 표정은 또 진지하심.

건강한 커뮤니티

발표의 많은 내용이 파이썬 커뮤니티가 어떻게 사람을 대하고 그것을 통해 어떻게 성장해왔는지에 대해 다루었다. 무엇보다 감명 깊었던 것은 파이썬 커뮤니티의 정신이었다. 어떻게 사람을 대하고, newcomers를 어떻게 반기는지, 또 그들이 커뮤니티에 안착할 수 있도록 다양한 방법으로 돕고, 어떠한 차별없이 다양성을 존중하고 장려하는 문화가 정말 너무 좋았다. 이런 문화가 있는 커뮤니티라면 꼭 파이썬이 아니어도 그냥 들어가서 눌러앉고 싶은 생각이 절로 든다. 그래서 영근님의 발표를 들으며 파이썬이 갑자기 더 좋아졌다. 차별없고 다양성이 존중받는 그 어느 곳이든 모두 아름답다.

코드만이 오픈소스에 기여하는 방법은 아니다

변정훈님의 말씀과 닮은 점이 있었던 문장이다. 이미 파이썬을 사용하고 있는 것 자체가 파이썬과 파이썬 커뮤니티에 기여하고 있다는 점은 다시 한번 놀랍다. 누군가 만약 파이썬을 활발히 사용하고 있다면 다른 누군가가 모르는 것이 있을때 알려줄 수도 있고 파이썬이 보다 나은 언어가 될 수 있도록 개선안을 제시할 수도 있을 것 같다. 이외에도 커뮤니티를 알리고, 문서를 번역하고, 이슈를 리포팅하고, 문서화를 돕는 것 모두 오픈소스에 기여하는 일이라는 점이 기억에 남는다. 점점 나도 기여해보고 싶다는 생각이 강해지는 것 같다.

이문수님의 ‘아파치 제플린, 프로젝트 시작부터 아파치 탑레벨 프로젝트가 되기까지’

문수님은 어떻게 아파치 제플린 프로젝트를 시작했는지, 그 과정에서 어떤 일이 있었고, 어떻게 아파치 탑레벨 프로젝트가 되었는지에 대해 이야기 해주셨다. 발표 내용도 재밌었지만 말하시는 내내 웃는 인상이셔서 나도 모르게 계속 웃고 있었던 발표였다.

작게 시작하는 것

크게 성장한 많은 프로젝트들의 공통적인 특성인 것 같다. 그리고 유니콘 스타트업들의 시작에서도 비슷한 면이 있는 것 같다. 모두들 작게 시작했다는 점이다. 아래와 같은 흐름인 것 같다.

처음 어떤 자그마한 문제나 의문점에서 프로젝트를 작고 빠르게 만든다. 그리고 바로 공개한다. 운이 좋으면 크고 작은 피드백들이 오기 시작한다. 만든이는 이런 피드백을 보고 신나서 기능을 추가하고 없애고 수정하면서 더 개선된 형태로 프로젝트를 발전시킨다. 다시 피드백이 온다… 이하 사이클 반복

발표를 들어보니 아파치 제플린도 비슷했다. 하둡과 관련된 생태계(정확히 어떤 생태계였는지 기억이 ㅜㅜ)에서 비어있는 부분을 발견하고 그 부분을 채우면 어떨까하는 생각에 프로젝트가 시작된다. 얼마간 놔뒀다가 다음 해에 다시 빠르게 만들고 공개한다. 얼마후 반응이 오기 시작한다. 신난다. 개선한다… 반복

신기하다. 거창하게 시작하는 것보다 작게 시작하면서 사람들에게 정말 필요했던 것을 만들고 그것이 좋은 반응을 얻으면 그때부터 성장의 길이 열리는 것 같다. 뭔가 Lean 개발 방법론과 궤를 같이 하는 것 같은 생각이 들었다.

완벽한 코드 보다는 돌아가는 코드

발표를 잘 이해하지 못한 것일 수도 있는데 아파치 제플린 프로젝트가 커져가면서 더 많은 가치를 빠르게 전달하기 위해 완벽한 코드 보다는 돌아가는 코드에 집중했다는 기억이 있다. 문수님도 이를 두고 좋지 않은 코드가 당시에 많았었다고 회상하시던 기억도 난다. 물론 그 정도가 얼마만큼을 의미하는 것인지는 알 수 없지만 적어도 완벽한 설계를 바탕으로한 코드에 집착하는 것 보다는 돌아가는 코드를 빠르게 만듦으로써 프로젝트의 성장을 우선시한다는 뉘앙스로 다가왔다. 코드의 가독성 개선이나 최적화 등의 리팩토링은 프로젝트가 어느정도 궤도에 오른 뒤 밟아나가도 된다고 받아들이면 되는 것일까? 아마 그렇지 않을까싶다. 물론 처음부터 좋은 설계 위에 좋은 코드를 쌓으면 더할나위 없이 좋겠지만 꼭 좋은 프로젝트/서비스가 항상 좋은 코드로만 시작하고, 그런 코드로만 구성되어 있지는 않으니까 말이다.

소감

이렇게 후기를 마쳤다. 이야기만 들었을 뿐인데 오픈소스에 한걸음 더 다가간 것 같다. 내가 살고 있는 세상이 생각보다 훨씬 더 오픈소스에 영향을 받고있음을 느꼈다. 이제 개발자로 일한지 14개월이 되었는데 지금은 부족하지만 연차가 늘어갈 수록 더 실력을 쌓으면서도 코드 뿐만이 아닌 여러 방면으로 오픈소스에 기여해야겠다는 다짐을 해본다. 좋은 배움과 좋은 계기가 남는 알찬 세미나였다. 이런 세미나를 기획하고 준비한 OSS 개발자 포럼과 황금같은 주말 시간을 내어 발표해주신 모든 발표자분들께 감사한 마음이 든다. 나는 오늘도 도움을 받는다. 나도 조금씩, 더욱 도움이 되는 사람이 되기를.

참고하면 좋은 링크들

http://it.chosun.com/site/data/html_dir/2018/05/03/2018050385084.html

 

세미나 당일에 찍은 사진들

Advertisements

되돌아보는 2017년

 

File_000 (1)

벌써 2018년이라니!

그동안 글을 써오면서 한 해를 돌아보는 글을 남긴 적이 없어 다사다난 했던 해였던만큼 이번 글에서는 2017년에 무엇을 했는지 굵직하면서도 구체적으로 되돌아보자.

KakaoTalk_2017-12-31-13-57-26_Photo_52
욕심은 커서 많이 적었는데 대부분 세모 아니면 fail..

무엇들을 되돌아보아야 할까. 2017년 1월에 작성한 위의 플랜을 바탕으로 굵직한 포인트를 먼저 뽑아보면 개발, 특히 React, 머신러닝, 영어, 독서, 공부, 운동 등이 있다. 좋아라 하면서도 시간을 많이 쏟은, 내게 많이 중요한 것들 위주로 돌아보며 무엇을 왜 했는지, 하고 난 결과는 어땠는지, 좋았는지 그렇지 않은지, 어떤 감정을 느꼈는지 등에 대해서 풀어내보자. 2년, 5년, 10년 뒤 이 글을 다시 보며 내가 누군지를 계속 상기하기를 바라며..!

JavaScript Based Development: 이게 다 뭐야..?

먼저 가장 머리가 아픈 개발 이야기부터 시작해보자. 어느덧 자바스크립트로 웹 개발을 시작한지 2년이 되어간다. 2015년 말 AngularJS로 모던 웹을 접하고 전 직장에서 나오기 전인 작년 9월까지 앵귤러로 이것저것 만들어 보았다. 그 다음 접한 것이 React. 앵귤러 때도 그랬지만 React를 할때 디렉토리 구조부터 잘 이해가 가지 않았다. 공식 홈페이지의 다큐먼트, React 관련 책, 블로그들을 보며 이것저것 시도할 때마다 디렉토리 구조가 모두 달랐다. 무엇이 무엇을 불러와 사용하고 최종적으로 어떻게 빌드되어 어떤 폴더가 deploy 되는지 등 전반적인 개념이 많이 부족했었다. 그때 깨달았다. 아, 난 웹에 익숙치 않은 게 아니고 그냥 개발 자체가 익숙치 않구나.. 사실 구조야 편리성에 따라, 취향에 따라 만들기 나름인데 당시엔 아득했다.

그 뒤 React로 좀 더 복잡한 것을 만들어 보려고 찾아보니 Flux가 나오고 Webpack, Babel이 나오더니 Redux, React Router… 등이 갑자기 쏟아져 나왔다. 이때 몇개 공부 해보다가 소리를 질렀다. 아니 난 React를 해보고 싶은데 뭐가 이렇게 많아! 입문자 중 나만 그러지 않았으리라 짐작.. 아니, 빌어본다.. 그렇게 찔끔찔끔 필요한 것들을 공부해가며 만들어 보기도 하면서 익혀나갔다. 그런데 생소한 내용이 양까지 많으니 하루에도 머리에 과부하가 몇번이고 찾아왔다. 그때 몇번 뵈었던 개발자분이 React를 두고 알면 알 수록 헬이라고 했던 게 떠올랐다. 시간이 흐른 지금은 이때보다는 느껴지는 헬의 정도가 덜하긴 하지만 react-router가 v4로 버전이 올라가고, redux-thunk에서 redux-saga로 옮기고, webpack으로 안하던 code splitting 등을 해보면서 과부하 챗바퀴는 또 시작되었다..

React + Redux + Babel + Webpack = Awesome? Nah, headache..

프론트엔드는 적응이 좀 됐다 싶으면 갑자기 새로운 것들이 쏟아진다. 그리고 그것들은 매번 큰 변경 사항을 내포한다. 기능이 변하기도 하고 패러다임이 뒤바뀌기도 해서 따라가기 벅찬 것이 솔직한 심정이다.

그렇게 공부하다보니 React는 프레임워크가 아닌 UI Library 인지라 이 모든 것들이 필요에 따라 혹은 취향에 따라 조합되어 사용된다는 걸 이해 하기까지 오랜 시간이 걸렸다. 어느 정도는 넓게 보아야 이것들이 다 무어고 왜 이렇게 되어있는지 이해를 하는데 이건 적당히 넓게 보기까지 너무 많은 계단이 있는 것처럼 느껴졌다. 그래서 혹시 이걸로 진입장벽을 만든 것은 아닐까 생각하기도 했다.

React: 높은 자유도

React로 그렇게 1년 가까이 개발을 해보고나니 React는 마치 개발자로서 스스로를 돌아보게 만드는 선생님 같다고 느꼈다. 라이브러리인 만큼 자체적으로 지원되지 않는 것이 많아 조금이라도 복잡한 것을 설계해야 할때 무엇이 필요한지, 필요한 것들을 어떻게 조합해서 사용해야 할지에 대해서 개발자가 충분히 알고 있어야 한다. 몰라도 만들 수 있지만 앱이 기능하는 범위나 특징에 비해 과도하게 많은 기술들이 사용되었다면 그것을 사용해봤다는 점을 제외하고는 오버 엔지니어링이자 시간과 에너지의 낭비일 것이다. 특히 실제 운영되는 서비스라면 그 결과의 크기는 더욱 커질 것이다.

React와 관련 기술들로 개발을 해보니 어떤 서비스를 만들지, 이 서비스가 어떤 것인지 등 그 특성을 명확히 이해한 뒤 내가 편하면서도 적합하다고 생각하는 기술의 조합을 이용해 앱을 설계하고 작성하는데 큰 도움이 되는 것을 느낀다. 아마 다른 프레임워크처럼 React가 앱을 만드는데 있어 강력한 틀과 constraints를 갖고 있었다면(자유도가 낮았다면) 이런 느낌은 덜 받았을 거라는 생각이 든다. 높은 자유도를 지닌 만큼 많이 허덕였고 허덕인 만큼 갭을 메우면서 알게 된 점들이 많았다.

이런 점에서 고맙지만 참 고된 시간이었고 지금도 고되기는 마찬가지지만 이 많은 정보의 범람 아니, 정확히는 기술의 범람 속에서 무얼 보고 무엇에 관심을 가져야할지 잘 모르겠는 것은 매한가지다. 다만 여기서는 최근에 읽은 Paul Graham‘해커와 화가’라는 책에서 힌트를 얻을 수 있었다. 책에 따르면, 어떤 언어가 좋다고해서 꼭 그 언어가 유명해지지는 않는다. 다만 영향력 있는 소수의 개발자들(폴형은 해커라 칭했다)이 판단하기에 충분히 좋은 언어라면 그 언어는 유명해지고 그 언어보다 기능적으로 더 우월한 언어가 있더라도 이 언어가 더 많은 인기를 누리고 더 오래갈 것이다. 즉, 최소한 여기서 얻을 수 있는 확실한 사실은 유명한 것은 충분히 좋고오래갈 수 있을 가능성이 크다는 것이다. 논외지만 이것은 개발자에게 꽤 중요한 포인트라고 생각한다. 기껏 시간과 노력을 투자한 기술이 인기를 잃어 더 이상 쓰이지 않는다면 커리어에 있어서 분명 악영향을 끼칠 것이기 때문이다. 물론, 많은 기술들이 그렇듯 큰 형태와 패러다임을 같이 하는 경우라면 내가 쓰던 기술이 당장 없어져도 큰 무리없이 다른 기술로 옮겨갈 수 있을 것이다.

나는 어떻게 공부했는가

위에서 React와 프론트엔드 진영에서 공부하고 만들며 느낀 것들에 대해 이야기했는데 입문자였던 내가 어떻게 공부를 했었는지 되돌아보는 것도 좋을 것 같다. 2~3년차가 되었을때 이때 공부했던 방식을 보며 좀 더 진화된 방식으로 공부하기를 바라며..! 근데 뭔가 React를 처음 공부한 것에  대한 회고라 분노로 가득 찰 것 같다.

먼저, 누구나 그렇듯 React의 공식 문서를 보았다. 이해가 안됐다. 지금도 이때 이해가 안됐을 때의 그 느낌을 생각하면 부들거린다. tender 말고 oscillate다. 정말 몸이 진동했음. 주먹쥐고 모니터를 노려봐서.. 도대체 저때는 무엇 하나 처음부터 단박에 이해되는 것이 없었다. 지금 돌이켜보면 AngularJS가 제공해주던 MVC적인 사고방식과 양방향 데이터 바인딩에 익숙해져 있었고 그전에도 Java로만 개발했었기 때문에 React의 Component Composition과 Unidirectional Data Flow 사상은 너무나 신세계였다. 아마 사고의 전환에서 느낀 생소함과 어려움이 원인이라면 원인이 되지 않았을까 추측해본다.

그렇게 공식 문서로 조금 감을 잡은 뒤(Thinking In React 파트가 도움이 컸다) Pro React라는 책을 훑으며 다시 고통받았다. 꽤 충실한 배경 설명과 많은 코드랩이 있어 React를 익히는 데에 좋은 책이라 생각한다. 물론 양이 많아서 문제다. 좀 적당히 했으면 좋겠는데..

그리고 책을 조금씩 보면서 궁금한 것이 생길때마다 아래와 같은 블로그들과 공식 문서를 참고했다.

이외에도 모르거나, 어렵거나, 헷갈리거나, 단순히 궁금한 것이 생기면 구글링을 한뒤 여러 문서를 보고 마음에 드는 것을 골라 에버노트에 정리해놓고 필요할 때마다 찾아보며 공부했다. 처음에는 부분 부분 골라서 보고 바로 적용해보는 방식으로 공부했으나 이내 공부하는 이 기술이 어떤 배경에서 생겼고 어떤 함수나 API가 왜 이런 형태로 생기게 되었는지 등의 맥락에 대한 이해가 많이 떨어지는 것을 느끼고 배경지식이 많이 부족한 지식일 수록 가능한 문서 전체를 읽고 맥락을 이해한 뒤 다시 모르는 것이 생기면 부분적으로 재학습하고 사용해보는 방식으로 공부하는 방식을 바꾸었다. 물론 또 시간이 지나 배경지식이 더 쌓이고나서 내게 더 알맞은 방식을 찾게 되면 다시 방식을 바꾸게 되지 않을까싶다.

그 다음은 스터디. MERN 스택을 공부하고 이것저것 함께 만들어보는 스터디 두개를 만들어 각각 4개월, 6개월 정도 운영했다. 각자 아는 것의 내용과 정도가 다르지만 같은 것을 함께 공부함으로써, 매주 공부하고 만든 것에 대해 코드 베이스로 이야기를 나눔으로써 혼자 공부하면 알기 어려웠을 것들을 알게 되고 다른 사람들의 생각을 알 수 있어 좋은 경험이었다. 그래서 앞으로도 React를 비롯해 다른 공부하고 싶은 것이 생기고 여유가 생긴다면 다시 스터디를 만들어보거나 다른 스터디에 참여해 공부하면 좋을 것 같다. 아 그리고 좋은 사람들도 알게 되는 점도 빼놓을 수 없다. 다들 잘 지내시죠!

이렇게 조금은 React에 대해 알게 되고 재미를 더 느끼게 되었을때 개인 프로젝트를 조금씩 만들기 시작했다. 아무래도 앞으로 만들게 될 프로젝트들도 대부분 Node 기반에 React를 사용하게 될 것 같아 Velopert님의 강의를 참고해 간단한 React-Node 보일러플레이트를 만들었다. 그리고 최근에는 React Native에 관심이 생겨 프로젝트를 하나 만들어 공부해보고 있다. 이전에 만든 프로젝트들은 커밋을 안한지 너무 오래되어 가슴이 아프다… 보일러플레이트도 그 중 하나다. 추석 내내 삽질한 webpack v3 config 설정 관련 프로젝트도 아직 병합하지 못했다. 빨리 업데이트를 하자. 해가 바뀌어 가는데 큰일이다. 이번 회고록을 통해 다음 해에는 기존 프로젝트들을 가다듬고 공부하고 싶은 것들을 바탕으로 또 어떤 새로운 개인 프로젝트를 해나갈지 정하고 꾸준히 커밋을 해야겠다.

마지막으로 알고리즘을 빼놓을 수 없는데, 직장을 옮기기 전에 Leetcode에서 조금씩 문제들을 풀며 자료구조와 알고리즘을 가다듬었는데 회사를 옮기고 스프린트를 시작하면서 멀어지게 되었다. 이미 React 만으로도 머리는 너덜거렸던 것이다..라고 변명을 해보지만 일주일에 하나씩 풀었으면 56 문제는 풀었을텐데 아쉬움이 크다.

알고리즘에 대해서는 한가지 더 이야기하고 싶은데, 알고리즘에 대한 중요성은 절절히 느끼지만 서비스를 만드는 것에 집중하다보면 어느새 뒤로 밀려나있는 경우가 많았다. 왜 그런 경우가 많이 생겼는지, 어떻게 지속적으로 환기시키며 가다듬어 나갈 수 있을지 고민을 해야할 것 같다. 진짜 2018년이다 이제.

말 많은 Algorithm

자연스럽게 다음 주제는 알고리즘이다. 요새 페이스북이나 여러 개발 관련 글들에서 알고리즘이 그렇게 많이는 중요하지 않다는 뉘앙스의 내용을 보았다. 그간 서비스를 만들면서 연쇄적으로 동작하는 기능이나, 여러 백엔드 시스템과 연계해야 하는 기능 등을 작성해야 하는 일들이 생겼다. 이때 Brutal하게 생각나는대로 만들어보니 결과적으로 작동은 했으나 가독성과 구성 면에서 잘 짜여진 코드가 아닐 때가 있었고 나중에 다른 기능과 연계하거나 개선 및 수정하는 등의 경우가 생겼을 때 이 코드 때문에 더 많은 시간을 들여야 했던 일들이 생겼다.

알고리즘을 어느 범위로까지 확장시켜 생각하느냐에 따라 이야기가 많이 달라지겠지만

  • 무엇을 만들지 혹은 문제가 무엇인지 정의하고
  • 필요한 것을 도출한 뒤
  • 원하는 결과를 얻는다

라는 맥락에서 보면 알고리즘을 꼭 코드 레벨에 국한시켜 생각할 필요는 없지 않을까싶다. QED(양자전기역학)를 만든 Richard Feynman이 말한 알고리즘에 관한 글이 이것을 잘 설명해준다. 무엇을 만들어야 하는지, 이 코드가 어디까지 영향을 미치는지, 다른 도메인과 어떻게 연계해서 만들어야 하는지 등을 잘 생각한 뒤 만들었다면 조금은 다른 결과를 얻지 않았을까 생각해본다.

코드로서 기능하던, 아키텍쳐 레벨에서 기능하던 큰 맥락에서는 궤를 같이 하므로 좋은 서비스를 잘 만들고 잘 운영하기 위해서는 이러한 알고리즘 혹은 알고리즘적인 사고가 어느 정도는 수반되어야 하지 않을까.

그리고 Machine Learning

개인적으로 머신러닝에 호기심이 있었다. 데이터를 갖고 어떻게 학습하는 걸까? ‘학습한다’는 것의 구체적인 의미가 뭘까? 데이터들에서 패턴을 찾아내어 수식화하는 것일까? 그럼 일종의 방정식을 유추하거나 만들어낸다는 것인가? 그렇다면 통계학과 큰 차이는 무엇일까? 통계학적 분석 작업을 사람이 하는 것에서 기계가 하는 것으로 옮겨가는 것을 의미하는 것인가? 학습한 것을 서비스에서 활용하려면 파이프라인 같은 것으로 시스템을 설계하는 것일까?..

이런 종류의 질문들이 떠올랐고 뭘 어떻게 학습한다는 것인지 전혀 모르겠지만 통계적인 관점을 일상 생활이나 관심 분야에 적용했을때 예상치 못한 재미있는 결과들을 책을 통해 여럿 접했던지라 자연스럽게 머신러닝에 관심을 갖게 되었다. 그래서 결국 Coursera를 오랜만에 열어 Andrew Ng 교수의 Machine Learning Course를 등록했다. 시작한지 2주만에 후회를 했다.. 프론트엔드만 해도 공부해야할 것들이 넘쳐나 허덕이고 있었는데 갑자기 안하던 미적분에 생소한 머신러닝 개념까지(아무리 Introduction level이라 해도..) 이해하느라 힘들었다. 그렇게 거금 79$를 들여 강의를 듣기 시작해 세달 정도가 지나 다행히 모든 시험을 마치고 해당 과목의 Certificate을 얻을 수 있었다.

스크린샷 2017-12-31 오후 3.05.04
79$를 결제하고 들으면 더 잘 듣게 된다는 남세동님의 말을 적극 따랐다.

 

당연한 이야기지만 아직 데이터 전처리를 어떻게 해야하는지, 서비스에 적용하려면 어떤 과정을 거쳐야 하는지 모른다. 그럼에도 이 수업을 끝까지 듣게 된 것에 대해 보람차게 느낀다. 여기엔 두가지의 이유가 있다.

첫째로, 너무 재밌다. 멋진 테크 기업들 덕분에 TensorFlow를 비롯해서 많은 wrapper들이 나왔고 그만큼 다양한 방식으로 높은 추상화가 되어있어서 머신러닝의 수학적인 부분까지 정확히 모르더라도 함수 두세개만 연달아 쓰는 것만으로도 Andrew Ng 교수의 집값 예측 예제처럼 꽤 재미있는 결과를 만들어낼 수 있다. 어떤 데이터를 어떻게 학습시켜 어떤 결과물로 보여줄지를 신박하게(?) 잘 생각해보면 전문가 수준이 아니어도 재미있고 유용한 것을 만들어볼 수 있을 것 같다. 당장 Tensorflow Korea 페이지나 Reddit을 보아도 작지만 재밌는 것들이 많다. Sung Kim 교수님 재밌는 것들 많이 올려주셔서 감사합니다.

둘째로, 지식만을 똘똘 뭉쳐 전달하는 강의나 수업 보다도 아주 복잡하고 어려운 지식일지라도 이것이 얼마나 재미있고 세상에 도움을 줄 수 있는지 등을 쉬운 언어로 잘 풀어내는 강의가 어떤 관점에서는 더 의미있고 강력하다. 이런 강의는 그 분야에 수강자로 하여금 큰 내적동기를 불러 일으킬 수 있고 흥미와 호기심을 간직한 체 오랫동안 재미있게 공부할 수 있는 원동력을 제공한다. 그래서 나도 세달이라는 시간을 들여 출퇴근 시간을 이용해 공부해서 당장 실질적으로 할 수 있는 것은 없지만 앞으로도 계속 관심을 갖고 공부하고 여유가 있을때 이것저것 만들어보고 싶은 큰 내적동기를 얻었다. 그래서 보람차다. 또 재밌다. 사랑해요 Andrew..

스크린샷 2017-12-31 오후 3.51.59
2017년 제일 멋있는 형이다.

2018년에는 남세동님의 멋진 가이드라인을 보고 Python과 Keras를 공부해보고 이것저것 만들어볼 생각이다. 여기에 대해서는 다른 글을 통해 무엇을 어떻게, 어떤 순서로 공부할 것인지 그리고 무얼 만들어 볼지에 대해 다뤄야겠다. 그리고 만들고 나서는 결과에 대한 회고 또한 작성하는 시간을 가져봐야 하겠다.

요새는?: 무얼 하는가?, 무얼 공부하고 있나?

최근에는 webpack을 이리저리 뜯어보고 있었다. 기존에 설정한 Hot Module Replacement가 바로 반응하지 않았고 최종 bundle size도 너무 커서 손을 봐야했다. 그리고 Code Splitting, Lazy Import, Tree Shaking 등을 공부하고 적용해보았다.

webpack이야기가 나와서 말인데 이 모든 멋진 기능들을 사용할 수 있어서 참 좋다. webpack 형들 너무 멋있다. 그런데 이것이 동작하는 원리를 파보지 않고 Document만 공부하며 ‘아 이런 거구나. 그럼 이렇게 쓰면 되겠구나.’ 라며 사용만 하고 있는데 무언가 가끔 찝찝하다. 내가 이걸 ‘안다’고 말할 수 있는 걸까? 내가 이걸 정말 ‘학습’한 걸까? 라는 의문이 의식 저편에서 스멀스멀 올라오고 그걸 끝내 외면하지 못한다.

그래서 자문해보았다. 카레이서 선수들도 람보르기니가 제공한 새 자동차를 타보고 새 기능의 원리를 이해하지 않은 체 운전대를 잡는 자신을 보며 나와 같은 찝찝함을 느낄까? 그렇지 않다면 새 기능의 작동 원리를 정확히는 모르더라도 그것이 무얼 위해 있는 건지, 사용할때 어떻게 해야하는지만 잘 이해하고 질주하기만 하면 되는 것은 아닐까? 새 기능이나 엔진같은 것은 그걸 만드는 엔지니어에게 맘편히 맡겨두고..!

여기서 다시 나의 입장으로 돌아와 생각해보면, webpack이 어떻게 이런 기능들을 가능하게 하는지 등의 원리에 대한 이해보다도, 물론 이것을 무시할 수는 없지만 우선 무엇을 활용해야 하는지, 그걸 어떻게 사용하는지 잘 이해하고 프로젝트에 적용해보고 결과를 살펴보는 것이 낫지 않을까? 그렇게 당분간은 학습과 적용에 집중하고 어느정도 익숙해진 다음 webpack의 부족한 점이나 오류 등을 발견하면 그때 webpack의 내부를 뜯어보아도 늦지 않을 것이다. 아마 오픈소스를 접하게 되는 자연스러운 흐름이 이렇지 않을까라고 생각이 드는데 아직은 잘 모르겠다.

webpack 외에는 PWA와 SSR, React Native를 조금씩 공부하고 만들어보고 있다. 이 역시 하나하나 공부할 때마다 찝찝함을 느끼나 언젠가 조금은 통달하기를 바라는 마음이다(커밋이나 해야할텐데 이놈아). 그리고 최근 Reselect를 공부하다가 Redux에서 불필요한 재계산이 생각보다 많이 일어나는 것을 깨닫곤 갑자기 내부가 궁금해서 조금씩 살펴보고 있다. 여기에 대해서도 살펴본 경험에 대해 코드 베이스로 글을 써봐야겠다. 진지하다. 2018년이다.

Blog: 더 공부하고, 더 읽고, 더 경험하고, 더 남기자

WordPressMedium 두 플랫폼에서 블로그를 하고 있는데 2017년 블로그는 가히 뭇매를 맞아 마땅한 수준으로 글을 썼다. 워드프레스엔 개발, 경험, 커리어, 문화, 과학, 철학 등 가장 관심있는 분야들에 대해, 미디엄엔 영어로 개발 위주의 글을 쓰려고 했는데 재료가 많이 부족하기도 했지만 생각보다 너무 글을 못남겨서 아쉽게 올해를 마무리짓게 됐다. 미디엄은 3월에 하나 쓰고 끝났다니..

처음 결심했던 바 그대로 살아있는 동안 더 많이 읽고, 더 경험하고, 다양한 사람들을 만나고, 더 만들어서 많이 남기자. 그렇게 해서 조금이라도 다른 이들이 나로 인해 도움을 얻고 용기를 얻고 지식을 얻기를 바란다.

4개국어는 하고싶다

대망의 외국어 회고다. 첫 회고이니 내 인생의 외국어는 어떻게 시작했는지 돌아보자. 아 점점 글이 길어지는데? 스마트한 독자는 단락별 소제목만 보고 흥미가 당기는 것만 읽었기를 간절히 바란다. 벌써 이 글은 너무 길어져서 아무도 안볼 것 같다. 그냥 쓰자.

대학교 2학년때 막연히 미래에는 세계를 마음껏 누비는 사람이 되고 싶다고 다짐했다. 무엇이 되고자 하는 목표도 없이 일단은 세계를 돌아다녀야 한다는 이상한 제 1원칙을 세웠다. 껌을 팔더라도 해외에서 사고 팔아야 한다는 해괴한 욕망이었다. 학원은 절대 다니기 싫었고 그렇다고 단어, 문법책을 혼자 보기는 더 싫었다. 그래서 2010년, TIME지와 뉴욕타임즈를 무작정 읽기 시작했다.

결과는? 중간에 느낀 건 없다. 그렇게 6년을 읽고나니 다행히 신문이나 분야 상관없이 읽고 싶은 책을 읽을 정도는 되었다. 근데 치명적인 문제가 있었다. 읽기만 했더니 듣고 말할 수 없었다. 신개념 벙어리가 되었다.

그래서 2017년 부터는 듣고 말하기에 집중했다. 집중이랄 것도 없다. 단순히 방식을 바꿨다. 원서를 소리내서 읽고 좋아하는 미드를 볼때 안들리는 문장 몇개를 원어민이 하는 발음, 억양, 감정, 강조, 표정 등을 똑같이 재현하는 연습을 했다. 드문드문 했기 때문에 전체적으로는 두달이 안되는 것 같다. 그리고 TED를 보고 이야기를 나누는 영어회화 스터디를 7개월 정도 참석했다.

결과는 꽤 희망적이다. 전보다는 많이 들을 수 있고 더 말할 수 있게 되었다. 무엇보다 작은 소통은 무리없이 되는 것을 확인하니 듣고 말하는데서 오는 스트레스가 줄게 되어 무병장수에 한걸음 다가간 것 같다. 난 오래 살거다. 아 그리고 처음으로 갑자기 미드가 청크로 명확히 들리는 경험을 했는데 올해 가장 기분 좋은 경험 중 하나였다. Netflix로 Designated Survivor(지정생존자)를 보다 그랬는데 이거 명작이다. 진짜 재밌다.

그 다음은 프랑스어다. 서른 중반이 되기 전 4개국어는 무리없이 하고싶다. 2020년의 노경모야 보고 있나? 4개국어를 하란 말이다. 이유는 딱히 없다. 다만, 분명 어족이 같거나 비슷한 언어 두세개를 익히면 패턴을 느껴 그 이상의 또 다른 언어를 습득하는 것이 쉬워질 거라는 느낌을 받았다. 지금은 Busuu라는 앱을 활용하고 있는데 뭔가 이름 때문인지 부수적인 것 같고 Duolingo로 갈아탈 예정이다.

마지막으로, 지금껏 외국어를 공부하며 느낀 것은 생각보다 책이 필요 없다는 점이다. 여기서 말하는 책이란 단어나 문법 책이다. 물론 멋진 단어책 한권 떼고 시작하면 굉장한 부스트를 받게 되는 것은 무시할 수 없으나 본질은 언어를 몸으로 ‘익히는’ 것이 아닐까 한다. 가령, 꼭 책을 보며 머리만 이용해 언어를 습득하지 않아도 몸에도 작업 기억이 있듯 영어의 호흡을 하고, 한국어를 사용할 때와는 다른 종류의 근육을 써가며 발음을 내뱉고 감정 표현을 하다보면 영어만이 주는 패턴이 온몸에 새겨진다. 호흡과 입 근육부터 시작해서 이후에는 영어가 주는 프레임으로 사고하게 된다. 한국어는 끝까지 듣고 보라는데 영어는 앞만 들으면 되는 것도 여기서 비롯된 것이다.

그래서 새로이 공부하는 프랑스어는 소리만으로 공부하고 있다. 기본적인 단어야 소리로 공부하면 되므로 우선은 이 방식을 고수하고 있다. 또 한두 분기 공부해보고 회고를 남겨봐야 알겠지만 지금까지의 경험에 의하면 이렇다. 물론, 아직 확신은 없다. 6개월 뒤에 다른 깨달음을 얻을 수도 있을 것이다. 다만, 이 멋진 영상에서 큰 힌트를 얻었다. 외국어 학습은 계속 책과 영상을 통해 이해해야 할 것 같다.

Read books: 나도 모르는 나를 발견하는, 전혀 새로운 나를 알게 되는 수단

이런 생각으로 처음 책을 읽었다. 이걸 쓴 사람은 대체 무슨 생각으로 이렇게 두꺼운 책을 썼을까? 그렇게 읽고 책의 내용을 이해하고 나니 이런 생각이 들었다. 만약 내가 2년에 걸쳐 깨달은 것을 책으로 낸다면 이걸 읽은 사람은 간접적일 지라도 그 2년의 지식과 통찰을 반나절만에 가져가는 것이 아닌가? 도둑놈인가?

내가 블로그를 하는 마음과 비슷하게, 더 멋지고 똑똑한 선대의 형들도 여러 해에 걸쳐 알게 된 모든 것을 잘 정리하여 세상에 알리고자 하지 않았을까. 이런 생각을 하니 책을 읽지 않을 수 없었다. 새로운 걸 알게 된 시점에 그 시각으로 새로이 보는 세상은 매번 바뀌어 왔다. 열권을 읽었다면 적어도 여덟번은 바뀌었다.

회고를 해보자. 지금 읽는 책의 분야는 철학, 물리학, 생물학, 인류학 및 GRIT과 같은 self-motivated 류의 책들이다. 과학에 치중되어 있는데 아무래도 경제/사회와 소설 쪽도 골고루 읽어야 할 것 같다. 인간에 대한 이해가 결여된, 감성 없는 기술 발전은 쓸모 없다는 나의 믿음을 위해서라도 밸런스를 맞춰야 하겠다. 2018년에 읽어볼 도서 목록을 정해보고 이에 관한 글을 따로 써보자. 그리고 블로그에 새로운 카테고리를 만들어 읽은 책에 대한 리뷰를 남기도록 해야겠다.

KakaoTalk_2017-12-31-16-13-38_Photo_14

KakaoTalk_2017-12-31-16-14-14_Photo_70

KakaoTalk_2017-12-31-16-14-18_Photo_66

이 재밌는 것들을 오래 하려면

위에서 다룬 이 모든 재밌는 것들을 오래 하기 위해선 건강이 무조건 뒷받침되어야 한다. 아직 스물일곱인데 이런 얘기해서 설득력이.. 하나도 없지만 시간이 더 지나기 전에 한번 습관을 만들어야겠다는 느낌이 들었다. 그래야 서른, 마흔이 되어서도 운동의 재미를 느끼며 꾸준히 하지 않을까.

그래서 시작한 것이 철봉과 푸쉬업 위주의 맨몸 운동이다. 일단 너무 힘들다. 철봉은 정자세로 풀업 한개를 채우기까지 한달이 걸렸다. 작년 가을부터 시작해 올해 여름까지 조금씩 꾸준히 해보니 드디어 사람같은 생김새를 얻었다. 그 전엔 너무 체구도 작았었고 무엇보다 조금만 힘써도 쉽게 피로감을 느꼈다. 요새는 춥다는 핑계로 실내에서 푸쉬업만 하고 있는데 내년엔 유산소 운동을 꼭 해야겠다는 생각이 들었다. 땀흘리지 않으니 몸이 정말 삐걱거린다. 재밌는 것들 오래 하려면 일단 건강하고 봐야 한다. 다음주에 올림픽공원 옆으로 이사가니 이제 더는 댈 핑계도 없다. 운동 열심히 하자.

앞으로는?

드디어 마지막 단락이다.

공부해야 할 것도 산더미고 하고 싶은 것도 산더미라 이 시점부터는 선택과 집중 그리고 우선순위 부여가 정말 중요해질 것 같다. 내가 내린 지금의 선택이 시간이 지나면 지날 수록 내게 미치는 영향이 너무 커지기 때문에 어떤 선택을 선뜻 내리기가 어렵다.

그래도 큰 가닥에는 변함이 없는 것 같다. Web Frontend와 Machine Learning 두가지의 큰 줄기로 공부와 개인 프로젝트를 이어나가고 싶다. 두 분야를 공부하다가 나중에는 대체 어떻게 연결시켜 하나의 커리어로 만들어나갈지 전혀 감이 오지 않지만 인생은 저지르고 보는 것 아니겠는가? 2018년에도 열심히 저지르고 열심히 회고하자. 아쉬운 2017년 안녕!

 

2017년을 나타내는 사진들

SK에서 난 무엇을 배웠나

이 회사에서 난 무엇을 배웠나. 그리고 스타트업으로 오기까지 난 무엇을 했나!

지난 2년을 정리하고 되돌아볼 때가 왔다. 그 2년을 크게 3 부분으로 나눠볼 수 있겠다.

  • 회사에 입사했고
  • 퇴사를 했고
  • 회사에 입사했다

2015년 2월 졸업을 하고 회사가 뭔지, 일이란게 무엇인지 아무것도 모르는 상태에서 같은 해 7월 1일, SK C&C에 입사했다. 그리고 정확히 15개월 뒤인 2016년 9월 30일에 퇴사를 했다. 지금 생각해도 아찔한 나날들이다.😨 너무 많은 변화가 짧은 기간에 일어나 무슨 일이 일어날 때마다 적절한 대처가 무엇인지 알기 위해 부딪치고 헤맨, 고된 학습의 시간이었다. 컴퓨터공학엔 관심을 가진지 2년도 안되는, 그저 철학 서적을 탐독하던 스물다섯 새파란 rookie였으니 옆구리만 찔러도 놀라고 뭘 갖다줘도 모든게 새로운 때였다. 물론 지금도 공부할 게 산더미다(..).

그래서 무얼 배웠나?

이것도 아래와 같이 크게 세가지로 나눠볼 수 있겠다.

  • 조직이 어떻게 구성되고 업무가 어떻게 부여되는가
  • 조직 문화가 갖는 회사에서의 역할
  • How to communicate efficiently!

조직, the organism constantly moving forward

팀에 부서 배치를 받고 사무실에 처음 들어간 날을 잊을 수 없다. 오우 이게 회사구나. 그렇게 첫 여섯달을 배우고 일하면서 가장 먼저 눈에 들어온 것이 이 정도 규모의 큰 조직이 어떻게 구성되어 있고 그 구조에 따라 개인에게 업무가 어떤 형태와 과정으로 부여되는가였다. 물론 신입사원의 눈으로 보는 것이었기에 많은 것을 다 파악하기엔 한계가 있었다. 그럼에도 그 구조를 알아보려 부단히 노력했다.

가장 중요해 보였던 것은 사업부다. 사업부란 말 그대로 어떤 회사가 생존하고 성장하기 위해 중점적으로 일으키고 있는 모든 경제적 행위들을 실행하는 세부 조직의 집합이다. 그리고 이것을 중심으로 사업과 직접적으로 관련된 세부 조직이 구성되고, 이 조직이 원활히 운영되기 위해 필요한 인적, 물적, 문화적 자원을 관리 및 배분하고 경영에 관련한 변경 사항이나 공지할 사항을 전 조직에 알리는 역할을 하는 지원 조직이 구성된다. 단순히 구분하자면 Running / Support로 나눌 수 있겠다. 이 Support 조직을 회사마다 다르게 부르고 구성한다. 이중에 인적 자원에 집중하는 조직을 대표적으로 부르는 이름이 HR 일테다. 그리고 돈을 벌어다주는 영업 조직. 사업의 형태와 성격에 따라 팀으로 있을 수도 있고 Running 조직의 부분으로 존재할 수도 있다. 그 다음으로 회사의 규모, 재정 상태 혹은 종류에 따라 부가적으로 생기는 조직들 중 하나가 R&D다. 이 연구개발 조직 또한 사업의 특성에 따라 완전히 독립적인 형태로 존재할 수도 있고 각 사업부마다 귀속된 형태로 있을 수도 있다.

이쯤 파악하고 나서 든 생각은 회사는 완전한 유기체라는 것이다. 가장 기본이 되는 단위 조직이 마치 움직이는 레고 같았다. 위 단락에서 본 바와 같이 어느 것 하나 글로벌하게 정해진 틀이 없다. 어떤 사업을 하느냐에 따라 Support 조직의 규모가 클 수도, 작을 수도 있고 R&D 조직이 독립적일 수도 있고 특정 사업부에만 존재할 수도 있다. 회사의 가치, 사업의 형태에 따라 이 레고들은 유기적으로 배치되고 조립된다. 더 높은 차원에서 이야기하면, 당연히 회사 또한 국가와 국제사회라는 더 큰 조직의 세부 조직이므로 회사의 레고들은 사회-회사에 걸쳐 이중으로 영향을 받는 셈이다. 이렇게 이중적 영향을 받아 생기고 있는 대표적인 레고 중 하나가 AI branch다. 애초에 회사의 사업을 구성할 때 AI 및 Machine Learning은 고려조차 하지 않았지만 시대적 흐름을 무시할 수 없어 만들어졌기 때문이다. 즉, 처음부터 ML로 돈을 벌기 위해 설립된 회사가 아닌데 회사 내에 ML related 팀이 있다면 그 레고는 이중적 영향을 받은 것이다.

나이 서른, 늦더라도 마흔에 북미권에서 스타트업을 꼭 만들고 싶은 나로서는 조직을 어떻게 구성해야 하는가에 대해 알아볼 수 있었던 소중한 배움들이었다. 조직에 대해 한 문장으로 정리해보면, 조직은 실행하려는 사업의 특성과 형태에 따라 적절히 구성하고 회사의 핵심 가치에 따라 끊임없이 개선 및 발전시켜야 한다는 것이다. 사업의 특성에 맞지 않게 Support 조직이 비정상적으로 비대하거나, Running 조직들 간의 조립 이음새가 시원찮거나, 외부의 흐름에 따라 유기적으로 조직 구성의 변화를 꾀하지 못한다거나, 조직의 구성이 사업의 특성에 맞지 않는다거나 하여 레고들이 잘 조립되어 굴러가지 않는다면 회사는 언젠가 삐걱거릴 것이라고 생각한다.

조직 문화의 역할과 중요성

다음에 배운 것이 조직 문화이다. 이것의 결핍을 회사에서 많이 느꼈기 때문에 그 필요성과 중요함이 매우 크게 다가왔다. 조직 문화는 실체가 없다. 그래서 만질 수도 없고 누군가에게 ‘여기 있어요~’ 라며 건네줄 수도 없다. 다만, peer colleague들이 서로를 어떻게 대하고 소통하는지, 서로 다른 직급에서는 어떻게 소통이 이루어지는지, 구성원들이 서로를 어떻게 부르는지, 구성원들이 회사를 어떻게 생각하는지, 경영진과 모든 구성원이 회사의 Service로 고객에게 어떤 가치를 주고싶은지, 경영에 관한 중대한 결정을 할때 구성원들이 어떻게 참여하고 의견을 내는지, 한 가지 사안에 대해 다같이 참여해야할 상황에 회의를 어떤 가치에 따라 진행하는지, 그 방식은 어떤지 등 회사 내에서 이루어지는 모든 행위에 추상적으로 깃들어있다.

만질 수 없고 보이지 않아서 쉽게 간과되고 무시될 수 있다. 그래서 더욱 중요하다. 보이지 않지만 회사 구석구석 모든 곳에 존재하고 그 영향을 끊임없이 끼치기 때문이다. 따라서 ‘우리가 하려는 일은 이러한 거에요. 이 일을 통해 이런 가치를 만들고 있어요. 우리는 이런 일을 하기 때문에 서로를 이렇게 생각했으면 좋겠어요. 그래서 일대일, 다대다 소통을 할때는 이런 방향으로 하길 원해요. 그 방식이 우리가 추구하는 가치를 더욱 풍성하게 하고 서비스를 더 좋게 만들 것이라 믿어요.’ 라는 식의 정언적 문장들이 지속적으로 갈고 닦아져야 하며 구성원들 또한 그것을 좋아하고 그것에 깊이 공명하고 그것에 따라 행동할 수 있어야 한다. 회사를 구성하는 아주 작은 개인들에게도 큰 영향을 끼치고 이는 곧 사업의 질과도 연결되어 있기 때문이다. 물론 뚜렷한 조직 문화가 없다고 해서 제품 혹은 서비스가 꼭 안좋지는 않을 것이다. 하지만 분명한 것은 그저 좋은 제품이 아닌, 사랑받는 제품과 서비스를 만드는 회사를 보면 하나같이 좋은 조직 문화를 갖고 있고 그것을 끊임없이 개선시키고 있다. 여기에 대해 생각할 때마다 문화가 좋으면 사내에 선순환적인 고리가 생길 것 같은 직감을 꾸준히 받는다.

소통이 뭐에요? 😲

그 다음은 소통. 가끔 인스타를 하다보면 누군가가 내 사진에 좋아요를 누르고 ‘잘 봤어요. 소통해요~’ 라며 댓글을 다는 것을 심심찮게 본다. 대체 난 저들과 무슨 소통을 해야한단 말인가.. 들어가보면 죄다 네일샵이다.. 이런 실체가 잘 와닿지 않는 소통을 회사에서도 적절히 잘 해야함을 느꼈다. 너무 당연한 말인가? 하지만 ‘잘’ 하는 것은 그리 쉽지 않다. 그것도 회사에서는 더욱. 결론적으로 ‘커뮤니케이션에 능하다’ 를 먼저 정의하자면, ‘상대가 어떤 심정, 상태, 맥락에서 어떤 메세지를 전달하려는지 의도를 파악하고 경청한 뒤, 나의 메세지 또한 상대가 잘 이해할 수 있도록 상대의 언어로 표현하는 것‘이다. 너무 조건이 많아 보이는가? 하지만 아주 필요한 것들로만 구성한 문장이다. 그만큼 잘 소통하는 것은 무척 어려운 일이다. 살아보니 실제로 그렇고 이것의 결핍때문에 크고 작은 불상사를 겪는 사람들을 주변에서 아주 많이 왕왕 봐왔다. 그래서 적어본다. 내가 겪은 소통이 참 어려웠던 불통 케이스들.

  1. 듣는 것 같긴 한데 말이 너무 없는 사람
  2. 듣지도 않고 말도 없는 사람(…)
  3. 잘 듣지도 않는데 자기 말이 너무 많은 사람
  4. 상대의 말을 아무렇지 않게 끊는 사람
  5. 듣기는 하는데 상대의 심정, 상태, 맥락 파악이 안되는 사람
  6. 말할 때 상대의 언어로 말하지 못하는 사람

모두 회사에서 만나면 골치아픈 건 매한가지인 사람들이다. 1, 2번은 매우 답답하고, 3번은 annoying하고, 4번은 매우 불쾌하며, 5, 6번은 안타깝다. 1~4번은 눈에 너무 띄기 때문에 웬만해선 주변에서 다 인식하고 있다. 그래서 협동(?)하여 잘 대처할 수 있다. 5, 6번은 안타깝다고 했는데 이유는 다음과 같다. 먼저 5번은 정상적인 소통은 가능하나 상대에 대한 이해를 바탕으로 이야기하지 못하기 때문에 메세지 전달력이 낮을 뿐더러 상대의 마음을 움직이는 데에는 십중팔구 실패한다. 상대의 심정을 알고 그의 말하는 전후 맥락을 파악하는 것이 어떻게 메세지 전달력과 설득력에 도움이 되냐고 묻는 사람이 더러 있다. 상대가 어떤 심정인지 알면 그에 맞춰 나의 말하는 stance를 정할 수 있다. 당연히 나의 stance에 따라 말하는 양태 또한 달라지고 이를 듣는 이도 느끼고 반응한다. 같은 내용의 메세지이더라도 어떤 방식과 형태를 취하느냐에 따라 분위기가 달라지고 듣는 이의 수용력에 영향을 미칠 수 있다. 그래서 5번은 그 이해의 폭만 넓히면 괜찮은 소통을 할 수 있기 때문에 안타까운 것이다. 6번도 안타깝지만 조금은 답답한 케이스다. 가끔 자기 분야의 용어로 뒤범벅된 언어를 구사하는 사람이 있다. 대화 중에 말이다. 모두가 같은 분야 사람이고 회의를 하는 경우에는 문제가 되지 않는다. 하지만 다양한 분야의 사람들이 모인 자리나 그런 개인과 소통할 때엔 문제가 된다. 듣는 이가 화자의 말에 공감할 수 없기 때문이다. 이런 경우, 듣는 이도 화자가 적어도 무슨 말을 하는지는 이해하지만 결론적으로 와닿지 않기 때문에 서로 좋은 소통을 하는 데엔 실패한다.

어디든 좋은 소통이 이루어지기 어려운 곳은 별로 있고 싶은 곳은 아니다. 좋은 소통이 되는 곳에 있으면 일과 대화에 완전히 몰입하고 시간 가는 줄 모르고 집중하게 되는 일이 빈번하게 일어난다. 그런 일이 잦으면 잦을 수록 직장 생활 뿐만 아니라 삶에 대한 만족도 또한 상승할 것이라 생각한다. 아니, 거의 그렇게 믿는다. 김정운 작가의 책을 읽다가 이런 구절을 본 적이 있다. 소통을 정말 잘하는 사람은 공감(sympathy), 감정이입(empathy)을 하고 나아가 공명(resonance)한다는 것이다. 정말 공감하는 바이다. 이 말은 앞서 설명한 ‘상대의 심정, 상태, 맥락을 이해’하지 않고서는 성립되지 않기 때문이다. 입사하기 전엔 이런 여러 종류의 불통러들을 회사 내에서 만났을 때 어떤 일이 일어날지 전혀 예상하지 못했고 생각할 겨를도 없었다. 1년 넘게 다니면서 이런 불통러들이 회사와 일에 어떤 영향을 미치는지 골고루 보아왔다. 그래서 참 고맙고(?) 좋은 소통을 하기란 쉬운 것이 아니고 그것엔 자기 개선이 필수적으로 수반된다는 사실을 알게 된 시간들이었다.

무엇이 나를 퇴사로 이끌었는가?

대학교 2학년때 처음으로 꿈이 생겼다. 당시엔 ‘세계적인 엔지니어가 되어 세상에 무언가 도움이 되는 걸 만들고 싶다’ 라는 다소 추상적인 형태의 꿈이었다. 다행히 전에 쓴 글 나, 주체적으로 살고 있는 걸까? 에서 설명한 것처럼 이 추상적인 꿈은 현재 나의 가장 근원이 되는 꿈이 되어 지금도 길라잡이 역할을 하고 있다. 입사를 할때에도 이런 삶의 방향성에 입각해서 계획을 세워야 했다. 그래서 생각한 것이, 개발 부서에 배치되면 최대 3년, 이외의 부서는 2년을 다니는 것으로 정했다. SI 회사였기 때문에 기간 산정이 저렇게 나왔고 대기업에서 배울 수 있는 것을 최대한 습득하고 service를 만드는 개발을 하기 위함이었다. 그래야만 최대 3년을 다녀도 스물여덟에 나와 다른 도전을 할 수 있다는 계산이 나왔기 때문이었다.

그렇게 입사하고 인프라 팀에서 일한지 13개월이 되었을 때 머릿속에 스멀스멀 피어오르기 시작했다. 이 이상 더 머무를 이유가 없다는 생각. 때마침 고객사였던 SK Hynix의 책임님께서도 새로운 도전에 대해 이야기해주셨다. 그래서 퇴사한 것은 아니다.. 3년이 되었든, 2년이 되었든 퇴사를 해야할 시점에 적절히 퇴사할 수 있도록 입사를 한 시점부터 퇴근 후 개인 포트폴리오를 위한 공부와 개발을 하기 시작했다. 그 공부와 개발의 행적을 남기기 위해 Github에 프로젝트를 만들고 꾸준히 commit 했다. 별거 아니지만 그땐 그 별거아닌 것이 필요했고 중요했고 간절했다. 그렇게 하루 두시간씩 매일을 공부하고 15개월이 지나 적절한 때(?)에 퇴사할 수 있었다.

스타트업으로 오기까지

그럼 퇴사를 하고 스타트업으로 오기 전까지 난 무엇을 했는가? 퇴사하기 전 다음 행보를 밟기 위해 필요한 것이 무엇인지 정리할 필요가 있었다. 그래서 아래와 같은 목록이 나왔다.

  1. 국제적 커리어를 위해 세계를 좀 더 직접적으로 경험해볼 필요가 있다
  2. 당연히 이를 위해 영어가 더 세련될 필요가 있다
  3. 관심을 쏟기 시작한 Web Development를 위해 React.js와 같은 신기술을 공부하고 이것으로 개발해 볼 필요가 있다
  4. 이력서를 국문/영문으로 각기 다른 버전으로 잘 다듬을 필요가 있다

1번을 위해 호주에 가기로 결정했다. 캐나다는 교환학생때 경험했고 때마침 친한 친구가 Gold Coast 부근 Griffith University에서 졸업을 앞두고 있었다. 그래서 오랜 친구를 만날 겸, 친구에게 호주 전반과 이민에 대한 이야기도 들을 겸, 직접 호주 IT 회사들을 살펴보고 문화를 경험해볼 겸, 다시 한번 방향 설정을 견고히 할 겸, 그간 못본 책을 마음 껏 볼 겸 그렇게 호주로 떠나 8주 넘게 지냈다.

IMG_3044UNADJUSTEDNONRAW_thumb_1553UNADJUSTEDNONRAW_thumb_1536

완벽한 시간이었다. 호주에서도 개발을 했고 책을 읽고 글을 썼다. 호주에도 IT 회사가 꽤 많고 Software Engineer가 꽤 괜찮은 것 같았다. 호주에서 캐나다 친구를 사귀게 되었는데 그 또한 Software Engineer였고 캐나다와 호주의 IT에 대해 많은 이야기를 나누었다. 그렇게 해외의 IT 업계에 대해서 조금씩 감을 잡기 시작했다.

늦은 겨울, 귀국을 하고나서 본격적으로 React.js, Webpack, Redux, Node.js로 Web app을 만드는 프로젝트 두개를 만들어 멤버를 모집하고 시작했다. 영어는 TIME이나 논문을 읽고 쓰는데는 편했지만 네이티브와 자연스럽게 듣고 말하는 데는 한계가 있어 회화 스터디를 시작했다. 그 무렵이 12월 말이었고 그렇게 넉달을 보냈다. 춥고 꽤나 고단스러운 시간이었으나 무엇보다 재밌었기 때문에 꾸준히 할 수 있었다. 이후 2주에 걸쳐 이력서를 다듬었고 여러 스타트업에 Wanted를 통해 지원하기 시작했다. 몇몇 한국 스타트업과 미국계 스타트업의 면접을 거치면서 어떤 회사에 가고 싶은지가 점점 명확해졌다. 미국계 스타트업은 면접을 영어로 5시간을 해서 실신할 뻔 했다.. 그렇게 d.code라는 앱을 서비스하고 있는 지금의 회사로 오게 되었고 좋은 배움의 나날들을 보내고 있다.

여기까지가 지난 2년간 SK에서 배운 것들과 스타트업으로 오기까지의 여정이다. 지금 또한 추상적 목표에 따라 끊임없이 방향 설정을 하고 재밌게 개발 공부를 하고 있다. 이제 스물일곱, 앞으로 어떻게 삶이 펼쳐질지는 어느것도 예측할 수 없지만 적어도 새로움을 추구하고 끊임없이 도전하고 공부하는 이 방향 아래에서만 나아간다면 행복하고 성장하는 삶을 살 수 있지 않을까 싶다.