[우아한테크러닝] 1주차 과정

[2021.06.01] 첫번째 과정

첫번째 과정은 간단한 아이스브레이킹으로 시작했다. 우아한 형제들의 기술이사가 몇명이냐는 질문에 가장 빠르게 답변을 해서 배달의 민족 10,000원 쿠폰을 얻을 수 있었다. 👍

50분 과정을 진행하고 10분 쉬는 형식으로 한 과정을 3시간, 총 1주 6시간 동안 과정을 진행한다.

첫 느낌은 김민태님은 정말 멋진 개발자라는 생각이 들었다. 멋진 개발자보다는 멋진 사람. 그런 느낌이다. 이러한 느낌을 받은 이유는 개발에 관한(자기 직업에 관한) 철학이 뚜렷하다는 느낌을 받았는데, 다음과 같은 4가지 질문을 통하여 소통을 진행하였다.

1. 시니어 개발자가 왜 필요할까? 또는 시니어 개발자가 필요할까?
2. 실무적 코드란 무엇일까?
3. HandsOn은 누가 잘하는가?
4. 개발을 잘한다는 것은 무엇일까?

시니어 개발자는 왜 필요할까? 혹은 시니어 개발자가 필요한가?

나의 의견 :
시니어 개발자는 필요하다.

사실 그냥 취준생 입장으로 시니어 개발자와 함께 일해본 적이 없어서 정확히는 모르겠다. 그저 내가 생각하는 것은 팀 프로젝트를 진행 할 때 "이끄는 사람이 필요할까?" 정도로 공감할 수 있을 것 같다.

팀 프로젝트를 진행 할 때 확실히 주관이 뚜렷하거나, 실력이 독보적인 팀원이 있으면 팀의 방향이 더욱 생산적이며 효율적으로 진행된 경험이 많다. 이런 관점에서 시니어 개발자를 투영하고 팀 프로젝트를 회사로 확대해본다면, 핵심 인재일 것이라 생각하기에 나는 시니어 개발자가 필요하다고 생각했다.

 

김민태님 의견(과정을 진행하고 몇일 뒤 생각나는 대로 적은 것이라 정확치 않을 수 있습니다.)

주니어 개발자들은 경주마와 같다 -> 앞만 보며 열심히 달려가지만, 주변을 잘 보지를 못한다.

한 주니어 개발자를 완전히 마른 스펀지와 같다고도 비유하셨다. 완전히 마른 스펀지는 물이 있는 곳에 두면 더러운 물이든, 깨끗한 물이든 모두 쫘악 흡수한다.

시니어 개발자는 이런 주니어 개발자가 보지 못하는 것을 봐주고 적재적소에 적용할 수 있도록 안내해주는 역할을 한다.

 

실무적 코드란 무엇일까?

나의 의견 :

기능위주가 아닌 시스템위주로 잘 설계된 코드라고 생각한다.

사실 회사에서 근무해본 적이 없기에 이 부분은 잘 모르겠으나, 외주를 하거나 개인적인 프로젝트를 할 때. 설계 단계에서 이런 고민을 많이 해보았다. "나중에 내가 이 코드를 보았을 때 빠르게 이해할 수 있으며, 수정이 용이하고 확장성이 좋은가?"를 고민하며 프로젝트를 진행하려고 고민한다.(하지만 막상 이렇게 설계하고 직접 코딩을 하다보면 복잡도가 너무 올라가져 버리기 일쑤이다...🥲)

내 생각을 조금 더 풀이하자면, 표면적인 기능은 어차피 다 만들어질테지만, 이 코드의 생명력은 얼마나 더 관리를 편하게 할 수 있느냐에 달려있고, 그 코드가 실무적인 코드지 않을까 생각한다.

 

Hands On은 누가 잘하는가?(하루에 다루는 코드량)

나의 의견 :

많이 해본 사람이라고 생각한다.

정확히 말하면 그 기술을 많이 다뤄본 사람. 혹은 기본적인 이론도 중요하겠지만, 실제로 코딩을 많이 해본 사람이 Hands On을 잘한다고 생각한다.

 

