• 당시 이용 모델은 GPT-5.5입니다. 이용 에이전트는 Codex입니다.
• 프롬프트나 에이전트의 답변은 예시로 작성한 것이며, 원문이 아닙니다.
• 참고로 이 기사는 AI 생성물이 아닙니다.

LLM의 새로운 모델이 출시되면서, Vibe Coding의 퀄리티가 점점 높아지고 있네요.

개인적으로 Codex를 사용하여 웹 페이지 등을 만들어 보았는데, LLM 이전에는 필사적으로 만들었던 것들이 순식간에 완성된다고 느낍니다.

다만, 비용이나 운영 부하에 대해서는 구체적으로 지시하지 않으면 알아서 잘 처리해 주는 것은 아닌 것 같습니다.

장래에는 그 부분까지 해줄지도 모르지만, 당분간은 인간이 체크하는 것이 좋을 것 같다는 느낌을 받고 있습니다.

그래서 제가 개인적으로 개발하고 있는 환경에서 마주친 과잉 지출 아키텍처를 3가지 공유합니다.

Lambda로 ***를 구현해 주세요. ***는 언제든 바꿀 수 있도록 변수로 설정해 두세요.

변수는 SSM Parameter Store에 생성합니다. ***는 기밀 정보로서 Secrets Manager로 생성하는 것이 좋겠네요.

AWS의 베스트 프랙티스(Best Practice) 측면에서는 말씀하신 대로지만, Secrets Manager는 하나당 월 $0.4의 비용이 발생한다.

물론 Secrets Manager에는 액세스 제어(Access Control), 감사(Audit), 로테이션(Rotation) 등의 장점이 있다.

하지만 자신만 이용하는 소규모 계정에서, 로테이션도 하지 않는 고정값을 모두 Secrets Manager에 넣는 것은 비용 대비 효과가 낮은 경우도 있다.

GitHub 등의 SaaS 리포지토리가 있고 Terraform을 사용하고 있다고 하더라도, 로컬의 tfvars를 .gitignore 하거나, GitHub Actions나 Terraform Cloud의 시크릿 변수(Secret Variable)를 통해 전달하는 정도만으로도 충분한 케이스도 있을 것이다.

정신을 차려보니 시크릿이 10개 정도 생겨 있어서 조금 기분이 좋지 않았다.

WAF로 ***에 관한 PATH를 보호해 주세요.

각 PATH에 대해 규칙을 생성했습니다.

뭐, 그렇게 되는 것이 자연스럽기는 할 것이다. 확실히 필터 조건으로서 깔끔하게 관리되어 있다. 인간의 시인성도 좋다. 운용하기 쉽다.

하지만 WAF 규칙은 하나당 월 $1의 비용이 발생한다.

모두 동일한 조건, 동일한 액션으로 처리할 뿐이라면, 필터 조건마다 $1를 내는 것보다 OR로 연결한 하나의 규칙으로 충분할 것이다.

이것을 그 자리에서 깨닫지 못해 지출도 뼈아팠던 문제.

액세스 분석을 하고 싶어서 Evidence를 정적 사이트로 배포하고, 집계는 Athena로 실시하기로 했다.

서비스마다 계정을 나누고 있어서, 분석용 계정의 S3로 크로스 어카운트(Cross-account)로 수집해서…… 등등을 하다 보니 놓치고 말았다.

AWS Organizations 산하의 모든 계정의 액세스 로그를 일원적으로 수집해서

CloudFront의 액세스 로그가 활성화되어 있지 않네요
활성화했습니다
S3에 대한 조작 로그가 활성화되어 있지 않네요
...

가능한 범위 내에서 경위를 거슬러 올라가 보니, 위와 같았던 모양이다.

S3에 대한 조작 로그가 활성화되어 있지 않네요

S3에 대해 CloudTrail의 데이터 이벤트(Data Event)를 활성화했습니다

이것이 전혀 기억에 없다. GPT는 그렇게 해석한 것인가…….

애초에 원했던 것은 CloudFront의 액세스 로그였지, S3 오브젝트에 대한 조작 이력이 아니었다.

이것이 나중에,

Evidence를 사용하려고 합니다. 정적 사이트로 CloudFront + S3로 배포하겠습니다
데이터는 Athena로 일간 생성하고, CodeBuild로 생성, 배포하겠습니다

알겠습니다!

라는 흐름으로 Athena에 휘말려 버려서,

CloudTrail의 로그를 S3에 저장
↓
Athena가 S3 상의 로그를 읽음
...

라는 흐름으로, 일간 처리 때마다 S3 오브젝트가 늘어나 버렸다.

Athena가 무한히 자동 실행되고 있었던 것은 아니지만, Athena의 읽기에 의해 생성된 로그가 다음 회차의 분석 대상에 포함되는 구성이 되어 있었다.

다만, 비용은 정기적으로 확인하고 있었기에 큰 사고가 나기 전에 멈출 수 있었다.

안티 패턴 (Anti-pattern)을 파악하는 것도 중요하지만, 비용은 수시로 확인합시다.

지금까지의 문제는 "개인치고는 돈이 많이 든다"는 것이지, 비밀 정보를 분리하거나, WAF로 보호하거나, 로그를 일원 관리하는 등의 기본 방침은 일정 수준의 정확도로 구현되어 있습니다.

듣고 보니 그렇군요. 비용 조건을 전달하지 않았다면, 안전성이나 관리의 용이성을 우선시하는 것은 자연스러운 일입니다.

LLM의 출력을 무조건 믿지 않고, 무기로 잘 다룰 수 있게 되면 좋겠네요.

그리고 비용은 '정신 차려보니'가 아니라, 정기적으로 확인합시다!

• 이 기사의 내용은 개인의 견해이며, 소속된 조직의 의견을 대표하지 않습니다.