케어링노트 그 두번째 이야기

이전 글에서 우리는 팀의 여러 가지 문제를 식별하고 변화하기 위한 노력들을 시도했다. 이번 글에서는 그 변화들 속에서 혼란 했던 팀의 2달간을 얘기한다. 이전 글과 다르게 회고보다는 사건의 나열을 통한 수필에 가까운 글이다.

그 전까지 상황

우리 팀은 기획, 프론트, 백엔드로 나누어져 일을 진행했고, 프론트는 요구사항을 맞추지 못할 만큼 실력이 부족했다. 5개월 중 2개월이 지날 쯤 나는 개개인에 대한 회고를 진행과 동시에 우리 팀에 필요한 ‘혜성’을 팀에 영입했다. 나는 풀 스택으로 전환하며 기획, 프론트에 모두 크게 관여하기 시작했다. 우리 모두 상황이 더 나아지길 바라며 2025년을 맞이했다.

소개

케어링 노트 회고 그 두 번째 이야기입니다. 새로운 인원이 추가되었고, 팀의 의사 소통 구조가 바뀌었습니다. 하지만, 사람은 쉽게 바뀌지 않습니다. 개개인과 팀에게 격정적인 변화가 일어나던 시기입니다. 많은 선택들과 갈등이 이 글에 담길 예정입니다.

주요 인물

• 상훈: ich(나)
• 지원: 백엔드 개발자 및 개발 PM
• 완고: 기존 프론트엔드 코드 리딩
• 묵관: 프론트엔드 개발자2
• 혜성: 혜성처럼 나타난 새로운 프론트엔드 개발자

본문

문제 해결을 위한 우선 순위정의

혜성님의 등장과 함께, 프론트엔드 repo의 전반적인 피드백을 진행했다. 그 동안 구체적으로 알지 못했던 문제점들은 다음과 같았다.

1. Linter 미적용(비활성화 되어 있었다.)
2. 로그인 플로우 미구현
3. 리액트 상태 관리의 문제점

Linter 미적용은 굉장히 기초적인 실수여서 금방 해결 가능했지만, 로그인 플로우와 상태 관리 이슈는 시간이 걸리는 중대한 문제였다. 특히, 로그인 시스템은 어플리케이션 전반에 걸쳐 수정 작업이 광범위한 영향을 미칠 가능성이 높았다. 따라서, 개발 우선순위를 재조정하고 사용자 인증 시스템을 위한 체계적인 구현이 가장 우선되어야 했다.

상태 관리 문제는 단순한 코드 수정을 넘어 개발자들 전반에 걸쳐 심층적인 접근이 필요했다. 팀원들의 리액트 상태 관리 패턴에 대한 이해도를 높이고, Zustand와 같은 적절한 상태 관리 라이브러리 사용이 시급했다. 현재 실력과 구현 방식은 코드 복잡성이 기하급수적으로 증가하고 유지보수성이 저하될 것이었다. 따라서 기술적 부채 해소와 함께 팀 역량 강화를 위한 교육 세션을 병행하는 이중 전략을 세웠다.

그런데, 다른 사람들은 이 필요성에 충분히 공감하지 않았다. ‘되기만 하면 되는 거 아냐?’, ‘나중에 하면 되는 거 아냐?’라는 생각들을 계속 얘기 했다. 그러나 시간이 지체 된 상황에서 나에게는 한 명 한 명을 설득할 시간과 힘이 없었다. 나는 랩장에게 얘기하고 변화를 밀고 나가기로 했다. 해야만 했다. 나는 성공하고 싶었으니까.

첫 번째 갈등, 로그인(Keycloak)

백엔드부터 유저 인증 과정을 keycloak으로 옮기고, 그 다음 프론트엔드 인증 시스템에 Keycloak 인증을 연결하는 방식으로 구현했다. 그 과정에서 그 동안에 최소한으로 구현했던 jwt인증 방식이 성립하지 않게 되었다. 우리 서버는 개발 서버 하나 밖에 없었기 때문에, 로컬에서 바꾸지 않는 이상 프론트엔드가 keycloak 연결이 준비될 때 까지 백엔드 인증에서 튕겨나가게 됐다. 예상하지 못 했던 다음 세 가지 문제가 있었다.

