(흑백요리사 스포주의!)
초점: 우리 팀의 개발 문화
#자기소개
안녕하세요, 현재 e스포츠 데이터 분석 회사, 팀스노우볼에 다니고 있는 강민석입니다.
라이엇 게임즈 코리아, 크래프톤, KeSPA와 협력하고 있고요.
저는 현재 회사에서 프론트엔드로 시작해서 3년이 넘었어요.
오늘 할 이야기는…
우리 팀의 개발 문화라는 이야기를 듣고 개발이 프론트엔드 백엔드만 있는게 아니어서 코드리뷰나 이런 것도 좋지만 좀 더 넓은 의미로 제품을 만들 때 어떤 문화를 가지고 있는지 폭 넓게 이야기 하고 싶어요.
여기 오신 분들 중에 혹시 스타트업에 다니시는 분 있으신가요?
(빈화면에서 아래의 헤더가 나옴)
여러분들은 프로젝트를 몇 개나 다루시나요?
라이엇, 크래프톤, 케스파은 사실 회사 외주에 가깝고, 자사 프로젝트도 해야겠죠?
이렇게 프로젝트가 쏟아질 때, 개발자들 간의 고도한 테크닉이 필요합니다. 어떻게 균형을 유지하는지 이야기 해보죠.
에? 이게 뭐에유 이게… 아 어얽 뭐어옭 이거옭
(출처: 매일 경제)
(백엔드: 숟가락 들고 있는 사람 → 데이터: 빠스 → 프론트: 백종원)
본 이미지는 백엔드가 프론트엔드에게 데이터를 밀어넣어버릴 때 나타나는 일이죠.
가끔식 서버에서 주는 데이터가 프론트가 원하는 형태가 아닐 수 있어요. 여유가 있으면 BFF를 만들어서 조치를 취할 수 있겠지만 저희 회사는 백엔드가 바쁩니다. 데이터 분석 회사여서 프론트 API 데이터 만드는 것 외에도 DS나 협력 업체에서 요청한 데이터를 만들기 때문에 쉴 새가 없거든요. 다른 회사도 비슷할거라 생각해요.
가장 이상적인 인터페이스
제가 들었던 가장 이상적인 인터페이스를 만드는 과정은 작업하기 전에 백엔드와 프론트가 데이터를 어떻게 주고 받을지 의논을 해야하지만 현실에서는 이게 많이 어려워요. 백엔드도 기획대로 만들 수 있는지 확인을 해야하고 프론트도 데이터의 관계를 정하는 일보다 UI 깎는 노가다를 해야하고요. 완벽한 검토는 불가능에 가깝습니다.
6개월짜리 프로젝트도 반토막 내기
회사 프로젝트는 동시 다발적으로 각자가 여러가지 일을 하느라 서로가 어떤 일을 하는지 잘 챙길 수 없습니다. 그렇기 때문에 저희 팀은 각자의 영역을 신뢰하고 슬랙을 이용해서 동시 다발적으로 협업해요.
- 기획자가 전체적인 틀을 만드는 것을 시작으로 기획자는 디자이너에게 기획을 공유합니다.
- 디자이너는 그 전까지 제품 아이디어만 듣고 디자인 시스템을 구축합니다.
- 이때, 백엔드와 프론트는 아직 기획이 완성되지 않았기 때문에 잠시 정체합니다.
- 기획의 전체적인 틀이 완성이되면 디자이너는 전체적인 설명과 와이어프레임을 보면서 디자인을 시작합니다.
- 기획자는 상세 기획도 같이 들어가게 됩니다.
- 백엔드는 UI에 나올 데이터를 확인하고, 구현 가능한지를 검토합니다.
- 프론트엔드는 프로젝트의 특성을 파악한 뒤에 사용할 기술을 정의하고 디자인 시스템 작업에 들어갑니다.
- 디자이너가 페이지 하나를 컨펌을 받고 프론트엔드는 UI 작업에 들어갑니다.
- 그 사이, 백엔드에서 구현할 수 있는 API가 나오고 프론트엔드에서는 적용할 수 있는 검토합니다.
그 뒤부터는 자연스럽게 사이클을 반복하고, 구현하기 시작합니다.
여기서 저희 팀은 소통을 하기 위해 하나로 통일된 용어를 사용하게 됩니다. 기획자든, 마케터든, 프론트, 디자이너 모두 서버에서 관리하는 모든 명명 규칙은 백엔드에서 주는 명명 규칙을 따라가요. 백엔드는 외부 데이터를 정제해서 사용하기 때문에 용어를 불일치 시키면 서로 간의 오해가 발생하기 때문이에요. 예를 들어, 경기에서 사용하는 용어인 토너먼트, 매치, 라운드, 세트를 통일 시키는게 중요합니다.
위 캡처는 저희 회사에서 사용하는 평범한 스웨거입니다. 여기서 프론트엔드는 메서드, 엔트리, DTO 모두 서버에서 정의한대로에서 쓰고 있어요. 최대한 소통에 오해를 줄이고 효율적인 프로세스를 가져가기 위해서는 해당 방법이 꽤 효율적이었어요.
그러나,
프론트엔드 기준에는, 이 DTO는 even하게 익지 않았어요.
프론트엔드는 가끔 백엔드가 보내준 데이터를 보면서 생각합니다. 이거 어떻게 쓰라고 준거지?
그러나 프론트엔드는 백엔드의 상황을 조금이라도 이해할 수 있어야 합니다. 왜 이렇게 주는지 물어볼 수 있어요. 좋은 접근이에요. 그런데 들어도 이해가 안될 수 있어요. 여기서부터 프론트엔드와 백엔드는 서로를 회의실로 들어갑니다.
여기서 왜 이렇게 처리를 했는지를 묻기도 하지만 지금 이걸 가공해야 하는데 어디서 데이터를 다루는게 효과적인지 서로의 의견을 모아요. 대부분 이런 일은 기획이 수정하면서 생깁니다. 이미 만들어진 DB 테이블 때문에 데이터를 정제하기 어려울 수 있어요. 가급적이면 백엔드에서 모든 걸 처리해주는 이상을 꿈꾸기 보다 지금 현재 상황에서 시간 내에 맞추기 어려울 수 있고, 대부분 백엔드에서 안해주면 프론트는 손이 놀 수 있기 때문에 가장 합리적인 방법을 찾습니다.
근데 뭐가 막 이렇게 만들어서
위처럼 일반적으로 백엔드에서 정제할 작업도 프론트엔드에서 하는게 더 효율적이라고 한다면 저희는 기꺼이 프론트엔드에서 처리합니다.
저희 팀은 수정 피드백이 들어오면 최대한 귀를 열고 들어줍니다. 가끔 프론트엔드 때문에 기획이 바뀌기도 하고, 백엔드 때문에 디자인이 바뀌기도 합니다. 어쩔 때는 처음부터 다시 만드는 상황이 벌어질 수 있어요.
우리의 일은 병렬로 처리되지만 결국 하나로 병합될 수 밖에 없습니다. 여기서 하나라도 문제가 생기면 이어지지 않기 때문에 모두가 자신이 할 수 있는 배려를 봐주려고 합니다. 의미없는 언쟁을 하지 않고, 서로가 좋은 관계를 유지하고 서로에게 힘이 되어주고 싶기 때문에 제품의 그 익힘이 굉장히 타이트해집니다.
그 익힘이 굉장히 타이트해요
순식간에 제품을 만들고 QA 하면서 빠른 결과물을 타이트하고 맛있게 요리하는 방법에 대해서 소개하였습니다.
각자 회사마다 가지고 있는 실력과 성향에 따라서 알맞게 업무 프로세스를 유동적으로 가져갈 수 있나고 생각해요. 그 프로세스를 보고 유명한 프로세스들과 다를 수 있지만 다양한 시도 끝에 회사에 맞는 프로세스를 여러분도 함께하면 좋을 것 같아요.
아래는 안쓰는 내용입니다
CTO가 없으신 분들도 있을까요?
CTO가 없는데 IT 서비스를 한다구요? 신입으로 일하시는 분들도 계신데 정말 대단해요.
여러분들이 마주할, 어쩌면 마주하고 있는 이 환경에 어떻게 살아남을지 저랑 이야기 나눠봐요.
(이미지 보여주기)
(출처: 노컷뉴스)
혹시 여기 화면에 마늘 보이시나요? 결승에 올라가는 최초를 뽑는 그 중요한 순간에 최현석 셰프님이 마늘을 빼먹은 장면이죠.
마늘 없는 봉골레 / CTO 없는 개발팀
여기 Chat GPT에서 봉골레에서 마늘이 중요한 이유에 대해서 물어봤습니다.
봉골레에서 마늘은 재료 간의 균형을 맞춰서 전체적인 맛을 조화롭게 해주는 재료죠. 이 마늘이 마치 CTO처럼 느껴질 수 있겠다 싶어서 끼워맞춰봤어요. 비유한거니까 반박 시 여러분 말이 다 맞아요 👀
결승 진출자를 뽑는 자리에서 마늘 없이도 2위를 했던 최현석 쉐프처럼 저희 팀도 전체적인 균형을 맞춰주는 CTO가 없지만 개발자, 디자이너, PM, 기획자, 마케터 모두 팀원들이 서로 균형을 맞춰서 제품을 개발합니다. 이렇게 마늘 없는 개발팀이 생각보다 많다고 생각해요.
여기서 저희 팀의 생존 베이스가 있습니다.
회사는 여러분을 존중합니다. 근데 이제 배려를 곁들인.
첫번째는 회사에서 개발자들을 먼저 존중하고 믿어주셔야 합니다.