6개월 간의 프론트엔드 개발 인턴 생활 회고

🏢 입사

학부생으로서의 마지막 학기를 ICT 인턴십 제도를 통해 IT 스타트업에서 보내게 됐다.

감사하게도 여러 곳에서 좋은 소식을 들을 수 있었고, 그 중 강남에 위치한 시리즈 A 규모의 한 스타트업(앞으로 B사 라고 부르겠습니다)을 최종적으로 선택하게 됐다.

👔 환경

B사에서 나는 프론트엔드 개발 업무를 맡게 됐고, 한창 개발 중인 한 서비스의 어드민 페이지의 프론트 개발을 첫 업무로 맡았다. 내가 속한 웹 서비스 관련 팀은 약 6명의 인원으로 구성되었으며 최근 가파르게 성장하는 회사 분위기에 맞게 현 인원으로 구성된지 오래되지 않았다.

2명 정도로 팀을 구성하던 과거의 업무 방식은 더 이상 유효하지 않았고, 젊은 IT 스타트업 특유의 변화를 즐기는 분위기에 힘입어 한창 개발적으로나 문화적으로나 많은 논의가 오가고 있었다.

개인적으로는 학부 생활만 하다보니 회사처럼 개발을 통해 다양한 사람과 협업하고 이를 위해 코드를 설명하거나 문서화 하는 필요성에 대한 인식이 부족했고, 이를 겪어볼 수 있겠다는 기대가 컸다.

---

⛏️ 배운 점

☑️ 업무 프로세스와 일정 관리

소프트웨어 공학 전공을 수강하며, 사실 애자일 방법론이니 나선형 모델이니 같은 프로세스가 (지금 생각하면 참 어리석게도) 그저 이론적인 내용인 줄만 알았다.

실제 현장에 나와보니 여러 사업이 실시간으로 생성되고 그에 따른 개발 업무들이 물밀듯이 쏟아져 내려왔다. 팀의 인원과 그에 따른 리소스는 한정된 총량이 있었고, 이를 효율적으로 배분하거나 부족함을 주장하기 위해서는 정량적인 수치가 필요했다.

바로 전사에 새로운 툴이나 방식의 도입을 주장할 수는 없다. 유수의 기업들의 사례를 참고하여 내가 개발하는 프론트엔드 부분이라도 먼저 스토리를 생성하고, 이를 figma 디자인에 할당했다. 이를 기반으로 상세한 테스크를 달고 동료와 함께 포인트를 부여해 보았다. 마침 사내에서 Jira 도입에 대한 이야기가 나오고 있던 터라 스프린트에 할당된 일정 스토리 포인트 총량에 각 스토리를 맞춰 넣었다.

이런 식으로 진행해도 스프린트 일정은 제대로 지켜지지 않았다. 하지만 이런 백로그가 쌓여 점점 정확도를 높일 수 있고, 일정이 왜 늦어졌는지 더 명확하게 확인하거나 사업 일정과 개발 일정의 조율을 더 설득력 있게 진행할 수 있었다.

☑️ 각종 툴에 익숙해지기

이전까지는 github를 단순 코드만 업로드하는 클라우드 저장소처럼 사용했다. 팀원과 코드를 공유하거나 리뷰 받기 위해 또 여러 브랜치 전략을 통해 버전을 효율적으로 관리하기 위해 git을 사용한다는 점을 제대로 깨달을 수 있었다.

slack과 notion, figma, jira 등 협업을 위해 여러 툴을 사용해야했다. 이 중 jira는 팀 프로젝트에 직접 세팅하고 서비스 간 연동한 과정을 팀원들과 공유해 많이 배울 수 있었다.

storybook, jest, 부하 테스트 툴 등 개발적으로도 많은 부가적 툴을 사용해 볼 수 있었다. 개념적으로 용도를 들을 때와 내가 필요성을 직접 느끼고 검색하여 적절한 기능을 도입해보는 과정은 정말 값진 경험이었다.

☑️ 피드백과 공유

피드백과 공유는 개인 뿐만 아니라 팀의 성장을 위해 필수적이다. 개발자로서 첫 직장 생활을 통해 알게 된 것은 경력의 적고 많음과 관계없이 서로가 서로를 통해 성장한다는 것이었다.

개인적으로 찾고 배운 기술을 팀원들과 공유하며 다각적인 평가를 해 볼 수 있었고, 코드 리뷰를 받으며 잘못 알고 있었던 정보들을 깨닫고 더 발전시킬 수 있는 점들이 어떤 것이 있을지 생각하는 습관을 기를 수 있었다.