1. Kubernetes nginx ingress 뒤 keycloak에 remote ip 전달
2. CORS error
3. Client, 인증 등 keycloak 전반에 대한 이해 부족

하루 만에 짠 하고 해결할 줄 알았던 문제들은 인프라와 코드 모두 해결이 필요했다. 아쉽게도 이 일은 5일 정도가 소모되었다. 그리고 완고님과 첫 번째 갈등이 발생했다.

‘기존에 인증도 어느 정도 만들어 놨고 다 잘되고 있었는데, 이렇게 바쁘고 할 일이 많은 와중에 이 작업 때문에 제가 오늘 일을 할 수 없다는 것이 안타까워서 그래요.’

내가 예상했던 3일 동안 해결하지 못 했던 것과, 이 작업의 중요성에 동의하지 못하는 마음이 혼합된 말이었다고 생각한다. 나는 대화가 끝나고 숨죽여 울며 2일을 밤새 해결했다. 너무 힘들어서 그랬는지는 모르지만, 그냥 한참을 슬퍼하며 이 악물고 코드와 키클락 설정을 수정하던 어렴풋한 기억만이 남아있다. 그렇게 내가 프론트엔드 참여 이후 첫 갈등이 종료됐다.

갑작스런 휴식 선언

나와 갈등을 빚은 하루 뒤, 완고는 쉬겠다고 선언했다. 언제 올지 모르지만 1차 QA기간이 끝난 뒤에 오겠다고 글을 남겼다. 나와 혜성, 묵관씨는 덩그러니 남아 있었다. 완고가 남긴 코드를 고쳐야 한다는 상황만 남은 채로. 우리는 18일 qa까지 10일을 남겨 둔 상황이었다. 지원까지 프론트엔드 코드에 참여시켰고, 우리는 미친 듯이 리팩토링, 개발에 매진했다. 이 뒤로는 기억도 나지 않는 순간들을 14일 동안 보냈다. 고치고, 바꾸고, 고치고, 바꾸고의 무한 반복이었다. 주로 고쳤던 목록은 다음과 같다.

• component
• 탭 구조 구현
• router
• zustand와 react query 구현
• 백엔드 api 오류

그렇게 시간은 흘렀다.

1차 QA, 설날에 있었던 일

사라져 버린 사람들, 급변한 상황 속에 우리는 1차 QA를 맞이했다. 기획과 디자이너는 다 완성된 상태로 버그를 잡는 것이 QA라고 생각했을 지도 모르겠다. 개발 상황은 사실 밖은 타고 속은 덜 익은 스테이크처럼 되어 있었다. 6개 페이지에 80개 넘는 qa 포인트가 쌓이고 설 연휴가 코앞이었다. 기획은 수 많은 오류들에 당황하고 있었고, PM은 해결하지 못한 채 부담과 스트레스만 쌓이고 있었다.

나는 QA와 기능 개발의 병행을 주장했다.

• 컴포넌트의 완전성이 보장 되지 않아 컴포넌트 리팩토링이 지속적으로 필요함
• 핵심 기능 개발에 집중할 인원과 단순 오류 수정 인원이 나눠져야 함
• QA에 잡힌 것들이 지나치게 많음

랩장은 나에게 QA, 개발 등에 대한 일정을 다시 요구했다. 우리 팀의 두 번째 갈등이었다.

랩장이자 PM의 입장, 그리고 개발자인 나

랩장은 지킬 수 있는 현실적인 목표를 세우고 일정을 계획하여 달성 가능한 목표를 만들고 싶었다. 그래야 베타 테스트를 협의하고 우리 팀의 일정 마감을 정할 수 있기 때문이었다. 문제가 많이 발생했기 때문에 언제 고쳐질지 알고 싶었을 것이다. 그러나 나는 이 말이 버거웠었다.

어떻게 계획 할 수 있을까요?

