이 글에서 다룰 내용은 내가 만들고 있는 데이터독 신기능 소개 문서 생성 자동화 파이프라인 구축기다.
파이프라인 얘기를 하기 전에 배경부터 간단히 설명하면, 데이터독은 아래 이미지처럼 신기능이 나올 때마다 콘솔 페이지에 릴리스 노트를 올린다.
그리고 우리 팀 업무 중 하나가, 이 영어 노트를 한국어로 읽기 편하게, 그리고 회사 템플릿에 맞게 다시 작성해서 고객사에 배포하는 것이다.
기존에는 이걸 전부 수작업으로 했다. 이미지 복사해서 ppt에 붙이고, 본문 긁어서 템플릿에 맞게 3~400자 한국어로 번역하고, 하이퍼링크 하나씩 따서 추가하고... 그런 식으로 말이다.
릴리스 노트가 별로 없는 달엔 금방 끝나는데, 많이 나오는 달엔 30~40개씩 쏟아진다.
그런 달엔 이 작업에만 2~3시간은 쓴다. 시간도 시간이지만 작업 자체가 꽤나 귀찮다.
그래서 이걸 자동화할 방법을 찾다가, 가능할 것 같아서 시도해봤다.
데이터독은 릴리스 노트 내용을 RSS로도 가져갈 수 있게끔 XML 형식으로 웹페이지에서 제공해준다.
각 릴리스 노트는 XML 에서 <item> 블럭으로 구분된다.
내가 생각한 파이프라인 플로우는
1. 하루에 한번 람다를 트리거해서 정보를 긁어오고
2. 기존에 작업한 이력과 비교해서 새로운 아이템이 있다면
3. 해당 아이템을 번역하고 (여기서 베드락을 통해 claude sonnet을 호출한다.)
4. 번역한 텍스트를 미리 만들어놓은 html 템플렛에 끼워넣는다.
5. 이 html을 pdf로 변환해서 s3에 아이템별 html, pdf를 저장한다.
대강 이 워크플로우로 작동한다.
아래는 도식화다. mermaid 언어로 작성했다.
일단 로컬에서 클로드와 함께 poc를 해봤다.
자동화 파이프라인은 나중에 만들고, 일단 베드락 번역 텍스트를 템플릿 html에 집어넣어서 pdf로 뽑을 수 있는지를 테스트했다.
일단 아래 이미지는 사람이 직접 수작업으로 만든 장표고,
아래 이미지가 poc로 프로그래밍을 통해 생성한 장표다.
... 이대로 그대로 사용해도 전혀 문제가 없을 퀄리티다. 그래서 바로 자동화에 착수했다.
제목, 태그 추출, 본문 번역 전부 베드락 클로드로 번역했고, 만들어놓은 템플릿에 텍스트를 넣은 결과다.
물론 템플릿 html도 클로드가 만들어줬다. 당연히 클로드와 여러번 대화하면서 만든 결과다. 한번에 이렇게 만들어주진 않는다.
파이프라인 구현 자체는 그리 오래 걸리지 않았는데, 신나서 하다보니까 테라폼과 깃허브 액션 사용해서 인프라 관리 & 소스코드 변경되면 이미지 자동 빌드해서 람다 자동 업데이트하는 cicd를 구현하고 싶더라.
그래서 이 작업 하느라 더 많은 시간을 쓴 것 같다.
이 과정에서 처음에 s3 버킷에 처리된 아이템들 리스트를 저장할 json 파일을 담아줘야 했다.
왜냐면 미리 처리된 아이템 리스트를 버킷에 담아줘야, 람다가 실행될때 몇년전부터 작성된 과거의 릴리스노트를 처리하지 않기 때문이다.
이 작업을 안하면 1900개 가량의 아이템을 처리하려하고, 람다랑 클로드가 1900번 호출됐을 것이다.
별도 DB로 빼진 않았다. 저장할 정보가 매우 단순하고 쿼리도 필요하지 않기 때문에 상태를 저장할 파일 하나면 충분하다고 생각했다.
근데 이 json을 내가 직접 넣어줘도 됐는데... 테라폼으로 구성하는 만큼, 그냥 이것도 테라폼으로 init 하고싶더라.
그래서 aws_s3_object resource로 명시해서 로컬 json 파일을 이 방식으로 버킷에 업로드했다.
이 부분이 생각지도 못한 에러를 불러올줄은 몰랐다.
파이프라인 돌리면서 기능 계속 개발하고, cicd로 배포하고 계속 작업했다.
이 과정에서 데이터독 측에서 릴리스 노트가 업데이트되는 일은 없었다. 신규 기능 업데이트가 없었다.
그러나 매일 로그를 확인하는데, 베드락이 계속 호출되더라
분명 처리된 guid 리스트가 업데이트 됐을텐데, 왜 계속 이계 실행되는지 감이 안왔다.
사소한 코드단의 상태 처리 로직 이슈겠거니 생각했고 별 신경 안쓰고 있었다.
근데 클로드 코드한테, 상태 처리 로직 확인해보라 했는데 별 이슈가 없다 하더라. 정상적으로 작성된 코드라고 하더라
그래서 이번 한번만 발생한건가? cicd가 꼬인건가? 뭐가 문제지 하고 넘어갔다.
다음날에도 클코한테 처리 로그 확인해보라 했더니, 또 베드락을 호출한 기록이 확인됐다.
아니 릴리스 노트가 업데이트가 되지 않았고 guid 리스트도 최신일텐데 왜 계속 실행되지? 싶어서 다시 분석시켰더니..
상상도 못했던 부분이 원인이었다.
아래는 클코가 분석한 내용이다.
이 processed_guids.json 파일은 DB역할을 하므로 매일 람다가 실행됨에 따라서 상태가 계속 변경되는 파일이었다.
선언형으로 관리되기에 적합한 리소스가 아니었다.
매일 람다가 실행해서 처리한 아이템 리스트 업데이트해봤자, 내가 코드 수정해서 커밋해버리면 테라폼이 apply되어서 이전 버전 파일로 업데이트 되어버렸던 것이다. 그러면 다음날 실행된 람다는 또 새로운 아이템인줄 알고 번역하려고 베드락을 호출했던거고...
이 문제는 아래처럼 코드를 삭제함으로써 간단히 해결했다.
IaC로 관리하기에 적합한 리소스와 그렇지 않은 리소스를 구분하는 것이 중요함을 배웠다.
인프라의 '형상'을 정의하는 리소스(vpc, iam 등)는 테라폼에 적합하지만, 런타임에서 상태가 계속 변하는 데이터 (이 경우 처리 이력 json)는 테라폼의 선언형 모델과 충돌한다.
이런 리소스는 init 할때만 스크립트로 처리하든, 수작업으로 처리하고 테라폼 state에서는 빼는 것이 맞다.
이번 문제를 처리하면서 놀라웠던 점이 하나 있다.
클로드가 데이터독을 사용하지 않았다는 것이다.
나는 데이터독을 다루는 엔지니어고, 이 워크플로우의 로그도 데이터독으로 전송하도록 설정해 놨다. 데이터독 MCP도 연결해 둔 상태였다.
그런데 클로드는 자동으로 쌓이는 CloudWatch 로그를 조회하더라.
데이터독 MCP를 연결해 놨는데 왜 안 쓰는 건지 살짝 짜증이 났었다.
그런데 조사 과정을 보니 CloudWatch만 보는 게 아니라 S3 버전 이력 등 다양한 정보를 수집하고 있었다. 자기가 원래 알고 있던 AWS CLI를 활용해서 직접 정보를 끌어온 것이다.
mcp도 결국 컨텍스트를 잡아먹는 도구인데, 굳이 데이터독 mcp가 필요했었나 싶기도 했다.
결국 S3 버전 이력이 문제 원인 파악에 결정적인 도움을 줬다. 내가 로깅한 로그만 봤다면 원인을 찾기 어려웠을 것이다.
이번 경험에서 인상적이었던 건, 클로드가 데이터독 MCP를 무시하고 CloudWatch 로그와 S3 버전 이력으로 원인을 찾아냈다는 점이다. 나는 데이터독 엔지니어인데, 정작 문제 해결에 데이터독은 필요하지 않았다.
음... 앞으로 ai가 더 똑똑해질텐데....
앞으로의 모니터링, 옵저버빌리티의 미래는 최대한 많은 데이터를 ai가 접근할 수 있도록 쌓아주기만 하면 되지 않을까 싶다.
데이터독에 로그 관련된 여러 기능이 있는데, 이게 ai 에이전트에게 그렇게 필요한 도구일까도 싶고..
에이전트 입장에서는 잘 만들어진 대시보드나 쿼리 인터페이스보다, 원시 데이터에 직접 접근할 수 있는 경로가 더 중요할 것으로 생각된다.
그런 점에서 값싸게 데이터를 모아주는 스토리지 환경이 기존 모니터링 환경을 대체하지 않을까도 싶고
그리고 최대한 많은 데이터를 쌓을 수 있는 환경을 만드는 능력이 중요할 것 같고.. (최대한 많은 메트릭 수집, 계측 Instrumentation 등..)
아무리 쓸모없어보이는 데이터라도 일단 쌓고봐야 할 것 같고..
솔직히 s3 버전 이력 설정이 내 프로젝트에 도움이 되리라고는 생각도 못했다.
이 워크플로우는 아직 개발중에 있다.
실제 100% 정확도로 돌아가기 위해서는 앞으로도 많은 수정 작업이 필요하다.
내가 필요한 기능들을 만들면서 이것 저것 많이 배우고 많은 생각을 하는것 같다 요즘
'AI 이것저것' 카테고리의 다른 글
| [번역] 검증 루프 닫기: 에이전트로 소프트웨어를 만들기 위한 관측가능성 기반 하네스 (0) | 2026.06.05 |
|---|