[회고] 2023 상반기 인턴 경험

 

올 한 해를 새로운 직장에서 인턴으로 시작했다. 인턴 생활을 마무리하고 정규직에 전환이 되었기 때문에, 그 과정에서 배운 것 느낀 것에 대해 기록해보려고 한다. 주관적인 경험을 정리한 글이라 내용이 두서없고 알맹이가 없을 것이다. 

 

 🚀 이직을 하게 된 계기

지난해(2022년)에는 다니던 스타트업에서 빠져나오려 애를 많이 썼다. 작년 중순에 입사했던 스타트업은 기대와는 달리 기술력이 많이 부족했고, 스타트업 답지 않은 문화, 출퇴근 그리고 하루 만에 바뀌는 인사 청책 때문에 회사를 그만두기로 마음먹었다.

물론, 스타트업 시장이 어려워지기 때문에 허리띠를 졸라매야 한다는 대표의 말이 이해가지 않은 건 아니였다. 그렇지만 입사한 지 한 달 만에 계약 조건과는 다른 처우를 받게 된다는 것은 납득할 수 없었다. 직장을 다니며 워라밸과 복지를 최우선으로 생각하는 것은 아니지만 회사의 모든 의사결정이 소통과 합의에 의해서가 아닌 대표 한 사람의 생각에 결정되는 상황. 남아있는 것들도 하루아침에 사라질 수도 있겠다는 불안감이 들었다. 당장 퇴사를 하고 싶었다. 하지만 퇴사를 하고 이직을 준비하는 게 힘든 일이라는 걸 알고 있었기 때문에.  퇴근 후 남는 시간을 활용해 이력서를 다시 쓰고, 친구들과 취업스터디를 하고, 코딩테스트를 준비하면서 이직 준비를 하게 되었다.

 

🎉 인턴 합격

이직 준비를 꾸준히 했기 때문에 12월 즈음에는 어느정도 결과가 나왔다. 최종 합격한 두 개의 회사 중 하나는 정규직이었고, 하나는 3개월 전환형 인턴이었다. 나는 후자를 선택했는데 정규직이 아니었음에도 이 회사를 선택한 이유는 세 가지였던 것 같다. 첫째, 현재 매출을 발생시키는 비즈니스 모델이 있었다. 둘째, 자체적인 기술력으로 여러 서비스에서 성과를 내고 있었다. 세 번째, 면접을 보면서 느낀 회사에 대한 여러 이미지(면접관의 태도, 회사의 분위기 등)

막상 이직을 눈앞에 두게되니 선택을 망설이게 하는 몇 가지 요소들이 있었다. 퇴사를 작년 초에 했었는데 두 번째 스타트업을 스쳐가듯 퇴사하게 되어 커리어에 약점이 되지 않을까 하는 불안감, AI를 하고 싶어 퇴사를 하고 부트캠프를 수료했는데 백엔드 개발을 하게 되는 상황(더 이상 AI 쪽으로 커리어를 쌓을 수 없을지 모른다). 그래도 회사에 대한 이미지가 좋다는 생각과, 자체 기술을 가지고 있는 회사이니만큼 일하면서 배울 것들이 많을 거 같다는 기대감에 인턴으로 새로운 회사로 입사하게 되었다.

 

🏃‍♂️ 인턴 생활의 시작

1월 3일 부터 판교에 있는 직장으로 새로운 시작을 하게 되었다. 일주일 동안 전사 온보딩 과정을 시작했다. 온보딩 과정에서는 회사에서 영유하고 있는 사업에 관한 이야기와 직장에서 지켜야 할 예절 그리고 간단한 레크리에이션을 진행했던 것으로 기억한다. 차라리 일을 시켜줬으면 좋겠다는 생각이 들 때쯤 교육이 끝나고 개발인턴들을 위한 온보딩을 시작했다. 개발자 온보딩은 과제와 평가를 중심으로 진행되는데 3개월이라는 기간 동안, 개발역량과 협업능력, 그리고 인성을 평가하는 과정이 이였다.

 

👨‍💻 개발 온보딩

개발 온보딩 과정은 크게 두 개의 단계로 이뤄졌다. 먼저 개인 프로젝트를 진행하게 되었고 주제는 사내 주주총회에서 주요 안건에 대한 투표를 위한 백엔드 서버를 개발하는 것이었다.

이 프로젝트에서 구현해야 할 핵심 기능은 투표건에 대한 동시성제어, 그리고 안건에 대한 투표를 예약 시작하거나 종료할 수 있는 기능이었다. 개발 언어는 java, 프레임워크는 spring으로 진행했는데, 주로 개발하던 언어도 아니었고 spring은 한 번밖에 사용해보지 못해 매일같이 장애물을 헤쳐가는 기분이었다. 간단한 API를 만드는 데에도 많은 시간을 잡아먹어 한주는 거의 프로젝트를 세팅하고 gitlab에 적응하는 시간을 보냈던 것 같다.

