지난 3년의 기록: 대기업에서 스타트업으로

어느새 스타트업에서 일을 한지 1년 5개월의 세월이 흘렀다. 그리 긴 세월은 아니지만, Paul Graham이 스타트업에서의 시간은 큰 기업에서의 시간을 몇배나 압축시킨 것이라 표현했을 만큼 스타트업에서 보낸 지난 시간들은 대기업에서 보낸 그것이 크게 잊혀질 정도로 압축적이었고, 숨이 찼고, 설레었고, 진하게 행복했다. 1년 5개월이 마치 3~4년이 흐른 것처럼 느껴진다. 뭐가 그리 압축적이고 행복했을까? 사실, 대기업에선 그토록 하고싶었던 Software Engineer를 하지 못하고 Infra 팀에 속해있었기 때문에 이런 시간의 밀도차가 내게 더욱 크게 느껴진 점도 있다. 큰 회사의 Infra Engineer 포지션에서 스타트업의 Frontend Engineer 포지션으로 급진적인(?) 커리어 이동을 준비하고 겪어온 근 3년의 시간동안 많이 힘들었고(특히 옮기면서), 인생에 많은 변화가 있었고, 알게 모르게 경험과 깨달음이 조금씩 쌓이게 되었다. 그래서 이번 글에서는 이동을 준비하고 넘어온 뒤 겪은 것들을 바탕으로 ‘대기업, 스타트업, 둘 사이의 차이점 그리고 이동’을 주제삼아 다뤄보고자 한다. 그동안 큰 회사에서 작은 회사로의 이동, 커리어의 전환, 첫 직장 구하기 등에 대해 고민하는 분들을 많이 보았는데 이 글이 작게나마 부분적으로 도움이 됐으면 좋겠다. 아마도 그간의 경험에 대해 이야기하는 만큼 어쩌면 이 글은 회고성 글이 될지도 모르겠다. 그리고 마침 HHKB, 매직 트랙패드, GoPro 사진이 지난 3년을 잘 축약해서 표현하는 것 같아 대표사진으로 정했다.

대기업에서의 시간

입사 당시 나의 상태는 컴퓨터공학과를 졸업했지만 구체적으로 어떤 분야의 Software Engineer가 되고자 하는지에 대한 명확한 생각이나 계획이 없었다. 약간의 Java, JSP, C, 더 절망적인 수준의 JavaScript 지식이 있었다. 이외에는 다년간의 독서와 글쓰기로 컴퓨터공학이 탄생한 배경, 다른 학문들과 어떤 관계를 갖고 있는지에 대한 Liberal Arts 관점의 이해가 있는 정도였다(뒤에서 다루겠지만 이때는 몰랐지만 이 부분이 어떤 엔지니어를 할지 그리고 인생을 어떻게 살면 좋을지를 선택할때 큰 도움을 주었다). 그런데 5000자의 자기소개서, 기술 면접, 임원 면접, 3달간의 소프트웨어 자사연수, 팀 배치 상담 등 이 모든 과정에서 개발 개발 개발 개발 개발 개발 구구절절 개발 이야기를 했지만 Infra 팀으로 배치되는 환상적인 경험을 하게 된다. 몰래카메라인줄 알았다. 그렇게 배치받은 다음날부터 이직을 준비하기 시작했다.

Infra 팀으로 배치가 된 뒤에 기본적인 Server(x86), Database, Network를 공부했고 틈틈이 선배가 주시는 간단한 업무들을 해나갔다. 관심없던 Infrastructure를 공부하면서 취했던 자세 또는 방향이 있었는데 아래와 같은 것들이었다.

  • 언제 퇴사를 하게될지 모르지만 적어도 어떤 개발자를 할지 정하고, 커리어 전환을 할 수 있을 만큼 최대한 관련 지식을 쌓고 코드를 많이 만들어보자.
  • 지금은 재미없어 보여도 나중에 내가 만들게 될 프로그램들이 결국 이 인프라 위에서 배포되고 운영되고 관리될 것이니 있는동안 최대한 많이 인프라를 경험하고 공부하자.

그렇게 1년여간 일하면서 약간의 OS 지식을 얻었고, Linux 터미널에서 명령어를 치는게 익숙해졌고, 인프라를 구성하고 운영하는 것이 무엇인지에 대한 대략적인 그림을 생각할 수 있게 되었다. 인프라에 대해 더 알고자 하는 욕심은 컸지만 출근하면 하루 9시간을 인프라를 붙들고 일하는 곳에 놓여 있다는 이질감, 어색함, 분노, 하고자 했던 Software Engineering은 하지 못하고 이대로 시간이 흐르고 있다는 짜증과 분노가 밑바탕에 깔려있다보니 높은 집중도로 익히지는 못했다.

이외에 관심을 갖고 봤던 점은 이렇게 규모가 큰 조직은 조직 구성을 어떻게 하고, 의사결정을 어떻게 하고, 그것을 어떻게 전달 및 전파하는가였다. 확실히 이 부분은 대기업을 다니면서 관찰할 수 있는 흥미로운 영역이었다. 왜냐하면 회사를 다닌 경험이 없더라도 동아리 및 대외활동을 하면서 그리고 그동안 책과 신문을 읽으면서 쌓인 조직이 구성되고 움직이는 것에 대한 직간접적인 경험들로 미루어보면 조직을 구성하는 구성원의 수에 따라 어떤 방식으로 커뮤니케이션을 하는지, 어떻게 decision making을 하고 그 결과를 어떻게 전파하는지가 많이 달라지고 그 방식에 따라 cost가 천차만별로 달라짐을 알 수 있기 때문이다. 조직의 구성원이 둘일때의 소통 채널은 1개이지만 넷일때의 채널은 6개이다. 이렇게 채널이 급격히 많아질때 주요 소통 채널은 어디로 정하고, 전체를 위한 중요한 결정을 누가 내려야하고 그에 따른 정보를 어떻게 전달하는가는 조직의 생사가 달린 중요한 문제다. 이런 맥락에서 대기업에서 어떤 커뮤니케이션 프로세스가 있는지 관찰하고 직접 참여해보는 것은 귀중하면서도 상당히 재미있는 경험이었다. 대기업에서 무엇을 느끼고 배웠는지에 대해서는 전에 썼던 이 글에서 좀더 일반적으로 다루었다. 지금 돌이켜보면 확실히 대기업에서는 일 자체 보다는 조직과 시스템 같은 구조적인 부분을 더 많이 흡수했다는 생각이 든다.

커리어 전환과 이직을 위한 준비

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

위에서 팀 배치를 받자마자 이직을 준비하기 시작했다고 했는데 이 과정은 회사를 알아보는 과정도 포함하지만 먼저 내가 무엇을 하고싶고, 어떤 개발자가 되고싶은지 등 나에 대한 이해를 다지는 일이 대부분이었다. 아래와 같은 질문 목록을 만들고 글을 쓰면서 이것에 답하는 과정을 몇개월간 반복했다.

  • 앞으로 대기업에서 일하는 동안 어떤 것들을 흡수할 수 있는가?
    • 내가 아는 팀 단위의 조직은 어디서 비롯된 것인가? 모든 회사가 비슷한가? 다르다면 무엇을 위해 다른가? 비즈니스와 서비스의 특성에 따라 다르다면 각각 구체적으로 어떻게 다를 수 있는가? 지금의 회사를 포함해 크고 작은 다른 회사들을 많이 살펴보자.
    • 커뮤니케이션을 어떻게 해야하는가? 아직 커뮤니케이션을 해본 경험이 전무하니 어떤 사람들이 있는지, 어떻게 회의를 하는지, 어떻게 의사를 전달하고 결정하는지 많이 살펴보자.
    • 조직문화는 어디서 비롯되는가? 어떤 종류의 문화들이 있는가? 다양하게 존재한다면 나는 어떤 문화가 마음에 들까? 왜 그럴까? 나의 성향에 따라 문화에 대한 taste가 달라지지 않을까? 그렇다면 나의 성향은 무엇인가? 나의 성향은 왜 이렇게 형성되었는가?
    • 인프라는 무엇인가? 인프라를 구성하는 것들에는 무엇이 있는가? Software Engineering에는 어떻게 연결될 수 있는가? 내가 이후에 개발을 한다면 인프라에 대한 약간의 지식이 어떤 도움이 될 수 있는가?
  • 나는 어떤 개발자가 되길 원하는가?
    • 나는 시각적인 것에 예민한가? 시각적인 것을 만드는 개발을 하고싶은가? 그렇지 않다면 내가 이것에 대해 아직 몰라서 그러는 것인가 아니면 확실히 이유를 알고 그러는 것인가? 확실히 아니라면 나는 구조적이고 논리적인 것에 더 관심이 많은가?
    • 개발자의 종류에는 어떤 것들이 있는가?
      • 위에서 답한 나에 대한 이해를 바탕으로 나는 어떤 개발자를 하면 좋을까?
      • 하나를 선택하면 중간에 바꿀 수 없는가?
      • 미국을 중심으로 어떤 포지션이 가장 많은가? 가장 변화가 심한 포지션은 무엇인가? 국내는 어떤 포지션이 가장 많은가? 국내 회사의 이 포지션에 대한 Job Description 및 Requirements는 무엇인가?
    • 그렇다면 나는 지금부터 어떤 것들을 공부하면 좋은가?
      • 공부할 것들이 구체적으로 어떻게 되는가?
      • 각각 어느정도까지 익히고 만들어보면 되는가?
      • 나와 비슷한 케이스를 다룬 글이 있는가? 그 케이스는 어떤 방식으로 학습 및 전환을 준비했는가? 최대한 많이 참고해보자.
    • 내가 개발자를 하려는 이유는 무엇인가? 단순히 코드를 만드는 것이 재밌어서 인가? 아니면 내가 속한 곳이나 더 크게는 사회와 세상에 기여를 하고싶어서 인가? 나는 소프트웨어를 통해 무엇을 하고싶은가? 단순히 geek하게 technology를 깊게 파고싶은 것인가? 아니면 이것을 통해 무언가 변화를 만들고 싶은 것인가?
  • 나는 어떤 삶을 살고 싶은가?
    • 어떤 엔지니어를 꿈꾸는가? 기술만 잘 아는 엔지니어이길 바라는가? 아니면 주어진 기술을 활용해 비즈니스를 움직이게 할 수 있는 엔지니어이길 바라는가? 나는 어느 수준까지를 바라는가? 최고의 수준을 바란다면 나는 기술 말고 어떤 것들을 꾸준히 함양해야 하는가? 내가 생각하는 정말 멋진 최고의 엔지니어들은 어떤 공통점을 갖고 있는가?
    • 한국에서만 머물 것인가? 아니면 세계를 누비는 엔지니어가 될 것인가? 해외로 나가길 바란다면 나의 문화적 성향은 얼마나 유연한가? 나갔을때 충분히 적응할 수 있는가? 나간다면 한국과 비교해 상대적으로 얻게 되는 것과 잃는 것은 각각 어떻게 되는가? 나는 영어에 얼마나 관심이 있는가? 현재 할 수 있는 영어의 수준으로 일을 할 수 있는가? 전공 지식을 잘 전달할 수 있는가?
  • 이 모든 질문들에 대해 충분한 답을 내렸다면 나는 어떤 회사를 가면 좋은가?
    • 내가 회사를 선택할때 중요하게 생각하는 기준은 무엇인가? 왜 그런 기준을 세웠는가?
    • 회사들에서 주로 어떤 Requirements가 있는가?
    • Job Description 및 Requirements를 확인하기 가장 좋은 곳이 어디인가? Glassdoor? Indeed? LinkedIn?

