2026-04-27 (월) 개발일지
오늘의 개발일지: 자동화 시스템과의 전쟁
Claude CLI 작업 로그 수집 자동화 개선
오늘 아침에 joyuno.github.io 블로그에 개발일지를 작성하려고 보니, 매일의 작업 로그를 수동으로 정리하는 게 너무 번거롭다는 생각이 들었어요. 특히 여러 프로젝트를 동시에 진행하다 보면 “오늘 뭐 했지?”부터 시작하게 되더라고요.
그래서 기존에 만들어둔 ~/.claude-daily-report 로그 수집 시스템을 개선하기로 했습니다. 문제는 로그가 너무 raw해서 LLM에 바로 던지기에는 컨텍스트가 부족하다는 점이었어요. summarize.py 스크립트를 수정하면서, 각 프로젝트별로 요청 내용을 어떻게 잘 요약할지 고민했어요.
결국 프로젝트명, 주요 요청, 편집한 파일, 실행한 명령어를 구조화해서 저장하는 방식으로 바꿨습니다. 이렇게 하면 나중에 회고글 쓸 때 “아, 그때 이 파일을 수정했구나” 하고 바로 기억이 나더라고요. 간단한 JSON 구조지만, 막상 만들려니 시간이 꽤 걸렸네요.
배운 점: 로그 수집은 가능한 실시간으로, 그리고 구조화된 형태로 해야 나중에 분석이 쉽다.
GCP 프로젝트 정지 대응 - 드롭쉬핑자동화
갑자기 드롭쉬핑자동화 프로젝트가 GCP에서 정지되었다는 알림을 받았을 때는 정말 당황했어요. “내가 뭘 잘못했지?”부터 시작해서 다양한 가능성을 생각해봤는데, GCP 측에서 보낸 메일에는 “문제를 해결하기 위해 어떤 조치를 취했는지 추가 정보를 보내주세요”라고만 되어 있더라고요.
여기서 중요한 건, 단순히 “해결했습니다”라고 말하는 게 아니라 구체적인 행동과 근거를 설명해야 한다는 점이었어요. 결국 답장에는:
- 리소스 사용량 모니터링을 강화했다는 점
- 의심스러운 트래픽 패턴이 있는지 확인했다는 점
- 필요시 rate limiting을 적용할 준비가 되어 있다는 점
을 명시해서 보냈어요. 클라우드 서비스 이용할 때는 예상치 못한 정지에 대비한 대응 매뉴얼을 미리 준비해둬야겠다는 생각이 들었어요.
배운 점: 클라우드 서비스 문제 대응은 구체적인 행동과 데이터로 말해야 한다.
소명처리시스템의 할당 로직 디버깅
오늘 가장 많은 시간을 쓴 부분이에요. 소명 자동화 시스템에서 assignees에 할당이 안 되는 문제가 발생했는데, 원래 설계대로라면 emp_key 값을 소명대상자로 지정해야 했거든요. 그런데 갑자기 작동을 안 하더라고요.
053_hr_employees_dedupe_external_id.py부터 ConditionBuilder.tsx, ScenarioAssigneeTab.tsx까지 여러 파일을 오가면서 디버깅을 했습니다. grep으로 rule_guid, getScenarios 등을 찾아보고, API 엔드포인트를 하나씩 추적했어요.
결국 문제는 두 가지였어요:
- 시나리오 캐시(
scenario_cache)가 갱신되지 않아서 옛날 데이터를 참조하고 있었고 -
과 34:443의 DB 구조 차이로 인해 조회 쿼리가 실패하고 있었어요
connectors.py의 1130~1170라인을 보면서 API 응답 구조를 확인하고, 프론트엔드의 connectors.ts도 함께 수정했어요. docker compose로 ESLint까지 돌려가면서 말이죠.
배운 점: 분산 시스템에서는 항상 데이터 소스의 일관성과 캐싱 타이밍을 의심해야 한다.
사주 앱의 결제 시스템과 UI 목업
사주 프로젝트에서는 결제 시스템을 어떻게 구성할지 고민했어요. 원래는 Claude 4.6 Sonnet을 사용하려다가 비용이 부담되어 .env에 API 키만 넣어두고 실제 결제는 나중에 연동하기로 했어요. 지금은 900원 결제했다 치고 바로 Claude를 호출하는 식으로 테스트 중이에요.
더 재미있었던 건 채팅 UI 목업을 만드는 부분이었어요. 카카오톡처럼 사람 목록이 있고, 클릭하면 대화창으로 들어가는 흐름을 만들고 싶었는데, 피그마에서 제공한 URL로 가보니 이상한 회색 스크린샷만 가득하더라고요.
imagemagick을 설치해서 /tmp/figma_thumbs에 썸네일을 생성하고, Python HTTP 서버로 띄워서 확인하는 삽질을 했습니다. 결국 피그마 export 설정 문제였는데, 이런 사소한 것에 시간을 쓰게 되다니…
배운 점: 디자인 협업 시 export 설정을 명확히 합의해야 한다.
퀀트 트레이딩 시스템의 자동화 고민
ficeptterminal과 bit-scalp 두 개의 트레이딩 프로젝트를 진행했어요. pulse7, pulse8로 버전을 올리면서 UI를 개선하고, 항상 “세계 제일의 퀀트 트레이더” 마인드셋으로 접근하라는 요구사항이 인상적이었어요.
bit-scalp에서는 특히 흥미로운 문제를 발견했어요. 로그를 분석해보니 수익 매도(take profit)를 4%에서 해야 하는데 자꾸 1%대에서 매도를 하고 있더라고요. tail -300으로 로그를 뒤지고, grep으로 TRAIL, Take profit, Stop loss 패턴을 찾아봤어요.
더 중요한 건, 이 분석 과정을 매일 자동으로 할 수 없을까 고민한 점이에요. 한국시간 00시마다 Claude가 스스로 로그를 분석하고 전략을 수정하는 자동화 시스템을 생각해봤어요. com.bitscalp.daily-optimize.plist를 만들고, orchestrator.py와 risk_manager.py를 수정하면서 말이죠.
배운 점: 트레이딩 시스템은 전략 자체보다 전략을 평가하고 개선하는 피드백 루프가 더 중요하다.
오늘의 한줄
여러 프로젝트를 넘나들며 각기 다른 문제를 해결하던 하루, 공통점은 모두 ‘자동화’와 ‘데이터 기반 결정’을 향해 가고 있다는 것이었다.