Gastby로 랜딩 페이지 만들기 개발 회고 및 팁2023년 8월, 당근마켓이 당근으로 새로 거듭났습니다.지역 생활 커뮤니티로서 더 당근다워진, 더 선명해진 비전을 사용자에게 잘 전달하기 위해 당근 리브랜딩 캠페인 페이지도 문을 열었는데요. 해당 랜딩 페이지를… 바로 제가 개발했답니다! (하하 감사합니다)당신 근처의 당근전사 차원에서 진행된 리브랜딩 프로젝트의 랜딩 페이지를 개발하면서 큰 성취감도 느꼈지만 또 그에 따른 부담감도 있었는데요. 개발하며 겪은 크고 작은 어려움을 공유하고, 다음에 또 랜딩 페이지를 개발한다면 어떤 식으로 진행할지 고민을 담은 글을 작성해보려 합니다.랜딩 페이지를 개발하는 많은 프론트엔드 개발자분께 도움이 되었으면 좋겠네요!개발 프레임워크 선택당근 리브랜딩 캠페인 페이지 개발 프레임워크로 Gatsby를 선택했어요. Gatsby를 선택한 이유는 사실 길게 고민하지 않았어요. 리브랜딩 캠페인 페이지가 나가야 하는 시간이 거의 한 달 정도 남은 상태였고, 새로운 기술을 배워 적용할 시간이 충분치 않았거든요. 또 주어진 기획안을 구현할 때 Gastby를 썼을 때 가져갈 수 있는 장점도 분명했어요.각자 처한 상황과 기획안에 맞게 더 편안하고 익숙한, 또 잘 할 수 있는 프레임워크를 택하는 게 중요할 것 같습니다.주로 사용된 개발 프레임워크 및 라이브러리 정리TypeScript (언어)GSAP (애니메이션)Gatsby (리액트 기반 프레임워크)Vanilla Extract (스타일)Cloudflare (배포)Gatsby 장점기획에 공유하기 기능이 있어서 이벤트 경품에 대한 링크를 공유하면 경품에 맞는 OG image와 title, description을 따로 보여줘야 하는 기획이 있었어요. 기존 CSR 프레임워크로 작업했으면 이 작업에서 커스텀으로 html을 여러 벌 뽑아주는 작업이 따로 필요했을 텐데, Gatsby를 선택함으로써 해당 작업이 많이 쉬워졌어요.gatsby의 여러 plugin들을 활용할 수 있다는 것이 큰 장점이었어요. clarity나 google analytics 같은 로그 툴을 붙일 때도 head 태그 안에 스크립트를 넣어주는 귀찮은 작업도 미리 만들어진 플러그인에 id 값만 넣으면 알아서 붙여주고, favicon과 같은 manifest 작업도 플러그인에 이미지 단 하나만 넣어주면 알아서 환경에 맞는 favicon을 미리 다 생성해 놓아요.특히 image 관련 플러그인을 사용하면 브라우저 크기에 맞는 이미지 생성 및 제공을 알아서 처리해 주니 (img의 srcSet과 media와 같은 프로퍼티) 특별히 이미지에 대해서 처리해 줄 게 없었어요. 그냥 preload 해줄지 아니면 lazy 하게 로딩할지만 내가 알아서 판단해서 선언해 놓으면 끝이었어요.Gatsby 단점Gatsby는 SSG(Static Site Generation)예요. 정적으로 미리 페이지를 뽑아놔요. 기획 중에 모바일과 데스크탑에서 다른 애니메이션을 보여줘야 하는 요구사항이 있었어요. SSG는 알다시피 유저의 브라우저 크기를 미리 알 수가 없

