애자일 회고 4L 방식 (키워드 위주)

Marimba | Online Whiteboard Collaboration Tool

😃 좋았던 것(Liked)

• 용철

  • 실제 프로젝트 경험

    이전에 했던 프로젝트들은 클론코딩 느낌이 많이 났었는데 이번에 직접 팀원들끼리 도메인을 정하고 같이 설계하면서 그냥 따라치기만 하는 것이 아닌 팀원들과 다양한 의견을 내며 적용해보는 것이 재밌었습니다.

  • 협업 경험

    여태까지 개발 공부를 할때 혼자서 하는 경우가 많았는데 이번에 팀원들과 같이 프로젝트를 진행하면서 내가 겪고 있는 문제에 대해서 공유하고 다 같이 해결책을 생각하고 다른 사람이 작성한 코드를 보며 이렇게 해결할 수 있구나라는 것을 많이 배운 것 같습니다.

  • 인프라 환경 구축

    데브코스를 진행하면서 다양한 과제를 제출하며 백엔드 개발을 어느정도 경험해보았지만 구현한 애플리케이션을 서버에 배포하는 과정은 진행해보지 못했습니다. 이번에 프로젝트를 진행하면서 코드를 작성하고 커밋하면 CI/CD를 통해 AWS에 존재하는 EC2에 자동으로 배포되게 구현함으로써 단순한 애플리케이션 작성에 그치는 것이 아닌 배포를 경험해본 것이 좋았습니다.

  • 스프린트 경험과 다양한 도구 사용(jira, notion)

    이번에 애자일 스크럼 방식으로 프로젝트를 진행하면서 협업툴로 많이 사용되는 JIRA를 선택하게 되었습니다. 많은 기업에서 사용하는 JIRA를 사용하며 기본적으로 이슈를 등록하고 스프린트를 시작하는 기본적인 사용을 해보고 깃허브와 연동하여 풀리퀘스트 요청들을 이슈에 매핑시켜 해당 이슈에 관련된 커밋들을 쉽게 확인할 수 있도록 했습니다.

    다만 JIRA도 커밋 내역들을 추적하여 어떤 기능에 대한 변경사항 추적에 좋았지만 깃허브 이슈를 활용하여 깃허브만 확인해도 현재 상황을 파악할 수 있게 했으면 어땠을까? 라는 아쉬움은 남는 것 같습니다.

    그리고 노션을 통해 회의 내용이나 트러블 슈팅, 규칙들을 정리하면서 나중에 코드를 작성할때 해당 내용을 참고했던 것들이 좋았던 것 같습니다.

• 연우

  • 회의 기록을 노션을 통해 날자별로 기록하며, 회의 템플릿을 통해 빠르게 회의내용을 문서화 할 수 있어 좋았습니다. 그리고 Jira 를 처음 사용해보았는데, 저는 팀원분이 설정해주신 Jira 를 사용한 것 뿐이긴 했지만, 도메인 별로 에픽을 만들고, 기능별 이슈, 그리고 그에 대한 하위이슈를 만들어 PR, commit 을 연동하는게 신기하고 유용했습니다!
  • 팀프로젝트도 처음이었고 기간 내에 반드시 완수해야 하는 작업을 나누고, 각자 업무를 할당하여 수행하는 것도 처음이라 감회가 새로웠습니다.
  • PR 을 올려 기능단위로 작업하다보니 커밋단위와 커밋 메시지가 더 중요하게 느껴졌습니다. 예전에 과제 할 때는 너무 자잘하게 커밋을 날리고는 했습니다. 팀프로젝트를 하다보니 이전 버전으로 돌아가야 하는 순간도 존재 했습니다. 작업하는 기능에 대해 너무 작은 단위의 커밋으로 나누다보면 리뷰어들이 보기에도 불편할 것이라고 생각되어 최대한 적절한 단위로 커밋을 날리려고 노력하게 되었습니다.

😢 부족했던 것(Lacked)

