오픈소스에 처음 기여하려고 하면 큰 기능부터 찾게 됩니다. 하지만 유지보수자가 반기는 기여는 작고 명확하며, 검토할 때 추가 질문이 적은 변경인 경우가 많습니다. 저도 처음에는 코드를 많이 바꾸는 것이 도움이 된다고 생각했습니다.이번 글에서는 문서 수정, 재현 가능한 이슈, 작은 코드 변경을 어떻게 고르고 준비할지 정리합니다. 실제 프로젝트마다 규칙이 다르므로, 아래의 절차를 그대로 복사하기보다 유지보수자의 시간을 줄이는 방향으로 적용하시기 바랍니다.첫 기여는 저장소의 사용 설명부터 읽습니다저장소의 README와 기여 안내는 단순한 예절 문서가 아닙니다. 브랜치 이름, 테스트 명령, 코드 스타일, 이슈 템플릿이 모두 들어 있습니다. 이 문서를 건너뛰면 작은 변경도 다시 설명해야 하는 일이 생깁니다.저는 ..

개발 프로젝트에서는 회고를 자주 하지만, 정작 내 생활은 기록하지 않는 경우가 많습니다. 저도 배포 성공률과 오류 수는 적어 두면서, 왜 글을 쓰지 못했는지는 ‘바빴다’로 넘겼습니다.생활 회고는 하루를 평가하는 일지가 아닙니다. 다음 주에 무엇을 하나 바꿀지 고르는 기록입니다. 이번 글에서는 일·체력·관계·창작을 함께 돌아볼 수 있는 일곱 가지 질문을 소개하겠습니다.질문은 사실과 해석을 분리해서 적습니다회고가 자책으로 흐르는 이유는 사건과 판단을 한 문장에 섞기 때문입니다. ‘이번 주는 엉망이었다’ 대신 실제로 일어난 일을 먼저 적습니다. 회의가 몇 번 있었는지, 몇 번 운동했는지, 언제 글을 썼는지처럼 관찰 가능한 사실을 남깁니다.그 다음 그 사실이 나에게 어떤 영향을 줬는지 적습니다. 해석은 바뀔 수..

퇴근 후 두 시간이 있어도 글을 쓰지 못하는 날이 있습니다. 몸이 피곤해서이기도 하지만, 더 자주 일어나는 이유는 업무가 끝났다는 신호가 없기 때문입니다. 메신저 알림을 확인하고 내일 할 일을 생각하다 보면 창작 시간은 이미 지나가 있습니다.저는 시간표를 더 촘촘하게 만드는 대신 경계를 만들었습니다. 언제까지 업무를 확인하고, 얼마나 회복한 뒤, 어떤 최소 작업을 할지 미리 정하니 창작을 못한 날에도 다시 돌아오는 길이 생겼습니다.창작 시간을 확보하기 전에 업무 종료 신호를 만듭니다업무용 프로그램을 닫는 것만으로는 머릿속 일이 닫히지 않습니다. 저는 퇴근 전에 미완료 업무를 세 줄로 적습니다. ‘다음에 할 일’, ‘기다리는 사람’, ‘내일 확인할 시각’입니다. 이 기록이 있어야 머릿속에서 계속 같은 일을..

경력이 쌓일수록 배워야 할 기술이 줄어들 것 같지만 실제로는 반대였습니다. 플랫폼은 계속 바뀌고, 예전에 선택한 라이브러리는 지원 종료를 맞습니다. 새로운 것을 배우는 일과 오래된 것을 정리하는 일이 동시에 들어옵니다.저는 이 문제를 ‘무엇을 더 공부할까’가 아니라 ‘무엇을 계속 들고 갈까’라는 질문으로 바꿔 보았습니다. 이번 글은 특정 기술을 버리라는 조언이 아니라, 개인 서비스와 커리어에서 우선순위를 정하는 방법입니다.기술 부채는 오래된 코드와 같은 말이 아닙니다오래되었다는 이유만으로 부채가 되는 것은 아닙니다. 오래된 코드라도 장애가 없고 수정 경로를 모두 알고 있다면 위험이 낮을 수 있습니다. 반대로 최신 라이브러리라도 팀이 이해하지 못하고 배포 때마다 불안하다면 부채가 됩니다.제가 쓰는 기준은 ..

혼자 만든 서비스를 운영하다 보면 새 기능을 만드는 일보다 이미 있는 기능을 설명하고 고치는 일이 더 많은 날이 옵니다. 저는 한동안 이 일을 모두 호의로 처리했습니다. 그러다 보니 사용자 한 명의 요청이 다음 주의 약속이 되고, 약속이 쌓일수록 정작 제품을 개선할 시간이 사라졌습니다.이번 글에서는 서비스를 접을지 말지의 문제가 아니라, 어떤 일만 남기고 어떤 요청은 계약 밖으로 둘지 정리한 과정을 적어보겠습니다. 금액을 정답처럼 제시하기보다 범위와 응답 기준을 먼저 세우는 방법에 집중합니다.유지보수와 신규 개발을 먼저 나눴습니다같은 코드베이스에서 나온 요청이라도 성격은 다릅니다. 오류를 원래 동작으로 되돌리는 일은 유지보수이고, 새로운 화면이나 업무 규칙을 추가하는 일은 신규 개발입니다. 둘을 같은 창..

