본 포스팅은 Swap() 프로젝트를 하면서 있었던 일들에 대해 회고 차 작성한 글입니다.

각자 학업 또는 취업준비를 하면서 진행했던 프로젝트인 Swap()은 일주일에 많은 시간을 할애하지는 못하고 조금씩 더디지만 차근차근 진행이 되었었다. 비록 지금은 누군가는 취업을, 누군가는 취준을 하며 개발이 잠정 중단된 상태이지만 이 프로젝트를 통해 배운 점들이 많은 것 같아 회고로 남기고자 한다.

커뮤니케이션 1. 모든 내용과 문제는 공유되어야 한다.

일상 생활에서 커뮤니케이션이라고 하면 목소리와 목소리가 오고 가는 또는 수화로 소통하는 등의 형태를 의미한다. 하지만 개발자들 사이의 의사 소통이라는 것은 코드나 문서 그리고 커밋메시지와 같이 기술적인 형태로 많이 이루어 지는데, 꽤 긴 시간 동안 진행되었던 Swap 프로젝트를 겪으며 이에 대해 더 많은 것들을 느낄 수 있었던 것 같다.

잘 정리된 문서

프로젝트를 진행하면서 전반적인 기획부터 요구사항과 기능명세서 정리, 플로우차트/와이어프레임 제작 등을 문서화 했는데, 이런 정리된 문서를 토대로 마크업을 하고 기능을 구현을 하면 되니 오롯이 개발에 집중할 수 있다는 장점이 있었다.

다만 각자의 일정 탓에 한두달 간 프로젝트에만 집중해 작업하는 것이 아니라 일주일에 한번씩 몇시간 정도 회의하고 개발을 하는 식으로 진행하다보니 문서화하는 과정이 너무 늘어지게 되어 이전 내용들을 자주 복기해야하는 일이 벌어졌는데, 현업에서는 더 체계적인 형태로 작업하게 될테니 문서화의 이점이 더 크게 작용할 수 있지 않을까 싶다.

심지어 Swap을 하면서도 결국 늘어졌던 프로젝트 기간 동안 계속해서 진행할 수 있었던 것 역시 디테일하게 문서화를 해뒀던 덕 아니었을까?

디테일한 커밋메시지

Swap팀은 커밋을 남길 때 .gitmessage를 통해 한줄짜리 커밋이 아닌 조금 더 디테일하게 커밋을 남기고자 했다. 이렇게 했을 때 다른 사람이 내 커밋 내용을 보더라도 훨씬 더 자세하게 내용을 파악할 수 있다는 장점이 있었고, (노출되는 첫째줄) 커밋내용을 길게 작성하지 않아도 본문내용으로 디테일한 내용 추가가 가능하기에 불필요하게 긴 커밋을 할 이유가 없어졌다. (어떻게든 의미를 잘 요약해 전달하려는 노력이 필요없어졌다.)

이런 사소한 차이만으로도 개발을 하면서 신경써야할 부분이 하나는 줄어드는 느낌이었다. 뿐만 아니라 다른 동료 개발자들이 굳이 번거롭게 직접 뭐가 바뀌었는 지 물어보는 일들이 줄어들었고 커밋내용을 토대로 대부분의 변경점을 캐치할 수 있게 되었다.

친절한 컴포넌트명 또는 변수명

내가 만든 컴포넌트를 다른 개발자가 사용하게 되는 상황이 있었다. 카드 컴포넌트를 재사용하는 경우였는데, 아토믹하게 분리하고 컴포넌트 이름과 props의 이름 등을 최대한 상세하게 작성했더니 동료개발자가 사용방법이나 구조에 대해 물어보지 않고도 재사용할 수 있었다는 말을 했다.

잦은 커뮤니케이션도 결국 소모적 비용일 수 밖에 없다는 것을 고객센터의 경험에서 크게 느꼈었는데 그렇기에 불필요한 소통을 줄이고 코드로 소통하기 위해서는 이름이 중요할 수 밖에 없다는 생각이 들었다.

가령 매번 다른 사람이 짜둔 함수를 사용할 때마다 그 로직을 파악해서 사용해야한다면 그것만큼 불편한 일이 없을 것이다. (상호 간 확실한 신뢰만 있다면) 함수의 이름만 가지고도 기능의 파악이 가능해야하며, 컴포넌트의 이름만 가지고도 그 용도를 파악할 수 있어야한다는 생각이 들었다. 업무 효율성에서 가장 중요한 부분 중 하나 아닐까?

코드리뷰

