달랩 멘토링 2기 회고

책 읽고 서평 작성하기

달랩 멘토링을 통해 좋은 습관을 만들었다. 내 블로그 about에 페이지에 가면 내가 했던 일들과 읽은 책 목록을 확인할 수 있는데, 읽는 책 목록을 여기에 썼다고 해서 내가 정말로 읽었다고 신뢰할 수 없다. 내가 과시하고 싶어서 거짓말로 읽었다고 책 제목을 써놔도 아무도 모르기 때문이다. 의심할 여지가 없도록 나는 증거를 남기기 시작했다. 그 증거로 회고를 작성했다. 하지만 읽은 책에 대한 증거는 없었는데 멘토링에서 매주 책 한 권을 읽고 책 서평을 작성하는 미션이 있었다. 이 미션을 완료하기 위해 악착같이 책을 읽었다. 사실 억지로 했지만 하고 나니 굉장히 기분이 좋았다. 증거를 남겼기 때문이다. 좋은 경험이었어서 멘토링을 계속하지 않는다고 할지라도 서평 작성은 계속할 것이다. 책을 읽고 나서 내용을 다시 한번 정리하는 것도 물론 좋았다. 멘토링을 처음 시작하면서 책 많이 읽기가 목표였는데 이뤄서 좋았다.

포모도로

멘토링 미션 중 데일리 저널을 작성하는 것이 있다. 나의 장애물을 다른 사람들에게 공유하고 오늘 내가 무슨 일을 할 것인지 어제는 어떤 일을 했고 그 과정에서 배운 것은 무엇인지를 다른 사람들과 공유를 하는 것이었다. 다른 사람들이 올리는 데일리 저널을 보는데 많은 사람들이 포모도로를 하는 것을 봤다. 뭔지 잘 몰랐는데 흥미가 생겨 알아보고 나도 시도해봤다. 클린 코더에서도 내용이 나오는 것을 나중에 알게 됐다.

포모도로를 하면서 나만의 단위가 생겼다. 뭔가 열심히 한 것 같은데 돌아보면 허무한 경우가 많았다. 그런데 정확한 포모도로 개수를 보면 내가 얼마나 했는지 알 수 있다. 그리고 특정 작업에 대해서 얼마나 걸리는지 포모도로를 세면 알 수 있다.

개인 프로젝트

VS Code에서 사용할 수 있는 Wiki와 번외로 한글 맞춤법 검사기를 만들었는데 github 레포에 모르는 사람이 스타를 눌러줬다. 내가 필요한 것들을 만들어서 재밌었다. 현재도 잘 쓰고 있다.

만들 때 무작정 만드는 것이 아닌 다음 순서를 따르면서 만들었다.

1. 이 프로그램을 사용하는 상황과 필수 요소, 제약 조건 등을 정합니다. “내가 이 프로그램을 쓴다면?”이라고 가정하면 더 쉬울 수 있습니다.
2. 무엇을 입력했을 때 어떤 결과가 나와야 하는지 “구체적인 사례”를 찾아 봅니다. 표현이 부족해서 추가적인 설명이 많이 필요하다면 더 많은 생각과 탐구가 필요합니다. 어디까지 구현할 건지, 무엇이 가장 중요한지, 어떤 순서대로 진행해야 할지 결정합니다. 구체적인 사례를 많이 찾았다면 우선순위를 정하는 게 필수입니다.
3. 만약 우선순위가 필요 없을 정도로 구체적인 사례가 적다면 2번으로 돌아갑니다.
4. 프로그램을 구현합니다. 큰 작업을 하지 말고, 매우 작은 작업을 반복해서 진행합니다. 각 작업은 (내 실력으로) 1시간 이내에 깔끔하게 완료할 수 있을 정도로 작아야 합니다.
5. 결과를 공유합니다.
6. 피드백을 통해 배운 점을 적용합니다.

피드백을 통해서 기능을 만든 경험이 좋았다. 일단 내가 어떻게 쓰고 싶은지를 결정해서 만들고 다른 사람의 입장에서 불편할 수 있는 부분들을 보완하여 개발을 진행했다.

사람들의 다운로드 수가 생각보다 많았다. 가끔씩 다운로드 수를 확인하는데 재밌다.

다른 사람들이 프로젝트를 진행하면서 했던 고민들을 듣는 것도 좋았다. 내가 만드는 것의 경우 내가 만들고 싶은 기능을 만들어서 사용자 스토리나 요구 사항에 대해서 많이 고민을 하지 않았는데 다른 사람들의 경우 이런 고민들을 한 흔적을 볼 수 있어서 좋았다.

아쉬웠던 점

• 팀이 없었다. 팀 프로젝트는 아니더라도 서로 코드 리뷰도 해주고 상황도 공유할 수 있는 팀이 있었으면 좋았을 것 같다. 각 팀에 조교가 있으면 더 좋을 것 같다.
• 목표가 불분명했다. 데모데이를 하면 어떨까 생각을 했었는데, 미리 데모데이가 잡혀있다는 사실을 알고 있었다면 더 열심히 만들었을 것이다.