팀을 리딩하면서 배운것들 #

3개월 동안 세 번의 프로젝트를 진행하며 팀을 리딩했다. 처음부터 리더가 되겠다는 생각은 없었지만, 욕심이 생겼고 자연스럽게 전체 구조를 책임지는 역할을 맡게 되었다. 그 과정에서 느낀 점들을 솔직하게 기록해보려 한다.

먼저, 부족한 나를 믿고 끝까지 함께해 준 팀원들에게 진심으로 고맙다는 말을 전하고 싶다. 돌이켜보면 모든 프로젝트가 도메인에 완벽히 맞는 설계였다고 말하긴 어렵다. 하지만 단순한 기능 구현이나 개발 생산성보다는 학습과 새로운 시도에 목적을 둔 프로젝트였다는 점에서, 기존에 실무에서 사용하지 못했던 아키텍처들을 직접 적용해보고 인사이트를 넓히고 싶었다.

첫 번째 프로젝트에서는 순수 POJO와 JDBC를 활용한 CLI 프로젝트를 진행했다. 팀원 중 노베이스인 분들도 있었고, 처음부터 DDD 개념을 접목해 책임 중심 설계와 Aggregate 개념을 설명하기에는 나 또한 많이 부족했다. Aggregate의 경계와 Root의 책임을 어디까지 가져가야 하는지에 대한 고민은 지금도 남아 있고, 당시 팀원들에게는 상당히 어렵게 느껴졌을 것이라 생각한다.

지금 돌아보면, 처음부터 함께 설계를 고민하고 아키텍처를 선택했더라면 더 나은 결과가 나왔을지도 모르겠다. 하지만 제한된 기간 속에서 많은 욕심을 부렸고, 그만큼 많은 타협도 있었다. 특히 팀원들의 러닝 커브를 충분히 고려했는가라는 질문에는 선뜻 그렇다고 말하기 어렵다. 단순한 Service 중심 구조였다면 더 따라오기 쉬웠을지도 모른다는 생각이 들며, 그 과정에서 “DDD를 버려야 하나”라는 고민도 많이 했다.

나는 실무 경험도 많지 않았고, 리딩 경험은 더욱 없었다. 어쩌면 팀 프로젝트를 나의 학습을 위한 수단으로 바라본 이기적인 시선이 있었던 것 같다. 그럼에도 불구하고 팀원들의 열정 덕분에 프로젝트를 마무리할 수 있었고, 그 점은 정말 감사하게 생각한다.

두 번째 프로젝트에서는 코드 리뷰와 커뮤니케이션에 더 신경 쓰며 비교적 건강한 흐름으로 프로젝트를 진행할 수 있었다. 패키지 구조와 프로젝트 흐름을 설명하며 시작했고, 기술적인 방향성도 어느 정도 공유되었다고 느꼈다. 다만 돌아보면, 의견을 전달하는 과정에서 다소 딱딱하고 강압적으로 느껴질 수 있었겠다는 아쉬움이 남는다. 논리적으로 설명하려다 보니 팀원들에게는 나를 어렵게 느끼게 만들지 않았을까 하는 생각이 들었다.

또한 팀 리딩에서 가장 중요하다고 느낀 일정 관리(due 관리) 역시 충분하지 못했다. 기술적인 완성도에 집중하다 보니 팀원들과의 소통, 상황 공유, 일정에 대한 공감대 형성이 부족했던 것 같다. 이슈를 테이블 위에 올려 함께 토론할 기회를 더 만들었어야 했다는 아쉬움도 남는다.

세 번째 프로젝트에서는 헥사고날 아키텍처와 DDD 구조가 본격적으로 커지며 나 또한 큰 부담을 느꼈다. 외부 의존성을 끊임없이 의식하고, 클린한 구조를 유지하려다 보니 오히려 복잡성이 증가했다는 생각이 들었다. 강사님께서 “방향은 좋지만 때로는 타협하고, 문제가 생겼을 때 리팩토링하는 경험도 중요하다”는 피드백을 주셨는데, 그 말이 크게 와닿았다. 학습을 목표로 하면서도 과도한 오버엔지니어링을 고집한 것은 아니었는지 스스로에게 다시 묻게 되었다.

