[회고] 엘리스에서 1차 프로젝트를 마치고 작성하는 회고록

📖 엘리스에서 1차 프로젝트를 마치고

🐾 반려in이란?

• 국내 반려 인구 1500만 명 시대로 접어들었지만 그에 따라 유기되는 동물 또한 증가하고 있다는 기사를 접하게 되었다.
• 이러한 상황으로 펫샵이 아닌 보호소를 통해 유기 동물 입양을 독려하고 권장하는 "사지 말고 입양하세요"라는 캠페인이 진행되고 있다.
• 이러한 상황이 조금이나마 개선되기를 바라며 유기 동물을 입양에 관심 있는 사람들에게 정보제공 및 교류할 수 있는 커뮤니티를 제작하기로 결정했다.

GitHub - h1jun/Pets-in: Pets-in

 

✍ 프로젝트에서 담당한 기능 - FrontEnd

• [반려 이야기] 게시판 - 상세 페이지 기능 개발
• [반려 이야기] 게시판 - 댓글, 대댓글 기능 개발

 

📝 무엇을 배웠는가?

• 이번 프로젝트는 애자일 방식으로 진행된 첫 팀 프로젝트여서 기술적인 성장뿐만 아니라 협업 능력에 대해서 많은 것을 배울 수 있었던 시간이었다.

 

📕 핵심 기능과 부가기능의 구분

• 혼자 토이 프로젝트를 진행할 때는 구현할 기능을 리스트업 하고 하나씩 해결해 나갔다.
• 반면 팀 프로젝트를 진행할 때는 시간이 한정적이다 보니 핵심 기능과 부가기능을 나눠서 구현 우선순위를 정했다.
• 이렇게 나누는 작업을 반복적으로 하다 보니 핵심 기능과 부가 기능을 나누는 안목이 생겼다.
• 또한, 프로덕트의 비즈니스 로직이 보이기 시작했다.

 

📕 오버스펙은 금물

• 코드를 작성할 때는 유지 보수성 좋게 유연하고 확장성 있게 설계하는 것이 좋다고 생각하고 그것이 좋은 프로그래밍 방법이라고 생각했었다.
• 하지만 프론트엔드, 백엔드 코치님이 동일하게 하셨던 말씀 중 하나는 미래에 서비스 규모가 커지는 것을 생각해서 유연하고 확장성 있게 설계하는 것이 좋지만 때로는 애플리케이션이 작은데 너무 오버 스펙이라면 오히려 독이 될 수 있다. 자신의 상황을 잘 판단해서 결정을 내려야 된다.라고 말씀하셨다.
• 이 말을 듣고 머리를 한 대 맞은 느낌인 거 같았다. 오버 스펙은 독이 될 수 있다. 정해진 시간과 한정적인 자원을 가지고 서비스를 론칭해야 할 때 상황을 정확하게 바라보고 분석한 뒤 기술 스택과 구현 방법을 결정해야 한다. 그 기술이 좋은 것은 맞지만 구현하는데 시간이 오래 걸려서 마감을 못 지킨다면 그 기술을 우리 서비스에는 적합하지 않을 수 있다.
• 이전에는 사람들이 많이 쓰니까~ 이게 편리하다고 하니까~ 이게 좋다고 하니까~ 이런 식의 생각으로 기술을 사용하고 그랬는데 이번 프로젝트를 통해 각자의 상황을 잘 판단해서 선택하고 설계하는 것의 중요성을 깨달았다.

 

📕 소통의 중요성 및 설득하기 위한 지식의 이해도

