[Memoir] 개발의 민족

🤨 개발의 민족? 그게 뭐야??

기존의 배달의 민족 앱 서비스가 피씨에서 사용할 수 없다는 면이 사용자 접근성에서 좋지 않다고 판단했고 이에 배달의 민족 웹 서비스를 만들고자 했다. 웹 접근성 준수가 주요 목적으로 HTML5, CSS3, Javascript를 사용하여 1주간의 프로젝트를 진행했다.

😧 5명이서 협업이라니?!

스타트업을 근무하면서 협업의 기회가 많이 없었기에 다인원의 협업이 긴장되었지만 개발에 대해 논의할 생각에 설레기도 했다. 5명의 사람들과 프로젝트 기획부터 개발까지 진행하면서 문제를 어떻게 상의하고 진행 상황을 파악할 수 있을까? 라는 생각이 들었다. 그 전까지는 혼자서만 레포지토리를 사용하다보니 협업할 때 깃의 사용법에 대해 모르는 점도 많았기 때문이다. 그래서 팀원들과 이야기한 결과 아래와 같은 규칙과 협업툴을 사용하기로 했다.

1. 협업툴
   • Jira : 맡은 부분 페이지 및 기능 단위로 등록하여 관리
   • Figma : 웹 UI 기획 및 의견 공유
2. git convention
   • branch : 각자 이름으로 작업하여 push
   • comment : [타입][페이지][세부 설명] 형식으로 표기.
     (타입은 feat / fix / bug 등 미리 정해둔 6가지 중 하나로 표기)
3. 의문점과 오류 발생시 바로바로 상의하기
   
   

😎 협업 후 느낀 점

• 진행 상황을 파악할 수 있는 협업툴
  위와 같은 규칙으로 1주동안 개발을 진행한 결과, 협업툴의 편리함과 프로젝트의 진행 상황들을 알 수 있다는 이점을 알았다. 아래처럼 보다시피 개개인의 파트 진행 상황을 파악할 수 있어 도움이 필요한 파트에 붙어서 같이 작업할 수 있었다. 원래 나의 파트는 쇼핑 라이브와 비디오 페이지였다. 주어진 페이지를 끝내고 시간안에 작업을 마무리하기 위해 남아있던 주문 상세 페이지를 구현하였다.
  

• git convention의 중요성
  git convention의 경우 적응하는데 시간이 걸렸었다. 항상 git comment를 페이지단위로 상세 설명으로만 입력을 하고 타입까지 붙여서 쓴 적은 없었기 때문이다. 그러다보니 왜 쓰는 거지?라는 의문이 들었고 프로젝트가 끝나고나서야 git convention의 중요성을 느꼈다. git commit을 살펴보는데 타입을 가장 먼저 명시를 해놔서 이 commit이 새로운 기능을 추가한 건지, 리팩토링이 된 것인지를 바로 알 수 있었고 찾고자 하는 부분도 해당 타입을 검색하여 금방 찾을 수 있었다.
  

• 모르면 바로 물어보고 같이 해결하기
  댓글 mock data를 만들어서 실시간 채팅이 일어나는 애니메이션을 구현하려고 했다. 객체 데이터와 for ...of문을 사용하여 데이터를 하나씩 가져와서 출력하려 했다. 하지만 무엇이 문제였는지 10개의 데이터가 6개만 출력되는 오류가 발생했다. 맨 처음에는 for ...of문이 잘못된 줄 알았었다. 하지만 객체이기 때문에 for ...of문을 써야되는데 하고 고민하다가 결국 팀원에게 SOS를 요청했다. 팀원과 같이 객체 데이터부터 살펴보면서 논의하다가 mock data 객체 안에 같은 키를 여러번 선언한 게 문제였다. 이에 팀원과 이중 배열로 데이터 구조를 바꾸었고 이를 해결할 수 있었다. 혼자 해결할 때는 제대로 파악하기 어려웠는데 부족한 부분을 팀원이 메꾸어주고 내가 무엇을 모르고 어떤 부분을 알아가야하는지 이정표의 역할을 해주었다. 이게 바로 협업을 하는 이유가 아닐까 싶다.

🧐 프로젝트를 통해 성장한 점