질문이 꽤 많은 것 같다. 그러나 사람은 죽기 전까지도 자신에 대해 온전히 이해하지 못한다고 하지 않는가? 그만큼 자신을 이해하기란 힘든 여정이고 정말 말 그대로 죽기전까지 계속 나를 이해하는 과정이 필요할 것이다. 아마도 일이 손에 잡히지 않거나, 슬럼프에 빠지거나, 앞으로 어떤 미래를 그려야할지 감이 오지 않거나, 어떤 커리어를 만들어 나가야 할지 잘 모르겠거나 등의 고민은 정체성에 관련된 문제이기 때문에 자신을 이해할 수 있는 질문들에 답하는 과정을 통해 많은 부분 해결할 수 있을 것이다. 이런 점에서 이 정도 양의 질문은 전혀 많다고 볼 수 없다. 이 질문들은 내게 있어 커리어를 전환하고 앞으로 어떤 삶을 살지에 대해 필요한 최소한의 질문들이었다.

그런데 왜 그럴까? 왜 이 정도의 질문들이 최소한의 질문들이었을까? 우선 위 질문들에는 사실 아래 사진과 같은 구조적인 순서가 있다.

f7045489-bd47-49d5-ac93-b1bf4b1ae66c-1-2732x2048-oriented.png
딱히 순서랄 것은 없지만 더 추상적인 질문이 다른 질문들을 뒷받침하는 구조라고 봐야할 것 같다.

사실 이외에 ‘나는 누구인가’ 라는 더 본질적인 질문이 가장 아래에 있고 이 질문에 대한 답이 선행되어야 하지만 이 질문들은 서로 별개로 존재하는 것이 아니라

  1. 자아를 구성하고
  2. 평생의 업을 찾고
  3. 자신에게 맞는 근본적인 행복의 형태를 찾는다

라는 세 관점에서 서로 긴밀히 연결되어 있다. 그리고 이중에는 더 근본적이고 밑바탕이 되는 질문들이 있고 이 질문들에 대한 촘촘하고 탄탄한 답은 그 다음 질문을 가능하게 한다. 가령, ‘나는 누구인가’라는 질문에 대한 답은 나의 정체성에 대한 튼튼한 ‘확인’을 제공하고 이것을 바탕으로 ‘나는 어떤 삶을 살고 싶은가’라는 좀 덜 추상적이면서 현실적인 질문을 가능하게 한다. 이어서, 어떤 삶을 살 것인가에 대해 내린 답들을 통해 구체적으로 어떻게 살아갈 것인지를 다각도로 바라볼 수 있고 다시 이 펼쳐진 가능성에 대한 확인은 ‘나는 왜 이 직업을 택했는가, 이 직업의 어떤 면모가 내 정체성에 부합하는가, 나는 왜 엔지니어를 하길 바라는가, 나는 엔지니어링을 통해 무엇을 하고자 하는가’ 라는 훨씬 더 구체적인 다음 질문을 가능하게 한다. 그리고 자연스럽게 이 답은 내가 매일같이 하는 일에 대한 이유를 제공하고 따라서 나를 흔들리지 않게 한다.

이처럼 질문들은 연결되어 있기 때문에 더 추상적인 질문에 대한 답을 많이 하면 할 수록 아이러니하게 구체적인 질문에 더 답을 하기 쉬워진다. 따라서 뜬구름 잡는 것 같아도 근본적인 질문을 많이 하고 답을 충실히 하는 것을 다시 한번 강조하고 싶다. 살짝 주제에서 벗어난 이야기지만, 일상에서 흔히 쉽게 ‘아 어떤 회사가지, 아 뭐하고 살지, 아 어떻게 돈벌고 살지, 이제부터 뭘 해야하지’ 등의 질문들을 하는데 막상 이에 대한 답을 내려도 선뜻 실행하기 어렵고 실행해도 어딘가 부족하고 답답하고 찝찝한 느낌이 들어서 오래 지속하지 못하는 경우가 상당히 많다. 이것은 ‘아 A 회사 가야지, 이런 것들을 앞으로 공부해야지’ 같은 답을 내렸더라도 그 질문과 답에 결정적으로 ‘나’가 빠져있기 때문일 것이다. 포인터가 유실되서 그렇다. 인간의 정신은 의식중이든 무의식중이든 항상 자신과 주변에 대해 확인하고 가치판단을 하기 때문에 매번 나의 생각과 행동들은 이런 우리 자신의 정신의 시험대에 오르게 된다. 그래서 때론 질문들에 ‘나’를 가득 채워넣은 것 같아도 불안하고 방향감을 상실한 것 같은 느낌을 받을 수 있다. 이런 허무하고, 불안하고, 앞으로 뭘 해야할지 모르겠는 등의 느낌은 우리 정신이 ‘나’ 좀 돌아봐달라는 신호를 보내는 것이니 잠시 시간을 갖고 나를 되돌아보자.

결국 이런 질문들을 통해 나는 Frontend Engineer로서 개발자 커리어를 시작해야겠다고 생각했고 이것에 맞춰 공부 방향을 설정할 수 있었다. 그리고 이 결정을 내릴때 독서를 통해 얻은 컴퓨터공학에 대한 다양한 관점에서의 생각과 지식들은 내가 엔지니어링을 통해 어떤 일을 할 수 있는지, 세상에 어떤 변화를 만들어낼 수 있는지, 어떻게 다른 분야로 생각의 확장이 가능한지, 그 가능성은 다시 무엇을 의미하게 되는지, 그것은 또 내게 얼마나 큰 재미가 될지 등 더 많은 생각의 연결지점을 만들어주었다. 이때 Frontend로 방향을 잡았던 것은 스스로가 좀더 변화무쌍하고 시각적인 것에 더 관심이 있었고,  서비스와 사용자를 잇는 인터페이스인 프론트엔드가 매력적이었기 때문이었다. 물론 기술적인 것 자체에도 관심이 있었기 때문에 Backend 관련 지식들도 같이 가져가야겠다고 생각했다.

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

그렇게 거의 매일 퇴근후 JavaScript/HTML/CSS를 공부하고 당시에 관심이 갔었던 MEAN, MERN 스택으로 간단한 SPA를 만들었다. 대부분 책, Codecademy, 블로그 등을 통해 공부했었다. 그런데 이 1년간 정말 힘들었던 것이, JavaScript만 해도 생각보다 너무 번잡(?)하면서 어려웠고(이게 왜 이런거야..? 라는 질문을 많이 했었다), HTML과 CSS도 각각 깊게 들어가면 굉장히 깊다는 것을 알게 되었고, Frontend의 history와 계속 변하는 trend에 대한 전후맥락을 모르다보니 Angular나 React, Redux, Webpack, Babel 등 눈앞에 아른거리는 것들을 선택하고 익히는 모든 과정이 어려웠다(지금도 잘 모름…). 그리고 무엇보다 이 모든 것들을 인프라 일들을 하고 퇴근한뒤 집에와서 찔끔찔끔 해야하는 것이 가장 힘들었다. 뭔가 조금 알만하고 재밌어진다 싶으면 12시가 넘어있고 출근을 위해 잠을 청해야했다. 또 출근을 하면 인프라를 해야한다는 스트레스가 계속 쌓여갔다.

