지난 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

옷, 개인 그리고 패션테크 스타트업

얼마전 김정운 작가의 Editology를 읽었을때 책에 이런 구절이 있었다.

공간의 형태에 따라 생각하는 방식도 달라진다.

facebook new building에 대한 이미지 검색결과

그래서 위 사진과 같이 Facebook도 자신들의 미션에 따라 새로운 공간에서 일하기 시작했는데 사방이 탁 트이고 천장도 매우 높은 공간이다. 그럼 그들의 미션이 뭐길래 탁 트인 공간에서 일하기를 원했을까? 이미 Zuckerberg가 Y Combinator에서 언급해 많이 유명해진 그들의 미션은 사람들을 더 연결시키는 것이다. 이런 미션에 따라 일하는 것이 업무 공간과 어떤 연관성을 갖는지 생각하기 전에 먼저 이 미션에 따라 일한다면 사람들이 어떤 방식으로 생각하게 될지에 대해 알아보는 것이 좋겠다. 그래서 아래와 같은 질문들을 떠올려봤다.

  • 전세계의 사람들을 연결시키고자 하는 이들은 일을 할때 생각이 어떻게 흐를까?
  • 한 국가에 한정된 서비스를 만드는 사람들의 사고 흐름과 비슷할까?
  • Facebook의 엔지니어들은 엔지니어링 부서 이외에 어떤 팀들과 소통을 얼마나 자주하고 어떤 과정으로 기능에 대한 아이디어를 얻어 설계하고 만들까?
  • 그럼 마케팅팀 직원들은?
  • 디자인팀 직원들은?
  • CEO와 경영진은?
  • 이 몇만명의 직원들이 어떻게 미션과 가치를 서로 공유하고 그에 따라 태스크를 구상할까?

질문을 하면서 답변이 동시에 저절로 나오는 걸 느꼈다. 국가, 종교, 문화, 기후, 언어, 인종 그리고 가치관이 서로 다른 사람들을 연결 시키려면 그에 걸맞는 서비스가 필요할 것이고 그 서비스를 이루기 위한 기능과 디자인이 필요할 것이다. 누구를 대상으로 어떤 서비스를 하느냐는 그 회사의 정체성을 나타낼 것이고 그에 따라 팀들 간의 유기적 협업 방식도 달라질 것이다. 즉, 일의 목적에 따라 그에 적합한 업무 방식이 필요하게 될텐데 그 방식이 회사 곳곳에 잘 정착되기 위한 문화나 공간이 필요하지 않을까? 이런 서비스를 하는 회사의 업무 공간이 팀별로 지나치게 구분되어 있거나 넓은 회의실이 몇 군데 없고 건물 곳곳에 배치되어 있지 않으면 팀들이 서로 협업하기 어렵지 않을까?

위에서 든 예는 업무 형태에 따라 적합한 공간 형태를 생각하는 순서였지만 반대로도 설명이 가능하다. 자연을 벗삼아 사는 사람과 건물이 빽빽하게 들어선 도시에 사는 사람의 사고 방식과 흐름이 전혀 다른 것처럼 업무 공간의 형태에 따라 같은 일을 하더라도 사고의 방식과 흐름에서 차이가 생길 것이다. 물론 업무에 적합한 공간에서 일하지 못한다고 해서 생산성이 급격하게 낮아지거나 하는 것은 아닐 것이다. 어디까지나 공간까지 생각하는 것은 생산성을 최대한 끌어올리고 자신들의 미션과 문화에 맞는, 직원들을 한껏 고무시킬 수 있는 환경을 만드는데 목적이 있기 때문이다. 98%에서 99%로 나가기 위함일 것이기 때문이다.

 


 

서론이 참 길었는데 패션테크 스타트업에서 일하면서 옷도 이와 비슷하다고 생각하게 됐다. 내가 좋아하는 옷을 입은 날은 집을 나설때부터 다르다. 아침에 하는 생각의 내용도 조금 달라진다. 오늘 있을 일을 생각하고 누굴 만나 어떤 이야기를 나눌지까지 생각이 이어진다. 뭘 입을지 생각이 안나 대충 입은 날은 종일 찝찝하다. 옷에도 생각이 반영되지만 어떤 옷을 입느냐도 생각에 영향을 미친다.

옷은 생각과 행동에 영향을 미친다.

심지어 옷을 구경하면서 이건 어떨까, 저건 어떨까 생각해보고 입다보면 내가 몰랐던 나의 모습을 알게 될 때가 있다. 전에는 한번도 생각해보지 못했던 디자인이나 스타일의 옷을 입어보면 되게 어색하지만 ‘어 뭐지 이런 모습도 있었나?’ 하고 생각하게 된다. 직장인이 되고나서 이런 경험을 서너번 했다. 이쯤 되니 사실 패션은 자기이해를 필요로 하는 자기표현인 거구나! 하고 깨닫게 되었다.

