Kim-Baek 개발자 이야기

실수로 테이블을 날렸다금요일 오후 4시, 배포를 준비하고 있었다.-- 개발 DB에서 테스트 데이터 삭제하려고DELETE FROM test_reservations WHERE created_at 실행 버튼을 눌렀다. 1초 후, 끔찍한 메시지가 보였다.Query OK, 450,234 rows affected45만 건? 테스트 데이터는 100건인데...급하게 확인해보니 운영 DB에 접속되어 있었다. 실수로 운영 DB의 예약 데이터를 삭제한 것이다.SELECT COUNT(*) FROM reservations;-- 50,000 (원래 500,000)45만 건의 예약이 사라졌다.심장이 멎는 것 같았다. 하지만 다행히 백업과 바이너리 로그가 있었다.# 1. 새벽 2시 백업 복원mysql 30분 후, 모든 데이터가 복구..

MySQL로는 처리할 수 없었다Court Alarm이 2년째 운영되면서 새로운 기능을 추가하기로 했다. 실시간 채팅이었다.사용자들이 코트를 예약하면서 서로 메시지를 주고받고, 매칭을 할 수 있게 하는 것이었다. 간단해 보였다.-- 채팅 메시지 테이블CREATE TABLE chat_messages ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id BIGINT NOT NULL, user_id BIGINT NOT NULL, message TEXT NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_room_created (room_id, created_at));베타 테스트를..

데이터가 사라졌다금요일 밤 11시, 장애 알림이 울렸다."DB 서버 응답 없음"Court Alarm의 모든 예약 데이터가 저장된 MySQL 서버가 다운됐다. 급하게 서버에 접속했다.mysql -u root -p# ERROR 2002 (HY000): Can't connect to local MySQL serverMySQL이 죽어있었다. 재시작을 시도했다.systemctl start mysql# Job for mysql.service failed로그를 확인했다.tail -f /var/log/mysql/error.log[ERROR] InnoDB: Corruption detected in tablespace reservations[ERROR] InnoDB: Database page corruption[ERROR..

서버가 80%의 시간을 놀고 있었다Court Alarm API 서버의 모니터링 대시보드를 보고 있었다. 이상한 점이 있었다.CPU 사용률: 20%메모리 사용률: 40%응답 시간: 평균 2초동시 접속자: 500명리소스는 충분한데 응답이 느렸다. 뭔가 이상했다.스레드 덤프를 떠서 분석했다.jstack | grep "WAITING\|BLOCKED" | wc -l# 결과: 190 (전체 200 스레드 중)190개 스레드가 대기 중이었다! 무엇을 기다리고 있을까?"http-nio-8080-exec-42" #42 waiting on condition at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.rea..

100만 개 파일을 저장했더니 서버가 느려졌다Court Alarm이 1년쯤 운영되면서 사용자들의 프로필 사진이 쌓이기 시작했다. 처음엔 몇 백 개였는데, 어느새 10만 개, 50만 개, 그리고 100만 개를 넘어섰다.그런데 이상한 일이 생겼다. 파일을 저장하거나 읽는 속도가 점점 느려지는 것이었다.// 프로필 사진 저장val file = File("/data/profile-images/${userId}.jpg")file.writeBytes(imageData) // 처음엔 10ms → 지금은 500ms?!왜 똑같은 작업이 50배나 느려진 걸까?서버 스펙은 그대로였다. CPU도, 메모리도, 디스크도 여유가 있었다. 문제는 파일 시스템에 있었다. 하나의 디렉토리에 100만 개 파일을 저장하면서 파일 시스템의..

