StudyDad

기술 실무 설계 시리즈 2/8내부 운영 도구를 만들 때 가장 어려운 질문 중 하나는 이것이다.어디까지 설계해야 충분한가?너무 단순하게 만들면 나중에 운영 문제가 생긴다.반대로 처음부터 대규모 서비스처럼 만들면 개발 속도와 유지보수 비용이 과해진다.내부 도구에는 내부 도구에 맞는 "충분히 좋은 설계" 기준이 필요하다.완벽한 설계는 목표가 아니다운영 도구는 대개 제한된 시간 안에 만들어진다.대규모 사용자 트래픽보다 특정 업무를 안정적으로 처리하는 것이 목표다.그래서 완벽한 설계보다 중요한 것은 다음이다.업무를 막지 않는가문제가 생겼을 때 복구 가능한가담당자가 바뀌어도 이해할 수 있는가변경이 필요한 곳이 좁은가지금 규모에서 운영 부담이 과하지 않은가완벽함보다 복구 가능성이 더 중요할 때가 많다.기준 1. 사용..

기술 실무 설계 시리즈 1/8관리자 페이지는 종종 작게 시작한다.목록 하나, 상세 화면 하나, 상태 변경 버튼 하나. 처음에는 단순 CRUD처럼 보인다.그래서 "이 정도는 그냥 만들면 되지 않을까?"라고 생각하기 쉽다.하지만 실제 운영에 쓰이는 관리자 페이지는 생각보다 빨리 복잡해진다. 인증, 권한, 배포, 캐시, API, 파일 다운로드, 장애 대응, 데이터 원천 같은 문제가 화면 뒤에 붙기 시작한다.작은 관리자 페이지에도 아키텍처가 필요한 이유는 규모 때문이 아니다.업무가 그 도구에 의존하기 때문이다.사용자 수보다 업무 중요도가 중요하다운영 도구는 사용자가 많지 않을 수 있다.하루에 몇 명만 쓰는 화면일 수도 있다.하지만 그 몇 명이 매일 중요한 업무를 처리한다면 시스템의 중요도는 낮지 않다.예를 들어..

AWS 실전 운영 시리즈 12/12WAF를 붙였다고 해서 시스템 전체가 자동으로 보호되는 것은 아니다.WAF는 어디에 연결되어 있는지에 따라 보호 범위가 달라진다.CloudFront에 WAF를 붙이면 CloudFront를 통과하는 요청은 검사할 수 있다. 하지만 CloudFront를 우회하는 API Gateway나 origin 직접 접근 경로는 별도 보안 정책이 필요하다.이 차이를 이해하지 못하면 "WAF가 있으니 안전하다"고 착각할 수 있다.문제 상황운영 콘솔 앞단에는 CloudFront가 있었다.프론트엔드 SPA는 CloudFront를 통해 S3에서 제공되었다.API 일부도 CloudFront를 거쳐 origin API 서버로 전달되었다.여기에 사무실 IP만 허용하는 WAF 정책을 붙일 수 있다.구조..

AWS 실전 운영 시리즈 11/12CloudFront를 S3 앞에 붙이는 구성은 익숙하다.하지만 CloudFront를 EC2나 API 서버 앞에 둘 때는 조금 다른 문제가 생긴다.CloudFront의 Custom Origin에는 origin domain name이 필요하다. 운영 중인 API 서버가 EC2 IP로만 접근 가능하다면, CloudFront origin으로 쓰기 위해 별도의 도메인을 만들어야 할 수 있다.이 글은 API용 CloudFront 앞뒤에 왜 도메인을 두 개 만들었는지 정리한 것이다.문제 상황운영 콘솔에는 상주 API 서버가 있었다.이 서버는 대시보드와 분석 API처럼 짧고 잦은 요청을 처리했다.사용자는 다음 도메인으로 API를 호출하게 하고 싶었다.api.example.com그리고 ..

퇴사와 이직 준비 시리즈 9/9아직 문이 열린 것은 아니다.합격 소식을 받은 것도 아니고, 다음 회사가 정해진 것도 아니다. 가족에게 모든 상황을 설명한 것도 아니고, 지금 회사에서의 마지막 일정이 분명하게 정리된 것도 아니다.그런데도 이 기록을 여기서 한 번 닫아보려고 한다.처음 이 시리즈를 시작했을 때는 답답함이 컸다.하나님께서 다음 일을 준비해두셨을 것이라는 믿음은 있었지만, 실제 하루는 분주했다. 공고를 보고, 이력서를 고치고, 지원하고, 기다리고, 불합격을 보고, 다시 공고를 봤다.뭔가 하고는 있는데 앞으로 가고 있는지 잘 모르겠는 시간이었다.지금도 결과가 생긴 것은 아니다.하지만 처음과 완전히 같지는 않다.적어도 무엇을 계속해야 하는지, 무엇을 내가 붙들 수 없는지, 어떤 말은 내 말이 아닌지..

