회고

[네이버 부스트캠프 8기] 멤버십 2주차 회고

whiporithm 2023. 9. 10. 03:05

 

눈 깜짝할 새 일주일이 지나갔다. 바쁘게 살면 잡념에 매몰되지 않기 때문에 썩 싫어하진 않는다. 단 그 강도가 심해지면 내 생각과 행동 양식을 정리할 여유가 부족하다는 단점은 있지만 말이다.  2주차는 1주차보다 조금 성장했을까? 한 주를 다시 되돌아봐야겠다.

 

시작은 계획부터

 

2주차의 주된 내용은 1주차의 보완과, 백엔드라고 느꼈다. 저번주의 우다다다 구현방식을 지양하기 위해서 첫 날에 과제를 확인하고 계획표를 작성하기 시작했다. '프론트엔드', '백엔드', '내가 학습할 토픽들' 총 3가지로 나누어서 작성했고, 구현 같은 경우에는 '프론트 엔드', '백엔드' 를 날짜별로 구분해서 작성하였다. 작성하고 나서 보니 꽤 괜찮았던 거 같다. 무엇보다도 마음의 안정감이 생겼고, 하루의 밸런스를 잘 맞출 거 같은 기분이었다.

 

 

누구나 그럴싸한 계획을 갖고 있다.

 

첫 도약을 계획작성으로 잘 시작했으나, 하루하루 지나가면서 그 과정은 순탄치 않았다. 계획에 없던 구현에 욕심이 나기도하고, 당장이라도 쓰러질 거 같은 내실을 가진 내 코드를 보면서 리팩토링에 하루를 다 쏟는 경우도 있었다. 그러니까 내 계획의 맹점은 현재 결과물에서 보이는 것들 위주로, 기능적으로 앞으로만 나아갈 생각만 했던 것이다. 

 

계획대로 새로운 기능을 추가할려고 학습하고 구현하다가도, 이런 구조로, 이런 코드로 작성하면 나중에 유지보수에는 손도 못댈 거 같은 두려움이 몰려왔다. 그렇기 때문에 그 순간부터는 리팩토링과 구조를 잡기 시작했고, 계획표와는 달리 즉흥적으로 하루를 보내기 시작한다. 문제는 이러한 스노우볼이 한 번 굴러가면 다시 계획을 잡기가 힘들다. 나도 모르게 다시 프리스타일러가 되고 있단 말이다.

 

 

학습은 또 어디가고?

자, 백번 양보해서 리팩토링이든 내가 계획했던 기능이든, 결론적으로 프로젝트의 퀄리티를 높이니 넘어가줄 수 있다고 하자. 그런데 학습은 또 어디갔지..?? 

 

사실 계획표를 작성할 때 적어두었던 토픽들은 주말에 정리를 하려고 했다. 근데 딱 주말이 되고 느낀거는, 쉬고싶다 였다. 금요일쯤 되면 에너지가 거의 한계치에 다다라서 주말에는 행동력이 대폭 감소해버린다.. 뿐만 아니라 주말에는 또 주말에 할 일이 생기다보니 쉽지가 않은 거 같다. (그래도 이번주에는 가장 헷갈렸던 개념 하나는 정리하고 보내줘야지..)

 

 

어떻게 보완할 수 있을까

1주차보다는 고무적인게 2주차였으나, 2주차도 아쉬운 점 투성이이고, 3주차에는 이러한 점을 보완해서 계획을 작성해보려 한다.

 

우선 프론트와 백을 나누어서 내가 해야할 일들을 작성하되, 날로 구분할 필요는 없을 거 같다. 날로 계획한다고 맞추기도 어렵고, 괜히 그 날 계획표 보고 있으면 다른 일을 하는 내가 미워지기 때문이다! 따라서 할 일을 작성하되, 순차적으로 수행해보려고 노력할려 한다. 그리고 그 계획은 내가 다 수행해야할 계획이라기 보다, 최대치를 작성해놓은 것이므로 하나를 하더라도 제대로 하는게 더 중요하다고 생각한다.

 

그리고 그렇게 기능 수행중에, 내가 모르는 개념이 나오면 과감히 '학습' 에 힘써보려 한다. 모르는 개념을 깔끔히 블로그에 포스팅 할 수 있을 정도로 학습하고, 구현으로 돌아가보자. 

 

이런식으로 하면 아마 남들보다 진도가 느릴 거 같긴하지만, 항상 명심해야 한다. 우리는 결승점에 먼저 도달하기 위해서 부스트캠프를 하는게 아님을. 

 


 

일주일간 느낀점은 위에 다 작성했고, 조금 잡념들도 적어보려 한다.

같이 일하고 싶은 개발자

 

금요일에 진행된 마스터 클래스의 끝자락 쯤에 각 마스터들이 신입사원들을 어떻게 뽑는지에 관해 설명하는 시간을 가졌다. 공통적으로 말해주셨던 건 '성장 가능성이 보이는 사람' 이였다. 이게 무슨말인가 하면, 이 사람이 우리 조직에 들어왔을 때 성장폭이 다른 사람보다 클 거 같은 사람을 의미하는 것이다.

 

A라는 사람은 취업전에 100의 능력을 지니고 있고, B라는 사람은 취업전에 50의 능력을 가지고 있다. 이 상황에서 우리 조직에 들어왔을 때 1년간 A는 성장폭이 30이고, B의 성장폭은 80일 경우 B가 훨씬 더 조직에 잘 맞는 인재란 말이다. 

 

 

기술만 주구장창 적는 블로그는 지양해라

 

사람끼리 긴밀하게 소통해야하는 개발자의 포텐셜과 성향을 보기 위해서는 '글' 만한 요소가 없다고 마스터분께서 말씀해주셨다. 내가 어떤식으로 문제를 해결하고, 어떤식으로 학습했는지를 대략적으로 적어둔다면 단순 이력서 한 장 보다는 분명히 가지는 힘이 클 것이라는 말이다.

 

나는 이전까지 취준생에게 블로그의 의미는 '내가 무엇을 하고 있다' 의 증명정도라고 생각했다. 내가 문제를 풀고, 학습을 해서 개념을 정리하고.. 내가 이만큼 개발에 시간을 할애한다는 상징이라고만 생각했다. 근데 마스터분께서 '기술만 적는 블로그' 를 지양하라고 말씀해주셨고, 내 관점이 확실히 달라짐을 느꼈다. (물론 기술블로그도 훌륭하다고 생각한다. 엄청난 도움을 받는다 항상..) 

 

내가 개념 학습한 글을 적더라도 어떤 방식으로 접근했는지, 그래서 어떻게 적용했는지 등의 서사를 담아 작성한다면 내가 다시 돌아보았을 때 떠올리기도 좋고, 내가 어떤 방식으로 개발을 하는지 다른사람에게 쉽게 어필도 될 것이다. 

 

 

 


 

글 한편 쓰는데 시간을 많이 할애해야해서 쉽지 않지만, 글을 쓰면서 내 생각과 한 주간의 부족한 점을 정리할 수 있는게 참 좋은 거 같다.

끝나지 않을 거 같은 여름이 이제 해가 지고는 조금 물러선 거 같다, 기분좋은 밤바람을 기대하며 3주차를 준비해봐야겠다.