이야기를 디버깅하는 개발자.

개발과 창작 사이에서, 사람들이 자기만의 이야기를 만들 수 있는 도구와 기록을 만듭니다.

roslyn.dev 자세히보기

전체 글 176

MCP Tasks로 장시간 작업 상태를 설계하는 법

AI 도구 호출이 짧을 때는 요청과 응답만 있으면 충분합니다. 하지만 파일 변환, 배포, 대량 분석처럼 오래 걸리는 작업은 사용자가 기다리는 동안 상태를 확인하고, 중단하거나 다시 이어야 합니다.MCP 생태계에서 Tasks와 관련된 논의가 확장되고 있지만 사양과 구현은 계속 변할 수 있습니다. 이번 글은 특정 SDK의 복사 예제가 아니라 장시간 작업을 설계할 때 필요한 상태를 정리하는 글입니다.작업 상태와 결과를 분리합니다작업이 실행 중이라는 사실과 결과 파일이 준비됐다는 사실은 다릅니다. 상태 조회는 진행률·마지막 업데이트·실패 이유를 보여 주고, 결과 조회는 완료된 산출물의 위치와 검증 상태를 보여 줘야 합니다.저는 작업을 만들 때 사용자에게 보이는 상태와 내부 실행 상태를 따로 둡니다. 내부가 여러..

1인 서비스의 OpenTelemetry Collector export topology

OpenTelemetry를 처음 붙일 때 애플리케이션에서 로그·메트릭·트레이스를 원하는 백엔드로 바로 보내면 간단해 보입니다. 하지만 백엔드를 바꾸거나 샘플링·필터링을 조정할 때 애플리케이션을 다시 배포해야 합니다.혼자 운영하는 서비스에서도 Collector를 둘 가치가 있는지 판단하기 위해서는 멋진 다이어그램보다 데이터가 어디에서 사라질 수 있는지를 먼저 봐야 합니다. 이번 글에서는 최소 구성의 책임 경계를 정리합니다.세 신호는 서로 다른 질문에 답합니다트레이스는 한 요청이 어디를 지나갔는지 알려 주고, 메트릭은 시스템이 얼마나 바쁜지 보여 주며, 로그는 특정 사건의 맥락을 설명합니다. 셋을 모두 수집한다고 자동으로 장애 원인을 찾을 수 있는 것은 아닙니다.저는 알림에는 메트릭을, 원인 추적에는 트레이..

Next.js Server Actions와 캐시 무효화 — revalidatePath와 revalidateTag를 함께 설계하기

Server Actions로 폼 제출과 데이터 변경 코드를 가까이 둘 수 있지만, 저장이 끝난 뒤 화면이 왜 갱신되지 않는지는 별도의 문제입니다. 서버 데이터, 전체 경로, 브라우저 라우터 캐시가 서로 다른 층에 있기 때문입니다.이번 글에서는 액션을 도입하는 방법보다 액션 이후 어떤 캐시를 언제 무효화할지에 집중합니다. 문서 버전과 현재 App Router 동작은 발행 전에 다시 확인해야 합니다.Server Action은 서버 함수이지만 권한 경계가 아닙니다Server Action은 서버에서 실행되고 POST로 호출되지만, 호출된 함수 안에서 인증과 권한을 다시 확인해야 합니다. 화면에서 버튼을 숨겼다고 해서 사용자가 해당 액션을 호출할 수 없게 되는 것은 아닙니다.저는 액션의 첫 부분에서 세 가지를 확..

카테고리 없음 2026.10.02

React 19.2 Activity와 useEffectEvent를 실제 화면에 적용할 때의 기준

React의 새 기능을 보면 기존 컴포넌트를 모두 바꾸고 싶어집니다. 그러나 화면이 빨라질지, 효과의 생명주기가 더 이해하기 쉬워질지는 코드의 사용 맥락에 따라 다릅니다.React 19.2에서 소개된 Activity와 useEffectEvent는 숨겨진 화면과 효과 이벤트를 다루는 선택지를 넓혀 줍니다. 이 글은 API 사용법을 나열하기보다 어떤 화면에 적용하고 어떤 화면에는 적용하지 않을지에 초점을 둡니다.Activity는 숨겨진 화면의 생명주기를 명시합니다조건부 렌더링은 보이지 않는 화면을 언마운트하는 단순한 방법입니다. Activity의 hidden 모드는 화면을 유지하면서 효과를 중단하고 업데이트를 늦출 수 있어, 다시 돌아올 가능성이 높은 화면의 상태를 보존하는 데 유용할 수 있습니다.하지만 모..

EF Core 11 Complex Types·FullJoin 프리뷰를 도입하기 전 검증 항목

ORM의 새 기능은 샘플 코드에서는 쉽게 동작하지만, 실제 서비스에서는 모델·데이터베이스·마이그레이션·쿼리 번역이 함께 움직여야 합니다. 특히 EF Core 11처럼 개발 중인 버전은 기능 목록보다 호환성 확인이 먼저입니다.이번 글에서는 Complex Types와 FullJoin 같은 기능을 바로 채택하자는 이야기가 아니라, 적용 여부를 판단하기 위해 어떤 실험을 해야 하는지 정리합니다. 테스트 환경과 버전은 글을 읽는 시점에 다시 확인해야 합니다.기능 이름보다 지원 범위를 고정합니다새 기능을 읽을 때는 무엇이 가능한지보다 어떤 데이터베이스와 런타임에서 가능한지 먼저 기록합니다. EF Core 11은 .NET 11 SDK와 런타임을 요구하는 개발 중 버전이므로, 기존 서비스가 사용하는 타깃 프레임워크와 ..

