팀을 더욱 유연하게 만들어가는 힘

체계라 쓰지만 보이지 않는 환상속 기린 같은 단어를 팀에 어울리게 써보자

오인택, 홍재성, 최준영, 최우림, 우민식, 오대호 게시 날짜: 2022.02.28.

• 인사말
• 🌥 들어가며
• 😱 이슈가 있수다
• 😎 다양한 사람들
• 🚩 기준을 세우다
  • 함께하는 무리
  • 지식을 맞추어 가는 무리
    • 작업 대상 선정
    • 일정&대상자 선정
  • 표준을 맞추어 가는 무리
  • 체계를 만들어가는 무리
    • 코드 스타일
    • GIT
    • 코드 리뷰
    • 로그 전략
  • 문서를 공유하는 무리
    • 보드 템플릿
    • 스프린트
    • 이슈 유형
    • 지라 스토리 티켓 표준화
  • 구조를 만들어 가는 무리
    • 운영 대응 매뉴얼
    • 배포 기록서
  • 회의를 만들어 가는 무리
    • 스크럼
  • 버스터콜
• 👨‍👩‍👧‍👦 우여곡절끝에
  • 하나
  • 두울
  • 세엣
  • 네엣
  • 다섯
  • 여섯
• 🎉 마치며

인사말

컬리는 개성넘치는 많은 무리가(팀) 있습니다. 그중 우리는 물류개발에 집중하는 출고서비스개발팀에서(WMS) 피킹에 대한 전반적인 개발 및 유지보수를 담당하고 있습니다.

🌥 들어가며

수많은 스타트업에서 업무를 진행할 때 흔히 체계가 없고 힘들다 라는 이야기를 하거나 종종 듣게 됩니다. 저 역시 컬리에서 의욕을 불태우는 🔥 개발자 입장에서 체계가 없고 힘들다 라는 생각을 불현듯 하게 되었습니다. 하지만 일을 진행함에 있어서 누구나 어느 정도 인지하고 이야기로 공유되어 지켜지는 룰이 있었습니다. 문득 체계나 룰은 있는데 없다!? 생각이 들어 정리할 시간이 필요하다 느꼈습니다.

😱 이슈가 있수다

김포 물류센터 오픈이 눈앞에 다가올 무렵 많은 개발자분들과 촉박한 시간 속에 빠른 개발&QA를 위해 열심히 달리기만 했습니다. 당시 개발 중인 업무가 완료되면 남은 업무 목록 중 다음 일정이 촉박한 개발건을 가져가는 식으로 진행이 되었습니다. 이를 통해 겨우 무사히 오픈은 하였지만, 시스템을 사용하는 기간이 늘어가면서 산재된 위험요소가 서서히 드러나기 시작했습니다.

• 중복 개발과 저마다 즐기는 코드 스타일
• 결괏값이나 코드에 대한 정의 부족
• 이슈를 발 빠르게 대응하기 위한 로그 전략 부재
• 생각을 공유하고 어느 정도 실천하지만 정리되지 않은 체계

이외에도 도메인과 시스템에 대한 이해도 부족, 기획에 대한 변경 이력 추적 불가능 등 수많은 이슈가 하나씩 얼굴을 들고 있었습니다. 수많은 이슈와 함께 지속적인 보강작업을 진행하다 보니 어느덧 큰 이슈는 없게 되었습니다. 하지만 땜질식 개발로 빠른 배포를 진행하였기에 유지 보수가 버거워지고 있었습니다. 코드를 보면 오픈 당시의 고단함과 등골이 오싹할 정도의 피곤함이 밀려왔습니다. 시스템 유지 보수 및 확장에 드는 공수를 줄이기 위해서는 리팩토링은 필수적인 과정이기 때문에 우리의 기술 부채를 줄이고 시스템의 향상이 필요했습니다.