김민태님의 의견 :

Hands On은 당연히 시간을 많이 들인 사람이 잘한다고 생각한다. 이것을 비유하자면 날이 서있다라고 표현하고 싶다고 말씀하셨다. 예를 5년 동안 쓰지도 않은 칼로 요리를 하려한다면 날이 잘 서있을 리가 없을 것이다. 그렇지만 꾸준히 관리되어 온 칼로 요리를 하면 전의 칼과 비교하여 훨씬 잘 들을 것 이다.

그렇기에 이런 훈련 과정을 꾸준히 하는게 중요하다고 생각한다. 속도가 빠른 것이 능사는 아니다. 그렇지만 무의식적으로 하는 올바른 행동들이 많아지면, 의식적으로 해야 하는 행동에 더 많은 시간을 쏟을 수 있을 것이다.

 

두번째 과정까지의 과제 및 목표

• React & Typescript 세팅, Repo를 팔 것.
• 추가적으로 필요한 라이브러리 생각해오면 좋을 것 같음.
• 올려진 Repo를 기준으로 공통적인 Repo 하나를 선정할 것.
• 선정된 Repo에 모두가 PR로 참여하여 결국 하나의 Notion을 만들 계획.

---

[2021.06.03] 두번째 과정

첫번째 과정의 과제를 수행하였다. 기본적으로 Hello World 수준의 Server와 Client를 나누어서 리포에 세팅을 해두었다. 마음같아서는 프로토타입이라도 빠르게 만들고 싶었는데, 정말... 물리적으로 시간이 너무 부족했다.(🥲) 현재 해야 할 것들도 많았기에 최소한 할 수 있는 것들만 해두었다.

총 100명 참여자 중 마흔명 정도의 참여자들이 리포를 만들었고 공유하였다.

 

두번째 과정은 기획을 중심으로 이야기를 풀어나갔다.

목표 설정

김민태님은 모든 참여자들이 '목표 설정'을 하지 않은 부분을 언급해주셨다. 우리는 각자 'Mini Notion'을 만들거야 ~!😉 했지만 이것은 '각자의 'Mini Notion'이다. Consensus가 되지 않았다. 이렇게 된다면 모두 다른 나만의 Notion이 되버릴 것이기에 정확한 목표 설정 및 기획에 관련된 부분을 Readme에 올리지 않은 것을 언급하였다.

정확히 맞는 말이었다. 하나의 Repo를 선정할 것이기에 자신이 생각한 라이브러리 선정 이유 및 프로젝트의 목표 및 방향성에 관련된 기획을 빼놓았던 점은 실수였다. 그렇기에 목표를 정확히 하는 시간을 가졌다.

• oAuth로 구글 로그인이 가능할 것.
• 단일 문서 형식으로 개발할 것.(Notion의 Directory는 사용하지 않음)
• 가장 마지막 유저가 값을 저장한 것을 기준으로 표현될 것.

또한 김민태님은 기술 선정에 대해 이러한 사항들을 고려해보는 것이 좋다고 하였다.

• 기술적 난제가 있는가?
• PoC를 해보는 것.
• 프로토타입과 같이 직접 만들어보는게 중요하다.
• 실용 가능한 것인지 확인해보자.
• 이미 사용해본 기술이지만 다르게 시도해보고 싶은 것들을 도출해보자.

추가적으로 나와 같이 Client와 Server를 한 Repo에 올린 사람들이 대부분이었다.(거의 전부인 것 같다)

하지만, Client Repo와 Server Repo로 나눈다면 추후 브랜치 전략에서도 복잡도를 낮출 수 있을 것이라는 의견도 말씀해주셨다. 이 말을 듣고 고려하지 못한 부분에 감탄하였다.

 

기술 선정

또한, 참여자 중 한명이 mini notion에 넣어도 괜찮다고 생각한 라이브러리를 제시했다.

Toast UI

nhn/tui.editor

 

