좀 더 실제 케이스를 중심으로 살펴볼까요?

Kiaf SEOUL은 2002년 처음 문을 연 한국 최초의 글로벌 아트페어이며, 바톤은 2020년부터 매년 새롭게 Kiaf SEOUL의 웹사이트를 리뉴얼하고 있습니다.

저희는 Kiaf SEOUL 웹사이트에서 이루어지는 모든 과정을 설계하고 구현합니다.

• 수백 개의 갤러리와 연계된 수천 건의 작품을 업로드 할 수 있는 신청 플랫폼
• 신청된 정보를 바탕으로 평가하고 승인한 뒤, 동적으로 작성된 공문을 관리, 전송할 수 있는 시스템
• 각 갤러리들의 OVR을 제공하고 이를 관리하기 위한 인터페이스와 시스템
• 행사 시즌에 등록된 모든 아트웍에 대한 글로벌 트래픽을 받아내는 캐싱 시스템

짧게 나열한 것 외에도 VIP-Ticketing과 현장 스태프들을 위한 소프트웨어까지 다양한 시스템을 제작하고 있습니다.

즉, 디자인 포트폴리오 이면에 숨어있는 수많은 어드민 인터페이스와 기능도 저희의 구현 대상입니다.

기획자와 디자이너, 개발자가 같은 프로젝트 안에서 '잘' 일하는 방법에 대한 책이 나올 정도로 이것은 오래된 이슈입니다. 그리고 어렵기도 하죠.

저희는 지난 10년간 각 팀들이 서로 효율적으로 '함께' 일하는 방법에 대해 계속해서 실험하고 개선시켜 왔습니다. 많은 시행착오 끝에 지금은 각 팀의 전문성을 높이면서 병목은 제거하고 역할과 범위를 명확하게 구분해 팀 작업의 집중도를 높이는 나름의 시스템을 정착시켰습니다.

그리고 이러한 시스템 외에 팀 구성도 한 몫 하고 있습니다. 디자이너 출신 개발자, 개발자 출신 기획자, 코딩 역량을 가진 디자이너 등 바톤에는 다양한 배경의 팀원들이 많습니다. 이런 팀원의 존재는 팀 간의 이해도와 문화 형성에 큰 기여를 하게 됩니다. 당연하게도 많이 알 수록 서로를 존중하게 됩니다.

그 밖에도 여러 요소들이 있지만 개발 사이드에서 언급해보자면 단편적으로 개발팀은 개발 과정에서 고객사와 커뮤니케이션 하지 않습니다. 전화를 받을 일도, 이메일을 보내거나 미팅을 가는 일도 거의 없습니다. 간혹 어드민 인터페이스를 직접 디자인하는 경우는 있지만, 외부 디자이너가 전달한 (=의도를 확인하기 위해 다시 커뮤니케이션을 해야하는) PC 버전 시안의 태블릿 버전을 상상하며 구현하는 일은 없습니다. 다시말해 개발 효율을 떨어트리는 일, 개발자가 고객사 담당자를 설득하느라 시간을 보내는 것과 같은 일은 바톤에서 발생하지 않습니다. -언뜻 너무 당연하다고 생각하시겠지만 이것을 당연하게 만드는 데에 지금껏 많은 노력이 필요했습니다.

당연한 것을 당연하게 잘하는 것, 이것이 지속 가능하려면 구성원 간에 평등하고 존중하는 문화가 반드시 필요합니다. 이 부분에 대해서는 정말 자랑하고 싶은 부분이 많지만, 문장으로 표현하자니 좀 쑥스럽네요. 바톤의 인스타그램과 이어질 내용, 개발팀 TMI를 확인해주시기 바랍니다.

프론트와 백-엔드 개발자 비율?

채용 면접에서 가장 자주 듣는 질문 중 하나인데요. 결론부터 이야기하자면 저희 개발팀은 풀-스택을 지향합니다.

이게 참.. 풀-스택이라고 하면 뭔가 거창해 보이지만―마치 마검사 같달까요― 저희가 하는 프로젝트는 '네카라쿠배' 규모가 아니어서 특성상 풀-스택을 지향하는게 맞다고 생각합니다. 게다가 node.js 등장 이후로 더욱 흐릿해진 프론트와 백의 경계는 최근 보급형 스펙인 next.js로 정점을 찍은 것 같습니다. 프론트가 SSR을 위해 GraphQL API를 구현하는 시기에 어디까지가 프론트고 백인지 나누는 것도 무의미하게 느껴진달까요?

가끔 채용 면접에서 만나는 부트캠프를 마친 지원자 분들이 캠프에서 백엔드 작업자들과 협업한 프로젝트에 대해 리뷰를 하실 때, 프론트를 맡았다는 이유만으로 스스로의 역할을 제한적으로 바라본다는 인상을 받은 적이 있습니다. ―실제로는 백-단을 하기에도 충분한 실력자였습니다.