그래도 뭔가에 집중할 수 있다는 사실이 이렇게 반가울 수 없었다. 전 직장에서는 주어진 일에 대한 확신이 없어(내가 했어야 하는 일이 팀원 그 누구에게도 필요한 일이 아니었다.) 집중이 안 됐었었다. 과제 때문에 하루하루 바빴지만, 개발을 하고 코드리뷰를 받으며 하루하루 성장한다는 느낌이 들어 행복했다.

주어진 기간 동안 겨우겨우 요구사항들을 다 맞춰서 끝낼 수 있었던 내 실력이 조금 아쉬웠다. 동시성 문제를 해결하는 데 있어서도 비관적 락을 사용했어야 하는데, JPA를 다룰 줄 모르니 DB 락이 자꾸 풀려서 하는 수 없이 프로세스락을 걸어 실행을 동기화시켰다... 나중에 프로젝트 발표 때 이 부분에서 부족한 부분을 많이 느끼게 되었다.

 

👬 팀 프로젝트

우여곡절 끝에 개인프로젝트를 마무리하고, 팀 프로젝트에 돌입했다. 개발 주제는 사내에서 활용할 굿즈 몰을 만드는 것이었는데, 선택의 이유는 내가 익숙한 구조의 백엔드 프로젝트를 해볼 수 있을 것이라 생각했던 것도 있고, 나중에 실제로 사내에서 굿즈를 판매하는 채널을 만들 계획이라고 하는데 잘하면 이 프로젝트를 이어서 해볼 수 있을 것이라 생각했기 때문이다.(아직 감감무소식이다..)

총 2개월 반동안 팀 프로젝트를 진행하게 되었다. 나를 포함해 팀원은 총 네 명이었는데 한 명이 중간에 이직을 해 네 명에서 세명으로 줄어들었다. 이번 프로젝트에서 나는 주로 상품에 관련된 모듈을 구현하는 것과 테스트 환경의 구축, CI/CD 파이프라인 구축, 인프라 설계 및 구현을 담당했다. 나이가 제일 많았던 것도 있고, 팀 프로젝트를 하며 팀장을 몇 번 해본 경험이 있어 PM 역할도 하겠다고 제안했다.

 

 

😅 PM을 하면서

PM을 하면서 이슈관리, 리스크관리, 일정관리, 의견조율 같은 일을 하였는데 이슈와 리스크야 팀원들도 개발을 하며 잘 정리해 공유하고 있었기 때문에 크게 힘들지는 않았다. 일정관리와 의견조율이 문제였는데, 주어진 작업을 정량적인 수치로 계량하고 그것을 적절한 일정으로 만드는 일은 쉽지 않았다. 결국 일정의 순서를 정하고 감각적으로 작업 일정을 추정해서 계획했는데, 일정대로 마무리되는 일이 하나도 없었다. 나중에는 참고용으로 사용을 하고 거의 업데이트도 하지 않았는데, 마감일이 다가올수록 신경 쓰기 힘들었기 때문이다. 그래도 작업 영역을 분배하는 데 있어 유용하게 사용했던 것 같다. 처음에 서로가 맡은 부분이 골고루 분배되어 누구 하나 개발을 더 하거나 덜 하지는 않았던 것 같다.(그래도 팀원 중 한 명이 개발에 열정적이어서 백엔드, 프런트엔드까지 도맡아서 구현을 했었다... 고맙기도 하고, 그 친구의 열정이 부럽기도 했다.)

 

🚧 테스트 환경 구축

테스트 환경 구축에서 통합테스트를 위한 환경을 구성하는 작업을 진행했었는데 testContainer라는 기술을 사용했다. 통합 테스트를 위해서는 애플리케이션뿐만 아니라 애플리케이션이 의존하고 있는 외부환경(DB, redis, 파일서버)이 필요하다. testContainer는 테스트 실행 시 컨테이너 형태로 외부 서비스를 만들어주고 테스트가 끝나면 다시 컨테이너를 제거하는 유용한 기능을 제공한다. 개발자 입장에서 테스트코드를 작성할 때 외부환경에 대한 고민 없이 테스트코드를 만들 수 있게 되는 것이다. 다만 이에 따른 추가적인 설정을 해줘야 하고, CI/CD 단계에서 자동화된 테스트를 해야 할 때에도 Dind 컨테이너를 사용하도록 만들어야 하는 복잡한 과정이 조금 필요하다. 하지만, 프로젝트를 하면서 통합테스트가 필요하다면, 한 번쯤 공부해서 적용해 보길 바란다.

 

🦊 Gitlab

