3달차 회고: 설계와 협업 사이에서 배운 프로다운 태도

1. 프로젝트 개요

이번 프로젝트는 LXP 서비스 설계에 초점을 둔 DDD 프로젝트였다.

LXP는 기존 LMS의 단방향 학습 구조에 학습 경험과 상호작용을 더한 플랫폼이다. 기존 LMS가 강의 제공 중심의 일방향 학습에 가까웠다면, 우리가 만들고자 한 LXP는 학습자가 더 능동적으로 참여하고 상호작용할 수 있는 양방향 학습 플랫폼에 가까웠다.

주요 사용자는 개발자와 취업 준비생으로 설정했다. 단순히 강의를 듣는 것에서 끝나는 것이 아니라, 학습 과정에서 미션을 수행하고, 의견을 나누고, 댓글과 구독 같은 상호작용을 통해 학습 경험을 확장할 수 있는 서비스를 목표로 했다.

프로젝트 기간은 약 1주일이었다. 나는 팀에서 설계와 백엔드 개발을 맡았고, 주요 담당 기능은 구독과 결제 기능이었다. 별도로 고정된 문서 담당을 맡지는 않았지만, 유비쿼터스 언어, 바운디드 컨텍스트, CRC를 정리하는 과정에서 설계 방향과 책임 분리에 대한 의견을 제시했다.

---

2. 프로젝트 진행 과정

프로젝트 초반에는 먼저 LXP가 무엇인지 정의하는 데 집중했다.

처음에는 단순히 “학습 플랫폼을 만든다”는 수준에서 출발했지만, 곧바로 “기존 LMS와 무엇이 다른가”, “누가 이 서비스를 써야 하는가”, “사용자가 왜 이 서비스를 선택해야 하는가” 같은 질문이 필요하다는 것을 느꼈다.

초반에 가장 많이 고민한 부분도 이 지점이었다. 개발자와 취업 준비생을 주요 사용자로 잡았지만, 그들이 기존 학습 서비스가 아니라 우리가 만드는 LXP를 사용해야 하는 이유를 명확히 정의하는 과정이 필요했다.

프로젝트 중반에는 유비쿼터스 언어, 바운디드 컨텍스트, CRC를 많이 수정했다. 도메인의 경계가 맞는지, 컨텍스트의 범위가 과도하거나 부족하지 않은지, CRC에서 Responsibility와 Collaborator가 적절하게 작성되었는지 확인하는 과정이 반복되었다.

특히 구독과 결제 기능을 맡으면서 두 기능이 같은 컨텍스트 단위로 묶일 수 있는지 고민했다. 같은 컨텍스트라면 애그리거트 루트는 무엇이어야 하는지, 구독이 루트가 되어야 한다면 그 이유는 무엇인지, 결제는 구독과 어떤 관계를 가져야 하는지 검토했다.

구현 전 설계에서는 Payment를 독립된 결제 기록으로 볼 것인지, Subscription 애그리거트 내부의 결제 상태 기록으로 볼 것인지가 중요한 책임 경계의 문제였다. 최종적으로는 Payment를 Subscription 내부의 결제 상태를 기록하는 구성요소로 보고 구현 단계로 넘어갔다.

또한 처음부터 복잡한 구조를 적용하기보다 모놀리식으로 구현한 뒤, 이후 필요에 따라 헥사고날 아키텍처로 리팩터링하는 방향도 가능한지 생각했다.

프로젝트 후반에 와서는 완벽한 설계만을 목표로 하기보다, 어느 정도 설계를 진행한 뒤 구현으로 넘어가는 균형이 중요하다는 것을 느꼈다. 설계를 고도화하는 것도 중요하지만, 설계만 오래 붙잡고 있으면 실제 코드로 옮겼을 때 드러나는 문제를 확인하기 어렵다. 결국 설계는 구현과 분리된 결과물이 아니라, 구현을 통해 계속 검증되고 수정되어야 하는 기준이라는 생각을 하게 되었다.

---

3. 이번 프로젝트에서 잘했다고 생각한 부분

이번 프로젝트에서 내가 특히 잘했다고 생각하는 부분은 애매하거나 부족하다고 느낀 지점을 그냥 넘기지 않고, 팀이 논의할 수 있는 문제로 드러내고 개선 방향을 제안하려 했다는 점이다.

단순히 맡은 기능을 구현하는 것에만 집중하지 않고, 기능이 어떤 도메인 경계 안에 있어야 하는지, 어떤 객체가 책임을 가져야 하는지, 문서에 작성된 책임과 협력자가 적절한지 계속 확인하려 했다.

구독과 결제 기능을 예로 들면, 단순히 구독 생성과 결제 처리를 구현하는 것보다 먼저 두 기능의 관계를 이해하려 했다. 구독과 결제가 같은 바운디드 컨텍스트 안에 있어야 하는지, 구독이 애그리거트 루트라면 결제는 어떤 방식으로 관계를 가져야 하는지 고민했다. 최종적으로는 Payment를 독립된 결제 기록으로 두기보다, Subscription 내부의 결제 상태를 기록하는 구성요소로 바라보고 구현 단계로 넘어갔다.