바톤의 개발팀은 각자가 더 좋아하고 잘하는 분야는 있지만 한 명 한 명이 올라운드 플레이어를 지향합니다. 그래야 이슈가 있을 때, 같은 선상에서 같이 고민하며 함께 성장할 수 있다고 믿고, 그를 위해 계속해서 노력하고 있습니다.

실제 개발 프로세스

웹 프로젝트에서 개발 프로세스는 대부분 3단계로 진행됩니다. (물론, 유형과 일정에 따라 일부 생략되거나 추가되기도 합니다.)

Step 1 : 프로젝트의 모든 것, 개발 가이드

• 기획팀으로부터 'OOO 프로젝트 개발 가이드'라는 약 20-30페이지 분량의 구글 프리젠테이션 URL을 공유 받는 것으로 시작합니다.
  

  

• 이 개발 가이드는 말 그대로 개발 매뉴얼입니다. 사전에 요청한 운영서버, 도메인, 써드 파티 앱, 라이브러리, 관련 서비스 계정 등 모든 것이 들어있고 UI디자인팀에서 전달한 Figma URL이 각 디바이스별로 포함되어 있습니다.

• 나머지 페이지에는 각 페이지별로 구현할 때의 특이사항과 주의할 점 등이 작성되어 있고 이것을 리뷰하며 보다 상세한 개발 일정과 계획을 수립합니다.

Step 2 : 코드 작성

• 대다수의 프로젝트들이 초기 기획과정에서 기술 스택을 정합니다. 하지만 점점 내용이 구체화되며, 실제 개발 단계에서는 다른 스택으로 변경될 수 있습니다. 2단계의 시작은 개발 서버를 설정하며 시작합니다.

• 저희는 가급적 새로운 방법과 기술을 지향합니다. 물론, 저희 모두가 모든 것을 다 아는 고오급 개발자는 아닙니다. 하지만 시스템의 안정성을 해치지 않는 범위 내에서 새로운 시도를 하는 것을 즐기며, 더 나은, 더 멋진, 더 편리한 시스템을 만드는 데 주저하지 않으려 노력합니다.

• UI디자인팀이 만든 Figma 프로토타입은 매우 상세합니다. 개발 과정을 고려한 디자인과 사용성에 대한 고민의 흔적이 고스란히 결과물에 담겨있습니다. 저희는 이 이미지와 느낌이 그대로 고객에게 전달 될 수 있도록 UI디자인팀과 계속 소통하며 완성해나갑니다.
  

  

• 버전 관리는 Git을 사용하며, 매일 아침 스탠드업 미팅을 통해 하루 작업을 설계하고 공유합니다. 내부 이슈 트래커를 통해 이슈를 등록하고 작업을 진행합니다.

• 개발팀 내의 협업 방식은 계속해서 발전시켜 나가고 있습니다. 지금의 방식이 어느 정도 정착되기는 했지만 충분히 더 개선할 수 있다고 생각하고 꾸준히 시도하는 중입니다.

Step 3 : 가완성본 그리고 배포

• 개발 서버에 가완성본을 올려 내부 공유를 합니다. 기획팀과 UI디자인팀의 내부 검수를 통해 고객사에 공유되며, 이후 QA과정이 시작됩니다. 이 과정이 사이트의 디테일과 성능을 끌어올립니다.
• QA 종료 후에는 배포에 앞서 부하테스트를 진행하고, 각 프로젝트별 배포 전략에 맞게 배포를 진행합니다.
• 배포 후의 유지관리는 저희가 하는 경우도 있고 외부 다른 업체가 맡는 경우도 있습니다. 대부분은 저희가 진행하지만 신규 개발과 유지보수의 비율은 대략 9:1 정도로 유지보수 업무가 크지는 않습니다.

{% hint style="info" %} 바톤에서 만든 사이트 수 대비 유지보수 업무가 크지 않은 이유는, 제작 시 대부분 고객사에서 수정이 가능한 형태로 만드는 것을 우선하기 때문입니다. 어떤 면에서는 유지보수 수익이 줄어드는 단점도 있지만, 고객사는 편리해서 좋아하고 저희는 신규 개발에 더 집중할 수 있어 장기적으로 더 효율적입니다. {% endhint %}

주로 사용하는 기술

팀 작업에서 주로 사용하는 기술과 이유를 간략하게 소개해보겠습니다.

JavaScript

javascript is everywhere.

일단은 이론의 여지 없이 JavaScript 입니다. 설명이 필요 없죠.

아주 특수한 경우를 제외한다면 웹 사이트는 결국 브라우저에서 돌아갈 수 밖에 없습니다. 그리고 웹 브라우저 환경에서 JS는 표현과 성능, 구현에 있어 필수 불가결한 존재입니다. 바톤은 프론트와 백 모두 적극적으로 JS를 사용하고 있습니다. ―특히 요즘은 JavaScript is everywhere.