gitlab을 이번 프로젝트를 하면서 제대로 사용해 본 것 같다. runner 세팅부터, CI/CD 스크립트 작성 그리고 jacoco를 적용해 커버리지를 확인하고 파이프라인의 스테이지끼리 어떻게 아티팩트를 주고받는지 알 수 있었다. 자동화 스크립트는 한번 잘 배워두면 써먹을 곳이 많다는 생각이 들었다. 빌드 테스트 그리고 배포까지의 단계를 자동화해 둔다면, 개발 생산성을 엄청나게 끌어올릴 수 있다. 예전 프로젝트할 때가 떠오른다. 로컬환경에서 돌아가던 애플리케이션이 배포환경에서는 잘 돌아가지 않아, 코드를 수정하고 매번 jar 파일로 빌드해 배포했던 경험이 있는데, 미리미리 공부해 뒀더라면 그때 고생하지 않았을 탠디 하는 아쉬움이 남는다. 어쨌든 이번 프로젝트에서는 CI/CD까지 한 싸이클로 돌아가는 자동화된 파이프라인을 만들었는데 사실 부족한 부분도 많다. 인프라의 변경이 생길 경우 CD 파이프라인이 영향을 받기 때문이다.

 

⚙️  예약 기능의 구현

상품의 판매 시점을 예약하는 기능을 구현하는 데 있어 골이 많이 썩었던 것 같다. 문제는 인프라를 구성할 때 서버를 이중화하기로 했었는데 특정 시점에 상품의 판매 상태를 업데이트하는 스케줄러를 구현해 문제를 해결하려 했기 때문에 발생했다. 서버가 두대일 경우 스케줄러를 돌리게 되면, 두대의 서버가 동시에 같은 작업을 하게 되는 골치 아픈 문제가 발생하게 된다. 이 작업을 어떻게 하나의 서버에서만 수행하도록 만들까 고민하다. 데이터베이스를 통해 해당 작업을 동기화시키기로 했다. 이때 shedlock이라는 기능을 활용하였다. shedlock은 예약된 작업을 수행하기 앞서 DB에 shedlock을 확인하고 해당 테이블에 내가 수행하고자 하는 작업이 등록되지 않았다면 수행하고, 반대로 작업이 등록되 있다면 수행하지 않는 일종의 작업에 락을 거는 기능을 제공하는 패키지이다. shedlock을 적용해 문제를 해결했지만, 아쉬운 부분은 스케줄 동기화를 하면서, 스케줄에 대한 작업 시간이 길어진다면, 다음 스케줄이 건너뛰어질 수 있다는 문제가 남아있었고, 프로젝트 마지막까지 남아있는 이슈가 되었다.

 

🏗 인프라 구축

인프라는 컨테이너 형태로 관리하였는데, Docker, redis, minio, nginx 그리고 서버 애플리케이션을 한 번에 관리하기 위해 docker-compose를 사용했다. 도커를 이전에도 사용했었지만, 실제로 인프라를 디테일하게 구성한 것은 이번이 처음이었던 것 같다. 인프라를 구성하며, 컨테이너 간 통신을 어떻게 해야 할지 고민을 많이 했었는데 통신이 필요한 컨테이너를 하나의 네트워크로 묶고 서로 컨테이너 이름으로 통신하는 방식으로 문제를 해결했었던 것 같다. 처음에 생각했던 방식은 컨테이너에 정적인 IP를 부여하고 이를 통해 통신을 하게 만드려고 했지만, 정적인 IP를 관리해야 하는 부가적인 작업이 발생했기 때문에, 다른 방식을 고민하던 와중 수많은 docker-compose 예제에서 컨테이너 이름으로 통신이 가능한 것을 알게 되어 동일한 방식으로 구현하게 되었다. 이번 프로젝트에서 가장 시행착오가 많았던 부분이 바로 이 인프라를 구성하는 부분이었다.

 

nginx로 서버 애플리케이션의 로드밸런싱과 무중단 배포를 구현하려고 했었다. 로드밸런싱은 nginx를 리버스 프락시 서버로 두고 nginx로 들어오는 요청을 spring boot 애플리케이션으로 1:1로 분배하도록 conf 파일을 작성했다. Blue/Green 배포 방식을 적용해 무중단 배포 환경을 구성하고 싶었지만, nginx 세팅을 변경시키는 스크립트를 짜는데 시간이 너무 많이 소요되었다. 무중단 배포도 계획했던 부분에서 끝까지 구현하지 못한 기능 중 하나여서 아쉬움이 남는다.

 

🪢 협업과 코드리뷰

