우아한테크러닝4기 2회차

- 환경설정 및 채택한 라이브러리 발표

환경설정을하고 채택한 라이브러리를 하는 과제였는데 이를 발표하는 시간을 가졌습니다.

김민태 기술이사님께서 발표하실 분 있냐고 물으셔서 "할까, 말까?"라고 잠시 머뭇거리다가 그냥 생각을 비우고 "손 흔들기"를 눌렀습니다. 그러자 발표할 기회를 주시고 이 저장소로 발표를 하게되었습니다.

 

- 제안의 문제점

저의 문제점은 선택한 라이브러리에 대한 이유의 논리가 부족한것입니다.

리액트가 일부 있지만 기본 코드가 vanilla js로 되어있어서 기술 스택이 맞지 않습니다.

올인원 에디터로 다양한 커스터마징을 위한 인터페이스를 제공하지 않습니다.

 

- 이전으로 돌아가서 어떻게 행동하는것이 최선이었는가?

피드백을 받고 나니 기준점이 없었고 이것을 듣기 전으로 돌아가서 많은 시간을 들여도 날카롭게 분석해오지 못했을것 같다는 생각이 들었습니다. 그렇다면 이전으로 돌아간다면 스스로 어떻게 행동하는게 더 나은 것이었을지 생각했습니다.

기존에는 markdown parser를 찾고 무작정 문서를 읽으려고 했었습니다. 그런데 검색하기 전에 무엇을 하려는지 생각해봤을 수 있을것 같습니다. 그렇게 되면 무엇을 찾아보고 어떤 기준으로 라이브러리를 분석해야하는지 모른다는 점을 발견했을것 같습니다. 그렇다면 이것을 slack에 공유하여 질문했을 수 있을것입니다.

이유없이 무언가를 찾아오는것보다 어떤 생각을 하였고 어떤 점이 어려웠는지를 정리하는것이 오히려 옳은 방향성일 수 있었을것이라고 생각합니다.

 

- 더 큰 문제, 무엇을 구현할지 공통되게 알고있지 못한것

하지만 더 큰 문제가 있다고 하셨습니다.

역할분담, 개발범위 설정, 사용자 선정 등 다양한 의견이 나왔습니다.

결론은 우리 모두가 무엇을 만들고자하는지 모르는것입니다.

노션을 만들겠다고하면서 각자 어떻게 구현할지 생각을 했을뿐 동일하게 이해하고 있지 못한것입니다.

모호하다고 생각하는것을 질문해야하는것을 알았습니다.

사실 정말 공감했던것이 첫날이라 적응하는것도 있었지만 서로에 대해 모르고 1,2년차 개발자님들도 있고 다들 잘하시는것 같고 무언가를 물어보기를 주저했던것 같습니다. 거기다가 정말 유명하신 김민태 기술이사님과 우아한형제들 개발자분들도 계셔서 긴장되는것도 있는것 같습니다. 하지만 지금 하는것이 기업면접도 아니고 틀리면 틀리는대로 배우면 되는것입니다. 지금 틀려서 배운다면 다행인것입니다. 그리고 사실 기업면접이라고 해도 마찬가지인것 같습니다. 모호하게 이해하는것이 있다면 질문해는것 자체가 자신이 무엇을 모르는지 인지하는것이고 그것을 알아야 상대방과 같은것을 두고 얘기하고 있지 않다는것을 아는것입니다. 결국 기업면접 과정도, 그리고 이렇게 교육 프로그램에 참여하는것도 의사소통의 일부라고 생각합니다. 뭔가 잘 평가받겠다는 생각보다는 의사소통을 해야한다는 생각이 더 마음도 편하고 적극적으로 참여할 수 있는 동력이라는것을 느꼈습니다. 개발자의 역량으로 의사소통을 꼽는것이 타부서와의 의사소통도 있겠지만 개발자들 사이의 의사소통도 중요하다는 생각도 들면서 이번에 의사소통이 필요했던 상황이 흔히 말하는 의사소통의 일부에 해당할 수 있겠다는 생각이 들었습니다.

 

- 기술/라이브러리 채택시 논리적인 이유 필요

기술이나 라이브러리를 선택하는 이유가 있어야합니다. 이런 좋은 꿀팁을 알려주셨는데 사실 이는 완전히 새로운 사실은 아닌것 같습니다. 그래서 어떻게 해야겠다는 '생각'보다는 '실천'이 중요한것 같습니다.

그렇다면 왜 중요하다고 생각하면서 실천을 하지 않는지 생각해보았습니다. 취업준비하느라 특정 기술만 공부하기도 바쁘다고 생각하는것 같습니다. 그런데 이는 사실 첫단추 부터 잘못된것 같습니다. 바닥부터 다 구현하는것은 흔하지 않고 어떤 기술을 선택할지 결정하고 들어가야하는데 이를 논리적으로 결정하지 않으면 나중에 구현을 할때 문제가 생기기 때문입니다.

 

- 제안을 발표해본 경험

제가 제시한 제안은 스스로 평가했을때 논리적인 설명이 없고 취지에도 안 맞는 제안이라고 생각합니다. 하지만 김민태 기술이사님께서 평가해주신것 자체가 정말 영광이었고 직접 저의 제안을 기준으로 평가해주셔서 저의 부족함을 적나라하게 알 수 있는 귀한 경험이었습니다. 그리고 다른 개발자님들의 평가와 질문을 받은것 자체가 미리 한 기업의 회의에 참여한것 같아서 훌륭한 경험이었습니다. 그리고 저의 제안을 평가 받다보니 무엇이 문제인지 다른 라이브러리는 어떤점에서 더 좋은지 더 집중할 수 있었습니다.

 

- 라이브러리 살펴볼때 눈여겨볼 사항들

1. 스스로를 설명하는 페이지

라이브러리가 스스로를 설명하는 페이지는 중요합니다.

왜냐하면 결국 사용자는 서비스를 설명하는 것을 볼것이고 만든사람은 이를 위해 공을 들여서 최대한 잘 설명하고자 하기 때문입니다.

 

2. 지원 언어

사용하고자하는 언어를 지원하는지 살펴봅니다.

 

3. 한 언어로만 가능한지 여부

한 언어로만 가능한지, 언어에 종속하지 않은 라이브러리를 포함하는지 봅니다.

예를들어, Slate는 slate와 slate-react가 있는데 이런식으로 코어와, react가 분리되어있어서 기술스택이 바뀌면 이에 따라 바꿀 수 있습니다.

 

4. 다양한 커스터마이징을 위한 인터페이스 제공 여부

커스터마이징이 다양하게 할 수 있도록 인터페이스를 노출하고 있는지 살펴봅니다.

이유는 하고자하는 프로젝트에 다양하게 활용가능한지 알 수 있기 때문입니다.

 

5. 원칙

어떤 원칙이 있는지 살펴봅니다.

이는 기술을 공부할때도 마찬가지인데 라이브러리/기술의 철학을 알 수 있고 어떤 의도로 만들었는지 알 수 있습니다.

 

- 라이브러리 후보 채택

Draft.js

Overview | Draft.js

 

1. 스스로를 설명하는 페이지, 2. 지원 언어

라이브러리를 설명하는 페이지에 rich text editor를 만들 수 있고 React를 지원하는것을 알 수 있습니다.

 

3. 한 언어로만 가능한지 여부

 

Slate

Introduction