선택

그렇게 1년을 보내고 퇴사를 했다. 다음 회사를 확정짓지 않은 상태에서 퇴사를 했기 때문에 다소 위험한 선택이었으나 정신적 소모가 컸던 점, 나만의 시간을 더 많이 갖고싶었던 점, 개발자가 아닌 상태로 시간은 계속 흐른다는 점을 중요하게 생각했다. 그 뒤 회사를 리서치하기 시작했는데 아래와 같은 기준으로 다음 행보를 정했다.

  • 문제를 해결하는 서비스인가? 가령, 상품을 팔더라도 정보불균형을 해소하는 서비스인가? 내가 그 목적을 이해할 수 있는가? 회사 구성원들은 자신들이 문제를 해결하고 있다고 생각하는가?
  • 어떤 팀인가? 어떤 분위기인가? 질문을 자유롭게 할 수 있는가? 문제점을 자유롭게 지적할 수 있는가? 이런 모든 것에 열려있는 문화인가?
  • 어떤 기술을 사용하는가? 너무 트렌드를 좇는가? 너무 과거에 묻혀있는가? 그 중간인가? 어떤 개발문화를 갖고 있는가?

이런 종류의 질문을 처음 해보았고, 첫 커리어를 시작하는 만큼 스스로 설정한 기준도 서툴렀고, 회사들과 면접을 진행하면서 이것들을 확인하는 과정도 서툴렀다. 다만 당시 내게 가장 중요한 것들이었고 현재 수정은 되었지만 지금도 큰 틀은 유지하고 있을 정도로 내게는 여전히 가장 중요한 기준들이다. 어떤 회사에 지원하고, 어떤 회사를 선택해야 할지 모두 어려운 결정이지만 포기할 수 없는 자신만의 기준을 갖고 있다면 크게 어렵지 않게 선택을 내릴 수 있을 것이다.

이때 레주메도 처음으로 구조를 생각해 PDF로 만들어보았다. 무슨 기술에 관심이 있고, 무엇을 만들어봤고, 나는 어떤 사람인지 간략하게 나타낼 수 있도록 작성했었다(물론 별로 매력적이지 않았을테지만..). 당시엔 실제로 진행 및 운영해본 큰 프로젝트가 없었기 때문에 위의 내용과 그간 만들었던 작은 개인 프로젝트 한두가지에 대해서 설명하는 것까지 포함해 최대 2장을 넘기지 않도록 만들었다. 그런데 정말 중요한 것만 담는다면 1장으로도 모두 표현할 수 있을 것 같다는 생각이 든다.

그리고 회사마다, 지원하는 팀마다, 심지어 사람마다 중요시하는 것이 크고 작게 모두 달라서 레주메에 어떤 내용을 꼭 어떤 방식으로 담아야만 한다라는 등의 정해진 것은 없는 것 같다. 그래서 많은 분들이 ‘실력 30% + 운 70%’와 비슷한 표현을 많이 하는 것은 아닐까 생각해본다. 내가 중점을 두어 나타낸 것이 누군가에겐 좋게, 누군가에겐 그저 그렇게 느껴질 수 있다는 가능성 자체를 생각해 본다면, 할 수 있는 만큼 무엇이든 열심히 만들고 공부한 다음 그것을 나의 언어로 잘 표현해 레주메를 일단 만들고나면 그 뒤는 내가 어떻게 컨트롤할 수 없는 영역이므로 더 이상의 신경은 쓰지 말아야 할 것이다. 다시 말해, 내가 바꿀 수 있는 부분과 내가 더 잘할 수 있는 부분에 더 신경쓰고 집중하는 것이 효과적이고 건강한 선택일 것이고 좋지 않은 결과에 크게 연연해 하지 않아도 될 이유도 여기에서 찾을 수 있을 것이다. 그러니 하고싶은 일이 있고, 가고싶은 회사가 있어서 ‘30%’를 열심히 준비해 여러곳에 레주메와 함께 apply를 했는데 결과가 좋지 않아도 절망하지 말자. 그저 그 결과에서 ‘30%’를 어떻게 개선할 수 있을지 생각 및 실행해보고 될때까지 도전해보자. 마흔여덟번 실패해도 마흔아홉번째에 성공하면 성공이다.

스타트업에서의 시간

KakaoTalk_Photo_2018-09-27-17-18-37

그렇게 원티드를 통해 여러번의 면접 끝에 회사를 선택하고 스타트업에서 Frontend Engineer로 일하기 시작했다. 드디어 커리어를 전환했고 원하던 일을 하기 시작했다. 안정된 곳을 떠나 도전을 하는 만큼 불안하고 두려웠지만 많이 설레고 신나는 경험이었다. 바라던 기준들을 충족하는 곳이었고 멋진 사람들과 일할 수 있어서 즐거웠다. 그러나 모든 것이 낯설었다. 규모도 다르고, 일도 다르고, 팀의 성격도 다르고, 일의 접점도 다르고 모든 것이 달랐다. 그래서 적응의 시간이 필요했고 앞으로 일을 하고 내적인 성장을 이루기 위해선 또 다른 기준과 방향이 필요했다.

커리어 전환을 준비하면서 답했던 질문들을 바탕으로 이번에는 아래와 같은 큰 기준들을 세워 다시 흡수하기 시작했다.

  • Communication
    • 같은 부피의 얼음 덩어리보다 깨진 얼음이 더 빨리 녹듯 스타트업의 구성원은 일의 접점이 대기업에 비해 더 많고 그만큼의 책임과 역량을 요한다. 그래서 접점이 많은 만큼 팀 내부와 팀 외부와의 커뮤니케이션이 상당히 많은 편이다.
    • 그렇다면 팀 내에선 어떻게 소통해야 하는가? 나와 같은 포지션인 사람과 어떻게 이야기 할 것인가? 다른 포지션인 사람과는 어떻게 소통해야 하는가? 포지션별로 각각 어떤 특성을 갖고 있는가? 각각의 입장은 어떠한가? 이 입장의 다름을 바탕으로 서로 업무에 대해 이야기할때 어떤 방식으로 이야기하면 좋은가?
    • 반면, 팀 외부와는 어떻게 소통해야 하는가? 개발자인 나는 서비스를 함께 만들어 나가는 입장에서 경영진, 마케터, 디자이너 등의 사람들과 이야기할때 각각 어떻게 소통해야 하는가? 그들이 갖고 있는 최우선 관심사는 무엇인가? 그들이 내게 바라는 것과 내가 그들에게 바라는 것은 서로 얼마나 다른가? 그 차이는 어디서 오는가? 차이의 크고 작음이 중요하지 않다면 우리는 공동의 목표를 위해서 어떤 이야기를 해야하는가? 나의 priority가 그들의 요구와 상충한다면 나는 무엇을 기준으로 재설정을 해야하는가? 아니면 누구와 어떻게 상의하고 그 결과를 어떤 방식으로 알리면 좋은가?
  • Problem Solving & Capability
    • 문제해결이란 무엇인가? 크게는 사회에 산재해있는 문제를 해결하고 작게는 주어진 데이터를 Array로 어떻게 필터링할지 코드를 만드는 것이 아닌가? 내가 만드는 서비스는 사회의 어떤 문제를 해결하려고 하고 있는가? 그것이 잘 되게 하려면 무엇을 더 해야하는가? 내가 속해 있는 포지션의 특성에 따라 나는 어떤 기술을 더 집중적으로 다뤄야 하는가? 내가 알고있는 기술로 어떤 기간내에 무엇을 얼마나 빠르게 만들 수 있는가? 지금 내게 가장 필요한 기술적 역량은 무엇인가? 어떤 순서로 기술들을 습득하면 좋은가? 지금 만드는 서비스에 어떤 기술을 얼마나 적용할 수 있는가? 그것이 서비스에 얼마나 영향을 미치는가?
    • 나는 JavaScript를 얼마나 이해하고 있는가? 나는 이 언어로 얼마나 나의 생각을 잘 표현할 수 있는가? 이 언어의 역사는 무엇인가? 지금껏 왜 이런 변화를 겪어온 것인가? 이 언어가 가진 가장 큰 문제점은 무엇인가? 그것이 개발을 할때 어떤 영향을 미치는가? 이것을 보완하기 위해 어떤 것들을 활용할 수 있는가?
    • 나는 얼마나 논리적으로 생각할 수 있는가? 나는 얼마나 추상적으로 생각할 수 있는가? 생각의 추상화와 코드의 추상화는 서로 얼마나 닮아있는가? 코드는 어디까지 추상화하면 좋은가? 추상화가 왜 필요한가?
    • Frontend와 Backend를 각각 어느 비율로 학습해나가면 좋은가? 하나에 치중할 것인가? 8:2와 같은 비율로 공부하는 것은 좋은 방안이 될 수 있는가? 조금이라도 Backend를 다룰 수 있는 것은 개발자로 일할때 어떤 이점이 될 수 있는가? 커뮤니케이션에 도움이 될 수 있는가?
  • Running Business and Service
    • 개발자는 어떤 존재인가? 코드만 만들어내는 직업인가? 비즈니스를 움직이게 만들 수 있는 직업인가? 기술적인 것에 특히 집중하는 개발자가 되고싶은가? 기술 뿐만 아니라 주어진 기술들의 조합으로 비즈니스와 서비스를 생각해내고 가치를 만들어낼 수 있는 안목을 가진 개발자로 성장할 것인가? 나는 서비스를 위해 어떤 개발을 해야하는가? 버튼의 위치에 따라 트래픽이나 컨버전이 달라질 수 있음을 이해하는가? 이것이 의미하는 바가 무엇인가? 개발자는 사용자를 얼마나 이해해야 하는가? 사용자는 서비스를 사용할때 어떤 생각을 하는가? 사용자는 무엇에 따라 움직이는가? Web Frontend는 사용자의 이런 특성을 어떻게 잡아낼 수 있는가? User Experience는 어떻게 일어나는가? 이 사용자 경험을 향상시키는 일에는 어떤 것들이 필요한가? 그렇다면 나는 기술 뿐만 아니라 기능의 전체적 조합이 어떤 사용 흐름을 만들어내는지 또한 이해해야 하는 것은 아닌가? 이 안목을 키우려면 무엇을 공부하고 어떤 자세로 서비스를 만들어야 하는가?

