Overview​

2024년엔 정말 많은 일이 있었다.

더 좋은 문장이 떠오르지 않아서, 이런 뻔하기 그지없는 문장으로 회고를 시작한다. 누구나 '오늘, 엄마가 죽었다' 같은 문장으로 글을 시작할 수 있는건 아니니까. 아니, 그게 가능한가. 잘 모르겠다.

Overview​

리뷰하기 쉬운 코드란 무엇인가?

읽기 쉽고 코드 리뷰하기 좋은 코드 작성 가이드 는 현직 LINE 개발자가 자신의 경험을 바탕으로 작성한 책이에요. 이 책은 코드의 가독성을 높이기 위한 다양한 방법과 원칙을 상세하게 다루고 있어요.

개인적으로 정말 잘 다듬어진 코드 컨벤션 입문 서적이라는 생각이 들었어요. 몇 가지 이유가 있는데 지금부터 소개드려볼게요.

Overview​

• 참가 일시: Nov 11, 2024
• 장소: 코엑스 그랜드블룸
• 관련 링크: DAN 24

운좋게도 네이버에서 주관한 DAN24 에 다녀올 수 있었습니다. 결론부터 말씀드리면, 24년에 참여한 컨퍼런스 중 가장 수준이 높았다고 할 수 있을 것 같아요. 아래는 대략적인 내용을 적어둔 것이며, 자세한 내용은 DAN24 공식페이지를 참고해주세요.

KafkaKRU 밋업 리뷰: Event Sourcing부터 리더 파티션 밸런싱까지​

2024년 11월 21일, 서울 중구 삼화타워에서 열린 KafkaKRU 밋업에 참석했습니다. 사실 대기자 명단에 있었어서 참석이 어려운 상태였던 것 같지만, 열정으로 봐주셔서 다행히 쫓겨나지는 않았습니다. 결과적으로는 예상을 훨씬 뛰어넘는 값진 시간이었어요.

Overview​

• 참여 날짜: 2024년 10월 24일 목 (day 3)
• 장소: Kakao AI Campus

Overview​

여러 기기에서 클라우드 스토리지를 사용하시나요? 그렇다면 아마도 충돌 파일이 조금씩 늘어나는 경험을 해보셨을 것 같아요.

틈만 나면 늘어나는 conflicted 파일

파일이 동기화되기 전에 수정작업을 하거나, 네트워크 이슈로 동기화가 조금 지연되었거나 하는, 여러 이유로 충돌파일은 계속해서 늘어만 갑니다.

개인적으로 항상 깔끔한 상태를 좋아하는 편이라, 이런 더미파일들을 주기적으로 지워주고 있어요.

그런데 뭔가 오늘따라 반복적인 작업이 귀찮네요. 오랜만에 shell 을 작성해서 개발자 티를 좀 내보려 합니다.

최근 블로그 플랫폼을 옮기는 작업을 진행했습니다. 이 과정에서 문제를 마주할 때마다 우아한 해결방법은 없을 지 고민하며 몇 자 적어두었는데, 나름 수요가 있을지도 모른다는 생각에 글로 발행해보았습니다.

Overview​

• 하나의 개발 언어만 쓰는게 아니라 다양한 개발 언어를 활용하고 계신가요?
• sdkman, rvm, nvm 등등 여러 패키지 매니저의 명령어를 외우는데 피로감을 느끼신 적은 없으신가요?
• 개발 환경을 좀 더 빠르고 편리하게 관리하고 싶지 않으신가요?

mise 를 사용하면 어떤 언어, 도구를 사용하더라도 정확하게 필요한 버전을 사용할 수 있고 다른 버전으로 전환해가며 사용한다거나 프로젝트별로 버전을 지정하는 것도 가능해요. 파일로 명시하기 때문에 팀원들간에 어떤 버전을 사용할지 토론하는 등의 커뮤니케이션 비용이 줄어들 수 있지요.