고민이 더해질 무렵 때마침 새로 무리에 합류한 개발자분들이 생겼습니다. 이번이 기회다 생각하게 되어 신규 입사자분들께는 업무 이해도를 높이고 기존 개발자분들과는 미뤄왔던 숙제를 해소할 명분이 생겼습니다. 저마다의 사연으로 똘똘 뭉친 시스템을 이번 과제를 통해 하나씩 해소하려 합니다.

😎 다양한 사람들

과제 진행에 앞서 다양하고 개성 넘치는 장인들의 현재 상태를 알아야 할 필요가 있었습니다.

	도메인 이해도	프로그램 이해도	장인 정신	비고
하나	중	중	땜질의 장인	아재 개그
두울	상	상	데이터베이스 장인	컬리에서의 오랜 경험
세엣	중	중	깔끔한 문서화 장인	목소리 좋음
네엣	하	중	로그 장인	TMI
다섯	상	하	테스트 코드 장인	도메인을 기본 탑재한 TMI
여섯	하	하	코드 장인	천상 개발자

그중 가장 먼저 생각된 부분이 도메인에 대한 이해도 부족 부분이었습니다. 저 역시 시스템 이해도가 낮은 상태로 개발만을 진행하였기에 조금 느리더라도 도메인 지식을 동일 수준으로 올리는 것을 첫 번째 목표로 시작하게 됩니다.

🚩 기준을 세우다

목적은 분명했으나 어떻게 진행할지에 대한 명확한 방향성이 필요하다. 진행전 사전 모의를 도모할 필요가 있다. 도메인 지식을 올리며 동시에 시스템 이해도를 높이기 위해서는 짝을 이루어 함께 진행하는 것이 좋지 않을까?

함께하는 무리

짝을 이루는 공동 작업.

과제 진행 전 우리는 몇 가지 기준을 세우게 됩니다. 각자의 장점을 살리기 위해 적게는 2명 많게는 3명까지 짝꿍을 이루어 진행하는 것으로 합의합니다. 그러기 위해서는 짝꿍을 이루는 무리에는 반드시 도메인 이해도가 중 이상인 인원이 포함되는 규칙을 정합니다.

출고 서비스팀에서 개발 요청 건이 나오면, 지라에서 티켓을 생성하고 티켓별로 두 명 혹은 그 이상으로 페어를 이뤄 페어 프로그래밍을 진행하게 됩니다. 툴은 인텔리 제이의 코드 위드 미로 진행하며, 호스트가 참여하고자 하는 팀원에게 링크를 공유하면서 동시에 개발을 진행할 수 있게 됩니다.

1. 페어 프로그래밍은 서로 다른 지식을 가지고 있기에, 서로의 지식을 공유.
2. 개발 중 의사결정에 있어 각자 같은 목표에 집중하여 빠른 의사결정.
3. 실시간 코드 리뷰가 가능하여 문제 접근 방식이나 변수명을 논의 가능.
4. 실제 키보드로 진행하는 사람은 기술적, 세부사항 등 작은 목표에 집중, 관찰자는 더 넓은 시야로 추가적 관찰 가능.

지식을 맞추어 가는 무리

프로세스 다이어그램을 도입하다.

함께하는 무리에서 도메인 지식을 끌어올릴 때 좋은 방법이 있을까 고민이 되었습니다. 물론 어떤 것이든 시작하고 보자는 생각도 들었지만 가급적 일에 대한 체계를 논하고 정하는 과정이 필요하였기에 고민이 되었습니다. 도메인 이해도가 중 이상인 분의 설명을 기준으로 진행해야 할까? 아니면 기획서를 확인한 후 물어보는 것이 효과적일까? 아니면 코드 분석 후 이야기를 해볼까?

장고의 시간 끝에 개발자스럽게 접근해 보는 건 어떨까? 라는 결론에 도달합니다. 프로세스 다이어그램을 API 단위로 그려보면 흐름이 자연스럽게 파악되어 도메인 지식을 올려나갈 수 있게 될 것 같았습니다.

작업 대상 선정

작업 대상을 선정하다.