대기업에서도 배울 수 있는 것이 많지만 조직 구성의 특성상 스타트업에서는 위와 같이 훨씬 더 많은 접점을 갖고 있어 성장 포인트를 많이 가져갈 수 있다고 생각한다. 질문이 많은 것 같아도 스타트업의 특성을 잘 이해하고 그것을 활용해 내가 어느 부분에서 무얼 더 잘할 수 있는지(장점을 강화), 부족한 부분이 어딘지 파악하고 개선을 어떻게 해볼지(단점을 보강) 등의 메타인지를 계속 키워나가면 밸런스있는 성장 전략을 만들어 볼 수 있고 내가 어떤 사람인지에 대해서도 알 수 있는 계기가 될 수 있으리라 생각한다. 무엇보다 이렇게 촘촘한 질문을 준비해놓고 주기적으로 확인하는 과정을 갖는다면 내가 아는 것과 모르는 것이 무엇인지 알 수 있기 때문에 적어도 무엇을 알고 모르는지를 몰라서 생기는 불상사는 막을 수 있다. 가령, 배울 수 있는 포인트가 있는데 놓친다든지(그게 배울 수 있는 것인지 몰라서), 모르는 무언가가 회의에서 나왔는데 그게 무엇이고 어느 맥락에서 필요한지 모르는데 알아야할 필요성을 못느끼는(알아야 하는 것임에도) 경우 등을 막을 수 있고 막을 수 없더라도 최소한 이런 것이 존재한다는 것을 인지할 수 있다.

이와 더불어 개발자로서 배울 수 있는 것들 중 몇몇 대기업에서도 가능하지만 대체적으로 스타트업이기에 가능한 것들이 있는데, 바로 기술 스택을 전체적으로 다뤄볼 수 있다는 점이다. 나의 경우, Admin Web과 B2C Web 두 프로젝트를 진행했는데 Admin 프로젝트는 초기에 Frontend와 Backend를 모두 했어야했다. Frontend는 react, redux, redux-saga, reselect, webpack(v3), Backend는 Node.js로 express, sequelize, passport, MySQL을 사용해 만들었다. 전체 구조를 다루는 만큼 하나하나를 깊게 알기는 어렵지만 네트워크 요청이 어느 과정을 통해 서버를 거쳐 브라우저가 응답을 받는지, 비동기 처리는 어떻게 다루면 좋을지, 여러 스택들이 어떻게 연결되어 있는지 등 좀 더 큰 관점에서 구조를 바라보며 개발을 해볼 수 있다. 이 경험은 다시 백엔드 개발자와 더 쉽게 커뮤니케이션을 하는데 도움이 될 것이다.

그간 한가지 아쉬웠던 점은, 서비스를 만들고 기능을 수정하고 추가하는 일에 집중하다보니 어떤 기능을 만들때 어떤 구조로 만들면 좋을지, 이 코드가 좋은 코드인지 등에 대해서 생각해볼 기회가 많이 없었다. 아마도 빠르게 성장해야 하는 환경에서는 좋은 아키텍쳐와 코드에 대해서 생각할 여유를 갖기가 많이 힘들 것 같다. 그래서 작지만 빠르고 확실한 성장을 거듭해나가는 전략을 취하면서 시작부터 좋은 아키텍쳐와 코드를 지속적으로 생각해볼 수 있는 문화 및 환경을 구성하는 방식을 택하는 곳이 늘어나는 것 같다. 이미 프로젝트가 비대해진 뒤에 그런 문화나 환경을 중간에 도입 하기에는 우선 그것에 드는 비용과 시간에 대해 경영진을 설득해야 하고, 그것을 지금껏 하지 않았던 개발 조직 또한 설득 및 교육을 하고 천천히 적용하는 데 적잖은 시간과 에너지가 소비될 것이기 때문에 어렵지 않을까싶다.

KakaoTalk_Photo_2018-09-27-17-18-23 (1)

추가적으로, 스타트업에서 일한다는 것이 어떤 것인지에 대해 Paul Graham의 ‘해커와 화가’라는 책에서 정말 잘 표현했는데 스타트업에서 시간을 보낸다는 것, 압축적으로 성장한다는 것에 대해서 이해할 수 있었던 고마운 책이다. 참고로 Paul Graham은 Dropbox, Docker, Reddit, Airbnb 등의 스타트업들을 인큐베이팅한 Y Combinator의 공동창업자이다. 꽤 오래전에 쓰인 책이기 때문에 어느 정도 현재 한국 상황에 맞게 재해석하여 읽을 필요가 있다.

이외에 그간 일하며 스타트업 및 개인적 성장에 관련해 썼던 글이 있는데 ‘스타트업에서의 시간’이라는 현재 단락의 연장선상에서 내용을 보충하는 것 같아 아래의 링크를 첨부해본다.

Simple Comparison: Big and Small companies

C7F759C9-7279-4826-BBA9-6EF0C7FA12AA-1-2732x2048-oriented
얼음을 회사에 빗댈 수도, 개인에 빗댈 수도 있을 것 같다.

앞서 ‘같은 부피의 얼음 덩어리와 깨진 얼음’ 이라는 표현을 사용했는데 대체로 이 비유가 큰 회사와 작은 회사의 비교를 적절히 잘 나타내는 것 같다. 어떤 점이 그런 것일까? 바로 스타트업의 구성원은 깨진 얼음 조각들처럼 같은 부피의 얼음 덩어리보다 표면적이 훨씬 넓다는 점에서 그렇다. 표면적이 넓다는 말은 곧 접할 수 있는 업무의 종류 또는 양, 관리해야할 포인트, 그에 따르는 권한 및 책임 범위가 더 많고 넓다는 의미이다.

이런 배경에서 전통적인 대기업(conglomerate) 및 비교적 최근에 생긴 Software based 대기업들도 employee 개개인에게 주어지는 책임과 권한이 전통적인 시스템에 비해 더 커졌을때 risk가 더 커질 것 같지만 오히려 risk handling이 용이해지고 더 나은 product 개발 및 관리가 가능해지는 점을 이해하고 팀 조직의 구성을 스타트업의 그것과 유사하게 가져가기 시작했다. 확실히 전통적인 제조 기반 대기업에서는 보기 어려운 구조이다. 개인적인 경험과 독서를 바탕으로 그간 생각해온 큰 회사와 작은 회사의 비교는 아래와 같다.

Big

  • 거의 항상 조직이 잘 나뉘어있고 분업화가 되어있다.
  • 분업화는 팀이 구성되는 발판이 되는 경향이 있고 효율적인 커뮤니케이션을 위해 회사마다 각기 다른 직급 체계를 마련한다(때로 직급 체계가 없고 role 기반의 명칭만 부여되는 경우도 있다).
  • 직급이 있는 경우, 일반적으로 팀과 직급 체계는 적게는 몇백명에서 크게는 몇만명의 많은 구성원을 효과적으로 조직하기 위해 탄생한 체계이기는 하나 되려 이 체계 때문에 개인 스케일로 큰 책임과 권한이 주어지는 일이 방해가 되기도 한다(그래서 하는 일이 때론 단조롭고 긴장감 있지 않아서 재미가 없다는 사람들도 종종 보인다).
  • 따라서 이런 규모의 회사에 간다면 상대적으로 자신이 하는 일에서 보람이나 정체성 및 커리어의 성장을 구체적으로 느끼기는 어려울 수 있다(위에서 언급한 스타트업과 유사하게 팀을 구성하는 대기업이라면 논외가 될듯).
  • 반면, 책임과 권한이 아주 크지는 않은 만큼 주어진 업무에 대해 큰 부담을 느끼지 않아도 되는 분위기가 다소 있다(‘대기업에서 편하게 다닌다’라는 말은 아마 여기에서 유래하지 않았을까 짐작해본다. ‘스타트업에서 편하게 다닌다’라는 말은 들어본 적이 없는 것 같고 벌써 말부터 뭔가 어색한 것 같다. 아마 이만큼 서로의 전반적인 분위기가 차이가 나지 않을까.).
  • 조직 및 체계가 갖춰져 있으므로 상대적으로 깔끔한 업무 분리를 경험할 수 있고 조직 및 체계에 대한 직간접적인 경험을 해볼 수 있다(물론 이런 체계가 갖춰진 스타트업을 간다면 비슷한 경험을 할 수 있을듯).

