아임웹의 새로운 기술블로그를 소개합니다.

date

slug

author

status

tags(최대 3개)

summary

type

thumbnail

기술 브랜딩 기반 공사하기

DevRel 담당자로 합류하며 받은 미션은 분명했습니다. 아임웹의 기술 조직을 더 알리고, 인재 밀도를 높이는 것. 그래서 첫 일은 거창한 캠페인이 아니라, 그동안 취약했던 부분을 하나씩 들여다보고 직접 뜯어고치는 일이었습니다.

B2B SaaS 기업이 기술 브랜딩을 한다는 것 자체가 새로운 시도일 겁니다. 고객의 무게중심이 보통 기업과 세일즈에 있다 보니, 개발자를 향한 기술 브랜딩은 우선순위에서 밀리기 쉽습니다. 그래서 이걸 어디서부터 시작할지가 먼저 풀어야 할 질문이었습니다.

흔히 기술 브랜딩이라고 하면 외부 개발자를 초청하는 밋업이나 해커톤과 같은 행사를 떠올리기 쉬운데요. 언젠가 그런 자리도 열겠지만 그 전에 먼저 다져야 할 기반이 있었습니다.

이 글은 화려한 행사 이야기에 앞서 기술 브랜드를 떠받치는 기반 공사 이야기입니다.

기술 블로그는 곧 기술 조직의 포트폴리오

기술 블로그를 읽는 독자는 대부분 지원을 고민하는 개발자일텐데요. 컨퍼런스에서 발표를 듣고 검색해 본 사람부터 링크드인에서 리크루터의 글을 보고 들어온 사람까지 그들이 마주하는 회사의 첫 페이지가 곧 기술 브랜딩이 될 수 있습니다.

특히 인지도가 낮은 조직일수록 지원자는 이 회사 개발팀은 어떤 수준일까를 강하게 확인합니다. 사실상 공개된 기술 포트폴리오인 셈이죠.

플랫폼의 한계

아임웹은 그동안 블로그를 외부 플랫폼인 미디엄에서 운영해 왔습니다. 운영 측면만 보면 굉장히 편리한 플랫폼임은 틀림없어요. 다만 DevRel 담당자의 시선에선 한계가 또렷했습니다.

브랜드 인식: 기업 로고보다 더 눈에 띄는 플랫폼 로고

디자인 자유도: 채용·서비스 페이지와 톤 정렬 불가

데이터 분석: 제한적인 플랫폼 자체 분석툴

방문자 이탈: 채용·행사 안내 같은 동선 설계 불가

가장 큰 문제는 기술 블로그로 유입된 독자가 자연스럽게 채용 페이지와 서비스 페이지로 이어지는 흐름을 설계할 수 없다는 점이었습니다.

더 넓게 보면 다음과 같습니다.

첫째, 브랜드 자산이 플랫폼에 귀속됩니다. URL 구조, UI/UX, 추천 알고리즘, 검색 유입이 모두 플랫폼 중심이라, 콘텐츠는 우리가 만들지만 브랜드 경험은 플랫폼이 가져갑니다.

둘째, 검색 SEO 자산이 축적되지 않습니다. 장애 대응, Kubernetes 운영, 대규모 트래픽 처리 같은 키워드가 자체 도메인에 쌓이면 개발자 유입·채용 유입·기술 신뢰도가 함께 커지는데, 도메인 권한이 플랫폼에 있으면 그 효과가 제한됩니다.

콘텐츠는 우리가 만들지만, 브랜드 경험은 플랫폼이 가져갑니다. 이걸 되찾는 것이 자체 플랫폼의 출발점이었습니다.

자체 플랫폼 개발

새 어드민을 만들고 싶지는 않았습니다. 글 한 편을 발행하려고 익혀야 할 도구가 늘어나는 건, 회사 전체로 보면 마찰이기 때문입니다. 다행히 아임웹은 이미 Notion을 적극적으로 쓰고 있어요.

답은 단순했습니다. Notion을 CMS(Contents Managemanet System)로 쓰고, 빌드 시점에 정적 사이트로 떨어뜨려 자체 도메인에 호스팅하는 것이죠.

운영 리소스 0: 작성·편집·예약·이미지·작성자 표시 모두 Notion 활용

사이트·운영 모듈은 일반 Next.js 프로젝트: 채용 배너·이벤트 팝업·분석을 자유롭게 구현

