대학을 졸업하고 사회에 나온 지 딱 10 년이 되었습니다. 대학 시절의 전공은 지금 하는 일과 거리가 멀지만, 복수전공 후 IT 업계로 전직한 계기를 설명하자면 글이 길어질 듯 하여 생략하겠습니다. 사실 갑자기 IT 업계에 관심이 생겨서는 아니었고, 예전부터 코드로 프로그램을 만드는 데 관심이 있기는 했습니다. (관련기사 - 직접 인터뷰 한 건 아니고, 공개된 정보를 통해 작성된 기사) 그래서 중학생 때까지는 장래희망에 프로그래머라고 계속 적었던 기억이 있습니다. 한참 돌아서 오기는 했지만, 결국 IT 업계에서 일하게 되었고 10 년 간 여러 가지 업무를 해 왔네요.

들어가며 인터넷 서비스를 운영하다 보면 DDoS 공격을 받는 경우가 종종 있습니다. 해킹 목적으로 사이트를 공격한다거나, 경쟁사를 견제하기 위한 목적으로 DDoS 공격을 하는 사례가 있습니다. 그 외에도 실수로 API 호출을 너무 많이 하는 바람에 의도치 않게 상대 서비스를 다운시키는 경우도 있겠죠. 이러한 DDoS 공격을 막기 위해, 클라우드 벤더에서 제공하는 기능이나 여러 회사에서 제공하는 솔루션 제품들을 사용할 수 있습니다. 이번 글에서는 공격에 사용된 IP 주소 목록이 있을 때, IP 주소의 세부 정보를 얻을 수 있는 방법에 대해 이야기 해 보고자 합니다.

2022년 펜타포트 락 페스티벌에서 찍은 ‘퇴사’ 깃발. 퇴사 기념 짤로 쓰고 싶었는데 실패했네요. (이 깃발은 올해에도 등장했습니다) 회사 상황이 어려워져서 재직 중이던 회사를 떠나게 되었습니다. 이에 의도하지 않은 이직을 하게 되었는데요. 조금 급하게 이직을 한 감이 있지만, 그 과정을 돌아보려고 합니다. 그리고 앞으로 어떻게 커리어를 이어 나갈지에 대해 고민한 내용도 이야기 해 보고자 합니다. 요약 금번 이직 과정을 정리한 구글 시트. 회사명과 담당자(리크루터, 헤드헌터, 자체 지원)는 숨김 처리 하였습니다.

최근 EKS에 Spring Boot 애플리케이션을 올렸는데, ServiceAccount에 IAM Role을 연결했음에도 AWS API를 호출하지 못하는 문제가 있었습니다. 이 문제를 해결하기 위해 테스트 한 과정을 남겨보려고 합니다. 우선, AWS의 Java 버전 SDK는 부여된 권한을 어떻게 찾는지 알아보겠습니다. 따로 설정을 하지 않았다면, 아래와 같은 순서로 찾습니다. Java의 시스템 properties 환경 변수 AWS의 STS(Security Token Service)로 부터 얻은 Web Identity Token 공유된 credentials, config 파일: 별도의 설정이 없으면 default 프로필을 이용 ECS 컨테이너 credentials EC2 인스턴스에 부여된 IAM Role 그리고 EKS의 IAM Roles for Service Accounts(이후 IRSA로 표기) 기능은 STS(Security Token Service)의 AssumeRoleWithWebIdentity API 호출을 통해 권한을 얻습니다.

최근에 런던 여행을 다녀 왔습니다. 이번 런던 여행은 두 가지 목적이 있었습니다. 첫번째는 프리미어 리그를 보러 가는 것이었고, 두번째는 음반 가게를 구경하며 제가 갖고 싶었던 것들을 구해오는 것이 목표였습니다. 마침 제가 여행을 다녀온 주에 토트넘과 브라이튼의 경기가 있어서 관람했는데요. 그 경기에서 손흥민 선수가 프리미어 리그 100번째 골을 넣었죠. 이번 이야기는 두번째 목표를 이루기 위해 떠난 여정을 설명드리고자 합니다. 사실 런던에는 정말 많은 음반 매장이 있고, 이걸 모두 설명해 드리는 데는 한계가 있을 것입니다.