안녕하세요. 카카오페이 PFM-L 파티에서 자산관리 서비스의 프론트엔드 개발자로 근무하고 있는 나나라고 합니다. 이번 글을 통해 지금 읽고 계시는 카카오페이 기술 블로그를 개발한 경험을 회고해 보고자 합니다. Gatsby를 기반으로 기술 블로그를 개발하고, Astro 마이그레이션하며 느낀 장단점 등을 공유하고자 합니다. 기술 블로그 개발을 준비하는 분들, 어떤 플랫폼을 선택할지 고민하는 분들에게 도움이 되기를 바랍니다.개발자들이 기술 블로그를 만들 때 가장 고민하는 부분이 인 것 같습니다. 개인 블로그를 구축할 때에도 이를 고민하다가 결국 글을 쓰지 않고 접을 때가 많을 듯합니다. Tistory, Medium, Velog 등의 전문 블로그 플랫폼을 쓰는 방법도 있고 깃허브 페이지를 사용하거나 Vercel 등에 직접 웹페이지를 구축하는 방법이 존재합니다.당시 기술 블로그 기획자와 개발자 모두 플랫폼 이용보다는 웹페이지를 직접 구축하길 희망했고, 짧은 기간 안에 개발 완료를 위해서 스태틱 페이지로 배포할 수 있는 깃허브를 활용하기로 결정하였습니다. 서버 없이 SSG 렌더링 방식으로 개발할 경우 개발 리소스 단축이 가능하고 운영 비용 절감도 가능하기 때문입니다. 또한 깃허브로 기술 블로그를 운영하는 회사들도 다수 존재했기에 큰 이슈는 없을 것이라고 판단했습니다.깃허브 페이지에 SSG 렌더링 방식으로 스태틱 페이지를 제공하는 데에는 Gatsby, NextJS, Jekyll 등의 선택지가 있었는데, 그중에 제가 선택한 것은 Gatsby였습니다. 개인 블로그를 Gatsby로 개발했기 때문에 가장 자신 있는 프레임워크이기도 했고, 아래와 같은 이점들이 있어 Gatsby를 골랐습니다.• Gatsby는 GraphQL로 마크다운과 Static Assets들을 조회 및 가공할 수 있도록 제공함• NextJS는 개발 모드에서 마크다운을 수정해도 HMR이 적용되지 않음• NextJS가 SSG 모드에서 이미지 최적화를 지원하지 않음• Jekyll은 커뮤니티가 크기 때문에 기존 테마를 그대로 쓰거나 약간 수정해서 사용하기에는 편리하지만, 루비 기반이어서 커스텀 하는데 어려움이 있을 것으로 생각함기술 블로그는 화면이 많지 않고, 화려한 JS 구현도 필요하지 않습니다. 따라서 마크다운 기반의 기술 블로그를 개발할 때에는 마크다운 콘텐츠 처리에 가장 공을 들이게 되는 것 같습니다.마크다운을 처리할 때에는 보통 라는 라이브러리를 사용합니다. unified는 콘텐츠를 구조화된 데이터인 로 변경하여 처리할 수 있도록 코어 프로세스와 플러그인을 제공합니다. unified가 동작하는 과정을 살펴보면, Input 값을 parser를 통해 syntax tree로 파싱하고, 이 tree를 다양한 transformer들을 통해서 가공한 뒤 compiler로 output을 얻을 수 있습니다. 마크다운의 경우 remark-parse라는 parser를 통해서 mdast (markdown syntax tree)로 파싱 되고, 이 상태에서 remark 플러그인들을 적용해서 자동 링크를 붙이거나

타다 개발팀은 10년간 서비스를 운영하면서 맞닥뜨린 기술적인 이슈, 개발 문화 등을 블로그를 통해서 공유하였습니다. 저희는 기술 블로그를 통해 업계 동료들에게 받은 도움에 대해 보답하고자 했고, 저희의 다양한 경험을 공유함으로써 다른 분들의 의사결정에 도움이 되기를 바랐습니다. 그뿐만 아니라 여러 동료 개발자분들의 피드백을 통해 저희는 올바른 선택을 하고 한층 더 성장할 수 있었습니다. 이처럼 기술 블로그는 저희가 업계의 다른 분들과 직접적으로 소통할 수 있는 가장 효과적인 방법의 하나입니다.또한 기술 블로그는 지원자의 입장에서 회사의 기술적인 고민과 정보, 그리고 조직 문화를 알 수 있는 공간이 되기도 합니다. 실제로 타다팀에 지원하신 대다수 지원자분은 기술 블로그를 통해 합류를 결심하셨다고 합니다. '최고의 복지는 최고의 동료들' 이라고 생각하는 타다팀에게 좋은 동료를 모시기 위해 기술 블로그는 너무나 중요한 채널입니다.TF 의 시작지난 1년간 타다팀(VCNC) 에는 많은 변화가 있었습니다. VCNC 가 운영하던 비트윈이라는 서비스가 다른 회사에 인수되어 저희는 온전히 타다라는 서비스에 집중할 수 있게 되었습니다. 그리고 타다팀은 전략적 투자를 통해 토스와 함께하게 되어, 당장의 생존이 아닌 시장 문제의 본질에 대해 집중하고 이를 기술적으로 해결하는 데 관심을 기울일 수 있게 되었습니다. HR 팀 주도로 회사의 이러한 변화를 알리기 위한 여러 액션이 시작되었습니다. 그리고 개발자 채용에 가장 큰 역할을 하는 기술 블로그의 오래된 정보 수정을 요청하셨습니다.기존 타다 기술 블로그는 포스팅을 제외한 운영 측면에서 사실상 방치되었습니다. 좋은 글을 작성하기 위한 타다팀의 노력에 비해 이를 표현하는 창구가 다소 아쉬웠고, 이에 공감하는 개발자분들이 여럿 있었습니다. 저희는 회사의 전반적인 채용 브랜딩이 바뀌는 시기에 맞춰 단순 요청사항 반영에 머무는 것이 아니라 기술 블로그 자체를 조금 더 변화시키기로 하였고, 근무 외 시간을 이용해 개발팀을 중심으로 새로운 기술 블로그 TF 를 결성하였습니다.기술 블로그 목표TF 의 시작은 우리가 만들고 싶은 기술 블로그를 다시 정의하는 것이었습니다. 우리 블로그의 목적을 확실히 하고, 이를 잘 표현할 수 있는 방법을 찾아나갔습니다. 타다팀이 기술 블로그를 운영하는 이유는 처음과 달라지지 않았습니다. 즐겁게 가꾸어 나가고 있는 저희의 개발 문화를 소개하고, 기술적 경험을 공유하여 업계 전반의 생태계가 발전할 수 있게 도우며, 서비스 투명성을 통해 사용자들이 타다를 더욱 믿을 수 있고, 뛰어난 동료 개발자분들의 비판적인 피드백을 받고 싶습니다.이를 위해 저희는 단순 기술에 대한 설명글이 아닌 실제 저희의 경험이 담긴 글들을 적고 있습니다. 특정 기술에 대한 주제라 하더라도 그것이 회사 업무에 적용해보았을 때 어떤 효과가 나타나는지를 적습니다. 그리고 따라 해볼 수 있는 구체적인 솔루션을 제시하거나 저희의 실패에 대한 회고를 충분히 공유하려고 합니다. 즉, 타다 기술 블로그는 실제 타다팀이 마주하는 문제, 그