서버가 10,000개 연결을 처리하는 방법Court Alarm이 성장하면서 동시 접속자가 급증했다. 처음엔 100명, 그 다음 1,000명, 그리고 어느 날 10,000명이 동시에 접속했다.서버가 버텨낼 수 있을까? 놀랍게도 서버는 문제없이 동작했다. CPU 사용률 40%, 메모리 사용률 60%. 여유가 있었다.어떻게 서버 한 대가 10,000개의 동시 연결을 처리할까?답은 운영체제의 네트워크 스택에 있었다. 운영체제는 네트워크 연결을 효율적으로 관리하는 정교한 메커니즘을 가지고 있다. 소켓, 버퍼, 인터럽트, I/O 다중화...5년 차가 되어서도 이 부분이 가장 어려웠다. 하지만 실제 성능 문제를 해결하면서 운영체제의 네트워크 처리를 제대로 이해하게 됐다.소켓(Socket)이란 무엇인가기본 개념소켓은 ..

예약이 두 번 되는 버그Court Alarm을 출시하고 일주일 후, 황당한 버그 리포트가 들어왔다."같은 시간대에 예약이 2개 잡혔어요. 코트는 하나인데..."처음엔 믿기지 않았다. 예약 전에 분명히 중복 체크를 하는 코드가 있었다. 하지만 로그를 확인해보니 정말로 같은 시간대에 2명의 예약이 동시에 들어가 있었다.[2024-01-05 10:23:45.123] 사용자A: 14시 코트 예약 시도[2024-01-05 10:23:45.125] 사용자B: 14시 코트 예약 시도[2024-01-05 10:23:45.234] 사용자A: 예약 성공[2024-01-05 10:23:45.236] 사용자B: 예약 성공두 요청이 거의 동시에 들어왔다. 둘 다 "예약 없음"을 확인하고, 둘 다 예약을 진행했다. 전형적인 Ra..

서버가 느려지는 이유를 찾아서월요일 오전, Court Alarm 서버의 응답 속도가 점점 느려지고 있었다.배포 직후에는 평균 응답시간 200ms였는데, 2일이 지나니 2초, 3일째는 5초, 그리고 금요일엔 거의 응답이 없었다. 서버를 재시작하면 다시 빨라졌지만, 며칠 지나면 또 느려졌다.모니터링 그래프를 보니 메모리 사용량이 계속 증가하고 있었다. 시작할 때 500MB였던 메모리가 일주일 후엔 3.8GB(전체 4GB 중)를 사용하고 있었다. 전형적인 메모리 누수(Memory Leak) 증상이었다.5년차가 되어서도 메모리 관리는 여전히 어려웠다. 하지만 이번 경험을 통해 Heap과 Stack의 차이를 머리가 아닌 손으로 이해하게 됐다.메모리 구조의 기본메모리는 왜 영역을 나눌까프로그램이 실행되면 운영체제는..

이 글을 읽으면: 제가 코트알람 앱 개발 중 실제로 겪었던 성능 문제와 inline 함수로 해결한 과정을 배울 수 있습니다. 언제 inline을 써야 하고, 언제 쓰면 안 되는지 실전 경험을 바탕으로 완벽하게 알려드립니다.📌 목차들어가며 - 앱이 느려진 이유inline이 뭐길래? - 쉬운 설명언제 inline을 써야 할까?crossinline과 noinlinereified와 inline의 관계실제 성능 측정과 비교실전 최적화 사례마무리 - 다음 편 예고들어가며 - 앱이 느려진 이유코트알람 앱에서 겪은 실제 문제2024년 9월, 사용자 리뷰"앱이 너무 느려요. 코트 검색할 때마다 몇 초씩 걸려요. 😢" - ★★☆☆☆"로딩이 너무 길어서 다른 앱 쓸까 고민됩니다" - ★★★☆☆이 리뷰를 보고 밤새 코드..

프로세스와 스레드 - 경력 5년차 개발자의 실전 경험새벽 3시에 울린 장애 알림새벽 3시, 장애 알림이 울렸다."API 서버 응답 없음. 모든 요청 타임아웃."급하게 서버에 접속해서 확인해보니 CPU 사용률은 20%인데, 스레드 200개가 전부 BLOCKED 상태였다. 5년 차가 되어서야 깨달았다. 프로세스와 스레드의 차이를 '아는 것'과 '제대로 사용하는 것'은 완전히 다른 문제라는 것을.이 글에서는 경력 개발자 면접에서 단골로 나오는 "프로세스와 스레드"를 기본 개념부터 실무 적용까지 상세하게 정리해보려고 한다.프로세스란 무엇인가프로세스의 정의프로세스(Process)는 실행 중인 프로그램을 의미한다. 좀 더 정확히 말하면, 디스크에 저장된 실행 파일(예: .exe, .jar)이 메모리에 올라가서 실행..

