1. OKKY 1월 세미나 한번 듣고 평생 써먹는 코드 리뷰 노하우
한줄요약: 코드 리뷰의 중요성과 방법론
| 시간 | 요약 |
|---|---|
| 25:12 | 코드 리뷰는 단순히 오류를 찾는 것이 아니라 코드의 가독성과 유지보수성을 높이는 데 중점을 두어야 함. |
| 26:41 | 리뷰어가 피드백을 줄 때 구체적인 예시를 통해 설명하는 것이 효과적이며, 이는 이해를 돕고 팀원 간의 신뢰를 쌓는 데 기여함. |
| 28:12 | 팀원 간의 코드 리뷰 문화가 정착되면 전체적인 개발 효율성이 향상되고 팀의 목표 달성에 기여함. |
| 32:12 | 코드 리뷰는 여러 번 진행하여 리뷰어가 피처 브랜치에서 여러 번 리뷰를 올리면 시간을 절약할 수 있음. PR 작성 시 주석을 잘 다는 것이 중요함. |
| 34:41 | 코드 리뷰는 단순한 검토가 아니라 팀의 성장과 발전을 위한 중요한 과정임. 각자의 경험과 노하우를 공유하는 기회가 됨. |
| 53:42 | 리뷰 과정에서 발생하는 질문은 팀원 간의 이해도를 높이고 서로의 기술적 성장에 기여함. |
| 01:35:11 | 코드 품질 향상은 개발 속도를 높이며, 기존에 4주 걸리던 기능 개발이 3주로 단축될 수 있음. 이는 회사의 인정을 받을 수 있는 기회를 제공함. |
| 01:35:42 | 버그 장애는 소프트웨어 개발의 숙명으로, 변경을 최소화하는 것이 가장 좋은 방법임. 코드 리뷰를 통해 버그를 줄일 수 있지만, 완전히 없앨 수는 없음. |
| 01:38:12 | 설계 리뷰는 회의실에서 화이트보드를 활용하는 것이 효과적이며, 문서 정리보다는 시각적으로 함께 검토하는 것이 더 유익함. |
2. 스크립트
이직을 어떻게 했냐는 질문이 있더라고요. 그래서 제 소개부터 시작하겠습니다. 어떻게 이직을 했는지 간단하게 말씀드릴게요. 학교 졸업 후 처음에 LG에서, 지금의 LG CNS에서 개발자로 처음 업무를 시작했습니다. 굉장히 재미있게 일을 하다가 1999년 가을쯤, 개발만 하지 말고 외주 관리도 하고 제안서도 좀 쓰면 좋겠다는 이야기를 들었습니다. 그때 우리나라에서는 닷컴 버블이 시작되고 있었고, 운 좋게도 어느 리프팅 업체와 연락이 되어 새로운 회사로 갈 수 있는 기회가 생겼습니다. 이 회사는 제가 개발에 처음부터 끝까지 다 해볼 수 있다는 점이 가장 큰 매력이었습니다. 그 회사와 다른 회사는 그 당시 벤처라고 불렸고, 스타트업이라고 하지 않았습니다. 정말 재미있게 일할 수 있는 그런 회사였습니다. 이 회사에서 재미있게 일을 하다가, 저는 굉장히 뛰어난 선배들을 몇 분 만났고, 그분들한테 많이 배웠습니다. 정말 좋게 지냈는데, 회사가 엑시서에서 실패하면서 운영 모드로 들어가게 되었습니다. 그래서 재미가 떨어지고 있던 참에 다른 벤처에서 연락이 와서 재미있는 일을 할 수 있게 되었습니다. 시작을 하다가 예산이 나중에 경영학과와 함께 회사가 어려워졌습니다. 그래서 그때 아는 분 소개로 다음 회사에 들어가게 되었고, 다음 회사와 카카오까지 해서 한 10년 정도를 다녔습니다. 이때는 게시판, 지금은 다 없어졌죠, 억울하게 게시판 같은 걸 했고, 그다음에 클라우드 플랫폼을 만드는 일, 검색 등을 했습니다. 2014년 1월부터 저희가 개발 본부장으로 처음 일을 하게 되었고, 그때부터 본부장으로서 여러 가지 일을 하게 되었습니다. 10년 카카오에서 있다가, 10년 전 10월쯤, 11월쯤에는 이 회사에서 더 기여하는 게 별로 없는 것 같고, 여기서 성장하는 것도 많이 못 느끼는 것 같다는 생각이 들어서 SK 플래닛으로 이직하게 되었습니다. 플래닛에서는 11번가로 분사가 되면 11번가에서 스프링 클라우드 기반으로 MS에 적용하는 일이나 카프카 기반의 결제 시스템, 이벤트 트래픽 수신 등의 일을 했습니다. 그런데 제가 화면을 이걸 못 쓰네요. 잠시만요. [음악] 그러면서 이제 실험에서 제가 할 수 있는 일이 다 된 것 같다는 생각이 들어서 지금은 이직을 좀 생각하고 있습니다. 그리고 저는 관심 있는 것들은 지속 가능한 소프트웨어 개발입니다. 주로 자바로 객체 지향을 많이 했기 때문에 OP라고 써 놓았고요. 그다음에 개발자 역량 증대에 대한 관심이 많았습니다. 이런 것들을 하기 위해서 개발 문화를 개선하거나 개발자를 성장시키는 방법, 코드 리뷰의 절차는 어떤 것들이 있는지, 코드 리뷰가 왜 어려운지, 기법들은 어떤 것들이 있는지 등을 말씀드릴 예정입니다. 그런데 여기서 말씀드릴 때 코드 리뷰가 뭔가 어떻게 하는 건가에 대한 자료는 아마 인터넷에 많이 나와 있고, 정리하기만 하면 될 것 같은데요. 왜 해야 되는지, 왜 중요한지에 대한 내용을 전달하는 게 좀 어려웠던 것 같습니다. 그래서 제 발표 내용에서는 이 부분을 좀 더 중요하게 들어주시면 좋겠습니다. 자, 우리가 살고 있는 시대는 어떤 시대인가요? 지금 도대체 어떤 시대이기 때문에 개발자가 그렇게 부족할까요? 개발 성능과 생산성은 얼마나 중요해지고 있을까요? 그리고 공학적인 측면에서 소프트웨어 공학은 다른 공학과 어떤 차이가 있길래 코드 리뷰가 정말 의미가 있을까요? 소프트웨어를 많이 하는데, 과연 학교에서 배운 것만으로는 왜 안 되는지, 그 정의나 목적은 무엇인지 등을 말씀드려 보겠습니다. 2011년에 마크 안데르센이라는 사람이 월스트리트 저널에 '소프트웨어가 세상을 집어삼키고 있다'고 말했습니다. 이분은 굉장히 유명한 분으로, 모자이크와 SK에 관련된 분이며, 지금은 VC 같은 일을 하고 계신 것 같습니다. 그 당시에는 소프트웨어가 많은 도메인에서 핵심적인 역할을 하게 될 것이라고 예측했습니다. 2011년이라면 10년이나 된 이야기인데, 그때는 보더스와 아마존, 넷플릭스와 블록버스터의 비교가 많이 언급되었습니다. 보더스는 오프라인 서점으로, 오프라인과 온라인 서점의 전략이 중요하지 않다고 판단하여 모든 것을 아마존에게 넘겼습니다. 그렇게 넘기고 나서 보더스는 회사가 없어지는 일을 겪었습니다. 블록버스터는 넷플릭스와 비교되며 굉장히 힘든 상황에 처해 있었습니다.. 블록버스터는 이제 더 이상 존재하지 않습니다. 그런데 아마존은 이제 서점이 아니라 커머스 회사가 되었죠. 이런 서점이나 비교 대여점뿐만 아니라, 굉장히 다양한 영역에서도 온라인 소프트웨어가 중요한 역할을 계속하고 있다는 얘기가 10년 전부터 있었습니다. 그 다음에 2016년에 4차 산업이라는 말이 세계 경제와 함께 나왔는데, 4차 산업은 다들 잘 아실 거예요. ICT 융합으로 이루어진 차세대 산업혁명인데, 여러 가지 기술에서 새로운 기술 혁신을 이루어 비즈니스의 혁신을 이룰 것이라는 얘기입니다. 4차 산업혁명의 중요한 특징 중 하나로 북한은 변동성, 불확실성, 복잡성 등을 언급하고 있습니다. 불확실하고 복잡하며 변화가 많은 세상이 될 것이라고 했는데, 지금 저희는 그런 세상에서 살고 있습니다. 그 중에서 가장 강한 속성은 변동성이라고 생각합니다. 변화의 속도가 점점 빨라지고 있어서, 우리가 뭔가를 예측하고 준비하는 것이 점점 힘들어지고 있습니다. 그래서 더 애절하게 일하는 것이 필요해지는 세상으로 가고 있는 것 같습니다.. 작년, 마이크로소프트 CEO인 사티아 나델라가 '길드 2021'이라는 마이크로소프트 컨퍼런스에서 이런 얘기를 했습니다. 글로벌 GDP에 대해 이야기하면서 사실은 미국의 산업체들만 언급했는데요. 미국의 업체들에서 테크의 비율, 즉 정보 기술의 비율을 보면 2020년에 5%였고, 2030년에는 10%가 될 것이라고 합니다. 그러니까 10년 만에 갑자기 두 배가 되니 굉장히 많이 늘었다고 얘기했습니다. 그런데 중요한 것은 10%밖에 못 간다는 것입니다.아직도 남는 것이 90%가 있다는 것이죠. 그래서 디지털 트랜스포메이션이라는 말을 저는 그리 좋아하지 않지만, 디지털 트랜스포메이션은 이제 시작일 뿐이지 완료되는 시점이 아니라는 것입니다. 앞으로 점점 더 소프트웨어 개발이 중요해질 것이라고 얘기했습니다.. 또한, 지난 2년 동안 주로 미국에서 IT가 들어가지 않는 영역에서 개발자 수의 증가 속도가 원래 주인 회사의 개발자 증가 속도보다 훨씬 더 가파르다고 언급했습니다. 자동차 산업에 대해 이야기하자면, 지금 전기차와 자율주행차가 나오면서 개발자가 많이 필요할 것 같죠. 그런 영역에서 기계공학을 전공한 사람보다 소프트웨어를 전공한 사람을 35% 더 채용했다고 합니다. 그래서 점점 개발자가 많이 필요해지는 세상이 되고 있다는 것입니다.. 그렇다면 개발자가 얼마나 부족한지에 대한 자료를 찾아봤습니다. 2020년 기준으로 미국의 전체 인구 대비 개발자 수가 조사되어 있고, 우리나라의 전체 인구 대비 개발자 수도 조사되어 있습니다. 미국의 인구는 3억이 조금 넘고, 우리나라보다 약 6배 정도 많습니다. 예를 들어, 우리나라의 개발자 수가 2020년 기준으로 약 17만 명 정도 되는데, 미국은 그보다 6배가 아니라 약 400만 명 정도 됩니다. 그러니까 우리나라가 미국과 유사한 비율로 개발자 수를 맞추려면 지금보다 4배는 많아야 합니다. 미국에서는 현재 개발자 수가 인구를 고려할 때 3배는 더 많아야 한다고 얘기하고 있습니다. 그러면 우리나라는 4배가 아니라 12배 정도가 많아져야 한다는 것입니다. 그만큼 지금 개발자가 부족한 세상에 살고 있습니다. 비즈니스가 성공하려면 개발이 굉장히 중요한 역할을 하게 된 것입니다. 아까 말씀드린 것처럼 4차 산업혁명 시대의 특징인 불확실성과 빠른 변화 속에서 비즈니스가 성공하기 위해서는 더 빨리 혁신을 이루어야 하고, 이를 위해 개발자가 필요하다는 것입니다. 오라클 컨퍼런스에서 크리스 리처드슨이 한 얘기에 따르면, 빠르고 안정적으로, 그리고 더 자주 해야 한다고 합니다. 그래서 이런 것을 할 수 있는 개발 조직의 성능과 생산성이 중요해지고 있다는 것입니다. 우리는 계속해서 출시를 하면서 우리의 생산성을 높여야 합니다.. 성은 어떻게 되나, 이런 걸 좀 보면요. 이 장편은 이제 그 로봇이 마틴이 쓴 클린 아키텍처 일정에 나오는 내용인데요. 여기 보면 괄호 측은 출시 회차예요. 회차는 첫 번째 출시, 두 번째 출시, 세 번째 출시 이렇게 가고 있고요. 그다음에 새로 측은 엔지니어링과 개발자 수예요. 출시가 증가함에 따라서 개발자 수는 기하학적으로 늘고 있어요. 그러면 이 개발 생산성도 뭐 유지가 되거나 늘고 있냐 하면, 처음에 첫 번째 출시 때는 생산성이 100%였는데, 이 생산성은 이제 회차별로 출시별로 100%였는데 점점 줄어든다는 거예요. 그래서 여덟 번째 출시할 때는 앞에 개발자는 이렇게 늘었지만, 지금 생산성은 이렇게 떨어진 걸 볼 수 있는 거죠.. 예, 이렇게 되는 거의 원인에 대해서 좀 보면요. 이 그래프는 이제 마틴 파울러가 작성한 그림들이 있는 건데요. 그 디자인 스태미나 하이퍼센티스, 그래서 이제 개발 설계 체력 가설, 뭐 이런 얘기인데요. 여기 보면 오른쪽은 시간이에요. 가로축은 시간이에요. 시간이 흐름에 따라서 누적된 기능의 수가 늘어나는데, 이렇게 선형적으로 계속 늘어나면 좋겠는데, 어떻게 되냐면 처음에는 좀 늘어나는 것 같지만, 시점이 지나면 그 다음부터 더 이상 늘어나지 못하고 줄어들고 있다는 거예요. 예, 이게 보면 이제요, 라인이 뭐였냐면 그 설계 수익 라인, 설계 수익성인데요. 시점을 딱 지나면 이제 더 이상 빠르게 진행되지 않고 느리게 된다, 이제 그런 얘기를 하고 있습니다.. 이게 왜 이러냐면, 만약에 우리가 계속해서 좋은 설계를 가지고 있다면 새로운 기능을 추구하는 데 어려움을 겪고 있지 않겠지만, 좋은 설계 없이 그냥 빠르게 개발하다 보면 어느 순간부터는 우리가 기능을 추가하는 데 시간을 쓰지 못하고, 기존에 쌓아 놓은 어떤 문제들을 해결하느냐고 기술 부채를 해결하느냐고 우리 시간을 많이 사용하게 되어서 시간이 지나면 점점 생산성이 떨어지는 모습을 보여준다는 거죠. 이제 그런 걸 보여주는 그래프입니다.. 그러면 이제 왜 소프트웨어 공학은 시간이 지나면서 그 생산성이 떨어지는 그런 일들이 많이 일어나나, 나는 공학하고는 뭐가 다른가, 이런 걸 좀 살펴보도록 하겠습니다. 공학이라는 것은 설계와 설계물을 가지고 어떤 것을 구축하는 빌드 과정으로 볼 수 있는데요. 설계라는 것은 대부분 예측하기 어렵고, 급여가 비싸고, 창의적인 사람들을 필요로 하는 영역이고, 빌드는 좀 더 예측하기가 쉽고, 그리고 급여가 저렴한 사람들을 써서 할 수 있는 부분이다, 이렇게 얘기를 합니다.. 건축공학 같은 경우 설계와 빌드가 아주 명확하게 분리가 되어 있고, 설계하는 사람이 빌드에 참여하거나, 빌드하던 사람이 설계에 참여하는 일은 없다, 이제 그런 얘기를 합니다. 그리고 건축공학은 빌드 비용이 굉장히 비싸대요. 설계 비용, 설계하는 분이 연봉이 아무리 높다 그래도, 빌드 비용이 건축은 전체 비용의 90% 정도가 빌드 비용이라고 얘기를 하고요. 그다음에 이 공항이 건축공학과 유지비, 유지보수 비용이 상대적으로 굉장히 낮다고 합니다. 소프트웨어 공학에 비해서요.. 그런 공학 활동의 최종 목적은 빌드를 할 수 있는 어떤 종류의 재생산 가능한 문서여야 한다는 거예요. 그 문서가 있다면, 뭐 설계도겠죠. 설계도만 있다면 누가 만들어도 동일한 결과물을 만들 수 있어야 한다고 얘기할 수가 있겠지요. 그런데 소프트웨어 공학은 보면 설계와 빌드가 좀 달라요. 설계는 문서를 만들었다고 해서 그 문서나 다이어그램을 보고 동일한 결과물을 만들어 낼 수 있는 것이 아니에요.
그러니까 동일한 UML 다이어그램이라도 누가 구현하는지에 따라서 약간 다르게 동작하는 코드가 나올 수 있다는 거죠. 예를 들어, 다이어그램만 가지고는 충분히 코드를 완벽하게 제어할 수 없는 거죠.. 그래서 소프트웨어에서 설계는 다이어그램이 아니라 소스 코드가 설계다라고 얘기하는 분들이 있어요. 소스 코드는 어떤 컴파일러를 누르고 어떤 빌드 툴을 돌려도, 우리가 나지 않는다면 동일하게 동작하는 그런 결과물을 만들어 낼 수 있는 것이죠. 그래서 재생산 가능한 문서가 소프트웨어 공학에서는 그냥 컴파일하고 링킹하는 거예요. 지금은 뭐 그냥 IDE에서 내가 에디터에서 뭔가를 수정하면, 실시간으로 다 컴파일을 하잖아요. 그리고 배포를 하기 위해서 자르거나, 뭐 만들 때 그때 정도는 빌드를 돌리지, 빌드의 비용은 거의 지금 소프트웨어에서는 거의 없다라고 느껴질 만큼, 특히 인건비는 거의 안 들어가는 거죠. 그런 영향인 거죠.. 그래서 소프트웨어 공학에서의 좋은 설계라는 것은 좋은 코드예요. 설계 산출물이 코드이기 때문에 좋은 설계는 좋은 코드가 되는 거죠. 그리고 우리가 소프트웨어 엔지니어라고 얘기했을 때, 소프트웨어 개발자, 소프트웨어 엔지니어라고 했을 때, 우리는 설계를 잘하는 사람이 되어야 하고, 설계를 잘하는 사람이라는 것은 코드를 잘 작성하는 사람이 되어야 한다는 걸로 이제 얘기를 할 수 있을 것 같아요. 그러니까 이제 클린 코드는 굉장히 중요하다고 생각합니다.. 얘기할 수가 있어요. 좋은 설계를 갖는 코드이기 때문에 소프트웨어 비용을 한번 보면, 소프트웨어에서의 전체적인 비용을 보면 개발 비용보다 유지보수 비용이 훨씬 높아요. 아까 건축공학에서는 빌드 비용이 한 90%라고 하고, 유지보수 비용은 거의 발생하지 않는다고 했어요. 그렇지만 수표 공항을 보면 유지보수가 전체 비용의 한 80% 이상을 차지한다고 많이들 얘기하고 있어요. 우리가 어떤 코드를 한번 작성하면, 만약 그 코드가 계속해서 사용되는 코드라면, 우리가 정말 한 번도 사용되지 않는 코드를 작성한 게 아니라 사용되는 코드를 작성한 것이라면 그 코드는 적어도 10번 이상 읽힌다고 해요. 그리고 코드를 작성하는 데 드는 노력과 코드를 이해하는 데 드는 노력을 보면, 코드를 이해하는 데 드리는 노력이 한 10배 정도 크다고 해요. 그러면 10번 이상 읽히고, 한 번 읽을 때마다 10배 이상의 노력이 든다고 보면, 작성할 때보다 한 100배 정도 노력이 드는 거예요. 우리는 소프트웨어 개발자이기 때문에 우리의 시간을 많이 쓰는 것 같지만, 엄격하게 보면 아이 요구 사항을 어떤 모듈에, 어떤 파일에, 어떤 함수에 넣을까, 어떻게 변경할까 이런 것들을 확인하기 위해 코드를 이용하는 데 굉장히 많은 시간을 소모하고 있어요. 실제로 우리는 새로운 기능을 추가하는 데 많은 시간을 사용하지 않는다고 많은 사람들이 얘기하고 있습니다. 빨리 간다고 생각하지만, 설계 수익 라인이 지나면 그 다음부터는 기술 부채가 생겨서, 우리가 저번에 새로운 기능을 추가하는 데 드리는 노력을 하지 못하고 기존에 있던 잘못된 코드를 수정하는 데 이해하는 데 많은 시간을 들이게 되어 새로운 기능을 빨리 넣지 못하게 된다고 합니다. 그래서 시간이 흘러도 생산성 저하와 비용 증가를 막으려면 우리는 그냥 빨리 가는 게 아니라 잘 가야 한다고 설명할 수 있을 것 같아요. 그래서 소프트웨어 품질에 대해서 우리는 매우 신중해야 합니다. 소프트웨어 품질의 비용과 관계는 비정상적이고 비논리적이라고 얘기하는데요. 일반적으로 핸드폰을 예로 들면, 갤럭시나 아이폰 같은 품질이 좋은 핸드폰은 대부분 비쌉니다. 그러면 품질이 좋은 소프트웨어는 항상 비싸냐? 그렇지 않다는 거죠. 품질이 좋은 소프트웨어는 향후 변경 비용과 추가 비용을 낮춰서 품질이 높다고 할 수 있습니다. 초기에는 품질이 높은 소프트웨어의 비용이 더 높을 수 있지만, 실제로는 품질이 높은 소프트웨어가 비용을 더 낮춘다고 얘기합니다. 그래서 우리가 일반적으로 알고 있는 비용과 품질 간의 트레이드오프, 즉 품질이 높으면 비용이 높고 비용이 낮으면 품질이 낮아진다는 그런 트레이드오프는 약간 뒤집어지는 것 같습니다. 소프트웨어 품질에 대해서 우리가 좀 더 신경을 써야 하고, 개발자의 자부심이나 전문가 정신으로 얘기하면 재무적인 입장에 있는 영업 조직이나 회사 대표님들과는 설득할 수 없다는 거예요. 그래서 우리가 품질이 좋으면 향후 추가 비용을 낮춰서 비용에 기여한다고 비즈니스 측면에서 설명해야 한다고 말씀드리고 싶습니다. 그리고 아까 말씀드린 것처럼 소프트웨어에서 굉장히 중요한 것은 좋은 설계, 좋은 코드, 품질인데, 이런 것들은 대학교 다닐 때 컴퓨터학과에서 배우지 못했어요. 저 같은 경우는 소프트웨어 공학으로 석사를 했는데, 그때는 그런 걸 많이 배우지 못했거든요. 그래서 왜 합격할 때 우리가 이런 걸 많이 못 배웠나 하는 생각을 해봤습니다. 학교 다닐 때 교수님들한테 배운 것은 이론에 대한 설명이나 그것을 구현하는 것에 대한 얘기는 들었지만, 그것을 구현하고 소비자, 사용자들이 사용하면서 들어오는 요구 사항 변경을 다뤄본 적은 없는 것 같아요. 그래서 소프트웨어 장인 정신에서 얘기하는 여러 가지 중에 저는 이 부분이 제일 맞았는데요. 학교에서 배운 지식만 가지고는 안 되고, 우리가 업무를 수행하면서 얻은 경험과 지식의 공유를 통해서 선배가 후배에게 혹은 후배가 선배에게 가르쳐 줄 수 있겠죠. 그런 공유를 통한 전문성을 가진 개발자를 육성하는 유일한 방법이라고 얘기하는데, 저는 이 말에 굉장히 공감하고 있습니다. 그래서 이 책을 넣었는데, 이 책을 한번 보시면 제가 말씀드린 것을 좀 더 잘 이해하실 수 있을 것 같아요. 공유를 하자는 게 아니라 결함 없이 소프트웨어를 배포하려고 하는 것이 가장 큰 목적이겠지만, 그 주목적 외에 코드 리뷰를 한다면 우리는 지금부터 바로바로 공유 활동을 할 수 있을 것 같습니다. 우리 조직 내에서, 우리 팀 내에서, 아니면 우리 팀과 다른 팀에 있는 분들과 많이 공유할 수 있을 것 같다는 생각이 듭니다. 처음 온라인 코드 리뷰를 했을 때의 느낌은 SNS 댓글처럼 느껴졌습니다.. 정말 재밌었던 것 같아요. 그리고 제가 생각할 때 서로 배움을 주고받으면서 지속 가능한 소프트웨어 개발 투자가 될 수 있는 아주 중요한 실천법 중 하나가 코드라고 생각하고 있습니다. 예를 들어, 코드 리뷰는 한 명 또는 여러 사람이 주로 소스 코드의 일부를 보고 있는 방식으로 프로그램을 확인하는 소프트웨어 중지 활동으로, 지원 후에 하거나 혹은 구현을 약간 중단시키고 진행하는 방식입니다. 이건 위키피디아에 나오는 정의고요, P열 리뷰, 플리캐스트라고도 합니다. 예, 코드 리뷰의 목적은 당연히 품질 문제를 검사하는 것입니다. 알려진 버그나 장애가 있는지 미리 점검하여 오류 없는 코드가 배포될 수 있도록 하는 것이 가장 큰 목적이죠. 그런데 그 외에도 더 나은 코드 품질을 위한 활동으로 코드 리뷰를 사용할 수 있습니다. 아키텍처 속성이라는 것이 있는데, 위키피디아 같은 곳에서 찾아보면 거의 한 페이지에 걸쳐 나오는 빌런티스와 같은 많은 것들이 있습니다.
그런 것들을 개선할 수 있는 활동입니다. 그렇게 해서 우리가 향후 변경 비용을 개선할 수 있습니다. 우리가 뭔가를 만들었는데 거기에 문제가 있다면, 나중에 보시는 것보다 문제가 있는 걸 빠르게 발견하고 빨리 고치는 것이 항상 더 적은 시간에 해결할 수 있기 때문에 변경을 개선하는 데 도움이 될 것이라고 얘기할 수 있을 것 같습니다.. 코드와 해결책 관련해서 지식을 공유하는 데 기여합니다. 공유라는 것은 주고받는 것이죠. 사전 질문에서도 그런 얘기가 많이 나왔는데, 시니어가 주니어에게 뭔가를 알려주고, 알려주고, 돈을 줄 수 있지만, 주니어끼리나 주니어가 시니어에게 뭔가 도와줄 수 있는 게 있냐, 이런 얘기가 있었거든요. 리뷰어와 저자, 리뷰를 받는 사람은 리뷰를 받는 사람만 배움의 기회가 있는 것이 아니라, 리뷰어들도 자기가 뭔가를 설명하려고 하면서 더 많이 배울 수 있는 기회가 있습니다. 연차가 비슷하고 역량이 비슷하다면 하드 스킬에 대해 얘기를 많이 할 것입니다. 하드 스킬이라고 하면 개발에 구체적인 영역들을 얘기하겠죠. 그런데 시니어가 주니어에게 뭔가 정말 기술적으로 뛰어난 시니어가 기술적으로 부족한 주니어에게 알려주려고 한다면, 그냥 자기가 알고 있는 상태로 그대로 얘기하면 주니어가 알아듣기 어려울 수 있습니다. 그래서 소프트 스킬을 익혀서 시니어가 어떻게 커뮤니케이션을 해야 이 사람이 더 잘 알아듣는지를 고민해야 합니다. 여러 가지 소프트 스킬이 필요하겠죠. 친절하게 한다거나, 공감 능력이 있다거나, 가르치는 방법을 다르게 한다거나 하는 것들이 필요할 것입니다. 그런 것들을 배울 수 있는 기회도 주니어에게 제공됩니다.. 그리고 이제 11번가에서 많이 느꼈던 부분인데, 동기부여에 정말 도움이 되는 것 같습니다. 12만 원 온라인 코드 리뷰를 전체 팀들이 다 볼 수 있게 오픈되어 있습니다. 자기 팀이 아니어도 다른 팀의 코드 리뷰도 볼 수 있습니다. 그러다 보면 우리 팀에서도 물론 잘하는 분이 계시지만, 다른 팀에 더 잘하는 사람이 있다면 그 사람이 어떻게 하는지를 보고 그 사람처럼 잘하려고 하는 마음이 생기는 분들이 많습니다. 그래서 이런 동기부여에 도움이 된다고 말씀드릴 수 있을 것 같습니다.. 그다음에 상호 책임감이 증대됩니다. 코드 리뷰를 통해 배포를 하면 작성자뿐만 아니라 리뷰한 사람들도 약간 책임감을 느끼겠죠. 그래서 집단 코드 오너십이 생기고, 결속이 증대됩니다. 예를 들어, 팀이 10명이 있는데 그 팀에서 하는 일이 열 가지라고 했을 때, 10가지를 두 명이 세는 방법도 있고, 아니면 10명이 한 가지씩 일을 하는 방법도 있을 것입니다. 그런데 전자의 경우는 같이 일을 하기 때문에 서로 관심도 갖고 결속도 생기고, 우리 팀에서 어떤 일이 일어나는지 알 수 있습니다. 이렇게 해서 결속이 생길 수 있는데, 10가지를 열 명에게 그대로 나눠버리면 서로 상대방에게 일을 얘기하지 않고 업무를 진행할 수 있습니다. 그런 경우에는 우리가 왜 같은 팀이지, 우리는 같은 심정으로 뭘 하지, 옆에 있는 팀원이 뭐라고 하는지 모르겠지, 그러면서 죄책감이 들 수 있습니다. 그런데 코드 리뷰를 하게 되면, 아 이분이 이런 걸 했구나, 그걸 이해하고, 내가 이렇게 도와줄 수 있겠구나, 이런 것 때문에 결속이 생기는 걸 확인할 수 있었습니다. 당연히 개발을 한 사람이 하는 한 사람이 그냥 늘 하던 대로 하는 것이 아니라 다른 사람들이 어떻게 하는지를 보고 배우고, 이런 것 때문에 개발 문화가 개선되는 것은 분명히 효과가 있습니다. 그다음에 설계 개선이 제한되는 것도, 그냥 하는 것이 아니라, 아 이런 방법이 있는데, 이번에는 만약에 시간이 어렵다면 다음에도 공부해서 적용했으면 좋겠어요. 이런 것 때문에 설계 개선이 제한됩니다.. 거는 볼 수 있었습니다. 지금까지 이제 코디 리뷰를 왜 해야 되나, 그다음에 정의 목적 이런 걸 말씀드렸고요. 네, 이거는 제가 어떤 블로그에서 딴 그림인데요. 저자는 코드를 작성해요. 코드를 작성하고 그다음에 변경된 것에 대해서 체인지 리스트를 만들어서 리뷰어들한테 리뷰를 요청해요. 리뷰어들은 피드백을 줘요. 그다음에 PD와 함께 사이클을 돌다가 어느 순간이 되면, 아 이건 100% 되겠어요, 뭐 어제도 되겠어요. 그러면 이제 머지가 되는 거죠. 네, 이런 게 일반적인 코드 리뷰의 절차라고 말할 수 있을 것 같고요. 변경 내역은 이제 리뷰 시작 전에 작성을 하는 거고, 저자가 머지를 원하는 소스 코드에 대한 일련의 변경, 이러이러한 변경을 한 건데요. 특히 여기를 좀 잘 봐 주시면 좋을 것 같아요. 그리고 나는 이건 좀 잘한 것 같은데, 봐 주시고요. 이거는 내가 좀 이거보다 더 좋은 방법이 분명히 있을 것 같은데, 저는 모르겠는데 혹시 의견 있으면 알려 주세요. 뭐 이런 식으로 이제 그 디스크립션을 작성하면 굉장히 효과를 많이 볼 수 있을 거예요. 이거는 11번가의 코드 리뷰 플릭스 맞는 것 중 하나를 제가 따온 건데요. 11번가는 이제 크롬 확장 플러그를 만들어서 요렇게 만든 형식으로 채워낼 수 있게 돼 있어요. 그래서 보면, 디스크립션은 뭐 하는 거야, 그다음에 어떻게 테스트하면 돼, 그래서 커맨드라인에서 요렇게 명령을 치면 이제 테스트를 할 수가 있는 거죠. 그리고 커밋 메시지는 이런 것들이 있어서, 아 대략 이런 것들이 이번 변경에 포함됐구나, 이런 걸 알 수 있게 해 주는 거죠. 그리고 코드 리뷰를 할 때 시간이 많이 드는데, 얼마나 시간을 들여야 되냐 이런 질문이 많았는데요. 여기서 중요한 거는 저자예요. 저자, 리뷰어가 고생을 하는 게 아니라 리뷰이, 저자가 고생을 해야 돼요.
2.1. 코드 리뷰는 단순히 오류를 찾는 것이 아니라 코드의 가독성과 유지보수성을 높이는 데 중점을 두어야 함.
저자가 고생을 해서 리뷰어들의 시간을 아껴줘야 이게 선순환이 일어나지, 저자가 바쁘다고 대충 대충 여기다 써 놓으면, 커밋 메시지 대충 쓰고, 그다음에 리뷰 PR 올리기 귀찮다고 일주일짜리 묶어서 올리고 이런 식으로 하면 리뷰어들이 이걸 볼 수가 없어요. 그러니까 저자가 굉장히 작은 단위로 리뷰하기 좋게 만들어서 리뷰를 올리는 게 굉장히 핵심적인 영역인 것 같아요. 제가 이거를 말씀드릴 때 많이 예를 드는 게 파스칼의 편지예요. 파스칼이 친구한테 편지를 쓰면서 다섯 장짜리 편지를 썼대요. 그런데 맨 마지막에 그 말이 있었대요. 이렇게 얘기를 했다고 해요. 그러니까 이 플리캐스트에 들어가는 정보는 리뷰어들이 시간을 절약할 수 있게 해 줘야 돼요. 자기 편하다고 그냥 대충 적어 놓으면 효과적인 리뷰를 할 수가 없어. 그리고 리뷰할 때 처음 하시는 분들이 보면 이런 문제가 생겨요. 보통 저자는 본인이 되게 잘했다고 생각해서 PR을 보내요. 그러면 리뷰어는, 아 너는 그렇게 생각해? 난 그렇지 않아라고, 내가 왜 네가 멋지지 않은지 알려 줄게라고 장황한 이유를 작성해서 보내면서 서로 간에 갈등이 생기는 그런 일들을 볼 수가 있어요. 이거는 어떤 숙달에서 나온 건데, 항공술에서 자기의 기술 레벨을 과대평가한 사람들은 대부분 죽었다고 해요. 그러니까 그 정도면 뭐 충분히 잘했어요라고 해서 이렇게 선순환을 만들어내는 게 훨씬 중요한 것 같아요. 그다음에 이것도 굉장히 중요한 얘기예요. 코드에 대해서 의견을 주고 받았는데, 처음 코드를 참여하는 사람들은 코드에 대한 어떤 비판이라고 생각하지 않고 자기 자신에 대한 비판이라고 이해하는 경우가 있어요. 이러면 서로 대화가 원활하지 않게 흐르고, 코드 리뷰를 두려워하는 그런 일이 생기게 되는 것 같아요. 코드 리뷰는 지식이나 공학적 결정을 공유하는 기회예요.
2.2. 리뷰어가 피드백을 줄 때 구체적인 예시를 통해 설명하는 것이 효과적이며, 이는 이해를 돕고 팀원 간의 신뢰를 쌓는 데 기여함.
잘한 것도 오해하는 거고, 아쉬운 것도 오해하는 거예요. 이거 더 잘할 수 있는 방법은 없어요라고 물어봐서 배울 수도 있고, 이건 정말 잘한 것 같은데 다른 팀원분들도 좀 보시면 좋을 것 같아요라고 할 수도 있는 거예요. 그렇게 지식과 경험을 공유하면서 서로 학습을 하는 거예요. 그렇게 해서 업무 수행을 통해서 자기 역량을 증대시키는 수단이란 말이에요. 책만 보고 공부하는 게 아니거든요. 그래서 코드 리뷰를 개인적인 공격으로 받아들이면 이런 토론을 할 수가 없어요. 물론 잘못된 부분을 지적할 때 굉장히 조심해야 되는 것도 있고요. 누군가 나한테 지적을 했을 때, 저분이 말이 좀 그렇지 사실은 잘 하자고 하는 거야라고 마음을 풀면서, 아 이건 내 코드에 대한 비난이기 때문에 내가 감정적으로 받아들이지 말아야지, 그런 자세들이 굉장히 필요한 것 같아요. 하지만 옆에 사람을 불러다 놓고 하는 것도 아니고, 온라인으로 글로 하다 보니까 분명히 어려움이 있어요. 오해의 위험이 굉장히 커요. 어떤 사람의 음성 톤도 안 느껴지고 표정도 안 느껴지니까요. 그래서 좀 더 조심스럽게 표현해야 되는 게 있어요. 이거는 제가 그냥 영어로 돼 있는 자료도 다운받아서 그대로 썼는데요.. 사람은 이렇게 쓴 거예요. 파일랜드를 클로즈하는 걸 잊어버렸어요라고 얘기했는데, 듣는 사람은 이렇게 넣는다는 거예요. 나는 이 바보야, 네가 이 파이낸들 있는 거 이런 것도 깜빡하다니, 난 도대체 믿을 수가 없어. 이 바보야라고 이렇게 있는데요.
2.3. 팀원 간의 코드 리뷰 문화가 정착되면 전체적인 개발 효율성이 향상되고 팀의 목표 달성에 기여함.
이 문제는 미의 문제가 아니에요. 절대 그런 문장이 아닌데, 그러니까 좀 더 조심스럽게 표현하는 것들에 대해서 준다. 저도 이제 처음 코드 리뷰를 했을 때 기억나는데요. 그때는 뭐 DC 나오기 전이었어요. 금요일 오후에 같은 시간이 많을 때 SBN 커밋을 하면서, 일주일 동안 팀원분들이 컴퓨터를 쭉 보면서 이상한 게 있으면 불러서 이걸 왜 이렇게 써라고 하면서 혼내는 거죠. 그러면 서로 이제 불편해져요. 그러다가 깃이 나왔어요. 너무 좋은 거예요. 너무 편한 거예요. 그러니까 지금 뭐 플리케이스 만들듯이 로컬 브랜치를 만들어서 커밋 단위로 굉장히 리뷰하기 좋게 커밋하기로 했어요. 커밋 메시지도 잘 잡고, 그러니까 이 컴퓨터가 굉장히 작아서 확인하기가 너무 좋은 거예요. 그러고서는 이제 뭐야, 그렇게 리뷰를 하니까 불러서 뭐 설명하면서 서로 성질 부리면서 할 게 없고, 그냥 간단하게 글로 의견을 주고받을 수 있게 되더라고요. 그런 다음에 기적이 나오면서는, 아까 말씀드린 대로 SNS 댓글로 우리는 그런 느낌이었던 것 같아요. 예, 그리고 이제부터는 뭐 효율적인 풀 리퀘스트 작성하는 방법, 리뷰를 잘하는 방법, 그다음에 피드백을 주고받는 방법, 그리고 둘이 싸우는 그런 교차 상태가 있어요. 이럴 때 어떻게 하면 좋을지, 그다음에 추가적으로 코드 리뷰에 어떤 것들이 있는지 이런 것들에 대해서 좀 알아보도록 하겠습니다.. 먼저 플리케이스를 할 때는 만들 때 지루한 작업은 컴퓨터가 해야 돼요. 이걸 리뷰어가 하게 하면 안 돼요. 그다음에 스타일 가이드, 이거 가지고 코딩 스타일이 서로 달라요. 뭐 누구는 괄호를 같은 줄에 두는데, 누구는 다음 줄에 두는 것 때문에 싸우는 것도 있어서 이거에 대해서 좀 얘기를 하고요. 그다음에 PR을 올릴 때 저자가 첫 번째 주소가 되는 거예요. 굉장히 도움이 되거든요. 이런 것도 좀 알아보고요. 그다음에 피드백을 할 때는 이 사람만 포함해야지 그러지 말고 최대한 많은 사람을 뽑아가는 게 좋다. 그다음에 의미 있는 커밋으로 분류하는 것도 굉장히 도움이 됩니다. 지루한 작업은 컴퓨터로 해야 돼요. 컴퓨터 코드를 읽는 것은 굉장히 부담이 되는 작업이란 말이에요. 굉장히 집중이 필요해요. 컴퓨터가 더 잘할 수 있는 일도 있어요. 그런 일을 사람이 하게 만드는 경우가 있어요. 예를 들면 포맷팅 같은 거예요. 공백이나 들여쓰기 같은 거죠. 그런데 이런 거를 IDE에서 프로젝트에 있는 모든 파일을 다 포맷팅을 하거나 이럴 수가 있잖아요. 별도의 PR로 분리해서, 아 이거는 포맷팅만 한 거예요. 코드 변경은 하나도 없어요.
2.4. 코드 리뷰는 여러 번 진행하여 리뷰어가 피처 브랜치에서 여러 번 리뷰를 올리면 시간을 절약할 수 있음. PR 작성 시 주석을 잘 다는 것이 중요함.
리뷰 안 하셔도 돼요. 머지하면 돼요. 예, 이렇게 분리를 하면 되는 거예요. 모든 클릭 캐스트를 안 올리면 이제 배포를 못 하기 때문에 그렇겠죠. 만약에 그렇지 않다면 이런 건 아예 클릭해서 올릴 필요도 없겠죠. 그리고 테스트 빌드가 안 되거나 머지가 안 되거나 버전 컴플릿이 있거나 이런 걸 클릭해서 올리면 안 되겠죠. 적어도 그런 것들은 본인이 다 확인한 다음에 올려야겠죠. 그리고 자기가 작성한 파일에서, 저 같으면 인텔리제이의 어떤 인스펙션 툴 이런 걸 돌려서, 인스턴트에서 기계가 알려주는 결함 이런 것들을 미리 제거하고 올리면 리뷰하시는 분들이 훨씬 더 편하겠죠.. 서로 스타일 때문에도 논쟁이 있다 이런 얘기들이 있는데요. 사용하시는 건 그냥 세 개 중에 하나를 치면서 정하면 될 것 같아요. 그냥 구글 스타일 가이드나 유명한 회사 스타일 가이드를 참고해서 쓰거나, 아니면 자기들 스타일을 점진적으로 만들거나, 아니면 사용하면서 점진적으로 변경하는 하이브리드 방식도 취할 수 있다. 이거 가지고 너무 많이 논쟁해서 시간 낭비하지 말아라. 올릴 때 PR을 저자가 먼저 읽어보는 거야. 내가 원래 PR을 리뷰어들에게 보여주기 전에 내가 먼저 읽어보고, 리뷰어들에게 아 이거는 이해 못 하겠는데, 그렇다면 내가 설명을 남겨서 이 사람들이 좀 이야기 편하게 만들어야지라고 코멘트를 남기라는 거예요. 그래서 리뷰어들의 시간을 절약해 주라는 거예요.. 지금 이런 경우에, 이거는 표준화 상품 블록인데 여기에 이걸 삽입해서 괜찮은지 잘 모르겠어요. 이걸 좀 봐 주세요라고 요청을 했잖아요.
2.5. 코드 리뷰는 단순한 검토가 아니라 팀의 성장과 발전을 위한 중요한 과정임. 각자의 경험과 노하우를 공유하는 기회가 됨.
아마 리뷰어들은 이거에 대해서 좀 더 의견을 잘 줄 수 있을 거예요. 혼자 개발하는데 코드 리뷰를 해야 되는 거냐, 뭐 이런 얘기가 있었는데요. 이거는 제가 기업에 올려놓은 어떤 커밋 노트 중에 일부예요. 커뮤로를 보면 아시겠지만, 굉장히 자세하게 숫자를 레이블링까지 하면서 넣어놨거든요. 이렇게 한 이유는 보통 아주 단순한 코드가 아니라면 자기가 작성한 코드를 한 2주 후에 보면.... 남이 짠 것 같아요. 잘 이해가 안 가거든요. 그러니까 2주 후에 내가 보더라도 이해가 잘 될 수 있도록, 2주 후에 나는 거의 남이거든요. 그러면 리뷰한테 도움이 된다면서 2주 후에 나한테도 도움이 되는 거죠. 이렇게 커밋하고 프리케이스를 나눠서 배포하는 것은 혼자 하더라도 굉장히 의미가 있는 거예요. 리뷰 방법에 대해서 좀 알아보도록 하겠습니다. 리뷰는 즉시 해야 되는 거고, 고수준으로 시작해야 하며, 예제 코드를 제공할 수 있어야 하고, 리드의 범위를 존중해야 하며, 태그를 사용하는 방법도 있습니다. 그다음에 한두 등급만 코드 레벨을 올리는 걸 목표로 해라. 뭐 이런 걸 가지고 말씀드리겠습니다.. 그래서 리뷰를 바로 시작해서 선순환이 일어나게 해라. 그리고 리뷰, 코드를 읽고 피드백 시간이 필요하겠지만, 진행은 최대한 빨리 해라. 리뷰 라운드에 최대 시간이 하루가 넘지 않게 해라. 9시에 왔으면 내일 9시 전에 리뷰가 끝나도록 그렇게 유지를 해라. 내일 아침 30분, 매일 점심 식사는 30분을 리뷰를 위해서 확보해라. 1시간 정도죠. 그렇게 된다면 사람들은 이 30분 안에 자기의 캐스트가 머지가 될 수 있도록 변경을 적게 넣으려고 노력을 할 거고, 반나절 넘지 않는 작업량 정도를 피하려고 올릴 거예요. 그러면 이런 것은 1, 20분 안에 충분히 리뷰가 될 수 있거든요. 그렇게 해서 더 자주 해라. 괴로우면 더 자주 해라. 이런 얘기고요.. 그럼에도 불구하고 리뷰할 시간이 없다고 느끼는 것은 이제 회사의 평가도 문제가 있다는 거예요. 그러니까 내가 플리케이스를 올리고 커밋을 많이 한 것은 평가할 때 내 기여로 보지만, 내가 리뷰를 많이 해서 그 사람들이 좀 더 성장하게 도와주거나 아니면 그 사람들의 버그를 사전에 방지해 주고 이런 것은 평가에서 성과를 안 본다면 누가 그걸 그렇게 진짜, 뭐 그 사람이 무슨 천사도 아니고 남을 위해서 그렇게 많이 하겠어요? 그러니까 이런 것은 리뷰를 하는 게 어렵고 시간이 많이 드는 그런 문제가 아니라, 회사에서 조직적으로 리뷰를 굉장히 중요하게 안 보는 그런 조직적인 문제가 있는 거예요. 이건 조직이 좀 잘해야 된다. 이런 얘기를 하고, 그다음에 또 이렇게 서로 어느 게 더 좋으냐, 뭐 이런 얘기가 있어요. 이건 트레이드오프다. 성능과의 트레이드오프다. 플리케이스가 수로 풀이 높겠죠. 예, 되게 많은 걸 처리할 수 있을 거예요. 회원은 둘이 항상 붙어 있어야 하니까 쓰로푸스는 낮을 거예요. 하지만 회원은 레이턴시가 없죠. 내가 뭔가를 행위를 했을 때 옆에서 보고 바로 얘기해 줄 거니까. 그런데 플리케이스는 내가 보내면 아까 같이 오전 30분, 오후 30분 해도 운이 안 좋으면 4시간 이상 걸릴 수 있는 거죠. 그런 차이가 있다.. 그다음에 우리 팀원들이 대부분 내성적이다라고 하면 플리케이스라고 얘기할 거고, 실제로 저도 이제 그랬던 적이 있는데 글로 설명하려니까 너무 힘든 거예요. 아무리 제가 조심을 하고 시간을 들여도 이걸 상대방이 이해하기 쉽지 않겠다. 이런 생각이 든단 말이에요. 그럼 그 사람하고 시간을 잡아요. 시간을 잡아서 같이 내가 피드백을 줄 거를 같이 코드를 보면서 얘기할 수가 있겠죠. 예, 그러면 거의 페어 프로그래밍처럼 될 거거든요.. 그다음에 리뷰할 때는 고수준으로 시작해서 저수준으로 내려가라. 리뷰 라운드에 진짜 쓸데없는 것까지 너무 많이 의견을 남기면 저자가 굉장히 당황할 수 있다. '나 왜 이렇게 많이 지적당하지?' 이렇게 느낄 수도 있다는 거죠. 그래서 한 번 리뷰할 때 20개에서 50개 정도, 20개가 넘는 그런 코멘트는 좀 위험한 시그널이 될 수 있다. 그러니까 초기 라운드는 되게 보스들의 피드백으로 제한하라. 장애, 성능, 보안 이런 굉장히 핵심적인 문제죠. 이런 문제는 절대 일어나면 안 되는 거잖아요. 이 정도만 하고, 그다음에는 리팩토링 정도를 제한하라. 코드의 가독성을 높일 수 있으면 리팩토링 정도를 제한하라. 그런다면 설계 개선이라든가 변수명 가지고, 지금도 괜찮은데 더 좋다고 주석을 어떻게 하고 이런 것들은 모든 게 해결되고 시간이 남은 이런 걸 봐라.. 리뷰할 때 예제 코드를 제공할 수 있다. 저자를 기분 좋게 하기에는 어떤 선물 같은 거다. 그런데 예전에 조심해야 되는 것은 너무 긴 예제를 제공하지 말아라. 너무 긴 예제를 제공하면 억압적으로 보인다. '나는 그 코드를 못 짜서 네가 다 짜주는 거야' 이렇게 느낄 수 있다는 거예요. 그리고 너무 많이 제공해 주지 말아라. 너무 많이 제공해 주면 '내가 다 알려줘야지' 하는구나, 이런 느낌을 줄 수 있다는 거예요. 그렇게 하지 말라는 거예요. 굉장히 자주 보이는 안티 패턴이죠. 플리케이스에 포함되지 않은 라인은 이게 범위가 아니에요. 예, 심지어 그 변경된 라인 바로 위에 오타가 보이더라도 이번 플리케이스의 범위가 아니면 얘기를 안 하는 게 더 좋겠다.
이런 얘기고요. 그런데 그런 건 있어요. 코드 블록을 변경하면, 위에 예를 들어서 메서드 이름이 반드시 같이 변해야 돼. 얘도 같이 변경되어야겠네요.. 태그를 활용하는 방법도 있습니다. 니트피킹이라고 하는데, 이제 뭐 하차는 일로 약자로 미국에서는 니트라고 하나 봐요. 이런 것들은 고치면 좋지만, 아니어도 그만입니다. 뭐 이런 거예요. 근데 그래도 보통 고친다. 그런데 이런 것들을 제공하는 데는 좀 뭐랄까 부담이 없어야 해요. 그래야 리뷰어들이 더 개선할 수 있는 의견을 자유롭게 나눌 수 있습니다. 이런 거는 안 할 수도 있지만, 하면 좋다는 거를 절대 얘기하지 마세요. 그러면 문제가 되는 거 아니면 얘기를 못 하고, 그러면 대화가 되게 적게 나오겠죠. 이런 것들도 이제 태그 같은 걸 활용해서 제공하면, 어떤 교육적인 목적으로 지속적으로 기술을 연마하는 걸 듣는다는 건 새로운 기술을 알려주는 것이 되거나 이럴 때 굉장히 도움이 될 거예요.. 그리고 제가 리뷰할 때 굉장히 중요하게 생각하는 것 중 하나인데, 제가 예전에 크게 실패를 했던 곳이어서 그런가 봐요. 한두 등급만 코드 레벨을 올리는 걸 목표로 하는 렉터 등급이라고 하는데, 그 레터 그레이드가 이제 대학 학점이죠. A, B, C, D가 있다면, 네트워크를 받았어요. 우리 팀에 있는 사람이 다 A+는 아니잖아요. D도 있을 수 있잖아요. 긴 사람의 것을 받았으면 비중도가 되도록 도와야지, 이걸 A+를 대기하겠다고 쥐잡기를 하면 안 된다. 이제 그런 얘기예요. 완전하지 않아도 충분히 좋은 코드가 되도록 하는 거지, 완전하게 모든 사람이 만든 걸 다 완전하게 하는 건 아니라는 거예요.. 우리 팀에 진짜 신입으로, 이제 막 코딩을 시작한 그런 분이 있다면, 그분이 만든 것은 사실 굉장히 잘하는 분이 보기에는 무조건 면이 굉장히 많거든요. 그런데 그 사람이 계속 피드백을 줘서 한 번에 자기 수준으로 올리려고 하는 그런 욕심은 절대 하면 안 됩니다. 그러면 사실은 그냥 싸우는 경우가 더 많죠. F가 있다면, 가끔 기능적으로 완전히 틀렸거나 너무 복잡해서 이게 정말 제대로 된 건지 도저히 리뷰에서 확실히 안 써. 그 정도는 F라는 거예요. 이런 경우에는 승인을 보류할 수 있는 거예요. 여러 차례 리뷰 라운드를 했는데도 코드를 비가 계속 F라면, 이건 배포하면 정말 잔인할 수도 있을 것 같아요. 도저히 난 이해 못 하겠어.. 아, 이거 생각나네요. 니트피킹에 관한 어떤 리뷰 코멘터리를 달았어요. 그분은 예를 들어서 D등급이었는데, 제가 한 A 정도 되는 그런 것에 대해서 아, 이런 것도 있으니까 다음에 한번 보세요라고 의견을 달았단 말이에요. 그런데 그분이 그 책을 주문하시더라고요. 그와 관련된 책을 주문하셔서 업무 시간에 제가 보고 있는 분이 계시더라고요. 그거는 잘못된 것 같아요. 그분은 그런 게 있으면 제가 나중에 할게요라고 하고, 나는 지금 기준금이니까 좋았던 것 같아요.. 예, 그다음에 피드백을 하는 방법에 대해 말씀드리자면, 너라는 말을 하지 말아라. 우리 잘하는, 제가 잘했던 건데 너는 왜 맨날 같은 말처럼 되게 잘했던 것 같거든요. 이런 말 하지 말아라. 건설적인 피드백을 해라. 진정한 칭찬을 해라. 명령이 아니라 요청을 해라. 그냥 내 개인적인 생각인데 잘 모르겠지만 이런 게 좋아요. 그게 아니라 원칙에 기반해서 반복적인 게 보이면 다 말하지 말고 몇 개만 얘기하고 말아라. 그런 얘기죠. 절대 너라고 하지 말아라. 너는 왜 맨날 이 말을 저도 많이 썼던 것 같은데, 이 말을 듣는 사람은 되게 기분 나쁠 것 같고, 저도 이 말 듣는 건 너무 싫은 것 같아요..
리뷰하는 것의 핵심은 무엇이 코드를 낮게 좋아지게 만드는가, 누가 이렇게 잘못했는가를 파악하는 게 아니에요. 더 좋아지게 하는 거예요. 집중하는 게 훨씬 더 중요한 거예요. 나는 뭐 제가 최고이고요, 제가 입사한 지 얼마 안 돼서요. 그런 얘기 필요 없는 거예요. 지금 여기서 뭐가 어떤 게 더 나아지는 건가요? 그거에 집중하는 것이 좋다는 거예요. 예를 들어, 이 단어를 이렇게 바꿔라고 하는 게 훨씬 더 받아내는 사람이 편하다는 거예요.. 그리고 이제 아이 메시지라는 게 있어요. 너의 이런 행동이 이렇게 결과를 만들어서 내가 기분이 어때 뭐 이런 식으로 표현하는 거거든요. 그러면 내가 기분이 나쁜 거지 너 때문에. 아빠가 이런 얘기가 안 나온다는 거예요. 그러니까 이런 식의 커뮤니케이션 방법도 필요한 거예요. 그런데 그냥 보통은 원하는 게 어떨까요? 이거는 이렇게 고치는 게 어떨까요?라고 물어보는 게 굉장히 좋은 커뮤니케이션 방법인 것 같아요.. 동료 간의 코드 리뷰는 경쟁을 유발하는 게 아니에요. 누가 더 잘하나 그걸 보려고 하는 게 아니에요. 우리 팀의 생산성을 높이는 거예요. 비판이 아니라 학습의 과정으로 인지해서 프로젝트의 성공에 기여할 수 있게 건설적인 피드백을 하면 배우고 역량을 증대하도록 동기부여할 수 있습니다. 그리고 내가 피드백을 하는데 도저히 이 건설적으로 받아들이게 피드백 말을 못 찾겠어. 그런데 이건 정말로 그렇게 크리틱하는 건 아니야. 그러면 차라리 아무 말도 안 합니다. 어설프게 말해 가지고 그 사람 기분 나쁘게 해 가지고 서로 네가 잘하는, 내가 잘하네 그런 분위기로 가느니 약간 부족하지.. 만이 정도면 됐어. 그것도 넘어가는 것도 조만간 진정으로 칭찬하라는 거예요. 보통 우리는 잘못된 부분에 집중을 많이 해요. 칭찬하면 긍정적인 행위를 강화할 수 있는 어떤 리뷰가 그런 좋은 기회를 제공하기도 하기 때문에 칭찬에 인색하지 말아야 합니다. 예를 들어서 이런 API가 있었어요. 정말 저는 몰랐는데 너무 유용하네요. 이런 얘기를 써주면 기분이 좋아질 거예요. 특히 그 저자가 신규 입사자라면, 되게 따뜻하구나 이렇게 받아들일 수 있다는 거예요. 이런 진심 어린 칭찬은 리뷰어가 감시자가 아니라 나를 도와주려는 친구라는 것을 알게 해 줘서 긴장감을 낮추는 데 큰 도움이 됩니다.. 그리고 이제 피드백은 명령이 아니라 요청을 해야 합니다. 우리는 일상에서 동료한테 명령하지 않아요.
2.6. 리뷰 과정에서 발생하는 질문은 팀원 간의 이해도를 높이고 서로의 기술적 성장에 기여함.
예를 들면, 명령은 '12번 테이블 자리가 비어 있습니다. 우리 가족은 저리로 걸어가서 앉을 것입니다.' 이렇게 얘기하는 거예요. 되게 구체적이죠. 요청은 '우리 네 명이 앉을 자리를 만들어 주세요. 12번 테이블이 됐든 뭐가 됐든, 그건 당신이 알아서 하세요.' 이렇게 얘기하는 거란 말이에요. 마치 명령형 프로그래밍 스타일과 선호되는 방식으로 얘기하면 되지, 어떻게 해 달라는 것은 그 사람이 알아서 하게 하라는 거예요.. 리뷰할 때 이런 강압적인 명령형 커넥트가 많이 보인다고 해요. '이 클래스를 별도의 파일로 분리해라.' 이렇게 구체적으로 얘기하지 말라는 거예요. '분리할 수 있지 않을까요?' 이것도 그래요. 더 좋은 것은 '이게 너무 커져서 나는 걱정이 되는데 괜찮을까요?'라고 하면 그 사람이 '아, 분리해야겠네요.'라고 대답할 수 있을 거예요. 그 사람이 '분리해야겠네요.'라고 한다면 분리하는 데 아무런 문제가 없는데, 내가 '분리해라.'라고 얘기해 놓으면 그 사람이 '나도 알아.' 그러면서 기분이 나빠할 수 있는 거예요.. 이것도 이제 그런 예를 하나 보여주고 있는 거고요. '이렇게 이렇게 하는 게 어떨까요?' 아, 그게 더 좋은 거예요. 의견을 그냥 내 생각은 그런데, 뭐 근거는 없지만 이렇게 하는 게 좋아요. 그렇게 하지 말고 원칙을 얘기하는 거예요. 예를 들어, '제안하는 변경이 있으면 변경의 이유를 원칙에 기반해서 설명해 주세요.' '이 클래스를 두 개의 파일로 분리해야 해요.'라고 하지 말고, '이건 파일 다운로드와 파싱 두 가지 책임을 하고 있으니 SRP(Single Responsibility Principle)를 준수하기 위해서 두 개의 클래스로 분리하는 게 어떨까요?'라고 얘기한다면, 굉장히 받아들이기 좋겠죠.. 소프트웨어는 항상 이렇게 논리적으로 설명할 수 있는 것만 있는 건 아니다. 논리적으로 설명하지 못하는 경우가 있다. 그냥 직관적이지 않을 수 있다. 그냥 보기 싫을 때도 있다. 그럴 때에도 무엇을 할 수 있을지 이제 객관적으로 설명을 해라라는 거예요. '이 코드는 되게 혼란스럽네요.' 뭐 그런 거보다 '나는 이 코드가 이해하기 어렵네요.'라고 얘기를 해 주면 저자가 좀 더 받아들이기가 수월해진다 하는 거예요.. 반복적인 패턴이 있어요. 예를 들어서 '스트링 유틸스의 뭐 이렇게 조사를 하더라.' 그런데 그게 한 10군데 나왔어요. 그러면 한 두세 개 정도에서는 얘기를 하고 나머지 한 일곱 개 정도는 내비 두는 거예요. 저자는 이제 한 두세 군데서 '아, 나머지도 그런 게 있는데.'라고 그 저자가 고치면 훌륭한 거고요. 일곱 개 안 고치면 '에이, 그럴 수도 있지.' 하고 넘어가면 돼요. 그거 열 개 다 알려주면 미주알고지알을 너무 많이 간섭하는 것 같아서 저자한테 굉장히 안 좋게 작용한다는 거예요.. 도착 상태, 그런 경우에 어떻게 대응하는지 그 얘기를 좀 드릴게요. 그리고 너무 많은 코멘트에서 방어적으로 저자가 '그걸 내가 몰라서 그런 게 아니라.' 일에 대해서는 이런 식으로 이제 변명이 들어가는 거죠. 이러다 보면 도착 상태에 빠지는 거예요. 교착 상태로, 뭐냐면 커멘트를 반영하지 않았으니까 내 의견을 반영하지 않았으니까 나는 어프로브 안 할래. 그러는 거고 저자는 '나는 네가 말하라고, 난 다 할 필요 없다.' 생각해요. '그 몇 개 쓰면 됐지, 그거 가지고 왜 나한테 그래?'라고 하면서 이제 커멘트 반영을 거부하는 게 서로 교착에 빠지는 거죠.. 이럴 때는 만나서 얘기해라. 화상 또는 만나서 얘기해라. 특히 복잡한 일이구나. 텍스트 기반의 의사소통은 내가 타이핑하고 있는 이 스크린 뒤에 사람이 있다는 걸 종종 잊게 한다. 뒤에 기계가 있는 것처럼 내가 말을 되게 가혹하게 할 때가 있다. 그러니 만나서 얘기해라. 그런 얘기고요. 벡터에도 큰 문제는 없을 것 같아라고 인정할 수도 있는 거예요. 아니면 '아, 난 도저히 나는 수긍 못 하겠으니까 우리 팀장님한테 에스컬레이트해야 될 것 같아.' 그냥 둘이 죽자고 계속 싸우잖아요. 관계가 나빠져서 둘 중에 하나 퇴사하는 그런 일까지 생겨요. 그러지 말고 그냥 승인하는 비용, 좀 불만족스럽지만 이 비용 때문에 속 제품이라는 잠깐 낮아질 수 있어요. 하지만 그 동료와 계속해서 일하면서 품질을 높일 수 있는 기회가 남아. 푹 자고 싸우면 같이 일해야 되지 않게 돼서 이제는 고수준의 품질을 얻을 수 있습니다.. ‘는 게 아니라 아예 없어지는 거예요. 그래서 좀 얘기하는데 저항이 너무 크다. 근데 크리티컬한 게 아니다. 그럼 넘어가는 것도 조망입니다. 인정이 절대로 불가능해요. 그러면 리더한테 에스컬레이션을 해야겠죠. 아니면 다른 사람한테 리그 해 달라고 해도 돼요. 뭐 상담하고 휴식하고, 가급적이 뭐 정 안 되면 당분간은 서로 피하려 하지 말고 갈등 해결책, 소프트 스킬이겠죠. 이런 것도 학습하는 게 필요하다. 설계 리뷰 때 했어야 되는 건데, 지금 내가 그걸 코드 리뷰 때 하면서 서로 싸우는 게 아닌가 그런 걸 고민해 달라는 거예요. 설계 리뷰 때문에 했어야 되는 그런 얘기라면 코드 리뷰 때는 다음 번에 할 수밖에 없으니, 이건 너무 가야 된다는데, 아까 말한 것처럼 아저씨가 한 게 아니면 좋은 관계로 동료와 어떤 기회를 계속 유지하는 게 훨씬 더 현명한 일이다. 이거는 제가 본 그 어떤 블로그에 있는 내용이었는데요. 저도 비슷하게 해 본 적이 있어서 이 내용이 굉장히 인상적이어서 추가 사례로 넣었는데, 어떤 거였냐면요. 팀에 굉장히 잘하는 분이 필리캐슬 올린 사람을 부르는 거예요. 그러면서 어떻게 계산하면 좋은지 다 보여주는 거예요. 한 20분 정도 보여줬어요. 그런 다음에 리버트를 해버려요.
그런 다음에 그 PR을 작성한 사람한테 ‘네가 네 자리에 가서 한번 해 봐’라고 하는 거예요. 20분 짝 프로그램이 했던 거를 이 사람은 2시간 정도를 해야 될 수도 있어요. 하지만 이 두 시간을 통해서 그 사람은 이제 수술하는 법을 배우게 되는 거예요. 결정은 저자가 하는 거예요. 완벽한 설계를 추구하는 게 아니라 우리가 할 수 있는 최고의 설계를 추구하는 거란 말이야. 네트워크 레이드에서 얘기했던 것처럼. 그래서 팀 정신, 우리가 팀워크를 유지하고 심하게 안 깨지고, 우리 둘이 같은 팀에서 계속 일할 수 있다면 약간 불안전한 해결책에도 받아들이는 게 좋겠다는 거예요. 왜냐하면 우리가 발견한 모든 설계 기간이 항상 실제로 그렇게 문제가 되지는 않을 수도 있다는 거예요. 뭐 자기가 나고 뭐 이런 거만 모르겠지만, 아 이것 때문에 느려지지 않아요. 근데 그런 게 항상 일어나는지 측정 안 했으면 그렇지 않을 수도 있다는 거예요. 결정을 저장하는 거다. 그 다음에 코드를 위해 목적이 비난이 아니라 병이라는 거, 굉장히 여러 번 얘기했고요. 리뷰도 배운다. 1시간 정도를 제가 설명을 드렸는데, 잠깐 쉬시고 하는 게 어떨까 하는데, 코드 리뷰 문화 정착하는 데 뭐 어떻게 해야 잘 되냐 이런 얘기 많이 나왔거든요. 근데 이제 오프라인 코드 리뷰를 처음에 시작하면, 약간 제가 했던 것처럼, 약간 요거를 나무라고 나무라는 분이 그런 분위기로 갈 수가 있거든요. 처음엔 좀 힘드셔도 온라인으로 진행하시면서 토론 위주로 하시다가 필요한 경우에 오프라인으로 성능, 그런 방법으로 하시면 좋을 것 같고요. 누차 말씀드리지만 저자의 노력이 중요해요. 한 명이 고생해서 여러 명의 시간을 절약해 줘야 돼요. 그래야 정착이 돼요. 그다음에 리더의 관심과 의지가 굉장히 또 필요하다고 생각해요. 사전 질문 중에 저희 기술 개발 리더가 코드 리뷰에 대해서 의지가 없는데 어떻게 하면 그분을 설득할 수 있을까요? 이런 게 있었거든요. 저는 그분을 설득해야 되는 이유가 있어야 되나라는 생각이 들어요. 그분이 하자고 해야 되는 게 맞지 않나 이런 생각이 들어서, 저는 리더분들이 관심과 의지가 있어야 좀 더 안착되는데 도움이 된다고 생각이 되고요. 코드 리뷰의 코드 비난에 대해서 두려움을 받지 말아야 한다. 이건 내 코드에 대한 거야. 뭐 내가 그 코드를 작성할 때 잠깐 정신 나갔었나 보지, 이럴 수도 있는 거잖아요. 너무 거기에 민감하지 말아라. 근데 누가 뭔가를 하게 만드는 제일 좋은 거고, 저는 멋져 보여야 된다고 생각해요. 이게 뭐가 됐든 하고 싶어져야 돼요. 제가 뭔가를 남들이 하기를 원하는 거를 보여준다면, 그게 뭐가 됐든 너무 멋져 보여서 나도 하고 싶다 이런 생각이 그 사람들한테 들어야 그게 정착이 된다고 생각해요. 그러니까 처음에는 그런 걸 하기에 제일 좀 하고, 이렇게 풀 아이디나 하키, 인텔리제에서 뭐 이런 기능을 이용해서 이렇게 리플링 할 수 있어요. 뭐 이런 걸 보여주면 코드를 교환할 때 저자가 ‘아, 그런 게 따라 하고 싶다’고 생각할 수 있단 말이야. 그러다 보면 조금 지루한 얘기죠. 그다음에 이거는 그 유튜브에, 그 아까 소프트웨어 장인 그 책슨 센드로망스 쏘가 한 얘기 중에 제가 인상적에서 좀 저장해 놓은 건데요. 정리해 놓은 건데, 새로운 어떤 거를 수용하게 침을, 그 영감을 부여, 어떻게 영감을 구해야 하냐. 그러니까 뭐 장윤정 시인 TV 이런 걸 하게 어떻게 할 거냐라고 물어봤어요. 이런 일을 하는 사람이거든요. 그랬더니 그 사람이 한 얘기가 ‘좌절할 준비를 해라. 당신이 원한다고 남에게 영감을 불어낼 방법은 없다. 당신은 당신 자신의 태도만 제어 가능하다. 타인이 나의 태도에 대해서 어떻게 반응할지 그건 제가 불가능하다.’ 그러면서 영감은 부산물이다. 내가 어떻게 하면 모험이 될 수 있을까, 특정 행위가 필요하다는 거예요.. 동이나 특정 기술을 채택하도록 하려면 내가 모범이 되어야 해. 내가 어떻게 하면 보험이 되어 저 사람들이 따라 하고 싶어 할까, 이런 걸 고민해라. 네가 너희 팀에 어떤 기술이 적용되길 바란다면 그 기술을 네가 맡아야 한다. 그래서 네가 꼭 모범이 되어야 한다. 이런 얘기도 해요. 지각하지 말고 업무에 기여해라.
긍정적으로 임해라. 사람들한테 잘해라. 그리고 기술적인 훈련에 대해서 얘기할 땐 아주 고대로 해라. 굉장히 많이 연습을 해서 남들이 따라할 마음이 생기게 만들어야 한다. 키보드로 코딩을 할 때는 사람들이 정확하도록 만들어야 한다. 이렇게 엄청난 모습을 보여주면 아마도 몇몇 사람들에게는 영감을 줄 수도 있을 것이다. 그렇게 어려운 거야, 새로운 것을 제거하는 게. 그러니까 이런 걸 적용하고 싶은 마음이 드는 사람이라면 내가 그렇게 남한테 잘해. 이거는 저도 되게 공감되는 게, 개발자 컨퍼런스 같은 데서 강연을 하면요, 되게 좋은 얘기를 했는데 반응이 쌓일 때가 있고, 되게 가벼운 얘기를 했는데 반응이 굉장히 좋을 때가 있어요. 그게 언제였냐면, 저 같은 경우는 레거시 코드 개설하는 것과 관련해서 예전에 이클립스를 이용해서 뭘 하는 걸 보여줬어요. 그런데 사람들이 너무너무 관심이 있다는 거야. 그래서 '와, 사람들이 내가 말하는 걸 잘 알아들었나 보다' 하고 너무 좋아했는데, 끝나고 저한테 뭘 물어보면 '아까 그 하키가 뭐예요?' 그걸 물어보는 거예요. 그러니까 이 사람들은 이클립스에 하키를 모르는 상태에서 나오거나 그걸 궁금해하는 거야. 처음에는 저는 약간 좌절했어요. '야, 내가 말한 건 그게 아니고 훨씬 중요한 얘기가 있는데' 이렇게 생각했는데, 저한테 그 하키를 물어본 사람들은 나중에 그걸 공부하고 거기에 대해서 굉장히 많은 숙련을 쌓으라고요. 뭔가 멋진 걸로 그 사람들이 참여할 수 있게 만들어주는 것이 좋은 시작입니다. 이런 거고요. 그리고 이거는 이제 고통의 계곡이라는 그래프예요. 뭔가 새로운 투자를 하잖아요. 그러면 초반에 이렇게 쑥 꺼져요. 생산성이 여기서 나오면 기하급수적으로 올라간단 말이야. 우리가 새로운 투자를 하잖아요. 바로 효과가 나타나지 않아요. 그 효과가 나타나기 위해서는 그 효과가 나타날 거를 믿고 꾸준한 투자가 필요해요. 코드 리뷰라면 뭐가 좋아지는데, 당장 해봤더니 '뭐, F 하는데 리뷰하느라 시간만 더 내고 좋아지는 거 하나도 없는데'라고 하면서 이제 우리 코드 리뷰를 하지 말자고 하면 끝난 거고, '아, 이거는 정말 좋아질 것 같아. 우리가 지금 익숙하지 않으니까 조금 시간이 걸릴 거야.' 그런데 우리는 지금 이 영역에 있는 몇 가지가 있으면 그 사람들은 나아질 수 있고, 코드 리뷰를 하다 보면 예상하지 못한 버그를 다른 팀에서 찾아주기도 해요. 그리고 또 좀 시간이 지나면 맨날 지적질만 하는 게 아니라 '선물도 달려요. 코드가 깔끔하네요. 이렇게 구하는 방법도 있네요.' 이런 얘기가 된다는 거예요. 그리고 이런 얘기들을 진짜로 해요. 많은 사람들이 본다는 생각에 좀 더 코드를 다듬게 되더라. 그리고 그러면서 코드를 비해서 저희 신용가에서는 그런 얘기를 했던 거, 실내 같은 걸 활용해 가지고 '아, 이건 설계에서 아키텍처에서 클린 코드에서 리팩토링에서 어떤 거에 해당되는지' 되게 좋은 예시 이런 걸 가지고 공유를 하면 개발 조직 내에서 공감대나 열정이 생기는데 굉장히 큰 도움이 돼요. 아까 말씀드린 대로 한 팀 자료라는 사람을 보면 자기도 잘하고 지금 열정이 생기는 사람들이 꽤 많아요. 몇 가지가 이제 코드 리뷰와 관련해서 많이 나왔던 얘기들이고요. 그다음에 코드 리뷰만 열심히 하면 다 잘하나? 그건 아니잖아요. 다른 기술들이 또 필요하거든요. 그런데 저는 그 중에 제일 중요한 건 리팩토링인 것 같아요. 결함을 찾고 성능 문제가 없게 하는 것도 되게 중요하지만, 코드의 품질을 높여서 향후에 변경 비용을 낮추는 게 중요하니까 품질을 높이는 것이죠. 그게 이제 리팩토링이잖아요. 리팩토링 정의는 결과의 변경 없이 코드의 구조를 재조정하는 거예요. 주로 가독성을 높이고 유지보수를 편하게 하기 위해서 버그를 없애거나 새로운 기능을 추가하는 행위는 아니에요. 그리고 요즘 이 책이 자바스크립트 버전으로 나왔는데, 저는 그 책은 앞부분만 조금 보고 아직 다 못 봤고요. 이건 되게 오래된 책인데 자바로 나온 오래된 책이에요. 예제도 비디오 테이프 빌려주는 거니까 지금하고는 안 맞지만, 굉장히 좋은 기법들이 많이 나와 있는 그런 책이라고 생각했고요. 처음에 이 책에서 굉장히 절차적으로 짜여 있는 프로그램을 리팩토링해서 객체지향적으로 알아보기 쉽게 바꿔요. 리팩토링 효과가 어떻다는 걸 보여주고, 그다음에 다양한 리팩토링 기법들을 설명하는 내용을 안 보셨다면 꼭 보시는 걸 추천드리고요. 그리고 TDD와 결합했을 때 리팩토링은 굉장히 강력한 기능을 가지고 있다고 생각해요. 저는 결합해서 갔을 때 리팩토링은 앞에서 리팩토링에 대한 마틴 파울러의 리팩토링 장이나 결과 변경 없이 코드를 재조정하는 것에 대해 이야기하고 있습니다..
‘드의 구조를 제정 활성화하는 거다’라고 했는데, 저는 PD랑 결합해 보면 돌아가는 코드를 가지고 설계를 하는 행위가 리팩토링이라고 생각해요. 그러니까 처음에 TDD로 하면 일단 페일링 테스트를 넣고, 그다음에는 그 테스트가 동작하도록 가장 빠르게 지저분하게 돌아가는 코드를 만드는 거잖아요. 그런 다음에 리팩토링 과정을 거쳐서 정말로 이해가 쉽고 유지보수가 편하며 가독성이 높아지는 방향으로 개선하는 일이죠. 그래서 아무것도 없는 상태에서 화이트보드나 종이에 분석 설계를 하는 것보다 돌아가는 코드를 가지고 계속해서 테스트를 통해 확인해 보면서 설계를 개선하는 행위는 굉장히 피드백 주기가 짧아서 즐겁게 할 수 있는 재밌는 일인 것 같아요. 그리고 리팩토링에 나오는 많은 기법들이 코드 리뷰에서 많이 언급되고요, 매일매일 할 수 있는 리팩토링이 가장 중요하다고 생각해요. 익스트랙티브 같은 기법을 많이 사용해서 메소드가 전이될 수 있게 하는 것도 중요합니다. 이 부분은 잘 모르시는 분들은 찾아보셔야 할 것 같고요. 그다음에 의존성을 낮추고 결합도를 낮추는 것은 굉장히 어려울 수 있어요. 결합도를 낮추기 위해 드려야 하는 비용과 결합도가 낮아져서 얻을 수 있는 효용을 비교했을 때, 어느 쪽이 더 높다고 할 수 없을 정도로 결합도를 낮추는 것은 어렵거든요. 하지만 응집도를 높이는 것은 상대적으로 굉장히 쉽다고 합니다. 그래서 관련된 것들을 밸류 오브젝트로 빼고, 이들과 관련된 기능들을 다시 모으면서 개선을 계속 이어 나갈 수 있을 것 같아요.. 그리고 리팩토링 외에도 우리가 주로 참고하는 책이 있는데, 굉장히 오래된 책이지만 여전히 가장 좋은 책이라고 생각해요. 이 책에는 의존성을 관리하는 방법이 나와요. 서브 클래스에 오버라이드 메서드가 가장 많이 언급되는 방법인데, 만약 현재의 테스트가 레거시 코드여서 테스트를 만들 수 없다면 어떻게 하면 테스트를 만들 수 있을까요? 그리고 이 코드가 어떻게 동작하는지 모르겠을 때, 테스트를 만들어서 어떤 동작을 하는지 알 수 있는 방법과 레거시 코드에 새로운 코드를 빠르게 추가할 수 있는 방법들에 대해서도 다루고 있어요. 그래서 레거시 코드를 분석하는 방법들도 언급되고 있어요. 이 책은 굉장히 좋은 내용을 다루고 있으며, 많이 활용할 수 있는 내용들을 포함하고 있다고 생각합니다.. 또한, ‘테스트 퍼스트로 개발하려고’라는 책도 있는데, 이 책은 한글판이 있습니다. 이 책에서는 테스트를 어떻게 만들어야 나중에 리팩토링을 하더라도 테스트가 잘 깨지지 않는지, 또는 시간이 지나도 테스트를 돌렸을 때 버그가 발견될 수 있도록 해야 하는지에 대한 내용이 나와 있습니다. 이 두 책 모두 한글판이 있으며, 다른 책에 비해 내용이 좋다고 생각해요. 그래서 한번 보시면 좋을 것 같습니다.. 그다음에 웹사이트는 클린코드스닷컴인데, 로버트 C. 마틴이 운영하는 동영상 사이트입니다. 거기서도 유용한 자료를 찾을 수 있을 것 같고요. 마지막으로, 제가 로버트 C. 마틴의 허락을 받아서 옛날에 그가 강연한 내용을 약간 각색해서 유튜브에 올려놓은 것이 있습니다. 이 부분도 한번 보시면 도움이 되실 것 같습니다.. 그리고 사전 질문에 대한 답변을 드리자면, 오늘 강연에서 다룬 내용이 답이 되시는 것들도 꽤 있었고, 너무 광범위한 질문들이 많았습니다. 제 생각에 이제 막 시작하는데 마치 모든 것을 질문하라고 해서 완벽하게 시작하고 싶어하는 그런 느낌이 들었어요. 너무 잘하고 싶으신 거죠. 하지만 이렇게 생각하셔야 할 것 같아요. 지금까지 못한 걸 한 번에 잘할 수 있을까요? 그렇게 말고 일단 시작하고, 그다음에 피드백을 받는 것이 중요합니다. 해 보니까 되더라, 안 되더라 하면, 안 되면 또 방법을 찾아야 하고, 그 방법을 내 몸에 익혀서 발전시켜 나가는 것이 필요합니다. 한 번에 모든 것을 다 해버리고 내일부터는 남은 다른 것을 해야지 하는 마음가짐은 적절하지 않은 것 같습니다.. 또한, 질문 중에 자신의 상태를 확인하고 싶다는 말이 많았는데, 이를 위해서는 피드백을 받아보는 것이 가장 좋은 방법일 것 같습니다. 누군가에게 찾아가서 그 사람에게 봐 달라고 요청하는 방법도 좋고, 요즘은 온라인으로 함께 볼 수 있는 방법도 많습니다. 그리고 너무 기법이나 절차에 의지하려고 하는 경향이 있는 것 같습니다. 그 기법만.... 지키고 절차만 지킨다고 해서 되는 것은 아니고요. 그런 것들을 잘 이해하신 다음에 본인에게 맞게 변형을 하셔야 하는 거지, 딱 그대로 하는 것은 아닌 것 같아요. 그래서 온오프라인을 적절하게 섞어야 하는 것이 분명히 필요하다고 생각합니다. 제가 플레이 처음 갔을 때 코드 리뷰를 하다가 그 글로 설명하기 힘들어서 불러서 같이 했는데, 사람들이 쭉 둘러서 구경을 하더라고요. 저는 그게 되게 낯선 경험이었는데, 뭐 그럴 수 있는 거예요. 그러니까 어떤 절차에 너무 의존하지 말라는 것이죠. 툴에 대해 물어보시는 분들이 많은데, 비법 같은 것을 많이 써봤어요. 그리고 아틀란티아는 없었으면 좋겠다고 했는데, 이건 안 써봤고요. 토요일보다 코드 리뷰는 일단 사람 눈에 잘 읽히는 코드인지 그게 더 중요하죠. 툴이 잘 작동하는 코드가 아니라, 누가 내가 작성했는데 내 눈에 잘 들어오고 내 옆에 동료가 더 잘 읽을 수 있는 코드인지 그런 게 더 중요한 거니까요. 기법이나 절차보다는 본질에 좀 더 충실했으면 좋겠다는 생각이 들었습니다..
그다음에 한 일정이 있고 우선순위가 있고, 우리는 너무 바쁘기 때문에 못하는 게 많아요. 이런 데서 우리 코드 리뷰에 대한 이야기가 굉장히 많았어요. 누구나 다 그런 질문을 하실 수 있을 거라고 생각하고요. 그럴 때 저는 이런 얘기를 많이 하는데, 우리는 매번 정해진 시간 내에서 시험을 치러서 성적을 받는 것 같아요. 고등학교 때 수학 시험을 보면 1시간짜리 시험을 한 시간 안에 보는 게 내 점수잖아요. 1시간 안에 봤는데 70점이야. 그런데 난 2시간 보면 100점을 맞을 수 있을 것 같아. 그렇다고 해서 내가 점수가 100점이 되는 건 아니잖아요. 정해진 시간 내에서 할 수 있는 게 우리 실력이라고 생각해요. 우리 일정, 우리 우선순위 이런 게 있죠. 물론 그중에는 우리가 예당 사자들이나 회사와 얘기해서 좀 뺄 수 있는 것들도 있을 거예요. 그런 걸 빼는 것도 실력이고요. 그렇게 해서 남은 시간 내에서 우리가 받을 수 있는 게 우리 실력인 것 같아요.. 그리고 그렇게 시간이 부족하고 또 시간이 많이 되는 게 코드 리뷰니까, 시간을 아끼려면 저자의 능력이 정말로 중요합니다. 그리고 주기에 대해서도 많이 물어보셨어요. 얼마만에 한 번씩 하면 좋겠냐, 코드 리뷰는 몇 시간이나 투입했으면 좋겠냐 이런 게 있는데, 짧게 자주 하는 게 좋습니다. 그럴려면 당연히 작게, 효과는 피드백 효과는 농구의 자유투를 예로 들어보세요. 코치가 자유투 열 개를 쏘라고 한 다음에, 열 개 다 쏜 다음에 첫 번째 건 이래갖고 두 번째 건 이렇게 피드백을 주는 것은 그렇게 피드백을 주기 힘들겠지만, 그렇게 주는 것은 효과가 좀 낮은 것 같아요. 그보다는 매번 던질 때마다 하나 던졌을 때 이번에 좋았어, 이번에 약간 스냅이 안 먹었어 이런 식으로 얘기해 주는 게 훨씬 효과적이잖아요. 처음 하는 거고 어려워하는 거라면 더 짧고 자주 하는 게 효과적입니다. 아까 나왔던 괴로운 일이면 더 자주 해라 이런 얘기도 많았어요.. 비전공자한테 초본데, 이게 맞는지 회의가 된다 이런 얘기도 많이 있었거든요. 그런데 이거는 비전공자용 처벌인 거는 아깝지만, 이건 나의 현실이에요. 이걸 어떻게 할 수 없어요. 그러니까 이런 걸 얘기한다고 달라지는 건 없는 것 같아요. 이런 걸 생각하는 시간에 노력을 건설적인 투자하는 게 더 좋아 보입니다. 제가 아주 뭐 같게 이런 의견을 주신 분만의 현실을 동등하게 경험한 게 아니라, 좀 건방지게 느껴질 수 있겠지만, 제가 힘든 걸 예를 들어서 어떤 분한테 얘기했을 때 그분은 그거에 별로 그렇게 관심이 없었던 것 같거든요. 제가 어떻게 하면 이걸 더 잘할 수 있을 것 같다라고 말을 했을 때 더 관심이 많았던 것 같아요. 얘기보다는 어떻게 하면 더 잘할 수 있을 것 같은데 괜찮나요? 그런 질문이 더 좋은 것 같아요. 어떻게 하면 잘할지 고민하는 게 좋을 것 같습니다.. 하루에 4시간씩 주 5일 하면 1만 시간은 10년이에요. 10년 그 정도 돼야 마스터가 된다는 말이에요. 그런데 내가 조금 해보니까 2, 3개월 해봤고 또 한 1년 해봤는데 잘 안 돼서 난 내 길이 아닌 것 같아. 이건 좀 더 노력을 하는 게 맞지 않나 이런 생각이 듭니다. 그다음에 저만의 코드 리뷰 노하우를 물어본 분들이 있었는데, 이거는 역할에 따라서 코드 리뷰할 때 좀 다른 것 같아요. 동료들이라면 결함이 있는지 없는지가 아마 제일 중요할 거예요. 그다음에 자기가 보고 이해할 수 있는지, 팀장이라면 다른 팀에서 일어난 버그나 이런 것들이 여기서 또 발견되는지 이런 것도 볼 수 있을 거고, 본부장쯤 되면 아마 버그나 장애보다는 구성원들의 동기부여 같은 걸 좀 더 많이 신경 쓸 거거든요. 그런 거에 따라서 좀 다를 것 같습니다.. 로컬로 저는 풀밭의 풀을 받아서, 인텔리지 같은 데서 열어보면서 이해한 다음에 제안을 하는 그런 과정이 필요하다고 생각해요. 아무것도 아닌 것 같지만, 그것도 노하우라고 할 수 있습니다. 주니어들만 있는 상황에서 코드 리뷰가 진행이 필요한가에 대한 질문이 있었는데, 신기능보다는 특정 방법론에 대한 명심으로 엔지니어링에 빠진 오버엔지니어링이 발생할 가능성이 높지 않나 하는 의문도 있었습니다. 그런데 이 부분은 이미 알고 계신 것 같아요. 이렇게 맹신해서 빨리 가능성이 있다고 하면, 알고 있는 거니까 조심하면 될 것 같습니다. 그리고 주니어라고 해도 실력이 모두 동일하지는 않을 것 같아요. 동일하다고 하더라도 코드를 보고 그날그날 보이는 정도가 다를 것이고, 제안하는 것도 다 다를 것이라고 생각합니다. 그래서 완전히 동일한 수준에 있는 사람들끼리만 있더라도, 저는 리뷰하는 것이 훨씬 더 유리할 것이라고 생각합니다.. 11번가는 코드를 리뷰를 어떻게 진행하고 있는가 하면, 주로 온라인으로 진행하고요. 그다음에 온라인으로 진행했던 것 중에 가끔 세미나 형식으로 사례 공유를 할 때가 있습니다.
좋은 사례가 있으면 공유하고, 폴리캐스트는 다른 팀의 코드도 볼 수 있습니다. 그리고 볼 때는 매우 자세하게 봅니다. 그래서 누군가 항상 자세하게 보는 사람이 있다는 신호를 주어서, 정성을 들여서 풀 캐슬을 작성하고 배울 수 있도록 노력했습니다.. 아, 그리고 아까 개발 생산성과 품질에 대해 이야기했을 때, 개발 품질을 높이는 코드 리뷰는 생산성이나 속도 측면에서는 바이러스가 아닐까 하는 얘기가 있었는데요. 도구 수정 비용은 수정 비용이죠. 분석, 설계, 개발, 로컬 테스트, 그다음에 통합 테스트를 거쳐 배포된 뒤에 고치려면 굉장히 큰 비용이 발생합니다. 그래서 품질이 좋으면 라이프 사이클 후반으로 갈수록 점점 더 비용이 절감됩니다. 개발 단위에서 로컬 테스트를 할 때, 통합 테스트를 할 때 코드 리뷰를 통해 품질을 높인다면, 스테이지나 100% 갔을 때 비용을 절감할 수 있다고 생각합니다.. 그리고 TDD, 테스트, 리팩토링, 코드 리뷰는 생산성을 증대시키는 수단이 될 수 있습니다. 이번 배포뿐만 아니라 이후에도 높은 품질을 유지할 때, 소프트웨어는 향후 추가 비용이 발생하는 변경이나 새로운 기능 추가를 더 빠르게 할 수 있기 때문에, 전반적으로 품질이 좋으면 생산성에도 긍정적인 영향을 미친다고 생각합니다.. 아, 그리고 코드 리뷰를 최대한 안 하고 한 번에 작성하는 방법이 있나요? 라고 물어보시는 분이 있는데, 그분은 나중에 찾으시면 저한테도 좀 알려주시고요. 그다음에 캔트 백을 챙길 때에 대한 이야기를 했습니다. 베어링 테스트를 만들고, 더럽게라도 빨리 만든 다음에 리팩토링으로 깨끗하게 만드는 것이죠. 그런데 더럽게 만드는 사람과 리팩토링으로 깨끗하게 만드는 사람은 같은 사람이잖아요. 그걸 왜 그렇게 하냐고 물으니까, 한 번에 두 가지를 같이 하기 힘들대요. 빨리 돌아가게 하는 것과 잘 만드는 것은 배타적이기 때문입니다. 그래서 한 번에 예쁘고 깔끔하고 빠르게 만드는 것은 어렵고, 일단 돌아가게 만든 다음에 테스트 커버리지를 가지고 이쁘게 만드는 쪽으로 리뷰를 통해 더 올려갈 수 있겠죠.. 코드 리뷰를 진행해도 조기에 발견되는 오류가 추후에 발견되어 장애가 나는 경우가 많습니다. 도대체 어디를 놓치는 건지, 리뷰할 때 무엇을 중요시하는지 잘 잡으시는 팀이 있었는데요. 리뷰를 한다고 해서 100% 버그를 사전에 잡을 수 있다고 생각하지 않습니다. 수학은 참인 것을 증명하는 학문이고, 과학은 거짓이 없음을 증명하는 학문이라고 하더군요. 그래서 과학은 어떤 이론이 나온 이후에 수백 년이 지나서 잘못됐다고 증명되는 경우도 있습니다. 우리가 만든 개발도 마찬가지입니다. 피해를 입으면 우리 코드에 버그가 없다는 것은 증명할 수 있지만, 지금까지 문제가 없다는 것을 증명할 수는 없습니다. 배포된 후에 정말 100% 버그가 없다는 것을 보장하는 것은 꾸준히 리뷰를 하고 피해를 줄여야 가능합니다. 그런 것들이 누적돼서 조직의 버그를 사전 탐지하는 데 도움이 되지만, 리뷰를 했는데 왜 여전히 버그가 있는지에 대한 의문이 생길 수 있습니다. 그래서 리뷰 같은 것은 할 필요가 없는 것 아닌가 하는 생각도 듭니다.. 그리고 평소에 시간 관리를 어떻게 하시는지 궁금합니다. 아침에 일어나면 맨 처음에는 RSS 레터, SNS 등에 있는 기술 관련 소식들을 보죠. 그다음에 빨리 못 볼 것 같으면 포켓 같은 데 저장해 놓고, 볼 때 어떤 것은 제목만 보고, 어떤 것은 인터넷 없이 인터랙션만 보고, 어떤 것은 추천을 따라해 보고, 어떤 것은 책을 주문하죠. 자기가 보면서 그런 것들을 분리해내는 것이 필요한 것 같습니다. 그리고 캘린더나 저는 이제 매개닉 생제라는 걸 쓰는데, 마인드맵, 노션 등을 통해 정리를 하면서 좀 벌을 가볍게 하려고 노력을 많이 했습니다. 마지막으로, 일요일 날 패스캠퍼스에서 강의를 했을 때도 나온 얘기입니다.. 중이 옮겨야 되는 거 아닌가, 이런 얘기가 있었어요. 그런데 저를 옮겨요. 이 사람은 지금 저를 옮기려고 하고 있어요. 그런데 저를 옮긴다 그러면 회사를 이직하는 거죠. 언제까지 이직을 하면서 피해 다닐 건가 하는 거예요. 과연 영원히 이직을 통해서 내가 마음에 안 드는 회사를 만날 때마다 피할 수 있을까? 이게 하나고요. 절에 순응하고 살 수 있죠. 좀 마음에 안 들지만 절에 순응하고 살 수 있어요. 그렇게 내가 몇 년을 살았어. 그러면 그 후에 나는 과연 행복한 주의가 될 수 있을까? 이런 고민을 한번 해볼 수 있는 것 같아요. 그러면 저를 고치는 거예요. 내가 맞다고 생각하는 방법. 그러다가는 잘릴 수 있죠. 그런데 잘 될 수도 있어요. 안 잘리고 혹시 잘리더라도 나중에 기회가 오면 좀 더 잘할 기회가 높아지지 않을까? 저는 그렇게 생각하는데, 이건 답은 없는 것 같아요..
그리고 오늘 제가 다른 강의와 무관한 질문이 많았어요. 이 강의와 그다음에 강의에 질문들이 굉장히 많이 겹쳐요. 그런데 지금 제가 오늘 짧은 시간에 이거 다 말씀드리지 못해서 약간 예, 홍보 좀 찾아보시면 될 것 같습니다. 네, 오늘 강연은 여기까지고 온라인으로 질문이 올라온 게 있나요? 자네가 큰 기능에 대해서 어떻게 쪼개냐? 여기서부터 9시 14분에. 아, 이거야. 큰 단위가 큰 PR은 나눠서 하셔야죠. 그런데 아, 정말 못 나온다 이거요. 꼭 같이 받아야 된다면 커밋을 잘라내고, 커밋 그래서 PR 디스크립션에다가 이거는 전체 디프를 보지 마시고요, 커밋 단위로 보시면 돼요라고 의견을 주시면 될 것 같아요.. 그다음에 피처 브랜치의 기능 개발이 끝나지 않았더라도 여러 번 올리게 되는 거예요. 저는 여러 번 키가 올린 게 나은 것 같아요. 나중에 리뷰하는 사람들이 도저히 시간의 리뷰를 못 하게 하는 것보다는 똑같은 피처 브랜치에서 여러 번 리뷰를 올리면서 하는 게 좋을 것 같아요. 이거는 나중에 알게 되면 좀 알려 주세요. 터미널 테마야. 터미널 안 찍었는데, 야다, Yader입니다. 연말 직원 평가는 어떻게 하셨나요? 네, 그런 분들. 코드 리뷰를 할 때 PR을 잘 작성하거나 리뷰 코멘트를 잘 작성했던 분들이 떠올라요. 이 팀의 누구, 이런 게 떠오르고 그분들 평가할 때 반영하려고 합니다. 잘하는 분들이거든요.. 대부분 ABC 실행할 수 없는 환경일 경우 구체적으로 어떤 부분을 봐야 할까요? 네이밍 컨벤션 시작해도 좋아요. 그런데 계속 이렇게 하지 말고, 이게 익숙해지면 좀 더 어려운 부분들을 보셔야죠. PR의 주석을 다는 것이 도움이 된다고 하셨는데요. PR의 주석을 단다는 것은 소스 코드에 다는 게 아니에요. 내가 PR을 하면서 그 소스 코드에다가 내가 예를 들어서 직업이나 이런 데서 컴퓨터를 남기는 거지, 소스 코드에 담는 게 아니에요. 그러니까 주석을 제거하고 멀지 않은 게 아니죠. 소스 코드에 가는 게 아니고, 플리캐스트를 리뷰하는 그 시스템에서 코멘트를 다는 겁니다. 게시판 댓글 잘 되시, 그렇게 하는 겁니다. 알지 않나요? 이 사람한테 이 정도는 무리야. 이 정도는 조금만 노력하면 할 수 있을 것 같아요. 이 정도는 아마 알 수 있을 것 같아요. 정확하게 ABCD, ABCDF 이렇게 나눠지는 건 아니잖아요. 아직 잘 모르겠어. 뭐 그럴 수도 있죠.
2.7. 버그 장애는 소프트웨어 개발의 숙명으로, 변경을 최소화하는 것이 가장 좋은 방법임. 코드 리뷰를 통해 버그를 줄일 수 있지만, 완전히 없앨 수는 없음.
이게 노하우가 다 다르지 않을까요? 저희한테는 되게 좋은 방법이었는데 다른 분한테는 안 통할 수도 있고, 저희 조직에서 만났는데 다른 문제는 안 맞을 수도 있을 것 같고요.. 준혁 개발자가 신약 개발자의 코드 리뷰를 부담스러워한다. 이거는 좀 안타까운 것 같아요. 그런 거는 좀 수평적으로 얘기할 수 있어야 될 것 같아요. 정확하게는 없는데, 그냥 저희끼리 얘기할 때 200라인 이상 변경된 건 많다고 생각해요. 그다음에 여기 있는 걸 답변 드린다. 이제 개발을 시작한 대학생이 넘어가면 좋았습니다. 어떻게 바꿀 수 있을까요? 숫자로 설득해야 할 것 같은데, 우리 코드 품질이 높아지면 새로운 기능을 요청부터 개발해서 배포하는데 기존에 4주 걸리던 게 3주 걸렸어요. 그걸 만들어야 돼요. 그런 지표를. 그러면 너네들이 코드 리뷰하고 리팩토링했으니까 좋아지는구나라고 회사가 인정을 해 주겠죠. 그다음에 코드 리뷰에 얼마나 시간을 들여야 하는지를 통해서, 이거는 코드 리뷰를 아무리 잘해도 버그 장애가 일어날 수 있어요. 버그 장애가 안 일어나는 가장 좋은 방법은 변경을 안 하면 돼요. 배포 안 하고 점점점 하면서 나아지는 거지. 뭐 얼만큼 매면 바로 본부 장애가 없어지나요? 그런 거는 없는 거. 이거는 우리가 계속해서 변경을 할 때 버그 장애가 있는 거는 약간 소프트웨어의 어떤 숙명 같은 거라고 저는 생각해요. 그래서 이거는 너무 그렇게 생각하지 말았으면 좋겠고요.. 주니어가 시행령이 어떤 코멘트를 전달할 수 있나? 아, 이거 왜 이렇게 하셨어요? 라고 물어볼 수 있죠. 저는 잘 이해 안 가는데, 왜 이렇게 하신 거예요? 라고 물어보면 그분이 설명해 주겠죠. 설명을 해 주면서 그분도 아마 설명하는 기술이 늘 거예요.. 게 설명하면서 그분의 설명이 팀의 어떤 지식의 전파가 되겠죠. 그런 것도 팀에 도움이 되는 거 아니에요? 꼭 나만 돈 받는 건 아니잖아요. 적절한 일에 코드 리뷰예요. 아까 말씀드렸듯이 한 200명 정도 될 것 같고, 그다음에는 제가 그런 거예요. 여러분들은 한 500라인도 충분히 괜찮을 수도 있어요. 비디오 선정은 예, 화재 리더 필수고요. 그 사람이 정말 너무너무 훌륭해서 모든 사람의 리뷰를 해야만 한다면, 그 사람은 리뷰만 하는 걸로 하고 보상을 해 줘야겠죠. 그러실 수 있는 조직이면 그렇게 할 수도 있겠죠. 근데 싫어하겠죠. 그 사람도 개발하고 싶어 할 텐데요. 그다음에 고급 기술자의 리뷰에 대한 부담은 어떻게 되는 건가요? 다 똑같죠. 시니어는 리뷰하는 데 1시간이 아깝고, 준연구원은 1시간이 안 아깝고 그렇지도 않을 것 같은데, 다 똑같이 아깝죠. 시니어는 더 빨리 리뷰할 수 있지 않을까요? 정말 그분이 잘 아시는 분이면, 비트에서 장개발팀에 있어요. 팀장님이 코드 리뷰에 대한 보고서를 원하셨는데, 코드 리뷰로 보고서를 작성하시는 건가요? 보고 싶은 게 뭔지 이제 팀장님한테 물어보셔야 될 것 같아요. 근데 저는 코드 리뷰를 통해서 보고서를 만드는 걸 본 적은 없습니다. 설계에 대한 얘기를 어떻게 하는 게 좋을까요? 코드가 없는데 그냥 문서 정리해서 하거나, 설계에 대한 리뷰는 어지간하면 회의실에서 모여서 화이트보드 놓고 하는 게 더 좋죠. 그다음에 정리된 걸 스마트폰으로 찍어서 위치에 올리면 되지 않을까요? 이걸 설계에 대한 리뷰를 클릭캐스트로 올리면 커멘트 중에 되게 어려울 거예요. 코드 리뷰는 코드 라인 바이 라인으로 줄 수 있으니까 되게 세밀하게 줄 수 있는데, 설계는 그렇지 않잖아요. 라인 바이 라인으로 줄 수가 없잖아요. 그림이 많을 텐데 같이 보셔야 될 것 같아요. 오구장애가 보일 수 있을까요? 특히 자바 같으면 쓰레드 안전 때문에 문제 생기고 이런 거 많거든요. 메모리 릭 같은 거, 이런 거 되게 알려진 패턴들이 많아요. 그리고 많은 공통 패턴들이 인터넷에서 코드 리뷰 체크리스트 이런 거 한번 찾아보세요. 많이 나와요. 근데 우리 회사에서 발생했던 그런 버그나 장애가 있으면 그런 걸 더 추가해야죠. 아까 말씀드렸죠. 되게 멋있게 보여주고, 그분들도 하고 싶은 마음이 생길 거라고요. 그래도 안 하면 어떻게 못 하죠?.
2.8. 설계 리뷰는 회의실에서 화이트보드를 활용하는 것이 효과적이며, 문서 정리보다는 시각적으로 함께 검토하는 것이 더 유익함.
3. 영상정보
- 채널명: 백명석
- 팔로워 수: 3,690
- 좋아요 수: 171
- 조회수: 3,169
- 업로드 날짜: 2022-02-25
- 영상 길이: 1시 40분 7초
- 다시보기: https://www.youtube.com/watch?v=96JLcIq4LRw
