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"],