• 현재 프로젝트가 SSR으로 진행되고 있는데 프론트엔드와 백엔드의 업무 경계점에 대해서 서로 다르게 생각하고 있었다.
• 초반에 기술 스택과 구현 방식 등을 명확하게 하고 가야 했는데 미숙했다. 수업 때 pug를 사용하는 SSR 방식으로 학습했다 보니 누군가는 SSR 방식을, 누군가는 CSR 방식을 생각하다 보니 협업 과정에서 미스 커뮤니케이션이 발생했다.
• A라는 기능을 프론트엔드에서 동적으로 처리하는 거로 생각했는데, 백엔드에서 ejs 내에서 처리를 하거나 등의 의사소통 문제가 발생했다.
• 이러한 상황을 겪으면서 나의 문제점을 발견하였다.
• 서로 생각하는 점이 다를 수 있으며 내가 말하는 말이 무조건적으로 옳지는 않다. 하지만 내 생각의 밑받침이 되는 지식의 깊은 이해도를 가지고 있다면 적어도 설명을 하고 설득을 할 수 있을 것 같은데 그렇지 못했다.
• 내가 보유하고 있는 지식의 자신감이 없었던 거 같다. 누군가에게 설명하고 설득할 수 있도록 기술에 대한 깊은 이해를 하도록 공부를 해야겠다고 결심했다.
• 이러한 고민 속에서 회의를 통해 나온 결론은 전체 페이지는 SSR으로 보여주고 일부 페이지의 세부 내용을 프론트엔드에서 동적으로 구현하기로 결정했다.

 

📕 도식화를 통한 생산성 향상

• 이번 프로젝트를 진행하면서 실천하려고 했던 점 중 하나는 바로 키보드 위에 손을 올리지 않기였다.
• 대신 머릿속에 생각을 아이패드로 정리했다. 즉, 나의 생각을 그림과 글로 적어가며 어떻게 구현할 것인지, 순서는 어떻게 할 건지에 대해 도식화하였다.
• 이러한 작업을 거치면 내가 구현할 기능의 순서가 보이고 잘못 생각했던 점이 드러나고 더 좋은 아이디어가 떠올랐다.
• 초반에는 작업 속도가 느려 보일 수 있지만 시각화한 것을 바탕으로 코딩을 하니 삽질하는 시간이 줄어들며 생산성을 높일 수 있었다.

변경 전 / 변경 후

• 폴더 구조를 페이지별로 나누고 재사용할 수 있는 기능들은 하나의 폴더에 넣기로 결정했다.

 

 

📝 프로젝트 중 마주친 고민사항

📕 BEM 방식 도입

• CSS 프레임워크는 사용하지 않고 BEM 방법론을 도입하기로 했다. 누구나 클래스명만 봐도 어떠한 역할을 하는지 파악하며 유지 보수를 높이기 위함이다.

<div class="comment-feed__input">
    <div class="comment-feed__content">
        <textarea class="comment-feed__textarea" placeholder="댓글을 입력하세요"></textarea>
    </div>
    <div class="comment-feed__submit">
        <button class="comment-feed__button" type="submit">등록</button>
    </div>
</div>

 

📕 자바스크립트 동작 방법

• 자바스크립트를 어떻게 동작시킬지에 대해서 고민했었다. 각 페이지에서 해당되는 스크립트 파일만 링크 걸어서 동작시킬 것인지 아니면 router.js 라는 파일을 모든 페이지에 태그 해주고 location.pathname으로 페이지를 구분해서 해당 스크립트를 동작시킬 것인지를 고민했다.
• 낮은 결합도와 높은 응집도를 갖도록 구현하려고 하다 보니 생긴 고민이었는데 자칫 잘못하면 오버 엔지니어링이 될 수 있으므로 router.js 내에서 관리하기보다는 해당 페이지에 맞는 스크립트를 만들어서 <script> 링크를 넣기로 결정했다.

 

📕 게시글/댓글 작성자만 수정 및 삭제 버튼 활성화(feat. 함께 고민하는 재미)

• 게시글/댓글 작성자만 수정 및 삭제 버튼을 보여주는 부분을 어떻게 처리할지 고민하고 있다가 백엔드 분에게 고민사항을 공유했다. 그리고 짧은 대화 속에 해결 방법을 찾았다.
• 고민사항은 header를 포함한 부분만 ejs로 서버에서 렌더링 해 주고 있고, 게시글 상세 내용과 댓글은 동적으로 생성해 주고 있다. 페이지 전체를 ejs로 처리하면 비교적 쉽게 해결할 수 있는데 세부 내용을 동적으로 처리하다 보니 생겼던 고민이었다.
• 그리고 대화는 유저 정보를 어떻게 가져오느냐에서 출발했다. 게시글과 댓글 태그에 작성자의 id값을 넣어주고 백엔드에서 로그인 객체를 넘겨주면 해당 id값들을 비교하여 일치하는 부분에만 수정/삭제 버튼을 보여주는 식으로 결정했다.
• 혼자 고민할 때는 방법이 떠오르지 않았는데 백엔드 분과 대화하니까 짧은 시간에 해결 방법을 찾았다. 상대방의 의견을 듣고 떠오른 아이디어를 말하고 그 아이디어에 대한 문제점을 지적받고 또 그 문제의 해결 방법을 찾는 순으로 반복하다 보니 해결 방법을 도출하였다. 때론 구글링보다 효과적인 방법이라고 생각한다.

 

