협업

[42 글로벌프로그램] 다시 미국에 오다 - (3편/완결)

이번 편에서는 42 글로벌프로그램의 피날레, Seattle Tech Week와 프로그램을 통해 느낀 점들을 돌아보고자 합니다. 혹시 프로그램에 참여하게 된 배경과 초반부가 궁금하시다면 이전 글들을 참고바랍니다. 기회를 발견하고 참여하기까지의 과정:  [42 글로벌프로그램] 다시 미국에 오다 - (1편) 2년 만의 미국 생활과 프로그램 전반부:  [42 글로벌프로그램] 다시 미국에 오다 - (2편) 플라이휠 그렇게 다섯 주가 지나고, 6주차엔…

hyeon_B•

추리 게임 시나리오, 외주에서 자체 파이프라인으로

문제: 추리 시나리오를 한 편 늘리려면 매번 외부 제작사와 새로 계약해야 했다. 팀에는 전담 작가도, 완성된 원고를 검수할 사람도 없었다. 결정: 용의자 한 명을 이루는 필드와 개수를 스키마로 고정하고, Claude 세션 하나가 설계 역할, 작성 역할, 검수 역할을 차례로 맡는 10단계 저작 파이프라인을 만들었다. 다음 단계로 넘어가도 되는지는 Python 스크립트(게이트)가 판정한다. 게이트는 산출물 존재와 승인 상태를 검사하고, 체크…

hyeon_B•

[스타트업/기술] WebP 변환을 통한 이미지 로딩 최적화 및 GCS 업로드 자동화 | PNG 대비 용량 89%, 지연 시간 81% 개선

문제 GCS 직접 호출로 한 번 줄였는데도 이미지 한 장에 1.39s가 걸렸다. 원인은 파일 자체였다. 에셋이 전부 무손실 PNG였고, 측정한 이미지는 477KB였다. 결정 PNG를 품질 82의 WebP로 바꾸고, 변환과 GCS 업로드(캐시 헤더, URL 맵 포함)를 셸 스크립트 두 개로 묶었다. 대가 손실 압축이라 화질이 조금 깎이는데, 얼마나 깎였는지는 재지 않았다. WebP를 못 읽는 환경을 위한 폴백도 두지 않았다. 결과 …

hyeon_B•

[스타트업/기술] SSoT 기반 카탈로그 시스템 설계 | 파편화된 가격 데이터의 비효율성을 극복하고 프로모션 구조 구축하기

서비스를 고도화하는 작업을 진행하면 할수록 초기에 잘 동작하는 것처럼 보였던 설계가 발목을 잡는 순간이 온다. 최근 우리 서비스의 결제 및 가격 구조를 개편하면서 이 사실을 다시 한번 느꼈다. 기존에는 콘텐츠마다 가격을 따로 정할 수 있게 설계돼 있었다. 그런데 출시를 앞두고 프로모션을 기획해야 하는 시점이 오자 이 구조가 기술 부채로 돌아왔다. 이 글에서는 흩어진 가격 데이터를 SSoT(Single Source of Truth, 단일 진실 …

hyeon_B•

[스타트업/기술] GitHub Actions CI 파이프라인 | 프로덕션 배포 전 런타임 에러를 차단하는 테스트 자동화

문제 2026년 3월 20일, main에 직접 푸시한 코드가 Cloud Run에 자동 배포된 뒤 채팅 요청이 500을 냈다. 원인은 Gemini 호출의 400 INVALID_ARGUMENT 였고 로컬에서는 한 번도 보지 못한 에러였다. 결정 외부 의존성을 mock으로 바꾼 pytest를 만들고, PR마다 포매터·린터·테스트·Docker 빌드를 돌리는 GitHub Actions CI를 붙였다. main에는 PR로, CI가 통과한 것만 들…

hyeon_B•

[스타트업/협업] 디스코드(Discord), 단순한 메신저를 넘어 우리 팀의 가상 오피스가 되기까지

문제 팀원이 모두 떨어져 일하다 보니 서로의 상황을 알기 어려웠고, 주 1회 회의가 밀린 소식 공유에 다 쓰였다. 결정 카카오톡과 노션을 오가던 소통을 디스코드의 텍스트 채널, 포럼, 음성 라운지로 나눠 옮겼다. 유료 부담이 있는 슬랙은 쓰지 않았다. 대가 도구 비용은 0에 가깝지만, 어떤 대화를 어느 채널에 둘지 같은 규칙은 우리가 처음부터 정해야 했다. 결과 회의가 소식 정리에서 논의 중심으로 바뀌었다. 아직은 체감이고 측정…

hyeon_B•
게시물 더보기
검색결과 없음