개발자 포트폴리오에 기술 블로그를 붙이려 한다면

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

프로젝트를 보여 주는 개발자 포트폴리오와 개발 과정을 기록하는 기술 블로그를 함께 운영하려는 순간, 의외로 까다로운 선택을 만나게 됩니다. 같은 도메인 안에 블로그를 넣을 것인가, 별도 도메인으로 분리할 것인가의 문제입니다. 화면 디자인만 보면 사소한 차이처럼 보이지만 검색 노출, 배포 방식, 유지보수 비용, 방문자의 이동 경로까지 달라집니다.

예를 들어 andrey-vasiliev.com/blog처럼 한곳에 합치면 방문자가 프로젝트와 글을 연속해서 살펴보기 쉽습니다. 반대로 독립된 블로그 도메인은 특정 기술 주제를 깊게 확장하거나 서로 다른 프레임워크를 실험하기에 유리합니다. 어느 쪽이 절대적으로 낫다기보다, 포트폴리오가 해결해야 할 목적과 앞으로 감당할 운영 범위를 먼저 따져야 합니다.

같은 도메인 vs 별도 도메인, 검색과 인상부터 달라집니다

한 도메인은 경력의 맥락을 한데 모읍니다

같은 도메인에 기술 블로그를 배치하면 프로젝트 페이지, 소개 페이지, 기술 문서가 하나의 경력 서사를 만듭니다. 채용 담당자가 JavaScript 프로젝트를 본 뒤 관련 회고 글로 이동하고, 다시 GitHub 저장소나 라이브 데모를 확인하는 흐름을 설계하기 쉽습니다. 개발 결과와 판단 과정을 같은 브랜드 아래 연결한다는 점이 가장 큰 장점입니다.

검색 관점에서도 내부 링크를 집중할 수 있습니다. PHP 성능 개선 사례에서 해당 프로젝트 페이지를 연결하고, 프로젝트 페이지에서는 Linux 배포 기록을 안내하면 사이트 내부의 관련성이 선명해집니다. 포트폴리오라는 개념 자체가 작업물과 역량을 선별해 제시하는 방식임을 이해하려면 Portfolio 용어 설명도 참고할 만합니다. 단순히 글을 많이 모으는 것보다 무엇을 어떤 맥락으로 엮느냐가 중요합니다.

• 브랜드 집중: 이름, 프로젝트, 개발 기록이 하나의 검색 결과군을 형성하기 쉽습니다.
• 방문 동선 단축: 메뉴와 내부 링크만으로 글과 결과물을 오갈 수 있습니다.
• 운영 단순화: 분석 도구, 검색 콘솔, 쿠키 정책과 디자인 시스템을 공유할 수 있습니다.
• 주의점: 블로그 글의 품질이나 주제가 들쭉날쭉하면 포트폴리오 전체의 전문성도 흐려질 수 있습니다.

별도 도메인은 콘텐츠 실험의 자유를 줍니다

별도 도메인은 기술 블로그가 하나의 독립 매체로 성장할 가능성이 클 때 강합니다. 개인 포트폴리오는 간결한 정적 사이트로 유지하면서 블로그에는 검색, 댓글, 뉴스레터, 다국어 기능을 붙일 수 있습니다. 포트폴리오는 Astro로, 블로그는 Next.js나 별도의 CMS로 운영하는 식으로 기술 선택을 분리하기도 편합니다.

그러나 방문자에게는 두 사이트가 서로 다른 주체처럼 보일 수 있습니다. 이름, 프로필 사진, 소개 문구, 대표 색상과 탐색 메뉴가 일치하지 않으면 블로그에서 확인한 전문성이 포트폴리오로 자연스럽게 이어지지 않습니다. 새 도메인의 인지도와 콘텐츠 축적도 처음부터 시작해야 하므로 분리 자체가 SEO 상승을 보장하지는 않습니다.

