[회고] 원티드 프리온보딩 인턴십 회고(라 쓰고 느낀 점이라 읽는다)

개요

 

4주간의 짧은 프리온보딩 인턴십이 끝났다. 짧은 과정에 비해 배우고 느낀 점이 많은 것 같다. 기술적으로는 물론이고 다양한 사람들과 의견을 나누고 코드를 분석하며 많은 생각을 하게 되어 간략하게 정리하여 회고를 작성해보고자 한다.

 

첫 동료학습

 인턴십 과정에서는 세 개의 과제가 있었는데 그 중 두개의 과제는 동료학습으로 이루어졌다.

원티드에서 설명한 동료학습이란 팀원 모두가 전체의 기능을 구현한 후 토론을 통하여 각 기능에 대한 best practice를 도출하고 각 best practice들을 모아서 최종적인 결과물을 만들어내는 것을 의미했다.

 

 우리 팀은 6명으로 이루어져 있었는데 현업 경험이 있으시고 개발에 숙련된 분들이 한두명씩 포함되어 있던 다른 팀과는 달리 팀원 모두가 개발문화에 능숙한 편이 아니었다.

 

 다들 참여는 열심히 해서 각자 코드를 구현하는 것에는 문제가 없었지만 best practice를 도출하는 과정과 Github을 사용한 협업에 어려움이 있었던 것 같다.

 best practice 도출과정에서는 다들 적극적으로 코드 어필을 한 사람이 별로 없었기 때문에 한명이 이거 좋은 것 같다고 하면 그냥 흐름따라 결정되는 분위기였다. 좀 더 적당한 근거에 기반한 선정 과정이 있으면 좋겠다는 생각을 했다. 그리고 Github를 통한 협업에서는 브랜치 관리가 제대로 되지 않아 효율적인 협업을 이루지 못한 것 같아 아쉬움이 남는다.

 

 하지만 다들 열정 가득한 모습으로 늦은 새벽까지 회의를 하면서 참여했기 때문에 결과적으론 과제 요구조건을 모두 수행한 결과물을 만들어 낼 수 있었다. 주로 혼자서 작업을 하다가 오랜만에 다른 사람들과 의견을 나누며 작업을 한 것이었는데, 여럿이서 작업을 하니 팀에게 민폐가 되지 않고 싶은 마음에 더 열정적으로 임하게 되는 것 같았다.

 

세 개의 과제

과제 1. [ 동료학습 과제 ] 로그인 기능을 갖춘 투두리스트 구현

 

과제 2. [ 동료학습 과제 ] 특정 github 레포지토리의 이슈 목록과 상세 내용을 확인하는 웹 사이트 구축

 

과제 3. [ 개인 과제 ] 한국임상정보의 검색 영역 클론

 

프로그램 진행하며 느낀 점..🙄

1. 세상 아래 같은 코드는 없다. 기술은 무궁무진

혼자 프로젝트를 진행할 때는 익숙함을 따라 늘 쓰던 프레임워크나 라이브러리를 주로 썼다. 이번 인턴십에서 여러 사람들과 같은 과제를 진행하며 다양한 코드를 보게 되었는데 아주 생소한 라이브러리를 쓰신 분도 계셨다. 사실 별로 효율적이지 못한 일이라고 생각했지만 코드를 자세히 뜯어보니 나의 편협한 생각과는 달리 그 기능 구현에 아주 알맞는 라이브러리였다. 

 

하나의 기술을 깊게 파는 것도 좋지만 여러 기술을 접해 보는 것 또한 굉장히 중요하겠다고 느꼈다. 모든 기술의 탄생엔 이유가 있을 것이고 장점과 단점은 언제나 공존할테니 직접 사용해보면 가장 효율적인 기술을 선별할 능력을 갖출 수 있을 것 같다.

 

그리고 나와 같은 기술을 써도 어떻게 사용하냐에 따라서 효율성에 차이를 만들어낸 분들도 많았고, 그건 많은 코드를 경험하면서 얻어진 센스인 것 같았다. 이걸 여기서 이렇게 쓴다고..?! 하는 포인트가 왕왕 있었다.

 

