컴공블로그

이 활동은 젝트에서 진행한 프로젝트입니다. 젝트 공식 홈페이지: https://ject.kr 한 줄 요약 팀 빌딩부터 젝러닝까지, 개발보다 팀과 문제 정의를 만드는 기간이었다. 이 기간의 결론은 하나다. 좋은 규칙과 좋은 문제 정의가 좋은 코드보다 먼저다.팀, 그리고 규칙부터메시지를 읽으면 반드시 이모지를 남긴다. 미팅에 불참하면 채널에 이유를 공유한다. 회의 안건은 월요일까지 미리 올리고, 질문과 의견은 회의 전에 작성한다. 사소해 보이지만, 매주 화요일 밤 한 시간뿐인 정기 미팅을 낭비하지 않으려면 필수였다. 사이드 프로젝트가 무너지는 건 실력이 아니라 소통 공백 때문이라는 걸 모두가 알고 있었다.팀 목표도 이때 정했다. 첫째, 아무도 나가지 않기. 둘째, 데모로 끝나지 않고 운영까지 이어지는 서비스..

이 활동은 젝트에서 진행한 프로젝트입니다. 젝트 공식 홈페이지: https://ject.kr 젝트젝트(JECT)는 다양한 포지션 멤버들과 협업할 수 있는 IT 사이드 프로젝트 동아리예요. 홈페이지에서 더 자세한 내용을 확인해보세요!ject.kr 한 줄 요약젝러닝 이후 두 달, RE:fit의 백엔드를 데모데이까지 완주했다. 이번 기간의 가장 큰 배움은 코드보다 인터페이스 합의가 개발 속도를 결정한다는 것이었다.무엇을 만들었나RE:fit은 대학생 미술·디자인 전공자와 카페·식당 같은 상업 공간을 연결하는 양방향 전시·공간 매칭 플랫폼이다. 예술가는 전시 경험과 포트폴리오를 얻고, 공간은 방문자 유입과 마케팅 효과를 얻는다. 핵심은 공간이 예술가에게 제안하고 예술가가 공간에 지원하는, 상호 수락 기반의 양방향..

채팅이 안 됐다. 정확히는 메시지를 입력창에 쳐도 아무 데도 안 갔다. 근데 방 목록이랑 과거 메시지는 멀쩡하게 보였다. 이 "절반만 되는" 증상이 원인을 가리키고 있었다.이 글은 nginx 리버스 프록시가 WebSocket 핸드셰이크를 막고 있던 사고의 추적 기록이다. 방 목록 표시 ✅과거 메시지 표시 ✅실시간 메시지 전송 ❌실시간 메시지 수신 ❌ 방 목록과 과거 메시지는 일반 REST API로 가져온다. 이건 됐다. 그런데 실시간 채팅은 STOMP over WebSocket으로 돈다. 이게 안 됐다.REST와 WebSocket의 차이가 핵심 단서였다. 둘 다 같은 백엔드, 같은 nginx를 거치는데 한쪽만 막혔다면 문제는 프로토콜 차이에 있다.진단 — 핸드셰이크를 직접 시도브라우저 콘..

왜 풀 페일오버 안 갔나홈서버에서 운영 중이던 서비스에 두 번의 사고가 있었다. Flyway 마이그레이션 충돌로 30분 다운타임, 그 며칠 뒤 CI/CD 환경변수 누락으로 또 한 번 부팅 실패. 두 사고 모두 잘 복구했지만 단일 환경 운영의 한계를 직접 체감했다.문제는 진짜 페일오버는 비쌌다는 거다. ALB가 월 $20, ElastiCache가 월 $12, RDS Multi-AZ가 단일보다 2배. 다 합치면 매월 $80~100. 매출이 없는 MVP 단계에 정당화하기 어려운 비용이었다.그래서 다른 길을 찾았다. 풀 페일오버의 핵심 가치(쓰기까지 가능한 진짜 페일오버)는 유지하되, 부차적인 자원은 다 빼고 최소한으로 가는 구성. 이걸 "미니 C"라 부르기로 했다.첫 번째 결정 — VPC 범위와 서브넷VPC는..

지난 글에서 PostgreSQL을 S3에 백업하는 기본 파이프라인을 만들었다. 하지만 그게 끝이 아니었다.진짜 백업 시스템은 다음 세 가지가 더 있어야 완성된다.오래된 백업 자동 정리 (라이프사이클)복구가 진짜 되는지 검증 (복구 테스트)매일 자동 실행 (cron)이번에 이 셋을 다 끝냈다. 그리고 그 과정에서 또 몇 번 부딪혔다.라이프사이클 — 백업 권한 없이 자동 삭제오래된 백업은 30일 후 자동으로 지우고 싶었다. 처음 떠올린 방법은 "스크립트가 30일 지난 객체를 찾아서 aws s3 rm으로 지우게 한다"였다.그런데 이 방법은 두 가지 문제가 있다.백업 사용자에게 DeleteObject 권한을 줘야 한다. 일부러 빼놨던 권한자격증명 노출 시 백업이 통째로 날아갈 수 있다. 랜섬웨어 시나리오에 다시..