현재 시스템은 모바일&관리자 API 영역을 같이 사용하고 있던 터라 관리자 영역을 분리하는 작업을 동시에 진행합니다. 그래서 리펙토링 과제 진행시 관리자 영역에서 진행할 목록을 취합하여 관리합니다.

일정&대상자 선정

시작과 종료를 명확하게 선정하다.

진행을 위한 기간 산정은 반드시 필요합니다. 하지만 개발자라면 누구나 일정 산정 부분은 불만이 있을 거라 생각했습니다.

• 종료일이 미리 확정되어 개발이 시작 -> 일정이 너무 타이트하다
• 본인이 종료일을 확정하여 개발이 시작 -> 더 손볼 곳이 보이는데 이렇게 마무리를 해야 하는 것은 아닌 것 같다.

어떻게 선정을 하게 되어도 약간이라도 볼멘소리가 나오는 게 당연하다 판단됩니다. 그래서 무리 내에서 진행하는 과제는 본인이 검토 -> 작업 범위 공유 -> 일정 공유 과정을 거쳐 일정을 산정하는 것으로 정하기로 합니다.

정 그리고 부

선정된 작업 목록 전체를 기준으로 마음에 드는 작업 대상을 선정합니다. 작업 대상은 쉽고 어렵고 등 고민할 필요는 없었습니다. 자사 서비스를 개발하는 입장이기에 자기 업무에 대한 욕심이 많습니다. 그래서 의욕 넘치는 장인들은 자기가 잘 모르거나 해보고 싶은 작업 영역을 원하는 만큼 그리고 어느 정도는 균등하게 자율 선택을 합니다. 그리고 짝을 이루어 진행할 대상자들을 정 과 부로 구분하여 업무 이해도가 중 이상인 대상이 포함되어 있는지 확인합니다. 작업별 담당자 확정과 짝꿍으로 이루어질 정 이 연결을 컨플루언스에 기록합니다.

표준을 맞추어 가는 무리

개선을 진행하기 위한 최소의 목표치를 정하다.

리펙토링 과제를 진행시 무엇인가 표준이라는 체계가 필요했습니다. 이번 작업으로 전체 시스템을 클린하고 유연한 소스로 단번에 개선할 수는 없지만, 캡슐화, 결괏값에 대한 규격, 부족한 밸리데이션 강화 등은 작업마다 필수로 할 수 있을 것 같았습니다. 그래서 최소한의 작업이 필요한 부분을 기준으로 공통되는 개선점을 선정하게 되었습니다.

• 밸리데이션 검증
• return type 개선
• 중복 코드 제거
• PageNation
• 테스트

체계를 만들어가는 무리

개발에 대한 체계를 확정하다.

시스템에 가장 큰 문제로 생각된 부분이 개발에 대한 체계가 있는데 없는 것 같은 애매한 경계에 있는 것이었습니다. 이를 해소하기 위해 보이지 않던 체계나 룰을 기록을 통한 수립이 필요했습니다.

코드 스타일

코드 스타일을 통일하다.

소프트웨어를 개발하는 일련의 모든 과정에 들어가는 비용 중 80%가 유지 보수에 쓰입니다. 컨벤션을 지키며 코드를 작성하면, 코드의 가독성을 증진시키고 협업 시 일관된 코드 스타일을 유지할 수 있습니다. 다른 개발자나 새로 입사한 개발자는 소스코드를 처음 보더라도 더 빠르고 완벽하게 이해할 수 있도록 코드 컨벤션을 구글 스타일을 채택하기로 결정합니다.

컨벤션을 정리할 때 여러 생각을 하게 되었습니다.

• 내용이 없거나 단 한줄에 해당하는 코드도 중괄호({}) 적용.
• tab으로 들여쓰기는 2개의 스페이스 적용.
• 오버로드는 순서대로.
• 코드라인은 100자까지 제한.
• import 작성은 와일드 카드(*) 제외.
• …

구글 스타일을 채택하게 된 이유는 우리가 일괄되게 작성 할 코드 규격의 정의가 대부분 적용되어 있기에 그저 빛인 구글님께 감사함을 전하며 약간의 수정만으로 사용하게 되었습니다.