지금까지 이 분야에서 가장 유명한건 asdf 였어요[^fn-nth-1]. 하지만 최근 mise 를 사용하기 시작한 뒤로는 mise 가 UX 측면에서 조금 더 괜찮다는 생각이 들었어요. 이번 글에서는 간단한 사용 용례를 소개해드려보려고 해요.

의도적인지는 모르겠으나 웹페이지조차 비슷하다.

mise-en-place, mise​

mise('meez, 미즈'라고 발음하는 것 같아요)는 개발 환경 설정 툴입니다. 이 이름은 프랑스 요리 문구에서 유래한 것으로, 대략 "설정" 또는 "제자리에 놓다"로 번역됩니다. 요리를 시작하기 전에 모든 도구와 재료가 제자리에 놓일 준비가 되어 있어야 한다는 뜻이라고 하네요.

간단한 특징을 나열해보면 아래와 같아요.

Overview​

여러 클라이언트의 요청을 동시에 핸들링할 수 있는 서버 애플리케이션을 구현하는 건 이제 너무나 쉽습니다. Spring MVC만 사용해도 뚝딱 만들어낼 수 있으니까요. 하지만, 엔지니어로서, 그 이면의 원리가 너무나 궁금합니다 🤔. 이번 글에서는 당연한 것처럼 느껴지는 것들에 '왜' 라는 질문을 던져보며, 다중 접속 서버를 구현하기 위해 어떤 고민이 있었는지 되짚어보는 여정을 떠나봅니다.

소켓(Socket)​

먼저 '소켓' 에서 출발합니다. 네트워크 프로그래밍 관점에서 소켓은, '네트워크상에서 데이터를 주고받기 위해 파일처럼 사용되는 통신 엔드포인트' 입니다. '파일처럼 사용되는' 이라는 설명이 중요한데, 파일 디스크립터(file descriptor, fd) 를 통해 접근되고 파일과 유사한 I/O 연산을 지원하기 때문입니다.

• 파일과 유사하게 다뤄야 하다 보니 많은 요청을 위해서는 그만큼의 파일을 열 수 있어야 하겠습니다.
• 예전에는 1개의 프로세스가 열 수 있는 파일 개수가 4096개로 제한되어 있었습니다.
• ulimit 을 사용하면 이 제한을 확인할 수 있습니다.
• 요즘은 unlimited 가 기본이라 크게 신경쓸 필요는 없지만, 오래된 리눅스 버전을 사용하는 경우는 주의해야 합니다.
• Too Many Open Files 라는 에러가 발생하면 이를 확인해보세요.

소켓을 사용하여 서버 애플리케이션을 구현하려면 다음과 같은 과정을 거쳐야 합니다.

SELECT FOR UPDATE 구문의 동작 방식​

PostgreSQL의 FOR UPDATE 잠금은 트랜잭션 내에서 SELECT 쿼리를 수행하는 동안 테이블의 행을 명시적으로 잠그는 데 사용됩니다. 이 잠금 모드는 일반적으로 트랜잭션이 완료될 때까지 선택한 행이 변경되지 않도록 하여 다른 트랜잭션이 충돌하는 방식으로 해당 행을 수정하거나 잠그지 못하도록 하려는 경우에 사용합니다.

예를 들면 티켓 예매처럼 특정 고객이 티켓 예매 과정을 진행하는 동안 다른 고객이 데이터를 변경할 수 없도록 막기 위해 사용할 수 있어요.

이번 글에서 살펴볼 케이스들은 조금 특별합니다.

• 잠금을 사용하는 읽기와 잠금을 사용하지 않는 읽기를 혼용하게 된다면 select for update 는 어떻게 동작할까요?
• 애초에 잠금을 사용했는데 다른 트랜잭션에서 읽기가 가능하긴 한 걸까요?
• 읽기 방식을 혼용해도 데이터의 일관된 읽기를 보장할 수 있을까요?