[회고] 늦었지만 외주를 해보고 작성해보는 회고!

오늘은 회고록을 한번 쭉 써보려고 한다. 사실 Velog에서 썼었다가... 기획 노출로 손해배상 청구를 받아서 바로 비공개 처리를 했었다. 다행히 청구는 받지 않았다.. 휴!

 

처음에는 이게 기획노출인가? 싶었지만 그런 사소한 거 하나가 걸릴만 했던 것 같다.. 이 부분에 있어서는 너무 죄송하게도 생각하고 잘 몰랐던 것 같다. 그 때는 너무 무서웠ㄷr...  어쨌든 이제는 내가 잘못된 부분을 확실하게 알았으니 다시 다듬어서 조금 써보려고 한다.

 

외주를 어떻게 시작하게 되었는지?

사실 외주(아웃소싱)라는게 신입(학생)들이 해보기는 어려운 경험이라고 생각한다. 나도 이 때까지만 해도 외주를 해보고 싶지만 할 수 있을까? 라는 생각을 했었다. 왜냐면 크몽같은 사이트에서 보면 거의 대부분이 경력직만 구하기 때문이다. 당연히 돈이 걸려있으니깐!

필자는 약 2년 조금 넘게 UMC라는 앱런칭 연합 동아리에서 몸을 담구고 있었는데, 동아리 관계자분이 추천을 해주셔서 한번 지원을 넣어봤었고 합격하게 되어서 외주를 참여할 수 있는 기회를 받았다.

 

필자는 동아리에서 2번 정도 외주를 받아서 진행했었다. 지금부터 간단하게 어떤 외주를 받아서 했는지, 어떤 기술을 썼고 후기는 어떤지에 대해서 정리해보려고 한다.

 

GRIDGE 기능 개발 외주

[기술 스택]

TypeScript, NestJS, MySQL, TypeORM, Swagger, AWS, GitLab, GitLab CI/CD Pipelines

 

서비스 명을 밝힐 수 있는 것은 지금 운영중인 서비스이기 때문이다. 혹시나 주니어, 신입분들이 외주를 한번 해보고 싶다라고 생각되면 GRIDGE로 들어가셔서 살펴보시면 좋을 것 같다!

 

GRIDGE는 IT 프로젝트 작업자 실시간 자동 매칭 온디맨드 클라우드 플랫폼이다. 필자는 어드민 페이지 API 기능 개선, 작업자와 의뢰자의 포인트 대시보드 개발 그리고 포인트 대시보드를 기반으로 일일 및 정산 보고서 변환 기능 구현에 참여했다.

 

특별한 라이브러리를 사용하지는 않았다. 필자가 처음으로 NestJS를 접한 계기가 되었다. 단순 기능 구현이기 때문에 내가 구현해야 하는 기능에 맞춰서 추가적으로 테이블 설계를 진행했으며 Swagger를 통해 API 문서화를 진행했다. 그리고 GitLab CI/CD Pipelines 통해 배포 자동화를 진행했는데 직접 Pipeline을 구축한 것은 아니고 CTO님이 구축을 해놓으셨다. 필자는 CTO님과 따로 미팅을 잡아서 배포 자동화를 어떤 식으로 구현하셨고 어떤 Flow로 진행되는지 정도만 알게 되었다.

 

필자는 해당 외주를 시작으로 가장 의미있었던 경험이라고 생각했던 계기는 코드리뷰, API 문서화였던 것 같다. 왜냐면 이전에 6개월 간 스타트업 인턴을 다녔을 때 이런 코드리뷰, API 문서화 그리고 커뮤니케이션이 진짜 거의 1도 없었던 회사였다. 물론 기술적으로 배운 것도 있는 회사생활이었지만, 개발 문화적으로는 조금 아쉬웠던 회사였다. 나중에 기회가 된다면 시간이 좀 지났지만 인턴 회고록도 작성해보도록 하겠다.

 

이 외에 다음과 같은 것들을 경험했던 것 같다.

- Slack을 활용한 에러 모니터링

- Squad와 활발한 커뮤니케이션

- CTO 님과의 GitLab PR & 화상통화를 통한 코드리뷰 및 Convension, 브랜치 전략 논의

- Swagger를 통한 API 문서화

- 배포 자동화에 대한 개념 --> 추후에는 직접 Pipeline을 구축해보고 싶다.

- 실제 회사를 다니는 것처럼 업무를 배당받아서 스프린트 기간 내까지 기능 구현을 해야한다는 책임감..?

 

반려동물 전용 소셜 커뮤니티 외주

[기술 스택]

JavaScript, Express, MySQL, AWS(EC2 Bastion, LB, CloudWatch, Certificate Manager), GitHub Action + Code Deploy CI/CD

 

참고로 아직 배포가 되지 않은 것 같아서 서비스 명은 공개하지 못할 것 같다. 필자는 총 2번 계약을 하게 되었다. 처음에는 기존에 1차로 작업되고 있었던 코드가 있어서 2차 개발에 참여했고, 다음 계약 건에서는 배포 전 QC 과정에 참여하게 되었다.

 

필자가 작업하고 경험한 내용은 다음과 같다.

- 랭킹시스템 기반 후원금 페이백 제도 기능 구현

- 스케줄러를 활용한 포인트 지급 및 알림 기능 구현

