보호되어 있는 글입니다.

AWS에서 RDS를 생성하고 로컬 개발환경에서 외부(DBeaver 등)에서 연결하려고 할 때,퍼블릭 액세스가 안 돼서 타임아웃 나는 경우, 대부분은 VPC 및 서브넷 설정이 잘못되어 있기 때문입니다.이번 포스트에서는 퍼블릭 액세스 가능한 RDS 인스턴스를 직접 생성하면서 겪은 문제와 해결 방법을 정리합니다.현재 구성은 AWS 실습 및 테스트를 위한 구성 설정이므로, 운영 환경에서 아래처럼 구성하는 것은 추천드리지 않습니다. 저는 테스트를 위한 용도로 구성했으니 참고해주세요!✅ 목표VPC 내에 퍼블릭 / 프라이빗 서브넷 구분퍼블릭 서브넷에 RDS 인스턴스를 배치외부 툴 (ex. DBeaver)에서 접속 가능하도록 설정 RDS 연결 안 될 때 점검 순서RDS → Publicly Accessible = ✅ Y..

🔥 클라우드 인프라에서 HA(High Availability)를 보장하는 진짜 방법Active-Active, DR, AZ, Docker, 그리고 진짜 고가용성의 본질까지 한방에 정리📌 목차Active-Active, DR, AZ, Cloud란?Standby 전략: Hot / Warm / Cold애플리케이션 장애에서의 HA 보장 방법Docker만으로는 HA가 안 되는 이유왜 인스턴스를 2개 이상 둬야 하는가?마무리: 진짜 HA 구성은 이렇게 한다1. ✅ Active-Active, DR, AZ, Cloud의 관계🔹 Active-Active두 시스템이 동시에 서비스 처리 (부하 분산 + 장애 허용)성능과 가용성을 동시에 잡는 구조단, 데이터 동기화/복잡도 ↑🔹 DR (Disaster Recovery)장애..

로그, 제대로 써보고 있나요?시니어 개발자 선배님과의 커피챗에서 느낀 부끄러움얼마 전, 시니어 개발자 선배님과 커피를 마시며 이런 질문을 받았습니다.“로그를 어떤 기준으로 작성하세요?”당황한 저는 이렇게 대답했습니다.“음… 인포는 인포용, 디버그는 디버그용이요...”그 순간, 제 안에 울려 퍼진 한 마디."이게 뭐 하는 소리야, 나 지금까지 그냥 감으로 로그 쓴 거였잖아?"로그는 선택이 아니라 생존이다로그는 단순히 콘솔에 뿌려지는 문자열이 아닙니다. 로그는 문제 해결의 첫 번째 열쇠이자, 운영의 나침반, 배포 후 유일한 증거물입니다.시스템에서 장애가 났다?→ 로그가 없으면 디버깅은 하늘에 별 따기.유저가 데이터가 사라졌다고 한다?→ 로그 없으면 "죄송합니다..." 말밖에 못 한다.로그 작성 기준이 없다면..

이번 글에서는 WSL2 환경에서 Cockpit을 설치하고 사용하는 방법을 정리했습니다.Cockpit은 웹 기반 리눅스 서버 관리 도구로, 시스템 자원 모니터링, 서비스 관리, 계정 설정 등 다양한 기능을 GUI로 제공해줍니다.특히 systemd 기반으로 동작하기 때문에, WSL 기본 환경에서는 별도 설정이 필요합니다.그럼 바로 시작해보겠습니다. 😎🔍 Cockpit이란?Cockpit은 Red Hat에서 만든 웹 기반 리눅스 서버 관리 도구입니다.터미널 없이도 브라우저를 통해 리눅스 시스템을 쉽게 관리할 수 있어, 초보자부터 전문가까지 모두에게 유용합니다.특히 SSH 포트(22번)가 차단된 환경에서도 Cockpit 포트(기본 9090)만 열려 있다면, Cockpit의 웹 터미널(Shell) 기능을 통해 ..

1. 서론회사 내부망에서 Jenkins 환경을 처음 구성할 때, 플러그인 설치나 외부 의존성 다운로드 중 다음과 같은 에러 로그를 자주 마주하게 됩니다.javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failedsun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target이 에러는 SSL 인증서 검증 과정에서 신뢰할 수 있는 인증 경로를 찾지 못해 발생하는 문제입니다. 구글 검색이나 여러 블로그 글에서는 대체로 skip-cert..

