학교 내 튜터링 중 프로젝트 경험이 없는 사람을 위해 작성한 글입니다. 저의 개인적인 경험에 기반한 글입니다. 이런 글을 작성하지만 스스로 아는 것이 없고 부족하다고 생각하기에 비판할 지점이 있다면 댓글로 달아주세요.
프로젝트를 함께할 팀원을 구할 때의 조언
- 진실되게 스스로를 평가하라
- 프로젝트를 진행하는 팀원은 나와 프로젝트에 들이는 우선순위 레벨이 비슷해야한다
- 나의 목적과 집단의 목적이 일치하는 집단에 들어가라
원칙 1: 진실되게 스스로를 평가하라
공부의 시작은 내가 무엇을 모르고, 무엇을 알며, 무엇을 할 수 있고, 무엇을 할 수 없는지 명확히 이해하는 것에부터 시작한다. 이 개념은 교육학에서 메타인지라고 한다. 인지에 대한 인지를 말하며, 이 능력을 통해 꾸준히 자신의 학습(배우고 연습하는)을 성찰해야만한다.
이 부분에서 최대한 진실되게 자신의 능력을 평가해야한다. 거짓없이 이 System, CS 전공자들 사이에서의 상대적인 위치를 파악하고, 부족한 지식이 무엇인지 파악하고, 가장 근본이 되는 기술부터 차근차근 쌓아나가야한다.
남에게 잘 보여주기 위해 이해도 하지 못하는 기술을 쓰고, 이해도 하지 못하는 이력은 평가의 시점에서 낱낱들이 해체된다.
원칙 2: 프로젝트를 진행하는 팀원은 나와 프로젝트에 들이는 우선순위 레벨이 비슷해야한다
해당 집단에 들어간 이후에는 팀원을 찾아야한다. 이 때 이 기준은 실력도 어느정도 중요하지만(모두가 처음하는 인원이라면 프로젝트만 십중팔구 망할 것이다), '이끌어나갈 사람이 있는가?', 그리고 '팀원 모두가 우선순위 레벨이 비슷한가?' 이 두 가지를 중점으로 두어야한다. 사이드 프로젝트, 토이 프로젝트는 수익을 추구하는 것이 아니자만, 매우 많은 노동 시간(1주일에 10시간 투여하여, 2달 간 개발하면, 80시간, 그걸 4명이 하면 320시간이다)이 투여되고, 반드시 지치는 사람이 있다. 따라서 누군가는 전체 프로젝트를 이끌어야한다. 이 사람은 비교적 경험이 많아야하고, 다른 팀원을 조율할 수 있어야한다. 그리고 이탈자가 없어야하는데, 보통 처음 개발을 시작하면 열정이 앞서, 여러 프로젝트에 참여하거나, 여러 동아리 활동을 동시적으로 참여하는 경우가 많다. 이런 사람을 주의하라. 소프트웨어 프로젝트 특성 상 수준급의 PM이 아니라면, 전체 개발 소요 기간을 제대로 추정할 수 있는 사람은 매우 드물다. 그러므로 프로젝트는 2개월, 3개월내의 배포를 계획하겠지만, 1년 가까이 소모될 가능성이 훨씬 높다. 따라서 이 프로젝트에 진심으로 시간과 열정을 쏟을 수 있는 누군가를 만나야한다.
원칙 3: 나의 목적과 집단의 목적이 일치하는 집단에 들어가라
자신의 능력을 평가한 뒤에는, 적절한 조직 혹은 집단에 들어가는 것을 추천한다. 동아리, 소모임, 부트캠프, 연구실 ,회사 등 개발을 하겠다고 모인 많은 사람들이 있을 것이다. 동아리만 해도 각자 지향하는 바가 다르다. 프로젝트 위주, 지식 공유, 네트워킹, 프로젝트만 하더라도 beginner를 위한 프로젝트 동아리, intermediate를 위한 프로젝트 동아리, 현직자들의 사이드 프로젝트 동아리 등등 수없이 다양하다. 주로 교내에서는 초급자, 중급자 정도의 프로젝트 동아리가 많은 것 같다. 각자의 목적에 맞춰 집단에 들어가되, 배울 것이 많은 사람들의 집단에 들어가야하고, 사람들과 많은 이야기를 하며 지식을 공유해야한다.
비교적 낮은 위치에서 배움을 받기를 원하는 입장이기 때문에 이 집단, 혹은 한 개인에게 무엇을 제공할 수 있을지 끊임없이 고민해야한다. 우리는 나보다 지식 혹은 경험이 많은 이의 시간을 사는 것이다. 제공하는 것이 없다면, 상대방도 금방 떠나갈 것이다. 그 제공하는 것이 반드시 물질적인 것일 필요는 없다. 열정이 담긴 질문, 고민, 감사한 태도, 진실된 태도가 오히려 물질적인 무언가보다 더 가치있을 때가 많다. 항상 고마운 이에게 무엇을 제공할 수 있는지 고민해야한다. 그렇게 내가 차근차근 실력을 쌓아나간 후에는 다시, 더 큰 조직, 더 고도화된 조직으로 나아가야하고 다시 그곳에서 모르는 사람이 되어 배워야한다. 가끔은 내가 머물렀던 조직에 무언가 기여하고, 이끌어 나가는 경험도 좋은 것 같다.
프로젝트를 시작하는 것에 대한 조언
- 첫 프로젝트는 대부분 흐지부지 끝나거나, 운용이 되는 경우가 많지 않다. 그럼에도 불구하고 아이디어를 수립하고 계획을 세우고 나아가야한다
- 내가 사지도 않을 제품을 만들지 마라
- 모든 것을 알고서 프로젝트를 시작할 수는 없다. 일단 시작하라. 다만 내가 무엇을 하고 있는지 명확히 이해해야한다
원칙 4 : 첫 프로젝트는 대부분 흐지부지 끝나거나, 운용이 되는 경우가 많지 않다. 그럼에도 불구하고 아이디어를 수립하고 계획을 세우고 나아가야한다
첫 프로젝트가 완성되지 않는 이유는 다양하다. 기술적 지식의 부족, 프로젝트 규모 산정 실패, 팀원 간 조율 문제, 동기 부여의 상실 등 여러 요인이 있다. 하버드 비즈니스 리뷰에 따르면 IT 프로젝트의 약 70%가 어떤 형태로든 실패하는데, 경험 많은 개발자들도 이런 통계에서 자유롭지 않다. 처음 프로젝트를 한다면 이 수치는 더 높아질 수밖에 없다.
그러나 이런 통계에 두려워하지 말고, 오히려 첫 프로젝트의 본질적 가치를 이해해야 한다. 첫 프로젝트의 진정한 목적은 완벽한 결과물을 만드는 것이 아니라, 프로젝트 진행 과정에서 얻는 경험과 학습이다. 개발 프로세스를 경험하고, 팀 협업을 배우고, 기술적 문제를 해결하는 과정 자체가 성장의 기회이다. 그러니까 가장 쉽게, 산출물을 내놓는 게 좋다. 그래도 무언가 만들었으니까.
원칙 5 : 내가 사지도 않을 제품을 만들지 마라
이때 내가 프로젝트를 시작하는 기준은 '내가 꾸준히 사용할 것인가?'이다. 모든 제품은 가치를 창출해야만 한다. 내가 생각하는 엔지니어의 정의는 문제를 정의하고, 문제를 해결하는 사람이다. 그렇지만 우리는 모두 노동하는 존재로서, 노동 산출물에 대한 이해가 필요하다. 물론 노동 자체는 나의 자아를 찾아가는 과정이기도 하지만, 노동은 반드시 이 세상에 가치를 창출해야한다.
그러므로 내가 만드는 product는 어떤 효용이 있는지 깊이 고민해야한다. 쓸모도 없는 제품을 만들지 마라. 적어도 참여하는 팀원 모두는 그 product에 효용이 있다고 진심으로 믿는 이들이 모여야한다. 그렇게 생각하지 않으면 스스로 노동에 대한 회의를 반드시 할 수밖에 없으며, 그런 태도로는 아무것도 끝까지 만들어낼 수가 없다고 생각한다.
진심으로 product의 가치를 믿고 태스크 우선순위도 비슷한 팀원, 그리고 열정과 경험이 있는 리더를 모았다면, 이제 높은 확률로 성공할 프로젝트를 시작할 수 있다.
선결조건이 많아보이지만, 성공하는 프로젝트가 되려면, 이런 조건이 많은 것이다.
원칙 6 : 모든 것을 알고서 프로젝트를 시작할 수는 없다. 일단 시작하라. 다만 내가 무엇을 하고 있는지 명확히 이해해야한다
일단 시작을 하고 싶은 사람이라면, 저 모든 역할을 모두 스스로 하면 된다.
- 프로젝트 아이디어 발굴
- 프로젝트 계획 수립
- 아키텍처 선택
- 개발환경 구축
- 소스 관리
- 프로젝트 평가, 프로토타입 출시
- 프로젝트 배포
- 피드백, 개선 사항 찾아 신규 기능 개발 혹은 패치하면서 운용
처음한다면 이를 모두하기 쉽지는 않지만, 간단하게 본인에게 유용한 토이 프로젝트를 시작해도 좋다.
이 때 내가 사용하는 스택을 모두 알려고 하지말고, 애초에 아키텍처나 기술 스택을 본인이 이해하는 가장 쉬운 무언가로 만들어라.
개인적으로 필자는 1학년에서 2학년으로 전과 당시 전과하는 과별로 성적 환산을 하여, 순위가 어떻게 되는 사이트를 만들었는데 구글 시트를 활용하고, 이걸 iframe으로 띄우는 사이트를 웹빌더로 만든 프로젝트가 첫 프로젝트였다. 사이트는 웹빌더로 만들고, 내가 할 일을 구글 시트에 formdata로 받은 성적 데이터를 복사 붙여넣기하는 것이 었고, 사이트에서 구글 시트를 보여주므로, 자신의 순위를 알 수 있었다.
전혀 기술에 대한 이해가 없었지만, 결과물을 만들어냈고, 효용을 제공하였으며, 100명의 실제 유저를 만들었다.
그러므로 일단 시작하고 결과물을 빠르게 만들고 사람들에게 선보이는 태도가 중요하다. 점진적으로 기술을 학습해나가면 된다고 생각한다. 하지만 내가 만든 프로덕트에 대해서 적어도 워크플로우는 본인은 모르는 것이 없어야한다.
프로젝트를 시작하고 코드를 작성할때의 조언
- 핵심 기능의 인풋과 아웃풋을 정의해라
- 적어도 인터페이스는 만들어야한다
- 내가 만드는 코드를 line by line 이해하라. 이해하지 못하는 코드는 작성하지 말 것
- 최대한 간단하게 만들어라. 복잡성은 소프트웨어에서 끔찍한 일이다.
원칙 7 : 핵심 기능의 인풋과 아웃풋을 정의해라
프로그램은 결국에 함수다. 인풋을 넣으면, 아웃풋이 나와야한다. 필자는 이 개념을 이해하면서 개발이 쉬워졌다. 우선 가장 큰 범위에서 인풋과 아웃풋을 이해한다. 그 다음에, 전체 프로그램의 단계를 구분하고, 그 단계 내에서 함수 혹은 객체가 주고받는 인풋, 아웃풋을 이해한다. Top - Down 방식으로 설계를 해나가는 것이다.
원칙 8 : 적어도 인터페이스는 만들어야한다
내가 만드는 프로덕트의 입력은 뭐고, 무엇을 반환해야하는지 구분한다.
그리고 그 함수들의 인터페이스를 구현해본다. 협업할 때도, 프로그램의 인터페이스를 미리 구현해두면 구현 난이도가 상당히 편해진다. 상대방이 어떤 데이터를 던지겠지만, 결국 정의한 인터페이스 대로 데이터가 넘어올 것이라고 난 믿기 때문이다.
원칙 9 : 내가 만드는 코드를 line by line 이해하라. 이해하지 못하는 코드는 작성하지 말 것
그리고 내가 작성하는 코드의 효과를 몰라서는 안된다. 모든 내부 callstack을 파악할 필요는 없지만, 피상적이라도 조금의 이해는 하고 있어야한다. 이걸 모르고 쓰고, 프로그램의 복잡도가 늘어나고, 예측하지 못한 버그가 발생해 디버깅을 해야하면 그때 빚을 갚는 것이다. 뭐 맞아가면서 해도 좋지만, 우리는 사용자에게 좋은 품질의 경험을 제공할 의무가 있는 소프트웨어 엔지니어라는 일종의 직업정신을 가져야한다.
원칙 10 : 최대한 간단하게 만들어라. 복잡성은 소프트웨어에서 끔찍한 일이다.
이 모든 골치 아픈 버그의 발생은 복잡성에서 기인한다. 인간의 뇌는 생각보다 복잡한 사고를 하지 못한다. 추상화라는 개념으로 우리는 개념을 이해하는 것이다. 모든 것을 알 수는 없다.
따라서 이해하는 정도로만 프로그램을 구성해야만 한다. 더 나아가 나의 지식이 발전하여 점점 더 복잡한 구조를 활용할 수 있다고 하더라도, 최대한 간단한 구조를 지향해야만 한다. 이 경험은 장애를 발생시키거나, 장애가 났을 때 대처할 때 주로 깨닫는 개념인 것 같다. 뭐 모르면 맞으면서 배우라는 말도 있지 않은가?
다만 회사나 연구실 등 내 코드가 꾸준히 쓰이는 곳이라면 내 지적 허영을 위해, 복잡한 구조를 만드는 것은 절대 지양해야한다고 생각한다.
