BATON DEV
스튜디오 바톤 개발팀을 소개합니다.
Last updated
스튜디오 바톤 개발팀을 소개합니다.
Last updated
안녕하세요. 스튜디오 바톤의 대표이자 공동 창업자, 개발팀 리드를 맡고 있는 한송욱입니다. 스튜디오 바톤은 2013년에 설립되어 웹서비스 구축과 비주얼 브랜딩 영역에서 활동 중인 디자인 스튜디오입니다. (좀 더 알아보기)
바톤이 디자인 회사로 알려진 만큼 온라인상에 개발팀과 관계된 정보는 많이 없습니다. 그래서인지 개발팀 채용면접에서 '정보를 찾기 어려웠다'는 피드백을 종종 듣게 되는데요. 이 페이지를 통해 그간 자주 받았던 질문부터 TMI까지 상세히 공개해보려고 합니다.
디자인 스튜디오의 개발팀은 마치 냉면집의 녹두전, 보이밴드의 드럼, 팥빙수의 고명 같은 느낌이기도 하지만 바톤의 슬로건이자 모토인 'The Balance of Aesthetics and Engineering' 에서 알 수 있듯 바톤에서 엔지니어링은 매우 중요한 가치를 구현하는 기능을 합니다.
개발팀은 바톤의 주요 아웃풋인 웹 서비스 구축 및 관리에 관한 기술적인 모든 부분을 다루고 있습니다. UI/UX에 대한 기술 컨설팅과 시스템 설계, 구현, 테스트, 유지보수, 배포 등 업무를 별도의 외주 없이 개발팀 자체 역량으로 진행합니다.
때때로 웹사이트 구축 프로젝트에서 디자인 회사와 개발사가 분리되어 있는 경우를 종종 볼 수 있습니다. 물론, 정답은 없습니다만.. 바톤의 웹사이트 프로젝트는 기획, 디자인, 개발, 배포 후 유지보수 등 모든 과정에서 각 파트가 단계의 구분 없이 깊고 잦은 상호작용을 필요로 합니다.
하나의 웹사이트가 만들어지는 과정은 크게 보면 선형적 흐름을 보이는 것 같지만 제작의 모든 과정은 비선형적이며, 특히 고객이 속한 섹터의 환경과 요구사항에 따라 웹이라는 공통점만 있을 뿐, 각기 다른 특성때문에 규격화가 매우 어렵습니다.
즉, 개발팀의 역량은 기획과 디자인을 보다 자유롭게 만들고, 할 수 있는 것과 할 수 없는 것의 경계를 설정하는 데 큰 역할을 합니다. 이는 결과물의 품질과 고객사의 만족도에 직접적인 영향을 미치는 요소입니다. 그리고 이러한 개발 역량이 내부에 있고 없고는 생각보다 큰 차이를 만들어 냅니다. 지금부터 바톤의 개발팀이 정확히 어떤 일을 하고 어떻게 일하는지에 대해 알아보겠습니다.
앞서 소개한 바와 같이 저희는 프로젝트를 성공시키기 위해 기술이 필요한 모든 것을 합니다.
다만, 대부분의 개발 작업은 포트폴리오 상에 직접적으로 드러나지는 않습니다. 저희의 가장 큰 역할은 기획과 디자인을 거쳐 완성된 결과물―현재는 Figma를 주로 사용―을 다양한 디바이스와 실행 환경을 고려하여 섬세하게 구현하는 것입니다. 그리고 이 과정에서 표면에 드러난 기능 뒤의 성능, 관리, 편의성 등 고객사의 특성에 따라 다양한 부분을 만들어 내는데, 이때 신경 쓸 부분과 작업들이 많아집니다. 몇 가지 예를 들어보죠.
고객사에서 런칭 후, 사이트의 유지보수를 담당할 개발자가 React 베이스라면 Next.js를 이용하고 Vue가 친숙하다면 Nuxt.js로 개발합니다.
기존의 레거시가 Wordpress 기반인데 기존 자원을 반드시 사용해야하는 경우라면 세계관은 유지하면서 관련 테마를 새로 빌드합니다. 별도의 특수한 플러그인이 필요하다면 제작합니다.
규모있는 쇼핑몰이 cafe24 플랫폼을 이용한다면 관련 스킨을 개발합니다. cafe24에서 지원하지 않는 기능을 원한다면 AWS와 같은 별도의 공간에 웹서버를 띄우고 DB―주로 Aurora MySQL―를 연동해 cafe24용 앱을 제작합니다. 트래픽이 많아지면 오토스케일링을 걸고 redis 캐시를 태우거나 람다를 이용해 이미지를 동적으로 리사이징 하기도 합니다.
고객사의 레거시 시스템에 대한 마이그레이션 툴을 만든다거나 모니터링을 위한 커뮤니티 크롤링을 위해 파이썬 봇을 제작하기도 합니다.
좀 더 실제 케이스를 중심으로 살펴볼까요?
Kiaf SEOUL은 2002년 처음 문을 연 한국 최초의 글로벌 아트페어이며, 바톤은 2020년부터 매년 새롭게 Kiaf SEOUL의 웹사이트를 리뉴얼하고 있습니다.
저희는 Kiaf SEOUL 웹사이트에서 이루어지는 모든 과정을 설계하고 구현합니다.
수백 개의 갤러리와 연계된 수천 건의 작품을 업로드 할 수 있는 신청 플랫폼
신청된 정보를 바탕으로 평가하고 승인한 뒤, 동적으로 작성된 공문을 관리, 전송할 수 있는 시스템
각 갤러리들의 OVR을 제공하고 이를 관리하기 위한 인터페이스와 시스템
행사 시즌에 등록된 모든 아트웍에 대한 글로벌 트래픽을 받아내는 캐싱 시스템
짧게 나열한 것 외에도 VIP-Ticketing과 현장 스태프들을 위한 소프트웨어까지 다양한 시스템을 제작하고 있습니다.
즉, 디자인 포트폴리오 이면에 숨어있는 수많은 어드민 인터페이스와 기능도 저희의 구현 대상입니다.
기획자와 디자이너, 개발자가 같은 프로젝트 안에서 '잘' 일하는 방법에 대한 책이 나올 정도로 이것은 오래된 이슈입니다. 그리고 어렵기도 하죠.
저희는 지난 10년간 각 팀들이 서로 효율적으로 '함께' 일하는 방법에 대해 계속해서 실험하고 개선시켜 왔습니다. 많은 시행착오 끝에 지금은 각 팀의 전문성을 높이면서 병목은 제거하고 역할과 범위를 명확하게 구분해 팀 작업의 집중도를 높이는 나름의 시스템을 정착시켰습니다.
그리고 이러한 시스템 외에 팀 구성도 한 몫 하고 있습니다. 디자이너 출신 개발자, 개발자 출신 기획자, 코딩 역량을 가진 디자이너 등 바톤에는 다양한 배경의 팀원들이 많습니다. 이런 팀원의 존재는 팀 간의 이해도와 문화 형성에 큰 기여를 하게 됩니다. 당연하게도 많이 알 수록 서로를 존중하게 됩니다.
그 밖에도 여러 요소들이 있지만 개발 사이드에서 언급해보자면 단편적으로 개발팀은 개발 과정에서 고객사와 커뮤니케이션 하지 않습니다. 전화를 받을 일도, 이메일을 보내거나 미팅을 가는 일도 거의 없습니다. 간혹 어드민 인터페이스를 직접 디자인하는 경우는 있지만, 외부 디자이너가 전달한 (=의도를 확인하기 위해 다시 커뮤니케이션을 해야하는) PC 버전 시안의 태블릿 버전을 상상하며 구현하는 일은 없습니다. 다시말해 개발 효율을 떨어트리는 일, 개발자가 고객사 담당자를 설득하느라 시간을 보내는 것과 같은 일은 바톤에서 발생하지 않습니다. -언뜻 너무 당연하다고 생각하시겠지만 이것을 당연하게 만드는 데에 지금껏 많은 노력이 필요했습니다.
당연한 것을 당연하게 잘하는 것, 이것이 지속 가능하려면 구성원 간에 평등하고 존중하는 문화가 반드시 필요합니다. 이 부분에 대해서는 정말 자랑하고 싶은 부분이 많지만, 문장으로 표현하자니 좀 쑥스럽네요. 바톤의 인스타그램과 이어질 내용, 개발팀 TMI를 확인해주시기 바랍니다.
채용 면접에서 가장 자주 듣는 질문 중 하나인데요. 결론부터 이야기하자면 저희 개발팀은 풀-스택을 지향합니다.
이게 참.. 풀-스택이라고 하면 뭔가 거창해 보이지만―마치 마검사 같달까요― 저희가 하는 프로젝트는 '네카라쿠배' 규모가 아니어서 특성상 풀-스택을 지향하는게 맞다고 생각합니다. 게다가 node.js 등장 이후로 더욱 흐릿해진 프론트와 백의 경계는 최근 보급형 스펙인 next.js로 정점을 찍은 것 같습니다. 프론트가 SSR을 위해 GraphQL API를 구현하는 시기에 어디까지가 프론트고 백인지 나누는 것도 무의미하게 느껴진달까요?
가끔 채용 면접에서 만나는 부트캠프를 마친 지원자 분들이 캠프에서 백엔드 작업자들과 협업한 프로젝트에 대해 리뷰를 하실 때, 프론트를 맡았다는 이유만으로 스스로의 역할을 제한적으로 바라본다는 인상을 받은 적이 있습니다. ―실제로는 백-단을 하기에도 충분한 실력자였습니다.
바톤의 개발팀은 각자가 더 좋아하고 잘하는 분야는 있지만 한 명 한 명이 올라운드 플레이어를 지향합니다. 그래야 이슈가 있을 때, 같은 선상에서 같이 고민하며 함께 성장할 수 있다고 믿고, 그를 위해 계속해서 노력하고 있습니다.
웹 프로젝트에서 개발 프로세스는 대부분 3단계로 진행됩니다. (물론, 유형과 일정에 따라 일부 생략되거나 추가되기도 합니다.)
기획팀으로부터 ‘OOO 프로젝트 개발 가이드’라는 약 20-30페이지 분량의 구글 프리젠테이션 URL을 공유 받는 것으로 시작합니다.
이 개발 가이드는 말 그대로 개발 매뉴얼입니다. 사전에 요청한 운영서버, 도메인, 써드 파티 앱, 라이브러리, 관련 서비스 계정 등 모든 것이 들어있고 UI디자인팀에서 전달한 Figma URL이 각 디바이스별로 포함되어 있습니다.
나머지 페이지에는 각 페이지별로 구현할 때의 특이사항과 주의할 점 등이 작성되어 있고 이것을 리뷰하며 보다 상세한 개발 일정과 계획을 수립합니다.
대다수의 프로젝트들이 초기 기획과정에서 기술 스택을 정합니다. 하지만 점점 내용이 구체화되며, 실제 개발 단계에서는 다른 스택으로 변경될 수 있습니다. 2단계의 시작은 개발 서버를 설정하며 시작합니다.
저희는 가급적 새로운 방법과 기술을 지향합니다. 물론, 저희 모두가 모든 것을 다 아는 고오급 개발자는 아닙니다. 하지만 시스템의 안정성을 해치지 않는 범위 내에서 새로운 시도를 하는 것을 즐기며, 더 나은, 더 멋진, 더 편리한 시스템을 만드는 데 주저하지 않으려 노력합니다.
UI디자인팀이 만든 Figma 프로토타입은 매우 상세합니다. 개발 과정을 고려한 디자인과 사용성에 대한 고민의 흔적이 고스란히 결과물에 담겨있습니다. 저희는 이 이미지와 느낌이 그대로 고객에게 전달 될 수 있도록 UI디자인팀과 계속 소통하며 완성해나갑니다.
버전 관리는 Git을 사용하며, 매일 아침 스탠드업 미팅을 통해 하루 작업을 설계하고 공유합니다. 내부 이슈 트래커를 통해 이슈를 등록하고 작업을 진행합니다.
개발팀 내의 협업 방식은 계속해서 발전시켜 나가고 있습니다. 지금의 방식이 어느 정도 정착되기는 했지만 충분히 더 개선할 수 있다고 생각하고 꾸준히 시도하는 중입니다.
개발 서버에 가완성본을 올려 내부 공유를 합니다. 기획팀과 UI디자인팀의 내부 검수를 통해 고객사에 공유되며, 이후 QA과정이 시작됩니다. 이 과정이 사이트의 디테일과 성능을 끌어올립니다.
QA 종료 후에는 배포에 앞서 부하테스트를 진행하고, 각 프로젝트별 배포 전략에 맞게 배포를 진행합니다.
배포 후의 유지관리는 저희가 하는 경우도 있고 외부 다른 업체가 맡는 경우도 있습니다. 대부분은 저희가 진행하지만 신규 개발과 유지보수의 비율은 대략 9:1 정도로 유지보수 업무가 크지는 않습니다.
바톤에서 만든 사이트 수 대비 유지보수 업무가 크지 않은 이유는, 제작 시 대부분 고객사에서 수정이 가능한 형태로 만드는 것을 우선하기 때문입니다. 어떤 면에서는 유지보수 수익이 줄어드는 단점도 있지만, 고객사는 편리해서 좋아하고 저희는 신규 개발에 더 집중할 수 있어 장기적으로 더 효율적입니다.
팀 작업에서 주로 사용하는 기술과 이유를 간략하게 소개해보겠습니다.
#node.js #express/fastify #react #next #vue #nuxt #typescirpt etc.. javascript is everywhere.
일단은 이론의 여지 없이 JavaScript 입니다. 설명이 필요 없죠.
아주 특수한 경우를 제외한다면 웹 사이트는 결국 브라우저에서 돌아갈 수 밖에 없습니다. 그리고 웹 브라우저 환경에서 JS는 표현과 성능, 구현에 있어 필수 불가결한 존재입니다. 바톤은 프론트와 백 모두 적극적으로 JS를 사용하고 있습니다. ―특히 요즘은 JavaScript is everywhere.
팀 극초기에는 Angular에 대한 선호가 있었으나 Nuxt.js가 자리를 잡아가며 Vue를 이용해 쇼핑몰과 같은 큰 규모의 통합 프로젝트를 많이 진행했습니다. 하지만 채용 시장의 대세는 React 이기에.. 현재는 Next.js로 대동단결!을 추구하고 있습니다.―개인적으로는 여전히 Vue를 좋아합니다...(뷰럽)
그 다음은 역시 PHP입니다. PHP만큼 호불호와 논란이 많은 언어도 없을 겁니다. 하지만 웹 에이전시 씬에 있으면서 PHP를 못할 수는 있어도 . ―저 역시 PHP가 잘 설계된 언어라고 생각하지는 않지만 일반적인 범주의 웹사이트를 다루기에는 좋은 언어라고 생각합니다. 모든 언어와 프레임워크가 그렇지만 적절한 곳에 잘 사용하면 그만입니다.
크고 강력하며 오픈된 플러그인 생태계를 갖춘 WordPress는 1년에 다량의 사이트를 만들어야 하는 웹 에이전시들에게는 필수 불가결한 존재입니다. 정기적인 메이저 업데이트와 표준화된 코드는 에이전시가 변경되더라도 운영이 가능해 고객사의 선호가 높습니다.
저희는 WordPress를 Laravel처럼 하나의 프레임워크로 사용합니다. 유료 테마를 구매해 디자인을 변경한다거나 플러그인들로 꽉 채우는 방식을 쓰지는 않고, 주로 관리자 인터페이스나 API 관리용으로 쓰며 빈 테마를 이용해 바닥부터 새로 빌드하는 방식을 선호합니다.
Cafe24 Eco-System, Cafe24는 국내 이커머스 솔루션 업계에서 70% 이상을 차지하고 있는 쇼핑몰 솔루션입니다. Skin이라고 불리는 템플릿 베이스의 테마를 이용해 쇼핑몰을 손쉽게 구현할 수 있습니다. 저희가 작업하는 됩니다.
Cafe24는 국내 쇼핑몰 솔루션 중에서는 API를 가장 적극적으로 지원하고 있습니다. 그리고 바톤은 Cafe24 커스터마이징으로 제법 알려져있습니다. 별도의 서버와 DB를 이용해 기본적으로 제공하는 Cafe24 스킨의 한계를 확장해 기능을 구현합니다. 그래서 모든 팀원은 Cafe24 템플릿 작성 규칙과 API 활용에 능숙해야 합니다.
물론 하나의 언어만 사용하는 기업은 없겠습니다만, 적어도 자사 프로덕트가 있는 기업이라면 주가 되는 언어는 있기 마련입니다. ―그것이 CTO의 취향이든 인력 구성의 영향이든― 하지만 저희는 프로젝트 주기가 상대적으로 짧고 포커스는 고객사이기 때문에 특별히 언어에 대한 고집이 없습니다. 쉽게말해 이길 수 있다면 어떤 무공이든 상관 없달까요. 그런면에서 개발 업계가 무림이라면 ''인 저희는 정파보다는 사파에 가깝지 않을까 생각해봅니다.
여러 이유로 Java와 Python을 백엔드로 사용하지는 않습니다. 취향을 비롯, 다양한 이유가 있지만 역시 가장 큰 이유는 ‘채용’이 어렵다는 점이 있습니다. ―JAVA가 대세인 국내 IT기업 채용 시장을 고려하면 의외라고 생각하실 수 있겠으나 이 부분에 대해선 나중에 따로 글을 작성해 올려보고 싶네요.
바톤의 공식 사이트 또는 인스타그램에 가시면 느끼시겠지만 감사하게도 정말 다양한 분야의 고객사가 찾아주셔서 특별히 어떤 분야, 작업을 주로 한다고 이야기하기가 어렵습니다.
하지만, 한 가지 공통점은 디자인에 대한 가치를 중시하고 기민한 고객사들이 주를 이룬다는 것입니다. 웹 사이트를 만들지만 동시에 한 명의 사람으로서 다른 분야의 전문가들에게 많이 배우게 됩니다. 실제로 고객사 관계자 분들이 더 편리하고 효율적으로 일할 수 있는 시스템을 제작하기 위해서는 그 분들이 일하는 방식을 이해해야 하고 해당 도메인에 대해 공부해야 합니다. 이 과정에서 발생하는 경험과 인사이트가 저에게는 굉장히 소중하게 다가옵니다.
물론, 모든 작업들이 그런 경험을 가져다 주지는 않습니다. 그리고 실제 업무도 언제나 이상적으로 흘러가지는 않습니다. 하지만 저희는 지금까지 멋진 고객사들과 함께 성장해왔고 앞으로 만나게 될 새로운 분야가 늘 기대됩니다.
앞서 언급했듯이 저희는 풀-스택, 올-라운드 플레이어를 지향합니다. ―여기까지 읽으신 분이라면 저희가 이야기하는 풀-스택이 어떤 의미인지 아시리라 믿습니다!― 물론, 모든 구성원이 백-엔드 아키텍처에 능숙하고 인터페이스 구성이나 서버 관리를 전문적으로 할 수 있는 것은 아닙니다. 하지만 이는 경계를 두지 않는다는 의미입니다. 저희는 프레임워크보다는 웹이라는 생태계를 이해하고 계속해서 전반적인 원리를 습득하려고 노력합니다.
그래서 역으로 바톤의 개발자는 모두 CSS 전문가여야 합니다.
가끔 테크 커뮤니티에 올라오는 글 중 'React를 잘한다고 하는데 JS를 못하고, CSS 프레임워크를 사용해 깔끔한 포트폴리오를 들고 왔지만 직접 CSS 구현은 너무 미숙한 주니어'에 대한 이야기들을 접할 때가 있습니다.
웹 개발자의 근간을 논할 때, 많은 요소가 있겠지만 가장 저평가되어있는 요소가 CSS라고 생각합니다. 때론 CSS 문법을 이해한 것을 마스터했다고 생각하는 경우가 있습니다. CSS는 경험이 필요합니다. 문법의 구성 원리가 쉬운만큼 자유롭고 그래서 방대합니다. 다양한 브라우저와 파편화된 모바일 디바이스, 윈도우와 맥, 같은 모양 다른 구현, “제 컴퓨터에서는 되는데요!?”의 대표적인 언어가 바로 CSS입니다.
사이트의 모양새와 세부 디테일을 결정하는 가장 큰 요소 중 하나가 CSS이며, 이는 전문 영역 입니다. 저희 팀은 이런 CSS와 같은 기본기를 우대합니다. JS도 React의 상태관리나 Vitual DOM의 구현원리를 이해하는 것도 물론 중요하지만 JavaScript라는 언어의 기본 문법과 브라우저 API, 비동기 처리, 이벤트 핸들링 등 원칙에 대한 이해가 우선되야 한다고 생각합니다.
그리고 성장에 대한 동기부여를 스스로 할 줄 알아야 합니다. 작업을 하며 새로운 도전을 하는데 주저하지 않기 위해서는 작업을 개인의 성장으로 연결할 수 있어야 합니다. 이것은 매우 중요합니다. 이 부분에 따라서 바톤은 최고의 놀이터가 될 수도 있고, 매 프로젝트가 고통일 수도 있습니다.
그렇다고 바톤의 개발자가 모두 기본기가 출중하고 어마어마한 풀-스택 개발자인가?! 물론 아닙니다. ―저 조차도 매일 좌절하고 배우고 노력합니다. 하지만 성장의 방점을 이렇게 설정하고 나아가고 있다!고 봐주시면 될 것 같습니다.
저희 팀은 새로운 멤버가 합류하면 두 권의 책을 권합니다. 한 권은 앤드류 헌트와 데이비드 토마스의 “실용주의 프로그래머(The Pragmatic Programmer)”이고 다른 한 권은 김창준 님의 “함께 자라기 : 애자일로 가는 길” 입니다. ―만약 이미 읽으셨다면 같이 한 번 더 읽습니다!―
대부분의 경우 바톤이 하는 일은 결국 '문제를 해결하는 것'입니다. 디자이너와 개발자가 다른 점이 있다면, 우리는 그것을 코드를 통해서 할 뿐입니다. 두 권의 책은 소프트웨어 개발자로서 주어진 문제를 가장 효과적으로 해결할 수 있는 접근 방법과 태도에 관한 지침을 제공합니다. 그리고 어떻게 협력하고 성장할 것인가에 대한 가이드가 저희 팀이 지향하는 점에 많은 영감을 주었습니다.
바톤의 개발팀은 실용주의적 관점에 완벽히 동의하며 빠르게 변화하는 환경에서 유연함을 갖추기 위해 노력합니다. 언제나 효율을 중시하지만 개인의 성장이 곧 팀의 성장임을 인지하고 실전과 훈련을 구분짓지 않습니다. 성장의 기회를 위해 서로를 배려하고 신뢰할 수 있는 문화를 만들어 갑니다.
그리고 이 모든 것의 종점에는 각자의 행복이 있습니다. 하루 중 가장 많은 시간을 함께 한다는 것은 곧 1년 중 가장 많은 시간을 보내는 것과 같고, 그 시간들을 좋은 사람들과 재밌는 일을 하면서 보내기를 희망합니다. 즐겁게 개발하는 것, 저희 팀에서 가장 중요하게 생각하는 가치입니다.
이 긴 글을 여기까지 읽어주셔서 감사합니다. 혹시- 저희와 함께 일하는 것에 관심이 있으신가요? 만약 그렇다면, 저희는 지금 채용 중입니다. 채용 페이지를 확인해주세요. 그리고 개발팀 TMI를 통해 사소하게나마 궁금하실 수 있는 저희 팀의 이모저모도 확인해보세요!
