ebson

들어가며자격증 시험을 앞둔 마지막 한 주가 되면, 누구나 한 번은 같은 충동에 빠집니다. 처음부터 다시 보고 싶어집니다. 강의도 다시 듣고, 노트도 처음부터 정독하고 싶습니다. 그런데 막상 시작해 보면 시간이 턱없이 부족합니다. 세 시험을 같이 준비했다면 정리해 둔 서비스 노트만 해도 수십 개이고, 강의 자료까지 더하면 다시 정독한다는 계획은 현실적이지 않습니다. 막판에 전부를 다시 보려다 정작 약한 곳을 못 보고 시험장에 들어가는 일이 생깁니다.그래서 마지막 복습의 전략은 "전부"가 아니라 "약점"이어야 합니다. 이미 잘 아는 곳은 한 번 더 봐도 점수가 오르지 않습니다. 점수가 오를 여지는 자주 틀리던 함정과, 아직 덜 정리해서 머릿속에 흐릿하게 남아 있는 영역에 있습니다. 문제는 그 약점이 어디인지..

들어가며 — 강의 따로, 내 노트 따로 놀 때자격증 공부를 강의로 하면, 자료가 두 갈래로 흩어지기 쉽습니다. 한쪽에는 강의 슬라이드 PDF가 있습니다. 강사가 짜 둔 순서대로, 처음부터 끝까지 선형으로 흐르는 자료입니다. 다른 한쪽에는 내가 직접 쓴 정리 노트가 있습니다. 앞 글들에서 잡은 대로, 서비스별로 한 노트씩 두고 시험별 관점과 도메인 속성을 얹어 둔 노트들입니다. 문제는 이 둘이 자꾸 따로 논다는 데 있습니다. 강의를 듣다가 "이건 내 S3 노트에 적어 둬야지" 싶은 대목이 나와도, 슬라이드는 PDF 뷰어에 떠 있고 내 노트는 Obsidian에 떠 있어서, 둘을 오가며 베껴 적게 됩니다. 그러다 보면 강의의 어느 페이지가 내 노트의 어느 대목과 이어지는지가 금세 흐려집니다.강의는 입력이고 내..

들어가며 — 비중을 모르면 엉뚱한 데 시간을 씁니다자격증 공부를 시작할 때 가장 흔한 실수는 흥미가 가는 주제부터 파는 것입니다. VPC 라우팅이 재미있어서 며칠을 붙잡고, 정작 출제 비중이 큰 보안 설계는 시험 직전에야 훑습니다. 시험은 공부한 시간에 비례해 점수를 주지 않습니다. 출제 비중에 비례해 점수를 줍니다. 그래서 공부 순서를 정하는 가장 정직한 기준은 "내가 재미있어하는 것"이 아니라 "공식 가이드가 몇 퍼센트를 배정했는가"입니다.다행히 AWS는 각 시험의 도메인과 비중을 공식 시험 가이드에 그대로 적어 둡니다. 이 비중은 추측이나 학원 자료가 아니라 AWS가 공개한 1차 정보입니다. 그렇다면 남는 일은 이 비중을 공부 도구 안으로 끌고 들어오는 것입니다. 앞 글에서 한 서비스 노트에 시험별..

들어가며AWS 자격증을 두 개 이상 같이 준비하기로 마음먹은 순간, 정리 방식에서 한 번은 갈림길을 만납니다. Solutions Architect Associate(SAA-C03), Developer Associate(DVA-C02), CloudOps Engineer Associate(SOA-C03)를 같이 보기로 했다고 해 보겠습니다. 폴더 트리에 익숙한 개발자라면 손이 먼저 움직여서 SAA/, DVA/, CloudOps/ 폴더부터 만들기 쉽습니다. 그리고 각 폴더 안에 S3.md를 하나씩 둡니다. 깔끔해 보입니다. 시험별로 칸이 나뉘어 있으니, 어느 시험을 공부하든 그 폴더만 열면 될 것 같습니다.그런데 막상 이 구조로 한 달쯤 공부하고 나면 문제가 드러납니다. S3의 스토리지 클래스나 버킷 정책 같..

