함께 자라기, 함께 잘하기

쓱닷컴 검색팀의 지난 10개월 간의 함께 성장하고 성공하는 문화를 만들기 위한 여정

안녕하세요. 검색팀 백승걸입니다.

2020년 11월 24일
검색 기획, 개발, 원부 파트로 각기 다른 조직에 있던 인원들이 하나의 팀이 되었습니다.

(2021년 11월 현재는 추천파트도 합류해서 검색추천팀이 되었습니다!)

그리고 당면한 과제,

1. 검색 내재화 모듈 안정화
2. MSA 확대 및 구조 개선
3. 오픈마켓, 원부 매칭 시스템 오픈

팀이 생기면서 받은 과제는 다음 세가지 였습니다.

1. 제품을 기반으로 처음부터 끝까지 책임지는 하나의 팀
2. 엔지니어링이 방향성을 주도할 수 있고 일회성이 아닌 지속가능한 제품을 만들어 나가는 팀
3. 검색 실패 페이지 없도록 해주세요(!)

오늘의 글은 앞의 1,2 번을 위해 저희가 한 노력입니다.

3번은 시간이 된다면 나중에 한번 써보겠습니다.

팀 결성과 함께 바로 1대1 면담을 한사람씩 했습니다.

1. 어떤 팀 문화를 만들고 싶은가?

2. 팀과 개인 모두 어떻게 성장하고 싶은가?

함께 일하는 문화

1. 서비스의 기획, 개발, 오픈까지 다 같이 하고 싶다

2. 코드 리뷰, 페어 프로그래밍

3. 내가 한 일에 대해 동료들에게 피드백 받고 싶다

4. 거리낌 없이 아이디어 내고 서로 대화하고 그걸 서비스에 녹이고 싶다

탈 SI 문화

1. 일정이 우선인 문화에서 일하고 싶지 않다

2. 사람들을 이리 붙였다가 저리 붙였다가 하는 문화에서 일하고 싶지 않다

3. 팀원의 멘탈을 잘 챙겨주는 문화

자유로운 스터디

1. 스터디 자유롭게 개설하고 함께 공부할 수 있는 문화를 만들고 싶다

2. 업무중에 학습하는 것이 부자연스럽지 않은 문화

어찌보면 참 별 것 아닌데, 열심히 회사의 성장만 챙기다보니 놓치고 온 것들이 많았습니다. 그런것들을 재조명 할 수 있는 시간이었습니다.

우리는 기존 질서를 혁파하고, 새로운 방식으로 일하겠다! 라는 목적의식을 고취시키기 위해서 일단 팀 슬로건 부터 만들었습니다.

검색팀 슬로건

그래서 어떤 팀 문화를 만들것인가?

크게 한 4가지 정도로 목표를 잡았습니다.

1. 정보를 잘 기록하고 공유해서 휘발성 문서들이 양산되고 버려지는 걸 막고,
2. 좋은 제품팀을 만들기 위해 노력하고,
3. 팀의 엔지니어링 성숙도를 올리기 위한 노력을 많이 했고,
4. 팀원의 삶을 단순화 하기 위해 여러가지 자동화를 좀 했습니다.

정보의 기록과 공유

노션을 이용해 처음 만들어본 팀 위키

각자 개별적으로 사용하고 있던 노션을 이용해 팀 위키를 만들었습니다.

회사에서 기존에는 레드마인을 이용해서 서로 티켓을 주고받는 형태로만 일했던 것에서 벗어나서, 각종 정보들을 주고받고 정리하고 저장하고 전파하는 식으로 팀 문화를 만들었습니다.

• Wiki
• 팀원 소개
• 스터디, 세미나, 기타 정책서와 공유 문서
• 팀 정산 같은 것들
• 포스트모템, KPT

네 저는 ENTP 앱등이 입니다…

좋은 제품팀 만들기

제품 관리자

먼저 팀내의 기획자들을 제품 관리자라고 부르기 시작했습니다.

