2년차에 접어들며,,, (feat. 주니어개발자 회고)

갓생.. 누구나 원하는 그 타이틀
저도 얻어보고자 올 한해 이런저런 목표를 세워보았으나 현실은 회사에서 야근이랄까요,,,

직장 생활

작년 1월 개발자로 첫 커리어를 시작해 중간에 이직도 하고 얼레벌레 회사를 다니다 보니 벌써 2년차에 접어들고 있습니다.
전 아직.. 말하는 감자인데,,,

솔직히 지금 다니는 회사는 정말 가끔 있는 야근을 제외하고는 꿀인 편에 속한다고 생각합니다. 일정으로 압박을 주는 사람도 없고 프론트 개발도 혼자라 제가 하고싶은대로 하면 됩니다..

클린 코드..? 개발 효율..? 코드가 거지같아도 아무도 지적해주지 않습니다..

그치만,,, 전 잘하고 싶은걸요,,,ㅠ

물론 백엔드 개발자 두분께 서버쪽 지식은 정말 많이 배우고 익혔습니다. 하지만 프론트 개발에 대한 조언을 구할 선배개발자의 부재가 점점 크게 느껴지기 시작했습니다. 누구나 개발을 할 수는 있지만 '잘'하기란 쉽지 않은 것 같습니다.

저희 회사의 경우 정말정말,,, 레거시한 코드를 쓰고 있는데 이걸 어떻게 수정하면 좋을지에 대한 방향을 아무도 제시해주지 않아 처음에 약간 힘들었습니다..^^ 코드만 봐도 담당자가 정말 여러번 바뀐 걸 알 수 있었고, 코드컨벤션이라는 게 따로 존재하지 않았습니다.

그래서 혼자 이리저리 삽질하며 개선해보고자 노력했던 점들에 대해 작성해보고자 합니다.

1. git flow 정리

요청사항을 하나씩 착착 개발해서 순서대로 배포할 수 있다면 얼마나 좋을까요. 하지만 모든 일이 그렇듯 중간에 "그거 말고 이거 먼저 해주세요" 라던지 열심히 만들던 기능 개발이 갑자기 중단되는 일은 비일비재합니다. 바로 직전에 개발하셨던 분은 한 브랜치에서 모든 걸 작업하셨는지 짜다 만 코드, 반영이 아직 안 된 기능들이 전부 들어가있었습니다. 하하

그래서 입사 후 첫번째로 작업한 건 git flow를 정리하는 것이었습니다. 실제 운영페이지에 반영하기 전, 운영팀에서 테스트할 수 있도록 연결해둔 branch가 있었는데 위와 같은 이유로 운영과 테스트의 싱크가 하나도 맞지 않아 사실상 정확한 테스트가 불가능한 상황이었습니다. 그렇다고 이걸 운영이랑 똑같이 맞춰두자니 배포 안된 기능들이 아직 남아있고...

그래서 제가 선택한 방법은 기존 브랜치는 참고용으로 두고 새롭게 development 브랜치를 만들어 운영 branch와 싱크를 맞추는 것이었습니다. 그 후 앞으로 모든 개발 프로세스는 아래와 같이 가져가겠다고 공지했습니다.(당돌)

운영팀 요청 -> 기능별 branch 생성 -> 완성 후 development 브랜치 반영 -> 운영팀 테스트 -> 운영 branch에 merge

입사한지 1주일된 주니어가 냅다 기존 걸 바꿔버리면 안좋게 생각하실 수도 있을 것 같아 현 프로세스를 유지할 경우 계속해서 발생할 문제점과 위와 같이 개선할 경우 얻을 수 있는 이점에 대한 보고서를 작성해 제출했습니다. 필요하다면 발표도 할 생각이었지만, 감사하게도 윗분들께서 운영팀에서 미리 테스트할 수 없는 부분에 대한 문제점을 이미 인식하고 계셨고 현재 운영 사이트에 영향을 미치는 것이 아니라면 얼마든지 바꿔도 좋다고 해주셨습니다.

2. 프론트엔드 협업 가이드 작성

어짜피 혼자 개발하는데 가이드가 필요합니까 라고 생각할 수도 있지만, 저의 경우 처음 입사했을 때 인수인계 하나 없는 상태에서 코드를 파악하는 데 정말 많은 시간을 소요해야 했기 때문에 이후에 생길지도 모르는 저의 동료개발자(아직 희망사항일 뿐이지만,,^^)를 위해서라도 협업 툴을 설정하고 가이드를 작성해야겠다는 생각이 들었습니다.

✅ 코드 작성 순서 정의
한 컴포넌트 내에서 여러 함수와 스타일링을 정의할 때 작성하는 순서를 정의했습니다.

