[인턴] 첫 인턴 회고

내 주변에는 개발자가 없기 때문에 처음으로 정말 돈을 받고 일하고 있는, 현업개발자, PRO개발자를 만나고

또 상호작용하며 프로젝트를 진행할 수 있는 귀한 기회를 얻어 인턴을 진행했다. 회고를 통해 스스로를 돌아보고 잘 한 점은 강화하고 못한 점은 수정하며 발전해 나가려고 한다.

인턴을 시작하기 전에

먼저 인턴을 진행하기 전에 나름대로 해당기업의 핵심 사업은 어떤것일인지, 최근에 인터넷 기사로 알려진 바는 무엇인지 등을

조사해갔고 최대한 외부에 공개된 정보를 통해 어떤 기업인지 파악해보려고 노력했다. 개발 외적으로도 해당기업의 핵심 서비스를 이해하기 위해 알아야할 것들이 있기도 했고, B2B 인지 B2C 현재 사업에서 확장 방향성은 어떤 것이 있을지 등에 대해 나름 고민을 해보았다. 다음으로는 개발자이기 때문에 해당 기업에서 사용한다고 알려온 기술에 대해서 공부를 시작했다.

잘'한'점

- 같은 인턴 동기들끼리도 서먹서먹한 사이였기 때문에 먼저는 이들과 가까워지고 잦은 의사소통이 가능한 환경을 만들려고 노력을 많이 했던 것 같다. Notion페이지를 만들고 공유해야할 내용들을 동기 모두가 공유할 수 있도록 만들었고 협업툴인 지라나 트렐로를 사용하자고 건의하거나 단체 채팅방을 만드는 등 소통을 위해 주도적으로 나섰다.

 

- 친절하게도 현업 개발자 분들께서 이런 저런 설명을 해주신 때가 있었는데 설명을 들으면서 기록해서 회의록처럼 나름대로 정리해서 설명 들었던 당시에는 처음 들어보는 기술스택과 적용방식이라 이해하지 못했던 것들은 차후 검색해보고 공부하면서 이해할 수 있었고 이를 또 공유해 팀전반의 생산성이 높아졌던 것 같다. 동기들 모두 비슷한 기술스택을 가지고 있었기 때문에 우리 모두에게 새로운 스택이었고 공유에 효과가 더 좋았던 것 같다.

 

잘'할'점

- 아직 처음 접하는 기술스택, 개발방식을 바로바로 적용하며 개발하는 능력이 부족했다. 개발자는 늘 새로운 업데이트, 트렌드를 맞이하고 익힘과 동시에 개발해야하는 상황에 처할 수밖에 없는데 이런 경험이 아직 부족한 것 같다.

 

- 칸반보드 사용,scrum개발방식 적용을 팀원들이 원치 않았다. 무조건 옳은 것이라곤 할 수 없으나 현재 우리 단계에서는 최선의 방식이라고 나는 판단했지만 동기들을 설득하거나 강요할 에너지도 시간도 없었다. 결과론적으로 칸반보드사용, 스프린트,미팅등을 체계적으로 하지 않았기 때문에 팀 전체의 생산성이 떨어졌던 것 같다.

 

- 매번 프로젝트를 하면서 느끼는 문제점, 시간 관리이다. 이번은 특히나 처음 접하는 것들을 적용하는 과정에서 어느 기간 안에 어디까지 구현가능한지에 대한 예상이 전부다 틀렸다. 스스로의 능력과 과업의 난이도를 분석하고 주어진 기간에 따른 시간분배를 더 정확하고 효율적으로 할 수 있는 방법을 찾아봐야겠다.

소감

- 나는 기존에 Python,Django,MYSQL로 백엔드 REST ful API를 개발해왔는데 이번 회사는 Typescript , Node-ts, Express.js, Prisma, Nexus-prisma , Apollo-GraphQL등 처음 접하는 것들뿐이었다. 인턴은 내가 원하는 회사를 정해서 갔던 것이 아닌 부트캠프에서 정해준 회사로 가는 것이었고 준비기간은 토, 일 주말뿐이었으며 해당 주말도 회고, 차후 리팩토링을 위한 회의,기업사전조사등에 시간을 투자해야 했기 때문에 사전에 많이 공부해서 갈 수 없는 상황이었다. JS도 익숙지 않았던 나는 프로그래밍 언어부터 새롭게 시작하는, 처음으로 돌아가 개발을 하는 기분이었다. 개발방식, 환경, 기술 모든 것들이 낯설었다. 다만 이런 기회가 없었다면 시작단계인 내가 같은 기능을 수행하기 위해 다른 프레임워크를 사용해보며 비교해볼 일은 없었을 것이고 내가 사용하는 기술스택의 장, 단점에 대한 이해도를 높일 수 있는 기회였다.

 

- 스트레스 관리의 측면에서 스스로는 아주 잘했다고 생각한다. 인턴 기간 중 일주일 정도를 2번의 장례식, 법원 출석등 개인적인 사정으로 빠지게 되었는데 팀 전체에 부담을 주게 되어서 미안한 감정과 스스로에게 닥친 안 좋은 일들로 어려움을 겪었다. 친족과 지인이 죽는 것은 내가 컨트롤 할 수 있는 부분이 아니었고 개발자가 되어 인생을 살다보면 언젠가 또 이런 외부적 요인에 의한 문제는 생길 수 있다. 미리미리 대비 할순 없지만 주기적인 의사소통으로 팀과 협업해 나가면 팀의 부담을 줄일 수 있을 것이라 생각한다.

 

- 실패, 그 것은 특정 누군가의 잘못일까? 포스트모템이란 말이 있다. 개개인의 잘잘못을 따지기 보다는 문제해결과 근본 원인에 집중하는 것을 의미한다. 개발자는 협업하는 일이 많은 직업군이다. 그것이 개발자와 개발자 사이의 협업 또는 비개발자와의 협업 일수 도 있다. 협업해서 하는 과정과 그에 따른 성공과 실패가 있을 수 있다. 성공은 달콤해 서로 웃으며 칭찬할지라도 실패의 경우 실패의 원인을 특정 누군가에게 전가하여 마치 '범인 찾기'처럼 될 수 있다. 그러나 훌륭한, 일 잘하는 팀은 문제가 발생했을 때 잘잘못을 따지기 보다는 문제해결과 근본 원인에 집중해야 한다고 생각한다. 특정 누군가이기 때문에 발생한 문제가 아니라 그게 누구였더라도 언젠가 발생할 문제였다고 생각하고 문제를 해결하고 생산성을 개선하는 방향으로 나아감이 옳다고 생각한다.