기획자 무용론 뭐 이런 이야기 많이 나오는데, 절대 아니라고 생각하고, 결국 프로세스의 문제라고 생각합니다만, 항상 일하면서 느낀점이 서비스 기획자란 용어로 인해 제품의 기획이라는 것이 오롯이 기획자만의 롤 처럼 받아들여지는게 아닐까라는 생각을 많이 했습니다.

기존에 서비스 기획 끝나면 개발 들어가는 방식에서, 아이디어가 생기면 같이 논의하다가 유저스토리 작성하면서 개발을 바로 시작하고, 서로 계속 피드백 주고 받다가 오픈 하는 식으로 프로세스를 좀 줄였습니다.

또한 PPT 기획서 작성하는 물리적인 시간을 줄이려고 노력했습니다.

• 발표 용 툴인 PPT 만드느라 드는 쓸데없는 시간 줄이고, 그 남는 시간에 서로 커뮤니케이션하고, 왜 이 기능이 필요한지에 더 집중하고,
• 윗사람에게 보고 하는 시간에 PM 들 끼리 혹은 개발자 포함해서 같이 아이데이션 하고 피드백 하도록 하구요.
• 문서 파일 레드마인에 업로드하고 휘발되는 것보다 더 생산적인 방식들을 찾았습니다.
• 피그마, 지라, 노션(현재는 컨플루언스), 미로 등을 적극적으로 활용했습니다.

실제 지라에 사용되는 유저스토리

피그마 디자인 예시

그 다음으로 제품 로드맵을 만들었습니다.

처음에는 트리 형태로 만들었었는데, 살을 계속 붙이고 있습니다.

제품 로드맵은 보여드릴 수 없는 점 양해 바랍니다.

저희는 저런 일들을 하고 있습니다 :)

저희팀은 고민끝에 칸반을 사용하기로 했습니다.

• 칸반은 쉽습니다. 워터폴 하던 팀들도 바로 적용이 가능합니다.
• 개발과 운영을 함께 하는 DevOps 환경에서는 칸반이 좀 더 편리합니다.
• 추정은 너무 어렵습니다. 스크럼은 추정이 잘되어야 하는데, 데이터를 많이 볼 수 밖에 없는 업무 특성상 추정을 하기가 쉽지 않습니다.
• 병목 지점을 찾아서 자원의 낭비를 없애고 효율을 높이는 것을 최우선 으로 목표로 했습니다.

다음으로 회고하는 문화 입니다.

좋은 점은 계속하고, 아쉬운 것들은 다른 방식으로 끊임없이 개선을 추구하려고 하고 있습니다.

칸반을 사용하기 때문에 각자 케이던스가 다르므로 프로젝트 별, 주별 회고등으로 진행하고 있습니다.

회고 프로세스는 팀원들의 만족도가 아주 높은데,
좀 더 많이 그리고 자주 할 수 있었으면 좋겠어요

회고는 KPT를 이용해서 하고 있습니다.

좋은 개발팀 만들기

Dirty and Fast Code의 끝에는 지옥이 기다립니다

빨리갈 수 있는 유일한 길은 제대로 가는 것이다.

제가 정말 존경하는 엉클 밥의 말 입니다.

먼저 지속가능한 개발을 위해서 많은 노력을 했습니다.

1. 빠른 배포

기존에 레거시에서 젠킨스 들어가서 버튼 누르고 기다리는 시간을 줄이기 위해, 브랜치가 머지되면 바로바로 자동으로 배포하도록 모든 프로세스를 만들었습니다.

주 1회로 정기배포 시간이 있는데, 그때는 배포요정이라는 툴을 만들어서 자동으로 배포하도록 했습니다.

MSA 환경의 이점도 있지만 아무튼 레거시 서버처럼 늦게 로드되는 일은 절대로 없게 했구요.

2. 깃 플로우

검색 개발 파트 시절부터 필요에 의해 사용하기 시작했고, 팀 결성 이후 완전히 정착이 되었습니다. 깃 플로우를 설명하는 내용은 아니니까 자세한 것은 생략하도록 하겠습니다.