Small

  • 전반적으로 큰 기업의 내용들이 정반대로 적용되는 것 같다.
  • 많은 경우, 체계가 큰 기업처럼 되어있지는 않다. 그래서 Job Description 이외의 업무를 할 수도 있다. 그래서 전혀 접해보지 않은 다양한 일을 해보게 되는 이런 점이 사람에 따라 장점이 될 수도, 단점이 될 수도 있다. 이후에 자신의 비즈니스를 일구고자 하는 사람이라면 아주 큰 장점이 될 수도 있을 것이다.
  • Cross Functional 하게 일하기에 좋은 환경을 갖추고 있다. 규모가 작기 때문에 가능한 일이기도 한데 서비스의 특정 기능 중심으로 다른 포지션의 사람들과 함께 긴밀히 일해볼 수 있다는 점에서 작은 회사의 분명한 장점일 것이다.
  • <아이디어 구상 -> Rapid Prototyping -> (서비스 런칭) -> 피드백 -> 빠른 업데이트 -> 가설 검증 및 평가>의 사이클을 접해볼 수 있다. 이렇게 빠른 가설 검증을 경험해봄으로써 비즈니스에 대한 감각, 효율적인 커뮤니케이션, 부분적인 리더쉽 등을 키울 수 있다.
  • 한 개인에게 부여되는 책임과 권한이 큰 기업에 비해 크기 때문에 부담감이 조금 있으나 그만큼의 책임을 감당해내는 경험을 할 수 있다. 서비스의 문제 및 체질 개선에 대한 아이디어 제안, 개진 및 테스트를 해볼 수 있다.

Big과 Small을 각 양극단이라고 봤을때 모든 회사는 이 중간 어딘가에 있다고 생각한다. 스타트업도 결국 성장하면서 몸집을 키우기 때문이다. 그런데 최근엔 회사의 규모에 상관없이 회사들이 각각 정말 다양한 체계 및 문화를 갖고 있어서 이런 식의 비교는 부분적으로만 의미가 있을 것 같다. 다만 전반적으로 이런 특성이 있다는 것을 이해한다면 나에게 맞는 회사를 선별하는데 도움이 될 수 있을 것이다.

앞서 ‘커리어 전환과 이직을 위한 준비’ 단락에서 여러 질문을 통한 스스로에 대한 이해에 대해 이야기했는데 내가 어떤 성향의 사람인지, 어떤 미래를 꿈꾸는지, 어떤 개발자로 성장하고 싶은지, 어떤 방식으로 일하는 것을 선호하는지 등 나 자신을 잘 이해하고 있다면 이러한 회사 규모에 따른 차이점의 세세한 부분을 잘 활용해 어느 회사에서 일하면 좋을지 생각해볼 수 있을 것이다.

이외에 도움이 된 것들

지금껏 대기업에서 스타트업으로 넘어오기까지의 준비 과정과 둘의 비교에 대해 다루었는데 이동을 준비하고 겪으면서 이외에 도움이 된 것들이 상당히 많이 있어서 아래와 같이 정리를 해보았다.

  • 영어
    • 영어는 어떻게 설명해야 할지 모르겠는데 무슨 일을 하든 항상 도움이 되어서 갖추면 정말 좋은 도구라고 생각한다. 개발자로서 가장 대표적으로 도움이 되는 예가 있는데, 구글링을 통해 찾을 수 있는 온갖 종류의 기술 아티클, 공식 문서, 학습 영상(Youtube, Coursera, Udemy 등)의 대부분이 영어로 되어있어서 곧바로 이것들을 흡수할 수 있기 때문에 큰 도움이 된다.
    • 그리고 업무(회의 및 커뮤니케이션 등)를 하거나 면접을 보는 경우에도 종종 영어로 모든 것을 해야할 때가 있는데 이때도 영어가 가능하다면 성장과 기회의 폭을 더 넓힐 수 있다.
    • 이외에 Youtube나 Ted에 기술이 아닌 다른 종류의 볼 것들이 정말 많기 때문에 다채로운 개발자로서 그리고 한 인격체로서 성장하고 시야를 확장할 수 있는 기회가 많아진다. 개인적으로 Ted를 보고 영어로 소감을 나누는 스터디를 9개월간 하면서 정말 재밌고 신기한 느낌을 많이 받았었다. 아직도 그때 본 영상들이 기억에 남고 지금 하는 일들에 도움이 되고 있다. 특히 대화했던 것들이 영어 면접을 진행할때 큰 도움이 되었다.
  • 독서
    • 독서가 커리어를 전환하고 이직을 하는데 직접적으로 도움이 된 것 같지는 않다. 다만, 그 과정에서 나를 이해하는 과정이 필요했는데 독서가 그것에 지대한 영향을 미쳤고 질문에 답하는 과정을 매우 수월하게 만들었기 때문에 독서를 빼놓을 수는 없을 것 같다.
  • 글쓰기
    • 글쓰기는 독서와 비슷한 면이 있는데 가장 큰 차이점은 독서를 할땐 지식과 그 지식을 담은 틀을 흡수하지만 글쓰기를 할땐 이번엔 나의 반응을 나의 언어로 표현을 해야한다는 점이다. 읽고 보고 흡수하는 것은 상대적으로 쉽지만 머릿속에 있는 것을 정리해서 풀어내는 것은 상당히 어렵다. 무언가를 학습 했을때 나의 언어로 설명할 수 없다면 아마 그것은 이해하지 못한 것일 것이다. 이런 맥락에서 글쓰기는 생각을 정리하고 나의 언어로 지식을 재구성하는 데에 큰 도움이 될 수 있다.
    • 그리고 글을 쓰면 나중에 참고할 수 있다. 잊었던 것을 다시 꺼내볼 수 있고 그간 내가 무슨 생각을 하고 어떤 이해를 하고 있었는지에 대한 궤적을 확인할 수 있다.
  • 블로그
    • 위에서 했던 글쓰기가 세상으로 나오게 하는 활동이라고 생각한다. 완전히 선택 사항이지만 심사숙고해서 쓴 글을 다듬어 내보내면 그 지식을 필요로 하는 누군가에게 도움이 될 수 있고 더불어 지식에 관해 쓴 글이라면 틀린 부분이 있을때 다른 이에게 피드백을 받아 나의 지식을 교정할 수 있는 기회를 얻을 수 있다.
    • 그리고 다른 사람들에게 레주메를 통해 보여줄 수 없는 나에 대한 여러 면모를(나는 어떤 사람인지, 어떤 가치관을 갖고 있는지, 어떤 관심사를 갖고 있는지, 어떤 미래를 꿈꾸는지, 어떤 성향의 사람인지 등) 보여줄 수 있는 좋은 채널이 될 수 있다.
  • 운동
    • 근데 이렇게 구구절절 떠들었어도 사실 인생은 건강이 최고인 것 같다.. 돈이 있고 예쁜 맥북이 내 옆에 있어도 건강하지 못하면 그 어느 것도 영위하고 지속할 수 없다. 그래서 풀업, 푸쉬업, 스쿼트 등 바디웨이트 운동을 계속 하고 있는데 그간 공부하고 회사를 옮기면서 받은 스트레스를 많이 날릴 수 있었고 전보다 좀더 오래 공부하고 코딩할 수 있었던 것 같다.
  • 세미나 및 다른 분들의 블로그
    • 이직을 하기 전에 Google Developer Group Korea에서 열었던 Job Fair, Job Recruiting with Wanted 등에 참여했는데 다양한 사람을 만났고 개발자로서 커리어를 쌓아가는 것에 대해 많은 힌트를 얻을 수 있었다. 양찬석님이 커리어에 대해 별 다른 것은 없고 그저 꾸준히 배우고 이것저것 만들어나가면 되지 않을까라고 말씀하셨던 것이 아직도 기억에 남는다. 세미나나 컨퍼런스 등을 참석하면서 다른 사람들과 만나 그들의 생각을 듣고 교류하는 과정에서 즐거움도 있었고 앞으로 어떻게 살아야할지, 커리어를 어떻게 만들어갈지에 대해 많은 힌트를 얻을 수 있었다.
    • 스타트업으로 오기 전에 구글링을 하다가 진유림님의 블로그를 들어가게 됐는데 한창 이것저것 알아보고 구경하고 만들어보던 시기여서 거의 정독을 해버렸다. 특히 TIL과 북리뷰를 많이 봤는데 개발과 독서를 좋아시는 분 같다고 생각했었다. 큰 자극이 되어 고마운 마음에 블로그 대문에 댓글을 썼었는데 스타트업으로 오고나서 2018년 4월 쯤 패스트캠퍼스 개발자 세미나에서 만나뵙게 되었다. 내겐 커리어 생명의 은인(?)같은 분이라 되게 반가웠고 신기했다. 다른 개발자들의 활동을 블로그나 GitHub을 통해 살펴보는 것도 나는 무엇을 하면 좋을지 고민할때 많은 도움이 되는 것 같다.

마치며