보일러플레이트를 줄이기 위해 라이브러리를 만들고 적용하려 했지만, 문서화와 사용 가이드 없이 “쓰세요”라고만 던져둔 점도 아쉬움으로 남는다. 기술적인 생산성만 바라보고, 협업과 이해를 위한 장치는 충분히 마련하지 못했다.

프로젝트 후반으로 갈수록 아키텍처의 복잡성 속에서 팀원들의 피로도가 눈에 띄게 느껴졌고, 나 역시 많이 지쳤다.

3개월 동안 함께했던 팀원과 개인적인 회고를 하며 인상 깊은 이야기를 들었다.
내가 설계한 코드와 아키텍처에는 분명한 의도와 맥락이 있었고,시간이 지나 다시 돌아보니 내가 했던 말들이 충분히 이해가 된다고 했다.
다만 그 이해가 그 순간에는 바로 오지 않았다는 점이 힘들었다고 했다.

당시에는 “왜 이렇게 설계했는지”보다 “이 구조를 어떻게 따라가야 하는지”가 먼저 보였고, 오히려 스스로가 답답하고 부담이 컸다고 했다.

다음 프로젝트에서 비슷한 선택을 마주했을 때 “아, 이래서 그때 그런 이야기를 했구나”라는 생각이 들었지만, 그 깨달음은 당시에 몸으로 느낄 수 있는 종류의 이해는 아니었다는 말이 오래 남았다.

이 이야기를 통해 나 역시 큰 부족함을 느꼈다. 아키텍처를 도입할 때 무엇을 선택할지보다 왜 이 선택이 필요한지를 먼저 공유하지 않았다는 점이다. 나는 이미 알고 있는 문제와 배경을 전제로 설계를 설명했고, 팀원들이 질문을 해야만 그 이유를 덧붙였던 것 같다.

하지만 리딩의 관점에서는 질문을 기다리기보다, 이 구조가 어떤 문제를 해결하기 위한 것인지, 이 선택을 하지 않았을 때 어떤 비용이 발생하는지를 먼저 공유했어야 했다.

아키텍처는 이해를 전제로 하지 않으면 ‘방향’이 아니라 ‘규칙’이 된다. 그리고 규칙은 쉽게 부담이 된다.
이 사실을 이번 경험을 통해 처음으로 체감했다.

기술적 실험은 누구를 위한 것이었나 #

프로젝트를 리딩하며 가장 많이 고민했던 질문 중 하나는 “내가 도입한 기술적 실험들이 과연 팀에게도 적절했을까?“였다.
나는 학습하고 적용하고 그런 배우는 과정에서 큰 만족을 느끼는 개발자다.
하지만 팀을 리딩하는 위치에서 이러한 기술적 실험이 ‘학습의 기회’가 아니라 ‘부담’이 되지는 않았는지 계속해서 되돌아보게 되었다.
기술적 도전은 분명 의미 있었지만, 그 실험의 비용을 누가, 어느 정도까지 감당할 수 있는지에 대한 합의가 충분했는지에는 아쉬움이 남는다.
특히 여러 아키텍처적 시도를 한 번에 도입하면서 팀의 러닝커브와 피로도를 세밀하게 조절하지 못했던 점은 리더로서 가장 크게배운 부분 중 하나다.

나는 과연 좋은 리더 자질이 충분한 개발자인가? #

이 경험을 통해 깨달은 것은 프로젝트에서 가장 중요한 것은 기술이 아니라 협업, 소통, 문서화, 그리고 일정 관리라는 점이었다. 나는 아직 좋은 리더라고 말할 수 없다.
하지만 이번 경험을 통해 무엇이 부족했는지는 분명히 알게 되었다.
앞으로의 프로젝트에서는 더 많은 합의, 더 많은 공유, 더 현실적인 선택을 의식적으로 해보고자 한다. 이 회고가 나에게 다음 단계로 나아가기 위한 중요한 경험이 되기를 바란다.