• 용철

  • 부족한 설계

    코드를 작성하면서 계속해서 처음에 설계했던 ERD나 API 설계가 계속해서 바뀌는 경우가 잦았습니다. 처음에 요청과 응답에 대한 값을 미리 설계하고 시작했지만 작성하면서 너무 빈약하거나 너무 과한 정보를 반환하는 경우가 많았습니다. 예를들어, 판매글을 상세 조회할때 모든 필드의 정보를 반환하는 것과 같이 핵심적인 정보만 전달하는 부분이 아쉬웠습니다.

    이에 다시 DTO나 도메인을 수정하면서 시간을 많이 쏟게 되었고 처음 설계할때 시퀀스 다이어그램을 작성하지 않았던 것이 후회되었습니다.

  • 소통의 어려움과 문서화의 중요성

    프로젝트를 진행하면서 팀원들과 회의중에 나눈 내용이 서로 잘못 이해되서 같은 이야기를 여러번 나눈 일이 있었습니다.

    초기에 롬복은 @Builder, @NoArgsConstructor만 사용하기로 했었는데 해당 부분이 와전되어 각자 다양한 롬복들을 사용하게 되었습니다. 중간에 이를 확인하여 다시 한번 리마인드하고 해당 부분을 회의록에 기록하게 되었습니다.

    이런 자잘한 문제들이 많이 발생하였고 이때마다 회의를 하고 해당 내용을 기록하는 등 시간을 많이 뺏기게 되었습니다.

    처음 회의때 부터 기록을 깔끔하게 잘 해두었다면 이런일이 안 일어났을텐데 하고 문서화의 중요성을 깨닫게 된것 같습니다.

  • 제각기 다른 코드 스타일

    프로젝트를 진행하면서 다른 사람이 작성한 코드를 보며 코드 작성 스타일이 다른게 많아 이해하는 데 시간이 더 걸린 것 같습니다.

    예를들어 Optional을 반환받는 값의 경우 어떤분은 Stream을 이용하여 orElseThrow를 통해 값을 받고 어떤분은 if문을 통해 값이 null인지 체크하는 방식이었습니다.

    이런식으로 각자 선호하는 처리 방식이 달라 코드가 늘어날 수록 이해하기가 조금씩 어려워졌고 코드 스타일에 대해서 어느정도 합의가 필요하다는 생각이 들었습니다.

  • 트러블 슈팅과 배운 내용의 정리

    프로젝트를 진행하면서 공부했던 내용들이 문서화가 잘 되지 않은 점이 아쉽습니다.

    예를 들어 CI/CD를 구축했던 과정이나 스프링 시큐리티를 적용했던 과정들이 문서화가 되었다면 해당 내용을 잘 모르는 팀원들이 정리한 내용을 읽으면서 학습한 내용을 공유할 수도 있고 에러가 발생했을 때 이해한 내용을 바탕으로 도움을 줄 수 있었을 텐데라는 아쉬움이 남습니다.

  • 시간 문제로 인한 부족했던 기술적인 고민

    초기에 같이 기본적인 도메인이나 시퀀스 다이어그램을 작성하지 않은 상태여서 작업속도가 잘 나지 않았고 두분이 취업하게 되면서 시간적인 압박을 많이 느끼게 되었습니다.

    그러다보니 테스트 코드 작성이나 로직에 신경을 많이 쓰지 못했고 일단 빠르게 구현하자라는 방향으로 진행하게 된 부분이 아쉬웠습니다.

