이전 글에서 깃허브의 브랜치 전략에 대해 일부 알아봤습니다.

다만 브랜치 전략을 바꾸는 것만으로는 병합 순서와 갯수가 꼬이는 일을 고칠 수 없기에, 이번 글에서는 병합 방식에 대해 알아볼까 합니다.

병합 방식

Git에서는 보통 네 가지의 병합 방식이 존재합니다.

Merge Commit

Merge Commit은 가장 기본적인 병합 방식으로, 브랜치를 병합하기 전 Merge Commit을 생성하는 방식입니다.

병합 후 브랜치 별 작업 내용이 명확히 구분되지만, 불필요한 Merge Commit으로 인해 히스토리가 복잡해지는 문제가 발생합니다.

특히, Hotfix나 Readme edit 등 사소한 커밋에도 Merge Commit이 붙기 때문에 커밋의 갯수가 방대해지고, 그래프 구조가 복잡해지는 문제가 생깁니다.

1 Commit Behind 문제

만약 Merge Commit을 사용하게 될 경우 겪게 될 문제가 하나 존재합니다.

만약 dev 브랜치 --> main 브랜치 와 같은 형식으로 병합을 진행할 경우, main에는 dev 브랜치의 내용과 함께 무조건 Merge Commit이 생성되기 때문에 dev 브랜치는 항상 커밋이 한 개 모자라게 됩니다.

| Test           [main] 
| \              
|  | Test2       [dev]
|  | Test3
|  | Test4
| /
| Merged (이 커밋이 dev 브랜치엔 없어서, dev 브랜치는 항상 커밋이 하나 부족함)

이를 해결하기 위해선 dev 브랜치를 main 브랜치와 동기화해줘야 합니다. git pull origin main을 사용하여 해결 가능합니다.

Fast-forward Merge

Fast-forward Merge는 목표 브랜치의 Head 커밋이 변경되지 않았을 경우 사용할 수 있는 병합 방식이며, 단순히 목표 브랜치의 Head 커밋을 현재 브랜치의 가장 마지막 커밋으로 변경하는 방식입니다.

커밋 파일이 생기지 않아 커밋 내역이 깔끔하고 작업 흐름이 보이지 않기 떄문에 핫픽스 브랜치와 같은 단기 브랜치에는 적합하지만, 목표 브랜치의 Head 커밋이 변경되거나 기록을 남겨야 하는 상황이라면 사용하기 어렵습니다.

Squash Merge

Squash Merge는 브랜치의 커밋들을 한 커밋에 압축하는 병합 방식입니다.

보통 병합 관련 글을 찾아보면 이에 관한 내용이 자주 나오지 않는 편인데, 커밋 기록을 최대한 보존하는 다른 병합 방식과는 정 반대로 모든 커밋 내역을 감추기 때문에 나오지 않는 것으로 보입니다.

하나의 대표 커밋으로 브랜치의 커밋 내역을 나타내기 떄문에 기능 순서대로 커밋 내역을 남겨야 하는 경우에 적합하지만, 반대로 하나의 커밋이 브랜치의 모든 커밋을 의미하기 때문에, 커밋별 롤백이 어려워지게 됩니다.

Rebase Merge

Rebase Merge는 커밋의 순서를 재정렬하고, 다른 브랜치 위에 커밋 내역을 덧붙이는 방식의 병합입니다.

언뜻 보면 Fast-Forward와 비슷하다고 볼 수 있겠으나, Head가 현재 브랜치의 시작점과 같을 경우에만 사용할 수 있는 Fast-Forward와는 달리, 커밋 내역을 재정렬한 뒤 목표 브랜치 뒤에 현재 브랜치의 커밋 내역을 잇기 떄문에 Head가 달라져도 사용할 수 있습니다.

위험성

만약 Rebase Merge를 사용할 경우, 커밋을 새로 생성하여 다시 덧붙이는 방식으로 커밋 내역을 잇기 떄문에 이미 푸시된 값을 변경하는 force push를 사용해야 하며, 병합 후 커밋들의 해시 값이 변경되게 됩니다.

이러한 변경 사항이 실제 협업 중인 브랜치에 적용될 경우 다른 사람들의 작업에서 병합 충돌이나 내역 왜곡 등의 문제를 일으킬 확률이 높습니다.

결론

이렇게 4개의 병합 방식에 대해 살펴보았습니다.

현재 Velog Dashboard 프로젝트에서는 Squash Merge 방식을 사용하고 있지만, 병합 방식에 대해 충분히 이해한 후에도 커밋 순서가 꼬였던 문제에 대한 명확한 원인은 아직 찾지 못한 것 같습니다. (적어도 Squash Merge에서 발생하는 커밋 순서 관련 문제를 아직은 발견하지 못했습니다.)

최근 들어 브랜치 구조를 정리하고 이전처럼 Trunk 형태로 전환하면서 자연스럽게 문제가 해결되었지만, 그 과정에서 이전에 경험한 문제의 원인을 명확히 파악하기 어려워진 점은 아쉬움으로 남습니다.

지난 주말동안 학습을 위해 집에서 소규모 홈서버를 구축했습니다. 단순히 도커까지만 올렸는데도, 처음이다 보니 하루를 꼬박 새워서 구축했던 것 같습니다.

개인적으로 구축을 위한 자료를 조사하면서 알아보기 힘들거나 제 상황에 맞지 않는 자료가 많은 것 같아 나중에 다시 볼 목적으로 글을 남겨두기로 합니다.

구축 과정

구축 과정은 크게 나누자면 '운영체제 설치', '서버 시스템 및 네트워크 구성', '도커 세팅' 으로 나뉩니다.

사실 서버 구축 후 Github action이나 NAS와 연결하는 등 특수한 목적을 위해 진행해야 할 일이 더 있긴 하지만, 당장 급한 건 아니라서 우선은 위와 같은 순서로 진행하였습니다.

운영체제 설치

우선은 서버를 위한 운영체제를 설치해야 합니다. 저는 Proxmox를 선택했는데, 이전에 어떤 선배님이 홈서버에 Proxmox를 사용하시는걸 봤어서 비교적 친숙하기도 하고, 내장된 웹 관리 패널을 통해 쉽게 관리할 수 있을 것 같아 선택하였습니다.

자료가 없는 운영체제

다만 Proxmox가 잘못된 선택일수도 있는데, 생각보다 특정 주제에 대한 한국어 기반 자료가 없으며 있더라도 업데이트가 되지 않은 옛날 자료인 경우가 많았습니다.

그래서 일부 주제에 대해서는 외국 포럼을 찾아가며 알아봐야 하는데, 영어에 능숙하지 않을 경우 영어로 된 문제 해결 방법을 놓치거나 잘못된 방식으로 문제를 해결하는 등의 문제를 조금씩 겪을 수 있어보입니다.

불안정한 무료 레포지토리

또한 Proxmox는 무료 버전을 사용할 경우 No-Subscription 레포지토리를 사용하게 됩니다. 해당 레포지토리는 Enterprise 레포지토리에 비해 덜 검증된 패키지들과 버전들도 업로드되는 레포지토리입니다.

만약 Proxmox의 구독비를 내기 어려워 No-Subscription 레포지토리를 사용하게 된다면 패키지 업데이트 이후 서버가 동작하지 않거나, 예상과 다르게 동작하는 등 이슈가 생길 가능성이 높다고 합니다.

서버 시스템 및 네트워크 구성

서버 시스템 및 네트워크는 위 이미지와 같이 구성하였습니다. 홈서버이다 보니 큰 복잡함 없이 최대한 단순하게 구현되어있으며, SSH 접속 대신 VPN으로 연결된 웹 관리 패널을 통해 관리하는 방법으로 작업할 수 있도록 설정하였습니다.

(사실 SSH 접속이 제일 간단하지만, 지식이 부족한 상황에서 빠르게 구축해야 하다 보니 어쩔 수 없이 VPN과 웹 관리 패널을 통한 관리 방식을 선택했습니다.)

통신사 공유기 이슈

사실 원래는 네트워크 구조가 위 형태였으나, 집 내부에서만 접근이 가능하고 외부에서는 포트포워드된 프록시조차 접근이 불가능한 문제가 있었습니다.

어떤 방식으로도 해결되지 않아 2차 공유기를 1차로 옮기고, 대신 허브를 달아 랜 케이블을 분배하는 방식으로 변경하였더니 정상 동작하였습니다.

현재는 통신사 공유기가 내부적으로 80 또는 443 포트를 공유기 관리 페이지에 할당하거나, 80 또는 443포트로 들어오는 요청을 전부 차단한 것으로 추정하고 있습니다.

도커 세팅

도커 세팅은 어렵지 않으나, LXC에서의 도커의 사용을 추천하지 않는 의견이 많아 조금 고민되는 부분이었습니다. 다만 현재 서버로써 사용하는 컴퓨터의 사양 (i5-4xxx, 8GB 램) 을 고려하여 비교적 가벼운 LXC 기반 도커를 사용하기로 선택하였습니다.

새로운 LXC 컨테이너 생성 및 패키지 업데이트 후 아래 명령어를 통해 docker와 docker compose를 설치해주었습니다.

curl -fsSL get.docker.com -o get-docker.sh && sh get-docker.sh
apt install docker-compose # 사실 이미 통합됬지만, 그 사실을 몰라서 그냥 설치했습니다

연결 Timeout 이슈

분명 DNS와 네트워크 설정을 정상적으로 완료했음에도 지속적으로 컨테이너 내부에서 Timeout 또는 Hostname not found 이슈가 발생하는 경우가 있었는데, 확인해보니 통신사 DNS에서 해당 서비스의 IP를 허용하지 않아 발생하는 문제였습니다.

DNS를 cloudflare의 보조 DNS인 8.8.4.4 로 변경하니 해결되었습니다. (주 DNS인 8.8.8.8의 경우 트래픽이 많은건지, 중간에 잠깐식 끊기는 경우가 있었습니다.)

계획과 목표

패키지가 이미 업데이트된 이미지 생성

지금까지는 항상 LXC 컨테이너를 새로 만들때마다 apt update 명령어를 통해 패키지를 업데이트해주고 있었는데, 이 작업이 약 3~40분을 소요하면서 생각보다 시간 낭비가 꽤 큰 문제점이 있었습니다.