나는 1월부터 cursor와 함께 내가 만들지 않은 스파게티를 다시 풀어 헤치고 정리하고 있었다. 얼마나 바꾸어야 할지, 어떻게 바꾸어야 할지 하루하루 단위로도 계획을 짜기 어려웠다. 명백히 다른 인원들의 실력이 부족한 상태에서 나와 혜성님이 고쳐나가는 상황에서 계획을 짜는 것보다 지금 당장 일을 하고 상황을 개선시키는 것이 나는 더 중요하다고 생각했다. 나는 다음과 같이 주장했다.

1. 언제 어떤 문제가 해결될지는 두 명의 keyman에게 달려있다.
2. 지금은 일정을 얘기하는 것보다 하루하루 집중하고 일할 환경을 만드는 것이 중요하다.
3. 언제 되냐는 말보다 같이 오늘 일할까요 라는 말을 해줬으면 좋겠다.

랩장의 의견 수용

그녀는 나의 말에 다음 날 전화를 걸어 할 거 없으면 같이 일하자고 말했다. 우리는 5시간 동안 함께 일하며 css부터 고쳐갔다. 그녀가 보여준 평정심과 즉각적인 반영이 아직도 충격으로 내게 남아있는 것 같다.

Feature team 분리, PM 보직 삭제

PM은 백엔드 개발자였기 때문에 프론트엔트 코드 상태와 문제점들을 파악할 수 없었다. 그 상태로 정해진 일정들은 계속해서 문제가 발생했고, 해결하지 못한 상태로 스트레스로 남았다. 나는 이런 소규모 팀에서 PM이 쓸모 없다고 생각했다. PM이라는 보직을 삭제 했다. 그 다음 일로는, 기획-백엔드-프론트 엔드 간의 거리를 좁히기 위해 8명의 팀을 core 팀 5명(기획2, 나, 혜성, 묵관)과 STT 팀 3명(기획1, 지원, 완고)로 분리했다. 각자 팀의 진행을 feature별로 책임지고 개발부터 기획의 모든 이슈를 해결하고자 하는 의지였다.

복귀, 탈퇴, 영입

팀의 재정비가 끝났다고 생각했고, 우리는 속도를 더해가며 2월을 보내고 있었다. 완고가 다시 합류했고, 나와 혜성의 코드 파악이 거의 끝나 65%정도의 리팩토링을 마쳤다. 그런데 점점 더 묵관의 말이 없어지고 있었다.

묵관의 탈퇴

그는 어느 날, 취업했다는 얘기와 함께 활동을 더 이상 못 할 것 같다는 말을 남겼다. 그에게 할당되었던 모든 일들을 못 하겠다는 말과 함께.. 내가 요구하고 있는 것들이 그가 감당하기 힘들었음을 어렴풋이 느끼는 순간이었다. 그 몫을 혜성이나 완고에게 할당할 수 없었으므로, 고스란히 나의 일들이 되었다.

새로운 인물의 등장

나의 프론트엔드 로드가 증가함에 따라, 나는 새로운 인물을 필요로 했다. 사실 모든 방향의 로드를 쳐내면서 백엔드의 테스팅이나 체계에 거의 관여하지 못 했기 때문에, 마치 잠만 자는 집처럼 지저분한 상태의 방에 옷가지처럼 코드만 쌓이고 있었다. 단순히 기능을 개발하기 보다 전문성과 정확성을 바탕으로 체계를 세워줄 누군가. ‘구조진’을 나는 프로젝트에 영입하기로 결정했다.

2월이 끝나가며

이제 우리는 QA를 마무리하고 새로운 기능 개발에 들어갈 수 있게 되었다. 결국 사람을 가르치고 변화를 일으키는 대신 다른 사람들이 일을 다시 하는 방향성으로 진행되었는데, 그 결과 묵관은 나가게 되었다. 완고는 나와 다른 팀으로 분리돼 그를 감독하거나 하지 않게 되었다. 나는 그 당시 그래야만 했다. 그를 신경 쓸 시간이 없었기 때문이다. 이전 개발 PM이었던 지원을 믿으며 3월을 맞이 했다. 3월 21일은 기말 발표가 있고, 4월 초에는 유저 베타 테스트가 예정되어 있다. 희망보다는 제발이라는 말로 2월을 마무리했다.