리뷰하다가 프로젝트 틀어질 뻔한 썰

토이 프로젝트를 누군가와 같이 해본적이 별로 없다. 그리고 주변에서도 성공하는 케이스 보다는 깨지는 케이스를 더 많이 보았다. 아무래도 회사와는 다르게 참여 인력들의 상황이 모두 다르기 때문일 것이다. 그것을 알기 때문에 담당분야를 분명하게 나눠서 후배랑 둘이 프로젝트를 시작해 보았다. 하지만 리뷰하는 과정에서 문제가 발생했다. 그 상황에 대해서 느낀점과 그 동안의 경험에 대해서 기록을 남겨 보려한다.

나는 리뷰를 한다고 했는데, 잘 안되었다. 분석을 위해 몇 가지 인자를 뽑을 수 있을 것 같다. 내 리뷰의 기술 품질, 내 리뷰의 감성 품질, 리뷰를 받는 사람의 자세. 순수하게 내가 느낀 내용을 적어보려한다. 온전히 내 입장에서 혼자 복기를 해본다.

이시돌목장에서 말이 풀을 뜯고 있다.

리뷰 기술 품질

우선 리뷰를 얼마나 꼼꼼하게 할 것인지에 대한 것은 분명하게 정하기 힘든 선이다. 많은 선이 그렇듯이 참여자들이 적당히 선을 찾아서 그어야 하는데, 많은 상황이 그렇듯이 그 선의 모호함 때문에 오해가 생긴다. 가장 좋은 것은 그럴 수 있다는 것을 서로 인지하고 있는 것 같다.

오류 발생 가능성의 차단에 대한 내용은 비교적 논쟁의 소지가 적다. 물론 아주 낮은 수준의 오류 발생 가능성에 대해 방어를 요구하는 경우에 화근이 되기도 한다. 중첩되지 않는 팔일명을 쓰기 위해서 시스템 타임 밀리세컨을 사용했는데, 불안정하다고 해서 나노인가로 바꿔던 기억이 있다. 심지어 임시 데이터 파일이라 중복되어도 큰 문제가 없었는데, 오로지 중첩될 수 있다는 가능성에만 방점을 두고 밀리는 불안전하다는 의견이었다.

성능의 문제는 논쟁의 소지가 가장 많은 것 같다. 나도 참새 눈꼽만큼의 성능에 프로그래머의 능력을 평가하는 사람은 아니지만, 조금만 수정을 하면 될 것을, 많이 쓰이는 방법을 쓰면 될것을, 더 간단하게 구현하면 될 것을 굳이 어렵고 복잡하게 낮은 성능으로 구현한 경우 대체로 수정을 요구하는 편이다. 이러한 내적 조건을 가지고 있음에도 불구하고, 성능에 대한 리뷰는 참으로 조심스럽고 의견을 잘 전달하더라도 괜히 욕먹기 십상이다.

스타일에 대한 리뷰는 가장 논란의 여지가 없는 편이지만 가장 저렴한 느낌이라 가장 리뷰를 하기 싫은 항목이다. 리뷰는 비난과 지적이 아니고 도움이며, 의견이고 공동 작업의 일부이지만, 아무리 생각해보아도 리뷰하는 사람을 찌질하게 만드는 느낌을 지울수가 없는 항목이다. 그래서 이 부분만큼은 룰을 정해서 기계적으로 하는 경우가 많다. 요즘엔 툴이 좋아서 자동으로 스타일도 맞춰준다. 룰에 따라서 수정하면 되는 거니까 가타부타 말 할 필요가 없고, 자동으로 해주니까 깜빡할 일도 드물다. 파일 저장할 떄나 커밋 생성할때 자동으로 동작하도록 하면 좋다.