- 회원가입 시 친구 추천 기능 구현 (추천 알림, 포인트 지급 등)

- 관리자 페이지에 필요한 API 구현

- 다양한 AWS 서비스 및 CI/CD 사용 경험 (DevOps 쪽에서 구현을 해주셨고 필자는 소통을 통해 수정이 필요한 부분은 수정했습니다)

- 부적절하게 사용되었던 반복문 순회, transaction, Promise.all 등을 리팩터링 한 경험

- 이후 전체 테이블 설계 수정 및 QC 과정 진행

 

개발 기간이 조금 길었던 만큼 경험했던 것들이 생각보다 많았던 것 같다.

 

필자가 기획 유출로 논란이 되었던 부분은 어려웠던 내용을 작성하면서 문제가 되었었다. 랭킹시스템 기반 후원금 페이백 제도 관련인데 이 부분을 해결했던 경험이 인상적이어서 전체적인 Flow와 해당 기능을 구현하기 위해 커스텀했던 함수? 를 일부 노출을 했는데 문제가 되었던 것이다.

 

가장 작업하면서 힘들었던 부분은 랭킹시스템 기반 후원금 페이백 제도 기능을 구현할 때 많이 어려웠던 것 같다. 일단 로직을 이해하는데 진짜 1주일은 사용했던 것 같고 새벽마다 PM님이랑 Google Meet으로 오래 얘기했던 기억이 난다..

 

이 외의 어려웠던 작업: 코드분석과 QC과정

이 전에 스타트업을 다닐때도 같이 들어온 입사 동기랑 퇴근 후에 잠깐 코드 분석 스터디를 할 정도로 양이 방대하고 어려웠던 기억이 있는데 역시나 코드 분석은 어려운 것 같다. 직접 작성한 코드가 아닌 동료 개발자가 어떤 의도로 코드를 작성했는지 봐야 하는데 눈에 잘 들어오지도 않을 뿐더러 시간이 많이 소요되었던 것 같다.

 

확실히 하나 느낀 점은 코드 분석을 하기 전에 필히 DB 설계를 꼼꼼하게 봐야할 것 같다는 생각이 들었다. 인턴할 때는 무작정 코드를 먼저 봤는데 이번 외주에서는 DB 설계도부터 보기 시작했다. 확실히 코드부터 먼저 냅다 보는 것 보다는 DB 설계도를 같이 보면서 분석하는 것이 훨씬 더 시간적으로도, 작업적으로도 효율적이라고 생각했다.

 

그리고 QC과정에 참여해봤는데 역시.. 내가 작성한 코드는 항상 옳지 않다고 생각하고 끊임 없이 의심을 해봐야 한다고 뼈저리게 느꼈다. 필자가 작업할 때는 괜찮았는데 QC과정에서 여러개 오류가 발생하더니 멘탈이 나갔다 ㅎ.. 

 

그리고 이전 작업자 께서도 API 문서를 최신화 하시지 않은 점도 있었고 등등 다양한 이슈들이 많이 있었다. 그래서 QC과정도 필자에겐 조금 힘들었던 경험이었다.

 

그래도 이런 경험을 해봤다는 것은 분명 나에게 도움이 될만한 것이라고 생각한다 :)

 

느낀점

먼저 신입 개발자로서 나름 체계적인 외주를 경험해 봤다는 것에 있어서 뜻깊은 경험이라고 생각한다. 개발만 하는 것이 아니라 실제로 고객사 쪽이랑 미팅을 해본 경험도 있었는데 이런 경험을 언제 해보겠나... 고객사에서도 개발자 분이 계셔서 이런 부분은 수정해주고, 이런 부분은 또 다르게 작성할 수 있을 것 같다는 등등 피드백도 다양하게 받아보았다.

 

그리고 아키텍처 같은 경우에는 필자가 따로 요청을 해서 업로드해도 되는지 여쭤보고 가능하다고 하시면 업로드를 할까 한다. 어쨌든 다양한 서비스를 사용해봤다. AWS 그리고 배포 자동화를 사용해 본 것이 기억에 많이 남았다. 취준생은 프리티어로만 작업하기 때문에 AWS의 다양한 서비스를 사용하지 못하니깐! (아니 근데 뭐 용돈에서 쪼꼼만 보태서 쓰는것도.. 이젠 괜찮을지도?)

 

확실히 취준하면서 아르바이트 대신에 외주로 용돈을 벌어 보는 것도 정말 좋은 경험이었던 것 같다. 기회가 된다면 꼭 한번씩 해보는 것도 좋은 것 같다.

 

한 가지 우려되는 점은 이제 첫 번째 외주 같은 경우에는 자회사의 서비스이기도하고 CTO님이 계셔서 주기적으로 코드리뷰를 받아서 괜찮다고 판단되었는데, 2번째 외주 같은 경우에는 코드리뷰를 받을 수 있는 환경이 아니었다. 그러다 보니까 A개발자, B개발자 .. 여러 명의 개발자들이 거쳐가면서 코드도 복잡해지고, 유지보수하기 힘들어지게 코드가 작성이 되었는데 고객사 쪽에 해당 코드로 구현된 프로젝트를 넘겨도 되는지가 조금 우려되었다.

 

하지만 이 부분은 필자가 고려할 수 있으면 좋지만 여건이 되지 않기 때문에 넘어가도록 하겠다.