2026-04-15 (수) 개발일지
오늘의 삽질과 깨달음: 7개 프로젝트를 오가며 배운 것들
오늘은 정말 여러 프로젝트를 왔다갔다 했던 하루였다. 아침부터 저녁까지 드롭쉬핑자동화, 사주, 소명처리시스템, 자동매매, bit-scalp, 하네스, free-cli까지 총 7개 프로젝트를 건드렸는데, 머릿속이 프로젝트 컨텍스트로 가득 찼다. 각 프로젝트마다 다른 문제를 마주하고 다른 해결책을 찾아야 했지만, 공통적으로 느낀 건 “기존 코드를 이해하는 시간이 실제 구현 시간보다 더 길다”는 점이었다.
드롭쉬핑자동화: Shopify 의존성 제거의 함정
문제: 클라이언트가 “Shopify 없이 드롭쉬핑 자동화를 만들 수 있냐”고 물어봤다. Pulse 시스템으로 재수립한 마스터 플랜에 따라 Pulse 1에서 Shopify 관련 코드를 모두 제거해야 했다.
시도: grep -r "shopify"로 의존성 파일을 찾아보니 정말 많았다. product.service.ts, order.service.ts, webhook.controller.ts 등 10개가 넘는 파일에서 Shopify API 호출이 박혀있었다. Prisma 스키마에도 shopifyId, shopifyOrderId 같은 필드가 있고, 환경변수에 SHOPIFY_ 접두사가 붙은 것들까지.
해결: 차근차근 하나씩 교체했다. syncToShopify() 메서드는 아예 삭제하고, create() 메서드에서 Shopify 동기화 호출을 제거했다. 대신 자체적인 slug 생성 로직을 추가했다. 가장 까다로웠던 건 웹훅 부분이었는데, Stripe 웹훅으로 전환하면서 이벤트 핸들러를 완전히 재작성해야 했다.
배운 점: 서드파티 서비스에 대한 의존성을 처음부터 추상화 레이어로 감싸놓지 않으면, 나중에 교체할 때 이렇게 고생한다. ShopifyService 인터페이스를 만들어두고 구현체를 바꿀 수 있게 설계했어야 했는데, 이미 늦었다.
사주 앱: 여성 UX와 기술 부채의 균형
문제: 사주 기반 소개팅 앱 “연분”의 UI가 “촌스럽다”는 피드백. 특히 여성 사용자들이 이탈할 가능성이 높았다.
시도: design-taste-frontend 스킬 원칙을 적용해 폴리싱을 시도했다. DESIGN_VARIANCE 8(비대칭 레이아웃), MOTION_INTENSITY 6(스프링 애니메이션) 설정으로 개선했지만, 여전히 만족스럽지 않았다. Pretendard 폰트를 추가하고, 색상 테마를 여성향으로 완전히 변경했다(#FCF8F5 따뜻한 크림 배경, #D4845A 테라코타 액센트).
해결: 가장 효과적이었던 건 아이콘 교체였다. 기존의 기본 Material 아이콘을 Phosphor 아이콘으로 전면 교체하면서 앱의 전체적인 느낌이 달라졌다. eye 아이콘을 arrowsLeftRight로, sliders를 faders로 바꾸는 작은 변화가 사용성에 큰 차이를 만들었다.
배운 점: UI 개선은 단순히 “이쁘게” 만드는 게 아니라 의미 전달의 정확성이 중요하다. 아이콘 하나가 사용자의 직관적 이해를 방해할 수 있다. 그리고 flutter analyze로 린트 경고를 꼼꼼히 잡아내는 게 성능 최적화에 실질적으로 도움이 된다는 것도 알게 됐다(prefer_const_constructors).
소명처리시스템: 데이터 중복과 마이그레이션 관리
문제: 소명처리 대상자 리스트에 중복된 아이디가 2개씩 보인다. HR 동기화가 여러 번 실행되면서 같은 테넌트 내에서 3~4회 중복 생성된 것이었다.
시도: DB를 직접 확인해보니 85건 중 고유한 건은 28건에 불과했다. DELETE 쿼리로 중복 제거를 시도했지만, 근본적인 원인인 HR 동기화 로직을 수정하지 않으면 또 발생할 문제였다.
해결: hr.py의 UserRole 상수 문제를 발견했다. ANALYST와 REVIEWER가 정의되지 않아 백엔드 시작 시 AttributeError가 발생했고, 이로 인해 모든 API가 502 에러를 반환했다. OPERATOR와 APPROVER로 수정하면서 해결했다. 또한 마이그레이션 044_add_audit_category.py를 생성해 스키마를 업데이트했다.
배운 점: 에러의 연쇄 반응을 주의해야 한다. 하나의 작은 상수 오류가 전체 시스템의 동작을 멈추게 할 수 있다. 그리고 데이터 중복 문제는 UI에서 발견되지만, 원인은 대개 백엔드 로직에 있다.
Pulse 시스템 개선: 외부 기억의 필요성
문제: Pulse 시스템이 “오케스트레이터가 모든 걸 기억한다”는 비현실적인 가정을 하고 있다. 장기 실행 작업에서 컨텍스트 유실이 빈번했다.
시도: 기존의 순차적 전문가 인터뷰 방식(35개 문항)을 라운드테이블 방식(13개 문항)으로 재설계했다. 여러 전문가가 동시에 관점을 제시하고 합의점을 찾는 방식으로 변경했다.
해결: pulse-status-schema.md를 도입해 오케스트레이터의 외부 기억으로 활용했다. 각 Pulse 단계에서 상태를 기록하고 다음 단계에서 이어받을 수 있게 했다. _workspace/pulse-status.md 파일이 실시간으로 업데이트되면서 컨텍스트 유실 문제가 크게 개선됐다.
배운 점: AI 에이전트 시스템도 상태 관리가 핵심이다. 인간이 작업 중간에 메모하는 것처럼, AI 시스템도 진행 상황을 외부에 저장하고 참조할 수 있어야 지속성이 보장된다.
skill-finder: 플러그인 생태계의 현실
문제: “오늘 뭐 좋은 스킬 있어?”라는 질문에 체계적으로 답변할 수 있는 시스템이 필요했다.
시도: GitHub 트렌딩, star 증가 속도, 기술 스택 일치도, 중복 여부를 기준으로 플러그인을 추천하는 skill-scout 스킬을 개발했다. claude-mcp-omnisearch, memclaw, code-simplifier 같은 유망 플러그인을 발견했다.
해결: 평가 프레임워크를 구축해 스킬의 효과를 측정했다. 스킬 사용 전후의 추천 품질을 비교했는데, 스킬을 사용했을 때 더 체계적이고 프로젝트 맞춤형 추천이 가능했다.
배운 점: Claude Code 플러그인 생태계는 생각보다 활발하다. 하지만 설치된 플러그인 관리가 중요하다는 걸 깨달았다. ~/.claude/plugins/installed_plugins.json을 주기적으로 정리하지 않으면 중복 추천이 발생한다.
오늘의 한줄
“여러 프로젝트를 병행할수록 각 코드베이스의 컨텍스트 스위칭 비용이 실제 구현 시간을 압도한다는 사실을 뼈저리게 느꼈고, 문서화와 상태 관리가 그 해결책임을 다시 한번 확인한 하루였다.”