긴 글을 드디어 마무리한다. 대기업에서 스타트업으로 옮기기까지의 과정을 주로 이야기 했지만 써놓고 보니 사실 핵심은 ‘나를 이해하는 것’이지 않았나 싶다. 그리고 이 글은 Infra Engineer에서 Frontend Engineer로의 전환이라는 position-specific한 한정된 내용을 다루기 때문에 다른 포지션에 종사하는 분들에게는 별다른 도움이 안될지도 모르겠다는 생각도 든다. 그래도 나의 한 사례에 빗대어 다양한 상황들에 적용되어 방향 설정에 도움이 되기를 바라며 글을 마친다.

Advertisements

오픈소스에 한걸음 더: 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

 

세미나 당일에 찍은 사진들

나만의 길을 걷는 것

두려움

개발자로 일을 한지 이제 11개월이 되었다. 긴장감이 끊이질 않았다. 하루를 마감할때 쯤이면 다음 날과 그 주에 해야할 일을 생각해보는 버릇이 생겼다. 뭘 해야할지 정리가 안된 상태에서 일을 시작하는 것이 너무 무서웠기 때문이다. 못하면 어쩌지라는 걱정과 함께. 물론 그렇게 했음에도 예상대로 진행된 적은 단 한번도 없었다.

시간이 지나 두려움은 약간의 익숙함으로 변했고 그 안에서 미래를 고민하기 시작했다. 현재 걷고 있는 길에 대해서도 다시 고민하게 되었다. 아마 많은 직장인들도 이런 고민을 하지 않을까?

가령, 이렇게 해서는 발전이 전혀 안될 것 같은데 어떡한담..?, 지금 이렇게 하고 있는 게 맞는 걸까?, 이대로 가면 내가 원하는 방향으로 가는 걸까?, 남들은 이만큼 하고있는 것 같은데 나는 그만큼 하고 있는걸까?, 나는 왜 학습 속도가 늘지 않는걸까?, 공부는 많이 한 것 같은데 왜 삶에 변화가 없는 것 같지?, 지금 몸담고 있는 분야 말고 또 어떤 분야를 터득해야 할까?.. 등

모두 나 스스로 해본 질문들이다. 직장인으로 살았던 3년 가까운 시간동안 끊임없이 나를 괴롭힌 질문들이다. 분명 몇개월 전에 답했던 질문 같은데 어느새 또 질문을 되뇌이고 있는 나를 종종 발견한다. 질문의 수만큼 두려움을 느꼈다. 왜 또 떠오르는 질문은 그렇게 많은지. 그간 수많은 질문을 스스로에게 던지고 답하면서, 답하기 위해 책과 신문을 읽고 글을 쓰면서 다행히 두려움과 불안감을 많은 부분 해소했다. 어느 정도 해답을 찾은 것 같아 그간의 고군분투를 정리해보고자 한다.

좋은 질문을 해야 좋은 답을 얻는다

누구도 가지 않은 길, 사람들이 잘 가지 않는 길 혹은 대부분의 사람들이 가는 길 중 어느 것을 선택해야 할까? 이 문장을 잘 뜯어보면 내 길을 정하는 데 있어 기준은 내 안이 아닌 남들이 어떤 길을 가느냐에 있다. 다시 말해, 이 문장에 답을 하게되면 필연적으로 그 대답은 타율성을 띄게 된다. 내 길을 선택함에 있어 다른 사람들의 행동을 살피고 있기 때문이다. 그래서 결론적으로는 내 길을 선택하는데 있어 이 질문은 큰 도움을 주지 못한다. 그런 의미에서 좋은 질문은 아니다.

본질적으로 중요한 것은 내가 누군지 이해하고, 내 마음을 따라 정말 하고자 하는, 온전히 열정과 에너지와 시간을 쏟을 수 있는, 큰 보상이 없어도 그걸 하는 것만으로도 좋은, 동시에 생계는 해결해줄 수 있는 길을 찾는 것 그리고 그 길을 묵묵히 걷는 것이지 않을까. 어떤 길을 선택하고 그 길을 걷는 이유를 내 안에서 찾는 것이기 때문이다. 그래서 질문을 바꿔야 한다.

  • 나는 어떤 사람일까?
  • 평생 어떤 일을 하면 아무 후회가 없을까?
  • 나는 무엇에 열정이 있을까?
  • 지금 갖고 있는 관점으로 별로라고 판단했던 많은 것들 중에 다른 관점으로 보면 완전히 다른 판단을 내릴 만한 것들이 있을텐데 그것들은 무엇일까?
  • 나는 나의 취향과 편향에 따라 지금껏 내린 가치판단들을 얼마나 신뢰할 수 있을까?

나 자신에 대해 알게 해주는 질문을 많이 던지면 던질 수록 미궁에 빠질 것 같지만 놀랍게도 생각이 훨씬 더 분명해진다. 질문에 하나씩 답하다보면 어느 질문에 답하기 위해서는 다른 질문에 대한 답을 선행해야만 하는 경우가 있다. 그런 것들을 그림으로 그리는 방법 등을 통해 질문들을 연결하고, 얻은 대답들을 모아놓고 구조를 살펴보면 더 전체적인 ‘나’가 보인다.

나만의 보폭

어느 길을 걸을지 정한 뒤 조금 걷다보면 분명히 나아가는 속도에 대해 생각을 하기 시작할 것이다. 그럼 또 아래와 같은 질문 다발을 맞이하게 된다.

  • 모르는게 너무 많은 것 같은데 왜 이 모양이지..?
  • 나는 학습이 좀 느린 것은 아닐까?
  • 이 속도로 가는 건 남들에 비해 좀 느린 건 아닌가?
  • 기반 지식을 넓히면 속도를 개선할 수 있는가? 관련된 책이 있을까?

어떤 질문은 자신을 외부와 비교해보게 하고 어떤 질문은 나에 대해 더 깊이 알아보도록 주문한다. 이 경우에도 앞선 문단과 맥락을 같이 한다. 외부와의 비교를 할때는 참고 수준에서 답을 내리고 나에 대해 이해하도록 만드는 질문을 많이 해야한다. 특히 학습의 속도에 대해 고민할때 남과의 비교는 자신이 최고 반열에 들지 않는 이상 나는 ‘어쨌든 느린’ 사람이 되어버리기 때문에 백해무익하다. 따라서 ‘저 정도 수준의 사람은 저 속도로 나아가니 나는 이 정도면 적당하겠구나’ 식의 참고까지가 좋을 것이다.

조승연의 ‘공부 기술’, Henry Roediger의 ‘어떻게 공부할 것인가’, 이준영의 ‘구글은 SKY를 모른다’, 학습과 교수법에 관한 희대의 역작인 Ken Bain의 ‘What best college students do’, Angela Duckworth의 ‘GRIT’, Anders Ericsson의 ‘1만 시간의 재발견’ 등 여태 읽은 학습에 관련된 책들을 종합해보면 인간의 학습에는 심적 구조물이 활용된다. 실제로 Anders Ericsson은 그의 저서에서 이를 두고 심적 표상이라는 단어로 표현했는데 가령 이런 것이다.

img_0037
이런 심적 구조물을 3차원으로 머릿속에서 그리거나 이미지와 연결지을 수도 있다. 심지어 이 그룹들에 색을 입혀 기억을 도울 수도 있다. 그림은 아이패드로 그렸다.

단어를 기억하는 방법은 여러가지가 있을 수 있다. 단순히 단어별 의미를 기억하는 방법, 단어가 가진 패턴을 분리해 새로운 단어를 패턴 그룹에 묶어서 기억하는 방법, 주제 및 상황 별로 묶어서 기억하는 방법 등 다양하다. 머릿속에 그림을 그려 구조를 만들고 그 안에서 단어들을 이리저리 옮기는 식의 방법이라면 심적 구조물을 활용하고 있는 것이다. 마음에 그림을 그리니까 말이다. 이때 중요한 것은 ‘외국어 잘하기’라는 목표아래 세부 목표로 단어를 많이 익히기로 했다면 더 좋은 심적 구조물을 갖고 있을 수록 더 빠르고 더 정확히 목표를 이룰 수 있다.

그런데 문제는 사람마다 갖고 있는 심적 구조물이 서로 다르고, 가진 갯수도 다르며 각각의 질 또한 다르다는 것이다. 영어 뿐만이 아니라 모든 종류의 학습에서 심적 구조물이 활용된다. 수학, 스포츠, 의학, 과학, 예술, 컴퓨터 공학 등 인간이 하는 모든 종류에 적용된다. 위상 수학에서 새로운 모델을 생각할때, 방사선과 의사들이 엑스선 사진 판독을 할때, 음악가가 선율을 머릿속에서 그릴때, 심지어 연주할때, 엔지니어가 딥러닝 모델 구조를 생각할때 등을 예로 들 수 있다.