여러모로 개발자는 평생 공부해야하는 직업이라는 것을 새삼 한번 더 깨닫게 되어버린..

 

2. 개발자는 글도 잘 써야 하는구나.

깃허브 리드미를 보면서 길지 않은 글임에도 글의 짜임새나 용어 등을 통해서 개발 내공이 드러났다. 나는 개발적인 요소를 설명할 때 용어 중복이 많고 명확하지 못한 경우가 많은데 그 글들은 군더더기 없이 깔끔하다고 해야 하나.. 이건 평소 많은 개발 블로그를 보면서 느꼈던 점이기도 하다.

 

 글도 잘 쓰기 위해서 가장 중요한 것은 많이 보고 많는 것이라는 걸 알고 있기 때문에 열심히 블로그 포스팅하고 개발 글들 정독해야겠단 다짐을 했다.

 

3. 내 코드에 대한 자신감이 필요하다.

 팀원들과 Best practice를 도출하는 과정에서 열심히 만든 내 코드를 어필하고 싶었지만 내 코드에 확신이 없어서 적극적으로 참여하지 못했다. 어필을 하기 위해서는 내 코드가 그만한 근거를 갖추고 있어야 하는데 정말 내 코드가 맞을까? 라는 의문이 스스로에게 들었다. 과거 경험 상 내가 짠 코드보다 더 완벽한 코드를 마주한 적이 많은 탓에 점점 자신감이 떨어진 것 같다.

 

 이걸 극복하기 위해 생각을 고쳐 먹기로 했다. 일단 내가 지금 완벽한 코드를 만들어내기에 부족하다는 것을 인정하기로 했다. 그렇지만 내가 짠 코드는 내 현재의 최선을 다한 코드이니까 다른 사람의 더 훌륭한 코드에 기죽지 않기로 했다. 피드백을 받아 점점 더 발전하면 되는 거니깐..! 이렇게라도 자신감을 회복해 협업에서 자신감을 갖고 여러 의견을 낼 수 있는 사람이 될 것이닷

 

4. 끊임없는 호기심이 개발자를 성장시키는구나.

 강의를 들을 때 항상 질문이 많은 분들은 눈에 띌 수밖에 없는데, 누구나 궁금해할만한 보편적인 질문을 하는 분도 있었지만 당연시하게 쓰이는 기술에도 왜 쓰이는지 집요하게 파고드는 분도 계셨다. 처음에는 그 작은 포인트에 강의가 지연되는 것이 지루하게 느껴졌다. 근데 질문에 대한 답변은 내가 몰랐던 새로운 내용이었고 그걸 알게됨으로 인해 조금 더 그 기술에 근본적인 이해를 하게 되는 느낌이었다.

 

그 이후로 당연한 건 없다는 시선으로 코드를 보려고 노력한다. 왜 이게 이렇게 되지? 라는 의문을 자주 갖으려고 의도적으로 행동하고 있다. 그렇게 하면 물론 시간은 훨씬 오래 걸리지만 완전히 이해하고 있다는 자신감과 성장하고 있다는 것을 느낀다.

 

~~ 결론 : 공부 열심히 하고 코드 많이 보자

 

그리고..

5. KPT에 기반하여 회고를 쓰는 습관을 들여야겠다

이 글이 처음으로 제대로 써보는 회고인데 글을 마치면서 새삼 너무 느낀점 위주로만 쓴 것 같다는 생각을 했다. 프로젝트가 아닌 인턴십 프로그램 회고라서 더 개인적인 느낀점 위주로 채워진 듯 하다. 다음 프로젝트 후에는 꼭 KPT 규칙 지켜서 써봐야지

 

• Keep (프로젝트에서 만족했고, 앞으로의 업무에서 지속하고 싶은 부분)
• Problem (프로젝트에서 부정적인 요소로 작용했거나 아쉬웠던 점)
• Try (Problem에 대한 해결 방식으로 다음 프로젝트에서 시도해볼 점)