또한 유비쿼터스 언어, 바운디드 컨텍스트, CRC를 정리하는 과정에서도 단순히 문서의 형식을 맞추는 것이 아니라, 실제로 도메인의 경계와 책임이 맞는지 확인하려 했다. CRC에서 Responsibility가 클래스의 책임으로 적절한지, Collaborator에 들어간 요소가 실제 협력자인지 점검했다. 이 과정은 문서를 고치는 일이기도 했지만, 동시에 팀이 같은 기준으로 도메인을 이해하기 위한 작업이었다.

협업 측면에서도 성장한 부분이 있었다. 기업에서는 혼자 일하는 것이 아니라 여러 사람과 함께 일하기 때문에, 단순히 내 의견이 맞는지보다 상대방이 이해할 수 있는 방식으로 설명하는 것이 중요하다고 느꼈다. 그래서 기존에 부족하다고 느꼈던 말과 행동, 태도를 의식적으로 바꿔보려 했다.

내가 생각한 프로다운 태도는 단순히 맡은 일을 끝내는 것이 아니라, 팀의 생산성을 해치지 않는 방식으로 의견을 내고, 상대방이 이해할 수 있는 언어로 설명하며, 결과물을 더 나은 방향으로 개선하려는 태도였다.

결과적으로 내가 한 행동이 프로젝트 전체를 크게 바꿨다고 단정하기는 어렵다. 하지만 수정된 부분을 중심으로 확인하고 의견을 제시함으로써 팀원이 다시 확인해야 할 범위를 줄이는 데는 일부 도움이 되었다고 생각한다. 또한 협업이 단순히 역할을 나누는 것이 아니라, 서로의 이해도를 맞추고 더 나은 방향을 함께 찾아가는 과정이라는 점을 생각해볼 수 있었다.

---

4. 부족했다고 느낀 부분

이번 프로젝트에서 가장 부족했다고 느낀 부분은 프로다운 꾸준함이었다.

여기서 말하는 꾸준함은 단순히 매일 같은 시간에 참여하는 것만을 의미하지 않는다. 프로젝트에 변수가 생기더라도 팀의 작업 흐름이 크게 흔들리지 않도록, 당일 또는 전날에 작업 안건과 우선순위를 명확히 정해두는 태도에 가깝다.

프로젝트 기간 동안 개인적인 외부 요인으로 참여가 흔들리는 경우가 있었다. 문제는 참여가 흔들린 것 자체보다, 그 상황을 대비할 수 있는 팀 운영 기준이 충분히 정해져 있지 않았다는 점이었다. 당일이나 전날에 어떤 안건을 우선 처리할지 명확히 정하지 않았고, 결원이 생겼을 때 남은 팀원이 어떤 기준으로 작업을 이어가야 하는지도 정해두지 못했다.

이 부족함은 경험 부족과 태도 문제에 가까웠다. 협업 프로젝트 경험이 많지 않았기 때문에, 개인의 참여 여부가 팀 전체의 진행 흐름에 어떤 영향을 줄 수 있는지 충분히 체감하지 못했다. 또한 학습 목적의 프로젝트라는 이유로, 실제 협업 상황에서 필요한 운영 기준과 책임 기준을 충분히 엄격하게 적용하지 못한 부분도 있었다.

이로 인해 특정 작업의 진척도가 느려지거나 멈추는 문제가 발생했다. 혼자 하는 학습이라면 내 속도만 조절하면 되지만, 팀 프로젝트에서는 안건, 우선순위, 담당자, 결원 발생 시 대응 방식이 정리되어 있어야 작업 흐름이 유지될 수 있다. 이 점을 더 무겁게 받아들였어야 했다.

이후에는 결원이 생길 경우 어떻게 진행할지 팀 회의를 통해 지침을 정했고, 수정된 부분을 색상으로 표시해 팀원이 변경 지점을 더 쉽게 확인할 수 있도록 제안했다. 또한 이전보다 소통을 더 자주 하려고 노력했다.

이 과정을 통해 협업에서 중요한 것은 단순히 내 작업을 끝내는 것뿐만 아니라, 팀이 어떤 기준으로 움직일지 미리 정하고 공유하는 것이라는 점을 배웠다.

---

5. 다음 프로젝트에서 개선하고 싶은 부분

다음 프로젝트에서는 협업에 임하는 태도와 작업 공유 방식을 더 명확히 개선하고 싶다.

먼저 다양한 의견을 제시하되, 서로를 존중하고 배려하는 방식으로 논의하고 싶다. 의견을 내는 것만큼 중요한 것은 상대방이 왜 그렇게 생각했는지 이해하려는 태도라고 느꼈다. 또한 모르는 부분이 있으면 모른다고 솔직히 말하고, 충분히 이해하지 못한 상태에서 다른 사람의 의견에 편승하지 않는 태도도 필요하다고 생각했다.