• 웹 접근성
  웹이나 앱을 사용하다보면 시각적인 부분이 강하기도 하고 마우스나 터치 패드로만 사용을 많이 하다보니 키보드를 이용하는 사용자에 한해서만 더 신경을 쓰면 된다고 생각했었다. 하지만 웹 접근성을 배우며 공부를 해보니 전자 누름식같은 입력 보조 장치, 스크린 리더기 등을 사용하여 컨텐츠를 제공받는 경우들이 있다는 것을 알게 되었다.

  • Markup
    이전에는 UI에 따라 마크업 구조를 고민하면서 시멘틱 마크업을 준수하려고 했었다. 하지만 웹 접근성에 대해 알고 스크린 리더기를 통해 컨텐츠를 사용해보면서 하나의 문서처럼 사용자에게 어떤 컨텐츠이고 어떤 구성인지를 미리 알려줄 수 있는 태그와 마크업 구조를 적용해야한다는 것을 배웠다. 예를 들어 스크린 화면상 로그인, 회원가입이 있고 그 다음에 로고가 보여지는 서비스가 있다. 이때 로고보다 다른 컨텐츠를 먼저 마크업하게되면 스크린리더 사용자는 어떤 서비스의 로그인, 회원가입인지 모르게 될 것이다. 고로 이런 부분을 염두하여 모든 사용자들이 환경과 관계없이 같은 컨텐츠를 이용할 수 있는 서비스를 만들어야겠다.

  • WAI-ARIA
    WAI-ARIA 처음 접한 것은 온라인 강의를 들으며 aria-hidden속성이였다. 이 속성을 쓰면 시각적으로 내용이 보인다고 알려주었지만 사실 그때는 이게 왜 필요한 건지 와닿지 않았다. 하지만 프로젝트에 들어가고 스크린 리더기를 사용해 들으면서 그 필요성을 깨닫게 되었다. 디자인에 맞게 마크업을 하면 '|'과 같은 알 필요없는 정보들이 많았고 aria-hidden을 설정하지 않으면 스크린 리더기는 이 의미없는 정보를 사용자에게 전달하고 있었던 것이다.
    또한 개인 파트인 video관련 WAI-ARIA를 찾아보면서 관련된 속성들이 꽤 있었서 놀랬었다. 사실 비디오같은 부분은 모든 사용자에게 똑같이 제공하는 게 어려워서 넘어가는 부분일꺼라 생각했다. 나의 안일한 생각에 반성하며 웹 접근성을 준수하기 위해 생각의 관점을 바꿔서 접근하야되겠다라는 것을 느꼈다.

• webp, webm
  이미지나 비디오는 트래픽을 많이 잡아먹고 다운로드가 늦게 되면 UX적으로도 좋지 않기에 최적화를 해야했다. 이 해결책으로 구글에서 만든 이미지 및 미디어 포맷 webp, webm를 알게 되었고 이는 JPG와 PNG, GIF 등보다 적은 용량을 차지한다. 단점이라면 IE에서 지원을 하지 않는 다는 것이지만 IE가 서비스 지원이 종료됨에 따라 서비스에 적극적으로 적용할 필요가 있다고 생각했다.
  

• 객체의 개념과 특징
  부끄러운 이야기지만 회사에서 근무시 퍼블리셔에서 프론트업무로 넘어가면서 객체를 JSON형태로만 접해보고 제대로된 개념에 대해서 알지 못했었다. 그러다보니 객체를 다루는 것이 어려웠고 앞의 협의에서 느낀 점과 같은 오류의 원인을 제대로 파악하지 못했었다. 하지만 실패는 성공의 어머니! 이 덕에 객체는 같은 키가 있으면 마지막으로 선언된 값이 덮어씌어진다는 중요한 특징을 알았고 앞으로 객체의 문제들을 해결할 수 있을 것이라고 기대해본다. (회고를 다시보는 지금 시점에서 이건 부끄러운 실수였지만 이 과정 덕에 딥다이브를 공부하면서 객체의 특징을 이해할 수 있었고 잊혀지지 않았다.)

🥲 아쉬운 점

• 기록의 아쉬움
  팀으로 프로젝트 작업을 하면서 Figma를 통한 UI나 Jira로 프로젝트 진행사항도를 보고 이 부분들이 남아있으므로 그 당시 프로젝트를 어떤 식으로 협업하고 진행했는지를 알 수 있었다. 하지만 개인적으로 이슈가 발생했던 부분들과 팀원들과 그 문제를 상의했던 부분을 기록으로 남기지 않아 몇몇 부분들만 기억이 난다는 것이였다. 그러다보니 원인이 무엇이고 고민을 하고 해결책에 어떻게 도달했는 지에 대한 생각의 흐름을 알 수 없었다. 이에 다음 프로젝트를 진행시 Readme에 기록을 틈틈히 남겨야겠다는 생각을 다짐해본다.

🍑 소감

1주 짧게 한 프로젝트였지만 배웠던 웹 접근성을 적용해보며 어떻게 활용되는지를 이해하게 된 프로젝트였다. 그리고 실무 경험이 있다는 게 프로젝트 기능을 어떻게 구현해야 한다던가 시간 안에 빠르게 구현할 수 있다는 것은 좋은 장점이 되었다. 하지만 늘상 개념이 부족하다고 생각했었는데 이번에 확실하게 느끼게 되었다. 이제 다가오는 자바스크립트 딥다이브 수업을 통해서 확실하게 개념을 이해하고 좋은 코드를 구현할 수 있는 개발자가 되도록 선구안을 가져야겠다. 부족한 부분을 부끄러워하지말고 해결하려고 노력하자!