협업 쉽게 해버리기

초급 팀 프로젝트를 진행하고 팀장들끼리 모여 회고 하던 중,
다른 팀장님께서 여러 협업 도구들을 알려주셨다.

슬랙, 지라, 리니어 같은 작업 관리 도구부터
프리티어, 린트, 허스키처럼 코드 스타일과 규칙을 관리하는 도구까지.

사실 나는 거의 처음 들어보는 것들이었다.
프리티어 정도만 "저장하면 코드 예쁘게 정리해주는 도구"로만 알고 있었을 뿐이다.

솔직히 충격이었다.

“PR 형식을 자동으로 맞출 수 있다”
“컨벤션이 안 맞으면 push 자체가 막힌다”

컨벤션이 안 맞으면 push 자체가 막힌다니.
우린 코드리뷰에서 하나하나 확인하고 알려주기로 했었는데 ...

물론 코드리뷰가 단순히 컨벤션만 보는 과정은 아니지만,
이 부분을 자동으로 처리할 수 있다는 건 꽤 큰 차이라고 느껴졌다.

특히 “push를 막는다”는 표현이 인상적이었다.
단순히 권장하는 수준이 아니라, 아예 지키지 않으면 다음 단계로 못 넘어가게 만든다는 의미니까.

그러던 중 또 다른 팀장님이 이런 말씀을 하셨다.

“나는 자동사냥처럼 돌아가는 구조를 만들어두는 걸 좋아한다”

사실 이번에 처음 듣는 말은 아닌데,
지금 다루려는 협업 도구들이랑 꽤 어울리는 말 같아서 인용해왔다.

나 또한 그렇다.
자동화가 가능하면 몸이 덜 고생하지 않겠는가 !

그런 나에게 이런 "자동으로" PR 형식을 맞춘다거나,
컨벤션이 안 맞으면 "자동으로" push 자체를 막는다거나
정말 매혹적인 말이 아닐 수가 없다.

그래서 그런 도구가 어떤 도구인지 살펴보고
그 외에 또 어떤 도구가 있나도 살펴보고 싶어서
이렇게 블로그 주제로 잡아왔다.

---

1. 작업 흐름을 보이게 만드는 도구

이번 프로젝트에서는
역할을 비교적 명확하게 나누고,
매일 데일리 스크럼을 진행하면서 작업 상황을 공유했다.

덕분에 협업이 크게 꼬이는 경험은 하지 않았다.

다만 느낀 건,
이 흐름을 사람이 계속 직접 관리하고 있었다는 점이다.

누가 어떤 작업을 하고 있는지,
어디까지 진행됐는지,
막힌 부분은 없는지
이런 것들을 매번 대화를 통해 확인해야 했다.

협업 도구는 이 과정을
시스템으로 대신해준다.

작업을 이슈 단위로 나누고,
진행 상태를 시각적으로 보여주고,
누가 무엇을 맡고 있는지 한눈에 파악할 수 있게 해준다.

즉, 매번 묻고 확인하지 않아도
흐름 자체가 자연스럽게 공유되는 구조가 된다.

물론 소통을 통한 방식도 충분히 협업을 굴릴 수 있고,
팀 분위기를 만드는 데에도 중요한 역할을 한다.

다만 이 흐름을 전적으로 사람에게만 의존하게 되면
상황에 따라 관리가 어려워질 수 있다.

그래서 이런 과정을 도구가 함께 담당해준다면
더 안정적이고 효율적인 협업이 가능해진다.

결국 협업 도구는
단순한 편의 기능이 아니라,

작업 흐름 자체를 관리해주는 역할을 한다.

GitHub Issues

이번 프로젝트에서는 GitHub의 Issues 기능을 활용해서 작업을 관리했다.

각자 해야 할 일을 이슈 단위로 정리하고,
관련된 PR을 연결하는 방식으로 작업을 진행했다.

코드를 관리하는 GitHub 안에서 바로 사용할 수 있다는 점이 편리했고,
이슈와 PR이 자연스럽게 연결되기 때문에
작업 흐름을 따라가기도 쉬웠다.

다만 첫 프로젝트였던 만큼
이 기능을 충분히 활용하지는 못했던 것 같다.

작업 흐름을 관리하기보다는
칸반 보드처럼 간단히 정리하거나
기록을 남겨두는 용도로 사용하는 데에 더 집중했던 느낌이었다.

다음은 보다 체계적으로 작업 흐름을 관리할 수 있는 도구들을 다뤘다.

Jira

지라는 이러한 이슈 기반 작업 관리를
더 체계적으로 확장한 도구다.

