| 도입
매일 반복되는 업무인데, 사람이 직접 하기엔 시간이 아깝고, 그렇다고 안 하면 애매한 문제가 생기는 일이 있습니다. 저에게는 외부 동향 체크가 이런 형태의 일이라고 생각하는데요.
메일 보안, 피싱, EDR, MDM 등 여러 개의 RSS 피드를 매일 아침 훑어야 하는데 바쁜 날은 건너뛰고, 건너뛴 날에 한해서 중요한 위협 정보를 이틀 늦게 발견하는 일이 반복됐습니다.
KISA, CISA, BleepingComputer, The Hacker News 같은 피드를 브라우저 탭 10개씩 열어놓고 하나씩 확인하는 루틴이 필요한데, 투입해야 하는 시간은 30~40분이 넘어가니 불편함이 점점 커져갔고요. 자동화하면 좋겠다는 생각은 늘 있었지만, 자동화 시스템 자체를 관리하는데 또 공이 들면 본말이 전도된다고 생각했습니다.
그래서 처음부터 기획 의도가 명확했습니다.
한번 세팅하면 운영 공수가 거의 0에 가깝고, 그러면서도 매일 아침 실제 업무 판단에 쓸 수 있는 결과물이 나오는 시스템. 이 두 조건을 동시에 만족시키는 게 이 프로젝트의 핵심이었습니다. 그런데 이걸 혼자 기획하고 설계하고 구현하려니 엄두가 안 났습니다. 그때 클로드 코드를 작업 파트너로 사용해 봤는데 코드를 짜주는 것보다 기획과 설계 단계에서 업무를 함께 구조화해가는 과정이 훨씬 가치가 있었습니다.
다만, AI가 빠르게 결과를 내주는 만큼 각 단계의 산출물이 다음 단계로 제대로 연결되지 않으면 오히려 혼란이 커진다는 것도 알게 됐습니다. 그래서 기획, 설계, 태스크, 구현, 검증 각 단계를 명확히 분리하고 단계마다 문서화된 산출물(handoff)을 남기고, 그 산출물(handoff)이 다음 단계의 입력이 되는 구조를 만들기로 했습니다.
이걸 저는 편의상 시스테믹 엔지니어링이라고 부르기로 했습니다.
최근 AI 엔지니어링 분야에서 이야기되는 하네스 엔지니어링, 즉 모델의 능력이 아니라 모델을 둘러싼 구조를 설계해서 일관된 결과를 만드는 접근과 같은 방향입니다. 이 글에서 저는 보안 뉴스 자동 브리핑 시스템을 만들고 안정화 시켜가는 3주간의 과정을 따라가면서,이 체계가 어떻게 만들어지고 작동했는지를 이야기하려고 합니다.
| 기획
앞서 언급했던 것처럼 프로젝트의 시작은 아주 개인적인 불편함이었습니다. 보안 뉴스를 매일 확인해야 하는 건 당연한 업무인데, 문제는 이게 능동적인 작업이라는 것입니다. 피드를 열고, 훑고, 중요한 걸 골라내야 합니다. 바쁜 날은 자연스럽게 밀리고, 밀리면 정보 격차가 생깁니다. 실제로 한번은 금요일에 피드를 못 봐서, 주말 사이에 터진 글로벌 네트워크 공격 이슈를 다른 분이 먼저 알려주신 적이 있습니다. 그때 꽤 민망했고, 이건 시스템으로 풀어야겠다고 생각했습니다.
다만 이 작업을 시작할 때 제가 가진 불편함의 해결책을 AI에게 바로 "만들어줘"라고 던지지 않았습니다. 대신 문제를 같이 정의하는 대화부터 시작했습니다. "보안 담당자가 매일 아침 20개 피드를 확인하는데, 이 업무의 비효율이 뭐라고 생각해?" 질문을 던지면서 제가 가지고 있는 불편함의 출발점이 어디인지를 확인하고 문제를 구체화시키다 보면 결국 해결책이 점점 뚜렷해지는 것 같습니다.
구체화를 통해 AI와 제가 정의한 문제는 뉴스가 많은 게 문제가 아니라, 나한테 관련 있는 정보를 추려내는 데 시간이 걸리는 게 문제라는 것입니다. 이 리프레이밍 덕분에 설계 방향이 "뉴스 찾는 시간을 줄이자"에서 "우리와 관련 있는 걸 자동으로 걸러서 분야별로 보여주자"로 바뀌었습니다. 이후 키워드 필터링 체계를 설계할 때, 이 초기 리프레이밍이 출발점이 됐습니다. 성공 기준도 이 대화 안에서 구체화됐습니다. 처음에는 막연하게 "아침에 메일이 오면 좋겠다" 정도였는데 주고받으면서 기준이 선명해졌습니다.
- 매일 아침 8시, 메일함에 보안 브리핑이 도착해 있을 것
- 분야별로 정리되어 있어서 훑는 데 5분이면 충분할 것
- 영문 기사는 한국어로 번역되어 있을 것
- 운영 공수는 월 1회 미만일 것
이 네 가지가 이 프로젝트의 성공 기준이 됐습니다.
성공 기준이 선명해지니까 파이프라인 구조는 거의 자동으로 나왔습니다. 수집, 필터, 번역, 분석, 발송. 각 단계마다 "이게 자동으로 돌아가려면 뭐가 필요해?"를 반복하면서 업무 흐름을 시스템 구조로 전환해갔습니다. 최종적으로 이 대화들을 하나로 묶어 PRD (Product Requirement Document, 제품 요구사항 정의서)를 작성함으로써 기획을 1차로 마무리했고요.
| 설계
요구사항이 잡혔으니 아키텍처를 골라야 했습니다. 여기서 제가 가장 신경 쓴 건 운영 공수였는데요. 예전에는 비 개발자로써 가장 난감한 지점이 설계 부분이었는데 어떤 언어가 좋은지, 어떻게 개발해야 하는지를 모르니 너무 큰 병목이 빠르게 다가왔던 것 같습니다. 그러나 이번에는 파트너 AI를 적극적으로 활용해 보기로 했죠.
AI에게 제 요구사항 구체화를 위한 기술 아키텍처를 추천받았고 그중 Lambda, EC2, 로컬 cron 세 가지를 비교해달라고 했습니다. EC2는 서버를 24시간 켜둬야 하고 OS 패치 같은 관리가 필요합니다. 로컬 cron은 내 PC가 꺼져 있으면 안 돌아갑니다. Lambda는 실행할 때만 과금되고 EventBridge로 스케줄을 걸면 서버 관리 자체가 없습니다. 하루 1회 실행에 나머지 23시간 59분이 유휴인 워크로드에서는 Lambda가 압도적으로 유리했습니다. 가끔 일이 생겨서 제 PC가 해당 시간에 켜져 있지 않더라도 이벤트가 진행되어야 했기 때문에 위 선택은 생각보다 수월하게 끝났고요.
번역 API도 같은 방식으로 좁혀갔습니다. DeepL과 Google Translate를 보안 뉴스 번역 관점에서 비교한 결과, DeepL이 기술 문서의 한국어 번역 품질이 높은 대신 무료 티어 월 50만 글자 제한이 있고, Google Translate는 제한이 넓은 대신 보안 용어 번역이 부자연스러운 경우가 있었습니다. 하루 수집량이 많아야 수십 건이라 DeepL 무료 티어로 충분하겠다고 생각했습니다.
이 단계에서 AI를 쓴 방식이 가장 마음에 들었습니다. 혼자였으면 각 선택지를 검색하고 블로그 글 읽으면서 비교하는 데 며칠이 걸렸을 텐데 하루 만에 아키텍처 전체를 확정했습니다. 재료는 AI가 정리하고, 우리 업무 맥락에 맞는 최종 결정은 제가 내리는 Human in the loop 과정이 이 단계에서 만들어졌습니다.
| 체계 구축
기획과 설계를 앞에서 정리했는데, 여기서 바로 구현으로 넘어가지 않았습니다. 한 가지 구조적 문제를 먼저 풀어야 했습니다. AI 에이전트는 세션이 바뀌면 이전 대화를 전부 잊어버립니다. 실제로 겪은 일인데, 첫 세션에서 기술 스택까지 확정해놓고, 다음 날 새 세션에서 “어제 정한 구조에서 필터링 로직을 추가하자”라고 했더니 "어떤 구조를 말씀하시는 건가요?"라고 되물었습니다.
두 시간 동안 논의한 내용이 통째로 사라진 것입니다. 기획에서 나온 이야기가 설계에서 빠지고, 설계에서 정한 원칙이 구현에서 흐려지고, 구현한 코드를 검증 없이 밀어 넣으면 나중에 문제가 터집니다. 여러 세션에 걸치는 프로젝트는 이 문제를 풀지 않으면 일관성 있는 진행이 불가능합니다.
해결책은 의외로 익숙한 곳에서 나왔습니다. 야간 근무자가 주간 근무자에게 남기는 인수인계 노트(handoff). 업무에서 늘 해오던 것인데, AI 세션 간 맥락 전달에도 같은 원리가 통하겠다는 생각이 들었습니다. 게다가 이미 AI를 통해 협업 개발을 진행하고 있는 여러 팀에서도 잘 활용하고 있는 방법이더라고요. 여기에 AI 에이전트가 매 세션 시작 시 읽을 수 있는 규칙 파일을 추가해서, 두 종류의 파일을 만들었습니다.
첫 번째는 프로젝트 규칙 파일입니다.
처음에는 "Python 3.11, AWS Lambda, feedparser 사용"이라는 세 줄짜리 메모였습니다.
두 번째는 인계 문서입니다.
"완료된 작업, 진행 중인 작업, 다음에 해야 할 작업, 주의 사항, 관련 파일 목록" 다섯 섹션으로 구성했습니다.
위 두 개 문서는 필요 시 세션이 끝날 때마다 갱신하는 걸로 워크플로우를 구성했고요. 이 두 파일의 역할은 다릅니다. 규칙 파일은 어떤 세션에서든 동일한 원칙이 적용되게 하는 가드레일이고, 인계 문서는 단계 간 맥락이 끊기지 않게 하는 연결 장치입니다. 규칙 파일은 프로젝트가 진행되면서 성장합니다. 이 성장 과정은 뒤에서 다시 이야기하겠습니다.
| 태스크
체계를 잡았으니 본격적으로 만들 차례인데, AI 에이전트한테 "다 만들어줘"라고 하면 정말로 다 만들려다가 중간에 맥락이 끊기거나 품질이 떨어집니다. 인간이 그러하듯 에이전트가 한 번에 사고할 수 있는 크기가 하나의 컨텍스트 윈도우에 한정되기 때문인데요. 그래서 Phase를 나누기로 했습니다.
Phase 1은 수집 파이프라인 안정화였습니다. "한번 세팅하면 손 안 대도 돌아가야 한다"는 기획 의도가 있었기 때문에 기사 수집 기능을 추가하면서 빠르게 예상되는 실패 시나리오를 정리했습니다. 서버 문제로 중단되는 경우, 중복 기사 수집의 경우, 무한 데이터 적재 시의 리소스 관리 등의 예상되는 문제를 아래와 같이 조치를 취할 수 있었습니다. 외부 피드 서버가 느리거나 응답이 없을 때 Lambda 전체가 타임아웃 나는 문제에는 socket 레벨 15초 타임아웃과 개별 피드 격리를 적용했습니다. 같은 기사가 여러 피드에 동시에 올라오는 중복 문제에는 URL 해시 기반 DynamoDB 중복 체크를 설계했습니다. 여기에 데이터가 무한히 쌓이는 비용 문제까지 고려해서 TTL 90일 자동 만료를 넣었습니다. 실제로 나중에 이 설계가 운영 안정성에 상당히 기여했습니다.
Phase 2에서는 트렌드 분석을 추가했습니다. 13개 분야 키워드 맵을 설계하는 과정이 개인적으로 흥미로웠는데 제가 이메일 보안, 클라우드 보안, 취약점/패치 같은 대분류를 잡으면 AI가 하위 키워드를 확장하고, 분야가 겹치거나 유사한 기사를 가져오는 걸 필터링하는 방식에 대해 AI와 파트너처럼 논의하며 최종적으로 제가 원하는 결과물로 이끌어내는 부분이었습니다. 이 부분을 진행하며 시행착오를 가장 많이 겪었는데 제가 원하는 걸 정확하게 AI가 대답하지 못한다면 애초에 제가 질문이나 요구사항을 잘못 말했다는걸 새삼스럽게 깨달았던 순간이기도 합니다.
Phase 3에서는 GPT-4o-mini를 파이프라인 안에 넣어 동향 요약과 산업 영향 분석을 자동화했습니다. 이 과정에서는 과도한 확대 해석을 방지하기 위해 모델 temperature를 0.3으로 낮춰 일관성을 잡고 응답 포맷을 JSON으로 고정해 파싱 실패를 방지하고, API가 죽어도 기존 템플릿으로 대체되는 fallback을 넣었습니다. 각 Phase는 충분히 작은 세션과 그 하위의 태스크 단위로 분해되고, 세션이 끝날 때마다 인계 문서(handoff)를 갱신했습니다. 단순히 "뭘 했다"만 적는 게 아니라, "이 Phase에서 내린 판단의 근거"와 "다음 Phase에서 결정해야 할미결 사항"도 함께 기록하면서요. 위 작업을 통해 하나의 컨텍스트 안에서 AI가 일할 수 있는 환경을 더 쾌적하게 만들어주고 작업의 품질과 일관성을 동시에 확보해 보려는 시도를 해보게 된 것이라고 할 수 있죠.
| 구현과 검증
코드 작성은 AI 에이전트가 리드합니다. 그런데 한 가지 구조적 결함이 있습니다. 코드를 쓰는 AI와 검증하는 AI가 같은 맥락에서 돌아가면, 자기가 쓴 코드를 자기가 리뷰하는 구조가 되면서 맹점이 생길 수밖에 없습니다. AI는 생각보다 자기가 편한 대로 동작한다는 사례들도 여럿 보게 되어 이 부분도 함께 고민할 수밖에 없었습니다. 그래서 코드 리뷰어와 보안 리뷰어를 별도 역할로 분리하고 각각 다른 기준을 부여했습니다.
코드 리뷰어는 품질과 유지 보수성에 집중합니다. 불필요한 복잡도, 에러 핸들링 누락, 네이밍 일관성 같은 것들. 보안 리뷰어는 OWASP Top 10 기준으로 인젝션 가능성, 입력값 검증, 시크릿 노출 여부를 전담합니다. 실제 업무에서 개발자와 보안 담당자가 다른 시선으로 코드를 보는 것과 같은 구조입니다. 이 체계가 실제로 작동한 사례가 있습니다. RSS 피드의 제목을 이메일 본문에 그대로 삽입하는 코드가 있었습니다. 피드 제목이 보통은 일반 텍스트지만, 공격자가 악의적인 HTML 태그를 넣어두면 수신자의 이메일 클라이언트에서 스크립트가 실행될 수 있습니다.
보안 리뷰어가 이걸 잡아서 html.escape() 처리를 추가했습니다. 외부 피드 호출에 timeout이 빠져 있는 것도 리뷰에서 잡혔습니다. Phase 1에서 "뭐가 망할 수 있는가"를 논의하면서 설계했던 안전장치입니다. 설계했는데 왜 구현에서 빠지느냐고 물을 수 있는데, AI 에이전트는 코드를 빠르게 생성하는 만큼 설계 문서의 요구사항을 하나씩 대조하며 작성하지는 않습니다.
사람도 마찬가지입니다. 설계서에 적어뒀다고 구현에서 자동으로 반영되는 건 아닙니다. 그래서 구현과 검증을 분리해야 하고, 단계별로 문서화해둔 설계 내용이 리뷰어의 체크리스트 역할을 하면서 여기서 효과를 발휘했습니다. 한편, 이 리뷰 체계 때문에 예상치 못한 보안 사고도 겪었습니다. 보안 리뷰어가 "환경 변수 관리가 안전한지 확인하겠다"면서 .env 파일을 직접 읽은 것입니다. 그 안에 있던 API 키가 AI 세션 로그에 그대로 기록됐습니다. AI 도구 자체가 보안 경계 안쪽에 있다고 무조건 신뢰하면 안 된다는 걸 이때 배웠습니다. 이 사건이 규칙 파일의 전환점이었습니다.
시크릿 보호 룰 6개가 한꺼번에 추가됐습니다. ".env 파일은 절대 읽지 않는다", "AWS CLI 응답은 --query로 필요한 필드만 추출한다", "시크릿 값이 터미널에 노출되면 즉시 키 로테이션을 권고한다". 세 줄짜리 메모로 시작했던 규칙 파일이 기술 스택, 보안 가드레일, 코딩 컨벤션, 배포 규칙까지 포괄하는 프로젝트의 규범으로 성장한 것입니다. 이처럼 체계는 미리 완성되는 게 아니라 프로젝트를 진행하면서 실패에서 배운 것을 구조에 반영하고 그 구조가 다음 실수를 방지하는 순환이 만들어질 때 비로소 체계가 됩니다.
| 운영
최종 산출물은 4개의 자동 파이프라인입니다. Daily 브리핑은 매일 아침 8시에 도착합니다. 20개 넘는 보안 피드에서 기사를 수집하고, 13개 분야 키워드 필터링과 해시 기반 중복 제거를 거친 뒤, 영문 기사는 DeepL로 번역해서 분야별로 정리된 이메일을 보냅니다. 주간 트렌드는 매주 월요일, 월간 트렌드는 매월 25일에 발송되는데, GPT-4o-mini가 분야별 동향 분석과 산업 영향까지 붙여줍니다. 전부 AWS Lambda와 EventBridge로 돌아가고, 서버 관리는 없습니다.
지난 한 달간 제가 이 시스템에 손댄 횟수는 0회입니다. 매일 아침 메일함을 열면 브리핑이 와 있고, 월요일에는 주간 트렌드가 추가로 옵니다. 기획 단계에서 세웠던 "운영 공수 월 1회 미만" 기준을 충족한 셈이죠.
| 회고
이 프로젝트를 돌아보면, 가장 큰 수확은 최종적으로 만들어낸 RSS 시스템보다는 만드는 과정에서 잡은 시스테믹 엔지니어링의 체계인 것 같습니다.
요소 |
역할 |
| 규칙 파일 | AI의 행동 경계를 잡는 가드레일 |
| 인계 문서 | 단계 간 매락을 연결하는 장치 |
| Phase 관리 | 범위를 사전에 합의하는 단위 |
| 분리 리뷰 | 구현과 검증의 맹점을 줄이는 구조 |
| 레포 | 체케의 저장소이자 진화의 기록 |
이 중 어느 것도 처음부터 설계된 것이 아닙니다. 프로젝트를 진행하면서 필요에 의해 하나씩 추가됐고, 보안 사고처럼 실패가 체계를 성장시킨 경우도 있었습니다. AI가 가장 도움이 됐던 건 코드를 짤 때가 아니라 업무를 구조화할 때였습니다. 막연한 불편함을 성공 기준 네 가지로 정리하거나 아키텍처의 트레이드오프를 한 세션 안에 비교하는 과정에서 AI는 제가 혼자 할 때는 시간이 훨씬 더 많이 걸렸을 구조화 작업을 몇 시간으로 줄여줬습니다.
비슷한 체계를 적용해 보고 싶다면, 시작점이 될 만한 것들을 공유합니다.
프로젝트 규칙 파일을 만들어 보시길 권합니다. 기술 스택 세 줄이면 충분합니다. 프로젝트를 진행하면서 규칙은 알아서 늘어납니다. 중요한 건 AI가 매 세션마다 이 파일을 먼저 읽게 하는 것입니다.
세션이 끝날 때마다 인계 문서(handoff)를 남겨 보시길 권합니다. 완료/진행 중/다음 작업 세 섹션이면 됩니다. 여기에 "왜 이렇게 결정했는가"를 한 줄만 추가하면 다음 세션에서 맥락 없이 판단을 뒤집는 일이 사라집니다.
구현과 검증을 분리해 보시길 권합니다. 같은 AI라도 역할을 나누면 시선이 달라집니다. 코드 품질과 보안을 각각 다른 기준으로 검토하게 하는 것만으로도 맹점이 상당히 줄어듭니다.
※ 작성 참고: 본 아티클은 실제 사내 프로젝트 경험을 기반으로 작성되었습니다. 코드와 설정 정보는 보안상 생략했으며, 엔지니어링 프로세스와 의사결정 과정에 초점을 맞추었습니다.
