2026-05-19 (화) 개발일지
오늘은 네 가지 프로젝트를 병렬로 굴리며, AI와의 협업 패턴을 실험한 하루였다.
보안 이슈 정리, 데이터 엔지니어링 조사, 동기화 인프라 구축, 게임 기획까지 — 각각의 작업마다 AI에게 접근하는 방식을 다르게 가져갔다. 가장 큰 교훈은 프롬프트의 구체성이 결과 품질을 결정한다는 점, 그리고 인간의 판단이 필요한 경계가 생각보다 명확하다는 점이다.
보안 이슈 정리와 이미지 버그 분석: 명확한 지시 vs 원인 추론
잘 통한 접근 — 키 노출 이력 정리
깃 히스토리에서 민감 정보를 완전히 제거해야 하는 작업에서는 명령형 프롬프트 + 단계 분할이 효과적이었다.
“마저 내가 말한 곳이랑 키노출된거 다 지워줘 깃에서 다신 볼수없게”
이 프롬프트는 두 가지 요소가 잘 작동했다:
- 범위 지칭 (
내가 말한 곳이랑) — 사전 대화 맥락 활용 - 최종 상태 명시 (
다신 볼수없게) — AI가 자체적으로git filter-branch나BFG같은 도구를 떠올리도록 유도
잘 통한 점: AI가 단순 삭제가 아닌 히스토리 재작성이 필요함을 스스로 파악했다. sed와 grep을 활용한 패턴 탐색도 빠르게 제안해줬다.
안 통한 점: “B로 진행해줘” 같은 축약형 명령은 이전 맥락이 불완전할 때 방향을 잃었다. 이후 “한번에 이전거 다생성하라”는 추가 요청을 보니, AI가 일괄 처리보다 단계별 접근을 선호한다는 점을 확인했다 — 이는 컨텍스트 윈도우 한계 때문일 가능성이 크다.
노하우: 민감 정보 제거는 AI의 제안을 100% 신뢰하지 말고, 반드시 git log -p로 결과를 수동 검증했다. AI는 “다 지웠다”고 말해도 실제로는 커밋 해시가 다른 브랜치에 남아있는 경우를 놓치기 쉽다.
잘 통하지 않은 접근 — 이미지 깨짐 원인 추론
블로그 이미지가 5일 중 3건 깨진 버그의 원인을 물었을 때는 정보가 불충분했다.
“현재 ai-tech 블로그 이미지가 깨져있는 버그 있는데 지난 5일중 3건이 꺠짐 원인 확인해줄래?”
AI가 내놓은 가설:
- CDN 캐시 만료 문제
- 파일 경로 대소문자 불일치
- S3 퍼미션 변경
안 통한 점: 실제 원인은 수집기 로직의 타이밍 이슈였을 가능성이 높은데, AI는 에러 로그나 HTTP status code 없이 일반적인 원인만 나열했다. 컨텍스트가 텍스트 설명뿐이라면 AI는 확률 높은 가설만 반복할 뿐이다.
배운 점: 버그 원인 분석을 요청할 때는 반드시 실제 로그 샘플이나 실패한 URL 목록을 함께 던져야 한다. AI에게 “왜?”라고 묻기 전에, 먼저 “무슨 일이 일어났는지”를 구조화해서 보여주는 습관이 필요하다.
otel_study 프로젝트: 구체적 수치와 역할 부여의 힘
MAU 80만을 제시한 데이터 조사
동백전 APM 도입 요건을 조사할 때는 수치를 프롬프트에 포함한 접근이 탁월했다.
“가입회원수 약 144만명 (목표 : 200만명) MAU : 80만 (Max 100~120만 트래픽 발생)”
AI는 이 수치를 바탕으로:
- 초당 요청 수(RPS) 추정
- 모바일 계측 오버헤드 계산
- OpenTelemetry exporter 튜닝 포인트 제안
잘 통한 점: 막연한 “APM 도입 검토”보다 구체적인 트래픽 프로필을 주니, AI가 Otel의 batch processor 설정이나 sampling rate 같은 실무적인 조언을 내놓았다. 숫자는 AI의 추론 정밀도를 높이는 가장 강력한 도구다.
iOS vs Android — 플랫폼 차이를 물었을 때
iOS의 OpenTelemetry 지원 범위를 질문한 건 전략적으로 좋은 선택이었다.
“ios 앱 기준으로 otel에서 아직 안드로이드 만큼 제공하지못하는것… 사용자 행동 로그 분석을 따로 구현하기 위해서 다른 오픈소스나 툴을 사용해서 살을 붙여 sdk형식으로 묶은걸 기존 ios나 안드로이드 앱 에 같이 빌드하는거 어때”
AI의 답변에서 인상 깊었던 점:
Swift의swift-distributed-tracing생태계 한계를 구체적으로 지적Sentry,Datadog같은 외부 SDK와의 통합 방안 제시- 직접 SDK를 래핑하는 아키텍처 제안까지 도출
안 통한 점: AI는 두 플랫폼의 차이를 과장하는 경향이 있다. 실제 iOS Otel 지원은 생각보다 빠르게 따라잡고 있는데, AI는 1~2년 전 정보를 기준으로 말하는 경우가 많았다. 날짜를 명시해서 “2024년 6월 기준”이라고 강제하지 않으면 부정확한 비교를 하게 된다.
노하우: 기술 조사에서 AI를 활용할 때는 역할을 구체적으로 부여하는 게 도움이 됐다. “너는 지금 동백전 APM 도입을 검토하는 시니어 엔지니어야. MAU 80만 환경에서 Otel 도입 시 고려사항을 5가지로 정리해줘” 같은 방식이 효과적이었다.
랭퓨즈 통합 동기화: 진단 도구로서의 AI 활용
네트워크 진단에서의 AI 활용
Windows 세션 데이터를 Mac으로 동기화하는 설정 중, SSH 연결 문제가 발생했다. 이때는 AI를 단계별 진단 도구로 사용했다.
“Continue Windows→Mac sync setup. Last action: started background network reachability check (Test-NetConnection …). Check the task output and continue diagnosis.”
잘 통한 점:
- AI에게 “지금까지 한 일”과 “마지막 상태” 를 정확히 전달
- AI가 제안한 진단 순서(
ping → port check → SSH verbose → firewall rule)가 실제 문제 해결 흐름과 일치 cron타이밍 이슈(10시 블로그 생성 전 pull)를 AI가 먼저 지적해줌
안 통한 점: AI는 내부 네트워크의 방화벽 정책이나 VPN 상태 같은 환경 정보를 모르기 때문에, “방화벽을 확인해보세요”라는 일반론에서 벗어나지 못했다. 결국 실제 문제는 Mac의 SSH 서비스 재시작이 필요했는데, AI는 이를 추측하지 못했다.
배운 점: 네트워크 진단에서 AI의 강점은 가능한 원인 목록을 빠르게 생성하는 데 있고, 약점은 환경 특화 문제(특정 라우터 설정, 사내 보안 정책)에 취약하다는 점이다. AI의 출력을 체크리스트로 삼고, 실제 진단은 직접 실행하는 분업이 가장 효율적이었다.
study_game 프로젝트: 창의적 기획에서 AI의 한계
게임 컨셉 논의 — AI는 좋은 브레인스토밍 파트너
검강화하기 플래시 게임을 Godot으로 재구현하는 기획에서, AI는 아이디어 확장에 유용했다.
“검색해서 자산 가져올수있는지 여부랑 푼 문제 갯수당 강화권 하나 지급하는식으로 하고 기존에 되파는 시스템이 있으니 화폐도 있어야하는식으로 전부다 수정하려하는데 어떻게생각해?”
AI가 제안한 시스템:
- 문제 풀이 → 강화권 획득
- 강화권으로 무기 업그레이드
- 강화 실패 시 파괴 → 되팔기 시스템으로 리스크 완화
잘 통한 점: AI가 기존 플래시 게임의 경제 시스템을 추론해서 화폐 도입의 필요성을 논리적으로 설명해줬다. 혼자 고민했다면 놓칠 수 있는 강화 실패율과 경제 밸런스 같은 포인트를 짚어줬다.
안 통한 점: 구체적인 게임 밸런싱(강화 성공 확률, 아이템 가격)은 AI가 전혀 도움이 안 됐다. “5%가 적당할 것 같다”는 말만 반복하고, 실제 유저 경험을 반영한 수치는 전혀 제시하지 못했다. 게임 디자인에서 재미와 밸런스는 AI가 아직 못 푸는 영역임을 확인했다.
노하우: 창의적 기획에서 AI는 “이런 것도 가능하지 않을까?” 하는 아이디어 리스트를 만드는 용도로 쓰고, 실제 디자인 결정은 사람이 직접 해야 한다. 특히 Godot 프로젝트에서 gh, curl, unzip으로 에셋을 다운로드받는 부분은 AI의 도움을 받아도 직접 검증이 필요했다.
YAML 규격 문제 — AI가 놓친 문법 오류
eta 키가 왜 안 되는가?
meta/questions만 허용된다는 에러는 AI에게 정확히 물어보기 좋은 질문이었다.
“@samples\learning\ 에 있는 yml 파일 넣으려고 했는데 알수 없는 최상위키 ‘eta’ meta/questions만 허용이래 왜 안되는거야? 규격이 안맞아?”
AI는 즉시 두 가지 가능성을 제시했다:
- 해당 YAML이 특정 프레임워크의 스키마를 따르고 있음
eta키가 상위 수준에 있어서 파싱 규칙에 위배됨
잘 통한 점: AI가 YAML 스키마 제약을 이해하고 있다는 점이 도움이 됐다. “questions 아래에 eta를 넣어보세요” 같은 구체적 수정 방안을 제시했다.
안 통한 점: 실제로는 eta가 사용자 정의 메타데이터였는데, AI가 스키마 규격만 강조하다 보니 왜 그런 규격이 생겼는지(도메인 특화 이유)까지 설명해주지는 못했다. 도메인 지식을 AI가 가지고 있지 않으면 원인보다 증상만 설명하게 된다.
배운 점: YAML/JSON 스키마 에러는 AI가 매우 강한 분야다. 하지만 “왜 이 규격이 존재하는가” 같은 메타 질문은 인간이 직접 문서를 읽어야 한다. AI는 문법 오류 해결사로는 탁월하지만, 설계 의도 해석은 아직 한계가 있다.