작업을 단순히 나열하는 것이 아니라,
진행 상태를 단계별로 나누고 보드 형태로 시각화해서
팀 전체 흐름을 한눈에 파악할 수 있게 해준다.

또한 스프린트 관리나 자동화 기능 등
협업을 위한 다양한 기능을 제공한다는 점에서
보다 구조적인 작업 관리 도구라고 볼 수 있다.

Linear

리니어 역시 이슈 기반으로 작업을 관리하는 도구다.

지라와 유사한 역할을 하지만,
보다 가볍고 직관적인 사용성을 강조한 도구로 알려져 있다.

복잡한 설정 없이도 빠르게 작업을 관리할 수 있어서
소규모 팀이나 스타트업에서 많이 사용되는 편이다.

결국 지라와 리니어는
작업을 ‘흐름’으로 관리한다는 점에서는 동일한 도구들이다.

Slack

이슈 기반으로 작업을 관리하는 것과 별개로,
팀원 간의 소통을 담당하는 도구도 필요하다.

슬랙은 채널을 통해 대화를 주제별로 나눌 수 있어
공지, 작업 공유, 질문 등을 구분해서 관리할 수 있다.

이 덕분에 대화가 뒤섞이지 않고,
필요한 정보를 빠르게 찾을 수 있다.

결국 슬랙은
팀의 소통을 구조화해주는 도구라고 볼 수 있다.

---

2. 코드 스타일을 맞춰주는 도구

협업을 하다 보면
생각보다 자주 부딪히는 문제가 하나 있는데,
바로 코드 스타일이다.

같은 기능을 구현하더라도
들여쓰기, 세미콜론, 따옴표, 변수명 등
사람마다 코드 스타일이 조금씩 다르다.

이 차이가 쌓이면
코드를 읽기 어려워지고,
리뷰 과정에서도 불필요한 피드백이 반복되게 된다.

물론 컨벤션을 정해서 맞출 수는 있고,
우리 또한 이러한 코드 컨벤션을 정해놓고
프로젝트를 시작했다.

하지만 문제는
서론에서도 말했듯이
이걸 사람이 계속 지켜야 한다는 점이다.

실수로 놓칠 수도 있고,
사람마다 기준이 다르게 적용될 수도 있다.

그래서 등장하는 것이
코드 스타일을 자동으로 맞춰주는 도구다.

Prettier

프리티어는 코드 포맷터다.

쉽게 말하면
코드를 ‘자동으로 정리해주는 도구’다.

저장을 하거나 명령을 실행하면
들여쓰기, 줄바꿈, 따옴표 스타일 등을
미리 정해둔 규칙에 맞게 자동으로 수정해준다.

덕분에 사람이 일일이 신경 쓰지 않아도
코드 스타일이 항상 동일하게 유지된다.

ESLint

ESLint는 코드 검사 도구다.

단순히 스타일을 맞추는 것을 넘어서
코드가 정해진 규칙을 지키고 있는지 확인해준다.

예를 들어
사용하지 않는 변수, 잘못된 문법, 위험한 코드 패턴 등을
미리 잡아낼 수 있다.

즉, 프리티어가
코드를 ‘보기 좋게’ 만들어준다면,

ESLint는
코드를 ‘올바르게’ 유지하도록 도와준다.

---

3. 규칙을 ‘지키게 만드는’ 도구

드디어 이 파트다.
사실 이 파트가 이번 포스팅의 메인이다.

앞에서 Prettier와 ESLint를 통해
코드 스타일과 규칙을 자동으로 맞출 수 있다는 걸 알게 됐다.

이제 더 나아가
그걸 항상 지키게 만들어야 할 때다.

아무리 좋은 규칙이 있어도
사람이 실수로 놓치거나,
검사를 건너뛰고 넘어가는 상황은 충분히 발생할 수 있다.

결국 중요한 건
규칙을 만드는 것보다, 지키게 만드는 것이다.

이 역할을 해주는 도구가 바로 Husky다.

Husky

Husky는 Git hook을 활용해서
특정 시점에 원하는 작업을 자동으로 실행할 수 있게 해주는 도구다.

예를 들어
코드를 push 하기 전에

• Prettier 실행
• ESLint 검사

같은 작업을 자동으로 돌릴 수 있다.

그리고 만약 이 과정에서
컨벤션이 맞지 않거나 오류가 발생하면

push 자체를 막을 수 있다 !

즉, 단순히 “검사해주는 도구”가 아니라
규칙을 지키지 않으면 다음 단계로 못 넘어가게 만드는 장치다.

---

4. 더보기

앞에서 살펴본 도구들은
협업에서 자주 사용되는 기본적인 도구들이다.