그래서 추후 패키지를 업데이트한 뒤, 해당 컨테이너를 이미지화하여 재활용하는것을 계획으로 잡고 있습니다.

Github Action과의 연결

현재 서버에 도커 컨테이너만 생성되어있으나, 추후 Github action와 연결하여 교내 배포 서비스인 Xquare의 소형화 버전을 만드는 것을 목표로 하고 있습니다. 물론 Proxmox의 불안정한 버전을 사용하는 소규모 홈서버인 만큼, 다른 사람들한테 공유하지 않고 제가 사용하기 위함입니다.

조금 더 안전한 환경

현재는 리버스 프록시와 VPN으로 도커 컨테이너와 관리자 페이지에 대한 보안을 일부 확보하고 있으나, 추후 웹 관리 패널에 https 적용, 방화벽 적용 및 인증서 기반 SSH 연결도 설정하여 현재보다는 조금 더 안전한 환경을 만드는 것을 계획중입니다.

결론

사실 대규모의 안정적인 서버도 아니고, 부품들조차 야매(액정 없는 인텔 맥북 기반 서버, 불안정한 무료 Proxmox, 서랍장 구석에 박혀있던 공유기)이지만, 서버 및 네트워크 지식 학습 용도로는 꽤 알맞았던 것 같습니다.

앞으로 이 서버를 통해 네트워크 심화, CI/CD 개념 등 이전에 배우고 싶었던 것들을 배워볼까 싶기도 합니다.

서론: 고도화

최근 Velog Dashboard 프로젝트를 다시 진행하며 초창기의 브랜치 구조에 조금 불편함을 느껴 점진적인 고도화를 진행하고 있습니다.

다만 별도의 공부 없이 그냥 불편함만 개선하는 방식으로 진행하고 있었는데, 추후 팀원이 바뀌거나 머지가 잘못되어 브랜치가 꼬이는 경우에 해당 브랜치를 지우기 전까지 문제를 안고 가야 하는 경우가 있어 조금 더 체계적인 방식의 고도화와 구조를 필요로 하게 되었습니다.

마침 이번 스프린트동안 머지가 잘못되어 '1 behind of' 문제가 다시 발생하고 있기도 하고, 취업을 위한 정리의 시기가 다가오고 있기도 해서, 브랜치 구조를 처음부터 다시 세울 목적으로 정리해보기로 합니다.

플로우

깃허브에는 다양한 브랜치 흐름 (플로우) 가 있습니다. 플로우는 브랜치들이 어떻게 생성되고, 병합되며, 배포로 이어지는지에 대한 일련의 과정을 의미하며, 대표적으로 GitHub Flow, GitLab Flow, Git Flow가 있습니다.

Github Flow

Github Flow는 Trunk-Based Development 기반의 플로우로, 중앙 브랜치를 생성한 뒤 해당 브랜치에서 Feature 브랜치를 생성하여 작업하는 방식입니다.

중앙 브랜치와 Feature Branch만 존재하기 때문에 Pull Request를 사용하지 않을 경우에 안정성이 보장되지 않으며, 보통 릴리즈 속도가 빠른 소규모 프로젝트에서 적용하는 편입니다.

다만 빠른 배포가 필요없거나 실수가 잦을법한 상황 (대규모 코드 리팩토링, 팀원이 자주 바뀌어 어떤 작업이 진행되고 있었는지 헷갈림) 에서는 해당 플로우를 추천하기 어렵습니다.

Velog Dashboard도 초창기에 해당 플로우를 사용하였습니다.

Gitlab Flow

Gitlab Flow는 Github Flow에서 Production과 Pre-production을 적용한 플로우로, Main 브랜치에서 Feature 브랜치의 코드를 모은 뒤, Pre-production에서 QA 후 Production에서 배포하는 구조입니다.

Github Flow에서 검사 가능 단계가 두 단계 추가되기 때문에 비교적 안정적이며, 큰 틀 아래 여러 기능들을 제작한 후 한 번에 배포하는 방식의 프로젝트에 적합합니다. 개인적으로 대부분의 웹 프로젝트에 대응 가능할 것으로 보이며, 소규모 팀부터 대규모 팀까지 거의 대부분의 팀에서 적용할 수 있을 듯 합니다.

Git Flow

Git 초창기에 나온 플로우로, 앱 서비스 개발 및 배포에 맞춰진 플로우입니다.

Main - Develop - Feature 구조는 다른 구조들과 비슷하나, 중간에 존재하는 Hotfix와 Release 브랜치가 복잡성을 더하는 편입니다.

웹 기반으로 환경이 많이 바뀐 현 상황에서도 많이 사용되고 있으며, 빠른 배포에는 적합하지 않으며 많은 팀원과 작업 시 커밋 충돌과 Rebase가 많이 일어날 확률이 높은 구조이긴 하지만, 배포 시의 안정성은 확실히 보장되기 때문에 배포의 안정성을 중요시 할 경우 적용할 수 있습니다. 또한, 버전 관리가 명확해야 하는 앱 개발 환경에서는 여전히 유용한 구조입니다.

결론

현재 Velog Dashboard Front-End에서는 위 플로우 중 Github Flow에서 Git Flow로 넘어가는 단계이며, 안정적인 배포를 위해 Git Flow의 형태를 조금씩 적용해보고 있는 느낌입니다. (최근 Release 브랜치가 추가되었습니다.)

개인적으로 안정적인 느낌이 들긴 하지만, 소규모 팀의 빠른 배포 및 기능 개발에는 그닥 적합하지 않다는 점을 뼈저리게 느끼고 있습니다. (복잡한 브랜치 관리, Hotfix 브랜치 없이 Main에 박아버려서 순서 꼬이기 등...)

다음 글은 커밋 순서 꼬임 문제를 해결하기 위해 머지 방식과 순서에 관한 글이 될 예정입니다.

이번에 팀원을 추가로 모으고, 실제 서비스 배포 후 정보를 모으며 프로젝트 진행을 다시 시작했습니다.

스프린트를 진행하며 큰 작업은 없었지만, 새로운 경험이 조금 있었기에 회고에 정리해보기로 합니다.

2. 진행한 작업

2-1. SEO, GA 추가

페이지 SEO를 개선하고 Google Analytics를 적용하였습니다. React였으면 React-Helmet 라이브러리를 사용(동적)하거나 실제 HTML 파일(정적)을 수정하여 메타태그를 적용해야 하며, Script 코드를 직접 작성하여 GA를 연결했어야 하는데, NextJS의 내장 기능 및 라이브러리를 통해 해결할 수 있어 만족스러웠습니다. 개인적으로 NextJS의 사용 이유를 SSR을 제외하고는 잘 몰랐는데, 이런 장점들을 발견할 수 있어 좋은 경험이었습니다.

2-2. NextJS 라우트 캐시 이슈 해결

이전부터 계속 골머리를 썩혔던 NextJS 캐시 이슈의 해결 방법을 찾았습니다. NextJS에 포함된 RSC에서 제공하는 Client-Side Route Cache가 제거되지 않아 생기는 문제였으며, revalidathPath 함수를 서버 액션 형태로 적용하여 해결할 수 있었습니다.

'use server';

import { revalidatePath } from 'next/cache';
import { redirect } from 'next/navigation';

export async function revalidate() {
  revalidatePath('/', 'layout');
  redirect('/');
}

다만 redirect가 return문으로써 동작하여 (서버 액션 실행 후 상태코드 304를 반환하여 페이지를 이동시키는 방식) 실행 직후 토큰 만료를 진행시킬 방법을 찾지 못해 아직은 개발 브랜치에 병합하지 못했습니다.

완벽히 해결하진 못했으나, 개인적으로 NextJS의 장점인 기능을 사용할 수 있어 좋은 경험이었다고 생각합니다.

2-3. 첫 공개 PR 대응

우선, 첫 PR을 작성해주신 데브현 님께 이 자리를 빌어 감사의 말씀 드립니다!

처음으로 저희 서비스가 "오픈 소스"라는 느낌이 들게 해주는 공개 PR의 리뷰 및 Approve를 진행하였습니다. 글이 올라온걸 확인한 직후 너무 기쁜 나머지 생각 없이 PR 내용을 읽은 후 Approve를 드렸는데, 현우님께 너무 빠르게 진행하려고 생각하지 말라는 말을 듣고 정신을 차렸습니다.

현우님의 말을 듣고 off-topic으로 가려버린 리뷰

그 이후 잠시 대기했다가 현우님과 함께 비교적 확실한 PR 리뷰 및 Approve를 진행하였습니다. 다른 오픈소스에 PR을 열어보고, 그 PR이 머지되는 경험이 있었으면 정말 좋았겠지만, 이런 경험도 충분히 보람차고 만족스러운 것 같습니다.

3. 좋았고 아쉬웠던 점

3-1. 좋았던 점

• 다시 늘어난 인원 및 활동 개인적으로 새로운 팀원 분들이 들어오고, 프로젝트에 활기가 생겨 즐겁습니다. 되려 제가 이전의 낮은 활기를 갖고 활동하는 건 아닌지 걱정이 되기도 하지만, 우선은 제 활기도 늘어났다고 생각하려 합니다.
• 이전에 비해 늘어난 유저 수 서비스의 사용자가 늘어나며 이전에 대략적으로 구축해뒀던 아키텍처의 성능에 문제가 생기고 있긴 하지만, 오히려 대형 서비스에서의 오류 대응 및 성능 개선 경험을 할 수 있는 것 같아 좋았습니다.

  3-2. 아쉬웠던 점

• 낮잠 방학이 거의 끝나감에도 불구하고 아직도 10시에서 12시 사이에 기상하는 습관을 갖고 있는데, 개학하고 나서라도 빨리 고쳐야 할 것 같습니다. 덕분에 스크럼과 회의도 놓치고, 여러모로 다른 분들께 욕보인 것 같아 죄송스럽습니다.

4. 결론

