1인 개발로 사내 운영 툴을 만들면서 가장 많이 의지한 도구가 Claude Code다. Claude Code 개발 경험을 한 마디로 요약하면, “옆에 시니어 개발자가 앉아 있는 느낌”이다. 코드를 직접 읽고, 수정하고, 실행하면서 함께 작업한다. 혼자 개발하는 입장에서 이게 얼마나 다른 경험인지, 실제로 겪은 내용을 정리한다. 기존 AI 코딩 툴과 뭐가 다른가 브라우저에서 Claude나 ChatGPT에 코드를 물어보는 방식은 … 더 읽기
자동화를 결심한 건 어떤 거창한 계기가 아니었다. 월말 정산에 며칠씩 묶이고, CS 처리하다 브랜드사에 확인 전화하고, 가격 역전을 뒤늦게 발견하는 일이 반복됐다. 업무 자동화 효과가 얼마나 될지 따져보기 시작한 건 그때부터였다. 지금은 운영 툴이 안정화된 지 꽤 됐고, 실제로 얼마나 달라졌는지 정리해봤다. 자동화 전 — 반복 업무 풍경 월말 정산. 채널마다 정산 데이터를 따로 받아서 … 더 읽기
CS 관리 시스템을 만들고 나서 한동안 잘 쓰고 있었다. 그런데 CS가 쌓이다 보니 새로운 불편함이 생겼다. 접수 폼에서 CS 유형, 귀책, 세부 사유를 담당자가 직접 선택해야 했다. 이커머스 경험이 어느 정도 있으면 금방 하는데, 새 직원이나 CS가 낯선 사람은 어떤 걸 골라야 할지 매번 헷갈렸다. 클레임 사유 텍스트가 이미 있는데, 이걸 읽고 AI가 자동으로 분류해주면 … 더 읽기
CS 처리가 번거롭다는 건 이커머스 운영하는 사람이라면 다 안다. 근데 우리 상황은 조금 더 복잡했다. 취급하는 브랜드가 수십 개였고, 브랜드마다 반품·교환 정책이 달랐다. 고객 귀책인지 회사 귀책인지, 브랜드사 귀책인지에 따라 비용 부담자도 달랐다. 이게 어디에도 정리돼 있지 않고 담당자 머릿속에만 있었다. CS 하나 처리하려면 경험 많은 담당자에게 묻거나, 브랜드사에 직접 전화해서 확인해야 했다. 이 비효율을 … 더 읽기
어느 날 우연히 네이버 쇼핑에 우리 상품을 검색했다가 황당한 걸 발견했다. 우리 판매가가 최저가보다 비쌌다. 며칠째. 경쟁사가 가격을 내렸는데 우리는 몰랐던 것이다. 고객 입장에서는 당연히 더 싼 곳에서 산다. 얼마나 오래 이런 상태였는지도 몰랐다. 그게 가격 모니터링 자동화를 만들게 된 직접적인 계기였다. 수동으로 가격을 확인한다는 것의 현실 취급하는 상품이 수천 개다. 이걸 매일 하나하나 네이버 … 더 읽기
지난 글에서 외부 API 연동과 데이터 파싱의 삽질을 다뤘다. 그 고통스러운 과정을 통해 결국 플레이오토 주문 데이터를 내 DB로 끌어오는 데 성공했다. 데이터가 들어오기 시작하자 자연스럽게 다음 문제가 떠올랐다. “이 데이터로 이제 정산을 어떻게 하지?” 이전까지 월말 정산은 이런 식이었다. 채널마다 엑셀을 따로 받아서 하나로 합치고, VLOOKUP으로 원가 테이블을 연결하고, 수기로 채널별 이익을 계산했다. 빠르면 … 더 읽기
지난 글에서 사내 맞춤형 ERP를 위한 거창한 백엔드 아키텍처와 데이터베이스(DB) 정규화 계획을 세웠다. 뼈대를 잡았으니 이제 외부 데이터를 내 시스템으로 예쁘게 가져오기만 하면 될 줄 알았다. 하지만 현실은 달랐다. 플레이오토 같은 외부 커머스 솔루션의 API를 연동해 주문 데이터를 수집하는 첫 단계부터, 끝없는 예외 처리와 삽질의 늪에 빠지고 말았다. 1인 개발자로서 이커머스 데이터를 다루며 겪은 뼈아픈 … 더 읽기
쇼핑몰의 모든 데이터가 모이고 흐르는 혈관 같은 사내 시스템(ERP). 이 거대한 프로젝트를 1인 프로그래머로서 멱살 잡고 이끌어가야 할 때, 코딩을 시작하기 전 아키텍처를 설계하는 단계가 가장 고통스러우면서도 중요하다. 첫 단추를 잘못 끼우면 나중에 데이터가 쌓였을 때 시스템 전체를 갈아엎어야 하는 대참사가 발생하기 때문이다. 맞춤형 ERP를 기획하며 초기 단계에서 치열하게 고민했던 아키텍처와 기술 스택 결정 과정을 … 더 읽기
쇼핑몰 CS를 처리하다 보면 문의 자체보다도 분류가 더 번거로운 경우가 많다.반품인지 교환인지, 고객 귀책인지 회사 귀책인지, 세부 사유를 무엇으로 볼지 담당자가 직접 판단해야 하고, 같은 내용을 봐도 사람마다 기준이 조금씩 달라진다. 특히 클레임 건수가 쌓이기 시작하면 이 단계에서 시간이 많이 소모된다. 내부 CS 모듈을 만들면서 먼저 해결한 것은 플레이오토 클레임 자동 수집이었다. 반품/교환 상태 주문을 … 더 읽기
지난 글에서 사내 맞춤형 ERP를 위한 거창한 백엔드 아키텍처와 데이터베이스(DB) 정규화 계획을 세웠다. 뼈대를 잡았으니 이제 외부 데이터를 내 시스템으로 예쁘게 가져오기만 하면 될 줄 알았다. 하지만 현실은 달랐다. 플레이오토 같은 외부 커머스 솔루션의 API를 연동해 주문 데이터를 수집하는 첫 단계부터, 나는 끝없는 예외 처리와 삽질의 늪에 빠지고 말았다. 1인 개발자로서 이커머스 데이터를 다루며 겪은 … 더 읽기