ft_transcendence를 마치고

(구)트센과 (신)트센

작년 12월 즈음이었나, 한 카뎃이 트센이 바뀐다는 얘기를 해외 42로부터 들었고, 42서울 페다고지 채널에 해당 내용을 문의하면서 그 내용을 알게 되었다.

(구)트센의 경우, 집현전 스펙과 거의 90% 유사해서 사실 (구)트센을 하면 나 혼자 백엔드를 맡는다 해도 한 달이면 끝낼 자신이 있었다. 그런데 솔직한 심정으로는 그러면 재미가 없을 것 같아서 (신)트센을 맛보고 싶었다.

42 서울 특성상 운영한지 거의 4년? 5년? 정도 된 걸로 아는데, 그 기간 동안 수많은 코드들이 제출되었을 것이고 그걸 바탕으로 대대로 학습해온 카뎃들은 코드가 어느 정도 정형화되어있는 것을 느꼈다. 당장 과제 평가만 하러 가도 “… 이런 알고리즘 사용하셨죠?” 라고 물어보면 다들 “네.” 라고 하니까. 정말 극소수만이 본인만의 근거로 평가를 받는 상황이었다.

그런 상황에서 나에게 트센 과제 변경은 반가운 상황이었다. 어차피 장고로 바뀐다 한들, 파이썬은 예에에에전에 해본 적도 있고 바닐라 스크립트를 사용한다 해도 자바/타입 스크립트 경험에 jQuery도 써봤으니 상관 없었다.

과제를 하면서 들었던 생각

팀원이 싸울 때 어떻게 중재를 해야할까?

이게 제일 큰 걱정거리였다. 초반부에는 우리도 화기애애했어서 싸울 거라는 생각을 못했는데, 결국 싸우는 팀원이 생기기 마련이다.

우리 팀은 두 번의 마찰이 있었는데(내가 모르는 곳에서 더 있었을 수도..?), 첫 번째 마찰 때에는 일단 둘을 분리해서 한 명씩 돌아가면서 이야기를 들었고 서로 원하는 바를 확인했다. 그리고 그 원하는 내용을 내 나름대로 조심스럽게 전달해서 둘이 잘 마무리하는 걸로 해결이 됐었다.
두 번째 마찰 때에는 프로젝트 후반부였는데, 그때는 서로 참지 않는 듯한 느낌이었다. 그래서 첫 번째 마찰 때보다 더 강도 높은 말싸움이 오갔고, 심지어는 서로 작업한 내용에 대해 깎아내리는 발언까지 나왔다. 처음에는 지켜보다가 이건 아니지 싶어서 내가 “그런 말은 하지 말자”는 식으로 말했고, 다른 팀원분도 함께 말렸다. 결국에는 그 둘은 직접적으로 소통하지 말고 다른 팀원을 통해 소통하는 것으로 마무리가 됐다.

두 번째 마찰 때 들었던 생각이 화를 한 번 내볼까였다. 다른 사람들이 보는 앞에서, 심지어 다른 팀원들은 코드를 치고 있는데, 그곳에서, 본인들 감정 상한다고 대놓고 말싸움을 하는게 과연 보기 좋을까? 차라리 나가서 둘이 싸우는 거였으면 몰라도. 적어도 싸울 거면 나가서 싸우라고 화라도 내볼까 싶었다. 그때 당시에는 괜히 안 좋은 분위기 기름 붓기 싫어서 조용히 말했는데, 진작에 싸움을 중재가 아닌 강제로 중지시켰다면 서로를 깎아내리는 말까지는 나오지 않았을까 싶다.

싸움 중재하는 건 너무 어렵다…

제발 API 명세를 잘 하자

초기의 스웨거

난 항상 API 명세를 작성하는 입장이었는데, 이번 과제에서는 프론트와 백엔드 둘 다 해보니 프론트 입장에서도 더 많이 생각해볼 수 있는 기회가 되었다.

프론트엔드 입장에서는 신뢰할 수 있는 API 명세 문서가 우리 프로젝트에서는 스웨거인데, request 예시나, response 예시가 다 안 적혀 있거나, 깃허브 프로젝트에 정리해둔 내용과 다른 경우가 있었다. 그때 솔직히 짜증났는데, 처음 하는 사람들이니까 그럴 수 있지하고 넘어갔다.

