[멋쟁이사자처럼🦁] 1차 프로젝트 회고

D uuu·2025년 5월 1일

목록 보기

2/3

약 3주간의 협업 프로젝트, 그리고 회고

약 3주간 진행한 첫 협업 프로젝트가 끝났다. 그동안은 기획, 디자인, 개발, 배포까지 혼자서 해오던 터라 ‘협업’에 대한 막연한 기대감도 컸었다. 그런데 막상 부딪혀보니 예상보다 더 어렵기도 했고, 그만큼 더 재미있기도 했던 것 같다.

혼자서 개발 할 때는 내가 모든 걸 결정하기에 빠르게 진행할 수 있었다. 물론 혼자하느라 시간적인 제약으로 구현하지 못한 기능이 많아 아쉬움도 컸었지만.. 그래서 이번 협업에서는 여러 명이 함께하니 더 빠르게 나아갈 수 있을거라 기대했지만, 현실은 오히려 혼자하는 것보다 더 많은 시간이 필요했다.

그 이유는 분명했다. 기능 구현보다 ‘의견을 조율하는 일’에 더 많은 에너지가 들었기 때문이다. 같은 화면을 보고도 각자 다른 이야기를 하고, 중요하게 생각하는 포인트도 달랐다. 개발 스타일도, 우선순위도 각기 달라 그걸 하나로 맞춰나가는 과정이 쉽지 않았다.

개발에는 정답이 없다. 같은 기능도 100명이면 100가지 방식이 있을 수 있다. 그래서 협업에서는 ‘소통’, ‘조율’, ‘약속’이 얼마나 중요한지 뼈저리게 느꼈다. 특히 아무것도 없는 제로부터 시작하는 프로젝트에서는 그 중요성이 더 크게 다가왔다.

팀 회고

프로젝트가 끝난 뒤, 팀원들과 함께 회고 시간을 가졌다. 서로 잘한 점과 아쉬웠던 점을 나누며, 다음에 더 나은 방향으로 나아가기 위한 이야기를 주고받았다.

가장 아쉬웠던 건 시간 분배였다. 하고 싶은 건 많았고, 다양한 의견을 반영하려다 보니 초기 기획과 DB 설계에 너무 많은 시간을 들였다. DB 설계에만 1주일 이상을 투자하다 보니 실제 개발에 집중할 수 있었던 시간은 2주도 채 되지 않았다.

초반에는 코드 퀄리티와 리뷰에도 신경을 많이 썼지만, 일정이 촉박해지면서 점차 여유가 없어졌다. 결국 코드 리뷰보다는 기능 구현이 우선이 되었고, 그 점은 모두에게 아쉬움으로 남았다.

그래도 좋은 점도 있었다. Git 협업 경험은 이번 프로젝트의 가장 큰 수확 중 하나였다. 혼자 작업할 때는 git add, commit, push 정도만 사용했는데, 이번에는 브랜치를 나누고 PR을 보내고 merge하는 전 과정을 직접 겪었다. 처음에는 실수로 팀에 피해를 줄까 걱정됐지만, 팀원들의 도움 덕분에 점점 익숙해질 수 있었다.

다만, 매번 브랜치에서 작업한 뒤 PR을 올리고 GitHub에서 merge되기를 기다리는 과정이 다소 번거롭게 느껴지기도 했다. 충돌 가능성 때문에 기다리는 시간이 생기고, 작은 수정에도 같은 과정을 반복하다 보니 비효율적이라는 생각이 들었다. 다음에는 rebase, squash merge처럼 터미널에서 직접 머지하는 전략도 시도해보고 싶다.

또한, 이번 프로젝트를 통해 기록의 중요성도 절실히 느꼈다. 중간중간 회의를 자주 했지만 대부분 구두로만 진행되어, 시간이 지나면 기억이 엇갈리거나 다시 조율해야 하는 상황이 많았다. 사람의 기억은 생각보다 빨리 휘발된다..! 그리고 말로만 전달하면 서로 다르게 이해하는 경우도 잦다. 나는 A라고 말했지만 상대는 A-1로 받아들일 수 있다. 이런 경우, 나중에 수정하려면 더 큰 에너지가 들어가게 된다.

작은 것이라도 기록하고, 서로의 이해가 일치하는지 확인하는 과정이 결국 가장 빠르고 안정적인 길이라는 걸 배웠다.

KEEP (잘한 점)

Git 브랜치 전략과 커밋 컨벤션을 잘 지킴
기능별로 컴포넌트 및 로직을 계층적으로 잘 분리함
팀원 간의 커뮤니케이션을 적극적으로 진행하고, 의견을 조율함

