엘리스에서 현장실습으로 프론트엔드 인턴십을 진행했다.
중간에는 정리하지 못했으나, 끝난 지금 제대로 정리해보고자 한다.
진행한 일들
팀원들께서 말씀하시기를... 나는 역대급으로... 바쁠때 들어왔다고 한다.
일이 굉장히 많았고(거의 쏟아졌던...), 그래서 밤을 새워가며 개발을 하기도 했지만, 그래도 그만큼 압축적인 경험을 통해 성장할 수 있었다고 믿는다.
나는 크게 네 가지 일들을 진행했다.
1. 기존 프로젝트의 우선순위가 높은 버그 픽스들
2. 커뮤니티 기능 및 UI개선 스프린트, 버그 픽스
3. 커뮤니티 신규 기능 개발
4. 디지털 교과서를 위한 클래스룸 신규기능 개발
느낀 점
규모가 다르다.
가장 크게 느낀 부분은 규모가 다르다..! 라는 것이었다.
모듈이 10만개가 넘어가는 거대한 레포지토리에서 작업한다는 것은 토이프로젝트나 신규프로젝트만 진행해서는 절대로 얻을 수 없는 경험이다.
그러다보니 하나의 기능을 구현하기 위해, 보통은 바로 구현하지만, 이경우에는 기존에 구현되어 있는 공통 함수가 있을 수 있었다.
새로운 모듈을 만들어 utils에 추가하는 것이 좋을지, 혹은 파일에서 간단하게 구현할지도 고민해야했다.
공통 함수, 컴포넌트는 없는 것보다 관리가 되지 않는 것이 더 나쁠 수 있다.
빨라빨라빨라...
생각보다 현업의 스프린트는 매우 몹시 빨랐다.
https://youtube.com/shorts/cYhJsz2MibY?si=UQRZjEGfyiLPgoiq
정말 이례적으로 바쁜 시기였기에, 2-3일단위, 때로는 하루 단위의 스프린트도 해내야 했다.
하지만, 레포지토리나 코드 컨벤션을 온전히 숙지하지 못한 레벨에서는 그렇게 하기가 꽤 힘들었다.
문제 해결과 문제 해결의 근본적 방법도 중요하지만, 그 속도 역시 절대 무시할 수 없는 것이라는 것을 크게 느꼈다.
언제나 이상적으로 개발할 수는 없는 법이다 .
개발 하는 속도 자체를 높힐 필요가 있다고 느꼈다.
새로운 기술
규모가 워낙 크다보니 프로덕트를 쪼개서 런타임에 합치는 Module federation기술이 적용되어있었다.
이런 부분은 거의 처음 보았기에 상당히 신기했고, 시간이 될때마다 회사 코드의 설정 파일을 하나씩 까보며 이해하려고 노력했다.
나중에 규모가 작더라도 토이플젝으로 활용해볼 예정이다.
솔직한 피드백
엘리스에서 근무하며, 즐겁게 일할 수 있었던 이유였던 것 같다.
지금까지 코드를 짜고 리뷰를 받는 경우, 직접적인 피드백을 받기는 어려웠는데, 사수분께서 정말 솔직하고 명확하게 피드백을 해주셔서 한층 더 발전할 수 있었던 것 같다.
에를 들어, 이전까지는 이렇게 변경하면 어떨까요? 라고 했을 때, "아니오, 이런 부분에서 변경하지 않는게 좋을 것 같아요 " 라는 피드백을 받기는 어려웠다. 이런 피드백은 자칫하면 공격으로 받아들여질 수 있기 때문에 나도 하기 어려운 피드백이고, 다른 분들에게서는 받아본 적 없는 피드백이었다.
하지만, 공격으로 느껴지지 않으면서도 정말 솔직하고 명확하게 근거를 들어 설명해주셔서 나의 생각의 한계를 인지할 수 있었다.
덕분에 미처 생각하지 못한 부분들, 부족한 부분들을 되짚고, 더 넓게 바라보는 방법을 완전히는 아니지만, 얕게 나마 얻을 수 있었다. 그래서 굉장히 좋았다.
좋은 팀원들
개발하는 데 있어, 좋은 팀원분들을 만난다는게 굉장히 중요하다는 것을 알게 됐다.
일정이 빡빡하다보니 다들 힘들텐데도 불구하고 항상 긍정적으로, 재미있게, 함께 해쳐나가는 분위기를 만드는 팀원분들에게서 많은 힘을 얻었던 것 같다. 팀원분들에게 감사하다고 전하고 싶다.
잘했던 부분
개선을 위해
multi-starter
앞서 이야기했듯, Module Federation이 적용되어 있어 빌드시간을 단축시킬 수 있었지만, 문제도 있었다.
바로 5개 가량되는 각각의 레포지토리를 개발시에 모두 켜줘야한다는 것이었다.
속도도 속도지만, 터미널을 5개 켜야한다는 것이 많이 불편했다.
회사 코드를 통해 기여하고 싶었지만,,,
어떤 구조인지 정확히 파악하기에는 시간이 없었기에 회사 의존성과 관계없이 이런 문제를 해결해보고자 했다.
그래서 multi-starter라는 cli를 만들어 npm에 배포했고, 이런 문제를 해결할 수 있었다.
https://www.npmjs.com/package/multi-starter
multi-starter
runner for multirepo with js. Latest version: 1.1.5, last published: 2 months ago. Start using multi-starter in your project by running `npm i multi-starter`. There are no other projects in the npm registry using multi-starter.
www.npmjs.com
lint룰
처음 새로운 컴포넌트를 작성할때, 컨벤션 관련 리뷰를 거의 20개가량 받은 것 같다.
이런 부분은 신경을 써도 처음에는 놓치는 부분이 많아 사수분의 시간을 너무 많이 잡아먹는 것 같다고 느꼈다.
그래서 컨벤션과 일치하는 lint룰을 issue를 통해 제시하고, 실제로 프로젝트에 반영시켰다.
과반수가 동의해야해서 원했던 모든 것들을 적용시키진 못해 아쉽지만, 그래도 기여했다는 부분에서 의미가 있다고 생각한다.
리팩터링
빠른 개발이었지만, 그래도 시간이 남을때마다 리팩터링을 진행하였다.
그래서 복잡한 라우팅 선언과 라우팅 처리를 상수 객체 형태로 관리할 수 있게 만드는 등 개선을 이뤄낼 수 있었다.
과정에서 util타입을 만들고, 선언하는 실력이 많이 개선되었다.
이런 활동들은 직접적으로 프로덕트에 도움이 된다고 보기는 어렵지만, 프로덕트를 만드는 사람들에게 도움이 되는 활동들이다.
나는 이런 활동이 바로 눈에 보이지 않지만 궁극적으로는 프로덕트 개발에 도움을 줄 수 있다고 생각한다.
이게 내가 바로 실행할 수 있는 작게나마 성장하는 조직으로 가게 만드는 방법이라 믿는다.
그리고 이번 인턴십을 통해 이러한 활동들이 팀원분들께 좋은 영향을 미칠 수 있겠다고 느낄 수 있었고, 계속해서 해나가야겠다고 다짐하게 되었다.
조건을 놓치지 않기 위해...
내가 작업한 커뮤니티/클래스룸은 사용자의 권한에 다른 기능 제한이 꽤 있었다.
그래서 상당히 복잡한 조건문 처리를 통한 기능 제한을 했어야 했는데, 이러한 부분이 처음에 제대로 되지 않는다는 문제가 있었다.
이건 그냥 개발을 하는 것이라면 크게 문제가 되지 않지만, 위에서 말했듯 규모가 크기 때문에 이건 굉장한 시간 낭비를 야기한다.
결론부터 이야기하면 if 조건문 하나 잘못쓴 것이 15분~최대 30분가량의 시간을 소비시킨다.
개발->QA서버->프로덕션 배포 이렇게 이어지는 큰 프로세스 중, 마지막 단계, 혹은 QA서버에서 버그가 발생하는 경우, 프로세스를 처음부터 진행해야한다.
조금 더 자세히 쓰면
개발: 규모가 크다보니 개발 서버 빌드시간이 굉장히 오래걸린다.
QA서버: QA서버가 올라가기 전에 프로덕트가 build가 되어야하는데, 이 과정에서 15분가량이 소요된다.
프로덕션: 혹시라도 프로덕션에서 문제가 발생하면, rollback 배포를 한 후, 다시 배포해야하므로 시간이 거의 30분 가량 소요된다.
그래서 하나라도 꼼꼼하게 개발하는 것이 중요했다.
물론 테스트코드를 작성하고, 이를 통해 확인하면 무엇보다 좋겠지만, 마감이 얼마 남지 않은 빠른 개발, 스프린트가 필요한 과정에서 그러한 부분을 적용시키기는 어렵다.
따라서 나는 부스트캠프에서 진행했던 체크리스트를 활용했다.
1. 기능에 대한 구현 조건을 작성한다.
2. 기능을 구현 할 때마다 체크한다.
3. 모든 조건을 완전히 구현한 뒤에, 모든 구현 조건을 다시 확인하고, 빠진 것이 있다면 다시 1번부터 진행한다.
이렇게 진행했더니, 실수나, 빼먹는 조건들로 인해 발생하는 시간 낭비를 많이 줄일 수 있었다.
개선해야할 부분
체력 체력 체력...
사실 이렇게 까지 크게 다가올 문제가 아니라고 생각했는데, 굉장히 타이트한 일정이 이어지다보니 체력이 부족한게 너무 크게 체감되었다.
부스트캠프 - 창업 - 인턴십으로 이어지는 과정에서 운동을 거의 하지 않고 개발만 했더니 체력이 떨어진게 너무 느껴졌다.
일과가 늦어지면, 자는 시간이 줄어들고, 이게 다음날 영향을 미치거나, 밤샘을 한번만 해도 그 다음주까지 영향을 미치는 등...
체력이 부족해서 야기되는 문제들이 많았다.
체력이 부족하다보니 위에서 말한 피드백을 온전히 피드백으로 받아들이는 것도 어려웠고, 좋은 코드와 구조를 고민하는데도 영향을 미쳤다.
마지막엔 코로나까지... 체력을 높히는게 무엇보다 시급하다고 느꼈다.
지속가능한 개발자는 체력이 필수다.
좋은 코드란.... 뭘까
규모가 다르기 때문일까?
회사 코드와 내가 작성해왔던 코드는 스타일도 다르고, 중시하는 부분도 다소 다르다고 느껴졌다.
나의 코드는 최대한 추상화해서 나를 포함한 코드를 사용하는 개발자가 더 쉽게 사용할 수 있게 하자 가 최우선이었다면,
회사의 코드는 누가 봐도 이 코드의 맥락과 구조를 이해할 수 있게 하자 가 더 우선으로 느껴졌다. (물론 내가 전반적으로 느낀 것이고, 실제로 추구하는 것은 아닐 수 있다.)
아무래도, 어디에 무엇이 있는지 모든 팀원이 파악하기 어렵기때문에 코드를 이해하기 쉽게 파악하는게 더 중요해진 느낌...?
누군가 코드를 읽었을때, 빠르게 이해할 수 있게 코드를 작성하는 느낌이었다.
빠르게 이해해야 확장하거나 변경할 수 있기 때문이다.
그래서 내가 제안한 것들이 많이 리젝되기도 했다.
그렇다보니 어떤게 좋은 코드인가? 하는 코드에 대한 고민이 커지게 되었다.
더불어 코어한 webpack 플러그인이나 계정을 불러오는 부분 등, 사수분들과 리드분께서 작성한 코드를 보고 있다 보니,
지금까지 내가 작성한 코드들이 네이밍이나, 맥락을 파악하는 부분에서 많이 부족하다고 느껴지기도 했다.
그래서 좋은 코드란 무엇이냐?에 대한 대답을 명확하게 하기가 어렵다.
더 잘 추상화된 것일까?
다른 사람이 읽기 쉬운 것일까?
어떤게 우선순위가 더 높은지는 상황에 따라 다른 것이겠지만, 나는 아직 그 기준이 명확하게 잡혀있지 않다.
그러나 분명한 것은, 사이드 프로젝트의 규모와 이렇게 대규모의 프로젝트의 규모 차이에서 오는 기준의 변화가 분명히 있다는 것이다.
그래서 더 많은 경험이 필요하다고 느낀다.
더 다양한 환경에서, 다양한 코드를, 더 많은 사람들과 의견을 나누며 작성해보고 싶다.
조금 더 고민하고 고민해보자.
마치며
엘리스의 인턴십은 시기적으로 바쁜시기에 진행하게되어 체력적으로 많이 힘들긴했지만, 그만큼 정말 유의미한 경험을 쌓을 수 있었다.
한편으로는 내가 믿는, 팀을 위한 문제해결과 개선에 대한 믿음이 강해지기도 했고,
한편으로는 거대한 규모에서 오는 새로운 고민들을 갖게하는 좋은 기회였다.
지속 가능한 개발자가 되기 위해서는 개발 외적으로도 많은 노력이 필요하구나라고 느낀 계기이기도 했다. (운동하자.)
언제나 처럼 좋은 점은 더 살리고, 부족한 부분들은 개선하자.
다행히 나는 졸업까지 아직 1년이 남은상태다. 이건 그만큼 더 많은 경험을 쌓고, 위의 과정을 겪으며 성장할 수 있다는 말이다.
더 다양한 경험을 하고, 고민을 해나가야한다.
짧았지만 지금까지 정말 잘 대해준 팀원분들,
그리고 특히 바쁘실텐데도 바로 질문에 대답해주시고, 항상 좋은 피드백을 주시던 사수분께
감사하다는 말씀을 전하며 글을 마무리하고자한다.
