현재 보유한 개인 프로젝트들의 운영 자동화를 위해 GitHub Actions와 웹훅(Webhook)을 연동하여, 주간 의존성 취약점 검사 결과와 특정 프로젝트의 Supabase DB 핑(Ping) 테스트 결과를 디스코드(Discord)로 받아보고 있었다. 하지만 디스코드에서 슬랙(Slack)으로 알림 채널을 전면 이관해야겠다고 결심하게 되었는데, 이유는 간단했다. 개인적으로 평소 디스코드의 사용 빈도가 낮은 반면, 슬랙은 이전부터 자주 접해 훨씬 익숙했기 때문이다. 실무에서 동료가 서버 및 프로젝트 이슈를 슬랙 알림으로 연동해 관리하는 모습을 보며 나도 충분히 구현할 수 있을거라는 확신이 있었고, 스마트폰에 디스코드와 슬랙을 모두 설치하는 것보다 슬랙으로 채널을 일원화하는 편이 관리 측면에서 훨씬 합리적..

그동안 사용해보지 않은 기술스택을 공부해보기 위해 새로운 프로젝트를 기획하면서, pnpm과 shadcn/ui을 도입해보기로 했다.특히 패키지 매니저로 npm 대신 pnpm을 선택한 이유는 명확하다. 프로젝트가 늘어날수록 node_modules가 차지하는 무거운 용량과 패키지 설치 속도 문제를 개선하고 싶었기 때문이다. 이번 글에서는 맥북에 pnpm을 설치하고 프로젝트를 생성하는 과정부터, pnpm과 npm의 차이점, 그리고 shadcn/ui 초기화 시 마주친 선택지들의 의미를 기록한다.✍️pnpm 설치 및 Vite 프로젝트 생성맥북 환경이었기에 Homebrew를 이용해 먼저 전역(Global) 환경에 pnpm을 설치해주었다.# Homebrew를 통한 pnpm 설치brew install pnpm그리고 로컬..

지난 포스팅에서는 개인 프로젝트의 리뷰 작성 기능에 Supabase Storage를 연동하여 포스터 이미지를 업로드하는 과정을 다루었다. 당시 스토리지 업로드 과정에서 발생했던 RLS(Row Level Security) 권한 에러를 해결하며 이미지 등록 기능 구현에 성공했지만, 해당 구현에는 한 가지 명확한 한계점이 남아있었다.바로 '가비지(Garbage) 이미지 누적' 문제다. 사용자가 리뷰를 수정하며 포스터 이미지를 교체하거나, 리뷰 자체를 삭제해도 DB의 데이터만 변경될 뿐, Supabase Storage에 이미 올라간 기존 이미지 파일은 그대로 남아있게 된다. 이러한 고립된 파일들이 쌓이면 불필요하게 스토리지 용량을 차지하게 되고, 서비스가 커질수록 관리 비용과 효율성에 악영향을 미친다. 따라서 ..

내가 처음 개발 공부를 시작했을 때만 해도, React 프로젝트는 대부분 create-react-app(CRA)으로 만들곤 했다. 나 역시 별다른 고민 없이 CRA를 사용했지만, CRA는 내가 쓰지도 않는 무거운 패키지들까지 node_modules에 설치되어서 프로젝트가 제법 무겁게 느껴졌다. 그러다 접하게 된 Vite는 필요한 것만 골라 가볍게 설치할 수 있을 뿐만 아니라 빌드 속도까지 획기적으로 빨랐다. Vite를 경험하면서, 프론트엔드 빌드 생태계가 얼마나 빠르게 발전하는지 실감할 수 있었다.하지만 빌드 도구가 Vite로 바뀌는 와중에도 내가 사용하는 패키지 매니저는 늘 npm이었다. 다른 프론트엔드 개발 레포나 기술 아티클에서 pnpm이나 yarn을 사용하는 모습을 보면서, 이들이 npm과 구체적..

서점에서 우연히 발견하고 정독한 도서의 독서기록.책 속의 예시 코드는 Java여서, 책을 읽으며 프론트엔드에서도 적용되는 부분인지 모호했던게 있어서 따로 공부했다. 직접 메모한 내용에 개인적으로 공부한 내용을 추가해서 기록해본다.지난 글은 아래 링크에 있다.https://hjinn0813.tistory.com/207 [도서] 육각형 개발자 #1 (기술)며칠 전에 서점에서 우연히 발견하고 대충 읽어봤는데 내용이 좋아서 정독해보고 싶었다. 동네 도서관에 있길래 중요한 부분을 메모하면서 읽다가, 휴대폰 배터리가 없어서 집에 오는 길에 E-boohjinn0813.tistory.com응집도와 결합도컴퓨터 프로그래밍에서 중요한 단어이다.좋은 코드, 좋은 설계를 가진 아키텍쳐는 높은 응집도와 낮은 결합도를 추구한다...