하지만 찾아보면
이 외에도 협업을 더 효율적으로 만들어주는 도구들이 정 말 많다.

GitHub Actions

GitHub Actions는
코드를 push 하거나 PR을 생성했을 때

• 테스트 실행
• 빌드
• 배포

같은 작업을 자동으로 수행할 수 있게 해주는 도구다.

즉, 사람이 직접 실행하지 않아도
코드가 올라가는 순간 자동으로 검증과 배포가 이루어진다.

이 도구와 밑에서 다룰 Commitlint는 다른 팀장님이 알려줬던 도구는 아닌데,
이 도구가 정말 너무 충격적이었어서 어떤 식으로 흘러가는 건지 더 알아봤다.

1. 이벤트 발생

먼저 코드 push 혹은 PR 생성과 같은 상황이 생기면 시작된다.

2. 가상 컴퓨터를 하나 띄우기

GitHub가 아무것도 없는 깨끗한 상태의
"임시 서버"를 하나 만들어준다.

3. 코드 가져오기

말 그대로 내 레포 코드를 그 서버에 복사한다.

4. 테스트 / 검사

여기서 패키지 설치, ESLint 검사, 테스트 실행이 이뤄진다.
하나도 실패하면 워크플로우가 중단되고,
PR에 빨간 X 표시가 된다.

5. 빌드

React는 정적 파일로 변환하고,
Next는 서버 코드와 번들을 생성한다.

즉 서비스로 돌릴 수 있는 형태로 만드는 과정이다.

6. 배포 (배포 플랫폼 호출 / 서버에 직접 업로드)

이건 방식이 두 가지가 있는데,

Actions가 명령 실행하면 배포 플랫폼이 받아서 배포하는 방식과
직접 서버에 파일 던지는 방식으로 진행된다.

Commitlint

Commitlint는
커밋 메시지가 정해진 규칙을 따르고 있는지 검사하는 도구다.

예를 들어
feat: 로그인 기능 추가
같은 형식을 강제할 수 있다.

이렇게 하면 커밋 로그만 봐도
어떤 작업이 이루어졌는지 한눈에 파악할 수 있다.

---

5. 협업: 자동화 돌리기

앞에서 살펴본 도구들을
실제로 어떻게 연결되는지
얼마나 자동화로 돌려먹을 수 있는지 한 번 정리해보면 이렇다.

1. 작업 정의

GitHub Issues 생성해서
작업 단위를 나눈다.

2. 개발

브랜치를 생성하고 코드 작성한다.

3. commit 단계 (1차 필터)

Husky를 실행하여 Prettier와 ESLint 자동 실행한다.

문제 있으면 commit 자체가 안 된다.

4. PR 생성

협업을 시작한다.

5. GitHub Actions (2차 필터)

GitHub Actions 실행하여

• 패키지 설치
• lint 검사
• 테스트 실행
• build

같은 작업이 자동으로 수행한다.

이 과정에서 하나라도 실패하면
PR에 오류가 표시되고 머지를 할 수 없다.

6. 자동 머지 (옵션)

조건을 만족하면 자동 merge 가능하다.

7. 자동 배포

Vercel / Render 연결하여 완전 자동으로 배포하거나
GitHub Actions 안에서 배포까지 진행해 서버까지 직접 제어한다.

협업 도구를 제대로 구성하면,
개발자는 코드 작성과 PR 생성만 하면 되고 나머지 과정은 모두 자동으로 처리된다.

commit 단계에서 한 번,
GitHub Actions에서 한 번 검증을 거친 뒤,
문제가 없을 경우 자동으로 배포까지 이어지는 구조다.

---

6. 협업은 결국 ‘흐름’을 만드는 일이다

이번에 협업 도구들을 살펴보면서 느낀 건
협업은 단순히 같이 일하는 것이 아니라,
하나의 흐름을 만드는 과정이라는 점이었다.

이슈로 작업을 나누고,
코드 스타일을 맞추고,
규칙을 자동으로 검사하고,
필요한 순간에 자동으로 배포까지 이루어지는 구조.

이 모든 과정이 연결되면서
하나의 자연스러운 흐름이 만들어진다.

그리고 협업 도구들은
이 흐름을 사람이 아닌
시스템이 관리할 수 있도록 도와준다.

물론 도구만으로 협업이 완성되는 것은 아니다.

하지만 최소한
사람이 계속 확인하고 관리해야 하는 부담을 줄여주고,
더 안정적인 협업 구조를 만들 수 있게 해준다.

우린 이러한 관리 외에도
집중해야 할 일이 많으니까 !