서론에서 말씀드렸듯 이번 스프린트 동안은 큰 작업이 없었습니다. 다만 SEO 및 GA 세팅, 사용자분들의 불만 사항 및 개선 사항 대응, 그리고 첫 공개 PR Approve 등 사소한 신규 경험들이 많아 큰 작업이 없었음에도 비교적 만족스러운 스프린트였습니다.

다음 스프린트부터는 미뤄뒀던 기능들 (공지, 스켈레톤 UI 및 로딩 스크린, 캐시 충돌 문제 완벽 해결 등) 을 처리하는 것을 목표로 잡고 진행해야 할 듯 합니다.

12월에 한 달 천하로 서비스를 배포하겠다는 V.D. 팀의 의지가 무색하게, 2월에 다다러서야 서비스가 배포되었습니다.

큰 규모의 프로젝트는 아니었지만, 사이드 프로젝트인 만큼 온 신경을 쏟을 수 없는데다가 한 팀원분의 부재로 프로젝트의 텐션이 낮아지는 것 같아 대략 한 달간의 휴식을 거치고, 지난 토요일에 마지막 QA와 점검 후 서비스를 배포하였습니다.

이렇게 배포한 뒤 회고할 생각을 하기만 하다가, 며칠만에 개발 회고를 작성해보기로 합니다.

어려웠던 애자일

프로젝트를 진행하면서 가볍게나마 현업에 가까운 애자일을 체험해 볼 수 있었습니다.

에픽 개념이나 칸반 보드 실사, 위클리 회고 등 다양한 애자일 프로세스를 사용하여 프로젝트를 진행해 보았고, 간단한 프로젝트임에도 현업에 관한 경험을 할 수 있었던 것 같습니다.

특히 매주 진행되는 회의나 회고는 제 자신을 돌아볼 수 있었던 것 같아 아직도 좋게 생각하고 있습니다. 종종 귀찮아서 밀려쓰는 경우는 있었지만, 스프린트동안 진행된 태스크를 되돌아보는 부분은 여전히 만족스럽습니다.

다만 그 외에는 개인적으로 좀 힘들었던 것 같습니다.

매일 매일 작성하는 데일리 스크럼이 특히 어려웠는데, 종종 까먹어버리기도 하고 초반에 오늘 할 일을 어떤 식으로 정리해야 할지 고민했던 경험은.. 참 막막했었습니다. (그래도 제가 "계획 세우기"에 확실히 부족하다는 점을 배울 수 있었습니다!)

NextJS 첫 발걸음 떼기

이번 프로젝트가 제가 처음으로 NextJS를 제대로 사용해본 프로젝트입니다!

이전에 진행했던 교내 서비스인 "Repo"는 당장 개발 기간이 두 달밖에 안 된다는 점과 NextJS에 익숙치 않다는 점을 고려해서 React로 진행했었는데, "Velog Dashboard"는 가벼운 사이드 프로젝트인 만큼 여러 경험을 위해 NextJS로 진행했습니다.

SSR 환경에서의 쿠키 관리 이슈나 NextJS의 standalone 빌드 이슈 등 단순하면서도 복잡한, 다양한 이슈를 겪어볼 수 있었고, 현재는 SEO를 더 최적화시키기 위해 알아보고 있습니다.

첫 테스트 코드 작성

프로젝트를 진행하며 처음으로 테스트 코드를 작성해보았습니다. 개인적으로 엣지케이스를 찾아내서 코드로 테스트하는 데 많은 애를 먹었던 것 같습니다.

사실 큰 규모의 프로젝트가 아닌 만큼 테스트 코드를 거대하고 완벽하게 작성할 필요까진 없겠지만, 그래도 첫 테스트 코드 작성인 만큼 오기가 생겨 나름 잘 작성하기 위해 노력했던 것 같습니다.

이 과정에서 시간이 더욱 소모되었는데, 현업에서 일하게 된다면 어떤 식으로 테스트를 진행하는지를 제일 먼저 봐야 할 것 같습니다. (엣지 케이스를 최대한 많이, 그리고 빠르게 찾아보고 싶습니다!)

Axios 대신 Fetch

사실 Axios 대신 Fetch를 사용하라는 점이 처음에는 제일 적응하기 어려웠던 점 같습니다. interceptor 개념도 없고, 자동 timeout 기능도 없는 fetch를 쓰라니, 저로써는 이해하기 어려운 점이었습니다.

그래도 axios를 사용하며 느꼈던 매너리즘도 깰 겸, NextJS와 잘 섞이기도 할 겸, fetch를 사용해보기로 했습니다.

처음에는 (매너리즘을 깬다면서) fetch에 axios와 같은 기능들을 추가해주는 라이브러리가 있을지 알아봤습니다. 그러나 완성형의 라이브러리는 찾을 수 없었고, 한 한국인 개발자분이 개발하신 return-fetch라는 라이브러리를 사용해 가내수공업 버전 axios를 개발하였습니다. (새로 시작하는 다른 분들은 ky라는 fetch 기반 라이브러리를 통해 연동하셔도 좋을 듯 합니다..!)

지원하지 않는 자동 timeout 기능을 직접 구현하고, 그 과정에서 최신 브라우저가 아닐 경우의 폴리필을 적용하는 과정은 귀찮고 복잡했지만, 만드는 김에 오류 대응의 용이성을 위해 HTTP 코드 별 콜백 객체도 추가하는 등 제 입맛대로 뜯어고칠 수 있다는 점은 정말 재밌었습니다.

대부분의 회사와 개발자분들은 axios를 애용하시겠지만, 재미와 유연함을 추구하시는 분이라면 사이드 프로젝트에서는 fetch를 가내수공업해서 사용하셔도 좋을 것 같습니다!

조금 더 탄탄한 타입과 에러 핸들링

실제로 사용되어야 하며, 사용자가 최대한 불편함을 겪지 않아야 하는 서비스인 만큼 타입 지정과 에러 핸들링을 최대한 탄탄하게 하기 위해 노력했습니다.

위에서 말씀드린 HTTP 코드별 콜백 객체와 sentry 기반의 오류 모니터링 시스템을 구축하여 에러 핸들링과 모니터링을 안정적으로 하기 위해 노력했고, 커스텀 에러 타입과 에러 클래스를 적용하고 타입 파일을 별도로 관리하는 등 타입 시스템도 안정적으로 구축하기 위해 노력하였습니다.

물론 아직 부족한 점이 일부 있겠지만, 조금 더 심화된 타입 시스템을 구축하여 훨씬 확실한 타입 시스템을 구축하고, 에러 핸들링에 대해서도 조금 더 배워서 적용해 볼 생각입니다. (특히 타입의 이름 관리가 제일 어렵고 또 엉성한 것 같습니다.. API 타입에서는 Dto와 Vo 라는 칭호를 붙여 타입을 관리하고 있는데 종종 헷갈리기도 하는 등 아직은 아쉽습니다.)

확장프로그램 개발기

프로젝트를 진행하며 전 버전부터 고려됬던 문제가 있었는데, "더 편한 로그인" 에 대한 문제였습니다.

초창기 버전의 Velog Dashboard는 개발자 도구에서 직접 토큰을 가져와서 로그인하는, 굉장히 서드파티스러운 로그인 방식을 사용하고 있었는데, 이번 V2에서 개선해보고자 했습니다.

다만 다른 로그인 방식으로 바꾸기에는 Velog에 너무 다양한 방식의 로그인이 있어 어려웠습니다. 따라서 원래대로 토큰 입력 방식으로 가기로 했으나, 마침 확장 프로그램을 이용하면 다른 사이트의 쿠키를 가져올 수 있다는 아이디어에 착안해서 확장 프로그램 기반의 자동 로그인 기능을 구상한 뒤 간단히 구현하였습니다.

다만 너무 단순한 기능이라 이를 위해 확장 프로그램 설치 유도가 어렵다고 생각했고, 추가적인 기능을 몇 가지 떠올려봤습니다.

설치 유도를 위한 기능들

그 중 두 가지가 간편 통계와 포스트 그래프였고, 이를 React를 통해 구현하였습니다.

이 과정에서 굉장히 귀찮은 작업이 있었는데, 통계 데이터나 그래프를 띄우기 위해서는 어떤 요소를 잡아서 그 위에 덮어씌우거나 새 노드를 추가해서 특정 요소 아래에 추가하는 방식을 사용해야 했습니다.

마침 각 페이지별로 남는 미사용 요소들이 있었기 때문에 덮어씌우는 방식을 사용했습니다. 통계 데이터는 프로필 페이지의 빈 팔로우 버튼을, 포스트 그래프는 통계 페이지의 동작하지 않는 그래프 요소를 갈아버리고 그 위에 덮어씌웠습니다.

아쉬운 점

다만 아쉬운 점이 한 가지 있는데, 로그아웃 후 다시 로그인 하거나 완전히 새로 로그인하는 경우에 종종 포스트를 읽기 전까지 프로필 통계 데이터가 표시되지 않는다는 것입니다.

추측중인 이유로 Velog의 localstorage 내의 CURRENT_USER 값을 비교하기 위해 사용하는 점을 꼽고 있는데, 재로그인 후에 게시된 포스트를 읽기 전까지 localstorage에 유저 정보가 저장되지 않기 때문입니다.

심지어 마이페이지에 가서도 값이 변경되지 않아 내 프로필임에도 통계 정보가 표시되지 않는 문제가 종종 생겼습니다.

우선은 api를 직접 호출하여 유저 정보를 따로 저장하는 방법을 생각해보고 있습니다.

왜 거부하는건지..

이렇게 개발된 확장 프로그램을 1월부터 꽤 자주 제출해보고 있는데, 구글이 배포를 거부하고 있습니다. 내용이 부족하다면서 배포를 계속 거부하고 있는데, 너무 안 된다 싶으면 그냥 Velog Dashboard 페이지에 공지 형태로 공유해버릴까 싶기도 합니다.

(혹시 확장 프로그램 배포와 규칙에 대해 상세히 알고 계신 분이 계신다면.. 댓글이라도 한 번 달아주세요...)

결론

이런 저런 수난이 있기는 했지만, 결국 Velog Dashboard를 배포해내고야 말았습니다.