📕 이벤트 위임을 통한 문제 해결

• 새로 생긴 요소에 이벤트가 적용 안 되는 것을 발견하였고 이벤트 위임을 통해 문제를 해결했다.

const clickCommentToolBox = () => {
  const commentUl = document.querySelector(".comment__list");

  commentUl.addEventListener("click", (e) => {

    if (e.target.classList.contains("tool__update")) {
      e.preventDefault();
      ...
      ...

 

📝 아쉬웠던 점

• 마감 직전에 큰 오류를 발견해서 주요 로직을 변경하는 상황이 발생했다.
• 각 페이지는 서버에서 내려주고 안에 내용을 동적으로 그려주는데 댓글/대댓글 작성 시 db에 저장되는 id값을 가져와서 수정 및 삭제 버튼을 넣어줘야 되는데 이 부분을 너무 늦게 발견했었다.
• 마감은 다가오고... 새벽에 발견해서 백엔드 분들에게 해당 api 수정 요청하고 작업을 진행하기에는 뒤에 남은 작업들이 많아서 댓글/대댓글 작성 시 새로고침 해주는 방향으로 코드를 수정했다. 이전에 1~2일 동안 작업했던 코드를 다 지워야 하는 상황이라 마음이 아팠다.
• 왜 이런 실수를 발생했을까에 대해서 생각을 해봤다. 어디서부터 잘못된 것일까?
• 이전에 혼자서 오픈 api를 사용하여 미니 프로젝트를 만들 때 get 방식만을 사용했기 때문에 post나 delete, put 요청을 한 번도 보낸 경험이 없었다. 항상 저장되어 있는 값들만 가져와서 사용했기 때문에 데이터 post 방식을 경험하지 않아서 발생했던 실수였다.
• post 요청을 받아서 동적으로 화면을 그려주는 경험을 했다면 이 점까지 고려해서 설계하고 구현했을 텐데 아쉬웠다.
• 그래도 이번에 이런 경험을 할 수 있어서 다행이다. 다음 프로젝트 때는 이전에 경험했던 에러까지 생각해서 설계 단계에서 고려하고 구현을 할 수 있으니까!

 

💡 총 회고

• 이번 프로젝트를 통해 프로덕트 오너십, 상황에 맞는 기술 및 구현 방법 선택, 핵심 비즈니스 로직 찾기, 소통의 중요성 등 많은 것들을 배울 수 있었던 소중한 시간이었다.
• 또한, 설계의 중요성을 느낄 수 있었던 프로젝트였다. 탄탄한 설계를 기반으로 프로젝트를 진행한다면 수정사항이 생겨도 큰 흔들림이 없이 나아갈 수 있다고 생각이 들었다. 초반 마크업 작업하는 것도 중요하다. Vanilla JS에서 마크업 구조가 바뀌면 css도 살짝 뒤틀리고 js에도 수정해 줘야 할 사항들이 하나둘 생기기 시작했다.
• 이번 프로젝트에서 함께 문제를 고민하고 해결해 나가는 과정을 통해서 개발이 재밌어졌다. 조직의 개발 문화가 왜 중요한지도 깨닫게 되었던 프로젝트였다. 함께 즐겁게 개발해야 생산성도 올라가고 개인의 성장이 조직에게 기여할 수 있다는 것을 느끼게 되었다.

 

📌 기록

• 프로젝트 1일 차 기록
• 프로젝트 2일 차 기록
• 프로젝트 3일 차 기록
• 프로젝트 4일 차 기록
• 프로젝트 5일 차 기록
• 프로젝트 6일 차 기록
• 프로젝트 7일 차 기록
• 프로젝트 8일 차 기록
• 프로젝트 9일 차 기록
• 프로젝트 10일 차 기록