일단 Dev, Stg, Release, Master 정도로 운영하고 있고,

개발자들은 각자 브랜치를 생성하고 원격 저장소에 머지하도록 했구요

문제 발생시에는 본인이 개발한 부분만 뽑아내면 되니까 아주 편리합니다.

3. 작은 피처단위의 개발

하향식 설계 (첨부터 위에서부터 한꺼번에 몽땅 설계) 같은건 절대로 존재하지 않는다는건 아무리 강조해도 지나침이 없다고 생각합니다.

짧은 주기마다 작은 단위로 개발해서 피처가 늘어날때마다 설계가 완성되고 주기적인 리팩터링을 통해서 다시 또 설계가 좋아지는 것을 추구하고 있습니다.

개발자는 코드 변경을 절대 겁내서는 안됩니다. 그런 환경을 만들기 위해 많은 노력을 했습니다.

4. 코드 리뷰 문화

코드 리뷰는 소프트웨어의 지속적인 품질 향상을 위한 가장 최소한의 시작점입니다.

PR을 한사람도 받은 사람도 서로에게 무한히 배울 수 있습니다.

저렇게 불친절하게 달면 안되요!

5. 습관적인 테스트 코드

일단 함수의 단위 테스트 기반으로 테스트 커버리지를 잡고 있고

테스트 코드가 없이는 PR을 승인하지 않도록 하고 있습니다

언젠가는 ATDD나 BDD가 아주 자연스럽게 될 수 있는 아름다운 날을 기대하고 있습니다.

6. 리팩터링

날 잡아서 하는 것도 아니고, 일정을 따로 빼는 것도 아니고,

당연히 항상 하는 겁니다.

아침에 일어나서 마당을 쓸듯이 습관처럼 할 수 있도록 많은 노력을 기울이고 있습니다.

7. 컨벤션

표준화를 그렇게 좋아하지는 않지만 그래도 컨벤션은 좀 많은 것들을 강제화 했습니다.

개발팀 사이에서 커뮤니케이션을 위한 최소한의 예의라고 생각했습니다.

• Code Style Scheme
• Commit Message
• Branch Naming
• Class Naming,
• Entity Naming
• Code Review

코드 스타일 컨벤션

깃 커밋 메시지 컨벤션

코드 리뷰 컨벤션

그리고 코드의 공동소유를 들 수 있습니다.

저희는 페어제도라는걸 운영하고 있습니다.

• 하나의 업무를 최소 둘이서 진행하도록 최대한 맞추고 있고,
  커뮤니케이션을 통한 코드, 설계에 대해서 책임을 공동으로 가지게 하고 있습니다.
• 자연스럽게 PP도 하구요. 코시국이라 재택으로 인해 아주 간편하지만은 않습니다.
• 장기적으로 봤을때는 팀에서 생성되는 모든 코드는 팀의 소유이고, 팀원들이 최소한 조금씩은 모두 알아야 합니다.
• 그래서 새로운 설계나 프로젝트가 종료되면 모두 모여서 코드 리뷰를 하거나 아키텍처 설명을 하는 시간을 갖도록 하고 있습니다.

또한 개발 공감 미팅도 가급적 주기적으로 진행하고 있습니다.

• 현재 운영 중이거나 진행중인 프로젝트의 아키텍처, 코드 단체 리뷰를 주로 하고 있고,
• 시간될때 몹코딩이나 몹 리팩터링은 기획하고 있는데 역시 코시국이라 어렵습니다.
• 한두번 해봤는데 아주 대환장 파티였습니다. 그래도 발표자 한명 빼면 정말 재미 있었습니다.

같은 모듈을 다른 사람이 전면 재작성 하는 것도 장려하고 있습니다.

• 기술은 계속 변하고 있고, 업무도 변하구요. 기술부채를 걷어내느라 리팩터링 하는 것도 좋지만 남이 만든 코드를 받아서 아얘 새로 짜보는 것도 코드에 대한 애정이나 이해도도 높아지고 매우 좋습니다.
• 새로운 기술이나 아키텍처를 이용해서 완전히 새롭게 문제를 해결할 수도 있습니다.
• 실제로 구글에서도 매우 장려하고 있는 방법입니다.