ASP.NET Core Rate Limiting 정책을 API 비용과 공정 사용량에 맞추는 법

API에 제한을 붙일 때 가장 먼저 떠오르는 문장은 ‘분당 몇 번 허용할까’입니다. 하지만 같은 분당 열 번이라도 읽기 요청과 파일 변환 요청의 비용은 다릅니다. 제한값 하나를 정하기 전에 정책의 목적을 분리해야 합니다.이번 글에서는 ASP.NET Core의 Rate Limiting 미들웨어를 특정 값의 정답이 아니라 정책 선택 도구로 읽어 보겠습니다. 실제 값은 부하 테스트와 사용자 행동을 보고 조정해야 합니다.제한의 목적을 네 가지로 나눕니다Rate Limiting은 악성 요청만 막는 기능이 아닙니다. 공정 사용량을 보장하고, 백엔드 자원을 보호하고, 외부 비용을 통제하고, 동시 작업 수를 제한하는 데 사용할 수 있습니다. 목적이 다르면 관찰할 지표와 실패 응답도 달라집니다.저는 엔드포인트마다 ‘무엇..

.NET 11 Runtime Async를 기존 async/await와 비교해 본 체크리스트

새 런타임 기능을 보면 곧바로 기존 프로젝트에 적용해 보고 싶어집니다. 하지만 운영 서비스에서는 기능이 빠르다는 기대보다 빌드·디버깅·라이브러리 호환성·롤백이 먼저입니다..NET 11의 Runtime Async는 이 글을 쓰는 시점에 프리뷰 문서에서 확인되는 기능입니다. 정식 출시 전까지 사양이 바뀔 수 있으므로, 아래 내용은 도입 권고가 아니라 실험 범위를 정하는 체크리스트로 읽어 주시기 바랍니다.프리뷰 기능은 서비스와 격리해 확인합니다첫 실험은 운영 코드의 브랜치가 아니라 작은 샘플 프로젝트에서 시작합니다. 동일한 SDK와 런타임을 사용하고, 기존 async/await 코드와 새 방식의 호출 경로를 나란히 둡니다. 결과가 다르면 어느 계층에서 달라졌는지 추적할 수 있어야 합니다.실험 환경에는 프로젝트..

베타 사용자 인터뷰를 이슈로 바꾸는 질문과 기록 방식

초기 서비스의 사용자는 ‘좋아요’라고 말해 주지만, 그 말만으로 무엇을 고쳐야 하는지는 알기 어렵습니다. 반대로 불편했다는 말도 어떤 상황에서 어떤 결과를 기대했는지 모르면 기능 목록으로 바뀌지 않습니다.이번 글에서는 베타 사용자 인터뷰를 제품 이슈로 변환하는 흐름을 기록합니다. 인터뷰의 목적은 좋은 아이디어를 많이 받는 것이 아니라, 반복해서 나타나는 문제를 작게 재현하는 데 있습니다.질문은 의견보다 최근 행동을 묻습니다‘어떤 기능이 필요합니까?’라는 질문은 상상 속 요구를 만듭니다. 저는 ‘최근에 이 작업을 언제 했습니까’, ‘그때 어디에서 막혔습니까’, ‘문제를 해결하려고 무엇을 했습니까’를 먼저 묻습니다. 실제 행동이 있어야 문제의 맥락을 알 수 있습니다.인터뷰 대상이 서비스를 사용하지 않았다면 ..

원고와 사진 파일의 버전·백업 정책을 직접 만든 기록

백업은 파일을 복사하는 일이라고 생각하기 쉽습니다. 하지만 복사본이 어디에 있는지 모르거나, 최신 버전인지 확인할 수 없거나, 복구해 본 적이 없다면 위기 때 백업은 존재하지 않는 것과 비슷합니다.저는 원고와 사진을 동시에 다루면서 파일의 종류보다 복구 시나리오를 먼저 정했습니다. 이번 글에서는 비용이 큰 시스템보다 혼자 유지할 수 있는 백업 정책을 설명합니다.원본·공개 자산·백업을 분리합니다작업 폴더에는 편집 중인 원본과 업로드용 변환 파일이 함께 생깁니다. 이 둘을 백업할 때 같은 폴더에 넣으면 무엇을 보존해야 하는지 모호해집니다. 저는 원본, 공개 자산, 백업을 저장 위치와 키 구조에서 구분합니다.원본은 수정 이력을 보존하고, 공개 자산은 다시 만들 수 있도록 생성 정보만 남깁니다. 백업은 현재 폴..

회원가입 없는 서비스의 스팸 방지 최소 장치

회원가입을 요구하지 않는 서비스는 진입 장벽이 낮다는 장점이 있습니다. 대신 한 사람이 반복 요청을 보내도 누구인지 구분하기 어렵고, 공격과 정상 사용을 구분할 정보가 부족합니다.저는 처음부터 복잡한 인증을 붙이기보다 서비스가 감당할 수 있는 행동의 범위를 정했습니다. 이번 글에서는 경로별 제한, 사용자 식별, 실패 응답, 관찰 지표를 최소 구성으로 나눠 보겠습니다.막아야 할 행동을 먼저 정의합니다스팸은 사용자라는 사람이 아니라 행동의 패턴으로 나타납니다. 짧은 시간에 같은 요청을 반복하거나, 파일 크기가 비정상적으로 크거나, 실패한 요청만 계속 보내는 식입니다. 무엇을 막을지 정하지 않고 방어 도구부터 붙이면 정상 사용도 함께 막힙니다.저는 엔드포인트마다 비용과 피해를 적습니다. 읽기 요청과 데이터 생..

반응형