GIT

GIT 브랜치 전략을 정리하다.

feature&dev&prod 브랜치만으로 작업을 하며 급하다는 이유만으로 upstream 을 바라보며 직접 개발을 강행하기도 했습니다. 이러다 보니 GIT에 대한 미안함이 밀려옵니다. 개발을 위한 브랜치와 개발/검증/스테이지 구분을 명확히 하고 개발에 대한 오너십을 조금 더 가져갈 수 있도록 전략을 수립합니다.

• master : 현재 운영 Product에 배포된 내용과 동일한 내용의 브랜치
• stage : 차기 운영 Product에 배포되기 전으로, 당장 내일 배포가 되어도 문제가 없는 브랜치
• qa : QA 검수를 받기 위한 브랜치
• feature : 신규 개발을 위한 브랜치

1. Jira에 티켓이 생성되면, 해당 내용에 대한 feature branch를 생성한다
2. 개발 완료 후 QA 일정이 확정되면 QA branch를 생성하고 소스를 병합한다
3. QA 검수가 완료될 동안, 개발자들은 QA branch에서 각자 개발한 소스를 병합한다
4. 만약 동시에 다른 QA가 진행될 경우, 새로운 QA branch를 생성하고 2~3번과 동일한 형태로 진행한다
5. QA가 완료될 경우 stage branch에 소스를 병합한다
6. stage branch 에서 master branch로 소스를 병합하고 이미지를 생성하여 운영 Product에 배포한다

• 브랜치 정의
  • branch type : feature 또는 QA
  • 티켓명 : Jira 티켓 번호를 기준으로 작성하며 언더 스코어를 마지막에 붙인다
  • 요약 : 영문과 언더 스코어로 해당 branch 내용에 대해 간략한 설명을 작성한다

코드 리뷰

코드 리뷰에 응원을 더하다.

코드 리뷰는 가급적 많은 의견과 이야기를 나눌 수 있는 좋은 문화이자 일하는 즐거움입니다. 하지만 업무를 진행하다 보면 개개인마다 스케줄, 휴가 등으로 모든 PR에 리뷰를 할 수는 없었습니다. 그래서 조금 더 좋은 코드 리뷰와 활성화를 위해 몇몇 규칙을 만들어 가고 있습니다.

• 리뷰어는 출근자가 대상이 되며 특정인을 지정하지 않는다.

  

• merge 진행은 최소 2명 이상의 리뷰어들이 승인 완료 후 진행한다.

• merge 승인 시 👍 으로 응원의 의사 표현을 한다.

  

로그 전략

로그를 쉽게 검색할 수 있는 키워드가 필요하다.

요청 파라미터, 응답 파라미터, SQL, 그 외 개발자가 남긴 로그 등 너무 많은 데이터가 로그로 쌓이고 있어 장애 발생 시 원인 분석이 너무 어려웠습니다. 정확한 오류 발생 지점을 빠르게 찾고 이슈에 대응하기 위한 방법이 필요했습니다.

ELK 적재 히스토리 데이터를 확장하다.

피킹 시스템에서 배치잡에 대한 생명주기를 담아 히스토리를 적재하여 활용합니다. 이로써 특정 배치잡에 대한 이력을 한눈에 알아볼 수 있게 되었습니다.

검색을 위한 키워드를 추가하다.

요청&응답 프로세스 모든 과정에서 동일한 키워드를 가지고 있으면 좋을 것 같았습니다. 이를 해소하기 위하여 MDC 를 적용하였습니다. 또한 MDC 키워드를 적재하는 부분은 AOP에서 처리함으로써 각각의 메서드에 대한 영향도를 줄일 수 있었습니다. 적용 효과는 명확했습니다. 우리는 Datadog를 통한 로그 모니터링을 진행하는데, APM(Application Performance Management)과 연동되어 있어 trace Id 추적으로 퍼포먼스의 문제가 되는 부분을 파악하는 것이 손쉽게 해결되었습니다. 임의로 추가한 ID, 사용자 등의 키워드 검색 역시 훌륭하게 제공되어 특정 사용자, ID, 요청에 대한 모든 로그를 한눈에 파악할 수 있었습니다. 그 외에 타 시스템과의 연동 부분도 하나의 trace Id로 관리되어 한번에 확인이 가능하여 매우 편리했습니다.

