📍 Intern Review

안녕하세요! 대학생 프론트엔드 개발자 Garden, 오소현입니다.

저는 대학교 마지막 학기를 유튜브 마켓팅 플랫폼을 서비스하는 스타트업에서 프론트엔드 개발 포지션으로 근무하였습니다:)

지난 6개월동안 학부에서만으로는 접하기, 시도해보기 힘든 기술들을 많이 접해볼 수 있는 좋은 기회였기도 하고 6개월은 모든 기술을 학습하기에 부족한 시간이라 많은 아쉬움이 남기도 합니다. 지난 상반기를 회고해보며 배우고 느낀점, 그리고 성장한 점을 작성해보려고합니다.

🤔 Part 1. 무엇을 배우고 느꼈을까?

[1] OJT, 새로운 기술 학습

저는 입사 전 React를 주로하고, FastAPI로 API 연동, 그리고 상태관리는 대부분 React Hooks를 쓰거나 전역으로 관리할때는 Redux로만 개발해 본 경험이 있는 상태였습니다. 개발을 시작한 2023년도에는 협업 프로젝트 여러개를 계속했었기 때문에 익숙한 기술을 사용해서 빠르게 프로덕트를 내는데 집중했었었습니다. 저는 회사에 입사해서 다양한 프론트엔드 기술 뿐만 아니라 백엔드/인프라까지 경험해볼 수 있었습니다.

회사에 입사해서 첫 한 달은 OJT를 진행했는데 이때, 사내 DevOps, Data Engineering, Backend, Frontend 각 분야 기본 교육을 받았습니다.

대표적으로 위와 같은 기술들을 학습했고, 특히 프론트엔드 개발만 해봤던 저에게 입사 후 백엔드부터 인프라까지 학습해볼 수 있어서 정말 좋은 경험이었습니다. 이때 도커와 쿠버네티스를 배울 때, 데브옵스 영역에 관심을 가지게 되어서 더 나아가는 공부를 따로 하기도 했었는데요! AWS를 전체적으로 공부해보고 싶어서 자격증에도 도전해, 저는 CLF라고 불리는 AWS FOUNDATIONAL 자격증을 취득하기도 했습니다🎉

또한 GraphQL이라는 기술을 접하면서 하나의 EndPoint에 여러 API 요청을 보낼 수 있고, 필요한 정보만 요청할 수 있다는 장점을 경험하면서 FastAPI만 경험해본 저에게 사용성이 높은 기술을 사용해 더 빨리 개발할 수 있었습니다.

[2] 기획부터 새로운 기술 도입까지, 개인 프로젝트

첫 달 OJT가 끝나고 사내 API를 활용한 개인 프로젝트를 한달이라는 시간동안 과제로 진행했었습니다.

기획을 경험하다.

저는 학부생일때 특히 많은 애정을 쏟았던 비대면 재활치료를 돕는 웹서비스 프로젝트에서 프론트엔드 개발 뿐만 아니라 모든 기능에 대한 기획을 진행하고, 의료진에게 자문을 구하면서 기능을 고도화했던 경험을 했었습니다. 이때 좋은 기획이란 무엇일지 고민하면서, 도메인에 대한 이해, 그리고 사용자 경험을 고민했던 기억이 개발자에게도 내가 개발하는 기능에 대한 오너십을 가질 수 있었던 기억으로 남아있었습니다. 따라서 저는 저희 사내 서비스에서 기획해 직접 개발할 수 있었던 개인 프로젝트의 한 달이 매우 행복했습니다.

사내 서비스가 "유튜버"와 "광고주"를 도메인으로 유튜브 마케팅 플랫폼이었고, 해당 시기에는 "광고주"를 겨냥한 기능이 많아서 "유튜버"를 대상으로 한 서비스를 개발하고 싶었습니다.

평소 좋아하던 유튜버 판교 뚜벅쵸님을 보면서 내 채널을 직접 광고주에게 어필해 효과적인 광고 마케팅을 이끌고, 내 채널 분석 데이터를 기반으로 내 채널 리포트(광고제안서) 를 생성하는 서비스를 개발했습니다.

서비스는 간단하게 아래의 사진들과 같습니다 :)

1. 내 채널 레포트(광고 제안서) 생성	2.나에게 딱 맞는 광고주 찾기 (매칭 시스템)

이때의 개발 개인 프로젝트 내용 및 회고 글은 사내 데이터로 사이드 프로젝트하는 인턴이있다?! 에서 자세하게 읽어보실 수 있습니다 :)

이 프로젝트를 기획하고 개발하면서 위에서 언급했던 즐겨보는 유튜버 판교 뚜벅쵸님과 커피챗도 했던 좋은 경험이었습니다 🥳