작업 상태 공유 방식도 구체화하고 싶다. 다음 프로젝트에서는 데일리 스크럼과 PR 코멘트를 활용해 현재 진행 중인 작업, 막힌 부분, 다음에 해야 할 일을 짧게라도 공유하려 한다. 특히 외부 요인으로 지각, 결석, 컨디션 문제가 생길 경우에는 노션에 현재 상황과 남은 작업, 우선순위를 남기고, 내가 맡은 업무가 있다면 다음날 오전까지 진행 방향이나 복구 계획을 공유하는 방식으로 팀의 작업 흐름이 끊기지 않도록 하고 싶다.

회의 방식도 개선하고 싶다. 이번 프로젝트에서는 회의 시간이 충분히 생산적으로 쓰이지 못한 경우가 있었다. 회의에서 여러 안건을 동시에 다루면 논의는 길어지지만 결론이 흐려질 수 있다. 그래서 다음에는 한 번의 회의에서 하나의 안건만 다루고, 회의 종료 시 결정 사항과 담당자를 반드시 남기고 싶다.

의견이 한 사람에게만 수렴되지 않도록 하는 태도도 중요하다고 느꼈다. 이를 위해서는 모르는 것을 모른다고 말할 수 있어야 하고, 근거 없이 다른 의견에 편승하지 않아야 한다. 협업에서 중요한 것은 갈등을 피하는 것이 아니라, 서로 다른 의견을 비교하고 합의 가능한 기준을 만들어가는 것이라고 생각한다.

설계와 구현의 균형도 더 명확히 잡고 싶다. 설계를 깊게 고민하는 것은 중요하지만, 일정 시간 이상 진척이 없다면 구현을 통해 검증하는 단계로 넘어가야 한다고 느꼈다. 다음 프로젝트에서는 같은 주제로 2일 이상 고민했는데도 진척이 없다면, 최소한의 설계를 기준으로 먼저 구현하고 이후 리팩터링하는 방식도 고려하고 싶다.

---

6. 다음 프로젝트에서 적용할 행동 규칙

이번 회고를 단순한 반성으로 끝내지 않기 위해, 다음 프로젝트에서 적용할 행동 규칙을 정리하면 다음과 같다.

1. 데일리 스크럼에서 현재 작업, 막힌 부분, 다음 작업을 공유한다.
2. 당일 또는 전날에 다음 회의의 핵심 안건과 우선순위를 정한다.
3. PR 코멘트에는 변경 이유, 주요 수정 범위, 리뷰어가 봐야 할 부분을 남긴다.
4. 결원 발생 시 남은 팀원이 어떤 기준으로 작업을 이어갈지 사전에 정한다.
5. 회의는 한 번에 하나의 안건만 다루고, 결정 사항과 담당자를 기록한다.
6. 같은 설계 문제로 2일 이상 진척이 없다면 구현으로 검증하는 단계로 넘어간다.

이 규칙들은 거창한 방식이라기보다, 팀 작업이 멈추지 않도록 만드는 최소한의 운영 기준에 가깝다. 다음 프로젝트에서는 개인의 책임감에만 의존하지 않고, 팀이 같은 기준으로 움직일 수 있는 구조를 만드는 데 더 집중하고 싶다.

---

7. 이번 프로젝트를 통해 배운 것

이번 프로젝트를 통해 좋은 협업은 단순히 의견을 많이 내거나 맡은 기능을 구현하는 것에서 끝나지 않는다는 점을 배웠다.

설계 측면에서는 완벽한 설계를 처음부터 만들려고 하기보다, 일정 수준의 설계를 기준으로 구현을 시작하고, 구현 과정에서 드러나는 문제를 다시 설계에 반영하는 균형이 필요하다는 것을 느꼈다.

협업 측면에서는 팀원이 각자의 작업을 독립적으로 수행하는 것만으로는 충분하지 않다는 것을 느꼈다. 누가 어떤 작업을 하고 있는지, 어디서 막혔는지, 다음에 무엇을 해야 하는지 공유되어야 팀 전체의 작업 흐름이 유지될 수 있다.

이번 프로젝트에서 얻은 가장 큰 기준은 “협업에 임하는 프로다운 태도”였다. 이는 단순히 결과물을 완성하는 것이 아니라, 책임감을 가지고 소통하며 팀이 함께 일할 수 있는 상태를 만드는 태도라고 생각한다.

다음 프로젝트에서는 이 기준을 더 구체적인 행동으로 옮기고 싶다. 데일리 스크럼, PR 코멘트, 노션 공유, 회의 안건 제한 같은 방식을 통해 작업 상태를 명확히 공유하고, 팀이 함께 앞으로 나아갈 수 있는 협업 방식을 만들어보고 싶다.