PHP (7.4 higher)

그 다음은 역시 PHP입니다. PHP만큼 호불호와 논란이 많은 언어도 없을 겁니다. 하지만 웹 에이전시 씬에 있으면서 PHP를 못할 수는 있어도 안 할 수는 없습니다¹. ―저 역시 PHP가 잘 설계된 언어라고 생각하지는 않지만 일반적인 범주의 웹사이트를 다루기에는 좋은 언어라고 생각합니다. 모든 언어와 프레임워크가 그렇지만 적절한 곳에 잘 사용하면 그만입니다.

크고 강력하며 오픈된 플러그인 생태계를 갖춘 WordPress는 1년에 다량의 사이트를 만들어야 하는 웹 에이전시들에게는 필수 불가결한 존재입니다. 정기적인 메이저 업데이트와 표준화된 코드는 에이전시가 변경되더라도 운영이 가능해 고객사의 선호가 높습니다.

저희는 WordPress를 Laravel처럼 하나의 프레임워크로 사용합니다. 유료 테마를 구매해 디자인을 변경한다거나 플러그인들로 꽉 채우는 방식을 쓰지는 않고, 주로 관리자 인터페이스나 API 관리용으로 쓰며 빈 테마를 이용해 바닥부터 새로 빌드하는 방식을 선호합니다.

Cafe24 System

Cafe24 Eco-System, Cafe24는 국내 이커머스 솔루션 업계에서 70% 이상을 차지하고 있는 쇼핑몰 솔루션입니다. Skin이라고 불리는 템플릿 베이스의 테마를 이용해 쇼핑몰을 손쉽게 구현할 수 있습니다. 저희가 작업하는 쇼핑몰의 90% 이상은 Cafe24 환경에서 작업²됩니다.

{% hint style="info" %} Cafe24는 국내 쇼핑몰 솔루션 중에서는 API를 가장 적극적으로 지원하고 있습니다. 그리고 바톤은 Cafe24 커스터마이징으로 제법 알려져있습니다. 별도의 서버와 DB를 이용해 기본적으로 제공하는 Cafe24 스킨의 한계를 확장해 기능을 구현합니다. 그래서 모든 팀원은 Cafe24 템플릿 작성 규칙과 API 활용에 능숙해야 합니다. {% endhint %}

굳이 말하자면 우리는 사파?

물론 하나의 언어만 사용하는 기업은 없겠습니다만, 적어도 자사 프로덕트가 있는 기업이라면 주가 되는 언어는 있기 마련입니다. ―그것이 CTO의 취향이든 인력 구성의 영향이든― 하지만 저희는 프로젝트 주기가 상대적으로 짧고 포커스는 고객사이기 때문에 특별히 언어에 대한 고집이 없습니다. 쉽게말해 이길 수 있다면 어떤 무공이든 상관 없달까요. 그런면에서 개발 업계가 무림이라면 '에이전시 디벨로퍼agency developer³'인 저희는 정파보다는 사파에 가깝지 않을까 생각해봅니다.

주로 하는 작업들

바톤의 공식 사이트 또는 인스타그램에 가시면 느끼시겠지만 감사하게도 정말 다양한 분야의 고객사가 찾아주셔서 특별히 어떤 분야, 작업을 주로 한다고 이야기하기가 어렵습니다.

하지만, 한 가지 공통점은 디자인에 대한 가치를 중시하고 기민한 고객사들이 주를 이룬다는 것입니다. 웹 사이트를 만들지만 동시에 한 명의 사람으로서 다른 분야의 전문가들에게 많이 배우게 됩니다. 실제로 고객사 관계자 분들이 더 편리하고 효율적으로 일할 수 있는 시스템을 제작하기 위해서는 그 분들이 일하는 방식을 이해해야 하고 해당 도메인에 대해 공부해야 합니다. 이 과정에서 발생하는 경험과 인사이트가 저에게는 굉장히 소중하게 다가옵니다.

물론, 모든 작업들이 그런 경험을 가져다 주지는 않습니다. 그리고 실제 업무도 언제나 이상적으로 흘러가지는 않습니다. 하지만 저희는 지금까지 멋진 고객사들과 함께 성장해왔고 앞으로 만나게 될 새로운 분야가 늘 기대됩니다.

바톤의 개발자

앞서 언급했듯이 저희는 풀-스택, 올-라운드 플레이어를 지향합니다. ―여기까지 읽으신 분이라면 저희가 이야기하는 풀-스택이 어떤 의미인지 아시리라 믿습니다!― 물론, 모든 구성원이 백-엔드 아키텍처에 능숙하고 인터페이스 구성이나 서버 관리를 전문적으로 할 수 있는 것은 아닙니다. 하지만 이는 경계를 두지 않는다는 의미입니다. 저희는 프레임워크보다는 웹이라는 생태계를 이해하고 계속해서 전반적인 원리를 습득하려고 노력합니다.