홈서버에서 운영 중인 PostgreSQL 데이터베이스를 매일 자동으로 AWS S3에 백업하는 시스템을 구축했다. 이 글은 그 과정에서 마주친 문제들과 해결 과정을 정리한 기록이다.왜 S3에 백업해야 했나홈서버 환경에서 운영 중인 서비스가 있다. Spring Boot 애플리케이션과 PostgreSQL 데이터베이스가 라즈베리파이 기반 서버에서 돌아가는데, 정전이나 디스크 고장 같은 사고가 발생하면 데이터를 잃을 위험이 있었다.처음에는 "DB 복제(Replication)를 하면 되지 않나" 싶었다. 그런데 복제와 백업은 보호하는 사고 유형이 완전히 다르다는 걸 알게 됐다.복제(Replication): 실시간 동기화로 가용성 확보 백업(Backup): 시점별 스냅샷으로 복구 가능성 확보예를 들어 새벽 3시에 졸..

결제 시스템이나 사용자 개인정보를 다룰 때, 단순히 데이터를 가리는 것만으로는 부족하다. 누군가 DB에 접근해서 암호화된 계좌를 변조하고, 서버가 그대로 복호화해서 송금해버린다면 사고가 발생한다.그래서 금융권이나 보안이 중요한 프로젝트에서는 일반적인 AES(CBC 모드) 대신 AES-GCM을 표준처럼 사용한다.GCM 모드란?보통 암호화라고 하면 비밀키만 잘 숨기면 된다고 생각하기 쉽다. 하지만 AEX-GCM을 이해하기 위해서는 IV(초기화 벡터)와 인증 태그(Authentication Tag)다.IV는 같은 데이터를 암호화해도 매번 다른 암호문이 나옥 섞어주는 난수다. GCM 모드에서 이 IV를 재사용하는건 매우 위험하다.인증 태그는 데이터가 1비트라도 조작되었는지 확인하는 디지털 지문이다. 이 태그 덕..

1. 기본 뼈대: "배열 (Bucket Array)"HashMap의 가장 기초적인 물리적 형태는 **거대한 배열(Array)**입니다. 이 배열의 각 칸을 **'버킷(Bucket)'**이라고 부릅니다.작동 원리:map.put("Key", "Value")를 호출합니다."Key"를 해시 함수(Hash Function)에 넣어서 정수값(Hash Code)을 얻습니다.그 정수값을 배열의 크기로 나눈 나머지(Hash Code % Array Size)를 구합니다. 이 값이 바로 배열의 인덱스가 됩니다.해당 인덱스(버킷)에 데이터를 저장합니다.물리적 특징: 배열이므로 인덱스만 알면 접근 속도가 $O(1)$로 매우 빠릅니다.2. 핵심 문제: "해시 충돌 (Hash Collision)"과 해결책문제는 서로 다른 Key가..

의문의시작보통 조회 속도를 높이기 위해서 Redis를 도입한다고 배운다.MySQL 공부를 하다 보니 MySQL의 InnoDB에는 Buffer pool이라는 메모리 캐싱 영역이 있다는것을 알게 되었고,"만약 DB Buffer Pool Hit Ratio가 100%라면(모든 데이터가 메모리에 있다면), Disk I/O가 없는데 굳이 Redis를 쓸 필요가 없는 것 아닐까? 왜 Redis가 구조적으로 더 빠를 수밖에 없을까?"자료구조의 차이MySQL(B+Tree)DB는 데이터를 찾기 위해 B+Tree 구조를 탐색한다.메모리에 있어도 Root -> Branch -> Leaf 페이지로 이동하는 논리적 비용이 발생시간 복잡도 O(log N)Redis(Hash Table)Key-Value 구조로, Key를 해싱하면 바..

이번 주, 나는 무엇을 경험했는가? 이번 주는 이전보다 내가 내가 어떻게 배우고 있는가에 좀더 집중을 했던 한 주였던거같다.기능을 완성하는 것보다 내가 진짜 이해했는지 스스로 점검하려는 노력이 컸고이 과정에서 구현보다 학습에 좀 더 집중을 하다보니 결과물이 부족하다는 것에 불안감이 들었지만 부스트캠프에서구현보다는 학습이 중요하다고 해서 불안감을 떨칠려고 노력했던거 같다. 스스로 반성했던점?1. 이해한것과 이해했다고 믿는 것은 다른 것 같다. 이해했다고 나는 생각했지만 막상 설명하면서 질문을 받고 정리해보니 내가 정말 안다고 말할 수 없다는 걸 깨달았다. 다음에는 스스로에게 질문을 하면서 내가 완벽하게 이해했는지에 대해서 점검을 하고 넘어가야 될 것 같다.2. 기록이 중요 한거같다. 2주차가 끝나고 회고를..