• 독립 출판물이나 커뮤니티로 확장할 계획이 분명하다면 별도 도메인이 유리합니다.
• 포트폴리오와 전혀 다른 독자층을 겨냥한다면 콘텐츠 경계를 분명히 할 수 있습니다.
• 두 사이트의 작성자 정보와 상호 링크를 일관되게 유지할 운영 여력이 필요합니다.

도메인을 고르기 전에 “이 글을 읽은 사람이 다음으로 봐야 할 것은 무엇인가?”를 먼저 적어 보세요. 답이 항상 내 프로젝트라면 같은 도메인이 자연스럽고, 독립적인 연재와 구독이라면 분리가 설득력을 얻습니다.

구현 난이도는 URL보다 배포 구조에서 벌어집니다

통합형은 하나의 저장소와 모노레포로 다시 갈립니다

같은 도메인을 택했다고 해서 반드시 하나의 코드베이스를 써야 하는 것은 아닙니다. 포트폴리오와 블로그를 한 애플리케이션의 라우트로 구성할 수도 있고, 서로 다른 앱으로 만든 뒤 프록시나 호스팅 규칙을 이용해 /blog 경로에 붙일 수도 있습니다. 전자는 개발 환경이 단순하지만 블로그 기능을 바꿀 때 전체 빌드에 영향을 줄 수 있고, 후자는 기술 선택이 자유로운 대신 라우팅과 캐시 설정이 복잡해집니다.

JavaScript 기반 정적 사이트라면 Markdown 또는 MDX 글을 저장소에 두고 빌드 시 HTML로 변환하는 방식이 관리하기 편합니다. 코드 예제, 프로젝트 카드, 성능 그래프 같은 컴포넌트를 글 안에서 재사용할 수 있기 때문입니다. 다만 MDX는 표현력이 높은 만큼 글이 특정 프레임워크 컴포넌트에 묶일 수 있으므로, 제목·본문·날짜·태그 같은 핵심 데이터는 가능한 한 이식 가능한 형태로 남겨야 합니다.

분리형은 숨은 운영비를 계산해야 합니다

별도 사이트의 직접 비용은 무료 호스팅 구간을 활용하면 작아 보입니다. 하지만 도메인 갱신료, 유료 CMS 요금, 이미지 저장 공간, 빌드 시간, 이메일 발송 서비스가 추가되면 매달 비용이 늘어날 수 있습니다. 더 큰 비용은 돈보다 관리 시간입니다. 보안 업데이트, 깨진 링크 검사, 분석 스크립트 변경과 개인정보 처리 문구를 두 번 확인해야 하기 때문입니다.

특히 PHP나 오래된 Zend Framework 프로젝트를 포트폴리오로 소개하면서 최신 JavaScript 블로그를 별도 운영한다면 배포 환경을 섞지 않는 편이 안전할 수 있습니다. 반면 소개 페이지와 글 모두 정적 결과물이라면 굳이 서버를 둘로 나눌 이유가 적습니다. 새 기술을 써 보고 싶다는 욕구와 실제 운영상 필요한 분리를 구별해야 합니다.

1. 현재 포트폴리오의 빌드 시간과 배포 실패 빈도를 기록합니다.
2. 블로그에 댓글, 회원 기능, 검색처럼 서버가 필요한 기능이 있는지 구분합니다.
3. 두 서비스를 따로 업데이트할 시간을 월 단위로 계산합니다.
4. 한쪽 서비스가 중단돼도 다른 쪽을 반드시 유지해야 하는지 판단합니다.
5. 콘텐츠를 다른 시스템으로 옮길 때 Markdown 원문을 그대로 쓸 수 있는지 시험합니다.

채용 담당자와 검색 방문자는 서로 다른 길을 걷습니다

채용 담당자에게는 짧은 증명 경로가 필요합니다