패션은 자신을 찾아가는 길이다.

그래서 패션테크 스타트업에서 일하는 사람으로서 패션을 자기이해의 수단으로 보는 관점이 사회에 얼마나 만연한가가 패션 사업성에 어떻게 영향을 미칠지 그 관계성에 대해서 다뤄보고 싶어졌다.

Fashion – 너에 대해 얼마나 알고 있니?

나는 나에 대해서 얼마나 이해하고 있을까? 정확히 말할 수 있다. 나는 아직도 나를 잘 모른다. 아직 찾지 못한 부분이 많다. 물론, 아는 범위 안에서는 누구보다 나를 더 잘 안다. 하지만 모르는 부분이 있는 것은 사실이고 인생은 어쩌면 자기를 찾고 이해하는 자아성찰의 여행일지 모른다. 마틴 하이데거도 죽기 전까지 자신에 대해서 완전히 이해하지 못했을 것이다.

The Sartorialist – 사진으로 가득 채워진 이 책은 패션에 대해 그리고 패션이라는 창으로 새로운 나를 보게 해주었다.

 

아마존 베스트셀러 중에 The Sartorialist라는 책이 있다. www.thesartorialist.com 라는 사이트의 도서 버전이다. 이 책은 텍스트가 반도 안된다. 전체가 인물사진이고 모두들 완전히 다른 옷을 입고 있다. 한명 한명 사진을 보면서 ‘내가 저 옷을 입고 있다면 어떤 기분일까’ 라며 계속 나를 대입시켜 보았다. 찌릿찌릿 했다. 어떨때는 부끄럽기도 했고 어떨때는 기분이 좋아지기도 했다. 단순히 멋진 옷을 자기만의 스타일로 입은 사람의 사진을 보았을 뿐인데 나는 거기서 오히려 나에 대해서 알게 되었고, 심지어는 가까운 미래에 어떤 커리어를 쌓으면서 어떤 옷을 입고 일을 하고 싶은지, 어떤 옷을 입고 회의에 참석하고, 연단에 올라 발표하고 싶은지를 생각해보게 되었다. 물론 지금은 너덜하게 막 입고 다닌다..

sartorialist에 대한 이미지 검색결과 sartorialist에 대한 이미지 검색결과sartorialist에 대한 이미지 검색결과sartorialist에 대한 이미지 검색결과

관련 이미지

사토리얼리스트에 있는 사진들이다. 요새 너무 formal하지 않은 정장에 관심이 많아서 이런 사진들을 가져왔다. 아.. 저 일본 아저씨들 너무 멋있다. 이 사진들을 보고 어떤 생각이 드는가? 그냥 저런 옷을 입은 외국인에 불과한가? 아니면 ‘내가 저 옷을 입고 출근을 하면 어떤 기분일까’ 라며 자신을 대입시켜 보고 상상해보았는가?

나는 단순히 옷을 입은 사람을 본 것이 아니었다. 패션 도서를 읽은 것이 아니었다. 나는 패션이라는 도구를 접함으로써 자기이해의 과정을 걷고 있었던 것이다. 몇년전의 내가 이 문장을, 이런 생각을 보고 엿듣게 된다면 코웃음을 쳤을 것 같다. 그런데 한번 관심을 갖게 되니 안보이던 것들이 보이기 시작하고 이 분야의 사람들이 이해되기 시작했다. 그리고 나도 모르던 나의 모습과 내가 어떤 모습이길 바라는가에 대해서도 서서히 알아가기 시작했다. 책을 읽고 여행을 떠나 모르던 곳을 탐방하고 새로운 모임에 나가 새로운 사람들을 만나 이야기하는 것만이 자기성찰의 방법이 아니었던 것이다. 나를 알아가는 새로운 루트를 찾은 것이었다. 옷을 통해서 나와 주변 그리고 우리를 감싼 문화 전반에 대해서 새로운 관점으로 이해하기 시작한 것이다. 문화에 따라, 오늘의 느낌에 따라, 충동에 따라, 만날 사람에 따라, 나갈 모임에 따라, 생각에 따라 옷을 골라 갖춰 입는 것은 그저 옷을 집어 걸치는 행위가 아닌, 충분한 자기이해를 바탕으로 한 자기표현의 행위인 것이다.