첫 개발자 커리어는 중소기업에서 시작해 약 2년 5개월간 자사 앱 서비스를 유지보수하는 역할을 맡았다. 그러나 점차 개발자로서의 역량 부족을 느끼며, 코드를 작성하는 데 부담감을 가지게 되었고, 결국 퇴사를 결정했다. 이후 부족한 부분을 채우기 위해 삼성청년소프트웨어아카데미(SSAFY)에서 1년간 교육을 받았으며, 그 후 외국계 SI 기업에 백엔드 개발자로 다시 커리어를 시작하게 되었다. 현재까지 약 10개월간 SI 백엔드 개발자로 근무했고, 진행 중인 프로젝트가 마무리되는 시점에 회고를 남기게 되었다.SI 기업에 처음 취업하면서 알게 된 점SI 기업은 인력을 Man/Month(맨먼스) 단위로 표현한다. 말 그대로 ‘한 사람이 1개월 동안 수행할 수 있는 작업량’을 의미하지만, 이 단위가 실제 개발자의 ..

2024 회고취업2024년 6월에 SSAFY 10기를 수료하고 운 좋게도 취업이 되어 지금 회사로 취업(이직?) 하게 되었다. 처음으로 SI 기업에서 일을 하게 되었는데, 악명이 높은것과 별개로 현재 워라밸, 기술스택, 고객과의 관계 모두 순조롭고 만족스럽다. 아쉬운점은 두가지가 있는데, 첫번째로 업무에서의 아쉬운 점은 SI 하도급으로 프로젝트에 참여하면서 보안상의 이유로 서비스의 전체 소스코드를 확인할 수 없는 점에서 기여할 부분들이 한정적이라는 점이다. 웹 개발 뿐만 아니라, 인프라 및 클라우드 관련 공부도 했었기에 지식들을 써먹을 수 없어서 조금 아쉬운 부분이 있다. 두번째로는 회사의 문제이다. 우리회사는 SI 기업의 해외 지사이므로 해외 개발 인원들과 협업을 해야하는데, 소통을 하는것이 정말 어렵..

개요SAA-C03, Github Foundations에 이어 올해 마지막으로 DVA-C02 자격증을 취득했다. SAA-C03를 공부하면서 다양한 AWS 서비스의 존재 여부와 전체적인 틀에 대해서 알 수 있었고, DVA-C02의 경우는 이 서비스들 중에 특정 서비스를 다루는 방법이라고 들어 자격증을 준비했다. SAA-C03에 비해 느슨하게 준비했었지만 간단한 후기를 올려본다.공부방법SAA-C03 취득 이후 약 4개월이 지났는데, 공부는 회사 업무가 끝나고 틈틈히 공부했다. 아마 3주정도 공부한 것 같다. 나는 별도로 Udemy강의는 듣지 않았고, examTopics의 덤프 문제를 1.5회독 했다.dump문제가 약 400개 있었는데, 시험치기 전까지 1회독 이후 200번 정도까지 한번 더 본 것 같다. 헷갈..

개요갑자기 예전에 만들었던 Android 앱을 Github Release로 배포하는 Github Action 스크립트를 누군가가 사용하고 있는지 궁금해서 검색해봤다. 그런데 정말 사용하는 사람이 있네?? 왠지모를 내적 친밀감이 생겨 해당 레포지토리를 조금 탐색해봤다.안드로이드 앱 런쳐 프로그램인 것 같은데, 그냥 보기만 해서는 잘 모르겠다.테마??를 적용하는 프로그램 인 것 같다.해당 프로그램은 꽤나 많은 사람들이 유지보수 하는 오픈소스로 보인다. (11명의 contributer, 37개의 frok, 181개의 star..) 내가 작성한 릴리즈 스크립트가 다른 오픈소스 활동에 도움을 줄 수 있다는 것이 기쁘다. 앞으로도 오픈소스 기여를 통해 전 세계의 개발자들과 소통하고, 사람들에게 도움을 줄 수 있게 ..