연재 중이던 원고에서 조연 이름이 두 화 만에 바뀐 적이 있습니다. 제가 실수한 건 아니었고, AI에게 이어 쓰기를 시켰더니 설정집에 분명히 적혀 있는 이름 대신 비슷한 다른 이름을 써서 돌려준 겁니다. 그때 제가 넣은 프롬프트는 세계관 문서 전체를 복사해 붙인 것이었습니다. 분량으로는 원고 열 화쯤 되는 양이었습니다.설정집이 있으면 AI가 알아서 지켜줄 거라고 생각하기 쉽습니다. 그런데 실제로는 설정집을 많이 넣을수록 반영률이 떨어지는 구간이 생깁니다. 모델이 게을러서가 아니라, 넣은 정보 사이에 우선순위가 없어서 무엇이 중요한지 판단할 근거가 없기 때문입니다.메리톡톡을 만들면서 이 문제를 계속 붙들고 있었습니다. 결론은 단순했습니다. 설정집은 한 덩어리가 아니라 성격이 다른 세 종류의 정보이고, 그걸..

느리다는 문의를 받고 로그를 열었는데 아무것도 못 찾은 적이 있습니다. 로그에는 요청이 들어왔다는 줄과 응답을 보냈다는 줄이 있었고, 그사이에 무슨 일이 있었는지는 비어 있었습니다. 데이터베이스가 느렸는지, 외부 API가 늦게 답했는지, 제 코드가 오래 걸렸는지 구분할 방법이 없었습니다.로그 도구를 바꾼다고 해결되는 문제가 아니었습니다. 필요한 것은 하나의 요청이 어디를 거쳐 얼마나 걸렸는지 이어 보는 방법이었고, 그게 분산 추적입니다. .NET 11에서는 ASP.NET Core가 OpenTelemetry 태그를 네이티브로 방출하는 방향으로 가고 있어서, 이 부분을 다시 정리해볼 만한 시점이 됐습니다. 아래 .NET 11 관련 내용은 현재 프리뷰 기준이며 GA까지 바뀔 수 있습니다.세 축은 각자 답하는 ..

엔드포인트 목록을 열어놓고 하나씩 세어본 적이 있습니다. 화면 하나를 만들려고 라우트 파일을 만들고, 요청 타입을 정의하고, 클라이언트에서 부를 함수를 또 만들고, 응답 타입을 다시 선언하는 일이 반복되고 있었습니다. 실제 로직은 열 줄인데 그걸 감싸는 껍데기가 세 배쯤 됐습니다.Server Actions로 몇 개를 옮겨보기 시작한 건 그 목록을 본 다음이었습니다. 결론부터 말하면 절반쯤 옮겼고 나머지는 그대로 두었습니다. 이 글은 무엇을 옮겼고 무엇을 왜 남겼는지에 대한 기록입니다.옮기면서 실제로 줄어든 것가장 크게 체감한 것은 같은 타입을 두 번 쓰지 않아도 된다는 점이었습니다. 서버 함수를 직접 호출하는 형태가 되니 인자와 반환 타입이 그대로 이어집니다. 필드 이름을 바꿨을 때 컴파일 단계에서 잡히..

프로젝트에서 useMemo와 useCallback이 몇 개나 쓰이고 있는지 세어본 적이 있습니다. 생각보다 많았고, 더 문제는 그중 상당수가 왜 붙였는지 기억나지 않는 것이었습니다. 언젠가 성능이 걱정돼서 붙였고, 그 뒤로 아무도 건드리지 않은 코드였습니다.React Compiler가 자리를 잡으면서 이 코드들을 어떻게 할지 결정해야 하는 시점이 왔습니다. 컴파일러가 알아서 메모이제이션을 해준다면 손으로 붙인 것들은 중복입니다. 다만 전부 지우면 되는 것도 아닙니다. 여전히 손으로 남겨야 하는 자리가 있고, 그 구분을 모르고 일괄 삭제하면 조용히 느려지거나 이상하게 동작합니다.컴파일러가 해주는 일과 해주지 않는 일React Compiler는 컴포넌트와 훅을 분석해서 렌더 사이에 재사용할 수 있는 값을 자..

서버 지표를 보다가 이상한 장면을 만난 적이 있습니다. 트래픽은 그대로인데 CPU 사용률만 눈에 띄게 올라가 있었습니다. 원인을 좁혀보니 압축 설정을 바꾼 배포가 그 시점에 있었습니다. 응답 크기를 줄이려고 켠 옵션이 CPU를 대신 먹고 있었던 겁니다.응답 압축은 켜기만 하면 이득처럼 보이지만 실제로는 거래입니다. 네트워크로 나가는 바이트를 줄이는 대신 프로세서 시간을 씁니다. 이 거래가 이득인지 손해인지는 서비스마다, 심지어 엔드포인트마다 다릅니다..NET 11에서는 Zstandard 압축이 들어옵니다. Brotli에 준하는 압축률을 더 낮은 CPU 비용으로 얻는다는 성격의 알고리즘입니다. 이 글에서는 압축의 기본 거래 구조를 먼저 짚고, Zstandard가 1인 서비스에서 어떤 상황에 실익이 되는지,..