https://iamkanguk97.github.io/Backend Engineer Jason의 일상과 생각을 기록하는 블로그. 2026-04-08T09:25:15+09:00 Jason https://iamkanguk97.github.io/ Jekyll © 2026 Jason /assets/img/favicons/favicon.ico /assets/img/favicons/favicon-96x96.png 2026-04-07T21:20:00+09:00 2026-04-07T21:20:00+09:00 https://iamkanguk97.github.io/posts/checklist-for-small-side-projects/ Jason

작은 프로젝트일수록 빨리 만들고 싶어서 구조를 생략하기 쉽습니다. 그런데 초반에 기준을 몇 개만 적어 두면 오히려 속도가 더 잘 붙습니다. 시작 전에 적는 것 이 프로젝트가 해결하려는 문제 한 줄 첫 주 안에 만들 최소 기능 버릴 수 있는 기능과 남길 기능 왜 도움이 되나 작은 프로젝트는 기능보다 집중력이 먼저 무너지기 쉽습니다. 그래서 해야 할 일보다 하지 않을 일을 정해 두는 편이 실제 완성률을 더 높여 줍니다. 메모 습관 README나 이슈 하나만 있어도 충분합니다. 중요한 건 완벽한 문서가 아니라, 다음 작업으로 바로 이어질 수 있는 기준입니다.

2026-04-07T09:00:00+09:00 2026-04-07T09:00:00+09:00 https://iamkanguk97.github.io/posts/starting-a-github-pages-blog/ Jason

GitHub Pages와 Jekyll 조합은 개인 블로그를 빠르게 공개하고, 유지 비용을 낮게 가져가기 좋은 선택입니다. 저장소에 글을 커밋하면 배포까지 자연스럽게 이어지기 때문에 글 쓰는 흐름이 끊기지 않습니다. 왜 이 조합이 좋은가 정적 사이트라 속도가 빠릅니다. Git으로 글과 구조를 함께 관리할 수 있습니다. 테마에 의존하지 않아도 레이아웃을 직접 제어하기 쉽습니다. 기본 흐름 저장소를 만들고 Jekyll 파일 구조를 준비합니다. _posts 아래에 날짜 형식의 마크다운 글을 추가합니다. GitHub Pages를 활성화하고 배포 소스를 지정합니다. 이 블로그에 적용한 방향 이번 블로그는 기본 테마를 그대로 쓰지 않고, 첫 화면에서 블로그의 성격이 분명히 보...

2026-04-07T07:40:00+09:00 2026-04-07T07:40:00+09:00 https://iamkanguk97.github.io/posts/api-boundaries-need-validation/ Jason

백엔드에서 문제가 커지는 지점은 대개 비즈니스 로직 한가운데보다 입력 경계에서 시작됩니다. 요청 형식이 조금만 어긋나도 이후 흐름 전체가 모호해지기 때문입니다. 먼저 막아야 하는 것 타입이 다른 입력 필수 값 누락 허용 범위를 벗어난 값 그 다음에 판단할 것 검증은 많이 할수록 좋은 일이 아니라, 책임이 어디까지인지 분명해야 좋은 일입니다. 컨트롤러에서는 형식과 계약을 검증하고, 서비스 레이어에서는 도메인 규칙을 검증하는 식으로 경계를 나누면 유지보수가 쉬워집니다. 기록해 둘 기준 한 번 정한 검증 기준은 문서보다 코드에 드러나는 편이 좋습니다. DTO, 예외 메시지, 테스트 이름에 같은 기준이 드러나면 팀 전체의 판단이 빨라집니다.

2026-04-06T22:10:00+09:00 2026-04-06T22:10:00+09:00 https://iamkanguk97.github.io/posts/logs-that-help-in-production/ Jason

운영 로그는 개발 중 출력하던 콘솔 메시지와 목적이 다릅니다. 나중에 원인을 좁혀야 하는 사람을 위한 정보여야 하고, 하나의 요청 흐름을 따라갈 수 있어야 합니다. 남기면 좋은 정보 요청을 구분할 수 있는 ID 사용자 행동이나 리소스 식별자 실패 원인과 상태 코드 피하고 싶은 로그 설명 없는 성공 메시지, 너무 긴 객체 전체 출력, 문맥 없이 반복되는 에러는 오히려 읽는 속도를 늦춥니다. 로그는 기록이 아니라 검색 가능한 단서에 가까워야 합니다. 작은 기준 문제가 생겼을 때 “이 로그 한 줄로 다음 추적 지점을 알 수 있는가”를 기준으로 보면 대부분의 로그 품질이 빠르게 좋아집니다.

2026-04-06T20:00:00+09:00 2026-04-06T20:00:00+09:00 https://iamkanguk97.github.io/posts/designing-a-blog-readers-enjoy/ Jason

개발 블로그는 정보가 중심이지만, 정보만으로 충분하지는 않습니다. 독자는 첫 화면에서 이 블로그가 읽을 가치가 있는지 아주 빠르게 판단합니다. 좋은 인상은 구조에서 시작한다 디자인을 세련되게 보이게 만드는 핵심은 장식보다 구조입니다. 제목, 요약, 메타 정보, 링크가 어디에 어떤 밀도로 놓이는지가 먼저 정리되어야 합니다. 읽기 좋은 블로그는 화려해서가 아니라, 다음 행동이 자연스럽게 이어지도록 설계되어 있습니다. 이번 레이아웃에서 신경 쓴 부분 헤더를 가볍게 고정해 이동이 편하도록 만들었습니다. 첫 화면에 블로그의 성격과 최근 글을 동시에 보여줍니다. 카드, 버튼, 타이포그래피 리듬을 통일해 산만함을 줄였습니다. 디자인의 목적 코드를 잘 정리하는 것과 글을 잘 읽히게 ...