채용 담당자는 모든 글을 읽기보다 특정 프로젝트가 어떤 문제를 해결했고 지원자가 어떤 결정을 내렸는지 빠르게 확인하려 합니다. 따라서 통합형 포트폴리오에서는 프로젝트마다 관련 기술 글을 두세 편만 선별해 연결하는 편이 좋습니다. “블로그 전체 보기”만 제공하면 방문자가 수십 개의 글 사이에서 증거를 직접 찾아야 합니다.

별도 도메인을 사용한다면 링크 옆에 목적을 적어야 합니다. 단순히 “기술 블로그”라고 쓰기보다 “NoSQL 데이터 모델 변경 회고”나 “Linux 배포 자동화 과정”처럼 얻을 수 있는 정보를 보여 주세요. 작업물을 체계적으로 제시하는 포트폴리오의 의미는 포트폴리오 개념 설명에서도 확인할 수 있으며, 개발자에게는 완성 화면뿐 아니라 문제 해결 과정까지 선별 대상이 됩니다.

• 프로젝트 상단: 역할, 기간, 사용 기술, 핵심 성과를 한 화면에 배치합니다.
• 프로젝트 중단: 주요 설계 결정과 연결되는 글 한 편을 안내합니다.
• 프로젝트 하단: 저장소, 데모, 장애 회고처럼 검증 가능한 자료를 구분합니다.
• 외부 블로그 링크: 새 창 표시만 믿지 말고 외부 사이트로 이동한다는 사실을 문구로 알립니다.

검색 방문자에게는 다음 질문을 준비해야 합니다

검색으로 들어온 독자는 작성자의 경력보다 당장 겪고 있는 오류나 구현 문제가 궁금합니다. 예를 들어 “JavaScript 메모리 누수 추적”을 검색한 사람에게 첫 문단부터 자기소개를 길게 보여 주면 이탈하기 쉽습니다. 먼저 재현 조건과 해결 방법을 제공한 뒤, 글에서 사용한 접근이 실제 프로젝트에서 어떤 결과를 냈는지 연결하는 편이 자연스럽습니다.

같은 도메인에서는 관련 글과 프로젝트를 내부 링크로 촘촘하게 연결하되, 모든 문장에 키워드를 반복해서는 안 됩니다. 별도 도메인에서는 두 사이트 사이의 링크 수를 무작정 늘리기보다 문맥이 맞는 대표 페이지끼리 연결해야 합니다. 개발자 포트폴리오, software projects, JavaScript developer 같은 표현도 독자의 질문에 답하는 문장 안에서만 사용해야 읽는 흐름이 살아납니다.

1. 검색 독자가 입력했을 법한 질문을 글마다 하나만 정합니다.
2. 첫 300자 안에 문제 조건과 글에서 얻을 결과를 제시합니다.
3. 코드 예제에는 입력값, 예상 결과, 실패 조건을 함께 적습니다.
4. 관련 프로젝트 링크에는 클릭해야 할 이유를 한 문장으로 설명합니다.
5. 작성일만 표시하지 말고 마지막 검증일과 실행 환경을 기록합니다.

기술 글은 “내가 이것을 안다”는 선언보다 독자가 같은 결과를 재현하도록 돕는 문서에 가깝습니다. 실행 명령, 버전, 실패 사례가 포함될수록 포트폴리오의 신뢰도도 함께 올라갑니다.

다국어 사이트라면 경로 규칙도 미리 정해야 합니다. /ko/blog/와 /en/blog/처럼 언어별 경로를 명확히 나누고, 번역되지 않은 글을 자동 번역처럼 보이게 노출하지 않는 편이 좋습니다. 같은 글의 언어 버전은 제목과 설명을 각각 자연스럽게 작성하고, 메뉴를 바꿨을 때 현재 읽던 글과 대응하는 언어 페이지로 이동하도록 설계하면 방문자의 맥락이 끊기지 않습니다.

30분짜리 연결 실험으로 도메인 선택을 검증하세요

