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 는 어떻게 동작할까요?
• 애초에 잠금을 사용했는데 다른 트랜잭션에서 읽기가 가능하긴 한 걸까요?
• 읽기 방식을 혼용해도 데이터의 일관된 읽기를 보장할 수 있을까요?

네트워크 패킷이란​

데이터를 네트워크로 전송하기 위해서는 어떻게 해야할까요? 상대방과 커넥션을 생성한 후, 데이터를 한 번에 보내는 방법이 가장 직관적인 방법일 겁니다. 하지만 이런 방법은 여러 요청을 처리해야할 때 비효율이 발생하는데요, 하나의 커넥션으로는 하나의 데이터 전송만 유지할 수 있기 때문입니다. 만약 큰 데이터가 전송되느라 커넥션이 길어진다면 다른 데이터들이 기다려야하겠죠.

네트워크는 데이터 전송 과정을 최대한 효율적으로 처리하기 위해 데이터를 여러 조각으로 나눈 후, 수신 측에서 조립하도록 했습니다. 이 조각난 데이터 구조체를 패킷이라고 부릅니다. 패킷에는 수신 측에서 데이터를 순서대로 조립할 수 있도록 여러 추가 정보를 포함하고 있습니다.

이렇게 여러 패킷으로 전송되면 패킷 스위칭을 통해 많은 요청을 효율적으로 처리할 수 있지만, 중간에 데이터가 유실되거나, 정확한 순서로 전달되지 않거나 하는 등의 다양한 에러를 만나게 될 수 있습니다. 우리는 이런 문제를 어떻게 디버깅해야 할까요? 🤔

Situation​

• 코드 베이스가 늘어나며 스프링 애플리케이션 실행에 필요한 설정값이 늘어나고 있음
• 대부분의 상황은 테스트 코드로 검증하지만, 로컬에서 bootRun 으로 테스트해보는 방법도 써야할 때가 있음

매우 비효율적이였던 기존 구현 방식을 설명하고, 개선하기 위해 시도한 방법들을 기록합니다.

"Write once, Test anywhere"

네이버에서 오픈소스로 개발되고 있는 테스트 객체 생성 라이브러리이다. 아마도 이름은 넷플릭스의 오픈소스, Chaos Monkey 에서 따온 듯하다. 랜덤으로 테스트 픽스처를 생성해주기 때문에, 실제로 카오스 엔지니어링을 하는 체험을 할 수 있다.

약 2년 전 처음 접한 이후, 가장 좋아하는 오픈소스 라이브러리 중 하나가 되었다. 어쩌다보니 글도 2편이나 썼다.

• Fixture Monkey 객체 생성 전략
• Fixture Monkey 0.4.x

이후로 버전이 변할 때마다 변경점이 너무 많아 추가적인 글을 안적고 있다가, 최근 1.x 가 릴리즈되었기에 새로운 마음으로 다시 소개글을 써본다.

이전 글에서는 Java 를 기준으로 글을 작성했지만, 최근 추세에 맞춰서 Kotlin 으로 작성한다. 글 내용은 공식 문서를 기반으로 실제 사용 후기를 좀 섞었다.