아무리 깃허브 프로젝트에 정리를 해둔다 한들, 실제로 백엔드에서 보내주는 응답값은 스웨거에 명시된 대로이다. 따라서 나는 깃허브 프로젝트에 정리된 내용을 보면서 하는 걸 원치 않았고, 스웨거에 명시된 내용을 바탕으로 하는데 스웨거가 제대로 작성되어 있지 않으면 난감하다.

여담으로 파일 업로드 스웨거 작성하는 데 파일 업로드 버튼이 나타나지 않아서 그거 하는 데 시간 꽤 쏟았다. 테스트도…

production 모드와 develop 모드를 나누는 데에는 이유가 있다.

나는 prod, dev 모드를 나누는 데에 적극적으로 찬성하는 게, 분명 개발용에서 더 자세하게 봐야할 내용이 있을 것이고 개발용에서만 동작해야하는 기능이 있을 것이다. 그런데 그 두 가지 모드를 분리하지 않으면, 오히려 개발할 때 불편하다.

일례로 우리는 도커 컨테이너를 prod와 dev로 따로 나누지 않았다. 그래서 백엔드를 돌리는 방법을 모르는 프론트 분들은 전부 도커 컨테이너를 띄워서 개발했는데, 데브옵스로 컨테이너가 여러 개 추가되다보니 컨테이너가 꽤 무거워졌고, 컨테이너를 한 번 띄우는 데 n분이 걸리게 되었다.
그렇다면 내가 자그마한 수정사항이 생겨도 컨테이너 다시 내렸다 올려야하는데, 그걸 n번 반복한다면? 상상만해도 짜증난다.

그래서 나는 이 n분 걸리는 것 자체가 스트레스라 그냥 로컬에서 백엔드 실행하고 프론트엔드 실행해서 했고, 야매로 prod, dev 모드를 만들어서 뚫어두었다.
백엔드 실행 방법도 깃허브 위키에 다 적어서 두었는데, 프론트 분들이 보시기엔 어려웠나보다…

제발 테스트를 작성하자

백엔드 테스트는 django.test를 사용했다.

프론트엔드는 테스트는 playwright를 사용했다.

부끄럽지만 난 프로젝트를 하면서 이번이 처음으로 내가 만든 기능들에 대해 온전히(백엔드 기준) 단위 테스트를 작성해 보았다. 테스트를 작성하며 느낀 점이 몇 가지가 있었는데, 다음과 같다.

1. 이 함수가 내가 의도한 대로 제대로 동작하는지 굳이 print를 하지 않아도 알 수 있다.
2. 디버깅 단계가 줄어든다.
3. 로직적인 오류는 잡아주지 못한다.

특히 1번과 2번 내용에서 감탄이 나왔는데, 이 함수가 단위 테스트를 통과함으로써 함수 자체는 잘 동작한다는 걸 알았으니, 디버깅 단계에서 그 함수가 잘 동작하는지는 볼 필요가 없다.
그리고 3번의 경우, 내가 테스트를 작성할 때 테스트 로직 자체를 잘못 생각하면 테스트는 통과되었는데 내 의도대로 함수가 동작하지 않는 경우가 있었다. 이런 경우는 100% 내 과실이라 할 말은 없다.

난 어디까지 손을 대야 하는 걸까

사회에서 나는 주니어지만, 이 팀에서는 시니어의 역할을 맡았다. 그러면서 많은 고민들이 생겼었는데, 그 중 하나가 “내가 어디까지 손을 대야 하는 걸까?” 였다.
회사였다면 일단 마감을 해야하니 못하겠으면 내가 하겠다 하고 다른 사람의 내용을 가져갈 명분이라도 생길텐데, 여긴 배우는 곳이다. 내가 그 사람의 몫을 가져가버리면, 그 사람은 학습을 하는 데 지장이 있을 수 있다.
그래서 차분히 기다리며 나는 코드들의 부분적으로 부족한 부분을 채워나가거나, 코드 리뷰 시 코멘트를 남기는 등 거의 고문에 가까운 역할이었던 것 같다.

사실 막바지에 게임 로직에 대해서는 다들 하고 싶어하지 않는 것 같아서 게임 로직은 내가 작성했다.