이후로, 저희 사내 서비스에 제가 개발한 이 프로젝트와 비슷한 더 고도화된 서비스인 유튜버를 겨냥한 "내 채널 리포트" 서비스가 공식적으로 출시되기도 했습니다🎊🎊 내 채널을 자세히 분석해주고, 주 1회 레포트를 생성해 이메일로 보내드리는 서비스이니, 유튜브 운영하시는 분들은 꼭 사용해보세요 :)

👏🏻 Vling 내 채널 리포트 바로가기 👏🏻

서비스를 기획해보고, 직접 개발해보는 경험을 통해 개발자로서 내가 개발하는 기능에 대한 애정을 갖고, 기획서만 보고 개발하는 것이 아니라 개발하는 서비스에 대한 이해와 오너십의 중요성을 크게 가질 수 있었던 시간이었습니다.

공부하고 싶었던 기술 도입

저는 개인 프로젝트를 개발하면서 평소 해보고 싶었던 기술을 공부해보고 싶었습니다. 해당 기술들이 사내에서 도입해 사용하고 있지는 않았기 때문에 개인 프로젝트때 도입해 구현하게 되었어요!

디자인 패턴 기반 한 스토리북 도입 및 구현과 cypress를 사용해 개발물을 사용자 관점에서 테스트 하는 방법인 E2E(End-to-End)를 구현하게 되었습니다.

한 달이라는 짧지 않은 시간이 주어졌었기 때문에 공부해 보고 싶었던 기술을 학습하고 직접 구현하면서, 기능 구현에만 초점을 맞추지 않고 코드 품질을 높기 위해 고민한 시간이어서 의미있는 시간이었습니다. 😀

[3] 본격적인 업무 시작!

2달간의 전체적인 온보딩 프로그램이 끝나고, 프론트엔드 개발자로 본격적인 업무를 시작하게 되었습니다.
팀 리더 Harry와 사내 운영성 업무를 제외한 저의 개발 로드맵을 2가지를 설정하게 되었는데요!

1) 사내에 스토리북을 도입해 세팅 및 배포함은 물론 기존 컴포넌트 요소들을 스토리북에 배포하고,
디자인 팀과 사내 디자인 시스템 구축
2) 프론트엔드 테스트 (E2E) 를 맡아 Playwright를 사용해 사내 테스트 코드 구현 및 자동화 업무를 맡게 되었습니다.

저는 4개월 동안 사내 서비스 운영성 업무를 중심으로 진행하지만 해당 로드맵 2개를 병행했습니다.

Main. 사내 서비스 운영성 업무 (서비스 개발)

서비스 개발 업무를 받을 때마다 해당 기능의 기획자, 디자이너, 타 개발자 분들과 함께 협업하면서 해당 기능을 출시하는 프로세스를 겪으면서 협업과 소통의 중요성을 배웠습니다.

그리고 출시 후에 유저들의 피드백, 그리고 기능을 더 고도화해서 해당 기능에 대한 N차 고도화 개발하는 경험을 통해 해당 기능에 대한 오너십을 가지게 되었습니다. 엄마의(?) 마음으로 제가 출시한 기능이 문제가 없는지 자주 들어가보고, 사용자 amplitude 이벤트를 주기적으로 모니터링하면서 보게 되었습니다.
또한 직접 써보면서 더 나은 사용자 경험을 위해 기획자, 백엔드 개발자와 고민하면서 계속해서 기능 검토, 결과로 개선해 나가면서 더 좋은 서비스를 만들어나가고자 함께 노력하는 경험을 했습니다.

이 과정에서 느낀점은 유지보수의 경험이 얼마나 중요한지 알게 되었고, 출시 때만 집중하고 버그가 나야 파악하게 되는, 즉 내 개발 기능에 대해 잘 돌아보기 힘들었던 것을 반성하고 돌아보게 되었습니다.

모두가 사내 서비스에 애정을 가지고 더 나은 서비스를 고민하면서 시작부터 출시, 그리고 N차 고도화 경험까지 정말 뜻깊고 개발자로서의 자세를 다시 바로 잡아주었던 업무 경험이었습니다.

RoadMap 1. 사내 디자인 시스템 구축

현재 atomic 디자인 패턴을 기반으로 개발된 atoms 컴포넌트들을 바탕으로 구현되어있는 사내 개발 환경에 스토리북을 도입하여 개발되어있는 컴포넌트들의 UI를 빠르게 확인할 수 있는 UI 문서를 만들었습니다.

이때 사내 모노 레포 환경에서 스토리북 초기 개발 세팅 부터 스토리 파일이 인식하게 하는 다양한 기술세팅에 대한 러닝 커브가 일주일 동안 진행되어 생각보다 오래 하게 되었었습니다. 인턴을 마치는 시점에서도 스토리 파일 내부에서 next 기술을 몇개 사용하지 못하는 작은 기술 부채가 몇 개 남아 있는 상태여서 더 아쉬웠던 것 같습니다.