문서를 공유하는 무리

지식 전달의 의미는 누구나 쉽게 이해하고 알아볼 수 있어야 한다.

우리는 서로 아는 지식과 정보 그리고 시스템 구성에 대한 전반적인 내용을 컨플루언스를 적극적으로 사용하기로 하였습니다. 물론 컬리에서는 컨플루언스를 오래전부터 사용해 왔지만 시스템에 대한 지식 전달 목적을 위해 조금 더 자세하게 남길 필요가 있었습니다.

Jira를 활용하다

• 도메인 이해도 부족으로 인한 개발 기간 증대
• 저마다 즐기는 코드 스타일
• Jira 기능을 십분 활용하지 못함
• 규격화되어 있지 않은 컨플루언스 문서들과 팀 내 규칙

기존 팀에서도 Jira를 활용했지만, 팀이 분리된 만큼 이젠 우리 팀만의 Jira 활용법에 대해 연구가 필요한 시점이 되었습니다. 이전엔 기획팀에서 요청이 오거나, 내부적으로 개발 건이 발생하게 되면 해당 이슈의 티켓만 생성하고 이슈의 작업 상세 내역은 컨플루언스에서 관리를 하여 이중 삼중으로 문서가 생성되었습니다. 이로 인해 이슈 트래킹이 점차 힘들어지고, 신규 입사한 분들은 이전 개발 히스토리를 파악하는데 어려움이 있었습니다. 그래서 과제 진행시 개발과 작업에 관련된 내용은 Jira로, 이외 문서화될 내용은 컨플루언스로 이원화하게 되었습니다. Jira를 어떻게 변경되고 도입되었는지 간략하게 소개하겠습니다.

보드 템플릿

Jira에선 현재 보드 템플릿으로 스크럼 보드와 칸반 보드를 지원하고 있습니다. 우리 팀은 스프린트 단위로 업무를 진행하고, 주로 로드맵에서 에픽 단위로 분류된 업무들로 업무 파악을 진행합니다. 따라서 자연스레 스크럼 보드를 활용하게 되었습니다.

스프린트

매 스프린트는 2주간 진행되며, 스프린트가 완료되는 시점에 회고를 진행합니다. 작업자들은 스프린트가 완료될 때까지 업무를 마무리하지 못하면, 연결된 이슈 > 다음에서 분할: 기능을 활용하여 이전 작업과 연결 고리를 생성하여 새로운 티켓을 생성합니다.

이슈 유형

우리 팀에선 에픽, 스토리, 작업, 버그로 총 네 개의 이슈 유형을 사용하고 있습니다. 에픽에선 여러 스토리들의 집합체가 될, 여러 스프린트가 필요한 작업 내용을 정의하고, 스토리에선 에픽의 Use Case들을 풀어서 나열합니다. 기술적인 용어보단 사용자가 수행하는 행동과 목표를 위주로 기술합니다. 그리고 작업에선 스토리에서 기술한 내용을 달성하기 위해 수행해야 할 기술적인 업무를 관리할 때 주로 사용합니다. 마지막으로 버그에선 결함 또는 오류가 발생 시 작업할 내용을 관리할 때 사용합니다.

지라 스토리 티켓 표준화

개발자마다 각자 표현하는 방식이 다르다 보니 각자 작성한 티켓을 확인하는데 시간이 소요되는 현상이 발생하게 되었습니다. 그래서 스토리 티켓을 생성할 땐 정해진 양식에 따라 작성하여, 다른 개발자에게 미리 작업 내용을 공유하고 피드백을 우선적으로 받아볼 수 있게끔 규칙을 만들었습니다. 또한 QA 요청 시에도 다른 요청 문서보단 작성한 티켓으로 내용을 공유하여 문서를 두 번 작성하는 일이 없도록 업무 효율을 개선하였습니다.

