정수의 코닥코닥

1. 들어가며사이드 프로젝트를 진행하며 궁금한 점이 생겼다. API에서 에러가 발생하면 어떤 상태 코드를 보내야 할까?프로젝트 팀원들과 이야기할 때마다 의견이 갈렸다. RESTful 원칙에 따라 400번대, 500번대를 사용하자는 의견과 응답을 정상적으로 받았으니 200이 맞다는 의견이 있었다. 나는 여기서 200이 맞다고 생각했다. 에러를 반환했다는 것 자체가 HTTP 통신에는 성공한 것이고, HTTP는 RFC로 정의된 표준 프로토콜인데 굳이 왜 변경해야 하는지 의문이었다. 차라리 그럴 거면 커스텀 상태코드를 만들어서 사용하는 게 낫지 않을까 생각했다. ZeroCho님의 유튜브 영상을 보고 다시 고민이 떠올라 이번 기회에 찾아보게 되었다. 클라이언트와 서버 입장에서 각각의 논리가 다 이해되었고, 상황과..

뒤끝터디 5주차 – 파티셔닝1. 들어가며5장에서 복제를 다루며 동일한 데이터를 여러 노드에 저장하는 방식을 배웠다. 이중화로 읽기 처리량을 높이고 장애 대응도 가능해졌지만, 여전히 데이터가 너무 많거나 요청이 너무 많은 상황은 복제만으로 감당할 수 없다. 이럴 때 등장하는 해결책이 바로 데이터 파티셔닝이다. 이번에는 파티셔닝과 다양한 기법들, 그리고 클러스터 환경에서의 재균형화 전략까지 적혀있어 읽어 보았다. 2. New – 새롭게 알게 된 개념 정리2-1. 데이터 파티셔닝의 진짜 이유파티셔닝을 고민하는 이유는 명확하다. 확장성이다.단일 장비로 처리할 수 없는 수준의 데이터를 쪼개서 여러 장비에 나누고, 그에 따라 저장과 질의 부담을 분산하려는 것이다. 단순히 데이터를 나누는 것이 아니라, 어떻게 나눌..

뒤끝터디 2주차 – 데이터 모델과 질의 언어1. 들어가며이번 챕터에서는 데이터 모델과 질의 언어에 대해 다룬다.사실 평소에 개발을 하며 데이터베이스 구조에 대해 깊게 고민할 기회가 많지는 않다.MSSQL을 중심으로 정형화된 모델만 사용해 온 입장에서, 이번 장은 모델링과 시스템 설계 전반을 다시 생각해보게 하는 내용이었다.관계형 모델의 태생적 한계와 이를 보완하기 위해 등장한 다양한 비관계형 DB의 목적, 그리고 각각의 데이터 모델이 사용되는 맥락에 대해 살펴볼 수 있었다.2. New – 새롭게 알게 된 개념 정리2-1. 계층 구조로 쌓이는 데이터 모델대부분의 애플리케이션은 데이터 모델이 단일 계층이 아니라 여러 계층 위에 얹힌 구조다.예를 들어 도메인 객체 → JSON → 관계형 테이블처럼 여러 표현 ..

글또와 함께한 3년2022년 5월, 글또 7기로 첫 발을 내디뎠다. 그리고 2025년 3월, 글또 10기를 끝으로 나의 글또 여정은 잠시 마무리된다. 글또와의 만남은 우연이었다. 인스타그램 알고리즘이 이끌어준 인연.당시 나는 2~3년 차 개발자로, 성장에 목말라 있던 시기였다. 다양한 스터디와 커뮤니티를 기웃거리며 나에게 맞는 ‘성장의 환경’을 찾고 있었고, 그 무렵 성윤님의 게시글을 통해 ‘글또’라는 개발자 글쓰기 커뮤니티를 알게 되었다.  받은 따뜻함을 나누고 싶다 7기 때 나는 주도적인 학습보다는 ‘해야 하니까 하는’ 느낌에 가까웠다.의무적으로 참여했기에 깊이 몰입하지 못했던 것도 사실이다. 그렇게 어영부영 8기를 맞이했고, 그때 CS 스터디를 통해 전환점을 맞이했다.소극적이던 나에게 스터디 멤버들..

최근 글또 활동을 하며 마인크래프트를 즐기고 있다.GCP를 사용해 서버를 열고 사용자와 함께 즐기고 있는데 같은 데이터 직군분께서 마크 데이터를 활용하여 통계를 내주시고는 하는데 이는 마크 서버에서 특정 데이터를 백업하고, 추출해야 하는 번거로움이 있었다.  기존에는 크론탭을 이용해 정해진 시간마다 백업을 수행했다. 하지만 이는 불필요한 데이터까지 백업하게 되어 비효율적이었다. 따라서 실제 접속이 발생한 시간대만 백업하는 방식이 필요했고, 이 문제를 해결하기 위해 Redis를 도입했다. Redis를 활용하면 접속 상태를 실시간으로 감지하고 특정 조건에서만 백업을 실행할 수 있어, 불필요한 백업을 줄이고 서버 리소스를 절약할 수 있다. 이 과정을 적어보며 redis를 설치 & 적용하며 수행했던 명령어와 느..