가장 고급진 리뷰는 구조에 대한 리뷰다. 불필요한 함수나 절차를 개선하거나 로직 자체를 변경하는 아이디어, 심지어 제출된 코드의 방향을 다시 생각해 보게 되는 리뷰가 이에 해당한다. 잘못된 API이나 인터페이스 언어의 특징을 바로 잡아 주는 것도 포함 될 수 있다 이런 리뷰는 동작에 대해서 충분한 이해와 동시에 고민이 있어야 한다. 자기 일도 아닌데 자기 일처럼 고민을 해야 할 수 있는 리뷰 이기에 참으로 귀한 리뷰다. 이런 경우 위의 경우와 달리 제안의 형태로 리뷰가 되는 경우가 많은데 제안이 수용 되지 않더라도 현재 솔루션을 다른 각도로 생각해 볼 기회를 제공 한다는 점에서도 매우 가치가 높다. 동시에 리뷰어의 수고도 가장 많이 필요하다.

내 마음대로 나눠서 그간의 경험도 좀 적어보았다. 여러 종류가 있지만 가장 안 좋은 것은 보지도 않고 아무런 의견 없이 완료 버튼을 누르는 것이다. 벽 보고 외치는 리뷰는 네트워크 패킹이 아깝다. 불필요한 이산화탄소를 발생시키는 환경 파괴다. 반대로 종류와 상관 없이 서로의 의견을 나누고 내가 작성한 코드와 기술에 대해서 1번 더 논의 할 수 있다면 그것은 참으로 생산적인 일이 라고 할 수 있다.

리뷰 감성 품질

프로그래머치고 리뷰 받고 기분 좋은 사람 거의 못 봤다. 페어 프로그래밍 할 때 옆 사람의 말은 기분 나쁘지 않게 듣지만, Github에 적힌 같은 의견은 사람을 흥분시킨다. 아닌척 노력하는 사람이 대부분인데 기회가 된다면 개발자가 리뷰 의견을 볼 때 표정을 몰래 카메라로 찰영에서 비교해 분석해 보고 싶을 정도다.

신기하게 글은 사람을 더 쉽게 화나게 하는 것 같다. 쉽게 오해의 소지를 만들어 줘서 그런가 보다. 상상의 나래를 팔 칠 수 있는 여지가 있어서 그런가 보다. 카톡으로 대화 하다가도 갑자기 빡치는 경우도 많다. 나도 친구는 기억도 못 하는 말 한마디에 식식거리며 분을 삼키다가 방탈출 했던 적이 있다. 집 앞에서 만나서 술 한 잔 하고 이야기를 나눴는데 내가 언제 그랬냐 절때 그런 말 한 적 없다 라고 해서 대화 목록을 올려서 확인 후 '어 아 뭐지' 잘 기억도 못 하는데...'거봐 그것 때문에 내가 화난거야' 라고 말하는 내가 더 초라해 지는 순간이다. 그래서 나는 그 뒤로 글은 좋은 쪽으로만 확장시킬려고 노력한다. 만나서 이야기하면 다 풀린다. 심지어 같이 일하던 고객사 담당자도 면전에서는 그렇게 상냥할 수가 없다.

어쨌든 리뷰는 글로 작성 한다. 그러니까 부정적으로 발전할 가능성이 크다는 것을 염두에 두고 조심스럽게 작성해야 한다.

