본 포스팅은 애플 디벨로퍼 아카데미 @POSTECH 테크 포럼 이벤트, '기술 글자랑 대회'의 게시글을 가져와 작성되었습니다.
안녕하세요, 3기 주니어 러너 한톨입니다! 😇
평소 테크 포럼에 기여하고 싶은 마음을 작게나마 가지고 있었는데,
기술 글자랑 대회라는 좋은 기회와 함께 살려보고자 용기 내어 글을 작성해 봅니다.
개발 협업이라는 주제에서 하고 싶은 얘기가 너무나도 많습니다.
하지만 오늘은 간단하지만 쉽게 적용해 볼 수 있는,
어쩌면 많은 것들을 바꿀 수 있는,
제겐 이미 많은 것들을 가져다준 실천법을 공유해 보려 합니다.
적용하기까지의 과정을 맥락과 함께 녹여보려다 보니 글이 두서없이 길어졌습니다.
부족한 글이지만, 너그럽게 읽어주셨으면 합니다 :)
1️⃣ 개발 협업의 의미
저는 아카데미에서 처음으로 개발 협업을 경험했습니다.
그전까지 작은 개인 프로젝트만이 유일한 개발 경험이었죠.
하지만 그리 두렵진 않았습니다. (무슨 자신감?)
다른 직군에서의 협업 경험이 있었고, 사람들과의 소통에 자신 있었기 때문입니다.
‘제가 생각하는 범주와 크게 다르지 않을 것’이라 생각했습니다.
하지만 이런 유의 이야기가 대개 그렇듯, 그렇게만 흘러가지 않았습니다.
개발 협업은 제가 생각했던 것과 달랐습니다.
2️⃣ 함께 개발 == 함께 글쓰기?
많은 사람들이 개발을 현실 세계의 개념에 빗대어 글쓰기라 이야기합니다.
의미 혹은 정보를 전달하고자 시나리오, 메시지 등을 고민해 작성하는 글쓰기처럼,
문제를 해결하고자 구조, 함수 등을 고민해 작성하는 개발은 많은 부분이 닮아있기 때문입니다.
그렇다면 함께 개발하는 것은 함께 글쓰기와 같다고 볼 수 있을까요?
하지만 조금 어색한 부분이 있습니다.
현실 세계의 글쓰기는 보통 ‘함께’ 하지 않는다는 것이죠.
문학, 포스팅, 기사 등 우리 주변에서 볼 수 있는 많은 글들은 대개 개인적인 작업들이 주를 이루고 있습니다.
화자의 표현, 사고, 설정, 결말 등이 여러 방향으로 섞여 희석될 수 있기 때문입니다.
물론 글쓰기에 다른 사람들의 직간접적인 영향(교열, 첨삭, 자료 제공 등)은 존재하지만
적어도 소설과 같은 문학에서는 협업 보다 개인 작업이라는 개념에 더 가까울 것입니다.
그에 반해 개발 협업은 단어 그 자체에 이미 내포되어 있듯, 함께 해야만 하는 작업임을 의미합니다.
더 큰 목표를 달성하기 위해 동료와 머리를 맞대야 하는 경우가 훨씬 많기 때문입니다.
결국 개발은 글쓰기와 닮아있기에 세심히 고민해야 하지만,
협업이라는 개념과 떼어놓을 수 없기에 복잡하고, 어렵습니다.
3️⃣ 개발 협업에서 가장 중요한 것
복잡하고 어려워도, 우리는 동료와 함께 글을 써 내려가야 합니다.
목표를 달성하기 위해 함께 개발해야 합니다.
함께 좋은 글을 작성하기 위해 가장 중요한 것은, 서로 같은 맥락을 공유하는 것입니다.
글을 쓸 때 현란한 글 솜씨와 흥미로운 주제보다 더 중요한 것은,
일관성 및 개연성 있게 이야기를 풀어나가는 것이라 감히 확신해 봅니다.
좋은 개발 협업을 위해서 가장 중요한 것 또한, 서로 같은 맥락을 공유하는 것입니다.
개발할 때 멋진 코드와 최신 기술 스택보다 더 중요한 것은,
일관성 및 근거 있게 코드를 풀어나가는 것이라 감히 확신할 수 있습니다.
우리는 같은 맥락을 ‘잘’ 공유해야, 개발 협업을 ‘잘’ 할 수 있습니다.
4️⃣ 같은 맥락을 공유하기 위한 도구
서론이 길었습니다.
의미를 전달하고자 너무 진지한 분위기로 가는 것 같아 본론은 조금은(?) 가볍게 가보려 합니다.
어떻게 하면 동료들과 같은 맥락을 ‘잘’ 공유할 수 있을까요?
다행히 우리에겐 많은 도구가 있습니다.
그중에서도, 지금 이 글이 적혀지고 있는 Github은 대표적인 개발자의 협업 도구(친구)라고 할 수 있죠.
함께 코드를 작성할 수 있게 많은 기능들을 제공하고 있습니다.
여러분은 어떻게 Github을 활용하고 계시나요?
5️⃣ 저는 이렇게 사용했었습니다
많은 분들이 공감하시겠지만 Pull Request, 줄여서 PR은 Github에서 가장 많이 사용하는 기능 중 하나입니다.
글쓰기로 비유하자면, “내가 이야기의 한 부분을 써봤어. 이걸 우리 이야기에 반영할 수 있도록 확인해 줘!” 와 같은 기능입니다.
나 혹은 협업하는 동료가 같은 맥락의 글을 작성하는지 공유할 수 있는 가장 좋은 도구임을 짐작할 수 있습니다.
이렇게나 중요한 PR은 안타깝게도 제 능력을 십분 발휘하지 못하는 경우가 많습니다.
해당 사례를 적나라하게 보여줄 수 있는 저의 과거 PR과 함께 차근차근 뜯어보겠습니다.
PR과 관련된 간략한 정보가 적혀있고, 이를 뒷받침하기 위한 테스트 영상도 업로드되어있습니다.
하지만 그도 잠시 가히 폭력적인 숫자들이 눈에 띄네요.
14개의 Commit, 29개 파일의 변경, +967줄의 코드 변경이 있는 이 PR은 언뜻 보기에도 꽤나 무거워 보입니다.
읽는 사람들로 하여금 부담감을 유발하고 있죠.
조금 더 밑으로 내려볼까요?
14개의 Commit 기록이 순차적으로 표시되어 있습니다.
나름 컨벤션에 맞게 Commit을 기록했기에 전체적인 작업 흐름을 유추할 수 있습니다만,
여전히 내부 구현을 보기 위해선, 동료들의 많은 노력과 인내심이 필요할 것 같습니다.
제 PR에 감동했는지 개발자들이 가장 좋아하는 단어가 나오고야 말았습니다.
동료가 코드를 확인했는지의 여부는, 서로의 신뢰만으로 믿을 수밖에 없겠네요.
6️⃣ 왜 이렇게 될 수밖에 없었을까?
조금은 극단적일 수 있는 제 PR을 보며 어떤 생각이 드셨나요?
짐작건대 문법적으로나, 기능적으로 한두 군데 동작하지 않아도 승인받을 수 있었을 것입니다.
최악의 경우 이런 PR이 점점 쌓여 최종 QA 단계에선 걷잡을 수 없이 많은 버그들과 함께 주말을 보내야 할 수도 있습니다.
물론 변명 거리야 준비되어 있답니다.
- 프로젝트 기간이 촉박해서 코드 칠 시간도 없는데,, PR을 꼼꼼히 적기 어려웠어요! 🥵
- 저걸 언제 다 읽어요,,! 기능이 동작하는지 확인하는 것이 PR의 주 목적이지 않나요? 🥲
- 이번 경우엔 코드량이 많아서 그렇지 PR을 적절히 분리하면 별문제 없을 것 같은데요? 🧐
마냥 변명이라 생각하시나요? (변명이 맞습니다!)
저는 이런 상황이 우리 모두에게 그리 멀지 않다고 생각합니다.
개발 환경은 언제나 변수로 가득하기 때문이죠.
실제로 저는 경험상 프로젝트 기간이 여유로울 때보다 촉박할 때가 훨씬 많았으며,
코드의 양은 점점 늘어남에 비해 질은 떨어져 서로의 PR을 가볍게 넘기는 상황이 빈번해지고,
자연스레 PR의 크기는 점점 커져 분리조차 불필요하게 느껴지는 상황을 마주하곤 했습니다.
‘더 열심히 해야 한다’, ‘어쩔 수 없는 것이다’ 타이르며 나아가기엔 현실은 녹록지 않습니다.
모두가 좋은 PR, 나아가 좋은 개발 문화를 꿈꾸지만 현실의 벽에 부딪히다 보면 조금씩 흐려져감을 느낍니다.
7️⃣ PR 3000% 활용하기
하지만 우린 알고 있습니다.
목표를 달성하기 위해 ‘같은 맥락을 공유하는 것’이 얼마나 중요한 것인지를 말이죠.
드디어 본 게시글의 핵심 목적이었던 실천 방법을 소개해 보려 합니다. (드디어,, 👶)
현실을 바꿀 순 없지만, 기존의 PR 작성 프로세스를 조금 손보는 것만으로 훨씬 좋아질 수 있습니다!
실천 방법은 간단합니다.
커밋 단위로 PR도 함께 업데이트하는 것입니다.
간단한 예제와 함께 PR의 생성부터 완료까지의 과정을 정리해 보았습니다.
1. Branch 생성
작업을 진행할 Branch를 생성합니다.
팀 개발 환경에 따라 다르겠지만, 저는 보통 Issue와 연계해 Branch를 생성합니다.
2. 작업 진행
기능 구현을 위한 코드를 작성합니다.
첫 번째 Commit으로 SwiftUI의 View 코드를 추가했습니다.
3. 첫 번째 Commit + PR 작성
여기서부터 기존 PR을 작성하는 흐름과 달라집니다.
첫 번째 Commit을 날린 후 곧바로 PR을 생성합니다.
(본 예제는 전체 흐름이 중요하기에 PR 내용은 간략히 작성했습니다.)
아직 PR의 모든 작업이 완료되지 않아도 괜찮습니다.
이를 표시하기 위해 Label을 이용하는 것을 권장 드립니다.
(동료들에게 현재 작업 중인 PR 임을 알리기 위해)
그리고 곧바로 방금 작성한 Commit에 대한 설명을 PR에 추가합니다.
이렇게 Commit 후 바로 이에 대한 설명, 즉 PR을 업데이트하는 것은 다음과 같은 효과를 기대할 수 있습니다.
- 질적 향상 - 방금 작성한 코드이기 때문에 가장 정확하고 명확하게 내 코드를 공유할 수 있습니다.
- 기술 부채 완화 - 곧바로 작성한 코멘트는 기존 PR 작성의 부담을 분산 시켜줍니다.
- 실시간 확인 - 실시간 동료들은 실시간으로 PR 작업 내용을 확인할 수 있습니다.
4. 작업 계속 진행…
위와 같은 플로우를 PR 작업이 종료될 때까지 진행합니다.
이는 자연스레 코멘트, 즉 공유하기 좋은 산출물의 양을 증가시킵니다.
작성하는 입장에서도, 읽는 입장에서도 PR의 이점이 더욱 극대화됩니다.
5. PR 작업 완료 후 코드 리뷰 요청
모든 PR 작업이 완료되었다면 남은 일은 쉽습니다.
Label을 변경 후 리뷰를 요청할 동료들에게 Request를 날리는 것입니다!
꾸준히 내용을 업데이트하니 숙제처럼만 느껴지던 PR 작성이 자연스럽게 끝나있네요.
6. 코드 리뷰 받기
위에서 언급했듯, 양질의 코멘트가 남겨진 PR은 읽기 쉬울뿐더러,
리뷰어들에게 더 많은 피드백을 받을 수 있는 환경을 조성합니다.
어느 부분을 집중해서 봐야 하는지, 어떤 맥락으로 코드를 작성했는지 쉽고 빠르게 파악이 가능하기에 양질의 피드백을 기대할 수 있게 됩니다.
7. PR 완료 및 closed
모든 코드 리뷰가 끝나고 PR이 완료되면, 프로세스는 끝이 나게 됩니다.
8️⃣ 작은 변화로 만들어내는 큰 효과
기존 PR 작성 프로세스와 비교했을 때 어떤 것이 달라졌을까요?
첫 번째, 작업량의 변화는 크지 않았습니다.
기존 PR 작성 프로세스보다 더 많은 코멘트가 작성되었을 것이라 예상합니다.
하지만 그 과정이 모든 작업을 마친 후 기억을 되짚어가며 PR을 업데이트하는 것과 비교했을 때의
시간과 노력을 생각한다면, 작업량이 크게 늘지 않았을 것이라 확신합니다.
오히려 동일한 퀄리티의 맥락 공유를 위해선, 기존 프로세스가 훨씬 더 많은 리소스를 사용하게 만들 것입니다.
두 번째, 기대 효과는 작지 않았습니다.
PR 작성에 대한 부담이 줄어들면, 자연스레 양질의 내용은 증가합니다.
코멘트가 많아진다는 것은, 내 코드에 대한 근거를 명확히 제시하고
맥락을 분명히 공유한다는 뜻입니다.
코드 리뷰가 많아진다는 것은, 동료의 코드를 통해 문제, 기회를 함께 찾아 해결해나가고
맥락을 분명히 인지한다는 뜻입니다.
이 밖에도, 프로덕트의 성장 과정을 효과적으로 기록할 수 있으며
동료들과의 건강한 개발 문화를 만들어나감에 따라, 좋은 팀워크도 따라오게 됩니다.
9️⃣ 결국 함께 성장해야 합니다
마지막으로 다시 강조 드리고 싶은 메시지는, 개발은 협업과 떼어놓을 수 없는 개념이라는 것입니다.
복잡하고 어려운 일이지만, 이를 해결해나가는 것 또한 개발자의 책임이라 자신 있게 이야기할 수 있습니다.
책임을 다하기 위해 우리는 함께 성장해야 합니다.
같은 맥락을 공유하기 위해 가장 중요한 것은,
이 맥락을 공유하는 모든 이해관계자들에게로의 세심한 관찰, 그리고 행동입니다.
동료와의 피드백에 더 많은 시간을 쓰고, 더 적극적으로 이야기해 보세요.
그 첫걸음으로 나를 위한, 동료를 위한, 프로덕트를 위한 PR을 작성해 보세요.
언젠간 소설 보다 더 어려운 글쓰기도 동료와 함께 쉽게 써 내려갈 수 있길 소망합니다.
처음 이 방법을 소개해 주신 오스틴, 그리고 지금까지 PR 작성에 도움을 주신 모든 동료분들에게 감사의 뜻을 전합니다!
