주니어의 짝코딩 경험기

Euntak·2019년 5월 8일

좌충우돌 실무 경험기

목록 보기

1/1

입사 후 처음으로 짝코딩을 경험하면서 좋았던 점과 아쉬웠던 점을 적어봤습니다.

나는 어떻게 짝코딩을 하게 되었나?

입사 6개월 후, 프로젝트의 새로운 피쳐(Feature)를 개발하는 업무를 맡게 되었다. 업무를 맡기 전에는 전반적으로 프로젝트가 어떻게 구성되어있는지 구조를 혼자 그려보거나 문서로 정리해보는 형식으로 프로젝트를 파악하고 있는 상태였다.

당연히 혼자서 아무런 배경지식 없이 코드만 보고 큰 프로젝트의 구조와 의미를 파악한다는 것은 쉽지 않았고, 솔직히 봐도 잘 모르겠는 부분이 대부분이었다.

이때, 하늘에서 내려온 킹 갓 제네럴 시니어 개발자분께서 같이 페어 프로그래밍을 해보는 것이 어떻냐고 권유를 해주셨고 꽤 규모가 있는 피쳐(Feature)에 전반적으로 프로젝트의 핵심 부분들을 수정 및 추가할 기회였기 때문에 시작하게 되었다.

좋았던 점

설계 및 코드에 대한 자연스러운 공유

1. 큰 규모의 프로덕트 코드가 어떻게 동작하는지 전부 알고 있는 것은 거의 불가능에 가깝다.

직접 코드를 작성한 사람이 아니고서야 그 코드를 작성한 당시의 상황이나 히스토리 등을 알 방법이 없다.
물론 시간을 들여서 커밋 로그나 주석 혹은 작성된 코드를 보면서 그때 상황이나 히스토리 등을 유추 정도는 할 수는 있을 것이다. 하지만 이것마저 불가능한 경우가 있을 수 있고 굉장히 힘든 일이 될 수도 있다.

내가 작성한 코드를 팀원들과 공유하는 방법은 여러 가지가 될 수 있지만 짝코딩은 코드를 같이 작성하는 것이기 때문에 따로 시간을 들여서 설명하지 않아도 이미 배경이나 상황이 공유가 된 셈이다.

누군가 내가 작성한 코드에 대한 전반적인 지식을 갖고 있다는 이유 하나만으로도 힘이 될 때가 있다. 내가 작성한 코드에 결함이 있을 수 있고, 다른 팀원들이 작성한 부분에서 에러가 발생할 수 있다. 이럴 때, 히스토리를 알고 있는 팀원들과 같이 이야기하면서 수정을 할 수 있다면 코드를 고치는 데에 있어서 거부감이 줄어들 것이고 그 과정이 조금 더 수월해질 것이다.

2. 코드 베이스에 적합한 코드를 작성 할 수 있다.

짝코딩을 하고 난 뒤에는 설계에 적합한 코드를 작성할 수 있도록 신경을 많이 쓰게 되는 것 같다.
설계에 어긋나는 코드를 작성하게 되면 지금까지 코드를 작성하기 위해 투자한 시간과 설계에 적합한 코드를 재작성하는 시간이 소요된다.
이왕 작성하는 코드 설계에 적합한 코드를 작성하는 것이 좋겠지만, 혼자서는 많은 시간을 투자해야 하는 경우도 있다. 이런 상황에 누군가가 옆에서 설명해준다면?

프로덕트를 직접 설계하고 작성한 사람에게 히스토리를 듣고 코드를 보면 마치 내가 짠 것처럼 보이진 않아도 어느 정도 이해할 수 있는 수준이 되는 것 같다. 이처럼, 누군가 설계를 설명해주면서 동시에 이를 응용할 수 있는 코드를 작성하는 기회는 흔하지 않다.

이렇게 점진적으로 다른 팀원이 작성한 코드에 대한 공유가 잘되면 전반적으로 팀 전체 생산성도 좋아지는 것 같다.

노하우 훔치기 (feat. 알쓸신잡)

코드를 작성하는 스킬 적인 부분과 더불어 전반적인 노하우들을 훔칠 수 있다.
알아두면 쓸데 있는 신박한 잡기술들을 기억해 두었다가 사용하자.

