한재중 : 2021-12-15 코드리뷰 인터뷰 with 김대석

질문	답변
SIA 는 코드리뷰를 왜 하고 있는가?	오래 되서 왜 하고 있냐고 질문을 받으니 기억이 잘 안나기는 함 본인 입사 시점에 개발자들 2명이 코드리뷰는 반드시 해야 한다고 공감하고 있었음 왜? 에 대해서는 굉장이 많이 이유가 있겠지만, 크게 2가지라고 생각함 내가 작성한 코드를 다른 사람도 볼 수 있도록 하게 - 공유 서로의 성장을 위해서 - 성장
코드리뷰 프로세스가 있는가?	도구에서 Merge 정책을 통해 develop 으로부터 feature branch 생성해서 PR 을 생성하도록 강제했음 Reviewer 선정하고 Reviewer 의 코멘트가 해결이 되어야만 merge 가 가능하도록 했음
리뷰어 선정 기준은?	같은 직무 and 같은 과제 적어도 같은 직무
적어도 과제 연관성이 있는 1인이 리뷰어에 포함되어야 할텐데...	그 부분이 SI 의 가장 큰 문제점 직무로 묶인 것이 아니라 단위 subsystem 으로 담당자가 있음 배경 지식이 없으면 서로 리뷰해주기 어려운 상황이기는 함
커밋과 PR 의 단위, PR 에 포함되어야 하는 내용은?	경험을 해 보면서 커밋/PR 의 단위가 생길 것임 서로 리뷰를 해야만 커밋/PR 의 단위에 대해 공감대를 갖게 됨 리뷰 요청자가 리뷰어가 되어봐야만 느낄 수 있음 모든 것을 PR 요청할 필요는 없음 리뷰 요청자가 리뷰가 필요한 코드를 지정해줘야 함 리뷰 요청자가 리뷰를 받고자 하는 부분을 명확히 언급해줘야 함 SIA 는 PR 템플릿을 사용하고 있지는 않지만 리뷰 요청 시, 작성해야 하는 필수 내용 (리뷰 포인트 등) 이 있음
코드리뷰의 활성도는? 리뷰를 하는 사람만 하고 리뷰 요청을 하는 사람은 요청만 하지 않나?	SI 에 있을 때, 김대석 혼자 리뷰를 해줬었음. 상호 성장이 어려웠음. SI 의 구조적인 문제임 직무로 묶어야만 활발한 리뷰가 가능함 SIA 의 경우, 조직 문화가 직급/나이와 상관없이 자유로운 의사소통을 하는 문화이기 때문에 상호 간에 활발하게 코멘트를 남겨줌
서로 리뷰를 활발히 하게 하려면?	SIA 에 입사하고 나서 직무를 세분화 했음 디자이너, FE 개발자, BE 개발자, DevOps 개발자, MLOps 개발자, 테스트 엔지니어 등으로 구분 같은 시스템을 개발하도록 해 줘야 함 → 서브시스템을 개별로 나눠서는 안 됨 서브시스템 별로 기술이 달라지는 부분도 있어서 장벽이 생길 수 있음
PR 에 대한 승인이 늦어져서 PR 이 쌓이면 어떻게 대처?	일단 해당 경험을 수차례 겪어봐야만 함 ^^;; PR 을 특정 기한 내에 완료해주자라는 이야기를 상호간에 계속적으로 했음 시간에 쫓기면 일단 Approve 함 테스트 branch 를 만들어서 review 가 완료되지 않아도 먼저 테스트를 해 봤음. 테스트에 있어서는 도움이 되었지만 결과적으로 PR 을 빨리 해 주자로 귀결되었음 현재 PR 승인을 완료하는 강제 규칙은 없음. 되도록 1일 안에는 하도록 구성원 간에 합의를 한 상태임
코멘트의 범주는?	단순히 변경 사항을 적는 것이 아님 공유라는 관점에서 코드에 대해서 물어보는 것도 코멘트에 포함되어야 함 리뷰어가 코드를 파악하기 위한 노력도 필요함
코멘트에 대해서 처리하느라 PR Merge 가 늦어지면?	처음에는 구성원들이 선임자의 요청을 무조건 다 반영하느라 다시 PR 을 생성하는데 오랜 시간이 걸렸었음 선임자가 한 이야기라고 해서 다 반영할 필요 없다는 이야기를 계속 해 줬음 코드가 의도한대로 돌아가면 반영할 필요 없음 코멘트에 필수 수정 사항, 나중에 고치면 좋을 것 같은 사항을 명시해 줌 나중에 고치고 말고는 작업자의 영역으로 남겨둠 선임자가 해당 내용을 관리할 필요 없음. 이것이 포인트. 성장이라는 관점에서 본인이 받아드려야 성장을 하는 것임. 성장을 하고 말고는 각 개인에게 주도권을 주는 것이 핵심임 시켜서 하는 수동적인 변화가 아니라 인지한 것을 통해 스스로 능동적으로 변화할 수 있도록 해야 함 선임자는 코멘트를 해주는 것 자체에 의미를 둬야 함 리뷰어는 모든 것을 다 챙길 생각을 하지 말아야 함
테스트 코드는 얼마나 작성/관리?	백앤드의 경우, 100% 코드 커버리지를 갖도록 테스트코드 작성 중 FE 의 경우, 아직 테스트코드를 적용하고 있지 못함 셀레니움을 사용해서 테스트 엔지니어가 수행하도록 접근 중
코드리뷰의 성숙도가 업무 효율성에 영향을 끼쳤나?	개발 속도가 빨라졌음 코드리뷰 초창기의 6개월 개발 속도와 현재 6개월의 개발 속도를 비교해보면 많이 차이가 난다고 느끼고 있음
그 전제는 테스트코드의 유무, 개발 방법론일 것 같은데 어떻게 생각하나?	일단, 스프린트는 개발 방향성을 지정해 준다고 생각함. 골인 지점을 설정하는 것임 스프린트의 백로그를 PM 의 요구사항을 디자이너들이 필요 기능/화면과 관련한 백로그를 개발자들에게 전달함 디자이너들이 SW 에 대한 기획자라고 보면됨 → (재중 생각) SI 로 보면 PL 전에 Pre-PL 로서 업무범위를 지정해주는 역할임
코드 품질을 어떻게 관리하나? 품질을 어떻게 정의하나?	품질에 대해서는 측정하지 않음 코딩 컨벤션은 Lint 에 맞김 → 코드리뷰 시, 코딩 컨벤션에 대해서는 이야기 하지 않음!! 나머지는 테스트 코드의 코드 커버리지 정도임
테스트 코드의 품질은 어떻게 관리하나?	관리하지 않음 어떤 사람은 다양한 케이스를 고려하도록 테스트 코드를 작성함 어떤 사람은 코드 커버리지만 만족하도록 테스트 코드를 작성함 (Assert 따위 사용하지 않음) 한 때는 테스트 코드를 이렇게 작성해야 합니다. 라고 교육도 했었는데 경험해보니 SIA 에서는 별 의미가 없다는 판단을 하게 되었음 테스트 코드는 소프트웨어의 안정성을 보장하는 것이 아니라 개발자의 심리적 안정감을 보장하는 것임 → 이렇게 하면 생산 속도가 올라감 테스트 코드가 있으니까 나는 일단 수정을 마음껏 할 수 있어 라는 느낌을 주는 것 테스트라는 것이 잘 되고 있는가? 에 대해서는 개발 과정에서 나타나는 부분이 있음 FE ↔ BE 간에 연동 시험을 하다가 의도하는 대로 결과가 안 나오면 그 과정에서 문제가 나타나고 수정할 수 있음 (재중 생각) 우리는 테스트 코드 프레임워크를 통해서 이 부분도 일정 수준으로 올릴 수 있을 것이라 생각함
코드리뷰 정착을 위해 강제적인 시도가 있었나?	백앤드에서 테스트커버리지 80% 달성하지 않으면 build fail 되도록 한 것 이것도 비율을 합의를 통해 계속 변경했었음 (현실적인 부분을 계속 반영하면서...)
강제적인 시도를 통해 구성원의 변화가 느껴졌나?	합의를 하며 진행했고 추후 이야기를 했을 때, 하길 잘 한것 같다라고 말을 들었음 그런 피드백이 있을 수 있었던 것은 구성원에게 "업무 주도권" 을 줬기 때문임 구성원의 목소리를 무시하지 않고 적극적으로 의견을 개진하고 반영해주었던 것을 통해 업무 주도권을 느낄 수 있도록 해줬다고 생각함
코드리뷰 시, Bad Comment or 하지 말아야하는 코멘트가 있다면?	그런 것은 없음 표현이 적당하지 않다면 해당 내용에 대해서 '해당 표현은 이러 저러하게 해석될 수 있으니 표현을 이러 저러하게 변경했으면 좋겠습니다.' 라고 코멘트를 달아주면 됨 다만, 코딩 컨벤션에 대해서는 언급하지 말아야 함. Lint 를 통해 해당 내용에 대해서는 눈높이를 맞추고 가자. Lint 가 기준이 되어 그 부분에 있어서는 사람이 신경쓸 필요가 없음을 인지하고 시작해야 함
대석이가 SI 에서 코드리뷰를 시도했는데 실패했었음. 해 본 사람으로서 다시 시작하려는 사람에게 해 주고 싶은 말은?	일단 해 보길 바람 누구에게든 남는 것이 있을 것임 (개인에게든/팀에게든)