이 글을 읽으면: 설정 파일, HTML, SQL 쿼리를 타입 안전하고 읽기 쉬운 Kotlin 코드로 작성하는 방법을 배울 수 있습니다. @DslMarker와 수신 객체 지정 람다로 직관적인 DSL을 만드는 실전 패턴을 완벽하게 마스터하세요.📌 목차들어가며 - DSL이 뭐길래?DSL 기초 - 수신 객체 지정 람다타입 안전성 - @DslMarkerHTML DSL 만들기설정 DSL - Config BuilderSQL DSL - 쿼리 빌더실전 DSL 패턴마무리 - 다음 편 예고들어가며 - DSL이 뭐길래?DSL (Domain Specific Language)"특정 도메인에 특화된 언어"일반 프로그래밍 언어 (Java, Kotlin):- 모든 것을 할 수 있음- 범용적DSL:- 특정 분야만 잘함- 전문적우리가 ..

이 글을 읽으면: Mockito 대신 Kotlin 친화적인 MockK로 테스트를 작성하는 방법을 배울 수 있습니다. Controller부터 Service, Repository까지 실전 테스트 패턴을 완벽하게 마스터하세요.📌 목차들어가며 - 왜 테스트 코드가 필요할까?테스트 환경 설정 - JUnit5 + MockKJUnit5 기본 - 테스트 작성법MockK - Kotlin 친화적 목 프레임워크Controller 테스트 - MockMvcService 테스트 - 비즈니스 로직Repository 테스트 - 데이터 계층통합 테스트 - 전체 플로우마무리 - 다음 편 예고들어가며 - 왜 테스트 코드가 필요할까?실제 프로젝트에서 겪은 사고2024년 12월, 금요일 오후 5시상황: 주문 시스템 배포 후 30분알림: "..

이 글을 읽으면: Java 중심의 Spring Boot를 Kotlin으로 더 간결하고 안전하게 작성하는 방법을 배울 수 있습니다. Controller부터 JPA, 코루틴 비동기 처리까지 실전 REST API 구현을 완벽하게 마스터하세요.📌 목차들어가며 - 왜 Spring Boot + Kotlin인가?프로젝트 설정 - Gradle + Kotlin DSLController와 REST APIJPA with Kotlin - Entity 설계Service와 비즈니스 로직코루틴으로 비동기 처리실전 REST API 구현마무리 - 다음 편 예고 들어가며 - 왜 Spring Boot + Kotlin인가?실제 프로젝트에서 겪은 변화2024년 11월, 레거시 전환 프로젝트기존: Java + Spring Boot- Gett..

이 글을 읽으면: 단일 값이 아닌 연속된 데이터를 안전하고 효율적으로 처리하는 Flow와 Channel을 마스터할 수 있습니다. 실시간 데이터, 이벤트 스트림, 반응형 프로그래밍을 실전 예제로 완벽하게 배워보세요.📌 목차들어가며 - 왜 Flow가 필요할까?Flow 기본 개념 - 흐르는 데이터Flow 연산자 - map, filter, collectStateFlow와 SharedFlowChannel - 코루틴 간 통신실전 반응형 패턴마무리 - 다음 편 예고들어가며 - 왜 Flow가 필요할까?실제 프로젝트에서 겪은 문제2024년 10월, 실시간 채팅 앱 개발요구사항:- 서버에서 실시간으로 메시지 수신- 사용자 타이핑 상태 업데이트- 접속자 수 실시간 표시→ "연속된 데이터"를 어떻게 처리하지?시도한 방법들:..