사실 이제까지는 0 to 1이었고, 이제 1 to 10을 향해 달려가야겠지만.. 1 to 10이라도 앞으로도 열정을 가지고 재밌게 개발할 수 있었으면 좋겠습니다! 열심히 참여해주셨던 다른 팀원 분들께 정말 감사를 표하며, 앞으로 더욱 발전하는 (그리고 늦잠 안 자는..!) 팀원이 되기 위해 노력하겠습니다!

P.S.

참고로 현재 저희 팀에서 추가 인원을 뽑고 있습니다. 아무래도 백엔드 팀원 두 분께서 패시브 메인테이너가 되신 만큼 주로 유지보수해주실 팀원분이 필요하려 추가모집하는 것 같은데, 2월 17일까지인 만큼 참여하시고 싶으신 분 께서는 빠르게 신청해보시는 것을 추천드립니다! (이제 고3인 저도 참여해서 큰 기여를 할 수 있었던 만큼, 주니어라면 나이/실력에 상관없이 지원해보세요! 좋은 경험을 쌓아가실 수 있을거에요~)

아직도 배포가 안 됬다니요..

사실 곧 배포 될 것 같다고 한지도 벌써 일주일이 지났습니다 (작성일까지 포함하면 거의 2주 정도네요..) 솔직히 말하자면 금방 배포될 줄 알았는데, 다들 일정이 바쁘셔서 모이기 어렵다 보니 배포할 수 있는지 확인하기도 어려운 느낌입니다;;

그래도 8주차는 결국 끝났으니, 회고록은 써야 하지 않겠습니까?

무슨 일이 있었을까요?

확장 프로그램 제작

썸네일에서도 보셔서 아시겠지만, 이전에 경험했던 확장 프로그램 개발을 통해 본가인 Velog에서도 V.D.의 데이터를 볼 수 있게 확장 프로그램을 제작하였습니다.

원래는 단순히 로그인 시 직접 토큰을 가져와야 했던 불편함을 개선하기 위해 제작했으나, 해당 기능만 넣기에는 사용성이 떨어진다고 느껴져서 두 개의 기능을 더 붙여줬습니다.

통계 요약 보기

썸네일에셔도 보셨듯 자신의 통계 정보에 대한 요약을 보여주는 기능입니다. 해당 요소를 클릭하면 Velog Dashboard 페이지로 이동하게 됩니다.

게시글 상세 통계 보기

그래프를 통해 오늘 포함 7일 동안의 조회수 통계를 보여주는 기능입니다. 통계 페이지에서 작동하며, 왼쪽 구석의 "상세보기" 버튼을 통해 Velog Dashboard 페이지로 이동할 수 있습니다.

잘 동작하지만, 좀 아쉽습니다

사실 확장 프로그램 경험이라고 했지만, 그냥 단순히 페이지를 확장 프로그램 전용 창에서 렌더링하던 이전과는 달리, 방문중인 페이지의 일부 요소에 렌더링을 해야 했기에 헷갈리는 점이 좀 많았습니다.

현재 페이지 접속 이벤트를 받았을 때 해당 페이지의 URL에 따라 createRoot를 통해 페이지의 특정 요소를 덮어씌우는 방식을 사용하고 있는데, 당장 확인하는 URL이 두 개 뿐이라 if문으로 단순 처리하다 보니 확장성과 재활용성이 아쉽습니다.

또한, 페이지 전역에서 QueryClient를 사용하는 게 아니다 보니, tanstack-query를 사용하는 이유도 찾아보기 어려운 느낌입니다. '데이터 핸들링이 쉽다' 정도의 장점만 제외하면 딱 떠오르는 필요성이 느껴지지 않는달까요.

리더보드 페이지 퍼블리싱

(이름들은 무시합시다.. 별로 중요한 게 아니잖아요?)

리더보드 페이지를 퍼블리싱하였습니다. 이 페이지에서, 3위 이후부터 표시되는 UI의 너비가 화면에 따라 너무 커 보일 수 있었다고 생각했습니다.

이에 맞춰 페이지의 최대 너비를 지정하였으나, 적용했음에도 불구하고 여전히 과히 넓어보이긴 합니다. 이를 해결하기 위해, flex-wrap과 너비 지정을 통해 한 줄당 최대 3명의 순위를 표현하는 방식의 디자인을 생각해보고 있습니다.

이벤트 트래킹 정리

이벤트 트래킹 시 사용되는 값과 코드들을 정리했습니다. 원래는 아래와 같은 방식의 값을 사용하였으나, 시인성이 너무 낮다고 판단되어 위와 같이 수정하였습니다.

{
    LOGIN: '01',
       CLICK: '02',
    GRAPH_OPEN: '03',
    ...
}

어떤 점이 좋았고, 어떤 점이 아쉬웠을까요?

여전히 좋은 점이나 나쁜 점은 비슷한 만큼, 제 개인적으로 아쉬운 점만 작성해보겠습니다.

아쉬웠던 점

• 계속해서 밀리는 업무 사실 한 업무에서 과한 시간을 차지하는 경우가 요 근래 늘어나면서, 해당 문제가 생기는 듯 합니다. (테스트 진행 시 모킹이 되지 않아 응답 데이터가 비거나, 토큰 만료에 대한 모킹을 동적으로 진행하기 어려운 점 등)
• 덩달아 밀리는 회고록 작성 사실 반쯤 현실부정이라고 할 수 있겠으나, 위 사유로 인해 한 스프린트마다 처리하는 일이 적어지면서 회고록 작성이 계속해서 밀리게 됩니다. 작성할 내용을 계속 찾더라도 결론적으론 안 나오다 보니 밀리게 됩니다

해결 방법

• 이론 공부 사실 제일 명확한 해결책입니다. 결론적으로 해당 테스트에서 어떤 동작이 어떻게 돌아가는지 이해하지 못하면서 생기는 문제니까요. 어차피 방학이겠다, 모자란 실력도 채워야겠다 이론 공부를 해야 할 듯 합니다.

결론은 뭔가요?

오늘은 딱히 결론이랄 게 없을 듯 합니다. 적어도 이번 달 내로는 배포할 것 같다는 제 사견 정도만 전달드리면 끝입니다.

사실 벌써 8번째 회고록이다 보니, 이렇게 늘어놓을 잡설조차 모자라게 되었습니다.

곧 배포될 것 같은 느낌

그새 7주차도 끝났습니다. 거의 2달 정도의 기간동안 나름대로 개발이 끝나서 슬슬 배포될 준비를 하고 있습니다. 오라클이 이틀동안 가입을 거부하고 있긴 하지만 도커라이징 준비만 끝나면 곧 배포되지 않을까 싶습니다.

어찌 됬든 이번 스프린트 회고도 시작해보도록 합시다.

무슨 일이 있었을까요?

API 연동

프로젝트에 API를 마저 세팅하였습니다. 단순한 연동에는 쿤 문제가 없었지만, Client Side에서 데이터를 불러오는게 아님에도 데이터가 늦게 뜨는 문제가 있었습니다.

Prefetch 이슈

알아보니, Tanstack-Query에서 SSR을 적용하기 위해서는 prefetchQuery를 사용하여 미리 데이터를 캐싱해야 했습니다. 다만 prefetchQuery를 적용한 상태에서도 동일한 문제가 발생하였습니다.

쿠키 이슈

혹시나 싶어서 Server Side에서 로그를 찍어보니, 401 오류가 발생하고 있었습니다. prefetchQuery가 서버에서 발생하기 때문에 쿠키가 적용되지 않아 생기는 오류라고 파악했고, 아래와 같은 방법들을 시도하였습니다.

• NextJS를 프록시 서버로서 사용 토큰이 httpOnly 쿠키로 저장되었기 때문에, NextJS를 프록시 서버로 사용하는 방식을 시도하였습니다. 하지만 prefetchQuery에서 요청했을 경우에 프록시 서버가 아닌 일반 서버에 전송되었습니다.
• cookies를 통한 쿠키 저장 혹시 몰라서 cookies를 통해 토큰을 불러왔는데, httpOnly가 적용됬슴에도 불구하고 정상적으로 불러와졌습니다. 해당 방식을 통해 헤더에 직접 쿠키를 적용하는 방식을 시도하였고, 정상적으로 적용되었습니다.

(커스텀 instance를 통해 불러오기 때문에 위와 같은 방식의 코드로 적용하였습니다.) (다만 이 부분은 instance에 통합할 수 있을 것으로 보이긴 합니다. 리팩토링 시에 개선해봐야겠네요..)

배포 환경 세팅

배포 준비를 위해 배포 환경을 일부 세팅하였습니다. env 파일을 두 가지 (production, development)로 나누었습니다.

그 외에 오라클 클라우드 가입도 시도하였으나, 오라클에서 계속 거부 메세지를 뱉어서 여전히 가입하지 못한 상황입니다.. (해결 방법을 아신다면 댓글로 꼭 알려주세요...)

어떤 점이 좋았고, 어떤 점이 아쉬웠을까요?

좋았던 점

• Back-End 팀원과의 소통 일정이 맞을 때마다 Back-End 팀원분들과 소통하며 API를 연동했습니다. 덕분에 빠르게 API를 연동할 수 있었고, 문제점이 있었고 바로 바로 해결할 수 있었습니다.

아쉬웠던 점

• 망가진 코드리뷰 문화 최근 들어서 코드리뷰 문화가 조금 망가진 것 같습니다.. 다들 현생이 바빠서 그렇지 않을까 싶은데, 이 때문에 진행 속도도 조금 느려지지 않았나 싶습니다.

해결법

• 시간이.. 사실 이 문제도 시간이 해결해줘야 하긴 같긴 합니다. 물론 이전에 있었던 제 개인적인 의욕 문제와는 다르게, 전체적인 분위기가 바뀐 만큼 팀 리더인 현우님이 이끌어주기도 해야 할 듯 합니다 (실제로 오늘 공지로 코드리뷰와 관련해서 말씀해주시긴 했습니다)

결론은 뭔가요?

상기했듯 요즘 코드리뷰 문화가 조금 깨진 느낌입니다.. 다들 연말과 연초 일정, 혹은 회사 일 때문에 바빠서 밀리는게 아닐까 싶은데 저라도 노력해야 할 것 같습니다.