학습의 속도가 걱정이 된다면 문제를 바라볼때 활용하는 내가 가진 심적 구조물을 생각해야 한다. 속도에 영향을 미치는 거의 유일한 변수이기 때문이다(여기서 지능은 의미가 없다. 지능이 낮아서 심적 구조물을 많이 생각해내지 못할 것 같은 걱정이 든다면 1만 시간의 재발견을 꼭 읽을 것을 권한다.). 따라서 내 생각의 방식의 구조와 틈새 그리고 한계를 면밀히 살펴보는 것이 우선이며 그 뒤에 한 단계씩 나아가야 한다. 아마 이렇게 걷는 것부터 ‘나만의 보폭’으로 걷고 있다고 말할 수 있을 것이다. 이런 점에서 남보다 늦고 빠르고 또한 별 의미가 없다. 이러한 보폭을 생각하는 일의 궁극적인 목표는 위 문단에서 얻은 나만의 길을 오래도록 걷는 것이기 때문이다. 남보다 더 잘 나가고 빠른 것을 원한다면 이 글은 소용이 없을 것이다.

개발자로서의 나는

글 전체의 흐름은 이어지지만 문단 별로 어느 정도 독립적인 내용을 담고 있으니 건너 뛰면서 읽으셔도 좋습니다.

Angular로 시작해 지금은 React 위주의 개발을 해오고 있다. 아주 많은 사람들이 이 분야에서 일하고 있기 때문에 이게 나만의 길이라고 말하기는 어렵다. 다양한 배경과 동기에 의해 이 분야를 택했을 것이고 나도 그들 중 하나다. 이 분야에서 왜 일을 하고 있는지, 나에 대한 이해와 개발자로 일하는 것이 서로 어떤 관련이 있는지 묻는다면

  1. 하다보니 너무 재미있고
  2. 재밌어서 더 하다보니 프로그램 자체가 아름다워서 신기하고
  3. 이걸로 해결할 수 있는 사회, 환경, 문화적 문제들이 많다는 걸 깨달았고
  4. 나 혼자만 잘 사는 것에 관심이 없기 때문에 더 멋지고 나은 세상을 만드는데 활용하고 싶고
  5. 가장 큰 관심사 중 하나인 교육 문제에 큰 영향력을 미칠 수 있다는 것을 깨달았기

때문이라고 현재까지는 이렇게 답할 수 있을 것 같다. 가장 근본적인 이유를 오랫동안 생각해온 것이기 때문에 아마 거의 변하지 않을 거라고 생각한다.

개인적으로는 이런 이유에서 이 일을 하고 있다. 단순히 돈을 벌고 커리어를 만들어나가는 관점도 있겠지만 그것만으로는 부족했기 때문에 근본적인 이유를 찾아 헤매온 것이다. 그럼 이대로 나아가면 될 것인가?, 이것만 계속 할 것인가? 라는 질문을 해볼 수 있는데 선뜻 그렇다고 대답하기는 어렵다. 당분간은 맞겠지만 10년, 20년을 생각해보면 그림이 잘 그려지지 않는다.

다행히 최근 우연히 머신러닝 분야가 위의 다섯가지 이유와 완전히 맞아떨어진다고 생각하게 되었고 이쪽 공부를 계속 해오고 있다. Tensorflow나 Keras 같이 ML/DL 모델을 빠르게 프로토타이핑 할 수 있는 걸출한 오픈소스들이 이미 엄청난 인기를 누리고 있고 이에 따라 굳이 이 분야를 병행하기 위해 반드시 대학원 진학을 해야만 하는 것은 아니기 때문에 계속 해나갈 수 있는 분야라고 판단했다. 앞으로는 블로그에 개발 외에도 모델링이나 수학에 관련된 글들도 많이 올려야할 것 같다. 개발 글도 거의 못쓰고 있는 형국이지만.. 먼산..

나의 이런 판단을 듣고 ‘굳이 프론트와 머신러닝을..?’ 이라는 반응이 더러 있었다. 의기소침할 뻔 했으나 생각해보면 또 안될 이유는 없지 않은가? 그래서 요새 페이스북에서 Sung Kim 교수님과 조대협님의 글들을 보면서 많은 용기를 얻고 있다(감사합니다!).

능숙해지기

아직은 개발과 공부에 엄청난 몰입을 하고 있는 것 같지는 않다. 위에서 나를 이해하네 어쩌네 했어도 남과의 비교에서 완전히 자유롭지는 못하…다. 인간이란.. 근래에 탁월함에 관한 어떤 글에서 Kobe Bryant는 자는 시간 6시간을 제외한 거의 모든 시간을 농구를 위해 사용했고, 월마트의 창업자인 Samuel Walton은 억만장자가 되어서도 항상 같은 태도를 유지했다는 내용을 보았다. 그럼 나는 그렇게 할 수 없는가? 라는 질문이 떠올랐다.

그들은 어떤 동기가 있었기에, 어떻게 동기를 계속 유지했기에 그렇게 엄청난 몰입을 했을까? 나는 하루에 자고 일하는 시간을 제외하고 거의 모든 시간을 개발과 공부에 쏟을 수 있을까? 나는 그들처럼 몰입할 수 있는 내적 동기를 갖추었는가? 내적 동기는 먼저 나를 이해해야 찾을 수 있는 것인가? 그럼 찾기만 한다면 그 뒤로는 실행과 correction만 남는 것일까? 그들은 그들의 분야에서 어디까지 가고 싶은 걸까? 아마 가고자 하는 목표에 따라 동기를 부여받는 방식과 빈도가 달라지지 않을까?

자신의 분야에 매우 능숙해지고 싶은 사람이 아주 많을 것이다. 잘하게 되면 얻을 수 있는 보상들이 많기 때문이다. 나는 왜 능숙해지고자 하는지 생각하기 전에 보상에는 어떤 것들이 있는지 생각해보자. 누군가는 자신의 꿈을 더 분명히 이뤄줄 길을 더 잘 보게될 것이고, 누군가는 더 많은 돈, 누군가는 사회적 인지도, 누군가는 기술과 지식 자체를 깊이 이해하고 갖고 노는 것에서 오는 희열감 자체를 원할 수 있다.

책, 페이스북, 링크드인 그리고 주위에서 유명하거나 아주 실력있는, 가히 괴물이라 부를 수 있을만한 사람들을 계속 보다보니 위에서 언급한 내적 동기와 보상은 능숙함의 정도와 무관하지 않음을 알게되었다. 그리는 꿈이 선명할 수록, 원하는 것과 이루고자 하는 것이 분명할 수록 더 많은 집중을 하게 될 거고 더 많은 시간과 에너지를 투자할 여지가 크다. 그것은 자연스레 능숙함의 향상으로 이어질 것이다. 무언가에 매우 능숙해지고자 한다면 내적 동기를 찾고 원하는 보상의 형태를 생각하고 그 이미지를 더 선명하게 만들어 보는 것이 도움이 되지 않을까 생각한다.

능숙해질 수 있는 대상은 참 많다. 내가 하고 있는 일, 타인과의 소통과 협업, 대인관계, 가정 꾸리기 등등. 그리고 놀랍게도 이 관계없어 보이는 것들 또한 서로 관련이 있다. 사랑하는 사람과의 관계는 분명 오늘 집중하는 일에 큰 영향을 미친다. 가정을 이루고 안정감과 행복을 느끼고 싶은 마음이 강하다면 가정을 이루는데에 관심이 가기 마련일 것이다. 또 자신이 대인관계와 다양한 분야의 타인과 소통하는 것에서 어려움을 느낀다면 그것 또한 커리어에 있어서의 능숙함에 영향을 미칠 것이다. 거대하거나 복잡한 서비스의 아키텍쳐를 설계하는 사람, 섬세한 미술 작품을 만드는 사람, 복잡한 의술을 행하는 의사, 연주할 모든 곡들의 흐름과 선율을 머릿속에서 끊임없이 그려가며 연주에 몰두하는 피아니스트와 같이 장인이라 부를 수 있는 대부분의 사람들 중에서도 롱런하는 사람들의 공통적인 특징은 위의 능숙해질 수 있는 네다섯가지의 영역 거의 모두 다에서 능숙하다는 점이다. 이 점을 절대 간과할 수 없다. 한번 반짝이고 사라진 장인들은 저 영역 중 한두가지가 아주 부족했다. 대인관계에 아주 서툴다던지, 다른 분야의 사람들과 소통이 잘 안된다던지 등이 이런 경우에 속한다. 이 소통에 관련된 부분은 전에 쓴 이 글에서도 다룬 적이 있다.

따라서 이런 생각을 해볼 수 있다. 아직 또래보다 기술적인 것에서 한참 뒤쳐져 있다고 생각이 든다면 내가 다른 이보다 좀 더 능숙한 영역에서의 장점을 적극 활용해보고, 이런 사고를 바탕으로 꾸준히 성장할 수 있는 장기적인 계획을 꾀할 수 있다. 예를 들어, 기술적 능숙함은 부족하지만 대인관계 및 네트워킹에서 능숙하고, 지식에 대한 호기심이 남달라 습득 속도가 빠르다면 기술 커뮤니티, 컨퍼런스 등에 적극 참여해 그 사람들과 교류하며 모르던 것을 배우고 함께 공부하거나 혼자 공부할때 조언을 얻을 수 있다. ‘능숙해지기’에 대해서 이와 같은 관점으로 살펴본다면 남과의 비교와 사회적 압박에서 자유로운, 좀 더 안정적인 마음으로 성장 계획을 세우고 나아갈 수 있다.