다음은 맹목적인 데이터 베이스 기반 디자인을 피하자 입니다.

• 제가 많이 하는 말이긴 한데, 개발자는 절대 SQL Mapper가 아닙니다.
• 쿼리 깎는 장인도 노인도 아니구요.
• 쿼리 결과 DTO를 만드는 사람도 아닙니다.
• 이렇게 되면 테스트 코드를 만들고 데이터 베이스를 목킹할 수가 없어요.
• 로직이 DB 에 다 들어있고 결과만 받으면 객체지향이 무슨 필요가 있겠습니까…

그리고 모던한 개발을 끊임없이 추구하도록 노력하고 있습니다.

• CQRS, 이벤트 소싱 뭐 이런것도 그렇고 검색 엔진은 기본적으로 조회와 저장이 분리될 수 밖에 없는 구조라 워낙 친숙하기도 하구요.
• 대규모 시스템을 다루는 다양한 관점이 있으니까 이것들에 대해서 공부하고 토론하고 사용해보고 실패해보고 성공해보는 기회가 충분해야 한다고 봅니다.
• 좀 Data Storage 관점에서의 DB를 바라보는 관점들.
• RDB 나쁘다는 이야기 절대 아닙니다. 오해 마시길.
• 대신에 RDB는 우리가 사용하는 객체와 딱 맞지 않아서 벌어지는 현실적인 설계 이슈같은 걸 말하고 싶습니다.
• 그래도 좀 더 객체 지향적이고 깨끗한 코드들 도메인 주도의 디자인들 그리고 함수형 프로그래밍이나 리액티브 같은 기술들.
• 이런 노력들이 결국에는 지금 우리에게 있는 어려운 문제들을 해결하기 위함이고,
• 한마디로 개발자는 결국 어려운 문제를 해결하는 사람이어야 합니다
• 개발자에게 수정은 당연한 거고 우리는 그걸로 월급 받고 있구요.

세번째는 실패에 대해서 좀 다른 관점에서 보자 입니다.

• 실리콘 밸리에서는 포스트모템이라는 말을 하는데,
• 이를 설명하기 위해 가장 좋은 말이 외발자전거로 피자 배달하다 떨어뜨린 배달원은 잘못이 없다는 말을 많이 합니다.
• 실패에 대해서 항상 실패한 당사자가 평소에 긴장하고 잘했어야 하고 문책하고 담부터 잘하자가 아니고, 왜 장애가 나기 쉬운 환경이 되었는지 이 환경을 해소할 수는 없는 건지에 좀더 집중하도록 하고 있습니다.
• 모든 상황을 개인적인 이유 즉 정신론으로 원인을 찾고 사람에게 책임을 지우고 문책을 하면 그 어떤 팀원도 모험을 안합니다.
• 새로운 도전을 하기에도 항상 위축되고 지나고 나면 결국 팀 전체적으로 보면 아무런 발전도 없구요.
• 이런 실패를 통해 배우고 개인에게 책임을 지우지 말자는 문화가 제일 중요하다고 보고있고 저희 포스트모템 문화의 핵심입니다. 장애를 축하하자 하고 실제로 박수도 몇번 쳤었는데, 좋은 효과는 없긴했어요.

실제 포스트모템 페이지

그리고 성장하는 팀 입니다.

• 개인의 성장, 팀의 성장, 그리고 나아가 회사의 성장
• 이 세가지 요소들의 성장의 방향을 맞추도록 하는게 저 같은 시니어가 해야 하는 일이라고 생각하고 있습니다.
• 저 자신을 포함해서 모든 팀원들이 성장할 수 있는 환경을 마련하고 성장의 멘탈리티를 심어주는게 정말 중요하다고 생각했습니다.
• 팀내 자발적인 스터디도 활성화 하고 있습니다.
• 팀에서 계속 4–5 개씩의 스터디가 진행중입니다.
• 책 읽기 모임 이라고 책 한권에서 정해진 챕터 정리해서 추첨을 통해 한명이 발표하고 토론하는 모임이 있구요
• 동영상 강좌 같이 보기 모임
• 케이스 스터디라고 해서 PM들이 주도해서 시장 현황이나 각종 이슈들을 소개하는 모임도 하고 있어요.
• 뭐든 꾸준하게 하는게 목표였는데, 아직까지는 너무 잘 되고 있습니다.