처음 swap을 진행할 때만 하더라도 데이터를 다루는 것에 익숙하지 않아 하드코딩되거나 지나치게 제한된 재사용성을 가진 코드를 작성하는 일이 비일비재했다. 이 때 가장 큰 도움이 됐던 것은 함께하는 동료개발자들의 코드리뷰였다. 이 당시는 지금보다 아는 게 적어 코드를 바라보는 시각이 넓지 못했고 그런 이유로 내 코드는 같은 수준에 머물고 있었다.

그런 때에 동료개발자들이 코드리뷰로 알려주는 다양한 접근법과 방법으로 시야를 넓힐 수 있었고 성장할 수 있었다.

코드리뷰에 대한 좋은 경험은 회사에 면접을 갔을 때 항상 회사에 물어보는 단골 질문이 되었다.

코드리뷰도 활발하게 이루어지나요?

서로가 발전하기 위한 가장 중요한 전제조건 중 하나 아닐까 싶다.

PR은 주기적으로

작업을 하면서 어떤 주기나 단위로 PR을 해야하는 지 전혀 감이 오지 않아 한달 동안 작업했던 것을 한번에 PR했던 적이 있다. 지금 생각해보면 대체 왜그랬을까 싶은 아찔한 상황이었으나 다행이도 심각하게 conflict가 발생하는 지점은 없었다. 하지만 이게 실제 상용화된 프로덕트였다면, 그리고 다른 컴포넌트나 로직과 의존성이 강한 것을 개발하고 있었다면 이렇게 말도 안되게 쌓인 commit들을 한번에 PR하는 내 행동은 정말 최악이었을 것이다.

오랜 시간 PR을 하지 않고 묵혀둔 이유는 단순했다. 기능이 완성되지 않았는데 PR을 할 이유가 있나?

하지만 있었다... 역시 경험이 소중하다고 묵혀둔 PR을 한번에 던지고 나니 동료개발자들의 눈총(?)과 많은 conflict를 만날 수 있었으니까.

PR은 조금 더 촘촘하게 할 필요가 있단 것을 깨달은 시간이었다.

커뮤니케이션 2. 주장에는 근거가 필요하다.

협업을 하다보면 어떤 내용을 "주장"하는 일이 많아질 수 밖에 없다. 특정 스택을 도입한다거나, 구현가능성에 대해서 논의를 한다거나 또는 마감 일정이나 스프린트 일정을 짜는 등의 것에도 의견을 주장하는 일이 빈번히 발생한다. 그 과정에서 많은 불화가 발생하는데, 어떤 협업의 과정에서든 서로 의견을 나누는 것은 당연하니 그 의견을 어떻게 나눠야 좋은가를 고민하는 것이 옳은 일이라고 생각한다.

TS 마이그레이션 후기

Swap 프로젝트는 처음에는 JS로 개발이 진행되었다. 이유는 단순했는데, 아직까지 제대로 사용해본 적이 없는 타입스크립트를 프로젝트에 도입하게 되었을 때 온보딩을 위한 시간이 길어질 것 같다는 이유였다. 다들 동의했었고 그렇게 JS로 작업이 진행되었다. 그러다 작업이 한창 진행 중이던 12월 중순 쯤 다시 한 번 TS로 작업해보는 것이 어떻겠냐는 의견이 나왔고 다시 한번 의견은 부결되었다.

당시 TS로 작업하자는 의견 중 찬성 측은, 포트폴리오로도 활용될 Swap프로젝트를 최신의 JD에 맞춰서 개발을 진행하고 지금 해볼 수 있는 것들을 다 해보자는 의견이었고 반대 측은 처음의 반대 이유였던 가파른 러닝커브에 따른 온보딩 기간이 필요하다는 점이었다. (애니스크립트로 개발할 수는 없으니까.) 역시 반대 측의 의견이 더 타당하다고 판단하여 타스로 작업하는 것은 기각되었다.

의견이 팽팽해 JS로 그대로 작업하기로 한 뒤 얼마 지나지 않아 동료개발자 중 한분이 TS로 마이그레이션해도 되는 이유에 대해 의견을 제시했다. 당시 우리가 가장 겁내던 것은 타입스크립트를 사용해보지 않은 개발자들도 있었기 때문이었다. 그렇기 때문에 타입스크립트를 사용하게 되면 당분간 프로젝트가 중단될 수 밖에 없다고 판단한 것이었는데, 타입스크립트는 파일별로 마이그레이션을 하면 된다라는 근거를 가지고 왔고, 이를 충분히 검토한 뒤 타입스크립트로의 마이그레이션을 결정하였다.

다행스럽게도 타입스크립트로 마이그레이션 해보는 과정을 겪은 것은 꽤나 성장에 도움이 되었다. 그러나 이 마이그레이션 과정보다 더 값진 경험은 팀 내 반목 없이 꾸준히 의견들을 내며 근거를 제시해 설득하는 과정을 우리가 겪었다는 점인 것 같다.

