Salangdung_i의 기록

라벨링 툴을 개발하면서 한동안 이유를 알 수 없는 현상을 겪었습니다. 지도 위에 feature를 하나 추가했을 뿐인데, 기존에 그려놨던 feature들이 전부 깜빡이는 것이었습니다. 분명히 하나만 추가했는데 왜 전체가 반응하는 것인지 한참 동안 이해하지 못했습니다. 뒤늦게 알게 된 이유는 단순했습니다. React와 지도 엔진이 서로 다른 방식으로 동작하고 있었기 때문입니다. React가 관리하는 것과 지도 엔진이 관리하는 것React는 DOM을 관리합니다React는 선언형(Declarative) 입니다. 결과를 선언하면 React가 알아서 화면을 만들어줍니다.const [markers, setMarkers] = useState([]);return ( {markers.map(m => )} );..

5분할 화면이라니요?최근 다개년 데이터를 비교해야 하는 요구사항이 들어왔습니다. 기획서의 안은 화면을 5개로 쪼개서(5분할) 연도별 데이터를 보여주자는 것이었죠.개발자로서 구현만 생각하면 시키는 대로 5개 화면을 띄우면 그만입니다. 하지만 유저의 입장이 되어보니 아찔했습니다. 화면 5개를 동시에 띄워놓고 눈동자를 바쁘게 굴리며 변화를 찾는 건 고통에 가까운 UX였거든요. 이건 "만들어도 유저가 외면할 서비스" 라는 확신이 들었습니다. "요구사항 그 이상의 신뢰, 그리고 역제안본격적인 개발에 앞서, PM님은 고용량 데이터를 다루는 만큼 시스템의 안정성을 먼저 확인하고 싶어 하셨습니다.PM의 요구사항 완수 (PoC): 시스템의 병목을 줄이기 위해 NAS vs GeoServer 성능 테스트를 선행했습니다. ..

2025년 11월부터 2026년 3월까지, 지난 5개월은 기획·개발·운영·피벗까지 제품의 전 사이클을 직접 경험한 시간이었습니다.'AI 활용 서비스 기획/개발 전문가 과정'을 시작으로 내은퇴(MyRetire)와 모아모아(MoaMoa)라는 두 개의 프로덕트를 세상에 내놓으며, 저는 '어떻게 구현할 것인가'를 고민하던 엔지니어에서 '왜 이 제품이 존재해야 하는가'를 결정하는 프로덕트 메이커로 성장했습니다. 내은퇴 · MYRETIRE국민연금·자산·지출을 한 번에 입력하고, 공식 엔진으로 은퇴 가능 나이와 자산 소진 시점을 1분 만에 확인하세요.my-retire.co.kr 1. 첫 번째 벽: "만들면 쓸 줄 알았다" (홍보와 마케팅의 체득)처음 제품을 배포했을 때 마주한 것은 기술적 난관이 아닌 '침묵'이었습..

모든 시작에는 끝이 있듯, 지난 몇 개월간 저의 모든 고민과 열정을 쏟았던 '내은퇴(MyRetire)' 프로젝트를 여기서 매듭지으려 합니다. 누군가에게는 이 결정이 중도 포기로 보일 수 있지만, 저에게는 다음 단계로 도약하기 위한 가장 치열하고 전략적인 선택입니다. 내은퇴 · MYRETIRE국민연금·자산·지출을 한 번에 입력하고, 공식 엔진으로 은퇴 가능 나이와 자산 소진 시점을 1분 만에 확인하세요.my-retire.co.kr 1. 시작의 씨앗: 엑셀 시뮬레이터에서 웹 서비스로이 프로젝트는 유튜버 미키피디아님의 '자산관리 비법' 영상을 보며 시작되었습니다. 엑셀로 정교하게 짜인 경제적 자유 시뮬레이터를 보며, "이를 더 직관적인 웹 서비스로 만든다면 많은 사람의 노후 불안을 해소할 수 있지 않을까?"라..

'내은퇴' 프로젝트를 처음 런칭했을 때 제 목표는 명확했습니다. "누구나 쉽게 자신의 노후자금을 계산하게 만들자." 하지만 실제 커뮤니티에 제품을 공개하고 유저들의 피드백을 마주했을 때, 제가 간과했던 냉혹한 비즈니스의 현실을 깨달았습니다. 내은퇴 · MYRETIRE국민연금·자산·지출을 한 번에 입력하고, 공식 엔진으로 은퇴 가능 나이와 자산 소진 시점을 1분 만에 확인하세요.my-retire.co.kr 1. 리텐션의 한계: "이거 1년에 몇 번이나 쓸까요?"일반 사용자들에게 은퇴 설계는 '중요하지만 시급하지 않은 일'이었습니다. 한 번 계산해보고 나면 내년 이맘때쯤에나 다시 열어볼 서비스였죠. 개인이 1년에 단 한 번 사용하는 서비스로는 지속 가능한 리텐션을 확보하기 어렵다는 결론에 도달했습니다. 2...