• 연우

  • 노션에는 스프린트를 1,2로 나누어 진행하였으나 Jira 에서는 스프린트1,2를 통합해버린것이 아쉽습니다.
  • 초반에는 문서화를 잘 해보고자 템플릿을 만들고 문서를 작성하였으나, 추가적인 잦은 회의가 발생하고, 또 문서화 책임자를 명확하게 정하지 않음에 따라 불충분한 문서를 갖게 되었습니다. 책임자 뿐만 아니라 회의 이후 빠진 내용이 있다면 팀원들이 채워주는 시간 또한 필요했던 것 같슴다
  • 요구사항만을 작성하고 , 시나리오에 대한 작성, 시퀀스 다이어그램 등을 하지 않음에 따라 다른 팀원의 코드를 볼 때면, 코드로 상황을 이해해야 했습니다 . 따라서 코드리뷰에 상당한 시간이 걸리기도 했습니다. 다음 프로젝트 때는 시나리오와, 시각적인 다이어그램을 작성하는 과정이 있으면 좋겠다고 생각했습니다.
  • 구현 난이도를 낮추기 위해 erd 설계하는 과정에서 많은 간소화가 이뤄졌습니다. 양날의 칼 같습니다. 덕분에 구현이 쉬워진 부분이 존재하나, 하나의 도메인 내에 너무 많은게 포함되기도 하고, 추가적인 기능이 필요할 때 이를 구현할 수 없는 상황도 존재했습니다.
  • 도메인에 대한 분석이 부족 하였던 것 같습니다.

🧑‍🎓 배운 것(Learned)

• 용철

  • 의견을 낼때는 뒷받침하는 내용을 준비하자

    회의시에 가장 많이 겪었던 문제로 이렇게 하면 어떨까? 라는 상황이었습니다. 의견을 낸사람도 해당 내용에 대해서 지식이 많이 없는 상태에서의 제안은 오히려 혼란만 가중시키게 되었고 이에 대한 내용에 대한 논의를 하느라 회의가 계속해서 길어지게 되었습니다.

    이런 상황을 겪고 나니 앞으로 어떤 부분을 제안하려면 미리 관련 내용을 준비하고 해당 내용을 공유하며 제안하는 것이 좋겠다라는 생각이 들었습니다.

  • 공통적으로 사용되는 부분은 미리 작성하자

    프로젝트 시작 후 처음에 속도가 거의 나지 않던 상황이 있었는데 이런 상황이 벌어지게 된 이유가 공통적인 부분이 미리 작성하지 않아서 다른 기능들(평가, 댓글)이 핵심 기능들(유저, 판매글)이 완성되는 것을 기다리느라 이런 상황이 벌어지게 되었다고 생각합니다.

    앞으로는 API 설계 내용과 시퀀스 다이어그램을 통해 알 수 있는 부분을 미리 작성하여 DTO와 각 계층별 인터페이스들이 완성된 상태에서 진행하면 좋겠다는 생각이 들었습니다.

  • 협업 중 발생하는 git 충돌 대처

    각자 코드를 작성하면서 같은 파일을 수정하는 경우가 많았고 이 때문에 conflict가 나는 상황을 자주 겪었습니다.

    처음에는 conflict 처리를 어떻게 해야하는지 감을 못잡았지만 처리할 상황이 많았다보니 나중에는 간단하게 처리할 수 있었고 git stash 같은 명령도 쉽게 사용할 수 있게 된 것 같습니다.

  • 가능한 것과 현실적으로 어려운 것을 빨리 분류하자

    회의 중에 다양한 의견이 많이 나왔는데 이런 거는 적용해보면 좋겠는데 하는 내용이 많았고 일단 해보자라는 방향으로 많이 결정되었습니다.

    하지만 해당 내용을 잘 아는게 아니다보니 공부하는데 많은 시간을 쏟게 되고 정작 중요한 코드에 신경을 많이 못쓰게 되는 상황이 벌어졌습니다.

    이를 개기로 잘 모르고 어려운 내용의 경우 보류하고 시간이 남는다면 하는 방향으로 진행하면 좋겠다는 생각이 들었습니다.

  • 회의, 정책 등의 문서화의 중요성

    프로젝트를 진행하다보니 회의했던 내용들과 코드 컨벤션 같은 내용이 제대로 문서화 되지 않아 계속해서 같은 얘기가 나오고 이를 통해 문서화하여 해당 내용을 계속해서 확인할 수 있게 하는 것이 중요하다는 것을 깨달았습니다.

  • API 설계, ERD 설계등 초기 설계의 중요성

    API 설계나 ERD 설계, 시퀀스 다이어그램 작성과 같은 초기 설계를 너무 대충하게 된다면 앞으로 프로젝트를 진행하면서 수정되는 사항이 기하급수적으로 늘어나고 이게 시간을 많이 잡아먹는 다는 것을 깨달았습니다.

    다음번에는 개발 전 설계할때 시간을 많이 사용 해야 할 것 같습니다.