도메인·데이터·디자인 전부 자체 통제

옵션을 비교해 보면 이 조합이 가장 합리적이었습니다.

옵션	도메인·디자인 통제	운영 리소스	시나리오 커스텀
미디엄·벨로그	❌	가장 낮음	❌
워드프레스 등 호스팅형 CMS	✅	새 어드민 학습	부분
자체 개발 + Notion CMS	✅	없음 (이미 Notion 사용 중)	✅

자체 플랫폼의 진짜 가치는 비용이 아닙니다.

카테고리 구조, 시리즈, 디자인, 콘텐츠 큐레이션, 조직 소개, 엔지니어 프로필, 아키텍처 페이지를 통해 우리가 어떤 문제를 중요하게 보고, 어떤 품질 기준과 의사결정을 갖는지 기술 조직의 세계관을 직접 보여줄 수 있다는 점입니다.

기술 스택과 요구사항

원하는 구조와 기능을 마크다운으로 정리해 Claude Code에 던졌습니다. 만들고 보니 구조는 단순했습니다.


[운영자]                  [빌드 시점]                  [방문자]
노션 DB ───── 30분 cron ──→ next build ──→ ./out ──→ GitHub Pages
              + push 트리거                              tech.imweb.me

데이터: notion-client(비공식 Notion API). 토큰 불필요, Publish to web으로 자동 페치

렌더:react-notion-x가 콜아웃·코드·수식·이미지 처리. 커스텀 스타일은 globals.css의 .notion 하위

빌드: Next.js 14 output: "export" 정적 HTML. 30분 cron으로 Notion 변경 자동 반영

호스팅: GitHub Pages + 커스텀 도메인 tech.imweb.me. CDN·인프라 비용 0원

이 구조의 장점은 운영자가 Notion만 보면서 사이트 자체는 일반 Next.js 프로젝트라 git으로 추적된다는 점입니다. 글 발행 흐름과 사이트 개선 흐름이 분리됩니다.

말 안하면 몰랐을 디테일 손보기

다크모드: 처음엔 '있으면 예쁜 기능' 정도로 생각했는데, 직접 개발하며 보니 하얀 배경은 눈이 실시간으로 건조해지는 게 느껴졌습니다. 이런 섬세함이 개발자 경험을 한 티스푼 정도 얹는 일이 아닐까요. 지금 이글을 읽으며 한번 써보세요.

카테고리와 태그: . Notion의 multi-select 속성을 그대로 매핑해, 한 글이 여러 카테고리에 속할 수 있습니다. 좁은 화면(< 1024px)에선 사이드바가 토글로 접히고, 펼치면 카테고리·태그가 2개 컬럼으로 나옵니다. 검색(/search?q=...)은 제목·요약·카테고리·태그를 substring으로 매칭합니다.

그리드와 리스트 뷰: DevRel 담당자로서 다른 기업의 블로그를 구경할 일이 많은데요. 간혹 데스크탑과 모바일 해상도가 맞지 않아 불편했던 경험이 있어, 유저를 고려해 그리드 뷰와 리스트 뷰를 함께 제공했습니다.

폭	적용
`< 640px`	카드 1열, 리스트 뷰 썸네일 숨김(텍스트 전용), 사이드바 토글
`640~1024px`	카드 2열, 리스트 뷰 썸네일 우측 배치, 사이드바 토글
`≥ 1024px`	좌측 사이드바(220px) + 본문, 카드 3열, 리스트 뷰 썸네일 우측

커스텀 기능

단순 플로팅 배너보다 효과적인 방법을 고민했습니다.

리본 배너(RecruitRibbon): 움직임(마퀴)으로 시선을 끌면서도 분문을 가리지 않음(채용 캠페인에 활용)

이벤트 팝업(EventPopup): 진입 순간 시선을 한 곳에 모아 CTA 전환 유도(밋업, 컨퍼런스 등에 활용)

둘 다 site.config.js의 토글로 켜고 끄며, 방문자의 닫기 선택은 localStorage에 보관됩니다(공용 useDismissible 훅). 단, 이벤트가 있을 때만 발생하는 만큼 운이 좋아야 볼 수 있으니, 자주 들러주세요.

단일 운영 설정 파일: site.config.js

자체 개발의 가장 큰 리스크는 그 사람만 고칠 수 있는 코드가 되는 것입니다. 그래서 운영 중 자주 바뀌는 모든 값을 한 파일(site.config.js)에 모았습니다.