✅ 네이밍 컨벤션 정의
기존 네이밍은 일관성이 전혀 없어 파일 하나를 찾는 데도 많은 시간이 걸렸는데요, 따라서 정말 기초가 되는 네이밍컨벤션(파일명, 상수데이터, 함수명, 변수명 등)을 정의하고 적어도 제가 작성하는 부분만큼은 컨벤션을 지켜 개발하려고 하고 있습니다. 정말 예전에 개발자로 일을 시작하기도 전에 네이밍컨벤션에 대한 글을 작성한 적이 있었는데 그땐 그냥 써야한다니까 그런가보다~ 하고 작성했던 내용이 이제서야 와닿기 시작합니다.
(그 때 작성한 글 - 네이밍 컨벤션 바로가기)

✅ 주석 활용하기(with jsDoc)
처음 전달받은 코드는 주석이 정말 단 한줄도 없어서 기능에 대한 설명은 고사하고 현재 사용되는 기능인지 아닌지 조차 알 수가 없었습니다. 개인적으로는 타인에게 저의 코드를 설명하기 위해서도 있지만 향후 유지보수를 위해서도 주석을 잘 활용하는 것이 중요하다고 생각합니다.

jsDoc은 전직장에서 정말 잘 활용했던 건데, 공통 컴포넌트를 생성할 때 주로 사용했던 기억이 납니다. 여러 곳에서 사용되는 컴포넌트일 수록 props에 대한 간략한 설명을 작성해주었을 때 어떤 컴포넌트인지 더 쉽게 파악이 가능하다고 느꼈습니다. 물론 지금은 저 혼자 개발을 하고 있긴 하지만 향후 유지보수, 또는 이후 협업하게 될 개발자를 위해서라도 주석을 활용하고자 마음먹었습니다.

✅ prettier 및 eslint 설정하기
사실 eslint와 prettier가 설정되어 있지 않은 프로젝트는 처음이라 조금 놀랐습니다. 입사 첫날 코드를 받고 vscode로 열었을 때 빨간색으로 된 파일명들이 미친듯이 떴던 걸 잊지 못합니다. 알고보니 css 작성시 세미콜론(;)이 빠진 부분들이 정말 많았고 그대로 git에 올라간 결과였습니다. 잠깐.. 그럼 해당 style은 적용이 안되었을텐데 이게 그대로 올라가 있었던걸까요..? 하지만 저희 회사는 디자이너도 없기 때문에 원래 작성하고자 했던 style이 무엇인지 조차 파악하기 어려웠습니다.🥲

또 따옴표와 쌍따옴표가 혼재되어 있어 이부분을 통일할 필요성도 느꼈습니다. 따라서 prettier, eslint를 설정하고, 적용 방법에 대한 가이드를 작성해 팀원들에게 공유하였습니다.

작성하고 보니 굉장히 기본적인 부분들이지만, 저 또한 누군가가 초기 세팅해놓은 프로젝트 구조 내에서 얌전히 개발해보았던 경험만 있었기에 직접 문제점을 느껴보고 해결해 볼 수 있었던 좋은 기회라고 생각합니다.

3. 리팩토링에 대한 고찰

현재 회사 프로젝트는 Next.js 9와 클래스형 컴포넌트로 이루어져 있습니다. "레거시는 무조건적으로 리팩토링하는 게 좋을까"라는 주제의 글을 본적이 있는데, 레거시코드가 때로는 필요하기 때문에 그대로 두는 경우도 있다는 내용이었습니다. 맞는 말이라고 생각했습니다. 또 위에서 작성했듯이 인수인계가 없었기 때문에 마음대로 코드를 수정하기엔 위험부담이 있었습니다. 이유가 있어서 그렇게 작성했을 수도 있으니까요.

하지만 Next.js 9는 우선 너무 옛날 버전이고 Image 태그 등의 제가 기본적으로 알고 있는 Next.js의 기능들을 전혀 사용하지 못했습니다. 또한 연결되어 있는 npm 패키지들이 매우 옛날 버전이고 심지어 마지막으로 업데이트가 7년전인 패키지들도 사용하고 있었습니다. 안정성을 위해서라도 업데이트된 패키지를 사용할 필요가 있다고 느꼈지만, Next.js 9와 호환이 되지 않는 패키지들도 있었습니다.🥲

따라서 next.js의 버전을 업그레이드 해야겠다고 마음 먹었습니다. 처음에는 app router를 사용해보고 싶은 개인적인 욕심에 next.js 13으로 업그레이드 하는 것을 고려했으나, 기존의 pages router를 app router로 변경하는 것 자체에 엄청난 시간이 소요될 것 같아 현재 고민중입니다. 버전을 정하고 업그레이드를 진행하게 된다면 이와 관련된 포스팅을 따로 작성하도록 하겠습니다.

자기 계발

안그래도 웹프론트엔드에 대한 기술이 뒤쳐진다고 느끼던 중 회사에서 앱개발을 맡게 되었습니다.