질문에 대한 답을 하는 나만의 방법

위에서 말했든 이 팀에서 시니어 역할의 풀스택을 맡아서 프론트와 백엔드로부터 많은 질문을 받았었다.
나는 “… 어떻게 구현해요?” 같은 질문을 받으면 답을 하는 일종의 프로세스(?)가 있다. 그 방법은 레이튼 교수 시리즈의 힌트 코인이랑 비슷하다.

레이튼 교수 게임 시리즈의 힌트 코인. 힌트를 단계 별로 준다.

첫 번째 단계에서는 그 기능을 구현하는 데 필요한 핵심 개념만 말한다. 그리고 그 개념에 대해 찾아보도록 유도한다.
두 번째 단계에서는 그 기능을 응용하는 방법을 알려준다. 그 개념을 가지고 어떤 식으로 활용할 수 있는지를 말한다.
세 번째 단계에서는 그 개념을 이용하여 본인이 원하는 기능을 어떻게 구현할 수 있는지를 말한다. 이 단계에서는 거의 사실상 답을 주는 거나 마찬가지다.

대학 다닐 때부터 시험 공부 시켜줄 때 써봤던 방법인데 나름 괜찮던 방법이었어서 지금까지도 쓰고 있다. 보통 감을 잘 잡는 사람들은 첫 번째 단계에서 개념을 찾아보다가 “아” 하면서 구현하는 사람들이 있고, 일반적으로는 두 번째 단계에서 마무리가 되는데, 세 번째 단계까지 가는 경우는 잘 없었다.

챗 GPT에 의존하는 것은 좋지 않다

나는 처음엔 챗 GPT를 옹호하는 사람이었다. 내가 코딩을 처음 시작했을 때 한글로 구글링하다 안 되면 영어로 구글링하고, 그래도 없으면 유튜브에서 영상 찾아보고 하면서 소비한 시간들을 단축할 수 있는 훌륭한 도구라 생각했다.
그런데 요즘 42 커뮤니티 내 모습을 보면 챗 GPT가 오히려 사람이 생각할 수 있는 능력을 방해한다는 생각이 든다. 내 착각이라면 다행이겠지만, 뭔가 오류가 발생했을 때, 트레이스를 읽어보거나 로그를 확인하지 않고 터미널에 출력된 내용을 그대로 긁어서 바로 챗 GPT에 붙여넣기하여 질문하는 모습을 자주 봤다.
점점 인간의 생각하는 능력을 상실해간다는 느낌이 들어서 조금은 불쾌했다. 차라리 챗 GPT가 없었던 때가 나았던 것 같다.

conflict를 두려워하지 말자

깃을 사용하다보면 conflict가 발생하는 경우가 있다. 그런 경우, resolve를 해주면 그만이다. conflict가 무서워서 작업 순서를 미룬다든가 등의 일은 없었으면 한다.

그리고 멘토님의 조언으로는 테스트가 있다면 conflict에 대한 두려움을 낮출 수 있다고 한다. 이건 테스트 작성이 띄엄띄엄 되어 있었던 것도 영향이 있었던 것 같다.

끝으로

42 서울의 공통 과정에서 가장 마지막이자 가장 큰 과제인 ft_transcendence를 끝냈다. 끝나고 난 이후의 기분은 덤덤하다. 그렇게 기쁘지도 않고, 화가 나지도 않고, 그저 과제 하나를 끝냈다는 기분 뿐이다.

오히려 아쉬운 점들이 남아있긴 하다. 게임 중 나갔을 때 다시하기 기능이라든가, 구현할 때 시간 상의 이유로 잘려나간 기획들이라든가. 더 잘 할 수 있었을텐데 하는 생각이 들어서 결과물이 크게 만족스럽진 않았다.

깃허브 CI/CD도 좀 더 적극적으로 이용해볼 걸 싶다. 다들 테스트를 작성했다면, 해당 app에 대한 테스트를 통과해야만 main 브랜치에 merge 할 수 있게 한다든가.

큰 마찰도 몇 번 있었지만, 그럼에도 끝까지 책임지고 프로젝트를 마무리한 팀원들이 고맙고 자랑스럽기도 하다. 다들 본인이 하고 싶은 일 잘 했으면 좋겠다. 나도 이제 인턴십 준비하고 취업해야지.