들어가며 — 개발자가 노트 앱에서 처음 헷갈리는 것코드를 다루는 사람은 폴더로 생각하는 습관이 몸에 배어 있습니다. 새 프로젝트를 시작하면 가장 먼저 디렉터리 구조부터 잡습니다. controller, service, repository로 나누고, 그 아래에 도메인별로 또 나눕니다. 무언가를 정리한다는 것은 곧 "어느 폴더에 넣을지 정하는 일"이고, 이 방식은 대체로 잘 작동합니다. 파일 하나는 한곳에 있어야 하고, 경로를 따라가면 반드시 찾을 수 있으니까요.그래서 Obsidian 같은 노트 앱을 처음 열면, 우리는 똑같이 합니다. 폴더부터 만듭니다. AWS 자격증을 준비한다면 자연스럽게 SAA, DVA, SysOps 폴더를 만들고 그 안에 노트를 채워 넣으려 합니다. 그런데 며칠 지나지 않아 이상한 지점..

들어가며 — apply 권한이 모두에게 있으면 생기는 일혼자 쓰는 Terraform과 팀이 쓰는 Terraform은 사실상 다른 도구입니다. 혼자일 때는 내 노트북에서 terraform apply를 치는 일이 전부지만, 사람이 늘어나면 같은 명령이 위험해집니다. 누구나 자기 노트북에서 운영 환경에 apply할 수 있다면, 어느 날 누군가의 로컬에만 있던 변경이 운영에 그대로 반영되고, 그 사람이 자리를 비운 사이 무엇이 왜 바뀌었는지 아무도 설명하지 못하는 상황이 옵니다. 인프라 코드가 팀의 자산이 되려면, 코드 자체보다 그 코드를 누가 언제 무엇으로 거르고 적용하는가가 먼저 정리되어야 합니다.이 글은 그 운영 장치를 다룹니다. 앞선 다섯 편에서 잡은 개념(선언형 사고, state, 문법, 모듈, 환경 ..

들어가며 — dev에 prod와 똑같은 돈을 쓸 수는 없다인프라를 코드로 짜기 시작하면 곧장 마주치는 모순이 하나 있습니다. dev와 prod는 같은 설계여야 하지만 같은 비용일 수는 없다는 점입니다. 개발 환경에서 운영처럼 가용 영역마다 NAT Gateway를 따로 띄우고, Aurora를 Multi-AZ로 굴리고, Kafka 브로커를 세 대씩 세우면 설계의 동질성은 얻지만 매달 나가는 비용이 감당이 안 됩니다. 반대로 dev를 너무 단출하게 만들면 "dev에서는 됐는데 prod에서 안 되는" 환경 차이가 사고로 돌아옵니다.이 모순을 푸는 가장 쉬운 길은 사실 가장 나쁜 길이기도 합니다. dev용 코드와 prod용 코드를 따로 복사해 두고 각자 손보는 것입니다. 처음엔 빠르지만, 시간이 지나면 두 벌의 ..

들어가며S3 버킷을 하나 제대로 만들려면 생각보다 손이 많이 갑니다. 암호화를 켜고, 버전 관리를 켜고, 퍼블릭 액세스를 네 가지 옵션으로 모두 막고, 라이프사이클 규칙을 걸고, HTTPS가 아닌 요청을 거부하는 정책까지 붙여야 합니다. 문제는 이런 버킷이 프로젝트 안에 하나가 아니라는 점입니다. 원시 데이터용, 정적 자산용, 로그용으로 여러 개를 만들다 보면, 어느 버킷에는 버전 관리를 빠뜨리고 어느 버킷에는 퍼블릭 차단 옵션 하나를 깜빡합니다. 같은 설정을 다섯 번 복사해 붙이는 방식은 다섯 번째에서 반드시 어긋납니다.이 글은 그 반복을 모듈로 묶기로 한 결정과, 모듈을 어떤 기준으로 설계했는지를 정리하는 글입니다. 앞 글에서 Terraform을 "무엇이 있어야 하는지를 적는 선언형 도구"로 봤다면,..