Terraform에서 개발/운영 환경을 나누기 위해, 폴더/디렉터리를 이용할 때가 있습니다. 하지만 이런 상황도 있죠. 개발/운영 환경 내 staging/QA 환경이 필요한 경우 테스트를 위해 임시 인프라 구성이 필요한 경우 위와 같은 상황에 대응하기 위해, Terraform에서는 Workspaces 라는 기능을 지원합니다. 이번에는 Terraform의 Workspaces 기능은 무엇인지, 어떻게 사용하면 되는지 알아보려고 합니다. Workspaces를 사용하려면? Terraform에서 관리하는 리소스 상태는 backend에 저장합니다. 이러한 데이터는 하나의 workspace에 속합니다. 기본적으로 이런 리소스 상태는 default workspace에 들어 있습니다. 몇몇 backend는 여러 개의 workspace를 지원하며, 하나의 설정과 연결된 여러 상태를 저장할 수 있습니다.

2022년은 우여곡절이 있었던 해였습니다. 주변의 여러 상황 때문에 팀 리더라는 직책을 맡게 되었습니다. 사실 재직 중인 회사에 입사하면서 고려했던 부분은 아니었습니다. 지난 회사에서도 팀 빌딩 경험이 있다 보니, 이번에는 피하고 싶다는 생각이 있었기 때문입니다. 그렇지만, 회사 생활이라는 것이 제 마음대로 되는 게 아니더라구요. 다행히 제가 요청한 대로 TO가 나왔고, 계획에 맞게 인원을 뽑을 수 있었습니다. 올해 회고는, 1인 팀에서 세 명으로 팀을 키운 이야기, 그리고 이를 바탕으로 1년 간 팀을 운영했던 이야기를 해 보고자 합니다.

(개인 사비로 책을 구매 후 작성하였습니다.) 최근에 개발자 분들 뿐만 아니라 개발자가 아닌 분들도 많이 읽으시는 "구글 엔지니어는 이렇게 일한다(원제: Engineering at Google)" 를 읽고 느낀 점들을 이야기 해 보고자 합니다. 나무위키에 따르면, 구글은 1998년에 설립되어 24년이 넘은 회사입니다. 그만큼 많은 엔지니어들이 대규모의 서비스를 구축하고 운영한 역사가 있고, 이러한 과정에서 배운 것들이 아주 많을 것입니다. 최근 저의 경험을 돌이켜 보면, 사수가 없이 일하는 경우가 많았습니다. 그리고 지금은 제가 작은 팀을 이끌어야 하는 상황이 되었네요.

AWS에서 Kubernetes를 사용하려면 여러 방법이 있겠지만, 가장 편한 방법은 EKS 서비스를 이용하는 것이죠. EKS 클러스터를 생성하는 방법은 여러 가지가 있는데요. 이번 글에서는 eksctl이라는 프로그램을 이용해서 EKS 클러스터를 생성하는 방법을 알아보고, 어떤 리소스를 생성하는지 알아보려고 합니다. 먼저 Kubernetes 클러스터의 구조를 알아보고, EKS에서는 어떤 차이점이 있는지 알아 보겠습니다. Kubernetes 클러스터의 구조와 EKS Kubernetes 클러스터는 다음과 같이 구성되어 있습니다. 출처: kubernetes.io 노드(Node): 컨테이너 내의 애플리케이션을 실행하는 서버들의 집합으로, 파드(Pod)는 워커 노드에서 동작합니다. 앞으로 노드 또는 워커 노드라는 말이 계속 등장할텐데, 똑같은 것으로 이해해 주시면 됩니다.

계기 저는 2년 전에 AWS의 Certified Solutions Architect - Associate 자격증을 취득한 적이 있습니다. 언젠가는 다음 단계의 자격증을 취득할 생각이 있긴 했습니다. (다음 자격증 시험에 응시할 때 50% 할인 쿠폰이 크긴 하더라구요) 그러다가 작년 하반기에 이직을 하였고, 최근 몇 개월 동안 현재 시스템을 분석하고 개선하는 작업들을 진행했습니다. 저희 팀은 지금의 시스템을 운영하고, 다음 버전의 시스템을 구축하여야 하는 과제가 있는데요. 그 과정에서 시스템을 구축하고 운영하는 데 좀 더 많은 지식이 필요하겠다는 생각이 들었습니다.