들어가며나는 달리기를 한다. 좋아하지는 않지만, 군대에서 처음 뛰어본 마라톤은 나의 스트레스를 해소하는 운동으로 이용되기 시작했다. 나는 평소에 생각이 많다. 업무를 하며, 일상을 살며 다양한 생각이 머릿속을 떠나지 않는다. 머리가 복잡해질 때, 혹은 다른 안 좋은 네이티브한 생각들로 머릿속이 가득 찰 때, 나는 뛰러 나가기 시작한다. 심장 소리와 나의 호흡을 느끼며 오래 달리다 보면, 생각이 사라진다(하지 못한다). 그리고 깨끗하고 맑은 생각으로 뇌를 초기화한다. 그렇게 마라톤을 시작하게 되었다.  실패와 성공첫 실패의 쓴맛은 나를 더 강하게 만들었다. 2023년 마라톤에 도전했을 때, "의지와 정신력만 있으면 풀마라톤을 뛸 수 있을 거야"라는 자만심으로 충분히 완주할 수 있을 거라 생각했다. 하지만 ..

1. 들어가며최근 회사 프로젝트에서 클라이언트와 실시간으로 데이터를 저장해야하는 일이 생겼다. 이 데이터를 보다 효율적으로 처리하기 위해 Apache Kafka를 도입하게 되었고 Kafka를 도입하기 전 Kafka의 개념과 주요 특징, 그리고 로컬에서 실행해보았다. 2. Apache Kafka란?Kafka는 대량의 데이터를 빠르고 안정적으로 전송하는 분산 스트리밍 플랫폼이다. 링크드인에서 개발되었으며, 현재는 실시간 로그 수집, 이벤트 스트리밍, 데이터 파이프라인 구축 등의 다양한 용도로 사용된다. Kafka의 기본적인 구조는 다음과 같다:Producer: 데이터를 Kafka로 보내는 역할Broker: 데이터를 저장하고 관리하는 서버Consumer: Kafka에서 데이터를 가져가는 역할Topic: 데이터..

이전 글 : Kotlin으로 Chunk 사용하기, Spring와 얼마나 다를까? 해당 글에서 이어집니다.  0. 런타임 시간을 줄일 수는 없을까?문득 공부를 해보고 궁금해졌다. 코틀린 런타임 시간은 줄일 수 없을까? 줄일 수 있다면 어떤 방법이 있는지 알아보고 기존 소스를 개선할 수 있는점은 없을까하여 추가로 수정해보았다. 1. Kotlin Reflection (kotlin-reflect) 제거kotlin-reflect는 주로 리플렉션 기능 (KClass, KProperty, KFunction 등)을 사용할 때 필요하지만, 현재 코드에서는 사용하지 않는다. 지워도 되는 이유는 아래의 이유가 있다.클래스 정보를 동적으로 조회하지 않음 (::class 사용 없음)프로퍼티나 함수 호출에 call() 같은 리플..

https://integer-ji.tistory.com/440 Spring Boot 3.x에서 Chunk 사용해서 데이터 read, write 사용률 알아보기0. Chunk를 사용하는 이유는 뭘까?메모리 관리에 용이전체 데이터를 한 번에 로드하지 않고 설정된 Chunk 크기만큼 메모리에 유지시킨다. 대용량 데이터 처리 시에도 OutOfMemoryError를 방지할 수 있다integer-ji.tistory.com 0. Kotlin과 차이가 있을까?저번주에는 Spring Boot에서 Java 17을 이용해 Chunk의 메모리 사용량을 알아보았다. 여기서 궁금한 점. Kotlin에서 Java 소스를 그대로 사용하게 된다면 과연 메모리 사용율은 어떻게 변할까?큰 차이가 있을지 궁금하여 시도해 보았다. 1. 프로..

0. Chunk를 사용하는 이유는 뭘까?메모리 관리에 용이전체 데이터를 한 번에 로드하지 않고 설정된 Chunk 크기만큼 메모리에 유지시킨다. 대용량 데이터 처리 시에도 OutOfMemoryError를 방지할 수 있다. Garbage Collection 부하가 감소된다. 2. 트랜잭션 관리Chunk 단위로 트랜잭션 처리가 되기 때문에 전체적인 프로세스 안정성에 향상된다. 3. 성능 최적화JDBC Batch 처리와 결합하여 데이터베이스 작업에 최적화한다. 네트워크 통신 횟수를 감소시킨다. 데이터베이스에 부하를 분산시킨다. 크게 이 3가지로 보인다.  나는 회사 프로젝트에서 대용량 데이터를 조금 더 효율적으로 다루어 보기 위해 테스트를 진행해 보았다.  1. 프로젝트 설정1-1. 사용된 언어와 라이브러리 버..