코드를 작성하는 데에 있어서 각자 자신들만의 스타일이 있고, 사용하는 도구들도 다양하지만, 옆에서보다 보면 가끔 허니팁 같은게 툭툭 하고 떨어진다.

실제로 코드를 작성하면서 알게 모르게 전수되는 허니팁이 꽤 생산성에 많은 도움이 되었던 것 같다. 작업하면서 자연스럽게 이루어지니 기억에도 오래 남는 것 같다.

피드백

팀 단위의 프로덕트가 견고하게 잘 만들어지려면 팀원 간에 소통이 굉장히 중요하다.
대부분의 개발팀 내부에서 짝코딩이나 코드리뷰와 같은 프로세스를 채택하는 이유도 프로덕트를 견고하게 잘 만들기 위한 방법일 것인데 이러한 방법들의 공통적인 부분이 바로 피드백이다.

짝코딩의 가장 큰 장점 중 하나는 피드백의 주기가 아주 짧다는 점이다. 즉각적인 피드백을 통해서 코드를 작성함과 동시에 Debugging, Linting 등을 같이 진행하게 되어 휴먼 에러를 방지하는 데 많은 도움이 된다.

피드백 주기가 짧은게 장점인 만큼 궁금한거나 이해가 안되는 부분은 바로바로 질문하는 것도 중요

터널 비전

알 수 없는 에러가 발생하기도 하고 수많은 이유로 인해서 코드를 작성하는 데 있어서 브레이킹이 걸리기 마련이다. 혼자서 코드를 작성할 때, 특히나 답이 정해지지 않은 문제 혹은 복잡하고 까다로운 작업을 할 때는 더욱더 터널 비전에 빠지기 쉽다. 말 그대로 시야가 좁아져 더 나은 솔루션을 위한 생각에 브레이킹이 걸리는 것이다.

짝코딩은 네비게이터와 드라이버가 의견을 주고받으며 코드를 작성하기 때문에 서로 터널 비전에 빠지지 않게 도움을 줄 수 있다.

아쉬웠던 점

집중력

오랜 시간 집중을 할 수 있는 것도 능력이다. 라는 말이 와닿는 경험이었다.
짝코딩 특성상 순간 상대방의 말을 놓치거나 딴생각을 하게 되면.. 이후에 작성되는 코드들을 이해할 때 더 많은 시간과 노력이 필요하게 된다. 그 때문에 엄청난 집중력을 필요로 한다.

처음에는 집중이 너무 안 돼서 힘들긴 했지만, 시간이 지나면서 집중할 수 있는 시간도 늘어가는 것 같다.

서로 상태를 체크를 해주세요.
집중력이 떨어졌을 경우 휴식 시간을 적극적으로 활용할 것
짝코딩이 끝나면 정말이지 피로 백만마리가 몰려오는 느낌이다.

전문성 훔치기

앞서 소개했던 노하우 훔치기와는 약간 다른 느낌이긴 하지만 맥락은 비슷하다.
전문성 훔치기는 하드 스킬에 대한 것들을 배우기 위해서 가장 가까이에 있는 전문가의 설명을 잘 끌어내야 하는데 이 부분이 많이 부족했던 것 같다.
물론 킹 갓 제네럴 시니어분께서 부가적인 설명을 해주실 때도 있긴 했지만 지금 와서 생각해보니 내가 조금 더 적극적으로 질문을 해야 했지 않나... 라는 아쉬움이 남는다.

시니어 : 이 부분은 이 클래스를 상속받아서 작성을 하는 것보다는 포함 관계로 해결하는 게 여러모로 좋을 것 같네요.
주니어 : (...그런가? 갸우뚱?) 아..
시니어 : 이 부분은 부모와 자식이 is-a 관계가 아니기 때문에 상속을 사용했을 때 ...(중략)... 리팩토링이 어려워지는 문제가 있어요.
주니어 : (아, 그런 문제가 발생할 수 있구나.) 아하.

기록 남기기

코드를 작성하면서 깔끔하게 처리하지 못하고 애매하게 처리(Workaround)하거나 나중에 처리해야지 하고 넘어갔다가 까먹은 경우도 종종 있다.

