diff --git a/public/img/project/blog.png b/public/img/project/blog.png
new file mode 100644
index 0000000..b6a0ab8
Binary files /dev/null and b/public/img/project/blog.png differ
diff --git a/src/app/_components/HistorySection/index.tsx b/src/app/_components/HistorySection/index.tsx
index 21a38b6..2b17a19 100644
--- a/src/app/_components/HistorySection/index.tsx
+++ b/src/app/_components/HistorySection/index.tsx
@@ -21,7 +21,7 @@ const HistorySection = () => {
>
@@ -41,7 +41,7 @@ const HistorySection = () => {
diff --git a/src/constants/interviews.ts b/src/constants/interviews.ts
index d5a0124..90ab6c6 100644
--- a/src/constants/interviews.ts
+++ b/src/constants/interviews.ts
@@ -1,36 +1,41 @@
export const INTERVIEWS = [
{
- question: "Q. 개발자를 시작하게 된 계기가 무엇인가요?",
- answer: `A. 사용자의 불편함을 해결하며 서비스와 함께 성장하는 과정에 매료되었습니다.
-
-내가 작성한 코드가 실제 서비스가 되어 사용자의 불편함을 해소하고, 그 과정에서 저 또한 어제보다 성장한다는 사실에 큰 성취감을 느낍니다. 이러한 즐거움 덕분에 팀 프로젝트 '침플래닛'부터 디스코드 봇, 웹소켓 채팅 구현, 그리고 현재 운영 중인 '메이플 헬퍼'까지 다양한 서비스를 주도적으로 개발해 왔습니다. 특히 출시 후 유저들의 피드백을 반영해 서비스를 지속적으로 개선하고 확장해 나가는 과정에서 개발자로서 가장 큰 희열을 느낍니다.`,
- },
- {
- question: "Q. 프로젝트를 하면서 가장 인상 깊었던 상황을 말해주세요",
- answer: `A. '메이플 헬퍼'를 리팩토링하며 기술적 이상과 현실적인 서비스 운영 사이의 균형을 배웠습니다.
-
-초기에는 기술 부채를 완벽하게 없애고 싶어 전면적인 코드 수정을 시도했습니다. 하지만 작업 범위가 예상보다 훨씬 커지면서, 정작 중요한 서비스 확장은 멈춰버리는 시행착오를 겪었습니다.
-
-이 과정을 통해 리팩토링의 목적은 개발자의 자기만족이 아니라, 서비스의 지속 가능성에 있어야 함을 깨달았습니다. 완벽한 코드를 위해 모든 걸 뜯어고치기보다, 비즈니스 목표(수익화, 확장)에 치명적인 걸림돌이 되는 문제부터 해결하고 나머지는 과감하게 넘어가는 '이유 있는 리팩토링'을 실천하게 되었습니다.`,
- },
- {
- question:
- "Q. 개발 과정에서 마주쳤던 가장 까다로운 기술적 문제는 무엇이었으며, 어떻게 해결했나요?",
+ question: "Q. 성능 문제 해결 경험이 있나요?",
answer: `A. Next.js 기반 블로그를 개발하며 겪은 렌더링 성능 이슈입니다.
-
+
초기에는 클라이언트(런타임)에서 Markdown을 HTML로 변환하는 방식을 사용했습니다. 하지만 게시글이 늘어날수록 브라우저의 연산 비용이 급증했고, 목록 페이지 로딩에 평균 761ms가 소요되는 심각한 성능 저하가 발생했습니다.
-
+
이 문제를 해결하기 위해 변환 시점과 데이터 구조를 단계적으로 개선했습니다.
-
+
1. 1차 개선
변환 시점을 빌드 단계로 옮겨 미리 HTML과 메타데이터가 포함된 JSON을 생성했습니다. 로딩 시간은 24ms로 단축되었으나, HTML 본문이 포함된 거대 JSON으로 인해 불필요한 네트워크 트래픽이 발생하는 문제가 생겼습니다.
-
+
2. 2차 개선
본문(HTML)과 메타데이터(JSON)를 물리적으로 분리했습니다. 파일 용량 문제는 해결했지만, 모든 게시글의 정보를 하나의 posts.json에 담다 보니 게시글이 늘어날수록 메타데이터 파일 자체가 비대해지는 확장성 문제가 남았습니다.
-
+
3. 최종 개선
필요한 데이터만 가져올 수 있도록 메타데이터를 카테고리별/게시글별로 잘게 쪼개어 저장하는 구조로 변경했습니다.
-
+
결과적으로 목록 페이지 로딩 시간을 초기 761ms에서 20ms 내외로 약 97% 단축했습니다.`,
},
+ {
+ question:
+ "Q. 기존에 작성된 코드를 리팩토링할 때, 사이드 이펙트(부작용)를 방지하기 위해 어떤 전략을 취했나요?",
+ answer: `A. 리팩토링 전후의 동작이 동일하게 유지되도록 점진적으로 접근하는 것을 원칙으로 삼았습니다.
+
+비즈니스 로직과 UI 로직이 강하게 결합된 이른바 '스파게티 코드'를 분리할 때 한 번에 뜯어고치기보다 순수 함수로 분리할 수 있는 유틸리티 로직부터 독립시켰습니다.
+
+기능이 정상 작동하는지 수시로 확인하며 작은 단위로 커밋하여 문제가 발생했을 때 즉각적으로 롤백할 수 있는 안전망을 확보한 상태에서 작업을 진행했습니다.`,
+ },
+ {
+ question:
+ "Q. 코드의 완성도와 서비스 운영 사이에서 딜레마를 겪은 적이 있다면 어떻게 대처하셨나요?",
+ answer: `A. '메이플 헬퍼'를 리팩토링하며 기술적 이상과 현실적인 서비스 운영 사이의 균형을 배웠습니다.
+
+초기에는 기술 부채를 완벽하게 없애고 싶어 전면적인 코드 수정을 시도했습니다.
+하지만 작업 범위가 예상보다 훨씬 커지면서, 정작 중요한 서비스 확장은 멈춰버리는 시행착오를 겪었습니다.
+
+이 과정을 통해 리팩토링의 목적은 개발자의 자기만족이 아니라 서비스의 지속 가능성에 있어야 함을 배웠습니다.
+완벽한 코드를 위해 모든 걸 뜯어고치기보다 비즈니스 목표(수익화, 확장)에 치명적인 걸림돌이 되는 문제부터 해결하고 나머지는 과감하게 넘어가는 '이유 있는 리팩토링'을 실천하게 되었습니다.`,
+ },
];
diff --git a/src/constants/projects.ts b/src/constants/projects.ts
index c8a2982..a243e4c 100644
--- a/src/constants/projects.ts
+++ b/src/constants/projects.ts
@@ -30,9 +30,34 @@ export const PROJECTS: Project[] = [
],
image: "/img/project/maplehelper.png",
},
+ {
+ title: "개발 블로그",
+ period: "2023.09 - 진행중",
+ description:
+ "개발 경험의 기록과 기술적 역량 어필을 위해 직접 설계하고 운영하는 포트폴리오 겸 기술 블로그입니다.",
+ tech: ["Next.js", "TypeScript", "Tailwind CSS"],
+ links: [
+ {
+ icon: GithubSvg,
+ link: "https://github.com/spde3289/blog",
+ label: "FE",
+ },
+ {
+ icon: LinkSvg,
+ link: "https://www.spde3289.dev",
+ label: "배포 사이트",
+ },
+ {
+ icon: RssSvg,
+ link: ROUTES.BLOG.SERIES("blog"),
+ label: "회고",
+ },
+ ],
+ image: "/img/project/blog.png",
+ },
{
title: "팀 프로젝트: 글로벌 노마드",
- period: "2025.01 - 2024.02",
+ period: "2026.01 - 2026.02",
description:
"체험 상품의 탐색부터 예약, 관리까지 지원하는 통합 플랫폼입니다. 지도 및 캘린더 SDK를 적극 활용하여 직관적이고 편리한 사용자 경험(UX)을 구현하는 데 집중했습니다.",
tech: ["Next.js", "TanStack Query", "Zustand", "Tailwind CSS"],