삼성청년SW아카데미에서 진행한 프로젝트에 대한 회고입니다.
소대장 시절부터 나의 리더십 정체성은 자율과 책임이었다. 소대원이 임무에서 가진 능력을 최대한 발휘하려면 심적 여유가 필요하다고 생각했다. 이를 위해 각자의 의견을 존중하고 진정성 있게 수용하는 과정이 중요하다고 여겼다. 또한, 팀이 올바른 방향을 믿고 나아갈 수 있도록 리더가 팀원들의 힘을 모아주는 역할이 필요하다고 판단했다.
반면, 팀원들이 리더를 신뢰하고 임무를 수행하려면 리더의 자질과 역량이 필수적이라고 보았다. 통신 부대 장교로서 내가 갖춰야 할 자질과 역량은 빠른 상황 판단력과 통신 분야의 전문 지식이었다. 그래서 훈련 전에는 가능한 많은 상황을 시뮬레이션하며 판단력을 연습했고, 틈이 날 때마다 통신 장비 교본을 읽으며 개념과 원리를 이해하려 노력했다. 그 결과, 여러 소대장 중 통신 지식이 가장 깊다는 자신감을 가지고 임무에 임할 수 있었다.
전역 후, 개발자의 길에 들어서며, 군에서의 리더 경험을 IT 분야의 리더십으로 전환하려면 어떻게 해야 할지 고민했다. IT 리더가 되기까지 시간이 많이 남았지만, 리더 역할을 경험한 것이 고민의 계기가 되었다. 군 생활에서 배운 것은 "훌륭한 리더는 훌륭한 팔로워"라는 것이다. 이는 리더십을 관통하는 거시적 관점이라고 보았다. 리더와 팔로워는 입장이 다르지만, 팀의 목표는 동일하기 때문에 "리더가 부여한 업무를 어떻게 수행할 것인가"와 "업무를 어떻게 부여할 것인가"는 같은 방향의 의미를 지닌다.
따라서 부여받은 업무를 어떻게 수행할지 고민하고, 그 결과가 팀의 성공에 어떻게 기여할지 생각하는 태도가 팔로워에게도 요구된다고 보았다.
다시 돌아와, IT 분야에서 리더로 역할을 수행하려면 자원 관리가 핵심이었다. 팀원이라는 자원을 그들의 능력에 맞는 위치에 배치해 최선을 다하게 하는 것이 중요했다. 이 과정에서 팀장도 자원의 일부로 포함시켜 그 역할을 명확히 해야 한다고 판단했다.
프로젝트 시작 전, 6명의 팀원이 구성되었다. 팀 빌딩 조건에 따라 전공자와 비전공자가 섞였고, 우리 팀은 그 비율이 반반이었다. 운이 좋았던 것일까? 전공자 팀원들은 이미 아는 사이였고, 맡은 일을 해낼 수 있는 사람들이라고 믿었다. 문제는 비전공자 팀원이었다.
비전공자 3명 중 1명은 아는 형이었는데, 웹 개발 경험이 약간 있어 큰 걱정은 없었다. 나머지 2명에 대한 고민은 뒤로 미루고 역할 분배를 시작했다.
프로젝트는 프론트엔드와 백엔드로 나뉘어 진행되었다. 비전공자 2명이 모두 프론트엔드를 맡아주길 바랐지만, 한 명은 백엔드를 희망했다. 이는 내 기대와 달랐지만, 개인의 선택을 존중하는 것이 나의 리더십 정체성이었다. 결국 프로젝트는 백엔드와 프론트엔드 비율이 4:2로 불균형하게 시작되었다.
프로젝트 시작 전, 프론트엔드 인원 부족이 팀의 주요 걱정거리였다. 프론트엔드 팀원 두 명은 리액트로 프로젝트를 처음 접했고, 나는 약간의 리액트 경험이 있어 풀스택 역할을 맡거나 컴포넌트 제작을 돕겠다고 했다. 또한, 백엔드 팀원들에게 프론트엔드 진행이 늦어지면 모두 지원해야 한다고 미리 알렸다. 프론트엔드 팀원이 최후의 보루가 있다는 안도감을 느끼길 바랐다.
프론트엔드 인원 부족으로 시간이 촉박하다는 직감이 들었다. 이후 프로젝트 속도를 높이는 방법을 고민했다. 프론트엔드 개발에는 최소한의 시간이 필요하다고 보았기에, 백엔드 개발 시간을 단축해 프론트엔드를 지원하는 전략을 세웠다.
백엔드 개발 시간을 줄이기 위해 기획/설계 단계부터 개발을 병행했다. 낮에는 기획과 설계를, 저녁에는 집에서 추가 작업을 했다. 이 단계에서 기술 스택을 미리 연동하고, S3를 사용하기 쉽게 라이브러리로 제공하며 파일 업로드와 삭제를 간편하게 했다. 스프링 시큐리티 설정, 일관된 API 데이터 제공을 위한 공통 객체와 예외 처리 설계, DB와 S3 데이터 등의 처리를 위한 가이드 코드를 작성해 제공하는 작업을 미리 완료했다.
기획/설계가 끝난 후, 프론트엔드 1명은 레이아웃 목업 제작, 1명은 라이브 통신과 소켓 기술 검증, 백엔드 1명은 AI 기술 검증에 투입되었다. 가장 바빠야 할 프론트엔드가 개발에 온전히 집중하지 못했다.
문제는 백엔드에서도 생겼다. 비전공자 한 명이 로그인 부분을 맡고 싶다고 했다. 그러나 그는 자바와 스프링 경험이 없고, 장고만 조금 다뤄봤었다. 할 수 있겠냐고 여러 번 물었지만, 해보겠다는 대답에 거절하지 못했다. 마감 기한을 목요일로 정했고, 그 주 금요일쯤 결과를 확인했다.
로그인 담당 팀원은 놀랍게도 기능을 구현해왔다. 정상 작동했지만, 코드를 보니 인터넷 강의 코드를 그대로 가져온 것이었다. 설계 단계의 컨벤션을 따르지 않았고, var와 val(Lombok 제공)을 혼용하며 제대로 이해하지 못한 상태로 작성했다는 점을 알게 되었다.
결국, 소셜 로그인 구조와 맞지 않는다는 이유로 내가 로그인 코드를 새로 작성했다. 이후 이 팀원에게 어떤 업무를 맡길지 고민이 깊어졌다. 처음에는 작은 작업부터 배정했다. 내가 2~3시간이면 끝낼 분량을 그에게 2~3일의 시간을 주었다. 그가 작성한 코드를 리뷰하며 잘못된 점과 컨벤션이 지켜지지 않은 부분을 알려주었다. 몇 번 반복하니 단순한 API 정도는 맡길 수준이 되었다. 2~3시간 기준을 둔 것은 필요하면 내가 다시 만들 수 있다는 계산이었다.
백엔드 개발 속도는 예상보다 빨랐고, 곧 백엔드 팀원이 프론트엔드를 지원할 시점이 왔다. 그러나 프론트엔드 진척은 여전히 느렸다. 백엔드 팀원들도 위기감을 느끼고 모두 프론트엔드 작업에 합류했다.
초반 우려가 과도했던 것인지, 미완성 상태였던 부분들이 비동기 데이터가 처리되듯 빠르게 완성되었다. 프로젝트는 예상보다 빠르게 마무리 단계로 접어들었다.
그러나 이번엔 내가 문제였다. 초반에 너무 신경을 쓴 탓인지 번아웃이 올 조짐이 보였다. 팀원들도 지친 기색이 역력했다. 이런 분위기 속에서 삼성 임직원 유저 테스트 프로젝트에 선정되었다는 소식이 왔다. 60여 팀 중 10팀이 뽑힌 결과였다. 나는 큰 감흥이 없었지만, 팀원들은 갑자기 활기를 띠었다. 선정된 기쁨 때문인지 몰라도, 팀원들이 열정을 보이는데 팀장인 내가 주저앉아 있을 수 없었다. 유저 테스트 전까지 매일 저녁 팀원들과 개선점을 테스트하고 엑셀로 정리하며, 낮에 수정하는 과정을 반복했다.
그 결과, 프로젝트 안정성이 높아져 유저 테스트를 무리 없이 치렀다.
개발이 일찍 끝나 다른 팀이 발표 전날 밤을 새울 때, 우리 팀은 일주일 전부터 여유롭게 발표를 준비했다. 의도치 않게 프로젝트 막바지에 워라밸을 지킬 수 있었다.
수상은 하지 못했지만, 오랜만에(혹은 처음으로) 만족스러운 개발 경험을 했다고 느꼈다.
소대장 시절에는 모든 것을 잘하는 슈퍼맨이어야만 했다. 이번 프로젝트에서 팀장은 모든 것을 잘 할 필요는 없었다. 팀원 중 누군가는 자발적으로 문서화를 담당해주고, 누군가는 팀 일정을 가끔 체크해주었다. 내가 문서화를 못하면 잘하는 사람이 하면 되고 시키면 된다. 못하는 일을 잘하려고 노력하는 것 또한 좋지만, 프로젝트 진행에 있어서 각자의 능력이 적재적소에 쓰이는 것 또한 중요하다.