코드에 정확하게 의도가 전달되면 베스트
해당 이슈를 바로 처리하지 못하는 경우 Workaround 대한 설명은 상세하게 적는 것이 좋다.
* 향후에 Workaround 관련한 코드를 수정할 때 수월하게 할 수 있도록 충분히 증거를 남겨야한다.
- 보통 내가 작성한 코드는 내가 수정할 가능성이 높기 때문에 미래의 나를 위해서라도...
주석으로 처리하지 않는 경우에는 팀원 모두가 볼 수 있는 곳에 기록하여 남겨둔다.
* JIRA Issue (description, comment...)
- 슬랙 채널 혹은 사내에서 사용하는 퍼블릭한 공유 채널

일정 측정

개발자의 운명은 데드라인에 의해서 결정이 될 만큼 일정 산출은 나름 중요하다.
엑셀에 이슈별로 정리해서 이슈별 예상 시간을 짐작해보고 실제 개발에 걸린 시간과 얼마나 차이가 나는지 대략적으로라도 비교해보는 작업을 했었지만, 끝까지 관리를 잘하지 못해서 아쉬웠다.

드라이버와 네비게이터의 교체 시기

생각보다 이 부분이 잘 지켜지지 않는 것 같다.

정해진 시간 단위
현재 개발하고 있는 작업 단위
쉬는 시간 및 정리 시간

중간에 쉬는 시간과 함께 작업한 요소들에 대해 정리를 하는 시간은 별도로 가지는 것이 좋다.
지금까지 진행했던 작업에 대해 서로 싱크를 맞추고 앞으로 어떻게 진행할 것인지 대략 얘기할 수 있기 때문이다.

지금 나의 생각과 항상 비교를 해야 한다.

나라면 어떻게 했을 텐데와 같이 비교를 통해서 결과물이 다를 때 짝에게 생각을 물어보는 것이 중요하다.

드라이버와 네비게이터 모두 어떤 문제에 직면했을 때는 서로의 의견을 물어보는 것이 좋다. 같은 생각을 하는지 다르다면 왜 그렇게 생각하게 되었는지에 대해 서로 대화를 하는 것이 성장의 발판이 되었던 것 같다.

주니어 : 음.. 여기서 타입 불일치가 생겨서 문제가 생기네요. 어떻게 해결하면 좋을까요?
시니어 : 주니어는 어떻게 생각해요?
주니어 : 타입을 새로 정의하는 것이 좋을 것 같아요.
시니어 : 왜 그렇게 생각하셨나요?
주니어 : 이전에 사용하고 있는 타입을 수정하면 사이드 이펙트가 발생할 수 있을 것 같아서요.
시니어 : 아하, 저는 주니어가 말한 방법도 좋을 것 같긴 한데 (중략) ... 이렇기 때문에 이런 방향이 더 적절한 수정이지 않을까 싶네요.
주니어 : 흠칫. 두둠칫.

위의 예시로 든 대화가 적절하진 않을 수도 있지만 대체로 이러한 흐름의 대화는 주니어에게 문제의 근본적인 원인을 해결하기 위한 능력을 기를 수 있기 때문에 확실히 많은 도움이 되었던 것 같다.

드라이버는 타이핑만 해서는 안 된다.

짝코딩을 진행하면서 제일 많이 느꼈던 것 중 하나가 현재 내가 작성한 코드가 나의 아이디어가 아니라면 코드를 정확하게 이해하도록 노력해야 한다. 앞서 말했지만, 코드를 이해하는 것도 중요하지만 왜 이렇게 코드를 작성했는지에 대한 배경과 상황들도 같이 인지를 하고 있어야 한다.

이해가 되면 코드는 자연스럽게 막힘 없이 작성될 것이다.
선 이해 / 후 타이핑
선 이해 & 타이핑 / 후 정리 & 피드백

두려움 때문에 피드백 주기가 짧을 수 있었음에도 불구하고 늘어진 것.

같이 집중할 수 있는 시간은 얼마 되지 않고 이 시간 만큼은 효율적으로 사용해야 한다는 압박감 때문에 일단 코드가 정상 동작하니까 OK, 나중에 혼자 살펴봐야지 하고 나중에 이해한 뒤 질문해야 하는 경우도 종종 발생한다.
혹은 이런 기본적인 것도 몰라!?라는 소리를 듣게 될까 봐 그렇다면 마음에 상처가 생길까 봐 두려워서 미루기도 했다.

