들어가며
새롭게 도약하는 엑셈, 그 시작에 함께할 수 있어 영광이었습니다.
안녕하세요, 엑셈 BX팀 프론트엔드 개발자 박승훈입니다.
저는 이번 차세대 홈페이지·백오피스 리뉴얼 프로젝트에서 클라이언트·서버 개발을 담당했습니다.
엑셈의 다음 세대를 위한 홈페이지를 공개합니다.
이번 리뉴얼은 엑셈의 브랜딩과 서비스 경험을 새롭게 정비하는 중요한 프로젝트였습니다. 2025년을 마무리하는 시점에, 새로운 홈페이지를 선보이게 되었습니다.
출시를 위해 보이지 않는 곳에서 힘써주신 여러 부서의 임직원 분들께 감사드립니다.
글은 이렇게 적어보려 합니다.
엑셈 임직원, 미래의 예비 지원자, 그리고 고객사 관계자 등 읽으실 분은 폭넓게 예상됩니다. 여러분들께서 과연 무엇을 얻고자 이 글에 닿으셨을지 생각해 보았습니다.
- 홈페이지는 어떤 과정으로 만들어진 걸까?
- 홈페이지를 혼자 개발할 때 무엇을 신경 썼을까?
- 이거 괜찮은데 무슨 기술을 썼을까?
독자들의 이러한 예상 목적에 맞춰, 이전의 기술 포스트보다 비교적 “경험 위주”로 적어보려 합니다. 개발 과정의 기술 소개, 철학과 가치관, 경험 전달에 초점을 맞췄습니다.
“엑셈 홈페이지는 이런 과정을 거쳐 리뉴얼되었습니다“로 요약해보겠습니다. 그럼 시작하겠습니다!
1. 성과를 위한 결정
프로젝트 운영에서 의사결정에는 다양한 지표들이 따릅니다.
- Input: 인적 비용, 소통 비용, 인프라 비용 등
- Output: 영업 매출, 마케팅 성과 등
- Etc: 난이도, 불확실성, 지속 가능성 등
그리고 저는 이것을 이렇게 요약하고 싶습니다.
비즈니스에는 ‘가성비’가 중요하다.
감당 가능한 리스크를 안고, 최소한의 리소스로, 최대한의 성과를 만들어내는 것. 이것이 비즈니스의 핵심이라 생각합니다. 개발에서는 어떤 전략들을 취했는지 소개하겠습니다.
1-1. 바퀴를 다시 발명하지 마라
라이브러리, 개발 시간을 아끼는 좋은 방법입니다. 개발 생태계로부터 실력과 노력, 시간을 빌리는 방법입니다.
리소스가 적을수록 보수적이어야 합니다.
개발 이후에는 유지보수가 따릅니다. 미래를 위해 계산적이어야 합니다. 특히나 1인 개발 상황을 고려하면, 더더욱 ‘가성비’에 신경 쓸 수 밖에 없습니다.
“생산성과 DX를 위해 활용한 좋은 바퀴들을 소개합니다”라고 내용을 먼저 요약해보겠습니다.
Notion을 이용한 블로그
이미 눈치 채셨을 수 있지만, 이 블로그는 Notion의 페이지 데이터와 UI를 프로젝트에서 렌더링하는 react-notion-x라는 라이브러리를 활용해 만들어졌습니다. 사이트의 톤앤매너에 맞게 많은 디테일을 재구성해야 했지만요.
UI를 포함한 고수준 라이브러리일수록 입맛을 맞추기 힘듭니다. 이 라이브러리는 그저 Notion 페이지를 프로젝트에서 그대로 렌더링하는 것이 핵심 기능입니다. OpenGraph 설정이나 통계 기능, CTA 버튼 등은 별도 백오피스에서 관련 CMS 기능을 개발해야 했습니다.
그렇더라도 충분히 강력합니다. 텍스트·이미지·동영상·파일·수식 등의 미디어 타입을 지원하며, 반응형 레이아웃을 지원하는 WYSIWYG 에디터 개발은 리소스가 몹시 큽니다. Notion의 고성능 WYSIWYG 에디터를 활용할 수 있는 것만으로 큰 이점을 가집니다.
GSAP을 이용한 스크롤
리뉴얼된 웹사이트는 페이지 곳곳에서 스크롤 UX를 제공합니다. 레거시 웹사이트, 특히 B2B에서는 더더욱 경험하기 어려운 현대 웹 UX 제공에 초점을 맞췄습니다.
이 과정에서 GSAP이라는 애니메이션 라이브러리를 사용했습니다. 각종 고급 기능을 지원하지만 유료다보니 사용이 제한되었는데, 2025년 4월, 전면 무료화되며 웹사이트에 안정적으로 도입해볼 수 있게 되었습니다. 유명한 Motion과 비교하자면, 더 난이도는 있지만 세밀한 애니메이션 인터페이스를 지원한다는 차이가 있습니다.
현재 웹사이트에는 GSAP 없이 많은 스크롤 기능들을 자체적으로 구현하고 있기도 합니다. 하지만 관성 스크롤이나 고정 시간 스크롤 등 직접 구현이 어려운 기능들 중 상당수를 GSAP의 도움으로 해결할 수 있었습니다.
i18n-ally를 이용한 다국어 지원
엑셈 홈페이지는 한국어 외에도 영어, 추후 일본어와 중국어까지 확장될 가능성이 있는 다국어 사이트입니다. 이를 위해 Next.js의 다국어 라이브러리 next-intl를 사용했습니다.
특히나 1,200개의 다국어 key를 효율적이고 안전하게 관리하기 위해 i18n-ally라는 VSCode extension을 도입했습니다. 가장 좋은 기능을 소개합니다. 다국어 key 자체로 보여지는 것이 아닌, 대표 언어로 key가 치환되어 표시됩니다. 이것만으로도 사용할 이유가 됩니다.
그밖에도 안전하고 효과적으로 다국어를 관리할 수 있는 많은 기능들이 있는데, 더 자세한 내용은 i18n-ally 문서를 참고해주세요.
1-2. AI 낭비하기
생산성을 논할 때 AI를 빼놓을 수 없는 시대입니다. AI 코드 에디터나 에이전트 사용을 넘어, 자동화 워크플로우와 QA 에이전트 등 흥미로운 주제들이 이전 포스트에서 언급되었습니다. AI를 똑똑하게 쓰기 좋은 세상입니다.
그래서 저는 기능 구현 외적으로 AI를 ‘낭비’한 사례를 소개하겠습니다. AI가 없었다면 시도하지 못했을 개발 사례들입니다.
“AI를 이렇게 쓰기도 했다”고 내용을 요약해보겠습니다.
Ascii Generator
현재 웹사이트의 메인 비쥬얼 섹션은 특정 문자와 key color로 구성된 아스키 미디어로 만들어졌습니다. 요구사항은 이러했습니다.
- 원본 미디어를 원하는 해상도의 아스키화된 미디어를 추출할 수 있다.
- 특정 문자에 대해 key color로 색상을 바꿀 수 있어야 한다.
- 60FPS와 선명도는 유지되어야 한다.
- …
이 요구사항을 만족하는 라이브러리를 찾을 수 없었습니다. 직접 개발하기로 했습니다.
ascii-react라는 라이브러리를 별도로 만들어 프로젝트 코드와 분리했습니다. 이후 다양한 옵션들을 원하는대로 설정하고 결과를 추출할 수 있도록 임시 사이트를 만들어 배포했습니다.
팀내 디자이너가 손쉽게 미디어를 아스키 미디어로 추출할 수 있게 되었습니다.
오래 유지할 프로젝트가 아닙니다. 성능, 안정성보다는 단기 목표 달성에 집중했습니다. 일부 문제가 눈에 밟히더라도, 결과에 영향을 주지 않는다면 무시했습니다. ‘원본 미디어의 아스키화’라는 MVP를 달성하여 웹사이트에 활용할 수 있었습니다.
SEO R&D
웹사이트에 적용할 SEO R&D를 위해 토이 프로젝트를 진행했습니다. SEO는 이런 것들이 필요합니다.
- 페이지별 컨텐츠가 온전히 구성되어야 합니다.
- 관련 메타데이터를 제공해야 합니다.
그래서 가짜 데이터를 만들고 페이지에 구성하는 과정에서 AI를 활용했습니다.
컨셉 및 제작 의도를 담은 AI 프롬프트를 통해 PRD를 구체화하고, 각 페이지 성격에 맞는 컨텐츠를 자동으로 구성했습니다. SEO에 영향을 주는 시멘틱 마크업, 컴포넌트 구성, 페이지 및 카테고리 구성 및 사이트맵 구성에 초점을 맞췄습니다.
그 결과 비즈니스 수준의 페이지를 5분마다 뽑아낼 수 있었습니다.
네이버와 구글에 색인이 되었고, 심지어 AI 요약도 되었습니다. ‘효과적인 인덱싱 테스트’라는 MVP 목표를 적은 리소스로 얻어냈습니다.
1-3. DevTool 만들기
어떻게 보면, 위의 ‘AI 낭비하기’와 이어집니다.
흔히 프론트엔드 개발에서는
console.log를 찍거나 debugger, breakpoint 설정으로 코드 진행을 중단해가며 데이터 흐름을 파악합니다. 하지만 이런 생각을 했습니다. ‘데이터 확인 뿐 아니라 데이터 구성까지, 조금만 더 DX에 도움을 주는 DevTool을 만들 수는 없을까?’ 그래서 AI를 활용해 DevTool을 빠르게 만들었습니다.DevTool은 사용자 환경에서 보이지 않기 때문에 비즈니스에서의 가치는 낮습니다. 때문에 코드 퀄리티보다는, ‘리소스 들이지 않기’와 ‘원하는 데이터를 쉽게 보고 생성하기’에 집중했습니다.
홈페이지 - 사옥투어
사옥투어 페이지에서 사옥의 마지막 레이어는 특정 층을 클릭했을 때 사옥투어 모달이 켜지고 해당 층부터 시작하게 되어 있습니다. 하지만 이 사옥의 모습이 3차원으로 뒤틀려 있어 각 영역을 polygon으로 구성하고, 꼭짓점 좌표를 찍어야 했습니다. 번거로운 과정이라 DevTool을 만들어 개발에 활용했습니다.
또한 텍스트가 표시/숨김되는 레이어, 스크롤 진행도에 따라 수 백장의 이미지를 교체하는 레이어, 그리고 클릭했을 때 모달이 나오는 레이어 등 레이어 간의 교체 타이밍을 설정하는 config가 있습니다. 타이밍이 중요한 데이터여서 UI와 함께 적절한 지 확인하기 위한 DevTool을 만들었습니다.
백오피스 - 인가 관리
홈페이지의 이면에는 사이트에 표시되는 데이터나, 접수된 문의를 담당자가 확인하고 설정할 수 있는 백오피스가 있습니다. 각 담당자들마다 어떤 페이지에 접근하고 수정할 수 있는지 구분해서 관리가 되어야 합니다. 이 인가를 관리하는 페이지에서도 DevTool을 제작해 사용했습니다.
추가로 이 백오피스의 인가 구조가 조금 재미 있는데요, 비트마스킹을 활용한 트리 구조로 설계했습니다.
AWS의 IAM처럼 세세하고 계층적인 권한 관리 기능을 지향했고, Linux의 777 권한 체계의 Bit 데이터 저장 방식에서 아이디어를 얻었습니다.
- 조회/생성/수정/삭제의 각 동작들을 개별 설정할 수 있다.
- 카테고리에 따른 인가는 위계적으로 연결되어 일괄 설정할 수 있다.
- DB에 인가 데이터를 효율적으로 저장할 수 있다.
1-4. Make Difference
저희는 리뉴얼을 합니다. 단순히 예뻐지는 것으로는 부족합니다. 회사 안팎의 사용자들을 위한 진화된 전략, 그리고 UI/UX가 필요합니다.
저희는 ‘마케팅’에서 답을 찾으려 합니다. 마케팅의 핵심을 서비스 기획과 개발로 끌어왔습니다.
- 고객의 니즈를 파악하고 분석한다.
- 작은 관심을 포착하여 큰 매출과 성과로 연결한다.
- 고객이 모르는, 더 좋은 제안과 가치를 제공한다.
저희 프로젝트의 사용자는 회사 밖의 고객, 그리고 회사 안의 실무 구성원들입니다. 모두를 위해 어떤 일을 했는지 소개합니다.
백오피스 리뉴얼은 대부분의 기획·디자인·개발을 직접 했습니다. 심미성이 부족할 수 있는 점 양해 부탁드립니다.
구성원의 편의 강화하기
백오피스는 CMS의 역할을 합니다. 홈페이지에 보여질 블로그, IR 자료 등을 구성하는 역할이죠.
리뉴얼 개발 과정에서 각 부서 실무자별로 개선사항을 취합했고, 긴급도·영향인원수·작업공수를 고려하여 출시 전후로 대응을 진행하고 있습니다.
또한 기존에는 모바일 환경을 지원하지 않았던 것과 달리, 이제는 모바일 환경을 지원합니다. 실무자들이 언제·어디서든 업무를 이어가고, 긴급 상황에 대처할 수 있습니다.
고객의 관심 파헤치기
홈페이지 문의 페이지에서는 제품과 투자, 고객 지원 등 고객들의 다양한 문의를 수집하는 창구입니다. 이렇게 접수된 문의는 각 담당자들에게 도달하게 됩니다.
고객의 문의는 곧 관심입니다. 이 관심의 이면을 더 분석하고 맞춤 대응에 활용할 수 있게 기능을 지원했습니다.
고객이 관심을 가지는 분야와 요청사항을 다양하게 수집하고, 그와 동시에 방문 페이지, 또는 오랜 시간 체류한 페이지들을 종합하여 고객에 대해 다각적으로 파악할 수 있게 되었습니다.
또한 문의를 요청한 기업의 최신 기사 등 AI 분석을 종합하여 문의 고객과의 라포 형성 및 맞춤형 제품을 제안할 초석을 깔았습니다.
아직 출시 초기이기에 디자인과 기능은 초입 단계입니다. 하지만 영업, 홍보, 마케팅은 매출로 이어지는 만큼, 실무 지원 차원의 AI 기능과 사용성, 심미성 강화 로드맵을 가지고 있습니다.
2. 개발 과정의 철학
저는 특수한 상황에 처해 있습니다. 비개발자 리더와 동료들 사이에서 프로젝트를 운영하는 유일한 개발자입니다. 이 프로젝트 코드의 미래를 홀로 책임져야 합니다. 정신 차려야 합니다. 주인 의식을 가지고 더 멀리 바라봐야 했습니다.
이 과정에서 저는 어떤 철학과 가치관, 전략을 가지고 개발에 임했는지 소개하겠습니다.
2-1. 변화에 대비하기
‘프로그래밍’과 ‘소프트웨어 엔지니어링’은 다르다. ‘프로그래밍’이 단순히 개발이라면, ‘소프트웨어 엔지니어링’은 개발, 수정, 유지보수를 모두 포함한다. 시간이 프로그램에 미치는 영향을 생각해야 한다.
《구글 엔지니어는 이렇게 일한다》
개발의 영역에서 ‘변화’는 애증의 동반자입니다. 기술과 패러다임이 계속 발전합니다. 동료가 바뀝니다. 리더가 바뀝니다. 요구사항이 바뀝니다. 코드는 요구사항 달성을 위해 누더기가 되기 쉽상입니다.
레거시로 향하는 건 피할 수 없습니다. 하지만 설계 단계에서 변화를 얼마나 고려했는지에 따라 프로젝트의 수명이 달라집니다.
여러 관점에서 제가 변화에 대비한 점들을 소개합니다.
요약하면 “혼자이더라도 팀처럼 일하기”입니다.
REST API 분리
리뉴얼 홈페이지는 Next.js를 이용해 Client와 Server를 개발했고, Supabase로 DB와 Storage를 사용하고 있습니다. Supabase의 JS SDK를 사용하면 클라이언트에서도 DB 데이터를 조회하고 조작할 수 있습니다.
하지만 저는 이런 생각을 했습니다.
백엔드 개발자가 합류하여 REST API 방식으로 서버와 통신하게 바꿔야 한다면?
인원 변화 시나리오 중 가장 가능성 있는 상황입니다. 위의 상황에서 1번 방식은 클라이언트에서 직접 호출하고 있는 DB 통신을 모두 서버와의 API 통신으로 변경해야 합니다. 코드가 쌓이면 큰일이 됩니다.
때문에 처음부터 클라이언트에서는 서버로 API 요청을 하고, 응답을 받는 정통적 데이터 통신 구조를 유지했습니다. 그리고 서버의 역할을 하는 Next.js API Routes를 사용했습니다. Next.js API Routes에서 Supabase DB/Storage와 통신하고, 이를 클라이언트에 반환해주었죠.
이렇게 된다면, 백엔드 개발자 합류 후 별도 서버(ex. Spring)가 나오는 경우, 클라이언트는 현재의 API 설계 구조와 호출 코드를 그대로 유지할 수 있겠죠.
덩달아 일반적인 서버-클라이언트 데이터 통신 구조의 이점을 유지할 수 있습니다.
- Tanstack Query를 사용한 서버 상태/캐싱 전략 사용
- Axios 등의 HTTP 클라이언트 라이브러리를 사용하여 권한/HTTP 상태 관련 intercept 전략 사용
- 클라이언트에서 노출되지 않는 서버 사이드 DB 통신으로 보안 강화
문서화
개발자 동료가 팀에 합류한다면 히스토리 전달이 필요합니다. 지금까지 제가 쌓아온 코드들이 어떤 요구사항과 배경에서, 어떤 작업 단위로 쌓여왔는지 기록되어 있다면 자세한 파악이 필요한 때에 도움이 되겠죠.
개발팀에서 일할 때에는 당연한 절차이지만, 혼자 개발할 때는 철저하게 하기가 참 어렵습니다. 그래서 더더욱 신경 썼습니다. 항상 동료와 함께 일한다는 마음으로 기록했습니다.
GitHub IssueIssue는 작업 요구사항, 또는 개발에서 설정한 목표를 기준으로 생성했습니다. 평범합니다.
GitHub Pull RequestPull Request(이하 PR) 대부분 그러하듯이, 특정 작업 목표에 대한 개발 코드 및 내용 요약을 작성했습니다. 특히 이해가 어렵거나 핵심 로직을 조금이나마 설명을 남기려 했습니다.
추후 label로 내용을 확인하기 위해 다양한 label를 생성하고, PR Labeler를 사용하여 CI 단계에서 자동으로 라벨링해주었습니다.
- diff: 작업 변경사항의 규모 구분
- type: feature/bugfix 등
- etc: Server, Test, Workflow 등 특수 작업
PR 작성 자체도 문서화 리소스가 필요합니다. AI로 PR을 자동 작성하고, 변경사항에 대해 전반적인 코드 리뷰를 개발 환경에서 표시, 나아가 PR에 댓글로 리뷰 내용을 달 수 있도록 설정했습니다.
그렇더라도 저는 ‘사람의 냄새’를 조금이나마 더하려 합니다.
- AI가 놓친 부분이나 개발자가 설계에 신경 쓴 부분들을 보완하여 작성합니다.
- AI로 PR과 리뷰를 완전 자동화한다면, 사람의 리뷰와 관심이 줄어들 수 밖에 없습니다.
사람이 관리하는 모든 컨텍스트와 히스토리를 AI가 넘어서는 날까지는, 사람의 눈과 머리가 필요한 곳에 관심을 잃지 않도록 문화와 시스템을 갖춰야 합니다.
README대형 프로젝트는 프로젝트가 어떻게 구성되는지, 어쩌면 어떻게 실행하는지조차 파악이 어려울 수 있습니다. 또, 프로젝트의 국소 범위에서 독특한 컨벤션을 이해하지 못할 수도 있죠. 그래서
README.md를 관련 도메인 폴더 곳곳에 두어 실행 방법, 컨벤션과 설계 배경 등을 기록해두었습니다.
최근에는 Deepwiki 등의 AI를 이용해서 Public 프로젝트 구조를 비교적 쉽게 파악할 수 있습니다. 개발자라면 AI로 프로젝트 구조에 대한 설명 문서를 쉽게 작성할 수도 있죠. codex, claude code에서는
/init만 입력하면 됩니다.그래서 저는 이런 것들을 문서로 남깁니다.
- 사람이 쉽게 놓칠 수 있는 부분이나 환경에 따른 트러블슈팅 가이드
- 컨벤션이나 구조 설계에서 설계자의 생각과 의도, 근거
추후에 시간이 지나 제가 설계에서 고려했던 점들이 ‘레거시’가 되고 더 나은 개선점이 마련되었을 때에는 과감히 낡은 설계를 바꿀 수 있게 하기 위함입니다.
규칙과 시스템
개발에서의 최소 작업 단위는 ‘커밋(Commit)’입니다. 저는 커밋을 유의미한 기록으로 판단합니다. 한 작업 단위에서 관련된 다른 파일의 변경도 확인하기 좋고, 해당 커밋이 포함된 PR도 추적이 가능하며, 유사시 롤백의 체크포인트로도 사용할 수 있습니다.
그러면서도 1인 개발에서는 지키기 힘든 부분입니다. ‘코드 리뷰를 하는 것도 아닌데, 당장의 구현도 급한 마당에 빡빡한 커밋 규칙? 피곤한데?’ 라고 생각이 들 수도 있습니다.
물론 현재의 발빠른 움직임과 성과도 중요합니다. 하지만 가장 중요한 점은 미래의 누군가가, 특정 파일에 대하여 과거의 작업 의도와 내용을 파악할 수 있다는 것이라고 생각합니다. 지나면 돌이키기 힘든 영역이니까요. 그래서 커밋 메세지 규칙을 만들고 철저하게 준수하고 있습니다.
규칙이 잘 유지되려면 규칙을 지킬 수 밖에 없게 하는 시스템이 필요합니다.
저는 git hook manager로 lefthook을 사용하고 있습니다. 커밋 시점에 호출되는
commit_msg job이 있는데, 커밋 메세지 규칙을 판단하는 shell script를 만들고, 해당 job에서 shell script를 실행하도록 했습니다. 
그 결과 커밋 메세지 규칙을 충족하지 않는 커밋은 실패합니다. 피곤한 규칙이지만 미래 세대에 빚을 물려주지 않기 위해 지금부터 고생을 분산하고자 합니다.
2-2. 지름길보다는 멀리 가는 길
웹사이트 리뉴얼 프로젝트는 굉장히 바쁘게 진행되었습니다. 최소한의 기간에, 최대한의 성과를 내야 했습니다. 하지만 발 끝만 쳐다보며 달린다면, 언제든 넘어질 수 있는 상태로 어디로 향하는지도 모르게 되겠죠.
현재의 성과와 미래의 유지 사이에서의 선택, 저의 사례를 소개합니다.
풀스택 결정이 프로젝트에서 제가 처음부터 풀스택 개발자는 아니었습니다. 최초에는 프론트 1명과 백엔드 1명으로 시작했으나 백엔드 개발자의 프로젝트 이탈이 있었습니다. 프로젝트 유지를 위해 타 부서의 백엔드 인력 지원이 불가피한 상황이었습니다.
하지만 정식 합류가 아닌 임시 지원이라면 문제가 예상되었습니다.
- 현업에 계신 백엔드 개발자의 당장 맡고 있는 업무는?
- 히스토리 학습과 백엔드 서버 재개발, 이 과정에서의 소통 비용
- 출시 이후의 불투명한 유지보수까지
당장의 비용은 물론, 장기적으로 유지가 어려울 것이라 생각했습니다.
그래서 고민 끝에 결정했습니다. “백엔드 개발자의 지원이 아닌, 내가 서버 개발까지 하겠다.” 전문 백엔드 개발은 아닐지라도, REST API와 DB, ERD 등 웹 어플리케이션 개발을 위한 기본 지식은 가지고 있었습니다. 하물며 Supabase나 Next.js 등 풀스택 개발을 위한 생태계도 잘 갖춰져 있었습니다.
리더는 저를 믿어주셨고, 다행히 저희는 여기까지 왔습니다.
모노레포 설계Next.js 프로젝트 내에서 풀스택 개발을 한다면 좋은 점이 있습니다. 서버와 클라이언트가 하나의 프로젝트 안에서 개발 코드의 상당수를 공유할 수 있다는 점입니다. 그런 것처럼 모노레포를 사용했을 때 좋은 점이 있습니다. 연관된 어플리케이션끼리 코드의 상당수를 공유할 수 있다는 점입니다.
저희 모노레포에는 현재 홈페이지와 백오피스, 총 2개의 어플리케이션이 있습니다. 홈페이지에서 제출한 문의 내용, 신청 내역은 똑같은 데이터 타입으로 백오피스에서 보여지고 관리되어야 합니다. 모노레포에서는 package로 low-level 공통 코드를 분리하여 각 어플리케이션에서 관련 코드를 사용할 수 있습니다.
모노레포 방식을 통해 여러 사용처의 코드를 단일화하고, 유지보수성과 안정성을 높였습니다. 멀리 가는 프로젝트를 위해 꼭 필요한 2가지 요소입니다.
꼭 모노레포가 아니라 멀티레포에서도 코드를 공유할 수 있는데요?
네, git submodule이나 subtree 등을 통해 멀티 레포 체계에서도 코드를 공유할 수 있습니다. 다만, 어플리케이션 간의 코드 유사도나 의존성 관리, 기타 코드 통합 등의 관점에서 보았을 때 관리 복잡도가 높지 않은 모노레포 방식이 유리하다고 판단하여 채택했습니다.
2-3. 미움 받을 용기
프로젝트의 사내 공개를 앞두고, 계속 중요한 개선사항이 겹치며 개발 기간이 부족해졌습니다. 리더가 이런 제안을 했습니다. “다국어는 구조를 잡는 시간이 걸리니, 한글로 모두 만들고 복제해서 영어로 번역해서 넣자.”
리뉴얼 이전 홈페이지가 이런 방식이었습니다. 반응형 대응을 위한 PC/MO 프로젝트 따로, 프로젝트 내에 똑같이 생긴 한글/영어 두 벌의 페이지가 있었죠.
당연히 유지보수는 어려웠습니다. 값을 하나 바꾸려면 2개 프로젝트, 4개 페이지를 각각 바꿔줘야 했습니다. 사소한 변경에도 소요 시간과 누락 위험이 있었습니다.
저는 현재의 대응을 위해 나쁠 게 확실한 미래를 선택하는 건 안 된다고 극구 반대 했습니다. 의견은 잘 받아들여졌고, 번역 key 기반의 효율적인 다국어 체계를 도입할 수 있었습니다.
고집, 이것은 프로젝트의 미래를 위해 리더의 결정에 목소리를 내는 ‘미움 받을 용기’입니다.
2-4. 언제든 대체 가능한 인재
“버스 지수(bus factor)”
몇 명의 팀원이 버스에 치어서 일을 할 수 없게 될 때 프로젝트가 망하게 되는지를 나타내는 지수
《구글 엔지니어는 이렇게 일한다》
세상은 ‘대체 불가능한 인재’, 즉 독보적 인력으로서의 가치를 지향합니다. 물론 개인의 입장에서는 맞는 말입니다.
하지만, 조직의 입장에서 다시 생각해보면, 대체 불가능한 인력의 이탈은 프로젝트 유지에 치명적입니다. 이직, 퇴사 등 자의적인 이유 뿐만 아니라 질병과 사고 등 불가피한 상황에도 말입니다. 이를 많은 개발 서적에서는 버스 지수, 또는 로또 지수로 소개합니다.
1인 개발의 상황을 생각해 보겠습니다. 개발자가 버스에 치여 개발이 불가하든, 로또에 당첨되어 퇴사를 하든, 프로젝트는
STOP입니다. 1인 방식은 빠르게 치고나갈 수 있지만, 보충 인력에 대한 안전장치가 없다는 점에서 리스크를 가집니다.저는 제가 일군 코드와 시스템이 제가 없는 상황에서도 문제 없이 인수인계 및 유지보수가 되길 바랍니다.
- 충분히 많은 히스토리를 기록합니다. AI와 사람 모두 힘써야 합니다.
- 규칙을 설계하고 준수하는 시스템을 갖췄습니다.
- 개발 리소스와 접근 계정을 리더와 사전 공유하여 유사시 대처가 가능하도록 했습니다.
- …
저는 리더에게 “내가 없는 미래를 위해 대비한다”는 말을 종종 합니다. 의도치 않게 리더는 불안해 합니다. 부연 설명을 잘 하도록 합시다.
3. 마치며
3-1. 홈페이지를 바꾸게 된 이유
B2B 회사인데 홈페이지가 그렇게 중요한가?
엑셈은 바쁘게 움직이고 있습니다. 더 안정적이고 수준 높은 제품을 위한 리소스도 부족한 상황입니다. 그런 상황에서 홈페이지 리뉴얼을 추진하게 된 배경을 설명하고 싶습니다.
WHY 엑셈은 B2B 회사입니다. B2B의 고객은 대중이 아닌, 소수의 고객사입니다. 매출은 계약에서 나옵니다. 계약만 잘 따낸다면 홈페이지는 그리 중요하지도 않고, 어쩌면 없어도 될 것 같습니다. 그런데 과연 사실일까요?
네, 사실입니다. 엑셈은 서비스도 잘 만들고 영업도 잘 합니다. 당장의 매출은 걱정 없습니다. 오늘의 엑셈은 튼튼합니다.
그래서, 저희는 엑셈의 미래를 준비합니다. 저희는 아래의 목적을 달성하고 싶었습니다.
- 더 전문적이고 세련된 기술 회사, 엑셈의 이미지를 만들고 싶다.
- 멋지게 잘 만든 서비스, 더 멋지게, 더 제대로 보여주고 싶다.
- 동종 업계에 속한 누군가라면, 당연히 엑셈을 알게 하고 싶다.
- 엑셈에 조금이라도 관심이 있다면 이를 먼저 알아채고 싶다.
- 영업이 조금 덜 뛰어도 서비스를 더 계약하게 하고 싶다.
집중해야 하는 포인트는 ‘고객이 우리에게 끌리게 하고, 그렇게 닿은 고객을 우리가 알아채고, 놓치지 않게 한다’는 점입니다. 그래서 저희는 무엇을 해야할 지 고민했습니다.
WHAT그래서 저희는 합니다.
변화, 그 너머의 혁신
엑셈은 지난 25년간 모니터링 업계에서 업력과 명성을 쌓아왔습니다. 선배들의 정신과 기술, 시간을 우리는 ‘유산’으로 칭합니다. 기술이 일주일마다 뒤바뀌는 요즘입니다. 저희도 발맞춰 더 빠르게 나아가야 합니다. 시대에 적응합니다. 세대를 바꾸겠다고 감히 말합니다.
그래서 저희는 엑셈의 리브랜딩을 추진했습니다. “더 ??하게”라는 표현을 적다가 지웁니다. 개선이 아닙니다. 탈바꿈입니다. 엑셈의 로고, 서비스, 대외 문서를 바꿉니다. 디자인과 마케팅, 브랜딩을 바꿉니다.
그렇게 홈페이지도 바꾸게 되었습니다. 함께 바뀐 많은 것을 담았고, 앞으로 바뀔 많은 것을 담을 예정입니다.
3-2. 맺음말
지금까지 엑셈 홈페이지 리뉴얼 프로젝트의 개발을 진행하며 경험했던 사례, 그리고 지키고자 했던 소신과 가치관들을 적어보았습니다. 엑셈 사이트의 새 시작의 이면에는 이런 상황과 개발자의 고민이 있었다는 개발 스토리로 봐주시면 좋겠습니다.
수많은 개발자들 사이에서 제가 회사를 대표하는 홈페이지를 리뉴얼한다는 사실에 기대와 부담이 컸습니다. 엑셈과 구성원 분들께 누가 되지 않으려 노력했고, 모쪼록 결실을 맺었음에 감사하게 생각합니다.
엑셈은 전문가 집단입니다. 지금도 많은 엑셈 구성원 분들이 전문성과 경험을 바탕으로 자신의 이야기들을 적어주고 계십니다. 앞으로 이 곳에 담기게 될 목소리들이 기대됩니다.
새롭게 시작된 엑셈의 홈페이지가 엑셈의 세련됨, 전문성을 널리 알리는 신호탄이 되길 바랍니다. 엑셈의 기술과 이야기를 더더욱 다채롭게 담아낼 수 있도록 계속 노력하고 발전시키겠습니다. 감사합니다.
함께 보면 좋은 아티클