이에 관련해 Tai Lopez라는 기업가의 블로그에서 도움이 되는 몇가지 팁을 찾았다.

  • Mentor: 선망하는 누군가를 찾고 직접 연락해보라. 할 수 있다면 그와 교류하고 조언도 구해보라. 배우고자 찾아온 사람을 매정하게 내칠 사람은 많지 않다.
  • Read more: 좋은 책은 여러번 읽는다. 1회독 때는 정독하고 2회독 때는 1회독때 표시해두었던 주요 포인트만 읽으며 속독하고 3회독 때는 본인에게 제일 중요한 몇 부분만 읽는다. 대부분의 책은 일부분만 읽어도 될 정도의 가치를 갖는다. 따라서 엄청난 양의 책을 비교적 적은 시간을 들여 읽는다. 양이 쌓이고 정리가 되어가면 전체적으로 볼 수 있는 능력이 매우 향상될 것이고 그 뒤부터 더 현명하고 가치있는 결정을 내릴 수 있을 것이다.
  • Be humble: 자만, 오만하지 않는다는 것은 인생, 세계, 사물, 사람에 대해 쉽게 판단을 내리지 않는다는 것이고 이는 바꿔말하면 겸손하면서도 호기심이 있는 것이다. 그런 사람만이 오래 학습하고 오래 성장하여 인간 지식의 미개척 영역을 한톨 넓히는 사람이 된다. 내 의견이 아니라 역사가 그렇다. (낮은 자세를 취하는 것은 도덕이 아니라 이쯤 되면 과학인듯)
  • Persevere: Bill Gates도 스무살부터 서른살까지 거의 쉬지 않았다. 그만큼 집중할 것이 뚜렷했다는 것이고 그렇게 할 수 있으려면 인내해야 한다. 될때까지. 나(Lopez)는 내가 선망하는 기업가의 비서를 17번 찾아갔다.
  • Stoic: 정말 재밌는 미래를 꿈꾼다면 그걸 위해 준비하고 조금만 참자. 오늘의 즐거움을 살짝 양보하고 스스로를 단련한다. 뭐 그렇다고 즐거움을 다 버리라는 것은 아니다. 다만 현재를 희생하면서까지 즐겨버리면 그만큼 성장해있을 미래는 없다. 성장에 관심이 없고 이대로만 행복하게 살고싶다면 현재를 마음껏 즐기자.

나를 믿는 것

그리고 나만의 생각을 키워나가는 것.

나만의 생각을 키워나가는 것은 답이 정해진 문제를 해결하는 나만의 방식일 수도 있고, 비구조적 문제를 이해하고 해결하는 나만의 방식일 수도 있고, 남들은 생각하지 못하거나 전통적인 생각의 방식에서 벗어나 비록 그것이 기존의 것과 충돌하더라도 나만의 방식으로 접근하는 것일 수도 있다. 남들이 절대 아니라고 해도 내가 확고하게 믿는 것이 있으려면, 그걸 갖고 강하게 밀고 나갈 수 있으려면 이러한 나만의 생각이 잘 진전되어 있어야 한다.

앞서 프론트 영역에서 개발을 시작해 머신러닝으로 영역을 넓혀간다고 했을때 ‘왜 굳이’라는 반응을 들었다고 소개했다. 만약 내가 그리는 미래가 분명치 않았다면, 내가 한번 주어진 인생에 무얼 하다 갈지, 어떤 사람으로 기억될지 구체적으로 상상해보고 정해놓지 않았다면 나는 분명히 흔들렸을 것이다. 왜? 남들의 기준, 사회의 일반적인 기준에 따르면 내가 가고자 하는 길은 전도유망하지 않기 때문이다. 그들의 관점으로는 머신러닝을 처음 시작했으면 했지 굳이 프론트로 이미 시간을 보낸 뒤 진입하는 것은 그리 큰 메리트가 없었을 것이다. 동의하지 않는 것은 아니다.

나는 다행히 여기서 나를 믿고 나만의 생각을 키워온 것에서 큰 힘과 방향을 얻었다. 어쩌면 이것은 인생을 대하는 나의 태도일지도 모른다. 그리고 나는 이 태도를 얻으려 부지런히 노력했다. 얻기까지 너무 힘들었고 좌절했던 적도 많았다. 그래서 그 얻은 힘과 방향이 무엇인고 하니, 머신러닝은 모델링 및 학습보다 데이터 전처리 및 가공에 더 많은 힘을 쏟아야 하는 성질의 분야이고, 내가 시작한 분야인 프론트 영역에서는 무엇을 데이터로 간주하고, 언제 어떻게 저장하고 가져올지 생각해볼 수 있는 곳이기 때문에 둘 간의 연결지점을 분명히 생각해볼 수 있었다. 자연스레 학습할 분야도 데이터와 관련된 분야로 옮아갔고 나는 미래를 더 분명히 그려볼 수 있는 기회를 갖게 되었다.

몇달전 읽은 Airbnb 스토리라는 책에 이런 내용이 있다. ‘이렇다, 저렇다 식의 남 얘기에 집중하지 마라. 나만의 생각을 키우는 것이 중요하다.’ Warren Buffett이 한 말이다. 그는 출근하고 대부분의 시간을 독서하는데 사용했다고 한다. 분명 사회에는 노이즈가 많다. 듣기 싫은 것도 있고 뭐만 하려고 하면 안된다고 초를 치는, 하등 도움이 안되는 말들도 많다. 그래서 흔들리지 않고 내 길을 올곧게 오래 나아가기 위해서는 남의 이야기에 경청할 줄도 알아야 하지만 반대로 듣지 않아야 할때도 있음을 깨달았다. 둘이 상충하는 것 같지만 자동차의 기어에 D와 R이 공존하는 것과 같은 이치다. 경청과 무시. 둘 중 아무래도 그간 사회가 이야기해온 것에 따르면 경청이 더 좋은 자세 같다. 경청만 해야할 것 같다. 그렇다고 차에 D만 있으면 막다른 길에서 빠져나올 길이 없을 것이다. 앞만 보고 달리는 것만큼 바보같은 것이 또 없다.

뭔가 하고싶은데 남이, 사회가 그걸 두고 별로라고 하는가? 본인이 봐도 별로라고 생각이 들면 안하는게 맞지만, 분명히 좋다고 생각한다면 기쁘게 남을 무시하자. 한국 사회는 지나치게 남에게 관심이 많다. 예의있게 무시하고 오래 성장하고 전진해서 멋지게 살자.

정리하며

이제 막 커리어를 계획하고 다듬어나가는 입장에서 보면 앞날이 까마득하고 배울 것은 왜이리 많은지 답답하기만 하다. 이걸 다 언제하지 라는 조바심도 나고 이렇게 해서 정말 내가 원하는 레벨의 엔지니어가 될 수 있을지도 의심스럽다.

이럴때 상상력을 적극 활용해보자. 영화를 보다보면 온갖 일을 겪고 은퇴해 노년기를 보내며 지난 날을 회상하는 장면이 간혹 나온다. 이런 장면들을 보면서 이런 생각이 들었다. 지금 아무리 치열하고 앞이 안보이고 어쩌고 해도 삶의 끝에 가면 결국 남는 것은 돈도 명예도 아닌 곁에 있는 사랑하는 사람들이다. 그렇지 않은가? 치열하게 살아온 젊은 나날들이 무의미하다는 것이 아니라 중요하고 어려워 보이는 모든 것들도 끝에 가서는 아련함, 시원섭섭함, 아름다움, 그리움으로 남는다는 것이다.

아마 사람들이 꿈을 갖고, 무언가를 만들고, 고군분투하는 모든 것의 존재 이유는 진행하는 당시에는 모르겠지만 그저 그것이 재밌어서일 것이다. 그리고 그것이 아름다워서일 것이다. 편리, 재미, 환경을 위한 모든 일과 사업들. 당시엔 사명감, 욕심 등 여러 이유를 갖고 그것에 따라 생각하고 무언가를 해나가겠지만 끝에가서 남는 것은 추상적 감정들일 것이다. 그러니 지금 하는 것이 어렵고 힘들고 앞이 보이지 않아도 풀어나갈 한가지의 실마리만 있다면 그걸 쥐고 하나씩 알아나가는 과정들을 기꺼이 받아들이고 즐기면 되지 않을까.

이 글을 쓰기까지 도움이 된 책들, 써온 글조각들, 만들어온 것들, 공부한 흔적들

img_4114

img_4134
1만 시간의 재발견: 2018년에 읽은 최고의 책(아직까지는)

img_4136

img_4118
Surely You’re Joking, Mr. Feynman!: 학습에 대해 유쾌하게 풀어내는 파인만의 재밌는 사연들이 감명 깊었다. 리처드 파인만은 정말 사랑스러운 과학자다.
img_4140
이 글의 바탕이 되는 첫 의식의 흐름
img_4054
심적 표상에 대한 정리
img_4141
이글과 연관이 있는 그간 써온 학습에 관련된 글조각들: 이 조각들은 이 글을 구성하는데 쓰였다.
스크린샷 2018-03-11 오후 5.39.34
입사하고 참여한 프로젝트의 결과물(React.js): dcode 앱의 웹 버전인 itsdcode
스크린샷 2018-03-11 오후 5.37.54
ML 분야의 hello world: tensorflow로 mnist 학습시키기

img_4138img_4139img_4137

KakaoTalk_2017-12-31-16-28-51_Photo_6
작년에 들었던 Coursera Stanford Machine Learning Course

KakaoTalk_2017-12-31-13-58-06_Photo_38

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