혹자는 이렇게 생각할 수도 있겠다. ‘나는 옷을 잘 입는데 그렇게까지 나에 대해 이해하면서 옷을 입지는 않는데?’ 어디까지나 자기이해는 메타인지의 영역이다. 옷을 잘 입는다고 꼭 자기이해가 수반 되었다고는 할 수 없다. 그러나 옷을 잘 입고 싶은 그 이유를 내 안에서 찾기 시작하면 그때부터 자기이해가 시작된다. 나 자신이 어떻게 생각하고, 어떻게 느끼고 반응하는지에 대해 알아가기 때문이다. 그렇다고 옷을 잘 입지 못한다고해서  자기이해가 덜 된 것도 아니다. 앞서 이야기했듯 패션은 자기이해와 자기표현에 이르는 하나의 길이기 때문이다. 내가 과도가 없다고 사과를 못깎아 먹는 것은 아닌 것처럼 말이다. 과도 없어서 못깎아 먹으면 인생에 대해서 한번 되돌아 볼 필요가 있다…

그리고 사업성

생각이 여기까지 이르고 나니, 패션테크 스타트업에서 일하는 사람으로서 사업성을 생각하지 않을 수 없었다. 지금까지 살펴본 바로는 패션은 개인의 취향과 생각, 가치관에만 그 영향이 국한되어 있지 않다. 사회와 문화에도 관련이 있고 둘은 서로 끊임없이 영향을 주고 받는다. 개인이 사회에서 갖는 역할을 중요시하는 문화에서는(성숙한 문화에서는) 많은 사람들이 다양한 활동을 하며 계속 자신을 이해하는 과정을 반복한다. 선진국에 작가와 블로그 문화(like WordPress and Medium)가 잘 발달되어 있는 것도 같은 맥락으로 볼 수 있다. 자신이 경험한 것과 알게된 것에 대해서 서로 공유한다. 도대체 이게 패션의 사업성과 무슨 연관성이 있단 말인가?

이 부분이 아주 중요하다. 옷은, 패션은 그냥 옷 걸치는 것이 아니다. 개인 문화가 성숙한 사회에서는 개개인이 스스로의 인생에 대한 관심과 애정이 높고 자신의 취향 또한 분명(확고)해질 수 밖에 없다. 자신이 뭘 원하고 앞으로 어떻게 살고 싶은지 이해하고 있는 개인들이 매우 다양하게 그리고 많이 존재한다는 의미다. 이것이 옷으로 옮겨가면 앞서 이야기했던 다양한 상황 속에서 자신이 어떻게 보여지고 싶은지 즉, 어떤 옷을 입어 자신을 나타내고 싶은지로 연결된다. 당연히 이런 곳에서, 이런 개인이 많은 곳에서 다양한 옷이 더 자주, 더 많이 팔리지 않을까? 옷에 정말 개미 코딱지 만큼도 관심없는 사람을 붙잡고 옷이 이래요, 추천이 어째요, 감성이 오져요라며 백날 설명하고 광고해도 통하지 않을 것이다. 특히 그런 개인이 많은 지역 혹은 국가일 수록 더 그럴 것이다. 물론, 아직은 옷에 관심이 없지만 이제 천천히 알아가고자 하는 사람이 있을 수 있듯 경우의 수는 매우 다양할 것이다. 하지만 분명한 것은 그 여러 카테고리에 속한 사람의 수는 많지 않을 것이다. 중요한 것은 어떤 카테고리들이 주류를 이루는가에 대해 알아내는 것이지 않을까?

이미지 검색결과
The Millennials – X 세대의 뒤를 잇는 밀레니얼 세대

 

airbnb에 대한 이미지 검색결과

 

 

 

Airbnb는 사업이 궤도에 오른 후 시인했다. 자신들이 성공할 수 있었던 가장 큰 이유 중 하나는 밀레니얼 세대였다고. 밀레니얼 세대는 디지털에 익숙하고 자금이 그리 넉넉치 않지만 여행을 떠나기 좋아하며 새로운 인연을 만들어 나가는데에 거리낌이 없는 세대다. 앞서 설명한 내용에 비추어보면 이 세대는 자기이해의 여정을 달가워하고 즐기는 세대인 것이다. 초창기의 Airbnb는, 현재도 그러하지만, 이 세대가 견인했다고 해도 과언이 아니다. 남의 집에 모르는 사람을 들여 숙박하게 한다? 새로움과 창의성이 샘솟는 실리콘 밸리에서도 Airbnb의 이런 아이디어는 철저히 무시당했다. 그러나 그들의 사업과 아이디어는 돈이 궁핍하지만 전세계로 여행하길 원하는 밀레니얼 세대에 의해 처음으로 환영받았고 지지 받았다. 그렇게 사업이 성장하기 시작했고 안정화 되어갔다. Airbnb가 이후 어떤 고난과 역경을 딛고 지금에 이르렀는지는 The Airbnb Story라는 책이 아주 잘 설명해 놓았다.