며칠 전에 서점에서 우연히 발견하고 대충 읽어봤는데 내용이 좋아서 정독해보고 싶었다. 동네 도서관에 있길래 중요한 부분을 메모하면서 읽다가, 휴대폰 배터리가 없어서 집에 오는 길에 E-book을 구매해서 마저 읽었다."좋은 시니어 개발자가 되고 싶은 주니어들을 위한 책"이어서인지, 현재 주니어 레벨인 내가 읽으면서 밑줄친 부분이 많았다. 책 속의 예시 코드는 Java여서, 책을 읽으며 프론트엔드에서도 적용되는 부분인지 모호했던게 있어서 따로 공부도 했다. 직접 메모한 내용에 개인적으로 공부한 내용을 추가해서, 기술과 아키텍쳐 설계 위주로 나눠서 기록해보려고 한다.개발이란?표면적으로는 유저에게 도움을 주는 서비스, 혹은 유저가 매력을 느낄 기능을 만드는 활동. 고객의 요구를 파악하고 니즈를 충족하는 기능을..

Supabase를 활용하여 개인 프로젝트에 리뷰 등록 CRUD 기능을 구현했는데, 이 과정에서 한 가지 생략한 것이 '이미지 첨부' 기능이었다. 의도적인 판단이었는데, '이미지 첨부' 기능은 단순히 파일 하나를 올려서 끝나는 것이 아니라 용량 최적화, 파일명 중복 방지, 업로드 실패 시 예외 처리 등 고려해야 할 변수가 많았기 때문이다. 무엇보다 '리뷰 등록'이라는 큰 기능 단위 내에 속한 부수적인 영역이었기에, 핵심인 데이터 CRUD 흐름부터 명확히 구축하는 것이 우선이라고 생각했다.하지만 기본적인 CRUD 구현을 마친 후 서비스를 점검하면서, 이미지 첨부 기능의 필요성을 강하게 체감했다. 기존의 읽기(Read) 및 리스트 페이지는 영화 포스터 이미지를 정상적으로 보여주고 있었지만, 작성 페이지에서 이..

매일 특정 시간에 알아서 실행되는 자동화 워크플로우는 참 편리하다. 필자 역시 현재 진행 중인 개인 프로젝트에서 Supabase의 자동 정지를 막으려고 스케줄 워크플로우를 구축해 두었다. 하지만 이 녀석이 제대로 일했는지 확인하려면, 매번 직접 깃허브 레포지토리의 Actions 탭을 열어봐야 하는 번거로움이 있었다.예전에 Gist를 이용한 커밋 수 자동 갱신 워크플로우가 며칠간 미작동했음에도 알림을 받지 못해 뒤늦게 발견했던 경험이 있어서, 만약 이번 Supabase 워크플로우가 어느날 갑자기 미작동하거나 실패했는데 내가 모르고 있는 상황이 생긴다면 문제가 커진다고 생각했다. 그래서 워크플로우의 상태를 지켜보다가 실시간으로 알려줄 나만의 AI 비서를 도입하기로 했다. 이번 포스팅에서는 GitHub Act..

이직 준비를 하면서 이력서에 회사의 비즈니스 모델을 입력하는 항목을 보게 되었다. B2B, B2C, O2O 같은 용어는 자주 들어봤지만 정확한 의미와 차이점을 설명하기는 어려웠다. 비즈니스 모델은 고객을 기준으로 분류하기도 하고, 서비스 제공 방식에 따라 구분하기도 한다. 헷갈리지 않게 기록해두려고 한다.1. 누구에게 판매하는가? (고객)누구에게 파는가?(고객) → B2B, B2C, B2B2C, C2C, D2C, B2GB2B (Business to Business)기업 → 기업으로 제품이나 서비스를 판매하는 모델예시:ERP, 그룹웨어 판매기업용 클라우드 서비스기업용 보안 솔루션제조업체에 부품 납품실제 사례: Salesforce, SAP, AWS 등특징:고객 수는 적지만 계약 규모가 큼영업 사이클이 길다의..

지난 포스팅에서는 개인 프로젝트에 Supabase를 도입하여 리뷰 데이터의 CRUD 기능을 구현했다. BaaS를 활용하여 내 손으로 리뷰 시스템을 구축했다는 사실이 기뻤지만, Supabase 무료 플랜을 사용하면서 한 가지 현실적인 문제에 직면했다.Supabase의 무료 플랜은 일주일간 아무 활동이 없으면 프로젝트가 자동으로 정지된다는 것이다.상용 서비스가 아닌 개인 포트폴리오용 프로젝트 특성상, 배포 페이지에 접속하는 유저가 따로 존재하지 않는다. 그렇다고 내가 매일 이 프로젝트만 작업하는 것도 아니고, 실제로 현생에 충실하느라 배포 페이지에 접속하는 것을 잊어서 Supabase로부터 ‘프로젝트가 일시 정지될 예정’이라는 경고 메일을 받기도 했었다. 배포 페이지에 접속하지 못해 프로젝트가 정지되면, 기..