2026-05-18 (월) 개발일지
오늘은 개인 블로그 개발일지 자동화 파이프라인을 멀티 피씨 환경에서 동기화하기 위해 구조를 다시 설계하는 하루였다. 로컬 세션 기반 컨텍스트 공유의 한계를 마주쳤고, 이를 AI와 함께 풀면서 “막연한 문제”를 “실행 가능한 명령어 모음”으로 변환하는 프롬프팅 기법을 체험했다.
문제를 “상태”로 재정의하기
처음에는 요청이 산만했다. 한쪽 피씨(맥북)에서만 개발일지가 생성되고, 다른 피씨(윈도우)에서는 그 컨텍스트가 공유되지 않는다는 불만이었다. 막연하게 “랭퓨즈 연동을 양쪽에 하면 되지 않을까?” 정도.
“두 피씨에서 모두 개발일지를 자동 생성하려면 어떻게 해야 할까?”
이 질문만으로는 AI도 일반론에 머물 수밖에 없다. 그래서 현재 상태를 데이터로 변환해서 보여주기로 했다.
잘 통한 점: 요청을 구체적인 수치와 조건으로 재구성했다.
- 기존 세션 데이터에서 평균 생성 빈도와 토큰 사용량을 계산
- “5/13, 5/14 데이터는 이상치라 제외”라는 필터 조건 명시
- “3 × IQR 이하면 블로그에 미반영”이라는 통계적 임계값 제시
이렇게 하자 AI 응답이 “일단 calc_activity_stats.py 를 만들어서 이 통계를 뽑아야 한다” 는 구체적인 첫 스텝을 제시했다. 문제 정의가 정확하면 해법도 순차적이 된다는 걸 다시 확인했다.
안 통한 점: 처음 요청에 “랭퓨즈 양쪽 연결” 같은 기술 용어가 섞여 있었는데, AI는 그 의도를 정확히 파악하지 못했다. 기술명이 아니라 “두 환경에서 같은 컨텍스트를 공유하고 싶다” 는 비즈니스 요구를 먼저 말했으면 더 빨랐을 것 같다.
플랫폼 차이를 “설정 파일”로 추상화
맥북과 윈도우라는 서로 다른 환경에서 같은 파이프라인을 돌려야 한다. 처음엔 “각 OS별로 따로 스크립트를 짜야 하나?” 싶었는데, AI와 함께 config.json 을 중심으로 한 플랫폼 독립적 구조를 설계했다.
핵심 아이디어:
- 경로, 명령어, 환경 변수 →
config.json에 정의 main.py는 OS를 감지해서 config를 선택- 윈도우용 명령어 모음은
WINDOWS_SETUP.md로 분리
“OS마다 다른 부분을 설정으로 외부화하면, 코드는 한 벌만 유지해도 되지 않을까?”
잘 통한 점: 이 아이디어를 AI에게 제시했을 때, 즉시 config.json 의 스키마 예시와 main.py 에서 읽는 방식까지 제안했다. 즉, 설계 방향을 먼저 제시하면 AI는 그에 맞춰 코드를 조각낸다.
안 통한 점: 처음엔 “윈도우에서 실행할 명령어들을 마크다운으로 정리해줘”라고 했는데, 너무 추상적이어서 AI가 일반적인 파이썬 셋업 명령을 뱉었다. 그 다음 요청에서 “우리 프로젝트의 calc_log_iqr.py, calc_activity_stats.py 를 실행하는 순서를 윈도우 명령어로 줘” 라고 구체적으로 물었더니 정확한 문서가 나왔다. 맥락 없이 “마크다운 만들어줘”는 약하고, “이 파일들을 이 순서로 실행하되, 윈도우 환경에서” 라고 제약을 넣으면 강하다.
통계 필터링 로직을 AI와 함께 검증
calc_log_iqr.py 를 작성할 때, 이상치 제거 임계값(3 × IQR)을 정확히 구현해야 했다. 수식은 알지만, 실제 데이터에 적용했을 때 “너무 많이 필터링되지 않을까?” 하는 의심이 들었다.
접근 방식:
- AI에게 IQR 계산 로직을 코드로 제시받음
- 샘플 데이터(5/13, 5/14 포함)를 직접 입력해서 “이 데이터로 돌려보면 뭐가 제외되나?” 물음
- 결과를 보고 “너무 공격적이면 2 × IQR로 조정해도 될까?” 협상
잘 통한 점: AI가 제시한 로직을 “다음 입력에서 이 코드 실행하고 결과 보여줄게” 라고 하니, 그 다음 대화에서 “아, 그럼 이렇게 수정하면 어때?” 하는 식으로 반복 개선이 가능했다. 코드를 받고 바로 실행해본 후 피드백을 주는 루프를 짧게 유지하는 게 핵심이었다.
안 통한 점: 통계 개념을 AI에게 “IQR이 뭐지?” 하고 물으면 교과서 설명이 나온다. 하지만 “우리 데이터셋에서 이상치가 몇 개인지 예상하고, 그 수가 합리적인지” 판단은 내가 해야 한다. AI는 논리적 일관성은 보장하지만, 도메인 의사결정(임계값 선택)까지는 담당할 수 없다. 그래서 “이 임계값으로 몇 개 제외되나?” 물어본 후, 내가 “합리적이다/너무 심하다” 판단하는 식으로 분업했다.
윈도우 환경 문서화 — “일반론” vs “우리 것”
“윈도우에서 셋업하는 방법을 마크다운으로 만들어줘”라는 요청은 처음엔 너무 넓었다. AI는 일반적인 파이썬 개발 환경 셋업을 썼고, 그건 우리 프로젝트와 맞지 않았다.
재요청: “우리 프로젝트는 config.json 을 읽고, 그 다음 calc_activity_stats.py → calc_log_iqr.py → main.py 순서로 실행해야 한다. 윈도우에서 이 순서를 따르는 명령어와 주의사항을 마크다운으로 정리해줘.”
| 요청 | 결과 | 이유 |
|---|---|---|
| “마크다운 만들어줘” | 일반론 (쓸모 없음) | 맥락 부족 |
| “우리 파일들을 이 순서로 실행하되 윈도우 명령어로” | 정확한 문서 | 구체적 제약 + 파일명 명시 |
잘 통한 점: “일반적인 X”가 아니라 “우리 프로젝트의 X”라고 명시하면 AI 응답이 즉시 현실적이 된다. 이건 프롬프팅의 기본이지만, 오늘 또 한 번 확인했다.
배운 점: 문서 요청할 때 마크다운 구조까지 지정하면 더 좋다. 예: “다음 섹션을 포함해줘: 전제조건, 순서, 각 단계별 명령어, 트러블슈팅” 하면 AI도 그 틀 안에서 정확하게 채운다.
오늘의 한줄
막연한 기술 요청을 “데이터 + 구체적 파일명 + 순서”로 재정의하는 순간, AI 응답이 일반론에서 실행 계획으로 변한다.