올-하 💚 안녕하세요! 올디브에서 Front-end Engineer를 맡은 주리랑입니다. 요즘 올리브영 기술블로그를 들어오면 무언가 많이 바뀌었다는 것 눈치 채신 분 계실까요? (두근두근 알아챈 사람 있을까...🧐)결론부터 말씀드리면 올리브영 기술 블로그는 기존의 Jekyll 프로젝트에서 Gatsby로 마이그레이션을 진행했는데요! 마이그레이션을 진행하며 디자인도 블로그 구성도 정말 많이 바뀌었습니다! 그래서 이번 포스팅에서는 올디브에서 기술 블로그를 1)Gatsby로 전환하게 된 계기 2)어떻게 블로그를 기획, 디자인 했고 3)새로운 프로젝트는 어떻게 설계, 개발 그리고 배포 했는지 4)최종적으로 전환하고 어떤 것을 느꼈는지 말씀드리고자 합니다.올디브에서는 기존에 Jekyll로 팀 블로그를 구축하고 운영까지 열심히 하고 있었습니다. 초반에 Jekyll를 블로그로 선택하게 된 이유는 많은 디자인 템플릿과 쉬운 커스터마이징이 가능하다는 점과 Jekyll을 사용하며 Github Pages와의 쉬운 연동으로 Git repo에 올리기만 해도 웹페이지에 호스팅 된다는 장점때문이였습니다. 또한 Jekyll은 정적 사이트 생성기(SSG, Static Site Generator)이다 보니 검색이 많이 되어야 좋은 블로그 특성상 SEO에도 유리했구요! (참고로 기존 기술 블로그는 기본(minima) 테마에 화면별로 스타일 적용했습니다.)그런데도 불구하고 기존 프로젝트에서 새로운 프레임워크로 전환하게 된 이유는 무엇일까요?기존 프로젝트에서 글을 포스팅하려면 Jekyll을 설치하는 환경구성 단계가 필요합니다. 사실 모든 프로젝트에 가장 어려운 것이 환경구성이지만 Jekyll로 구성한 프로젝트는 유독 환경구성이 어려웠습니다.실제로 신규입사자분들이 포스팅을 하려고 하면 Jekyll과 Ruby 그리고 macOS, Window 각 환경에 따라 심지어는 macOS m1의 경우 초반에는 설치가 안 되어서 엄청난 삽질을 하며 환경구성을 진행했습니다. 이 과정에서 실패한 분들도 있었고 구글링을 해도 자료가 많이 없어서 고생을 하기도 헀습니다 😂기존 블로그 콘텐츠 구조는 아래와 같았습니다.• 소소한 이야기 : 여러 이벤트 등 개발자들 사이에 있었던 이야기들의 모음위에서 설명해 드린 것과 같이 블로그를 운영하며 필요한 페이지와 정보를 추가하는 과정에서 비슷한 정보들이 여러 페이지에 분산되어 있음을 발견했습니다. (개발팀 소개와 채용정보 내 내용이 겹쳐요 ~!) 또한 올리브영 Tech 조직이 커지고 새로운 문화가 수립되고 바뀌면서 변경된 정보가 있어 콘텐츠 수정이 불가피 했구요 😂 그리고 테크 직군을 제외한 PO, 디자이너, 데이터 관련 직군들도 같이 소개하는 것이 좋다고 생각했습니다.더군다나 기존 블로그에 Google Analytics(GA)를 활용한 웹 로그 분석을 통해 본 사용자 유입의 결과 조금 더 관심 있어 하는 화면과 내용은 강조하고 관리가 잘 안되거나 유입이 적은 화면은 과감하게 삭제하는 것은 어떨까라는 생각도 들었습니다. 더 나아가 작년부터 진행된 공격적인 채용