개발자로서의 첫 사회생활 경험기(부제: 인턴십 회고)

Yeshin Lee
7 min readAug 9, 2022

--

올 4월은 최근 들어 최고로 바쁜 달이었습니다. 42 서울 마지막 과제를 진행하면서 이력서와 포트폴리오를 끊임없이 다듬으며, 면접을 보았습니다. 심지어 휴가 중에서도 말이죠. 과연 내 스펙으로도 뽑힐까 했지만, 감사하게도 ‘진학 어플라이 채용 전환형 개발 인턴십 2기’에 합격하여 5월부터 7월까지 총 3개월간 인턴십 진행했었습니다. 후에 팀장님께 뽑아주신 이유를 여쭤보니, 열심히 할 것 같은 사람들을 뽑았다고 하셨습니다.

개발 직군으로 전직하고 시작하는 첫 회사 생활이라, 더욱 궁금했고 떨렸습니다. 인턴십 기간 동안 하루하루가 굉장히 소중하게 느껴졌기 때문에, 일주일 단위로 내 생각을 다른 블로그에 기록했습니다. 후에는 주 초반의 기억을 까먹어 퇴근하는 길에 하나씩 썼던 기억이 있습니다. 그 수 많은 기록 중, 인상 깊었던 에피소드나 제 생각을 공유해보겠습니다.

그 당시 공부한 기록들과 느꼈던 감정이 담긴 게시물들.

0.

모르면 모르는대로 한다.

이번 주 내내 vue.js로 to do list를 만들면서 가장 많이 되새겼던 말이다. 인턴 시작 전에 ‘잘 그리기 금지’와 저 문장을 접하게 되어 정말 다행이라고 생각한다. 내 순서 전에 끊겼지만, 오늘 코드리뷰하는 시간을 가졌었는데 확실히 동료들과 하는 것과는 다르게 느껴졌다.

1.

금요일날, 노트북을 지참할 수 있게 됐을 때 오랜만에 프로젝트 회의를 진행했다. 한 분이 Nest.js를 사용해본 소감을 물어봤었는데 인상적인 질문이어서 적는다.​

보통 자바스크립트를 공부하고 그 후에 node.js를 공부하고 프레임워크로 express를 공부한다. 그리고 type을 명시하는 타입스크립트를 공부하고 그 후에 express 상위 버전인 Nest.js를 공부하는데, 나의 경우 여기와서 es6를 처음 공부하다 보니 위에서 아래로 내려가는 방식으로 공부하고 있었다. express를 알았다면 nest.js를 좀 더 쉽게 이해하고 공부할 수 있었지만 돌아가는 방식이 크게 다르지 않아 재밌다.

2.

프론트엔드 팀이 바쁘기도 하고 인턴 분들 중에 내가 vue를 제일 모르는 것같아, 로그인과 회원가입 페이지는 내가 담당해서 기능 구현하기로 했다. 로그인과 회원가입은 굉장히 일반적인 로직을 따르고 있기 때문에 UI만 프로그래머스를 따르고 어렵지 않게 만들 수 있었다. 이 과정에서 피그마라는 툴을 처음 사용해봤는데, 좀 더 정교한 파워포인트 같달까. 팀원 분이 로그인 시, 아이디와 비밀번호 중 뭐가 틀렸는지 알려줬으면 좋겠다고 해서(!) 이전 면접때 들었던 피드백을 그대로 들려드렸다. ‘둘 중 뭐가 틀렸는지 안다면 해커가 그 것만 팔거예요!’

3.

service에서 find 옵션을 쓰는 방법도 있지만, DB에 관련된 작업은 repository에서 처리한다고 하여 일일이 querybuilder를 이용해 반환값을 보내주고 있었다. 그렇게 뚝딱 뚝딱 하고 있는데, query parameter오 받는 catID가 ‘수시’인 경우를 고려하지 않았던 것을 커밋 후에 알았다. ‘정시’라면 정시와 관련된 데이터만 보내주면 되는데, ‘수시’는 수시뿐만 아니라 수시 시즌에 이뤄지는 전형들 전부 보내줘야한다. 조건 자체는 정시를 제외한 모든 value를 보내주면 되기 때문에 어렵지 않았다. 호기롭게 case-when-then을 사용했는데, then에는 조건(catID != ‘정시’)이 들어갈 수 없다는 것이다. if-else 를 사용했을 때 또한 조건을 넣을 수 없었다. 안에 where를 넣어야하나? 싶어 넣어도 실행되지 않았다. 동기에게 물어보니 service에서 find 옵션을 사용해서 조건을 주는건 어떠냐고 했다. 그러면서 왜 repository에 query를 만들어서 하냐고 물어봤는데, (핑계지만) 퇴근 10분 전이라 머리가 돌아가지 않았다. DB CRUD를 repository 에서 하는 거라고 말하긴 했는데, 나 또한 의문을 가지게 되었다.