다시 패션으로 돌아와, 이 Airbnb의 이야기를 패션에 적용해보면, 현재 우리가 시장으로 삼고 있는 사회에 속한 사람들이 어떤 사람들인지를 알아보는 것이 필요해진다. 물론 Airbnb는 사업을 시작할때 밀레니얼 세대는 생각조차 안했지만 말이다. 적어도 서비스를 제공할 대상에 대해 알아본다면 사업을 진행하고 전략을 수립하는데 큰 도움이 되지 않을까? 우리가 만들 서비스를 쓸 사람들에 대해 알아보기 위한 질문들을 아래와 같이 생각해보았다.

  • 이들은 어떤 사람일까?
  • 자신에 대해 알기를 꺼려하지는 않을까? 그럴 준비는 되었을까?
  • 아직 그 정도로 문화가 성숙하지는 못하지 않았을까?
  • 2, 3, 4, 50대 각각은 어떤 생활 양식으로 대변될 수 있을까?
  • 지금 그들의 상황은 어떠한가?
  • 앞으로 더 잘 벌 수 있으리라는 분위기가 사회에 만연한가?
  • 이들은 미래를 낙관하는가? 아니면 반대인가? 그에 대한 이유는?
  • 이들은 여행하기를 좋아하는가?
  • 이들이 명품에 대해 또는 어떤 브랜드에 대해 어떤 인상을 갖고 있을까?
  • 또 그 인상의 강도는 강한가? 혹은 약한가?
  • 강하다면 어느 방향으로 강하고, 그 방향이 우리가 알리려는 방향과 다르다면 어떻게 이해시킬 수 있을까?
  • 이해시키는데에는 얼마만큼의 시간이 걸릴까? 그 시간을 우리가 견뎌낼 수 있을까?
  • 거부감이 들지 않도록 바꾸고 이해시키려면 어떤 마케팅과 홍보 전략을 어떤 스텝으로 수립하고 실행해야 할까?

타겟을 이해하고 좁혀 사업을 진행하는 것은 중요할 것이다. 그런데 그 타겟이 속한 사회와 이를 대변하는 개인을 이해하지 못한다면, 위와 같은 질문들에 대한 대답이 선행되지 않는다면 뭘 어떻게 좁힐지 정하는 것이 어렵지 않을까? 적어도, 위와 같은 질문 및 이해가 뒷받침 된다면 좀 더 수월하게 사업을 진행하고 여러 전략들도 시장에 대한 이해를 바탕으로 수립할 수 있지 않을까라는 생각이 든다. 이 이해를 바탕으로 또 다시 아래와 같은 질문을 해볼 수 있다.

  • 우리가 제공하려는 패션 서비스의 가치가 무엇인가?
  • 그 가치가 소비자 주류에게 얼마나 다가갈까?
  • 다가가지 못하고 있다면 그 이유가 성숙한 개인 문화의 부재 때문은 아닐까?
  • 다른 이유가 있다면 개별적인 영향은 얼마나 될까?
  • 현재 소비자 카테고리는 어떻게 나눌 수 있을까?
  • 각각에 대한 상황은?

지금까지 패션이 개인의 자기이해와 어떤 관련이 있는지 그리고 그 관련성이 패션 서비스를 만드는 관점에서 어떻게 사업성에 영향을 미칠 수 있는지 살펴보았다.

자기이해의 관점에서만 보면 우리는 음악을 들으면서, 옷을 사고 입으면서, 여행을 하며 새로운 곳에 가보면서, 새로운 분야를 공부하면서, 새로운 사람을 만나면서, 새로운 언어로 소통하면서 끝없이 자기이해의 과정을 걷는다. 나는 이 각각이 서로 분리되어 있다고 믿지 않는다. 아직은 보수적인 사회 분위기에 의해 이 연결고리들이 군데군데 끊어져있다. 남자가 화장을 하네, 여자가 저런 옷을 입네, 저 사람은 저런데를 가네.. 등 온갖 편견들이 도사리고 있다. 이 편견들이 자취를 감출때, 모든 개인이 각자의 성향과 하고자 하는 일에 대해 존중을 받을때 개인들의 활동은 더욱 다양해지고 풍성해질 것이라 믿는다. 그리고 그렇게 되었을때 옷에 대한 사람들의 관심 또한 훨씬 더 다양하고 많이 생길 것이라 생각한다. 그때 우리 서비스는 사람들이 자신을 찾아가는 여정을 돕는 건강한 서비스로서 더 큰 성장을 할 수 있을거라 믿는다.