그럼에도 불구하고 그걸 아는 사람도 상냥한 척 존대를 하면서 비꼬는 말투를 사용하기도 한다. 사실 이런 경우는 코드를 넘어 관계 뭔가 문제가 있어서 감정이 실린 글을 쓰게 되는 것이다. 왜 문제가 있는지 어떤 문제가 있는지 어떻게 해결 할 지는 모르겠지만 어쨌든 리뷰에 감정이 들어와서는 안 된다. 좋은 쪽으로도 감정 리뷰는 안 된다. 이를테면 코드를 깔끔하게 작성 하시네요. 가독성을 중둔 코드가 참 보기 좋습니다. 이런 칭찬도 불필요한 감정 혼선을 만들 수 있다. 꼭 이야기 하고 싶은 부분 있다면 사실을 기반으로 구체적으로 이야기 하는 것이 좋다. 140 라인에 조금 많이 간단하게 정리 되어서 깔끔해진 것 같습니다. 중첩 된 블록이 해소 되니 가독성이 좋아진 것 같습니다 정도면 될 것 같다. 최대한 감성을 제외하고 사실에 기반에서 고려 된 점과 계산 안에 대해서 제한을 하고 수정을 요청 하는 것이 좋다. 감정을 표현하고 싶으면 만나서 또는 메신저나 전화 통화로 좀 더 섬세하게 전달하는 것이 좋은 것 같다.

리뷰를 받는 자세

나는 항상 리뷰를 감사하게 생각한다. 내가 약간 관종 이기 때문이다. 적당히 튀는 거 좋아하고 나한테 관심 가져 주는 것을 선호 한다. 그래서 나는 욕이 아닌 이상 다 좋아한다. 물론 리뷰를 받으면 행복한 것 보다도 부끄러운 마음이 드는 일이 가장 많다. 대부분 나의 실수 이거나 내가 미처 생각하지 못했던 부분이기 때문이다. 아무리 부끄러워도 어쨌든 나를 생각해 준다는 것을 고맙고 그 일을 통해서 내가 조금이나마 발전할 수 있다는 것이 좋다. 물론 가끔 나를 밟고 올라서 자신의 우월함을 팀원 전체에게 보이려고 하는 경우도 있다. 그런 경우에서도 나는 꼭 그 사람의 수고를 인정하고 많이 널리 알리도록 한다.

물론 정말 짜증날 때도 있다. 나를 공격하는 듯한 리뷰다. 정확한 이유는 모르겠지만 나한테 삐진거 같은 느낌이 강하게 든다. 특히 평소와 다르게 감정이 실린 리뷰를 하면 분명 나와의 관계에서 무슨 일 있었던 것이다. 내가 인지하지 못한 채 내가 그 코드가 관련된 문제로 그 사람을 무시거나 곤경에 빳데리 있거든 그 사람이 업적에 치명적인 손상을 줬던 경우에도 그럴 수 있다. 정확하게 코드 관련이 없다 하더라도 기술 미팅에서 리뷰어의 다른 건으로 마찰을 겪었거나 주장하는 바가 다른 상황에서 이견이 큰 경우에도 그럴 수 있다.

어쨌든 그 사람의 궁극적인 리뷰를 작성 하게 된 계기가 코드와 리뷰 시스템 내서 해결 될 수 있으면 좋겠지만 힘들다면 대화를 통해서 상황을 정리하는 것이 좋다. 이럴 때 일수록 오히려 명확하게 직설적으로 리뷰 의견을 물어 보는 것이 좋다. 신기하게도 대화를 통해서 왠만하면 해결 된다. 물론 코드와 전혀 상관 없는 인간 관계에서의 일이 얽혀 들어갈 수도 있지만 그건 뭐 알아서...ㅎ

사실 나도 리뷰를 받는 순간 방어적인 자세를 취하게 된다. 감사한 마음이 들면서도 내가 짠 코드 에 대해서 방하려는 기재가 활동한다. 확실이 느낄 수 있는 아주 명확한 감정이다. 나는 성인 이기 때문에 그 감정을 잠 재우고 열린 마음으로 리뷰를 포용하려고 노력 하지만 늘 강하게 발현되는 것을 느낄 수 있다. 내 코드가 무시 되는 것 같고 내가 무시 되는 것 같은 그런 생각을 할 필요가 없는데도 감정은 나의 생각과 다르다. 하지만 많은 사람들 앞에서 발표를 많이 하다 보면 무던해 지듯이 리뷰도 자주 하다 보면 그런 감정도 많이 누그러 진다. 진짜 리뷰를 많이 주고 받다 보면 확실이 좋아진다. 반대로 리뷰 의견을 받아 보지 못한 사람일수록 많은 사람들 앞에서 첫 연설할때와 같이 쉽게 흥분 하는 것 같다. 그래서 수평적인 문화를 바탕으로 리뷰를 자유롭게 많이 해야 좋다. 많이 할 수록 부담 없이 의견을 나눌 수 있고 의견을 나누면서 더 좋은 의견이 도출되고 자연스럽게 의사소통이 되고 지식과 기술의 수준이 맞춰진다. 그래서 IT 회사에서 앞 다투어 영어 이름을 쓰고 호칭을 간소화 하고 리뷰를 활성화 하려고 하는 것이다.