• 연우

  • 여러 도메인이 얽혀 있는 부분에 대해서는 초반에 작업을 프로토타입 으로라도 완료해야 한다는 것을 배웠습니다. 이 과정에서는 해당 부분에 엮여 있는 모두가 적극적으로 함께 참여하는것이 중요하다고 생각하게 되었습니다.
  • 팀 작업에 있어 작업 초기에 설정해야 하는 부분들이 존재함을 배웠습니다. (ex 특히 DTO..)
    • 필요한 것이 존재한다면 다른 도메인 담당자에게 이를 요청 할 줄도 알아야 한다는 것을 배웠습니다
  • 위에서도 언급되었지만 문.서.화 가 매우 중요하다는 것을 배웠습니다 🥲
  • 이미지를 업로드하는 도메인이 두가지 존재하여 이들에 대한 공통적인 인터페이스를 구현해보는 경험을 하였습니다. 흠이 많은 것 같지만, 공통기능에 대한 인터페이스를 작성하는 것은 좋은 경험이었습니다.
  • 요구사항에 대한 우선순위를 부여하는 것의 중요성을 배웠습니다

🥺 원했던 것(Longed for)

• 용철

  • 테스트 커버리지 100%

    처음에는 테스트 코드 작성에 적극적이었고 유닛 테스트 작성 후 통합 테스트를 작성하고 인수 테스트를 통해 최대한 빈틈없는 테스트 코드를 작성하고 싶었습니다.

    하지만 초기에 생각보다 업무 분담이 잘 이루어지지 않았고 시간에 쫓겨 테스트 커버리지를 80프로 밖에 달성하지 못했습니다.

    다음 프로젝트때는 TDD로 개발을 진행하여 테스트로 높은 커버리지를 달성하고 싶습니다.

  • 원활한 소통

    처음 원활한 소통을 위해 JIRA와 같은 협업툴과 notion을 이용하여 필요한 만큼만 최소한의 회의를 하고 나머지는 문서화시켜서 원활한 소통을 하고 싶었지만 회의전 준비가 덜 된 상태에서 회의를 하다보니 회의는 길어졌고 해당 내용이 문서화가 잘 되지도 않았습니다.

    이 경험을 바탕으로 회의전 필요한 자료를 준비하는 것과 문서화의 중요성을 깨달았습니다.

  • 컨테이너를 활용한 인프라 환경 구축

    인프라쪽에 관심이 많아 환경을 구축하는 것에 관심이 많았습니다. nginx를 이용한 무중단 배포 환경이나 도커를 이용한 컨테이너화를 하고 싶었지만 해당 내용을 공부하고 적용하는데 시간이 많이 지날 것 같아 인프라 환경은 간단하게만 구축하고 최대한 코드의 품질을 높이는 방향으로 진행했습니다.

    다음에는 프로젝트전에 미리 공부하고 금방 적용할 수 있도록 준비하고 싶습니다.

  • 프로젝트의 특별한 아이덴티티

    처음에 당근마켓 클론이라는 주제를 가지고 시작했을때 당근마켓이 가지는 특별한 아이덴티티가 무엇일까라는 생각이 먼저 들었습니다.

    그리고 현재 위치기반으로 가까운 위치의 게시글들을 보여주는 기능이 차별점이라고 생각해서 이번 프로젝트에 이부분을 적용하고 싶었지만 시간적인 문제로 적용하지 못했습니다.

    이번 프로젝트에서 우리만의 특별한 아이덴티티가 없었던 것이 아쉬움이 남습니다.

• 연우