세팅 후 기존 atoms 컴포넌트를 스토리북에 UI문서를 만들고, 템플릿 스토리 코드를 구축하고 난 다음에 본격적으로 디자인 시스템을 구축하면서 사내 디자인 팀과 함께 재사용성이 강하도록 컴포넌트를 새로 다 엎고, 가이드라인을 논의하면서 디자인 시스템을 잡아갔습니다.

디자인 시스템이 사내에 처음 구축되는 것이라서, 사이드 프로젝트에서 디자인 시스템을 개발한 수준보다 더 체계적으로, 많은 공부를 병행하면서 이렇게 해보고 저렇게도 해보고 많은 애정이 쏟아진 로드맵이었습니다.

디자인 시스템 1차가 완료되면 따로 사내 디자인시스템 개발 후기를 작성할 예정이지만, 공부에 가장 많이 도움을 받았던 것은 타사의 디자인 시스템 기술 블로그와 세미나 영상 거의 모두를 보고 분석한 과정이었던 것 같습니다. 이때의 정리한 기술 내용을 사내에 적용하는 과정에서 그리고 사내 개발 상황에 맞게 디자이너, 그리고 팀 리더 Harry, 팀 선배 개발자 디자인 시스템 고민을 함께 해주신 Glen과 논의를 하면서 현 상황 가장 효율적인 시스템을 잡아갔던게 큰 도움이 되었습니다.

RoadMap 2. 사내 통합 테스트 자동화 구축

사용자 경험을 우선으로 하는 테스트 케이스를 고려해 자동화 시스템을 구축하는 업무인 해당 업무에서는 저희 사내에서 인증, 결제의 테스트를 필요로 하는 기능들에게 대해 우선적으로 테스트코드를 도입하게 되었습니다.

e2e 테스팅 툴인 Playwright로 선정하는 것 부터, 사내 서비스 인증 기능에 대해 테스트 코드를 구현하였습니다.

저희 서비스에는 크게 2가지 방법으로 계정이 관리되고 있습니다. 바로 Google 로그인과, 사내 서비스 자체 로그인 방법인데요, 저는 여기서 사내 서비스 자체 인증에 대한 여러가지 테스트 시나리오에 대한 테스트 코드를 완성했습니다.

이 업무에서 어려웠고, 가장 배운 것이 많았던 점은 바로 Playwright로 e2e테스트를 통해 구글 로그인 테스트 코드 구현이었습니다. Google OAuth를 쌩으로 다시 구현해보면서 Google 로그인 인증에 대한 테스트 코드를 구현하는 과정에서 러닝 커브가 매우 높았습니다. Playwright에서 E2E 테스트로는 구글 봇에 감지되어 다운되는 걸 대응하기가 어려웠었는데, Playwright 동작에 대한 이해가 필요하다는 생각이 들어서 Playwright 오픈소스까지 뜯어보게 되었습니다.

열심히 Playwright 내부에서 테스트 환경이 돌아가게 되는 것을 공부하면서 문제를 해결하게 되는 힌트를 많이 얻은 것은 아니었지만, 그래도 제가 사용하게 되는 기술 자체의 동작 프로세스를 이해하는데 매우매우 큰 도움을 받았습니다. 이 과정에서 좋은 기회로 인제님의 도움을 받아 Playwright에 오픈소스 기능 기여를 하게되어서 정말 뜻깊은 업무였습니다. 오픈소스 기여 회고는 나의 첫 오픈소스 기여!! (feat. 인제님, Playwright 🎭),
드디어 병합된 Playwright PR!
에서 자세히 볼 수 있습니다!

해당 업무를 겪으며 새로 도입하는 기술에 대한 러닝 커브, 구현을 해쳐나가는 집념이 크게 생겼고 혼자 고민하는 과정이 길어지기도 해서 아쉽기도 했지만, 개발자 스스로 성장에는 많은 도움이 되었던 업무였습니다.

🌱 Part 2. 이외로 더 성장한 점?

저는 앞선 업무들을 하면서 배우고 느낀점을 포함해 6개월간 개발자로 많이 성장했습니다.
배우고 느낀점에 대해서 가장 많이 성장했지만 개발자로서의 자세도 그에 못지 않게 개선된 점을 소개합니다.

[1] 🐛 버그, 러닝커브에 대응하는 자세

지금 생각하면 조금 웃기긴 하지만 이때는 엄청 진지했었던 버그를 대하는 자세가 개선되며 올바르게 잡혀갔습니다.