이걸 저 혼자요..?

어찌저찌 개발은 마쳤지만 앱과 디바이스에 대한 기초지식도 없이 말그대로 동작하게만 만들어둔거라 이걸 제대로 된 앱이라 말할 수 있을까에 대한 의문이 계속 들었습니다.

사수가 있었다면.. 아니 최소한 비슷한 연차의 프론트엔드 개발자가 한명이라도 있었다면 피드백이라도 요청할 수 있지 않았을까? 모든 개발에 대한 고민과 결정을 혼자 해야한다는 점이 이제 막 1년을 채운 주니어로써는 벅찼던 것 같습니다. 기술적인 고민을 나눌 수 있는 동료개발자가 있으면 좋겠다는 생각이 점점 간절해졌습니다.

1. 사이드 프로젝트

그래서 시작했습니다 사프!

(따란~!)

개발쪽이 트렌드가 빠르긴 하지만 프론트엔드 개발은 특히 더 트렌드에 민감한 분야라고 생각했습니다. 회사에서 레거시코드만 만지다가 최근에 nextjs 14가 나왔을 땐 약간 위기감도 느꼈던 것이 사실입니다.

또 최근에는 앱개발만 하다 보니 웹프론트엔드에 대한 감각(?)이 점점 떨어지는 듯한 느낌이 들어 올해 초부터 사이드프로젝트를 알아보기 시작했습니다.

제가 사이드 프로젝트를 고른 기준은 다음과 같습니다.

✅ 디자이너 유무
현 직장에는 디자이너가 없어 매우 어려움을 겪고 있어 이 부분을 가장 먼저 보았습니다.

✅ 현직자의 비율
웹프론트엔드 개발에 대한 트렌드를 익히고자 시작하는 사이드프로젝트인 만큼 다른 회사에서는 어떤 기술들을 사용하고 어떤 흐름에 맞추어 개발을 하는지를 서로 공유할 수 있는 현직자들이 많았으면 하는 바람이 있었습니다.

✅ 프로젝트에 투자해야 하는 시간
스펙업을 위한 과정이긴 하지만 그래도 1순위는 현직장의 업무이기 때문에 일에 영향을 끼칠 정도로 시간을 많이 투자해야하는 프로젝트는 전부 걸렀습니다. 2번에서 현직자의 비율을 따진 부분도 재직중인 분들이 많다면 직장과 병행할 수 있을만한 프로젝트일 것이란 생각이 들어서입니다.

✅ 서비스 정식 배포 여부
포트폴리오용으로 배포만 하고 끝날 프로젝트보다는 이후에 실제로 운영될 서비스에 참여하고 싶다는 생각이 강하게 들었습니다.

위의 네 조건을 만족하며 실제 결제연동까지 해볼 수 있는 프로젝트에 지원했고, 지난주부터 합류하게 되었습니다.
막상 참여하고 보니 꽤나 본격적인 프로젝트 규모에 놀랐고, 또 설렜습니다.

(특히 잘 짜여진 피그마 디자인을 보니 마음이 편안해졌습니다.. 디자이너 없는 회사에서 일해본 개발자분이 계시다면 공감할 것입니다.🥲)

아직은 개발을 더 진행해봐야 알겠지만 정기적인 미팅을 통해 의견을 조율하고 사람들과 협업하고, 기술적인 공유가 이루어지는 과정이 너무너무 즐겁습니다! 잘 마무리해서 서비스가 정식배포되는 그날까지 열심히 참여해보고 싶습니다!!

2. 운동💪

저의 경우 작년 8월 헬스를 시작해 지금까지 해오는 중입니다. 살기위해 시작한 운동인데 점점 재미를 붙여가고 있습니다.

개발자들이 가장 싫어하는 말이 "님 개발자같아요" 라고 하죠. 저는 다른 일을 하다가 개발직종으로 넘어왔는데, 그때도 개발자 하면 체크무늬남방에 안경을 쓰고 약간은 조용한 이미지가 떠올랐던 게 사실입니다.

하지만 막상 개발세계에 입문해보니 운동도 열심히하고 옷도 잘입는 힙스터 개발자들이 매우 많더군요. 공대출신 친구는 최근 들어 자기관리를 열심히 하는 개발자들이 많아진 거라고 하는데 아주 좋은 징조라고 생각합니다.

특히 요즘은 정말 운동을 열심히 하는 개발자들이 많이 보이는 것 같습니다. 거북목과 말린 어깨를 조금이나마 펴보기 위한 노력일까요?(일단 저는 그렇습니다..)

개발도 운동도 열심히 해서 튼튼발자로 거듭나는 것이 저의 올해 목표입니다!

Summary

• 프론트엔드 개발자로서의 고민과 고찰.. 그래도 노력중ㅠ
• 사이드 프로젝트 열심히!
• 운동도 열심히 튼튼발자💪