내가 토이 프로젝트 경험을 공유하는 이유
필자는 친구들과 함께 하고 있는 루비콘이라는 팀에서 토이 프로젝트 멘토링을 재능 기부 형식으로 진행하고 있는데, 많은 분들이 도대체 돈도 안 받으면서 왜 이런 프로젝트를 왜 진행하는지, 얻고자 하는 것이 무엇인지에 대해 많이 물어보셔서 그에 대한 필자의 생각을 적어보려고 한다.
좋은 개발자가 지녀야하는 역량은 프로그래밍 스킬만이 아니다
지난 여러 편의 포스팅에서 이야기했던 것처럼 필자는 좋은 개발자가 되기 위한 조건에는 하드 스킬 외에도 소프트 스킬 역량이 필수적으로 포함된다고 생각한다.
물론 어디까지나 개발자는 프로그래밍을 통해 제품을 만들어내는 직업인 만큼, 어느 정도의 프로그래밍 실력을 기본적으로 갖춰야 하는 것은 변명의 여지가 없는 사실이다. 하지만 중요한 것은 실제로 조직에서 원하는 개발자가 프로그래밍”만” 잘 하는 개발자는 아니라는 의미이다.
초창기 비즈니스나 프리랜스와 같은 상황을 제외하면 대부분의 개발자들은 혼자 일하지 않는다. 아무리 뛰어난 개발자라고 해도 거대한 소프트웨어를 설계하고 만드는 일을 전부 혼자 한다는 것은 굉장히 어려운 일이기 때문이다.
그래서 우리는 거의 대부분의 상황에서 다른 사람들과 협업을 해야하고, 이때 중요하게 부각되는 것이 바로 소프트 스킬이다. 소프트 스킬은 하드 스킬과 다르게 어떤 한 가지 특성을 의미하는 단어가 아니라, 커뮤니케이션, 문제 해결 능력, 리더십, 동기부여와 같이 하드 스킬을 제외한 대부분의 능력을 의미한다.
대표적인 소프트 스킬들의 예[출처] https://www.wikijob.co.uk/content/interview-advice/competencies/soft-skills
아무리 뛰어난 개발자라고 해도 다른 사람과 자주 마찰을 빚어내어 팀의 사기를 저하시키고 원활한 커뮤니케이션을 하지못해 의사결정에 오랜 시간이 걸리거나 잘못된 의사결정을 반복한다면 장기적으로 조직이 성장하는데 별 도움이 되지 않기 때문에 채용 시장에 발을 들여놓은 많은 조직들 또한 소프트 스킬에 집중하고 있다.
그래서 우리는 하드 스킬뿐만 아니라 소프트 스킬을 갈고 닦는 데에도 노력을 쏟아야 하는 것이다.
소프트 스킬은 어떻게 배워야하나요?
하지만 문제는 도대체 소프트 스킬을 어디서 배워야 하냐는 것이다. 하드 스킬은 각 직군의 전문적인 지식이기 때문에 리서치와 공부, 그리고 충분한 연습과 열정이 동반된다면 학교나 학원을 통해 배우거나 심지어 독학을 해서라도 성장하는 것이 가능하지만, 소프트 스킬은 그런 종류의 지식이 아니다.
게다가 소프트 스킬이라는 것은 일을 할 때 필요한 스킬들 중 하드 스킬을 제외한 거의 모든 부분을 의미하는 것이기 때문에, 어떤 한 가지로 설명될 수 있는 것이 아니다.
존 손메즈의 소프트 스킬이라는 책에서는 70개 챕터에 달하는 내용이 담겨있을 정도로 소프트 스킬은 방대하다
대표적인 소프트 스킬인 커뮤니케이션, 리더십, 시간 관리 등을 보면 알 수 있듯이, 소프트 스킬이라는 것은 컴퓨터와 사람이 아닌 사람과 사람 간의 이슈를 해결하거나 자기관리(Self-Management)에 더 가깝기 때문에 직접 부딪혀가면서 시시각각 터지는 예외 상황들을 처리하는 성격이 강하다.
그런 이유로 이런 종류의 소프트 스킬은 학원이나 학교같은 교육 기관에서 특정한 커리큘럼을 정해서 가르치기 어려운 종류의 능력이고 결국은 다양한 경험을 통해 자신만의 방법이나 가치관을 확립해나가면서 습득하는 수 밖에 없다.
최근 대두되고 있는 부트캠프와 같은 교육 기관들은 학원이나 학교처럼 커리큘럼대로 강의를 진행하고 학습하는 것이 아니라 강의와 협업을 병행하며 나름 실무에서 경험할 수 있는 상황들을 미리 튜토리얼처럼 경험할 수 있는 환경을 조성해주고 있기 때문에 하드 스킬 뿐만 아니라 소프트 스킬도 연습할 수 있는 아주 좋은 환경이라고 할 수 있다.
게다가 부트캠프라는 어원에서 알 수 있듯이 부트캠프에 다니는 몇 개월 동안은 거의 밥 먹고 코딩만 한다고 이야기 할 수 있을 정도로 빡세게 굴린다고 한다.
애초에 부트캠프의 어원 자체가 여기다...
그러나 부트캠프에 대해서 조금 알아보신 분들은 알겠지만, 이 교육 과정들은 가격이 그리 싼 편이 아니다.
최근에는 수강생의 부담을 덜기 위해 교육을 수료한 후 취업을 하면 연봉의 일정 퍼센트를 부트캠프와 공유하는 방식을 채택하고 있는 곳도 있는데, 물론 구직자에게 한 번에 몇 백 만원에 달하는 돈을 요구하지는 않기 때문에 경제적인 부담이 덜 하다는 것은 사실이지만, 막상 부트캠프에 납부해야하는 총 금액을 계산해보면 적은 돈은 아니다. (납부 금액이 최대 2,000만원인 곳도 있다)
물론 전문적인 기술을 배우는 학원들의 가격이 보통 비싼 편이기도 하고 부트캠프의 강사 섭외 비용이나 사무실 입주 비용 등 각종 운영 비용들을 고려하여 산출된 가격이겠지만, 그렇다고 우리같은 개미들이 쉽게 낼 수 있는 금액이 아니라는 점은 변하지 않는다.
그렇다면 우리가 소프트 스킬을 배우기 위해서는 어쩔 수 없이 저런 큰 비용을 지불할 수 밖에 없는 것일까?
사람들과 토이 프로젝트를 해보자
결국 부트캠프가 학원이나 학교에 비해 가지는 강점은 강사 > 학생으로 단방향으로 흐르는 지식의 전달이 아니라 학생과 학생 간의 커뮤니케이션과 협업을 통해 하드 스킬과 소프트 스킬을 동시에 연습할 수 있는 환경이다.
이런 환경 속에서 나와 상황이 비슷한 사람과 협업을 하면서 서로 자극도 받을 수 있고, 소프트 스킬에 대한 경험도 쌓을 수 있는 것이다. 그렇다면 이런 생각도 한번 해볼 수 있다.
스스로 이런 환경만 구축할 수 있다면 굳이 몇 백만원에 달하는 거금을 내지 않아도 성장할 수 있지 않을까?
사실 부트캠프와 비슷한 환경을 구축하는 방법은 그렇게 멀리 있지 않다. 바로 마음이 맞는 동료들을 만나서 재미있는 토이 프로젝트를 함께 하는 것이다.
물론 프로그래밍이나 디자인 스킬같은 하드 스킬이 부족하다면 처음에는 조금 어렵고 힘들긴 하겠지만, 프로젝트에 참여한 팀원들의 실력이 비슷비슷하다면 서로 공부하면서 함께 제품을 만들어나가는 과정은 팀원 모두에게 반드시 소중한 경험이 될 것이다.
필자도 프로그래밍에 대해서 거의 아무것도 모르던 대학생 시절, 구글에만 의지하면서 프론트엔드 프로그래밍을 독학했었다. 물론 당시 친구들과 함께 만든 루비콘이라는 팀의 첫 번째 프로젝트는 물론 엉망진창이었고 개발 기간도 엄청 길었지만, 그래도 엎치락 뒤치락하며 결국 어떻게든 릴리즈를 해냈고, 그 경험은 현재 필자가 개발자로써 살아가기 위한 가치관이 형성되는데 상당히 큰 영향을 주었다.
처음 팀이 생긴 지 6년이 지난 지금도 필자는 친구들과 함께 새로운 도전을 하고 있다
당시 루비콘 멤버들은 대부분 프로덕트를 만들어본 경험이 없었기 때문에 작업 스코프를 너무 크게 잡아서 일이 진행이 안되거나, 사소한 의견 다툼으로 싸우기도 하는 등 굉장히 많은 문제들이 발생했었다.
하지만 분명한 건 그때 그렇게 티격태격하며 문제를 해결하고 프로젝트를 진행했던 경험이 필자가 현재 개발자로써 살아가며 경험하는 문제들을 해결하는데에도 많은 도움이 되었다는 것이다.
토이 프로젝트는 일종의 테스트 환경이다
사실 토이 프로젝트에서 발생하는 문제들의 대부분은 직장에서 일을 할 때도 비슷하게 나타난다. 그러나 직장과는 다르게 토이 프로젝트는 이런 문제를 해결하지 못했을 때의 리스크가 적은 편이고, 직장보다는 사적인 인간 관계로 얽혀있기 때문에 조금 더 편하게 문제 해결에 집중할 수 있다. (경제적인 타격이 없거나 적은 것만 해도 개이득이다)
직장에서 어떤 문제에 대한 의사결정을 할 때는 팀 내부, 외부의 수많은 이해관계자(Stackholder)들, 비즈니스, 법 등 여러가지 상황을 함께 고려해야하기 때문에 어쩔 수 없이 제한된 의사결정을 할 수 밖에 없지만, 토이 프로젝트에서는 그딴 거 없다.
어차피 토이 프로젝트는 완전 처음부터 제품을 만들어나가는 과정이니까 초기에는 제품을 사용하는 유저도 없을 것이고, 이걸로 큰 돈을 벌 것도 아니기 때문에 조금 더 과감한 의사결정을 해볼 수 있다.
그리고 대부분의 경우 프론트엔드, 백엔드, 디자인과 같은 롤을 각각 한 명씩 맡아서 하는 경우가 많기 때문에, 새로운 기술을 도입하기 전에 팀원들의 동의를 얻어야하는 직장에 비하면 기술적인 도전을 해보기에도 자유로운 환경이다.
즉, 토이 프로젝트는 직장에서 팀으로 일할 때처럼 실제로 협업을 하는 환경이면서, 동시에 프로젝트를 진행하는 개개인에게는 도전적인 의사결정과 기술을 시험해볼 수 있는 환경이라고 할 수 있다. 일종의 테스트 환경인 것이다.
프로덕션 환경에서 예상치 못하게 발생할 위험 요소를 테스트 환경에서 컨트롤하는 것처럼직장에 어떤 방법론을 적용하기 전에 토이 프로젝트에서 테스트해보자
이렇게 프로젝트를 진행하며 사용해보았던 신기술에 대해서 충분한 경험이 쌓였고 이 정도면 쓸만한 도구라는 판단이 들었다면, 그 경험을 토대로 여러분이 일하고 있는 직장에 해당 기술을 도입해보자는 의견을 제시할 수도 있다.
하지만 결코 쉽지 않다
그러나 아무리 간단한 제품을 만드는 일이라 해도 막상 실제로 해보면 그렇게 간단하지는 않다는 사실을 체감할 수 있다. 소프트 스킬을 배우기 위해 토이 프로젝트를 선택했지만, 정작 프로젝트를 진행하다보면 구성원들의 소프트 스킬의 부족으로 인해 문제가 발생하는 경우가 많기 때문이다.
많은 사람들이 토이 프로젝트를 시작하기 전에 걱정하는 부분이 자신의 하드 스킬 부족인데, 사실 하드 스킬이 부족하더라도 어찌어찌 공부를 하며 제품을 만들어낼 수는 있기 때문에 하드 스킬 부족은 의외로 프로젝트의 진행에 큰 문제가 되지 않는다.
물론 다른 팀원들에 비해 자신의 하드 스킬이 크게 떨어져서 프로젝트의 진행이 어려운 상태라면, 피나는 노력을 해서라도 그들을 따라가야하는 건 당연하지만, 적어도 스스로 노력해서 실력을 키울 수는 있으니 큰 제한 사항은 아니다.
그러나 소프트 스킬이 부족한 경우에는 조금 다르다. 앞서 이야기했듯이 소프트 스킬은 경험을 통해 습득하는 성향이 강한 만큼 소프트 스킬을 익히는 과정은 어느 정도의 시행착오와 실패가 필수적으로 동반된다.
문제는 소프트 스킬이 시행착오와 실패를 통해 배운다는 그 자체가 아니라 이 과정 속에서 모임 자체가 흐지부지하게 끝날 가능성이 높다는 것이다.
게다가 토이 프로젝트는 직장처럼 일을 하면서 뭔가 대가를 받는 것도 아니기 때문에 사실 상 프로젝트에 참여하는 구성원들에게는 어떠한 책임도 없는, 구성원들에게 내제된 모티베이션에 100% 의지하고 있다는 특성도 있다.
이제는 일종의 밈이 되어버린 대학교 조별과제 썰들에서 주로 등장하는 “일 잘하는 사람에게 일 몰아주기”, “미팅에 무단불참하기”, “자기가 맡은 일을 제대로 못 끝내기”와 같은 것들은 당연히 토이 프로젝트에서도 그대로 등장할 뿐더러, 심지어 조별과제에서는 학점 때문에 하지 못하는 행동인 팀을 나가는 사건까지도 발생한다.
슬프지만 한 번쯤은 다들 공감할 수 있는 조별과제 짤...
이런 문제들은 프로젝트 진행에 상당한 타격을 줄 수 있는 것들이지만, 사람들이 대학교 조별과제 썰을 보면서 서로 공감하는 것만 봐도 알 수 있듯이 그렇게 드문 일은 아니다.
이때 모임을 건강하게 유지하기 위해서는 이런 문제를 해결하기 위한 구성원들의 적극적인 노력과 개선이 뒷받침되어야하는데, 팀에 대한 애착이나 모티베이션, 참여율 등이 멤버들마다 각각 다르기 때문에 특정한 누군가가 부담을 떠안는 경우도 발생한다.
여러 번 이야기하지만 이런 경험은 굉장히 흔하게 발생하기 때문에 대부분의 사람들은 이런 경험을 몇 번하고는 “스터디가 원래 다 그렇지 뭐”라는 슬픈 결론을 내려버린다.
이렇게 소프트 스킬의 부족으로 발생하는 문제들은 팀원들의 성향이나 팀의 현재 상황 등에 따라 해결방법이 천차만별일 수 있기 때문에 비슷한 문제를 해결해본 경험이 없다면 헤쳐나가기가 쉽지 않은 것들이다.
우리가 이런 부분을 도와줄 수 있지 않을까?
처음 개발자로 취업했을 때까지만 해도 필자는 같은 팀에서 오랜 기간동안 동고동락하며 함께 공부하고 프로덕트를 만들어보는 경험이 그렇게 특별한 것인지 잘 못 느끼고 있었다.
그러나 조금씩 시간이 지나고 사람들을 만나보며 토이 프로젝트나 스터디에 대한 이야기를 들어보기도 하고, 또 직접 참여해보기도 하다보니 사실 이런 팀을 만나는 것 자체가 어떻게 보면 운이 좋았던 것이라는 생각을 하게 되었다.
그리고 다들 필자가 친구들과 함께 이런 팀 활동을 꾸준히 하고 있다는 사실을 부럽다고 하시는 것을 보면 뭔가 이런 경험을 겪어보고 싶다는 니즈 또한 확실히 있어보였다.
하지만 앞서 이야기했듯이 많은 사람들이 스터디나 조별과제와 같은 경험을 통해 이런 커뮤니티를 꾸준히 운영해나가는 것 자체가 어렵다는 것을 알고 있기 때문에 선뜻 도전하는 것도 쉽지 않다.
이런 사실을 알고 있기 때문에 필자가 속해있는 루비콘 팀에서는 우리가 지난 6년 간 팀 활동을 하며 겪었던 각종 문제들을 해결해나갔던 경험을 다른 사람들과 공유해보는 것을 어떨까하는 공감대가 형성이 된 것이다.
루비콘 팀 또한 처음부터 지금처럼 성숙한 커뮤니티였던 것은 아니다. 각각의 멤버가 가치관이나 일하는 스타일이 다르기 때문에 어떤 문제를 해결하는 방법을 놓고 몇 시간 동안 싸우기도 했고, 잘못된 MVP(Minimum Viable Product) 설정으로 인해 개발 기간이 너무 늘어져서 모두 열정을 잃었던 적도 있었으며, 심지어 특정 한 사람에게 업무가 확 몰리거나 멤버가 나가는 등 다른 커뮤니티에서 발생하는 모든 문제가 루비콘 내에서도 발생했고, 또 지금도 발생하고 있다.
하지만 6년 정도의 시간 동안 이런 다양한 문제를 겪으면서 함께 이런 문제를 해결하는 방법을 조금씩 배워나갔기 때문에 우리가 경험했던 이렇게 문제를 해결했던 경험을 다른 사람들과도 함께 공유하고 싶은 것이다.
그래서 지금 필자가 진행하고 있는 멘토링 프로젝트는 개발이나 디자인에 관련된 멘토링이 아니라 오롯이 커뮤니케이션이나 협업 방법론, 심지어는 개인의 시간 관리와 같은 소프트 스킬에 집중하고 있다.
물론 필자가 누굴 가르칠 만큼 대단한 사람은 아니지만, 이 블로그를 운영하면서도 스스로 별 것 아니라고 생각했던 지식이나 경험들이 다른 이들에게 큰 도움으로 다가올 수 있다는 경험을 했었기 때문에 필자는 이 멘토링 자체가 가지는 의미가 크다고 생각한다.
마치며
필자는 지난 대학생 때부터 6년 동안 루비콘이라는 팀 안에서 좋은 친구들과 함께 성장할 수 있는 운 좋은 기회를 얻었다. 주말마다 부담없이 함께 작업하자고 이야기할 수도 있고, 모아놓은 회비를 사용해서 새로운 기술을 사용해보고 싶다고 할 때도 흔쾌히 오케이해주는 팀이 있기에 필자는 지금도 매일 이 사람들과 함께 가슴 설레는 도전을 할 수 있다.
비록 지금은 꼴랑 4~5명의 멘토가 투입되어서 한번에 20명 정도의 인원에게만 경험을 전파할 수 있는 열악한 환경이지만, 멘토링 프로젝트를 거치며 좋은 경험을 얻었던 사람들이 또 다른 사람들에게 그 경험을 전파하다보면 언젠가는 더 많은 사람들이 필자와 같은 경험을 할 수도 있지 않을까하는 행복한 상상을 해본다. (이렇게 쓰고 보니 왠지 다단계같다…)
이상으로 내가 토이 프로젝트 경험을 공유하는 이유 포스팅을 마친다.