좋은 협업이란 뭘까? 이번 인턴 과정에서 나는 같이 일하는 사람들과 서로 긍정적인 영향을 주고받았을까? 프로젝트를 마무리하게 될 시점에서 이런 질문들을 스스로 하게 되었다. 지금껏 개발을 하며 이렇게 능동적인 의사소통을 하며 프로젝트를 진행했던 경험이 없었다. 이전 직장에서 개발을 했을 때에는, 그저 잘 돌아가기만 하면 오케이였기 때문에, 좋은 설계 좋은 코드인지에 대한 피드백을 누구에게도 받을 수 없었다. 팀 프로젝트를 시작할 때 까지만해도 잘 돌아가는 코드를 만들면 된다는 생각이 무의식에 있었던 것 같다. 결국 그런 코드들은 필연적으로 리펙토링을 해야하는 상황이 생겼었는데, 처음 시작할 때 조금만 더 고민해봤으면, 두세번 코드를 고치지 않아도 됬을 것이다. 짦은 식견과 경험이 아쉽기만 했다.

코드리뷰에 대해서도 많은 생각을 하게되었다. 내가 짠 코드에 왜 이렇게 설계하였고 왜 이런 외부 의존성을 사용해서 구현을 했는지 물었을 때, 적절히 대답할 수 없었다. 부끄럽다는 생각이 많이 들었는데, 엔지니어로서 충분히 여러 가지 문제해결 방법을 비교 분석해 적절한 문제해결방법을 선택하는 과정이 없이, 그저 구글링을 통해 얻은 방식으로 구현하고 문제를 해결했었기 때문이다. 또 다른 사람의 코드를 리뷰해 주면서 더 나은 방법을 제시할 수 없었고, 왜 그렇게 구현했는지, 더 좋은 방법이 무엇이 있을지 충분히 제시하지 못했기 때문에 내 코드리뷰가 다른 사람에게 도움이 되지 못해 안타깝다는 생각이 들었다.

협업을 위해 정한 컨밴션도 조심성이 없는 성격 때문에 많이 실수해서 코드리뷰를 받으며 컨벤션을 지켜달라는 코멘트도 많았는데, 이건 컨밴션을 너무 스트릭 하게 잡아서 프로젝트를 진행했었기 때문이라고 스스로를 변호해 본다.

 

🏙 직장 사람들

우리는 직장을 다니며 만나는 사람들과 거의 대부분의 시간을 함께한다. 그만큼, 어떤 사람을 만나느냐가 굉장히 중요하다. 전 직장에서도 그랬지만, 인복이 있어 좋아 어디에 있던 괜찮은 사람들을 만나게 되는 것 같다. 이번에도 마찬가지이다. 이번 인턴 과정에서는 나를 포함해 7명의 동기들이 함께 인턴 생활을 보냈고 결과적으로 모두 전환이 되었다.

인턴기간 동안 재밌게 지내려고 노력했다. 보드게임도 하고 클라이밍도 가고 회식도 자주 했다. 특별한 일이 없다면 같이 저녁을 먹고 퇴근을 했다. 인턴을 하면서 다른 생각하지 않고 회사생활에 집중할 수 있었던 건 동기들과 함께 해쳐 나왔기 때문인 것 같다. 서로 코드리뷰를 하고 짬을 내서 테크톡도 하고 이런저런 구실을 만들어 놀러 다녔던 게 기억에 남는다.

 

📚 앞으로 해야 할 것

올 상반기 인턴을 하면서 많은 것을 배울 수 있었다. 백엔드 개발 역량, 협업 능력, 인프라 설계 및 구축, 커뮤니케이션, 코드리뷰 등 이번 인턴 과정이 없었다면 배울 수 없는 것들이라고 생각한다.

앞으로 해야할 일은 주어진 업무에 집중하는 것이다. 현재 팀에서는 레거시 코드를 걷어내고 새로운 기술스택을 적용하려고 한다. 최근에는 레거시 환경에 적응하기 위해 과제를 수행하고 있는데 상당히 곤혹스럽다. 레거시는 시스템은 엄청 오래되고 이제는 거의 유지보수 되지 않는 프레임워크를 사용하고 있는데, 잘 만들어진 스프링 프레임워크를 사용하다 이런 오래된 기술을 사용하니 마치 전동드라이버를 사용하다 직접 드라이버를 만들어서 쓰는 느낌이 든다. 생각보다 적응하는데 어려움을 겪고 있는데 오히려 프레임워크를 왜 사용하는지 알 수 있는 기회라고 생각하고 공부하고 있다.

블로그를 운영하며 공부하는 기술에 대한 경험을 작성하고 싶다. 인턴과정을 거치며 배운 내용들을 블로그에 정리해 두긴 했지만, 앞으로도 계속 기술적인 경험을 채워 넣고 싶다. 지금 보니 쓴 글 중에도 틀린 부분도 있고 보완해야 할 부분도 많아 보이기 때문에, 계속 다듬고 보다 양질의 정보를 제공할 수 있으면 좋겠다는 생각이 든다.