이전 글과 이어지는 내용입니다.
백엔드 파트장 제안
2024년 1월..
나는 이전 글에서 말했 듯이 전공 과목을 수강에 집중하고 코딩 테스트를 준비했지만 세 곳에서 인턴 서류 탈락을 한 뒤 SW 마에스트로 지원을 준비를 하며 지내고 있었다.
코테이토는 8기 활동이 어느정도 마무리 되고 있었고, 나는 같은 학교 친구들을 보러 아주 가끔 세션에 게스트로 참여했다.
8기에선 7기와 다르게 파트장과 네트워킹이라는 제도가 추가되었다.
다른 프로젝트 팀과 교류할 기회가 거의 없었던 기존의 시스템으로 인해, 동아리의 장점을 살리기 어려웠다. 따라서 8기가 되며 많은 활동들이 개편되거나 추가되었고 그 중 하나가 파트장과 네트워킹이었다.
네트워킹 시간은 파트별 부원들끼리 모여 프로젝트를 하면서 고민했던 것들이나 여러 기술 관련 얘기를 하는 시간이었다. 파트장은 이 네트워킹 시간을 주도하며 부원들에게 각종 과제를 내주는 직책이다.
당시 8기 백엔드 파트장은 같은 학교를 다니는 친한 형이었는데, 따라서 그동안 어떤 과제를 진행하며 네트워킹이 어떤 식으로 진행되는지 소식을 간간이 들을 수 있었다.
하지만 당장 1달 뒤 9기를 준비해야하는 만큼 코테이토에선 새로운 파트장이 필요했고, 당시 운영진으로 포진해있던 친한 친구들에게서 9기에 복귀하여 파트장을 맡으면 어떻겠냐는 제안을 받았다.
고민
분명 좋은 제안이었다. 15명이 되는 사람들을 이끌며 지식을 전파한다는 것은 그 어디서도 해보지 못할 경험이라고 생각했다.
하지만 한편으론 걱정이 많이 됐다. 나에게 있어 파트장이란 자리는 동아리에서 해당 파트에서 가장 역량이 뛰어난 사람이 맡는 직책이었다.
8기 파트장 형은 그러한 사람이었으며, 여러 활동들로 쌓은 경험과 특유의 꼼꼼한 성격을 기반으로 정갈하며 완벽히 문서화된 과제를 출제했으며 부원들을 체계적으로 관리하고 있었다.
반대로 나는 요구사항에 맞춰 빠르게 기능을 구현할 수 있고 동아리 사람들에게서 잘한다 소리를 가끔씩 들어왔지만, 결코 1등은 아니었다.
이런 내가 8기 백엔드 파트장 형이 해놓은 활동이나 과제들을 넘어설 수 있을까란 생각이 들었고, 내가 과연 이렇게 많은 부원들을 한 명씩 신경써가며 동아리 활동을 진행할 수 있을까라는 막연한 생각이 들었다.
또한 4학년을 앞둔 1월, 졸업 프로젝트나 앞으로 할 가능성이 있는 'SW 마에스트로' 과정과 병행이 가능할 지도 의문이었다.
운영진 친구들은 나의 이런 걱정을 듣고, 잘하는 것과 지식을 전달하는 것은 엄연히 다른 것이고 시간은 쪼개면 얼마든지 나오지 않겠냐는 말을 해줬다. 실제로 생각 해보니 나는 동아리 내에서 해커톤을 할 때면, 항상 백엔드 팀원들을 이끌었으며 모르는 부분들은 가르쳐 줬었다.
그렇게 해커톤이 끝나면 '욱트캠프'라며 사람들은 칭찬해 주었고 나 또한 그런 일들이 재미있게 느껴졌었다.
또한 가끔식 세션에 나와 8기 신입 부원들과 안면을 텄었고 그만큼 복귀했을 때 자연스럽게 어울릴 수 있을 것 같다는 말도 덧붙였다.
결국 'SW 마에스트로'를 붙는다는 가정하에 8월까지의 스케줄을 러프하게 예상해보았고, 어떻게든 시간은 낼 수 있겠다'라고 결론지었고 3월에 9기 백엔드 파트장으로서 코테이토에 복귀하기로 했다.
파트장 준비와 내가 하고 싶었던 것
이전 글에 설명했지만, 프로젝트를 진행할 수록 점점 똑같은 코드를 쓰는 것 같다는 생각을 했다. 하지만 이 고민은 분명 나만 하고 있는 것은 아니라고 생각했다. 따라서 처음 과제를 구상할 때는
처음 과제를 구상할 때는 신입부원들이 들어와 프로젝트를 하게 될 때 도움이 될 수 있도록 일종의 '백엔드 기본 패키지' 같은 느낌의 코스를 생각했었다. 하나의 시나리오를 가지고 네트워킹 시간마다 점점 고도화 시켜가는 것이다.
예를 들면 이런 느낌이다.
- 1회차
게시글, 사용자가 존재하는 게시판 프로젝트 CRUD
- 2회차
좋아요 기능, 페이징 기능 추가
- 3회차
로그인 구현 및 EC2를 사용한 배포
- 4회차
redis를 사용해서 실시간 인기 글 순위 기능
하지만 내 계획을 본 친구는 이렇게 말했다.
이런 거는 너가 가르치는게 아니라 부원들이 직접 부딪혀 가며 배워야 되지 않을까?
분명 맞는 말이었다.
개발 경험이 있는 신입 부원들에겐 어느정도 도움이 될 수 있지만, 프로젝트를 경험해본 부원이나 나의 입장에선 똑같은 일을 반복하는 것이다.
이 때 내가 작년 8월에 했던 고민이 떠올랐다.
여러 프로젝트들을 진행할수록 나의 소프트웨어적인 실력이 늘기 보다는 어느 부분에 정체된 채 매번 똑같은 플로우를 거쳐 비슷한 코드를 공장처럼 찍어내고 있다는 생각이 들었다.
저런 과제를 내게 된다면 부원들에게 내가 했던 고민을 똑같이 하게 만드는 것이나 다름 없었고 이는 기수 종료 후 부원의 탈퇴로 이어질 수 있었다. 따라서 나는 부원들이 '남들과 다른 프로젝트'를 할 수 있길 원했다.
그렇게 나는 어떤 인사이트를 줄 수 있을지 고민에 빠졌다.
그 때 전공 수업으로 수강했던 '데이터베이스' 과목을 떠올리며 어느정도 해답을 찾을 수 있었다. 교수님께서는 인덱스나 join 같은 개념을 가르치시며 '항상 데이터가 매우 많을 때를 생각해라'라고 말씀하셨고, 나 또한 앞으로 프로젝트를 하게된다면 꼭 다량의 데이터를 고려하며 진행하리라 다짐했었다.
이런 많은 데이터를 다루며 성능 개선, 정합성 관리를 생각하는 것이 백엔드 개발자로서 메리트있는 경험이라 생각했고 꼭 부원들과 함께 경험해보고 싶었다.
설령 제대로 따라오지 못해서 남의 코드를 따라치거나 검색해도 이해하기 어려워 머리를 쥐어 뜯더라도, 분명 값진 경험이 될 것이라 생각했다.
첫 번째 과제
그렇게 완성된 첫 번째 과제는 아래와 같다.
https://github.com/IT-Cotato/9th-BE-Networking-1
기본적으로 다음 과제와 연계될 수 있도록 설계했다.
첫 번째 과제는 신입 부원들이 어느 정도의 역량을 갖추고 있는지 파악하기 위해 기본적인 CRUD를 출제했다. 하지만 추후 진행할 대량의 데이터를 삽입하는 과제를 위해 주제 선정에 두 가지 조건을 고려했다.
- 부원들 대부분이 이미 친숙하거나 알고있는 분야여야한다.
- 다량의 정형화된 데이터 셋을 구할 수 있어야 한다.
그렇게 주제를 고민하던 중 2년 전 한이음에서 만난 멘토님의 말씀이 떠올랐다
그.. 지하철 도메인을 다루는 여러분은 데이터의 갯수를 고민할 필요가 없지만 우편번호 다루는 팀은 성능에 병목을 느끼더라구요
머리에 전구가 번뜩였다. 우편번호는 모든 사람들이 사용해봤으며 전국의 모든 지번 주소, 우편번 호 등과 같은 데이터를 쉽게 입수할 수 있었다.
그렇게 엑셀에서 16개의 주소 데이터를 파싱해 DB에 넣고, 이를 CRUD하는 내용의 과제를 출제했다.
다행히 모든 부원들이 제출해줬으며 여러 의견을 들었을 때, 크게 어렵지 않게 할 수 있었다고 해했다.
두 번째 과제
첫 번째 과제를 마감하니, 어느 새 시험기간이 다가와 있었다. 새로운 기능을 구현하거나 코드를 작성하는 과제는 학기 중인 부원들의 참여를 고려해 우선 미뤘다.
대신 코드 리뷰를 과제로 출제했다.
https://github.com/IT-Cotato/9th-BE-Networking-2
나는 프로젝트를 경험하며 항상 코드 리뷰를 했던 경험이 없었다. 개발 시 참고하기 위해 남의 코드를 본 적은 많으나 정작 내 코드를 보여주며 남에게 개선점을 받거나 하진 않았다.
하지만 코드 리뷰는 분명 좋은 팀 문화라고 생각했다. 당시 'SW 마에스트로' 과정을 하며 여러 멘토링을 들었고, 그 중에선 코드 리뷰 문화의 중요성을 가르치는 것이 여럿 있었다. 따라서 나 또한 해당 과정에서 코드 리뷰를 도입할 계획이었기에, 미리 간단한 과제를 통해 감을 잡고 싶었다.
세 번째 과제
드디어 내가 가장 공들였던 과제를 출제할 수 있었다. 바로 16만건의 데이터를 삽입하며 성능을 개선하는 과제였다.
물론 16만건이면 실제 운영하는 서비스라면 적은 양이라고 할 수 있다. 하지만 이정도라면 부원들이 성능 차이 라는 것을 체감하기엔 충분한 양이었다.
https://github.com/IT-Cotato/9th-BE-Networking-3
같은 백엔드 부원들이 프로젝트를 진행할 때 옆에서 지켜보면, 대부분 많은 양의 데이터를 고려하여 테스트 하지 않는다. 단순히 포스트맨으로 CRUD를 하거나 데이터베이스에 필요한만큼만 수동으로 삽입하여 활용한다.
나는 이런 방식에
지금 그 코드가 이렇게 해도 잘 돌아갈까요..?
라는 의문을 던지고 싶었다.
그렇게 삽입 시간을 단축하기 위해 Spring Data JPA의 save()와 saveAll()이 어떤 차이를 가지고, 키 생성 전략은 삽입에 어떤 영향을 주는지를 깨닫고 이렇게 배운 내용들을 블로그에 기록하는 것을 의도했다.
나 또한 해당 과제를 직접 수행하며 블로그를 본격적으로 쓰게 되었다.
네트워킹
네트워킹 시간에는 주로 과제에 대한 얘기를 하며 시간이 남는다면, 한번 쯤은 고민해봤을만한 내용에 대해 조사한 것을 얘기하거나 과제에 대한 피드백을 서로 주고받았다.
예를 들면
- 키 생성 전략은 항상 Auto-Increment로만 해야할까? 내가 직접 랜덤한 값을 지정하면 안되나?
UUID나 TSID를 소개
- 한 화면에 여러 도메인의 정보들이 필요하다면 화면 단위로 정보를 보내주는 것이 맞을까?
조사 결과, API를 분리하는 것이 여러 면에서 유리, Backend-For-Frontend라는 개념을 소개
- 한 부원이 과제에서 @Async를 적절치 못하게 사용
비동기, 동기 개념에 대해서 설명
결론
그렇게 지난 주 데모데이 앙케이트에서 내 이름에 몇 번 나왔다. 대부분 네트워킹과 관련된 칭찬이 적혀있었다.
시간을 쪼개 준비한 것들이 보람차게 느껴진 순간이었다.
작년 초, 아무 것도 모르는 3학년 신입 부원이었던 내가 어느새 부원들을 이끄는 역할을 맡고 이제는 코테이토를 떠나며 취업을 준비하고 있다.
'같이 성장하자!'라는 가치관을 가진 동아리인 만큼 나도 분명히 성장하였고 작년 5기에 같이 들어온 사람들 중 일부는 훌륭한 기업에 들어가 직장인으로서의 삶을 살고 있다.
나 또한 올해 초 소프트웨어 전문가 양성 프로그램인 'SW 마에스트로' 연수생에 선발되었으며 프로젝트를 실제 런칭까지 하며 매우 많은 것을 배우고 있다.
2022년 12월에 코테이토에 귀찮다며 서류를 제출하지 않았더라면, 면접날 늦지 않기 위해 서둘러 옷을 갈아입고 택시를 타지 않았더라면, 과연 이렇게까지 성장할 수 있었을까?
언젠가 훌륭한 개발자가 된다면, 부원이 아닌 데브톡 연사로서 세션에 다시 한 번 와 1n대 파트장과 만나고 싶다.