이런 경우, 질문을 간단명료하게 정리해서 요청한다.
* 메일 혹은 슬랙에 멘션과 같은 기능을 이용해서 남긴다.
하지만 나중에 이해한 뒤 질문을 해야 하는 상황에서 같이 진행하던 짝이 다른 일 때문에 바쁘다면? 계속 피드백 주기는 늘어진다.
결국 코드에 똥을 싸게 되는데....

중요한 건 서로에 대한 신뢰와 상태를 파악하는 것이 짝코딩의 시작이다. 두려움은 대부분 일어나지 않을 일에 대해서 미리 걱정하는 것 때문에 생기는 것이므로... 일단 모르면 지르고 봐야 한다. 그 후에 일어날 일들은 이후에 생각해도 늦지 않다.

마음가짐

짝코딩과 관련하여 구글링하던 도중 발견한 2010년에 작성된 글에 달린 댓글들이다.
밑줄 쫙 돼지 꼬리 달고 별 다섯개로도 부족한 부분인 것 같다.

상대방이 실수할 때 서로 거리낌 없이 지적해도 괜찮아야 합니다.
신뢰를 바탕으로 한 충돌이 거침없이 일어나야 합니다.
비난하거나 비꼬거나 한 수 가르치겠다는 생각이 아니라 생산적인 충돌이어야 합니다.

이러한 마음가짐을 가지고 있는 당신. 당장이라도 짝코딩을 시작해도 좋다.

짝코딩 선언문

짝코딩 선언문이라고 정하고 싶을 정도로 좋은 글이다.
만약 짝코딩 하고 있다면, 진행 하기 전에 한 번씩 가슴속으로 외치고 시작하자.

코드의 소유와 책임이 개인이 아닌 팀에 있다. 아무나 다른 사람의 코드를 비판하고 고칠 수 있다.
"우리"에 잘못이 있지, 특정인에게 잘못이 있지 않다. 코드는 비난하더라도 사람은 비난하지 않는다.
같이 일하다 결과가 있을 때마다 서로 축하한다. 하이파이브나 괴성 등으로 서로의 감정을 공유한다.
급한 일이 있으면 상대에게 이야기하고 양해를 구한다. 서로 존중하면서 해결해야 할 사적인 문제는 바로 해결한다.
아무리 나보다 못한 사람에게도 배울 점이 있음을 간과하지 말며, 나도 언제나 다른 사람이 저지르는 실수를 똑같이 저지를 수 있음을 잊지 않는다.
좋은 아이디어가 있으면 바로바로 상대방과 상의하며 개발한다.
짝이 틀린 것을 지적하면 고마움을 표한다.
짝이 틀린 길로 들어서면 바로 지적한다. 만일 그에 대해 짝이 멈추지 않게 계속한다면 의중을 파악하려고 노력한 후 그래도 자신이 옳다는 생각이 들면 기회를 기다렸다가 조리 있게 왜 그것이 틀렸는지 설명한다.
일이 안 풀리고 막히면 바로 상대에게 넘긴다.
상대에게 프로그래밍을 해설 및 중계방송하는 느낌으로 자신의 생각을 끊임없이 말해준다. 상대가 자기 생각을 이야기하면 귀담아듣고 문제는 없는지 어떻게 앞으로 일들이 펼쳐져야 할지 머릿속에 그리며 함께 일한다.
일을 마치기 전에 상대에게 얼마나 고마운지, 짝이 없었다면 자신이 얼마나 형편없는 결과물을 만들어 냈을지 서로 이야기 하고 격려한다.
열심히 일한 후에는 칼퇴근 한다.

마치며..

처음에 짝코딩했던 경험들을 잘 정리해둘걸.. 😇
여러 가지 공유할 방법을 고민하던 중에 개인 블로그에 올리면 아무도 보지 않을 것 같아서 velog에 쓰게 되었네요.
짝코딩을 경험하고 나서 꽤 시간이 지난 뒤에 글을 작성한 터라 기억을 더듬더듬하며 적은터라 많이 부족하겠지만, 제 경험이 다른 분들에게 조금이나마 도움이 되었으면 좋겠습니다.

쓰다 보니 좋았던 점도 많고 아쉬웠던 점도 많네요. 처음 시작할 때 기대 반 두려움 반이었는데, 지금은 다른 사람들에게 권유하고 싶은 생각이 들 정도로 만족하고 있습니다.

많은 개발자분이 건강하고 행복한 짝코딩을 경험하길 바라면서.. 피드백은 언제나 환영입니다!

감사합니다 🤗