팀 스터디 진행

마지막으로 MSA를 향한 끊임없는 여정을 저희가 진행중 입니다.

• 다양한 언어 특히 자바랑 파이썬은 일단 기본적으로 왠만하면 다들 쓰고 있습니다.
• Golang 모듈은 이제 하나 남았네요..
• MSA가 목적이 아닌, 빠르고 간단한 배포, 빠른 실험, 유연하고 얕은 결합을 가진 구조를 항상 강조하고 있습니다.
• 또한 개발팀의 높은 책임과 자유를 부여하고 모듈 분리와 통합을 지속적으로 진행하고 있습니다. (가장 중요하다고 생각합니다)
• 그래도 스택이 목적인 형태는 가급적 말리고 있습니다. 나 이거 써봤다와 몇년간 트러블 슈팅해서 맷집이 높은것은 차원이 다른 앎이죠.

검색팀 BE 아키텍처

팀의 삶을 단순화 할 수 있는 아이디어를 적극적으로 채용하고 허용하고 있습니다.

• 우리의 업무환경을 편하게 하는 것은 무조건 선한거다라고 생각하고 있습니다.
• IT 업무는 창의적인 업무입니다. 무지성적이고 불필요한 시간을 줄이고 그 시간에 창의적인 일을 해야 합니다. 차라리 서비스 관련한 농담따먹기가 더 생산적일 수도 있어요.
• 배포요정 : 주 1회 자동 배포 툴
• 기술요정 : 기술 블로그, 컨퍼런스 소식 전달
• 스케줄 요정 : 팀 스케줄 (휴가, 반차, 기타 소식들) 알림이
• 결재 문서 자동 생성기 : 결재 문서에 첨부되는 엑셀 자동 생성
• 각종 업무용 툴들 : 업무 중 자주 찾는 사이트 크롬 익스텐션 등등

배포 요정

기술 요정

스케줄 요정

끝으로

• 저희 팀은 어찌되었건 이런 목표를 가지고 일하고 있고,
• 이런 프랙티스, 문화를 정착시키기 위해 많은 노력을 했습니다.
• 이게 베스트 프랙티스냐? 라고 하면 그건 절대 아니라고 생각하구요.
• 그냥 지금 있는 후보중에 가장 좋은 방법을 찾아가는 과정이라고 늘 생각하고 있고 말하고 지키고 있습니다. (Best Practice of Which!)
• 뭔가 가설을 세우고 검증하는데 팀 전체적인 논의 끝에 최선의 결과를 찾는데 주력하고 있습니다.
• 뭐 저희가 완벽하다 이런생각은 절대 안하고 있고 아직 할일도 많고 서툰부분들도 많습니다. 그래도 지난번에 했던 방식은 계속 측정하고 회고 할 거니까요. 다음 주, 다음달이 되면 더 나아지겠죠.

팀으로써 함께 자라고, 그리고 함께 잘해서 좋은 서비스와 좋은 시스템을 지속적으로 만들어나가는 것이 저희의 목표입니다.

그래서 저희는

• 항상 저희와 함께 일하실 분들을 찾고 있습니다!
• 회식자리에서도 개발/서비스 이야기 하실 멘탈을 가진 분
• 기술/서비스 욕심이 많고 주도적으로 일하는 것을 좋아하시는 분
• 스타트업 멘탈리티로 대기업에서 일하고 싶은 분
• 자연어처리, 대용량 데이터, 대규모 트래픽 처리에 관심이 많으신 분

감사합니다~