PROBLEM (아쉬웠던 점)

기획과 설계에 너무 많은 시간을 써 개발 시간이 부족했음
PR을 너무 자주 날려 오히려 리뷰 효율이 떨어졌음
회의 내용이 구두로만 이루어져 기록이 부족했음
PR에 충분한 리뷰나 코멘트가 이뤄지지 못했음
타입스크립트의 타입을 엄격히 지키지 못한 점

TRY (다음에 시도할 것)

초기 단계에서 일정 타임테이블을 설정하고, 주기적으로 체크포인트 설정
rebase, squash merge 등 다양한 Git 전략을 실험해보기
회의록 작성 습관화
코드 리뷰 문화 정착
타입 시스템을 더 명확하게 유지하고 적극적으로 활용

개인적인 회고

💡소프트 스킬

이번 프로젝트에서 내 개인적인 목표는 ‘협업에서의 소프트 스킬’을 키우는 것이었다. 기술적 성장도 중요하지만, 사람과 함께 일하는 능력은 또 다른 역량이라고 생각한다.

그동안은 누군가에게 내가 왜 이 기술을 선택했고, 어떻게 설계했는지를 설명할 기회가 많지 않았다. 하지만 협업에서는 내 생각을 말로 풀어내야 하고, 때로는 상대를 설득해야 하는 상황도 생긴다. 이 과정이 기대되면서도 가장 어렵게 느껴졌다.

특히 의견이 다를 때, 상대의 이야기를 충분히 듣고 감정이 섞이지 않도록 조심하면서도 내 입장을 설명해야 했는데, 가끔은 감정이 앞서거나 ‘설득’보다는 ‘반박’을 하게 되기도 했다. 그 경험을 통해 ‘듣는 자세’와 ‘설득 방식’도 기술만큼이나 중요하다는 걸 배웠다.

결국 협업은 사람과 사람이 하는 일이다. 감정도 있고, 스타일도, 우선순위도 다르다. 이런 차이를 이해하고 존중하면서도, 내가 옳다고 생각하는 방향을 효과적으로 전달할 수 있는 힘이 필요하다. 이번 프로젝트 덕분에 내가 부족했던 부분을 돌아보고, 다음엔 어떻게 소통하면 더 좋을지 깊이 고민할 수 있었다.

💡디자인과 기술의 균형

이번 프로젝트를 진행하면서 ‘디자인과 기술 사이의 균형’ 에 대한 고민이 깊어졌다. 보기 좋은 UI를 구현해내는 과정은 분명히 즐겁고, 결과물에 대한 애정도 커진다. 특히 프론트엔드 개발자에게 ‘보여지는 부분’은 중요한 요소임이 분명하다.

하지만 나는 ‘디자인을 예쁘게 만드는 일’이 프론트엔드 개발자의 역할이 아니라고 생각한다. 디자이너가 전체적인 레이아웃과 스타일을 고민하고, 퍼블리셔가 그 디자인을 정교하게 옮기고 다듬는 이유가 있다. 그렇다면 나는 프론트엔드 개발자로서 어떤 가치에 집중해야 할까? 를 고민해봐야 한다.

나는 결국 ‘기능을 실제로 작동하게 만들고, 데이터를 효율적으로 처리하며, UX를 고려한 인터랙션을 구현하는 일’에 무게를 두어야 한다고 생각한다. 물론 디자인 감각까지 갖추면 금상첨화겠지만, 지금 내게 중요한 건 ‘기술적인 깊이’라고 스스로를 다잡는다.

가끔 결과물을 보며 “너무 디자인을 소홀히 한 건 아닐까?” 하는 불안도 든다. 하지만 겉만 그럴듯한 포트폴리오보다, 기술적 고민과 시도가 담긴 결과물이 더 가치 있다고 믿는다.

나의 멘토이자 오빠가 해준 말을 종종 되새긴다. “보기 좋은 결과물이 시선을 끄는 건 맞지만, 결국 실력이 없다면 뽑히지 않는다.” 나는 이 말에 진심으로 공감한다. 조금 투박한 디자인이라도, 내가 어떤 고민을 했고, 왜 그렇게 구현했는지 말할 수 있다면, 그건 나만의 이야기이자 강점이 될 것이다. 지금 나는 여전히 디자인과 개발 사이에서 균형을 찾기 위해 외줄을 타고 있지만, 이 고민과 과정 속에서 분명히 성장하고 있다고 믿는다.