퇴사와 이직 준비 시리즈 7/9이직 준비를 하다 보면 해야 할 일이 끝없이 나온다.업무와 프로젝트를 정리해야 한다. 최근 회사에서 발생한 이슈 중 내가 경험으로 가져갈 수 있는 것도 남겨야 한다. 회사에 있을 때만 확인할 수 있는 자료나 맥락도 정리해야 한다. 포지션에 맞는 공고를 찾고, 공고에 맞게 이력서를 다시 보고, 제출하고, 기다려야 한다.그리고 이 과정을 반복해야 한다.글로 쓰면 단순한데, 실제로는 꽤 지친다.처음에는 해야 할 일이 보이면 움직이면 된다고 생각했다. 그런데 시간이 지나면서 조금씩 알게 된다. 내가 열심히 할 수 있는 영역과, 아무리 붙들어도 바꿀 수 없는 영역이 계속 섞여 있다는 것을.그 둘을 구분하지 못하면 하루가 쉽게 흐려진다.내가 해야 하는 일은 분명히 있다지금 내가 해야 ..

AWS 실전 운영 시리즈 10/12운영 콘솔을 AWS에 올릴 때 배포만큼 중요한 것이 도메인 라우팅이다.React SPA를 S3에 올리고 CloudFront를 붙이면 화면은 열릴 수 있다. 하지만 실제 운영에서는 도메인이 여러 개 생긴다.프론트엔드 도메인API 도메인CloudFront origin 도메인디버깅용 직접 접근 도메인도메인은 단순 주소가 아니다.사용자가 어디로 들어오고, CloudFront가 어떤 origin을 보고, WAF가 어디에 붙고, API가 어떤 경로로 백엔드에 도달하는지 결정하는 인프라 설계 요소다.문제 상황운영 콘솔은 크게 두 종류의 트래픽을 가졌다.첫째, React SPA 정적 파일을 가져오는 프론트엔드 트래픽이다.사용자-> console.example.com-> CloudFro..

퇴사와 이직 준비 시리즈 6/9어제 코딩테스트를 봤다.제출까지 완료했다. HackerRank에서 제출 완료 메일도 받았다. 그래도 마음 한쪽에는 긴장이 남아 있었지만, 일단 내가 해야 할 것은 했다고 생각했다.그런데 오늘 출근길에 채용팀 메일을 받았다.정해진 기간이 만료되어 채용 진행 의사가 없는 것으로 간주하고 전형을 종료하겠다는 내용이었다.나는 이미 제출했는데.제출 완료 메일도 있는데.처음에는 단순한 해프닝이라고 생각했다.시스템상으로 제출 내역이 아직 반영되지 않았거나, 채용팀 쪽에서 확인이 늦어진 것일 수 있다고 생각했다. 그래서 HackerRank 제출 완료 메일을 캡처해서 답장을 보냈다. 제출했다는 사실을 확인해달라고 보냈다.그때까지만 해도 마음 한쪽에는 기대가 있었다.이 상황이 어떻게 정리될까..

퇴사와 이직 준비 시리즈 8/9면접을 준비하려고 하면 결국 내가 해온 일을 다시 말로 설명해야 한다.이력서에는 어느 정도 정리된 문장이 들어간다.정산 자동화.광고 운영 플랫폼.통합 운영 콘솔.Redash 대시보드.인프라 비용 정리.이렇게 적어두면 일단 항목은 보인다. 그런데 면접에서는 항목만으로는 부족하다. 누군가가 실제로 물어볼 것이다."그 프로젝트에서 어떤 문제를 해결하셨나요?""왜 그렇게 만들었나요?""가장 어려웠던 부분은 무엇이었나요?""성과를 숫자로 말할 수 있나요?"이 질문들 앞에 서면 갑자기 막막해진다.내가 한 일이 없는 것은 아니다. 오히려 할 말은 많다. 그런데 그 많은 일을 어떤 순서로 말해야 하는지, 어디까지 설명해야 하는지, 어떤 표현이 내 말처럼 들리는지 잘 모르겠다.내가 한 일을..

퇴사와 이직 준비 시리즈 5/9처음에는 가능한 포지션이 보이면 지원해봤다.각 잡사이트에서 내 이력서를 바탕으로 추천해주는 포지션이 있었다. 완전히 맞지는 않아도 그나마 가능성이 있어 보이면 열어봤고, 공고에 맞춰 이력서를 다시 검토하고 조금씩 조정해서 넣었다.비슷한 포지션에는 일반화된 이력서로 간편 지원도 해봤다.처음부터 거창한 전략이 있었던 것은 아니다. 시장에 나가보는 감각이 필요했고, 내 이력서가 어떻게 읽히는지 확인하고 싶었다. 그래서 지원 버튼을 누르기 시작했다.그런데 지원한 곳이 10개를 넘어가고, 서류 불합격도 나오기 시작하니 마음이 조금씩 바뀌었다.이제는 100개까지 지원해야 하는 건가.그런 생각이 들었다.가능한 포지션이면 일단 넣어봤다공고를 볼 때 처음 기준은 단순했다.비슷한 포지션이면 ..