나 같은 주니어 개발자에게 타인의 코드 리뷰는 정말 값지다. 팀 내에 코드 리뷰에 대한 룰이 있고 최근에는 PR 템플릿도 정리 되었으나, 적극적으로 리뷰를 주고받기 위해 강조할 부분을 표시하거나 부가 정보를 남기는 등의 노력이 필요했다.

☑️ 엔지니어가 되기 위한 노력

입사 초기에는 단순 기능 요구를 제 시간에 충족하기 위한 개발을 한 것 같다.

하지만 여러 프로젝트를 진행하고 사업적인 이해가 성장하며, 더 큰 그림의 요구사항을 파악해 이를 어떤 방식으로 해결하는 것이 합리적일지 고민하게 되었다. 때로는 기획자와의 소통으로 기획 내용을 살짝 바꾸어 문제점을 해결할 수도 있었다.

😓 실수와 배운 점

• 컴포넌트 재사용성을 극대화하기 위해 사내 자체 디자인 시스템을 만들고자 하는 움직임이 있었다. 나도 효과에 긍정하고 좋은 기회라 생각해 개발 환경 설정을 개인적으로 꾸려보기도 하고, 프로젝트의 장기적이고 완성도를 요구하는 특성 상 나선형 모델의 프로젝트 진행 방식을 제안해 받아들여 지기도 했다.

• 하지만 이후 프로젝트 기획과 시작 초 단계에 다른 업무들과의 우선순위 문제 및 효용성에 대한 이야기가 나왔고, 시기상조가 아닌가에 대한 의견을 접했다.
• 당시에는 여러 기업들에서 바람직한 사례로 소개되고, 여러 장점에만 몰두해 도입하면 좋은 것이 아닌가만 생각했다. 그러나 최근 유행하는 마이크로 서비스도 규모와 환경에 따라 적절히 도입하는 것이 좋다는 내용의 강연을 보고 내 생각이 짧았음을 느꼈다. B사의 여러 특성들을 놓고 따져 보았을 때 디자인 시스템의 도입은 꽤 먼 훗날에나 그 쓸모가 있을 것이라는 결론을 짓게 된 것이다.

---

⌨️ Project Overview

📍B2C 서비스 Admin 제작

B2C 서비스의 통계 그래프 표출 및 조회, 관리를 위한 admin 웹 페이지

• stack
  • ReactJS, TS
  • Recoil
  • React Query
  • Styled-Components
  • Antd
• 주안점
  • 그래프와 여러 리스트, 필터링 등 각종 컴포넌트를 어떤 방식으로 생성하고, 재사용할 수 있는 구조를 생성할지

📍모바일 규격의 분석 정보 제공 서비스

회사에서 제공하는 서비스를 모바일 규격으로 사전에 정의된 특정 고객에게 제공

• stack
  • NextJS, TS
  • Recoil
  • React Query
  • Styled-Components
  • Storybook
• 기타
  • GTM, GA 연동 및 트리거 설정
  • locust를 이용한 부하 테스트
• 주안점
  • 다양한 모바일 규격에 대응
  • AxiosInterceptor를 provider화 하여 사용해 hook으로 얻은 값을 사용
  • AxiosInterceptor provider를 통해 API 및 에러 핸들링, 스낵바의 효율적 처리
  • 복잡한 케이스에 영향을 미치는 전역 변수 관리

📍csv 데이터 리포트 변환기

csv 양식의 데이터를 특정 디자인의 리포트(pdf)로 변환하는 툴

• stack
  • ReactJS
  • Recoil
  • Storybook
  • SCSS
• 주안점
  • 디자인 요구사항 충족 및 다양한 데이터 길이 및 양식에도 일치 보장
  • 사용자의 커스터마이징과 파일 저장 기능에 따른 DOM 다루기 및 스타일링

---

♟️끝으로…

개발자로서의 첫 직장 생활을 스타트업에서 시작해 시도하고 싶은 것들을 마음껏 시도하고, 괜찮으면 동료들에게 공유해 팀 문화에 기여하는 경험을 주저없이 할 수 있었다.

성장에 목마른 동료들과 정신 없이 급변하는 환경에서 함께 일 할 수 있어 더할 나위 없이 즐거운 시간이었다. 이 경험들이 좋은 개발자로의 성장에 큰 밑거름이 될 거라 믿어본다.