소프트웨어 개발에서 가장 무서운 것은 '복잡성'입니다. 특히 여러 명의 담당자를 거치며 일관성 없이 쌓인 코드는 팀의 생산성을 완전히 마비시키곤 합니다. 최근 제가 담당했던 프로젝트가 바로 그런 상황이었습니다.재앙의 시작: 파편화된 코드와 90개의 스토어marinetraffic 예시 이미지에서 보시는 것처럼, 하나의 화면에 수많은 기능과 데이터 시각화가 동작하는 복잡한 대시보드 프로젝트였습니다.장기간 여러 담당자를 거치면서 프로젝트의 질서는 무너졌습니다.데이터 흐름의 오염: 전임자들이 남긴 로직들이 엉키며 데이터가 어디서 오고 어디로 가는지 알 수 없게 되었습니다.스토어의 홍수: 무분별하게 생성된 90개의 상태 관리 스토어는 관리 한계를 넘어섰고, 작은 수정 하나에도 예측 불가능한 사이드 이펙트가 발생했..

앞선 글에서 '모아모아'가 기술적으로 어떻게 만들어졌는지 기록했습니다. 실시간 동기화, 역할 기반 권한 분리, 모노레포 아키텍처까지 나름 공들인 결과물이었습니다. AI와 함께 2주 만에 완성한 디지털 스티커판 '모아모아''모아모아' 프로젝트는 단 2주 만에 시작하고, 2주 만에 멈춘 프로젝트입니다. 이번 글에서는 Product Engineer로서 0에서 1까지 어떻게 제품을 설계하고 구현했는지, 그 기술적 실체를 기록합니다. 왜salangdung.tistory.com그런데 이 모든 것이 쿠팡에서 파는 8,000원짜리 종이 스티커판 앞에서 무너졌습니다. 1. 문제의 발견장기 프로젝트였던 내은퇴 의 안정화 단계를 지나, 저는 엔지니어로서의 시야를 넓히고 싶었습니다. 단순히 코드를 짜는 것을 넘어, "기술이 ..

대부분의 초기 프로젝트에서 '어드민(Admin)'은 우선순위 뒤편에 밀려나기 일쑤입니다. 하지만 저는 "운영 효율이 곧 제품의 성장 속도"라고 믿습니다. 단순히 DB 값을 수정하는 툴이 아니라, 비즈니스 의사결정을 돕는 '데이터 제품(Data Product)'으로서 백오피스를 구축한 과정을 공유합니다. 1. 관점의 전환: "개발자용 모니터링"에서 "운영자용 대시보드"로이전에 제가 만든 백오피스 버전0.1은 사실 '관리자용'이라기보다 '개발자용'에 가까웠습니다. 데이터에서 의미 있는 지표를 찾아내기보다, 그저 DB에 값이 잘 들어갔는지 확인하는 '데이터 출력 창'에 불과했습니다.하지만 이번 내은퇴(MyRetire) 백오피스 버전0.2 프로젝트에서는 완전히 다른 관점으로 접근했습니다. "실제 운영자가 매일 ..

'모아모아' 프로젝트는 단 2주 만에 시작하고, 2주 만에 멈춘 프로젝트입니다. 이번 글에서는 Product Engineer로서 0에서 1까지 어떻게 제품을 설계하고 구현했는지, 그 기술적 실체를 기록합니다. 왜 멈췄는지가 궁금하다면, 글 말미의 링크에서 비즈니스 회고를 확인하실 수 있습니다. 1. 설계의 핵심: "현장의 긴박함을 담은 PRD"단순히 화면을 그린 것이 아니라, 실제 학원 환경의 페인 포인트(Pain Point)를 해결하기 위한 최상위 기준(PRD)을 먼저 정립했습니다.시스템 존재 목적: 수업 흐름을 방해하지 않으면서 아이의 긍정 행동을 즉시 강화하고, 보상 이력을 명확하게 관리하는 것에 집중했습니다.우선순위 원칙: 기록의 정밀함보다 즉시성을, 화려함보다 명확한 인지를 최우선으로 두어 미니..