위 라이브러리는 텍스트 Editor 라이브러리이다.

 

김민태님은 참여자 모두와 이 라이브러리에 대해 우리 mini notion에 적합한지 각자 생각해보는 시간을 가져보자고 하였다. 20분의 시간이 주어졌다.

 

"나는 이 라이브러리를 사용하면 편리하다고 생각했다."

일단 솔직하게 나는 괜찮다고 생각했다. 그 이유 API를 확인해보니 사용하기 매우 편리해보였으며 MarkDown도 기본적으로 지원해주어서 우리가 원하는 기능들을 만들 수 있겠다고 생각하였다. 최종적으로 All in one 에디터이다 보니 "notion에 없는 새로운 기능들도 쉽게 넣을 수 있겠는데?" 싶었다. 추가적으로 꽤나 최근에도 관리되고 있기도 하였다.

그렇지만 여러 참여자들과 김민태님의 의견을 듣고 나의 생각은 확 바뀌었다. 매우 설득력 있었으며, 다시금 기술 선택에 대해 넓게 생각해야한다는 생각을 했다.

솔직히 이렇게 단조롭게 판단한 내 자신이 조금 부끄러웠다.

 

김민태님과 일부 참여자들의 의견은 "이 라이브러리는 적합하지 않다."라고 생각했다.

All in one editor이다. 이렇게 거대한 라이브러리는 자연스레 커스터마이징을 하기 힘들 것이라고 판단했다. 그래서 커스터마이징 API가 지원이 잘 되어있는지 파악했으나 커스터마이징 API는 매우 적다고 판단했다. → 애초에 커스터마이징을 편리하게 할 수 있도록 만든 라이브러리가 아니지 않나? 싶었다. 우리는 React-Typescript인데 이 라이브러리는 바닐라인데 라는 생각이 컸다. 물론 해결방안은 있었겠지만 그거 자체가 비용이다.

라이브러리를 선택할 때 introduction을 잘 보아야 한다. 잘 만들어진 라이브러리 introduction은 많은 고민을 하고 작성한다. 그렇기에 우리 목표와 맞는지를 확인할 때는 introduction을 잘 보자.

또한 새로운 라이브러리가 API가 너무 많고 배우기 어렵다는 것도 감안해야 한다. 이것은 비용의 문제이다.

 

그리고 다음 과정까지의 과제이다. 😄

정말 다 해보고 싶은데... 면접이 겹쳐있어서 다 할 수 있을지 모르겠다... 😂😂😂😂😂😂

• oAuth 회원가입 - 로그인
• 간단한 prototype 개발
• SlateJS를 가지고 (에디터 + bullet) 정도 만들어보자.
• DraftJS로 가지고도 만들어보자.
• https://codesandbox.io 로 만들어보자.
• 선정된 Repo를 fork 떠서 PR을 날려보자.

추가적으로 기억에 남는 말들 !

• 좋은 개발 문화란 시니어든 주니어든 자기의 의견을 말할 수 있는 조직이라고 생각한다.
• 책은 최대한 가까이 해라. 다독해라 !
• 프론트엔드라고 해서 프론트엔드에만 집중하지 말아라 ! 넓게 보자.
• 취업은 전략이다. 경쟁력 있는 사람이 되려면 어떻게 해야할지 고민해보아라.
• 자기가 개발한 프로젝트의 기술 스택에 대해 이유가 있어야 한다. 단지 선택권한이 없었다는게 이유라면 아쉬운 엔지니어이다. 선택 권한이 없었더라도, 프로젝트에 부합되는 장단점과 특징 정도는 이해하고 있어야 한다.
• 엔지니어는 언제나 이유를 만들어야 한다.(논리적이어야 한다.)
• 10을 수용할 아키텍쳐로 구성하였다가 100으로 볼륨이 커져버리면 자연스럽게 복잡도가 올라가고 리팩토링을 거치게 된다. 반대로 10을 수용할 것이지만 100을 수용할 아키텍쳐로 구성했다면 오버 엔지니어링이다.