처음에 입사하고 출시한 기능에 대해서 버그가 발생했을 때 개인적으로 멘탈도 많이 나가고, 자책을 많이하면서 대응을 하고는 있지만 난 왜 저럴까 ㅠㅠ 후회를 많이 했었습니다. 이때 버그 원인 파악도 지금보다 많이 걸리기도 했고, 발생 원인에 집중해서 대응에 시간 투자가 길었습니다.

하지만 이를 극복하려면 제가 버그가 발생하지 않도록 개발해야하는데 이는 불가능하다는 것을 깨달았고, 최대한 많은 예외처리 현상을 개발 시기에서 고려할 수 있도록 경험치와 꼼꼼함이 중요하다는 것을 느꼈습니다. 이후로 초반보다 버그에 대응하는 자세가 유연해지고, 발생했던 버그 케이스에 대해 대응 회고하면서 나만의 테스트 케이스 문서를 기록하기 시작했습니다. 다음 비슷한 기능 출시에서는 해당 경험치들을 통해 버그를 점차 줄여나갈 수 있도록 하는 개발자가 되어갔습니다.

입사 전에는 협업을 잘하는 개발자가 되고 싶었는데, 이제는 예외 사항을 잘 고려하는 개발자가 되고 싶습니다 🥹🤔

[2] 결과를 먼저, 자주 출시/배포하기

사람의 욕심은 끝도 없다고 하죠? 저도 개발하면서 더 잘하고 싶은 마음, 더 완성도 있게 내고 싶은 마음이 크게 있는 개발자입니다. 하지만 이런 욕심과 마음은 업무의 시간을 더 길게 가져가는 큰 리스크가 되었는데, 점차 내려놓고 업무의 결과를 자주 배포하며 1,2,3 .. N차 지속하는 개발자가 되었습니다.

스스로도 각 회차마다 점차 고도화되는 기능을 비교해서 파악할 수 있었고, 보다 짧은 호흡으로 개발을 하면서 집중도와 결과 개선도가 높아지게 되었습니다.

Part 3. 인턴을 마치며,,,

저는 지난 6월로 인턴을 마치고 이후 행보를 다음과 같이 결정하게 되었습니다. 바로 정규직 연장 제의를 수락해 이어서 회사와 함께하는 것으로 결정했습니다:)

인턴을 하면서 스스로 너무 부족한 점이 많은 것을 크게 느껴서 공부를 더 해야할 것 같다는 생각도 많이 했었지만...

하지만 현업에 나왔기 때문에 경험할 수 있었던 모든 것, 업무로 받아 더 열심히 공부했던 6개월이기도 했었고, 제가 진행하고 있던 여러 업무들, 그리고 성장을 이끌어주셨던 CTO Ethan, 팀리더 Harry, Glen, David 그리고 제 동기 Sera 에게 많이 감사하고 함께 또 더 좋은 서비스를 만들고자 결심하게 되었습니다. 그리고 이제야 회사 전체적인 개발 환경에 대해 제대로 알아가고 있었기 때문에 더 퍼포먼스를 내고 싶은 아쉬움이 가장 컸습니다.

인턴 생활을 회고해보니, 회사 입장에서 바로 업무에 투입하도록 하는 것이 바람직하였을 것 같은데 인턴 생활 초기 2달을 거의 공부하는 환경을 만들어주셨어서 감사한 마음이 들었습니다. 회사가 인턴을 많이 배려해주신 덕분에 저는 마음껏 공부하고 업무를 시작할 수 있었습니다. 개인적인 성장을 많이 믿어주시고 응원해주셔서 이 자리를 빌어 감사하다는 말씀을 드립니다 :)

인생에서 이때의 인턴의 경험은 개발자로서 현업에 나가기 전에 많은 도움을 받았습니다.
현업과 학부는 많이 달랐고, 그동안 개발을 해온 것이 크게 도움되어 작용되지는 않았다고 생각합니다.
그만큼 다시 시작하는 마음으로 많은 것을 배우고 기술적으로, 협업적으로 성장한 경험이었습니다.

다시 학교에서 프로젝트 했던 작년으로 돌아간다면 서비스를 빠르고 여러 개 만드는 도전 보다,
프로덕트 하나를 출시하고 유지보수를 해보는 경험을 가지거나 기능을 더 고도화 하는 경험을 가져보는 경험을 더 많이 하고 올 것 같아요 :)

현재는 위의 디자인 시스템, 통합 테스트 구축 업무 2개를 그대로 이어서 더 고도화하는 작업을 진행하고 있습니다. :)
본격적인 신입 프론트엔드 개발자 회고는 다음 포스팅에서 이어서 작성해보겠습니다!

마지막으로 항상 잘 해낼거라고 믿어주시고 아낌없이 도와주시는 팀원분들인 리더 Harry, Glen, David, 동기 Sera 그리고 저희 회사 모든 구성원 분들에게 큰 감사함을 전하며 회고를 마치겠습니다. 인턴 Garden 안녕!