(해당 양식은 https://fastcampus.co.kr/dev_red_lhc 강의 내용에서 일부 발췌하였습니다.)

구조를 만들어 가는 무리

간략한 구조로 접근을 쉽게 하다.

단순한 메뉴 구성과 프로젝트에 접근하기 용이한 링크 등 가급적 쉽게 알아볼 수 있도록 간결하게 구성을 합니다. 물론 정리가 완벽하지 않기에 앞으로도 구조변경이 조금씩 조금씩 생길 것입니다.

운영 대응 매뉴얼

모두가 대응할 수 있어야 한다.

시스템을 운영하다 보면 다양한 이슈와 마주하게 됩니다. 동일한 이슈는 가급적 다시 재발하지 않도록 하는 것이 올바른 대처입니다. 하지만 운영 업무 진행시 내부적 혹은 외부적 요인으로 즉각 대응이 어려운 경우도 많습니다. 무리에선 운영하면서 발생하는 크고 작은 이슈들은 해결 후 문서로 관리합니다. 동일한 이슈 발생 시 모두가 대응할 수 있도록 스크럼을 통해 가볍게 공유하고 모두가 필요시 매뉴얼을 기준으로 즉각 대응을 하게 되었습니다.

배포 기록서

배포 태그를 관리하다.

이력뿐만 아니라 배포 예정인 릴리즈 정보들 또한 관리하고 있습니다. 각 시스템 별로 GIT 태그 버전을 기준으로 관리되고 있으며, 태그에 포함된 이력을 확인할 수 있습니다.

회의를 만들어 가는 무리

팀에선 업무 시작 전 스크럼 시간에서 진행 중이거나 예정/완료 내용을 논의하며 공유합니다. 회의는 업무에 필요한 정보를 공유하고 의사결정을 진행하는 중요한 업무이지만, 불필요한 회의는 자칫 큰 리소스 낭비로 이어질 수 있습니다. 회의 주제와 목표를 명확하게 하고 주제에서 벗어난 이야기는 지양하여 정해진 시간 내에 회의 목표를 달성하는데 집중합니다.

스크럼

짧은 주기의 개발 방식을 진행하다.

매일 오전 정해진 시간에 어제 진행한 일과 오늘 진행할 일을 서로에게 간단하게 공유하는 시간을 가졌습니다. 이때 스크럼이 너무 오랜 시간 진행되지 않도록 몇 가지 규칙을 가졌습니다.

공유 내용을 기록하다.

스크럼 시작 전 공유해야 할 내용을 기록함으로써 내용 정리를 하였습니다.

주제에 충실하다.

기존에도 데일리 미팅을 진행한 적이 있으나, 미팅 시 주제를 벗어나는 이야기가 지속되어 취지를 벗어나는 또 다른 회의로 이어져 시간을 많이 소요하게 됩니다. 결국 미팅을 원활하게 진행하기가 어려웠습니다. 그래서 참여자에게는 내용 공유만 진행하고 논의가 필요한 경우 별도 미팅으로 진행하도록 하였습니다.

개인별 진행 상황과 문제점을 공유하다.

추가 논의가 필요한 내용은 별도 미팅으로 진행하기로 합니다. 이로써 스크럼 시간이 길어지는 것을 사전에 방지할 수 있게 되었습니다. 개인별 진행사항과 진행 중 발생한 문제점들을 전체에게 공유함으로써 업무 조정, 논의할 내용 및 결정사항에 대한 정리 등을 쉽게 진행할 수 있었습니다. 이를 위해서 모두가 논의가 필요한 내용을 사전에 기록하여 공유할 수 있도록 하였습니다. 스크럼에서 논의하지는 않았지만 별도 논의가 필요한 내용에 대해서 정리하고 이를 별도 일정으로 분리 진행함으로써, 그저 생각나는 대로 진행하는 회의가 아닌 생각을 정리하고 준비한 회의를 진행하여 좀 더 신속한 의사결정을 진행할 수 있었습니다.

버스터콜

임팩트 있는 결정을 확정하다.

원피스에서 등장하는 군사작전으로, 지도에 있던 섬이 흔적도 없이 사라지는 해군 대함대에 의한 무차별 섬멸 공격. 해군본부 소속 중장 5명이 지휘관인 대형 군함 10척을 한곳에 소집한다. 발동 권한은 세계정부로부터 위임받아 해군 원수와 해군 대장에게 주어진다.(출처 : 나무위키 )

버스터콜의 의미는 위와 같습니다만 우리는 조금 다르게 사용하고 있습니다. 누가 먼저 말한 건지는 모르겠지만 임팩트 있는 결정 사항을 결정하기 위해서 팀원 모두가 잠시(10분 이내) 모여서 회의를 하는 것을 뜻합니다. 가령 메소드명, API 파라미터 등을 변경하거나 테이블 변경사항이 발생할 때 혹은 시스템 영향도가 커질 것을 대비하여 크로스체크가 필요한 상황 등 여러 사람들의 의견이 필요할 때에 진행됩니다. 버스터콜은 짧게나마 서로의 작업에 대해 싱크를 맞출 수 있는 시간이 되기도 하고, 미처 생각 못 한 영향도를 파악할 수 있는 시간이 되기도 합니다.

미처 정의하지 못한 컨벤션, 명명 규칙 등 개발을 하다 보면 사소하지만 결정해야 할 사항들이 있습니다. 코드의 일관성을 위해서 결정해야 할 일이지만, 회의를 하자니 내용도 너무 짧고, 서로 간의 시간을 빼앗는 것 같다는 느낌이 들 때 우리는 슬랙의 Poll 기능을 사용합니다.

투표를 발의하는 사람이 후보들을 적고 아래 이유도 적어두면 팀원들이 읽어보고 본인의 의견에 따라 가볍게 투표합니다. 물론 투표하면서 본인이 투표한 이유도 간략하게 언급하면서 다름 팀원들의 선택에 도움을 주기도 합니다. 만장일치가 나오면 좋겠지만, 표가 갈릴 경우도 있습니다. 이럴 때에 우리는 그냥 다수결로 결정하는 게 아니고 소수의 의견을 물어봅니다. 가령 A가 3표, B가 2표 일 때, B에 투표한 분들의 의견을 다시 한번 물어봅니다. 이때 B에 투표하신 분들이 A로 의견을 바꿔주시면 그대로 진행되고, 의견을 안 바꿔주신다면 버스터콜이 소집됩니다. 다시 말씀드리지만, 코드의 일관성을 위해서 팀의 합의가 필요한 경우(예를 들면 itemList 로 할까요? items로 할까요? 라던가 Interface의 method signiture에 public을 넣을까요? 말까요?)에 투표를 진행하기 때문에, 버스터콜이나 별도 회의로 가는 경우가 많지는 않습니다. 서로 논의하고 합의한 후 결정해야 하는 사항은 처음부터 버스터콜이나 회의로 결정하기 때문입니다. 사실 사무실에서 근무할 땐 이런 방법들에 큰 필요성을 느끼지는 못했습니다. 그냥 자리에 앉아있는 동료들과 함께 모여 짧게 이야기한 후 결정하면 되는 부분입니다. 하지만 재택근무가 일반화되면서 근무환경의 변화로 인해 발생할 수 있는 불편함을 해소하기 위해, 우리 팀은 새로운 문화를 만들어 가고 있습니다.

👨‍👩‍👧‍👦 우여곡절끝에

함께 만들어 가는 시간

우리는 개성 넘치는 사람들과 함께 체계를 만들어가며 소통하고 정착시키는 시간을 보내고 있습니다. 그리고 함께한 시간 속에 우리가 경험한 내용은 서로를 위해 기록합니다.

하나

무리를 만들어 내는 과정에서 자유롭게 서로가 의견을 내고 실행, 보정, 정착해 나가는 과정은 개발자로서의 성장뿐 아니라 함께하는 구성원으로서 다른 시각에서 볼 수 있도록 시야를 넓혀주었다. 혼자가 아닌 무리의 일원으로서의 개개인의 장점을 충분히 끌어올려 함께하는 시간이 앞으로도 기대된다.

두울

결정사항이 필요한 상황에서 결정이 더디게 되는 경우가 많았는데, 이번 과제를 통하여 업무 진행시 즉각적인 결정을 할 수 있어서 너무 좋았다. 또한 불필요한 회의가 현저히 줄어들어 능률이 올라간 것 같다.

세엣

정형화된 포맷 없이 산재되어 작성된 문서에서 정형화된 포맷으로 가독성 있는 문서를 공유할 수 있어 효율이 극대화되었다. 또한 문서를 만들어가는 것도 하나의 개발 문화가 될 수 있다고 생각된다.

네엣

그동안 아픈 손가락이었던 일관성이 없던 코드 베이스를 개선해 나갈 수 있어서 의미 있는 시간이었다. 이슈에 대한 로그 추적이 용이해져서 문제에 대한 원인을 빠르게 파악할 수 있게 되어 의미 있는 시간이었다.

다섯

리팩토링을 통해서 기존의 코드와 도메인, 히스토리를 많이 알 수 있게 되었다. 리팩토링을 했다고 해서 우리의 코드가 완벽해진 것은 아니다. 지금도 우리는 가야 할 길이 멀지만 함께 코드를 발전시킬 팀원들과 같은 방향을 바라볼 수 있게 된 것이 가장 큰 성과라고 생각한다.

여섯

잡히지 않은 체계나 불분명한 논쟁을 공론화한 투표를 통해 만들어 가는 재미가 있다. 또한 도메인 지식에 대한 부분이 많이 부족하여 프로그램 분석에 어려움을 겪었지만 짝꿍 프로그램을 진행하면서 지식 향상에 많은 도움이 됐다.

🎉 마치며

많은 시도와 변경 그리고 아직도 정착되어야 할 많은 체계가 있지만, 말로만 물 흐르듯 지나가버린 약속을 정리하며, 함께하는 무리가 만들어지고 있습니다. 컬리에서 무엇인가 체계를 정착시키고 서로가 지켜 나가야할 것들을 만들어나간다는 자체만으로도 개발자로서 수많은 경험을 할 수 있었던 시간이었습니다. 물론 만들어가는 과정에서 시도해 보고 아니다 싶은 경우도 많았습니다. 그렇다고 체계를 만들어갈 때에 매끄럽지 않거나 실패가 동반되는 경우라 하더라도 무거운 책임으로 돌아오거나 문제 사유로 번지지는 않습니다. 그렇기에 의견이 존중되는 공간 안에서 모두가 한번 해보자라는 의지를 불태울 수 있는 것 자체가 수평적인 문화에서 나온 것이라, 컬리가 추구하는 이미지와 잘 맞지 않나 생각이 듭니다.

컬리에서는 새로운 시도나 도전, 그리고 문화를 만들어가는 길이 자유롭게 열려있습니다. 체계라는 것 자체는 하나의 룰과 규칙들로 완성이 되지는 않습니다. 그리고 머물러 있을 수도 없습니다. 앞으로도 우리는 개성 넘치는 무리의 균형 있는 발전을 위해 조금 더 토론하고 실행하며 만들어 나아갈 것입니다. 계속해서 만날 수많은 과제와 함께(데이터베이스 분리 MSA 신규 서비스 론칭 피킹 시스템 개선등) 지금보다 더 좋은 문화와 새로운 시도를 하며 발전할 것이라 생각됩니다. 지금 이 시간에도 컬리, 그리고 우리는 조금 더 좋은 체계와 문화를 만들어가고 있습니다.

그래서 그런지, 보이지 않던 기린이 조금씩 우리의 손에 닿을 것 같습니다.