TTS를 위해 포스팅 되는 사진 모두에 alt값을 받을 수 있도록 작성해야할까?

웹접근성을 얘기할 때 alt를 작성하는 것에 대해 많이 얘기하게 된다. 개발을 할 때 개발자가 작성하는 alt는 당연히 필수적으로 작성해야하지만, Swap 프로젝트처럼 사용자가 게시물을 올리는 형태라면 alt 값을 일일이 다 받는 것이 맞지 않을까 하는 고민을 했었다. 하지만 이것을 구현하기 위해 자료를 찾아보고 공부를 하는 것에는 당연히 시간이라는 비용이 들기 때문에 구현을 할 지 말 지에 대한 의견을 팀원들에게 물었었다.

나는 이 기능의 당위에 대해 어필을 했고 팀원들은 동의했다. 그래서 구현했었느냐?

결과는 구현하지 않았다. 이유는 단순했는데, 당시 최대한 빠르게 프로젝트를 진행해보자는 의견이 나온 상태였고, 실제로 포스팅되는 게시글의 내용을 토대로 상품에 대한 상태 파악이 가능하다는 점이었다. 그렇기 때문에 사용자가 생겨 그에 대한 니즈가 공식적으로 나왔을 때 기능을 구현하는 것이 좋지 않을까 하는 의견이 지배적이었고, 이를 수용해 우선순위를 가장 낮게 잡았었다.

이 역시 TS 마이그레이션과 마찬가지로 팀 내 서로 근거있는 주장을 통해 의견을 피력한 경우라고 볼 수 있다.

프론트엔드 개발자의 역량

프론트엔드 개발자로서 프론트엔드에 관한 지식을 가지는 것이 제일 중요하다고 생각했었으나 (그것만으로도 벅차기도 했다.) 프로젝트를 하면서 프론트엔드 개발자의 역량이 단순히 프론트엔드 개발 지식만으로 국한되지 않는다는 것을 경험하게 됐다.

피그마에 대한 이해

Swap에서는 플로우차트와 와이어프레임을 위해서 피그마를 직접 사용해야했었는데, 실제 실무 환경에서는 디자이너가 준 피그마 파일을 해석하는데에 조금 더 비중이 있지 않을까 싶다.

하지만 사용할 줄도 알아야 해석도 된다고 했던가?

우리는 정해진 파트를 각자 와이어프레임으로 만들었는데, 구현은 내가 만든 와이어프레임이 아닌 동료개발자가 만든 와이어프레임을 가지고 하도록 했기때문에 사용할 줄도, 읽을 줄도 알아야했다. 1인 외에는 디자인은 모르는 개발자들인지라 피그마를 해석하지도 다루지도 못하는 상태였는데, 한두달 가량을 플로우 차트와 와이어프레임을 만들기 위해 시간을 쏟다보니 다른 사람이 만든 것도 해석이 되는 경험을 했다. 나중에 실무를 하게 된다면 디자이너와 대화를 할 때 어떤 방식으로 소통을 해야하는 지에 대한 이해도도 살짝...증대 하기도 했고!

DB에 관한 지식

물론 지금 당장도 백엔드 개발자가 만든 DB구조를 이해하기도 벅차지만, 당시 프로젝트를 진행하면서는 백엔드 개발자가 팀 내에 없다보니 DB의 구조를 어떻게 갈 것인지, 또 postId를 어떻게 1씩 증가시켜 받아올 지 등의 고민들을 많이 했다. 결론적으로는 도저히 내 머리로는 당장 모르겠다 싶어서 우회책을 생각해내 개발을 진행했지만, 수많은 게시글들이 동시에 작성되었을 때도 그 우회책이 제대로 동작할지는 여전히 의문으로 남아있다. 조금의 여유가 생기면 공부하고 싶은 높은 순위의 공부인데, 데이터 구조에 대해서 알아야 프론트개발도 편해진다는 점을 알아서일까? 소통을 위해서라도 공부해야지 싶다.

---

마무리하며...

늦은 회고를 작성했다. 아마 더 많은 생각들을 프로젝트를 하면서 했던 것 같은데... 너무 많은 시간들이 흘러서 인지 아쉽게 놓친 생각들이 많은 것 같다. 회고를 습관화하는 것도 필요한 것 같다 ㅋㅋ..

프로젝트를 진행하면서 정말 많은 것들을 배우게 된 것 같은데 늦게나마 짧은 회고 남겨본다. 즐겁고 고마운 프로젝트.