진짜 조금만 있으면 배포되는 만큼, 조금만 더 노력해 보기로 합니다.

방학이 겹치는 6주차가 끝났습니다. 사실... 회고를 쓰다 보니까 소재 고갈 느낌처럼 서론에 쓸 만한 내용이 크게 없습니다;; 바로 무슨 일이 있었는지 복기부터 시작하도록 합시다.

무슨 일이 있었을까요?

그래프 제작

아래 디자인과는 조금 다른 디자인의 그래프를 제작하였습니다. 제작 과정에서 그래프에 반응형을 넣을 때 important를 넣어야 해서 귀찮았던 기억이 있네요; 지원 자체는 아래 코드를 통해 쉽게 가능했습니다.

<Line
  data={data}
  options={{
    responsive: true, // 반응형 지원을 켜고
    animation: false,
    plugins: {
      legend: {
        display: false,
      },
    },
  }}
  className="w-[100%_!important] h-[auto_!important] max-h-[300px]" 
  // 강제로 너비를 100%로, 높이는 너비에 따라 맞추는 식으로 반응형을 지원했다. (디자인을 위해 최대 높이도 넣었다)
  />

서버와 클라이언트 (아주 조금) 연결

서버와 클라이언트를 조금이나마 연결했습니다.

로그인 페이지가 정상적으로 동작하는걸 확인했고, 화요일 새벽 동안 대시보드 페이지의 리스트를 연결했습니다. 다만 처음 연결하다 보니 API나 클라이언트나 완벽하진 않아서, 분리해야 할 일부 API나 로직에 관한 검토 또한 진행했습니다.

디자인 변경 및 반영

강제 새로고침 버튼과 정렬 기능 등에 대한 디자인을 새로 제작하였습니다. 다만 강제 새로고침 버튼은 개인적으로 어떤 방식으로 동작시켜야 할 지 조금 고민입니다. (서버에서 Velog에 직접 데이터를 요청할텐데, 악용될 여지가 있을까 싶기도 합니다)

어떤 점이 좋았고, 어떤 점이 아쉬웠을까요?

해당 부분은 지난 주와 동일합니다. 반복해서 적는 것보단 이렇게 처리하는게 좋을 것 같았습니다..

결론은 뭔가요?

사실 몇 번째 하는 말이긴 하지만, 진짜 얼마 남지 않았습니다. 올해 내로 배포하는게 목적이었던 만큼 제발 이번 스프린트에서라도 끝내야 합니다.

공교롭게도, 12월 31일이 다음주 화요일입니다. 올 해의 마지막 스프린트 회의가 되지 않을까 싶은데, 그 때는 서비스를 배포하고 난 뒤 뵜으면 좋겠습니다.

(그리고 작성일인 12월 26일은 목요일입니다. 매번 스프린트마다 했던 일을 찾을 때마다 계속 사소한 일들만 진행되고 있는 것 같아 회고록 쓰기를 점점 미루게 됩니다. 이 점은 정말 반성합니다...)

5주차

그새 5주차가 지났습니다. 뭔가 슬슬 글의 길이가 짧아지는 것 같아서 부족한 건 아닐지 걱정됩니다..

무슨 일이 있었을까요?

대시보드 페이지 퍼블리싱

대시보드 페이지의 퍼블리싱을 완료했습니다. 이번에는 퍼블리싱을 진행하면서 반응형 지원도 동시에 진행하게 되었습니다. 그런데, tailwindcss에서의 max와 min의 개념이 헷갈려서 자주 틀렸던 것 같습니다..

• max-[] Tailwindcss에서 화면의 너비가 n 이하일 경우 적용되는 속성입니다. max-[1000px]:w-full 라는 속성이 있을 경우, 화면이 1000px 이하일 경우 width 100%가 적용됩니다
• [] Tailwindcss에서 화면의 너비가 n 이상일 경우 적용되는 속성입니다. [820px]:flex-col 라는 속성이 있을 경우, 화면이 820px 이상일 경우 flex 방향이 세로로 설정됩니다

어떤 점이 좋았고, 어떤 점이 아쉬웠을까요?

좋았던 점 (Keep)

• 모각코 현우님이 지난 주 주말에 모각코를 열어주셨습니다. 중간 중간 까먹었거나 정확히 알지 못하는 일들에 대해 물어보기도 편하고, 서로 지켜보는 효과가 있어서 빠르게 일을 진행하기 정말 좋았다고 생각하고 있습니다. 내일도 다시 여신다고 하는데, 컨퍼런스 끝나고 빠르게 참여해볼 생각입니다!

  아쉬웠던 점 (Problem)

• 또 밀려버린 일 사실 여유가 있었다고는 했지만, 방학 전 마지막 스퍼트 주간이라 교내 온갖 이벤트가 다 열렸습니다. 외부 공연, 교내 전시회, 대청소 x3 등 큰 일들이 거하게 터지지 않았나 싶습니다. 4주차 때는 서울만 2번 갔던 것 같은데... 방학이라고 온갖 게 다 일어나는 것 같습니다..

개선 방법 (Try)

• 시간이 해결해줄 예정 이렇게 밀린 일들은 그냥 제가 시간을 죽여서라도 해결해야 합니다. 중간 중간 여유가 있었음에도 해결하지 않은 저를 탓할 수 밖에요.. 그래도 대시보드 퍼블리싱과 연동만 끝나면 가장 필요한 기능들은 완성하게 됩니다.

결론은 뭔가요?

빠르게 일을 끝내지는 못했습니다. 2주동안 끌고 가는 일이 점점 늘어나는 느낌입니다; 그래도 곧 있으면 배포할 수 있을 거라는 생각으로, 찐막 스퍼트를 내보기로 합니다..

(글 길이도 짧아졌다는 점에 대해 반성합니다...)

벌써 Velog Dashboard의 4주차 스프린트가 끝났습니다. 메인 기능인 대시보드만 만들면 원래 생각했던 기능 자체는 끝이긴 한데, 이벤트 로깅같은 잡다한 곳에서 뭔가 막혀서 답답한 느낌입니다;

무슨 일이 있었을까요?

AutoFill 확장 프로그램 제작

Velog에 로그인이 되어있는 상황에서 Velog Dashboard에 접속했을 시 자동으로 토큰을 수집해 입력해주는 AutoFill 확장 프로그램을 제작했습니다. 크게 어려운 작업은 아니었는데, 개인적으로 확장 프로그램에서 DOM을 바로 건들 수 없다는 점이 이해가 안 갔었던 것 같습니다.

커스텀 에러 적용

최대한 편하게 쓰기 위해 나름대로의 최선을 다했습니다..

이 과정에서 “서버가 응답하지 않을 경우“ 의 테스트 케이스도 작성하였는데, fetch가 자체적으로 Timeout 기능을 지원하지 않는다는 점을 알 수 있었습니다..

다행히도 최근 JavaScript에 AbortSignal.timeout이라는 함수가 추가되었고, 해당 함수를 통해 특정 시간이 지나면 요청을 취소하고 오류를 출력하는 방식으로 직접 제작할 수 있었습니다.

그 외 여러 리팩토링

• import문 순서 정렬 Import문 또한 작성 순서가 있다는 사실을 팀원분이 알려주셨습니다. 원래는 제 성격상 깔끔한 코드를 선호해서 코드의 길이 순으로 정렬했었는데, 아래 규칙에 맞춰 다시 정렬하였습니다.
  • 언어 내장 모듈은 항상 최상위
  • 핵심 라이브러리 (react , django , express 등)
  • 우리가 작성하고, 참조하는 모듈, 내부 라이브러리 중 "유틸 성격이 강한 것"
  • 우리가 작성하고, 참조하는 모듈, 내부 라이브러리 중 해당 파일에서만 사용하는 것들

어떤 점이 좋았고, 어떤 점이 아쉬웠을까요?

좋았던 것 (Keep)

• 팀원과의 소통 코드나 Task 등 아쉬운 부분이 있을 때 팀원분들이 일부 지적해주시는 경우가 있는데, 제가 놓쳤던 부분들을 다시 돌아볼 수 있어 여전히 만족하고 있습니다!

아쉬웠던 것 (Problem)

• 여전히 쌓여있는 일 여전히 Task들이 몇 가지 쌓여있습니다.. (이벤트 로깅, 대시보드, 모바일 지원 등) 뭔가 이번주 내내 많이 한 것 같긴 한데, 다시 돌아보니 어디선가 시간이 새어나가는 것 같습니다;;

개선 방법 (Try)

• To-Do리스트 다시 갱신하기 최근 To-Do 리스트를 던져놓고 살고있는데, 다시 잡아서 갱신해두면 빠지는 일 없이 최대한 끝낼 수 있지 않을까 싶습니다.
• 내가 오늘 한 일 기록하기 오늘 무슨 일을 했는지를 자기 전에 기록해봐야 할 것 같습니다. 분명 어딘가에서 시간이 새어나가고 있읉텐데, 이 부분을 무조건 해결해야 합니다.

결론은 뭔가요?

크게 많은 일을 한 것 같진 않지만, 그래도 이제 오류 로깅과 대시보드만 제작하면 큰 기능은 끝나게 됩니다.

이번 주에 인턴십 면접이 있어 준비해야 하긴 하지만, 시간 나는 대로 노력해서 이번주 내로 API 연동을 제외한 모든 일들을 끝내는 걸 목표로 할 생각입니다. 그리고 와이어샤크가 새어나가는 패킷을 잡듯이, 꼼꼼한 일정 관리와 작업 기록 습관을 들여서 새어나가는 시간을 잡기 위해 노력해야겠습니다;;

(오늘따라 이모지가 없는 이유는, 기숙사에서 노트북 안 낸걸 들켜서 태블릿으로 적고있기 때문입니다.. 키보드가 정말 불편합니다;;)

❄️ 12월인데요?

가을이 잠깐 왔다가 도망가고 바로 겨울이 왔습니다. 그렇습니다. 12월입니다.

그리고 Velog Dashboard의 스프린트는 벌써 3주차가 끝나고 4주차에 접어들고 있습니다.

💭 무슨 일이 있었을까요?

로그인 브랜치 Merge