그래서 역으로 바톤의 개발자는 모두 CSS 전문가여야 합니다.

가끔 테크 커뮤니티에 올라오는 글 중 'React를 잘한다고 하는데 JS를 못하고, CSS 프레임워크를 사용해 깔끔한 포트폴리오를 들고 왔지만 직접 CSS 구현은 너무 미숙한 주니어'에 대한 이야기들을 접할 때가 있습니다.

웹 개발자의 근간을 논할 때, 많은 요소가 있겠지만 가장 저평가되어있는 요소가 CSS라고 생각합니다. 때론 CSS 문법을 이해한 것을 마스터했다고 생각하는 경우가 있습니다. CSS는 경험이 필요합니다. 문법의 구성 원리가 쉬운만큼 자유롭고 그래서 방대합니다. 다양한 브라우저와 파편화된 모바일 디바이스, 윈도우와 맥, 같은 모양 다른 구현, “제 컴퓨터에서는 되는데요!?”의 대표적인 언어가 바로 CSS입니다.

사이트의 모양새와 세부 디테일을 결정하는 가장 큰 요소 중 하나가 CSS이며, 이는 전문 영역 입니다. 저희 팀은 이런 CSS와 같은 기본기를 우대합니다. JS도 React의 상태관리나 Vitual DOM의 구현원리를 이해하는 것도 물론 중요하지만 JavaScript라는 언어의 기본 문법과 브라우저 API, 비동기 처리, 이벤트 핸들링 등 원칙에 대한 이해가 우선되야 한다고 생각합니다.

그리고 성장에 대한 동기부여를 스스로 할 줄 알아야 합니다. 작업을 하며 새로운 도전을 하는데 주저하지 않기 위해서는 작업을 개인의 성장으로 연결할 수 있어야 합니다. 이것은 매우 중요합니다. 이 부분에 따라서 바톤은 최고의 놀이터가 될 수도 있고, 매 프로젝트가 고통일 수도 있습니다.

그렇다고 바톤의 개발자가 모두 기본기가 출중하고 어마어마한 풀-스택 개발자인가?! 물론 아닙니다. ―저 조차도 매일 좌절하고 배우고 노력합니다. 하지만 성장의 방점을 이렇게 설정하고 나아가고 있다!고 봐주시면 될 것 같습니다.

실용주의 프로그래머와 성장

저희 팀은 새로운 멤버가 합류하면 두 권의 책을 권합니다. 한 권은 앤드류 헌트와 데이비드 토마스의 “실용주의 프로그래머(The Pragmatic Programmer)”이고 다른 한 권은 김창준 님의 “함께 자라기 : 애자일로 가는 길” 입니다. ―만약 이미 읽으셨다면 같이 한 번 더 읽습니다!―

대부분의 경우 바톤이 하는 일은 결국 '문제를 해결하는 것'입니다. 디자이너와 개발자가 다른 점이 있다면, 우리는 그것을 코드를 통해서 할 뿐입니다. 두 권의 책은 소프트웨어 개발자로서 주어진 문제를 가장 효과적으로 해결할 수 있는 접근 방법과 태도에 관한 지침을 제공합니다. 그리고 어떻게 협력하고 성장할 것인가에 대한 가이드가 저희 팀이 지향하는 점에 많은 영감을 주었습니다.

바톤의 개발팀은 실용주의적 관점에 완벽히 동의하며 빠르게 변화하는 환경에서 유연함을 갖추기 위해 노력합니다. 언제나 효율을 중시하지만 개인의 성장이 곧 팀의 성장임을 인지하고 실전과 훈련을 구분짓지 않습니다. 성장의 기회를 위해 서로를 배려하고 신뢰할 수 있는 문화를 만들어 갑니다.

그리고 이 모든 것의 종점에는 각자의 행복이 있습니다. 하루 중 가장 많은 시간을 함께 한다는 것은 곧 1년 중 가장 많은 시간을 보내는 것과 같고, 그 시간들을 좋은 사람들과 재밌는 일을 하면서 보내기를 희망합니다. 즐겁게 개발하는 것, 저희 팀에서 가장 중요하게 생각하는 가치입니다.

Next

이 긴 글을 여기까지 읽어주셔서 감사합니다. 혹시- 저희와 함께 일하는 것에 관심이 있으신가요? 만약 그렇다면, 저희는 지금 채용 중입니다. 채용 페이지를 확인해주세요. 그리고 개발팀 TMI를 통해 사소하게나마 궁금하실 수 있는 저희 팀의 이모저모도 확인해보세요!