이번에 스프린트에서 프로젝트를 진행한다.
계획서를 자잘자잘하게 쓰고 프로젝트를 진행하게 되는데,
거기서 팀장을 맡아버렸다.
그런 나서는 사람이 아니라 굉장한 부담이 함께하는데,
이 또한 성장 중 하나려니 싶어서
부담이고 자시고 모두 안고 가려고 한다.
본론으로 돌아가서 일정 및 R&R을 비롯한 계획서를 작성하고
멘토님께 피드백을 받았는데
멘토님께서 페어 프로그래밍에 대해 언급해주셨다.
그래서 주제로 잡고 한 발자국 나아가려고 한다!
1. 혼자 개발하는 방식에서 벗어나기
혼자 개발할 때의 한계
처음엔 강의도 혼자 듣고, 과제도 혼자 풀면서
당연히 혼자 개발하는 게 기본이다.
근데 어느 순간부터 이상한 느낌이 온다.
- 이 코드가 맞는지 확신이 없음
- 더 좋은 방법이 있는지 모르겠음
- 그냥 "돌아가니까 OK" 상태가 됨
이게 반복되면 뭐가 생기냐면
성장이 멈춘 느낌을 받게 된다.
한계의 이유
혼자 개발하게 되면 아래와 같은 구조를 갖게 된다.
- 내가 생각
- 내가 작성
- 내가 검증
이게 문제로 작용한다.
누가 틀렸는지 체크해주는 사람이 없고,
다른 시각이 들어올 틈이 없다.
비유해보자면
혼자 시험 보고, 혼자 채점하는 상황이다.
틀려도 모르고, 맞아도 왜 맞는지 모른다.
그래서 등장한 방식이 페어 프로그래밍이다.
혼자 하는 게 아니라
처음부터 같이 생각하고 같이 만드는 방식이다.
2. 같이 코딩처럼 보이는 오해
처음 들으면 그냥 이렇게 생각하기 쉽다
둘이 앉아서 같이 코딩하는 거 아닌가?
둘이 같은 내용을 각자 나눠서 코딩하는 방식이라면
그건 오히려 비효율적인 중복 작업에 가깝다.
실제로 모습만 보면 비슷하게 오해할 만하다.
하지만 서로의 역할이 확실하게 구분된다.
페어 프로그래밍은 한 명이 키보드를 잡고 코드를 작성하고,
다른 한 명이 옆에서 화면을 보며 함께 진행하는 구조다.
그냥 같이 있는 게 아니라 역할이 나뉘어 있다는 것이 포인트다.
Driver / Navigator 역할
페어 프로그래밍은 기본적으로 역할이 두 개다.
- Driver → 직접 코드 작성하는 사람
- Navigator → 옆에서 방향 잡는 사람
여기서 많이 오해하는 게 있는데
Driver는 단순히 코드만 작성하는 사람이 아니라
왜 이렇게 작성하는지 설명하면서 코드를 짜야 한다.
Navigator도 그냥 구경하는 사람이 아니고
- 이 방식이 맞는지
- 더 좋은 방법이 있는지
- 놓친 부분이 없는지
이걸 계속 생각해야 하는 역할이다.
중요한 건 역할이 아니라 "생각의 흐름"
여기서 진짜 중요한 포인트가 하나 있다.
둘이 코드를 나눠서 만드는 게 아니라
생각을 같이 끌어내는 구조다.
혼자 할 때는 머릿속에서만 생각하고 끝났던 것들이
말로 설명되고 바로 피드백 받고
다시 수정되는 흐름이 생긴다.
이게 핵심이다.
이런 구조로 인한 변화
이 구조 때문에 생기는 변화가 있다.
- 애매하게 알고 있던 게 바로 들킨다.
- 그냥 감으로 짜던 코드가 설명 가능한 코드로 바뀐다.
- 선택 하나하나에 이유가 붙기 시작한다.
결국 코드 퀄리티보다 먼저
생각하는 방식 자체가 바뀐다.
3. 실제 진행 방식
한 기능을 같이 끝까지
페어 프로그래밍은
중간에 나눠서 하는 방식이 아니다.
하나의 기능을 처음부터 끝까지 같이 만든다.
예를 들어
상품 등록 기능을 하나 만든다면
API 설계부터 UI까지
전부 같이 진행하는 구조다.
이 과정 자체가 페어 프로그래밍의 핵심이다.
시작은 항상 "같이 생각"부터
바로 코드부터 치지 않는다.
먼저 어떻게 만들지, 어떤 방식이 좋을지
같이 이야기하면서 방향을 잡는다.
이 과정이 없으면
그냥 둘이 앉아 있는 혼자 개발이랑 다를 게 없다.
코드 작성도 혼자가 아니라 같이
코드를 작성하는 순간에도
한 명만 생각하는 게 아니다.
코드를 작성하면서
왜 이렇게 짜는지 설명하고
옆에서는 계속 질문하고 체크한다.
이게 계속 반복된다.
중간중간 계속 수정되는 방향
혼자 개발할 때는
한 번 정한 방향을 끝까지 밀고 가는 경우가 많다.
근데 페어 프로그래밍은 다르다.
- 더 좋은 방법이 나오면 바로 바꾸고
- 놓친 부분이 있으면 바로 잡는다.
즉
계속 방향을 조정하면서 진행한다.
처음 하면 느껴지는 특징
처음 하면 대부분 이렇게 느낀다.
- 느리다
- 답답하다
- 혼자 하는 게 더 빠르다.
근데 이게 정상이다.
왜 이렇게 만드는지 이해하고
그 과정을 공유하는 게 목적이다.
그래서 결과적으로는
코드를 만드는 과정 자체가 달라진다.
4. 해보면 얻을 수 있는 것들
강제로 넓어지는 시야
혼자 개발할 때는
내가 아는 방식 안에서만 선택하게 된다.
근데 페어 프로그래밍을 하면
다른 사람이 생각하는 방식을 계속 보게 된다.
- 같은 문제를 다르게 접근하는 방식
- 내가 생각 못한 구조
- 더 단순한 해결 방법
이게 계속 들어온다.
그래서 자연스럽게
"내 방식 하나"에서 "여러 선택지"로 바뀐다.
바로 들춰지는 애매한 이해
혼자 할 때는
- 대충 아는 상태
- 감으로 짠 코드
이게 그냥 넘어간다.
근데 페어 프로그래밍은
- 왜 이렇게 짰는지
- 이게 어떻게 동작하는지
이걸 말로 풀어야 한다.
즉 설명을 해야 한다.
이 순간
모르면 바로 티가 난다.
코드에 이유가 생기기 시작한다.
혼자 개발하면
"일단 되게 만드는 코드"가 많다.
근데 페어로 하면
- 이 구조 왜 썼는지
- 이 선택이 맞는지
계속 확인을 받는다.
그래서 모든 코드에 이유가 붙기 시작한다.
줄어드는 실수
혼자 개발하면
내가 놓친 건 끝까지 놓친다.
근데 둘이 보면
한 명이 놓친 걸 다른 한 명이 잡는다.
이게 생각보다 크다.
결국 바뀌는 건 코드가 아닌 사고방식
페어 프로그래밍을 하면
단순히 코드 퀄리티가 좋아지는 게 아니라
생각하는 방식 자체가 바뀐다.
설명 가능한 코드만 쓰게 되고
선택에 근거를 붙이게 되고
더 나은 방법을 계속 고민하게 된다.
이게 핵심이다.
5. 페어 프로그래밍 시작하기
처음부터 완벽 X
페어 프로그래밍이라고 해서
규칙 완벽하게 지키고
역할 정확하게 나누고
이상적인 방식으로 시작하려고 하면
시작도 못한다.
처음은 그냥
"같이 해본다" 수준이면 충분하다.
기능 하나 잡고 같이 해보는 게 시작
가장 현실적인 시작 방법은 이거다.
- 작은 기능 하나 정한다.
- 둘이 같이 붙어서 구현해본다.
예를 들어
- 상품 목록 가져오기
- 검색 기능
- 간단한 폼 처리
이런 것부터 시작하면 된다.
처음엔 어색한 게 정상
처음 하면 무조건 이상하다.
말하면서 코딩하는 게 어색하고
옆에서 보는 것도 어색하고
서로 타이밍도 안 맞는다.
이게 정상이다.
속도보다 "같이 이해하는 경험"에 집중
혼자 하면 더 빠른 건 사실이다.
근데 페어 프로그래밍은
빠르게 만드는 게 목적이 아니다.
왜 이렇게 만드는지
서로 어떻게 생각하는지
이걸 맞춰가는 과정이 핵심이다.
부담을 가지는 순간 오히려 어려워진다.
많이들 여기서 막힌다.
- "내가 못하면 어떡하지?"
- "민폐 아닐까?"
근데 이 구조 자체가
서로 부족한 걸 드러내는 구조다.
그래서 오히려
모르는 걸 말하는 게 맞는 방향이다.
결국 중요한 건 경험
페어 프로그래밍은
설명으로 이해하는 게 아니라
해봐야 이해된다.
한 번만 제대로 해보면
왜 느린지 왜 필요한지
뭐가 달라지는지 바로 체감된다.
실제로 스프린트 강사님이 따라오기 어려운 인원들을 모아
각자의 화면을 공유하면서 함께 실습을 진행하시는데
나는 내 모습이 드러나는 게 부담스러워 쉽게 참여하지 못했다.
그런데 돌아보니 그 방식이
페어 프로그래밍과 꽤 비슷했다.
결국에 내가 애매하게 알고 있는 모습들을
다 들춰내기 위한 방식이었고
내 애매함이 들춰지면 그건 또 성장으로 이어질 것이다.
그래서 멘토님이 페어 프로그래밍 방식을 추천하셨던 것 같다.