const CONFIG = {
  blog: { title, description, siteUrl },
  notion: { databaseId },
  nav: [...],
  recruitCTA: { enabled, label, href },           // 하단 고정 채용 LED 마퀴
  eventPopup: { enabled, title, date, ctaHref },  // 메인 이벤트 모달
  analytics: { enabled, measurementId },          // GA4 측정 ID
  comments: { giscus: {...} },
}

채용 시즌이 시작되면 recruitCTA.enabled: true, 외부 행사 홍보가 필요하면 eventPopup로 간편하게 설정합니다. 미디엄에서 할 수 없었던 기능들을 한 개의 파일로 관리하는 거죠.

좋은 글이 계속 나오는 구조

블로그를 만들면서 신경썼던 부분은 지속적으로 좋은 글이 나오게 만드는 구조인데요. 좋은 사이트를 만들어도 글이 올라오지 않으면 의미가 없으니까요. 그래서 테크니컬 라이팅 가이드는 단순 문서 규칙이 아니라 기술 조직의 커뮤니케이션 품질 기준으로 잡았습니다.

가이드가 없으면 어떤 글은 지나치게 학술적이고, 어떤 글은 일기에 가깝고, 어떤 글은 맥락이 부족해, 결국 독자는 읽기 어렵다고 느끼게 됩니다. 가이드는 이 편차를 줄이고 작성 허들을 낮춥니다.

가이드가 하는 역할은 셋입니다.

같은 신뢰감 — 누가 쓰든 일관된 톤 유지

본질 집중 — 자주 부딪히는 결정의 사전 합의

공동 언어 — 작성자·리뷰어가 같은 기준으로 피드백

정해둔 톤은 한 줄로 요약됩니다.

차분하고 명료하게. 과장 없이 데이터로 말하고, 동료에게 설명하듯이.

가이드만 있으면 작성자가 매번 정독해야 하니, 가이드를 내장한 프롬프트도 함께 제공합니다. 작성자가 본인이 쓰는 AI에 그대로 붙여, 자가 검수가 끝난 초안을 던지면 가이드 기준으로 어색한 부분을 짚어주는 식입니다. AI가 글을 쓰는 게 아니라, 가이드를 작성자에게 한 번 더 비춰주는 역할입니다.

가이드는 내부에 먼저 적용했습니다. 글을 쓰기 시작하면 의사결정 기록, 기술 회고, 장애 분석, 지식 공유 문화가 함께 자랍니다. 좋은 기술 블로그는 결과이고, 실제 핵심은 조직의 문서화 문화입니다.

외부와의 접점 확대

플랫폼과 콘텐츠가 자리를 잡으면, 글을 읽고 흥미를 느낀 사람이 생깁니다. 발표를 같이 하고 싶거나, 오픈소스에 대해 묻고 싶거나, 함께 일해보고 싶은 사람입니다. 문제는 그때 이들이 우리와 연결될 길이 마땅치 않다는 것이었습니다. 블로그를 타고 들어온 사람이 자연스럽게 다음 행동으로 이어지려면, 누구에게 말을 걸어야 할지가 분명해야 합니다.

많은 조직이 가볍게 보지만, 이 외부와 연결되는 공식 접점이 실제로는 중요합니다. DevRel은 본질적으로 기술 조직과 외부 개발자의 관계를 관리하는 일인데, 공식 창구가 없으면 문의가 개인에게 오고, 담당자가 퇴사하면 이력이 유실되고, 히스토리가 흩어집니다.

그래서 전용 메일(tech@imweb.me)을 개설했습니다. 이 주소 하나가 발표 문의, 오픈소스 문의, 협업·밋업 제안, 파트너십의 허브가 됩니다. 동시에 우리는 외부 개발자와 소통할 준비가 되어 있다는 메시지이기도 합니다.

마무리

많은 테크 기업이 그들만의 문화와 가치관 아래서 개발자 생태계를 만들어 가듯, 아임웹도 우리만의 기술 정체성을 만들어 가기 위한 고민을 지금도 이어가고 있습니다.

그 과정에서 우리가 어떤 기술 조직인지, 어떤 문제를 어떻게 푸는지 앞으로 이곳에 천천히 쌓아갈 예정이니 많은 관심 부탁드립니다.

오민석 Developer Relations

아임웹의 기술 조직이 성장할 수 있는 환경을 고민합니다.