여기에는 경험으로 느껴지는 답변이 달렸는데, 생각해보면 디자인 패턴과 연관있는 것 같다. 어쩌면 createQuerybuilder도 결국은 리소스를 잡아먹기 때문에, 소요시간이 find보다 길어질 수도 있으니까. 테이블을 조인하지 않고 하나의 테이블에서 컬럼 값을 갖고 오는 service는 find 옵션을 써도 될 것같다. 내일 가자마자 바꾸면서, catID 조건을 어디서 처리하고 어떻게 처리할지 고민해야겠다.

4.

TypeORM은 진짜.. 후.. 쉽지 않다. 아냐, 공식문서를 전부 다 읽지 않기도 하고 sql에 익숙하지 않으니 그럴 수 있다. 이런 어려움들을 기억해 성장의 양분으로 삼아야지. TypeORM 외에도 service에서 find 옵션으로 찾거나(get method 한정), 쿼리를 직접적으로 작성하는 경우(connection.query) 그리고 prisma까지 다양하지만, 그나마 좀 써봤다는 이유로 TypeORM을 사용하고 있었다. 새롭게 바뀐 반환값에 따라 이번에는 직접적으로 connection 생성자를 service에 쿼리를 넣어보았다. 그렇게 좋아하고 있었는데, parameter 를 식별할 where 조건에서 에러가 나는 것이다. 이거때문에 괜히 엄한 곳에 이슈를 남겼다가 호다닥 지우는 일이 생겼다.. 일단은 반환 형식이 중요하므로 필터링은 무시한채 넘겨주기로 했다.

5.

인턴십 마지막 날, 코드 리뷰를 받는 중 JWT token은 보통 cookie에 저장한다고 하셨다. 기존에는 누가 이 데이터를 필요로 하는지가 중요하다고 하여 localStorage에 저장했는데, 피드백을 바탕으로 localStorage와 cookie 중 어디에 저장할지에 대한 이야기가 나왔다. (지금 생각해보면 내가 검색했을 때는 JWT token에 대한 언급이 없다.) 팀원들과 토론하고 보니 기존에 알고 있던 것들 조차 헷갈려 찾아보다가 httpOnly() 옵션을 주어 cookie에 저장하는 것으로 결론이 났다.

비록 정규직 제안에는 거절했지만, 새로운 기술을 습득하는 것 외에 다양한 경험을 할 수 있어 뜻깊은 3개월이었습니다. 프로젝트 회고 때, 바꾸는 것과 여러 시도를 해보는 것을 두려워하지 말아라, 최적의 방법을 찾아나가라는 팀장님의 말씀이 기억에 남습니다. 그동안의 기억을 떠올려 앞으로의 성장을 위해 돌아보았습니다.

Keep

  • 매주 무엇을 공부했는지 개인 블로그에 회고 글을 작성하였다.
  • 문제를 해결한 후, Jira에 간단하게 포스팅했다. 후에 같은 문제를 접했을 때, 빠르게 해결할 수 있었다.
  • 할 일의 우선순위를 설정하여 계획한 대로 실행할 수 있었다.

Problem

  • 출퇴근 거리와 퇴근 후에도 과제를 진행했기 때문에, 체력의 한계를 굉장히 많이 느꼈다.
  • 프로젝트를 진행하면서 팀원 간 말이 달라 소통의 오류가 종종 있었다.
  • 기능 구현보다 최적화에 초점을 둔 경우가 있었다.
  • 업무에 집중하지 못했을 때 종종 자책감을 느꼈다.

Try

  • 다음 주부터 PT를 시작하기로 했다. 그리고 일주일 중 하루는 확실하게 쉬는 것으로 결정했다.
  • 나 혹은 상대방이 요구 사항에 대해 제대로 이해하고 있는지 꾸준히 기록하여 상기시킨다.
  • 마음에 안들더라도 일단 동작하게 만든다.
  • 집중이 잘 되는 때와 잘 안될 때를 파악하여 그에 맞는 업무를 진행한다.

--

--