이동 경로 하나를 실제로 만들어 봅니다

아직 어느 쪽을 선택할지 모르겠다면 사이트를 전면 개편하지 말고 대표 프로젝트 하나로 작은 실험을 해보세요. 가장 자신 있는 프로젝트 페이지에 기술 글 한 편을 연결하고, 그 글에는 다시 프로젝트의 데모나 저장소로 돌아오는 링크를 넣습니다. 통합형을 고려한다면 임시 /blog 경로에서 만들고, 분리형을 고려한다면 현재 사용 가능한 별도 호스팅의 미리보기 주소로 구성하면 됩니다.

여기서 확인할 것은 디자인 취향이 아니라 이동의 명확성입니다. 처음 보는 사람이 프로젝트에서 글로 이동한 뒤 “왜 이 글을 읽어야 하는지”, “이 글이 어느 프로젝트와 연결되는지”, “다음에 무엇을 확인해야 하는지”를 이해할 수 있어야 합니다. 포트폴리오는 무조건 많은 작업을 쌓아 두는 창고가 아니라 목적에 맞게 선별한 결과물이라는 관점은 포트폴리오 관련 정의와 함께 살펴보면 선택 기준을 세우는 데 도움이 됩니다.

• 프로젝트 페이지에서 관련 글 링크를 찾는 데 10초 이상 걸리지는 않는지 봅니다.
• 글을 직접 열었을 때 작성자와 소유 프로젝트를 즉시 알 수 있는지 확인합니다.
• 모바일 화면에서도 데모, 저장소, 본문 링크의 우선순위가 분명한지 점검합니다.
• 외부 도메인으로 이동할 때 글꼴과 색상이 달라도 동일한 작성자라는 신호가 있는지 살핍니다.
• 분석 도구에서 프로젝트→글→데모의 이동을 개별 이벤트로 측정할 수 있는지 확인합니다.

선택 기준은 확장 계획보다 실제 운영 습관에 둡니다

매주 글을 쓰고 기술 주제별 시리즈를 꾸준히 확장한다면 별도 블로그가 독립 매체로 성장할 여지가 있습니다. 반대로 프로젝트를 완성할 때마다 회고와 설계 기록을 한두 편 추가하는 방식이라면 같은 도메인의 통합 구조가 효율적입니다. 언젠가 뉴스레터와 커뮤니티를 만들 수도 있다는 막연한 계획보다 지난 석 달간 실제로 얼마나 기록했는지를 기준으로 삼는 편이 정확합니다.

통합형을 택했다면 첫 행동은 거대한 CMS 설치가 아닙니다. 대표 프로젝트 페이지에 ‘설계 결정 읽기’ 링크를 하나 추가하고, 연결되는 글의 첫 문단에 프로젝트명·문제·측정 결과를 명시하세요. 분리형을 택했다면 같은 위치에 설명이 포함된 외부 링크를 달고, 블로그 프로필에서 포트폴리오로 돌아오는 경로를 마련해야 합니다.

1. 지금 가장 설명하기 쉬운 프로젝트 하나를 고릅니다.
2. 그 프로젝트에서 내린 중요한 기술 결정 하나를 800자 내외로 작성합니다.
3. 프로젝트와 글 사이에 양방향 링크를 배치합니다.
4. 동료 한 명에게 링크만 보내고 3분 동안 이동해 보게 합니다.
5. 어디서 길을 잃었는지 확인한 뒤 도메인 분리 여부를 결정합니다.

지금 바로 할 행동은 대표 프로젝트 한 개를 열어 관련 기술 글로 이어지는 링크 한 줄을 추가하는 것입니다. 이 작은 연결이 자연스럽게 작동하면 같은 도메인 전략에 힘이 실리고, 서로 다른 독자와 기능이 충돌한다면 별도 도메인이 필요한 이유도 구체적으로 드러납니다.