장렬하게 전사한 히드라(코드래빗)이 남기고 간 엄청난 리뷰의 흔적..

3일동안의 대장정을 통해 로그인 페이지를 main 브랜치에 merge했습니다. PR을 올리자 마자 코드래빗이 하나를 resolve 처리하면 두 개의 리뷰가 새로 생기는 히드라같은 리뷰를 수없이 뿌렸습니다. 이 자가 복제 리뷰를 처리하느라 정말 고전했던 것 같은데, 오히려 이 덕분에 ESLint가 동작하지 않는 문제를 해결할 수 있었습니다.

오류 핸들링 관련 고민

프로젝트에서 아쉬운 부분을 개선하고자 새로 refactor 브랜치를 파고, 오류 핸들링에 대해 고민해봤습니다. 확장이 쉽고, 디버깅하기 쉬운 방식에 대해 고민해봐야 했는데, 뭔가 아직도 제자리걸음인 듯한 느낌입니다.

우선 생각해둔 방법으로는, 커스텀 에러 핸들링의 구조를 잡고 나서 필요한 오류가 생길 때마다 하나씩 추가하며 사용하는 방식을 적용해야 할 것 같습니다.

대시보드 화면 구성

간략한 정리 함께 대시보드를 어떤 방식으로 구성하면 좋을 지에 대해 팀원 분들과 회의를 진행했습니다. 현재는 위 사진과 같은 내용을 추가하자고 결정된 상황입니다.

👍 어떤 점이 좋고, 어떤 점이 아쉬웠을까요?

좋았던 점 (Keep)

• 여전히 만족스러운 코드 리뷰 점점 풀리퀘와 코드 리뷰가 쌓여가는 느낌이라 힘들긴 하지만, 그래도 여전히 만족스러운 느낌입니다. 특히 제가 놓친 부분을 잡을 수 있다는 점이 정말 좋았습니다.
• 종종 들어오는 새 스택과 정보들 팀원 분들이 가끔 가다 재밌는 스택이나 정보를 공유해주시곤 합니다. 제가 생각해보지 못한 부분이나 뭔가 이상한 프로젝트, 새로운 라이브러리 등 좋은 정보를 공유해주셔서 새로운 것들이 끊이지 않는 느낌입니다.

아쉬워던 점 (Problem)

• 조금 느린 프로젝트의 속도 사실 제가 학생이기도 하고, 프로젝트의 리더이신 현우님이 현업자신 만큼 프로젝트의 속도가 느릴 수밖에 없다고 생각합니다. (생각날 때마다 Task를 적어서 처리하는게 아니라 미리 적어둔 Task를 쳐내는 방식이라 느린가 싶기도 합니다.)
• (개인적으로) 일이 밀리는 듯한 느낌 진행 속도가 느려서 그런 걸지도, 아니면 그냥 전혀 모르는 부분을 건드리는 느낌이라 그런 걸지도 모르지만 개인적으로 일을 쳐낸다는 느낌이 좀 강한 것 같습니다. 최근 들어서 일을 일요일에서 월요일 사이에 다 끝내는 느낌이 들기도 하고, 뭔가 일이 밀리는 것 같습니다.

개선 방법 (Try)

• 안정적인 우선순위 선정하기 사실 이것보다 더 오래 걸리고 덜 급한 일들이 있는데, 잘 몰라서 어떻게 손대야 할지 모르는 급한 일보단 이런 일들을 더 우선적으로 처리하는 것 같습니다. 우선순위가 깨진 상황이라고 보면 되는데, 다시 확립해주면 안정적으로 일을 진행하지 않을까 싶습니다.

🎬 결론은 뭔가요?

뭔가 요즘 들어서 일 처리가 늘어지는 느낌이라 조금 아쉽습니다. 하고 싶은것도 많고, 해야 할 것도 많아서 묶여있는 것 같은데, 마침 한 해를 끝내는 기간이 온 만큼 슬슬 묶인 일을 풀어야 하지 않을까 싶습니다.

올 한 해와 동시에 Velog Dashboard도 잘 마무리됬으면 좋겠습니다.

☹️ 예? 벌써 3주차라고요?

네 그렇습니다. 벌써 2주차가 끝났습니다. 지금까지 뭔가 많이 하진 않았던 것 같은데.. 그새 3주차가 다가오고 있습니다.

그래도 프로젝트 세팅이나 코드 리뷰 참여 등 또 아얘 안 했다 그러진 못하는 애매한 기간이었던 것 같습니다;

💭 무슨 일이 있었을까요?

프로젝트 세팅

프로젝트 레포지토리를 새롭게 세팅했습니다! 이전에 선택했던 스택을 기반으로 세팅했는데, 중간 중간 문제점들이 있어서 고생했던 기억이 있습니다..

NextJS에 Vite 적용이 안 되나?

NextJS를 거의 처음 사용하다 보니, 첫 세팅부터 막막했습니다. 원래 Vite와 NextJS를 통해 프로젝트를 구성하기로 정했었는데, Vite로 시작하는 방법이 아무리 찾아봐도 안 나왔습니다.

알아보니 NextJS에선 내장 번들러가 있기 때문에, 굳이 다른 번들러를 사용하지 않는다는 내용이 있었습니다! (다만 15 버전부터 TurboPack을 사용할지에 대한 여부를 세팅시에 물어봅니다.)

레퍼런스

간단히 로그인 페이지 제작

간단한 로그인 페이지를 디자인하고 제작했습니다. 사실은 "했습니다" 보다 "하고 있습니다" 가 더 적절한 표현일 것 같은데, Velog API에서 정상적인 응답값을 보내주질 않아서 아직도 어디가 문제인지 찾고 있습니다;

이것만 끝나면 테스트 조금 작성하고 바로 PR을 올릴 수 있는데 정말 어디가 문제인지 찾을 수 없는 느낌입니다.

그래도 API와 그에 관련된 테스트를 제외한 다른 테스트를 포함해서 전부 완성했고, 테스트 작성이 대략 어떻게 진행되는지 배울 수 있었습니다.

확장 프로그램 관련 고민

이전 버전의 Velog Dashboard는 사용자가 직접 벨로그의 토큰을 개발자 콘솔에서 가져와서 입력하는 방식으로 동작하였는데, 이를 확장 프로그램을 통한 auto-fill 기능으로 대체할지에 대해 고민하였습니다.

사실 처음엔 아이디어를 내긴 했어도, 과연 이걸 사용할 사람이 있을까 싶었습니다. (그냥 토큰을 자동으로 뜯어주는 확장 프로그램일 뿐이라 굳이 설치할 이유가 없어보였습니다. 또한 자동 리프레시를 서버에서 시켜줄 것으로 예상했기에 한번 로그인하면 삭제해야 하는 필요없는 확장이라고 생각했습니다.)

그런데, 토큰 자동 리프레시는 아직까지는 가설일 뿐이며, 다운로드 수가 적더라도 트래픽이 발생한다면 실제로 유용하다는 증거라는 현우님의 말씀을 듣고 나니 만드는 쪽이 더 좋을 듯 하다고 생각했습니다. 또한 이미 확장 프로그램 개발 경험이 있는 만큼 충분히 빨리 개발할 수 있기도 합니다!

코드 리뷰

처음으로 코드 리뷰에 참석해봤습니다.

다른 분들이 제 코드를 읽고 개선점을 알려주시다 보니 놓친 부분을 다시 한 번 돌아볼 수 있었고, 다른 분들의 코드를 보며 제가 몰랐던 점을 깨달을 수 있었습니다.

물론 다른 분들의 코드를 읽고 리뷰하는 작업에도 참석하였는데, 다들 정말 잘 꾸며주셔서 아쉬운 부분을 찾기가 어려웠습니다; 그래서 좋았던 점이랑 개선했으면 하는 점 정도만 적어 리뷰해드렸는데, 혹시 부족한 리뷰이진 않았을지 조금 아쉽습니다.

👍 어떤 점이 좋고, 어떤 점이 아쉬웠을까요?

좋았던 점 (Keep)

• 좋았던 점이 필수인 코드 리뷰 개인적으로 정말 만족스러운 규칙이었습니다. 아쉬운 점만 나열되어있으면 기분이 상하지 않았을까 싶은데, 도려 칭찬을 들으니 요청된 개선점을 빠르게 개선하고 싶은 생각이 듭니다.
• Back-End 개발자분들과의 의사소통 질문이 있을 때마다 편하게 드리거나, 편하게 받을 수 있어 좋았습니다. 최근에 토큰 관련해서도 어떤 방식으로 반환되는지 정확히 알 수 없어서 질문드렸는데 상세히 답변주셔서 좋았습니다. (하온님 감사합니다!)

아쉬웠던 점 (Problem)

• 늘어지는 느낌과 귀찮음 아직도 로그인 페이지를 제작하고 있는데, 이상하게 늘어지는 느낌입니다. 퍼블리싱이나 페이지 관련 테스트는 빠르게 됬는데, Velog에서의 응답이 정상적으로 오질 않아서 어떻게 나가야 할지 아직도 고민하고 있는 상황입니다. 한 곳에 계속 갇혀있는데다가 방법도 도저히 안 나와서 그런지 되려 개발하기 귀찮아지기도 합니다;

개선 방법 (Try)

• 빠르게 문제 알아내는 방법 기르기 현재로써는 fetch에 대해 더 공부해보는 방식으로 왜 데이터가 넘어오지 않는지 알아내야 할 것 같습니다. 이런 문제가 오래 지속되지 않는다면 흥미를 가지고 계속 개발할 수 있을 것으로 보입니다. (똑같은 일을 계속 반복하고 있어서 지루해지는 것으로 보입니다. 진전이라도 있어야 재미가 있죠..)

🎬 결론은 뭔가요?

(제 메일함은 곧 저렇게 됩니다..) 무언가를 많이 하지는 않았지만, 새로운 것들을 자잘하게 경험할 수 있었던 것 같습니다. 처음 코드 리뷰에 참여하는 느낌이 가장 신선하고 좋았던 것 같은데, 이제 얼마 뒤면 PR로 융단 폭격이 떨어질 걸 생각하니 조금 두렵기도 합니다;