리뷰를 받는 사람이 열린 마음으로 리뷰 의견을 받아서 문답 하면 리뷰를 통해서 의견을 받았을 때 설령 그것이 조금 부족한 의견일지라도 추가로 의견을 주고 받는 과정을 통해 생각에 전환이 발생하기도 하고 심지어 잘못된 의견을 통해서도 해당 부분을 다시 확인해 보고 서로의 지식수준을 맞춰 갈 수도 있다. 부족하고 쓸모 없는 시간 낭비 라고 생각하지 말고 좋은 기회가 될 수 있도록 마음을 열고 리뷰를 보자.

주는 사람과 받는 사람

주는 사람과 받는 사람은 사이에는 비용이 있다 이것은 열역학 제2 법칙 와도 관련이 있다 내가 친구에게 50,000원 지수를 산다면 친구는 10,000원 정도의 신세를 졌다고 생각하게 되는 것이다 이것은 수치와 인간성을 배제한 상태에서 어느 정도 잘 맞는다고 생각 한다. 따라서 친구에게 술 사주면 바로 잊는 것이 우정에 도움이 된다.

리뷰도 비슷하다. 리뷰를 문화의 영역에 두는 회사도 있지만 리뷰도 업무로 인정하는 회사도 많이 있다. 남의 코드를 리뷰하는 것은 내 코드를 보는 것보다 더 힘들고 적지 않은 시간 고민을 해야 하기에 리뷰를 하는 것은 분명히 큰일이다. 당연히 주는 사람은 자신의 수고가 크게 느껴지는데 받는 사람은 그렇지 않다는 것이 문제다. 친구에게 선물을 사는 일이라면 그냥 우정을 위해서 희생하면 되지만 이건 그렇지가 않다. 특히, 토이 프로젝트와 같은 각각의 노력이나 수고가 비대칭을 이루는 과제에서 리뷰를 해주는 것은 정말 쉽지 않은 일이다. 그 시간에 내가 맡은 부분을 작업했으면 차라리 더 많은 눈에 띄는 결과를 얻을 텐데, 그렇다고 리뷰를 안 할 수도 없고 회사에서처럼 근무시간을 할당에서 리뷰를 하는 것도 아니고 여러므로 쉽지 않은 일이다. 솔직히 이 부분에 대해서 제대로 된 해결책이라는 것은 없는 것 같다. 결국 서로에 대한 신뢰를 바탕으로 하는 수밖에 없다. 감사와 존중을 바탕으로 분명한 역할과 관계 안에서 프로젝트를 진행 하면 될 것 같다는 뻔한 답 밖에 될 수 없을 것 같다.

결과적으로 그래서 토이 프로젝트가 어려운 것 같다. 지분이 불분명해서 역할과 관계가 모호해서 어려운 것 같다. 확실한 것은 내가 손해 보는 것 같다는 생각이 들거나 내가 더 많이 일하고 있다는 생각이 들면 서둘러서 그만 두는 것이 좋을 수 있다. 둘 다 오만원어치 술을 사고 만원어치 술을 얻어 먹었다고 생각하였고 있다면 그 결과는 뭐 뻔하지...