그래도 열심히 참여해서 좋은 코드를 만들기 위해 노력해나가야겠습니다!

2달만에 돌아와서 쓴 글이 갑자기 뜬금없는 회고록이라 왜인지 궁금해하실 분들도 계실 것 같습니다. 사실은 최근에 Velog Dashboard (V.D.)라는 프젝에 참여하게 됬고, 이에 대한 회고록을 작성하게 되었습니다.

Velog를 자주 읽어보시는 분이라면 이 글을 보셨을 거라고 생각하고, 실제로 벨로그를 자주 읽는 저도 이 글을 봤습니다.

솔직히 말해서 위의 썸네일을 보고 들어온게 가장 큰 것 같은데.. 읽다 보니 스토리도 그렇고, 사용자들이 실제로 사용한다는 프로젝트라는 점에 이끌려 신청하게 되었습니다.

그렇게 신청 하고 어찌 저찌 지내다 보니.. 같이 참여하지 않겠냐는 문자가 도착했습니다.

그렇게 도착한 문자에 참여 의사를 밝히고, 해보고 싶던 프젝에 참여하게 되었습니다.

🤔 첫 회의

그렇게 초대를 받게 되고, 화요일 밤에 프로젝트 첫 회의를 진행하였습니다.

첫 회의인 만큼 프로젝트에 대한 소개와 함께 서로 자기 자신에 대해 소개하는 시간을 가졌습니다. 또한 그라운드 룰, 데일리 스크럼 룰, 회의 일정 확립을 진행하는 등 프로젝트에 대한 많은 걸 정했습니다.

아 그리고 또 기억에 남는 점으로, 구글 Meet이 프리미엄 없이는 1시간 제한이 있어서 하다가 중간에 방이 터지면 5분씩 쉬는 시간을 갖기도 했습니다.

💭 프로젝트에서...

목표는 어떻게 되는가

[North Star] velog 쓰는 모든 사람이 전체 통계를 아주 편하고 빠르게 보게하는 것

현재 저희의 목표는 위와 같습니다. 이를 위해 velog 를 쓰는 모든 사람이 velog dashboard 를 사용하게 만든다. 라는 하위 목표 또한 준비해둔 상황입니다.

스택은 어떻게 되는가

• 기술 스택?
  • 프레임워크 (NextJS) NextJS ⇒ 서버 측 자원 관리가 필요하긴 하지만, 최적화 기능도 많고 SEO도 좋음 ReactJS ⇒ 시작하기 빠르고 단순하지만, SEO가 조금 모자랄 수 있음 SEO 지원과 배포 용이성을 고려하면 NextJS가 좋을 듯 (100명 목표 달성 기회)
  • 언어 (Typescript) Javascript 사용시에 Human Error 발생 가능성 농후 Typescript를 통해 Human Error 방지 및 데이터 관리의 용이성 보장 (+ 모델링 구조 지정)
  • API 연동 (Fetch + Tanstack Query) 연동시에 꼭 fetch + Tanstack Query를 써야 할까? 서버에서 파싱을 위해 GraphQL을 사용한다면, 클라이언트에서도 사용해볼까? (다만 기능들을 보면 API가 많지 않을 것으로 보임, 단순한 방식도 괜찮을 듯)
  • 스타일링 (TailwindCSS) 스프린트가 적용되어 빠르게 개발해야 하는 점, 프론트엔드쪽에 큰 협업이 없다는 것을 고려하면 TailwindCSS가 좋을 듯 (+ NextJS는 TailwindCSS 기본 지원!)

다른 분들이 작성해둔 스크럼과 제 생각을 기반으로 골라본 기술 스택입니다.

또한 선택 과정에서 아래와 같은 이슈가 있었습니다.

• NextJS 선택 과정에서 현우님이 "단순 CSR이 아니라 SSG로 하는게 어떤지"에 대한 의견을 제안해주셨습니다. 다만 SSG는 프로젝트를 빌드할 때마다 값이 바뀌는 것으로 기억하고 있었고, ISR을 적용하여 일정 시간(서버에서 데이터를 갱신하는 시간)마다 데이터를 캐싱하는 식으로 적용하자는 제안을 드렸고, 괜찮을 것 같다는 답변을 들어 선택하였습니다.
• TailwindCSS 교내 프로젝트를 협업 없이 저 혼자 진행한 경험도 많았고, 프로젝트 개발시에 네이밍에 쓸 시간을 줄이면 좋지 않을까 싶어 선택하였습니다. 다만 이번 프로젝트는 프론트엔드/백엔드의 경계를 비교적 허물어둔 상태로 서로의 코드를 리뷰하며 진행하는 프로젝트였기 때문에 다시 한 번 고민해봐야 했습니다. 다만 현우님이 TailwindCSS를 사용해본 경험이 있다고 말씀해주셨고, 현 상황에서 이 라이브러리를 대체할 만한 라이브러리가 없다고 판단되어 선택하였습니다.

경험은 어땠는가

뭐, 겨우 1주차밖에 안 된 만큼 기술적으로 새로운 부분을 배우진 못했습니다. 다만 "스타트업의 느낌에 맞춘 프로젝트"를 표방했던 만큼 정말 체계적으로 진행됬고, 이 부분에서 굉장히 새로운 느낌이 많이 들었습니다.

좋았던 점 (K)

• 협업을 위한 쳬계적인 프로젝트 관리 그라운드 룰, 코드리뷰 룰 등 협업을 위한 규칙 마련이나 매일 매일 진행되는 daily scrum을 통한 정보 공유가 꽤나 인상적이었던 것 같습니다.

• 수평적인 의사소통 제가 고등학생임에도 불구하고 수평적으로 의사소통하는 경험도 만족스러웠습니다. 다들 서로를 적절히 높여서 말씀해주시는 것 같고, 어느 한 팀원분이 곧 면접을 보신다고 하니 현우님이 밤늦게 도와주셨던 점도 기억에 남는 일이었습니다.

아쉬웠던 점 (P)

• 용어와 개념에 대한 이해성 기술적 용어는 고사하고, OKR이나 애자일의 에픽 개념 등 생소한 용어나 개념들이 많아 대화에 집중하기 조금 어려웠던 것 같습니다. 나름대로 모르는 단어가 나올 때마다 찾아봤다고 생각하긴 하지만, 여전히 부족하긴 한 것 같습니다.

• 협업 경험 그 자체 위의 문제와 연결되는 문제로, 이해도가 낮아 집중하기 힘들다보니 중간 중간 멍한 느낌이 보이진 않았을까 싶습니다. 다들 열심히 진행해주셨는데, 중간 중간 멍한 표정을 짓거나 집중을 못 하는 모습을 보여드린 것 같아 조금 죄송스럽습니다.

해결 방법 (T)

• 용어 알아오기 중간 중간 남는 시간이 있는데, 이 시간마다 노션을 둘러보며 모르는 용어를 찾고, 정리해보는 게 좋을 듯 합니다. 이 부분을 해결하면 아마 협업 경험 그 자체에 대한 문제도 해결되지 않을까 추측됩니다.

결론적으로

새로운 프젝에 새로운 규칙, 처음 뵙는 분들과의 깊은 협업이 조금 어려운 느낌이긴 합니다. 하지만 이런 부분을 개선해나가며 성장하는게 아닐까 싶습니다.

이번에 많은 걸 정한 만큼, 앞으로 이 규칙들을 따라나가며 V.D.를 잘 완성시키기 위해 노력하자는 생각과 함께 글을 마칩니다.

(아 그리고 이제 내일이면 스크럼 마스터가 바뀔텐데, 만약 제가 된다면.. 과연 제가 스크럼 마스터를 잘 할 수 있을지 좀 걱정됩니다;)

판교까지 3시간..

(출발전에 대전역에서 먹었던 햄버거이자 몇 없는 사진중에 하나입니다..)

대충 대전역에서 아침을 떼우고, 수원역까지 가서 버스타고 진행 장소로 갔습니다. 판교디지털센터에서 진행됬는데, 지하철이 없어서 가는게 쉽지 않았던 것 같습니다.

발표 진행

(사실 사진을 많이 못 찍어서 이미지는 발표자 설명 자료로 대체하겠습니다)

플러터의 첫 세계에 발을 내딛기 - 이정주

플러터는 구글이 만든 오픈소스 프레임워크 만능이다 (한 코드로 거의 모든 플랫폼 지원) 선언형 ui (상태라는 개념 쓴다. 리액트하고 비슷) 구글어스가 플러터를 씀..? 신기하다 외에 BMW 도요타 삼성(타이젠)이 사용

공부 순서 추천

Dart 문법 공부 → UI 제작 공부 → 상태관리와 네비게이션 → 전역 상태관리(BLoC, Riverpod 등) → API 통신(JSON 하드웨어 등, http나 dip로 요청)

플러터 체크리스트

1. 취미로 개발, 컨셉을 잡고 아래 프로세스로 진행
   1. 기획 디자인
   2. 목업 데이터 작성
   3. UI 작성
   4. 상태와 네비게이션 작성
   5. API 연결
   6. QA
   7. 배포
2. 실무로 개발, 여러 기술을 결합한다
   1. 로그인 인증
   2. 푸시 알림 (FCM)
   3. Crashlytics나 로깅 도구
   4. 자동 업데이트
   5. 테스트 자동화
   6. 배포 프로세스 자동화 (CI CD)
3. 새 기술 두려워하지 말기
   1. 네이티브, 웹뷰 등 여러가지를 섞어쓴다
   2. 네이티브 sdk를 플러터에 적용하기 위한 지식 필요
   3. 새 기술을 두려워해선 안 됨

스위프트 UI로 MVP 만들기 - 서희찬

나만의네컷 앱, 뷰팜 앱 개발하심 미국 카네기멜런 대학교에서 연구중이심.. 새벽 한시에 강연중, 목 상태가 안 좋으시다

Object-C 스위프트 스위프트UI 차이점

• Object-c (1980)
  • 넥스트스텝 개발에 사용됨
• Swift (2014)
  • Object-C가 너무 오래되서 개발함, 오픈소스 언어임
  • UI킷과 같이 사용됨.
    • UI 구성에 사용
    • 스토리보드 제작 가능
• SwiftUI (2019)
  • 코드 한번에 Swift와 Ui킷을 사용할 수 있게 하는 신흥 강자
  • 하위 언어들에서 마이그레이션 가능

MVP 만들기

나만의 네컷 앱 개발하신 방법이나 설계 등을 발표해주셨다 MVVM 모델 사용하셨다. ㄴ MVC 모델에서 Controller의 역할을 줄이기 위해 MV - VM 식으로 만들어진 모델이다. 계층 관계 관련해서도 설명해주셨다. IOS 개발자 아니라서 무슨 말인지는 자세히 모르겠다. MVVM이 뭔지는 좀 알게 된 듯.

React native under the hood - 이현우

세션 준비한 동기는 뜨거운 감자라서? 정확히 설명은 안 해주셨다 플랫폼별로 android ios 폴더가 따로 있고, 그 외 구성은 일반 react와 비슷함 JS는 모듈화 js 파일을 못 읽음 그래서 합쳐줘야 하고, 그 역할을 번들러가 함 Webpack rollup metro(RN) 등등 있음 Polyfill 과정을 통해 JS 코드를 네이티브에 적용시킴 (js console.log → android log) Babel 통해 번들링된 코드를 React native 실행환경에 맞게 변환함 최근 코드 번들러가 바뀔 조짐이 보임 (뭔진 못들었다 찾아봐야지) JS 런타임 관련 사진 찍어뒀다

JSC

Apple이 제공한 JS 엔진 C 기반이라 메모리 관리 힘들고 브릿지 역할 과중 JSC와 RN의 강결합

JSI

JSC, v8, Hermes를 통해 JSI 개발됨 데이터 플로우도 찍어뒀다 네이티브가 2개.. (플랫폼과 C++)

RN 성능 개선 프로젝트

• Turbo module
  • 특정 모듈을 자연 초기화시켜 앱 시작 속도 개선
• Fabric
  • 새 UI 렌더링 아키텍처
  • 유저 인터렉션을 메인/네이티브 스레드에서 동기적으로 처리
• Codegen
  • 플랫폼 코드 타입을 JS에서도 지원
  • TS 활용시 좋음

깔끔한 선언형 ui with Jetpack compose - 박준수

XML(명령형) 에서 jetpack compose(선언형)으로 갈아타는 추세

컴포넌트 분리 시점

한 컴포넌트가 한 문제를 해결하게 개발 RN이랑 구조가 비슷한 듯 하다 고수준 컴포넌트일수록 정의가 명확해지고 커스텀되는 부분이 적어진다고 한다

컴포저블 함수 네이밍 가이드

UI를 가지는 컴포저블은 앞자리를 대문자로 (Pascalcase), 명사형 값을 반환하는 컴포저블은 소문자로 (camelCase) 값을 저장하는 컴포저블은 remember 붙이기, 유지될 값임을 명시 따로 사진으로 리스트 남김

파라미터 선언 가이드

명시적인 의존성과 암시적인 의존성 존재 Modifier를 파라미터로 무조건 가짐

• UI 반환하면 modifier 필요
• Modifier 여러개 안 됨
• Modifier가 컴포넌트의 최상단에 위치해야 함
• 자세한건 사진 참고

선언 순서

• 필수 파라미터
• Modifier
• 기타 파라미터
• Composable

파라미터는 Null이 없는게 좋음. 컴포넌트는 상태를 안 가지는 게 좋음 걍 이미지들은 공유된 페이지 보고 이해하자

AI 시대를 맞는 시니어 개발자의 노하우 - 배필주

코테는 문제 해결력을 위해 봄 이 문제 해결력과 AI에 대해 설명하셨다

손코딩은 왜 하는가

앞으로 우리가 보는건 새롭게 만날 문제들이다. 새로운 문제엔 새로운 창의력이 필요하고, 이를 위해서는 문제 해결력이 필요하다

창의적 문제 해결볍

• 논리적인 설득력
• 커뮤니케이션 스킬
• 현실 적용 구현 능력

라이트닝 토크

인간이 읽기 편한 코드가 좋은 코드인 것 같다 크로스 플랫폼 말고 네이티브에서만 되는 거는 알람, 앱끼리의 연동 등이 있다

다시 돌아가기

돌아가는데 4시간 걸렸습니다. 6시 반에 출발해서 집에 10시 반에 도착했습니다. 아마 퇴근시간이랑 겹쳐서 오래 걸리지 않았을까 싶은데.. 그래도 주말이어서 다행이지 않았을까 싶기도 합니다.

여담

사실은 FECONF도 다녀올 생각이었는데, 티케팅 시간이 이동수업 시간이라 신청 페이지조차 못 보고 마감되서 HYPER APP만 참여하기로 했습니다. 뭐 아쉽긴 하지만, HYPER APP 하나만으로도 충분히 좋은 경험이었던 것 같아서 다행입니다.

아 그리고 마지막 럭키드로우 시간에 티셔츠를 받았습니다. 하필 집에 두고 오는 바람에 사진은 없는데.. JetBrains 옷입니다. 못받으신 분들은 아쉽지만.. 그래도 뭔가 받아가니까 기분이 좋았습니다

학교 동아리 프로젝트로 진행중인 PiCK 안드로이드 앱에 Sentry를 적용해 지금까지 쓰고 있습니다.

그런데 오류가 떠도 저한테 직접 메세지로 알려주진 않다보니, 아침부터 계속 로그 화면을 켜두고 모니터링해야 하는 문제가 있었습니다. 게다가 오류가 발생했을 때 자동으로 새로고침이 되는게 아니기에, 중간중간 새로고침해야 하는 불편함도 있었습니다.

이런 불편함들이 늘어나던 차에, 오류 제보까지 점점 늘어나고 있었습니다. 오류 제보 기능이 없었기에 사용자가 제게 와서 직접 제보를 하는 방식이었는데, 이 부분도 사용성에 꽤 문제가 되었기에 센트리의 오류 로그와 디스코드를 연동해보기로 했습니다.

🔗 자동 연동 시도

우선 센트리와 메신저를 연결하는 방법은 여러가지가 있습니다.

슬랙과 연동할 수도, 디스코드와 연동할 수도, 정말 뜬금없이 마이크로소프트 팀즈와 연동할 수도 있습니다. 그 외에도 깃허브, 깃랩, 비트버킷 등 여러 서비스들을 지원하는 모습입니다.

제가 정한 건 디스코드였기에, 디스코드로 들어가 봅니다.

유료 에반데;

아뿔싸, 디스코드 연동을 사용하려면 유료 플랜에 가입해야 했습니다.

슬프게도 유료 플랜의 최소 가격은 $29였고, 지원금도 잘 안 나오는 동아리 서비스에 적용하기엔 너무 큰 돈이였습니다.

이러면 어떻게 연동하지..?

방법이 없다고 생각했으나.. 다행히도 웹훅 연동은 무료였습니다.

하지만 저는 순수 프론트만 공부하던 개발자로, 웹훅은 디스코드 서버 설정 창에서나 보던 메세지였습니다.

그래도 Sentry 공식 사이트에 예제 문서와 예제 코드가 있으니, 이 문서를 읽으면서 웹훅으로 시도해봅니다.

🪝 웹훅으로 수동 연동하기

웹훅으로 수동 연동하면서, 단순한데 치명적인 문제가 몇개 생겼습니다. 아무래도 처음 하는 서버 작업에, discord.js까지 건드려야 하다 보니 조금 헷갈리는 게 많았던 것 같습니다.

유저 데이터는 어디로..?

예제 문서를 보면, 데이터로 유저 정보나 태그 등 이벤트에 대한 모든 정보가 넘어오는 페이로드가 있는 걸 알 수 있습니다. 근데 이상하게도 제 서버에서는 일부 데이터만 넘어왔습니다.

처음엔 유저 데이터를 따로 받질 않다 보니 그냥 오류 데이터만 넘어오면 됬었는데, 개발중에 유저 데이터도 전송하게 수정하고 나서부터 이 부분이 계속 걸렸습니다.

여기서 몇시간을 해맸는데.. 알고 보니 integration 설정에서 세팅을 켜주는게 아니라 alerts에서 따로 액션을 만드는 방식으로 설정하는 거였습니다.

날짜가 왜 이러지;

넘어오는 날짜와 시간이 한국 시간대가 아닌 GMT 시간대를 기준으로 반환되는 문제가 있었습니다.

센트리 사이트를 뒤져본 결과, 유저 설정에 시간대 설정이 있긴 했는데.. 사이트에서 표기되는 시간대만 한국 시간대로 바뀌었고 웹훅의 시간대는 바뀌지 않았습니다.

아무리 찾아봐도 자료가 안 나와서 결국 dayjs 라이브러리를 이용해서 반환된 날짜와 시간을 한국 시간대로 바꿔주었습니다. (솔직히 좀 비효율적인 것 같긴 합니다.. 혹시 센트리와 메신저 연동 해보신 적 있으신 분은 댓글로 알려주시면 감사하겠습니다.)

🚀 결론

결국 어떻게든 해서 완성은 시켰습니다. 코드도 더럽고, 크게 복잡한 기능도 없는데 시간이 걸리긴 했지만 나름 재밌는 경험이었던 것 같습니다. (그리고 가끔 디스코드로 수십통씩 날아오는 500 에러도 참.. 즐겁습니다)

아 그리고, 서버 해결을 아직 못 했습니다. 학교에서 지원하는 배포 서비스라도 써볼까 했는데, 기능 자체도 너무 단순한데다가 요즘 갈아엎고 있어서 그런지 좀 복잡해져서 안 쓰기로 했습니다. 아마 홈서버라도 구축해서 나중에 다시 올리지 않을까 싶긴 한데, 이 부분은 좀 더 알아봐야 할 것 같습니다.

https://github.com/five-standard/PiCK_Android_Webhook

번외

첫 글이라 글을 잘 쓴건지 모르겠습니다. 다른 선배님들 보면 다들 잘 쓰시는 것 같은데, 앞으로 개발만 하지 말고 글도 좀 많이 써봐야 할 것 같습니다. 아무튼 제 첫 글 읽어주셔서 감사합니다.