들어가며

1월 10일부터 인턴십을 진행중이다. 벌써 인턴십 기간의 절반이 지나갔고 더 나은 절반을 위해서 회고를 쓰려고 한다. 나는 어떤 실수를 범했고, 무엇을 어떻게 개선하면 좋을까?

책임 전가의 대가. 황성찬

인생은 선택의 연속이다. 일할 때도 선택이 필요한 순간들이 자주 찾아온다. 지금까지 선택이 필요한 순간에 멘토님들께 선택의 책임을 떠넘긴 것 같다.

주간 미팅 때 리더님께 보여드릴 기획서를 작성할 때의 일이다. 동료와 기획서를 작성하던 중 기획서를 두 가지 버전으로 작성했다. 두 버전은 각각의 장단점이 있었다. 그리고 우리는 각각의 장단점을 정확히 파악하고 있었다. 그렇지만 멘토님께 두 가지 버전을 보여드리며 어떤 버전이 낫냐고 여쭤봤다. 선택을 멘토님들께 미뤄버렸다.

멘토님들께서는 친절하게 답변해주셨다. 그리고 답변은 우리의 생각과 크게 다르지 않았다. 멘토님들께서도 선택에 앞서 각각의 장단점을 말씀해주시고 이번에는 A 기획서로 결정하면 좋겠다고 하셨다. 이 순간 크게 부끄러움을 느꼈다.

나는 줄곧 학생 티를 벗고 싶었다. 학생, 인턴 이라는 이름 뒤에 숨고 싶지 않았다. 학생 치고 잘하네, 인턴치고 잘하네 같은 소리를 듣고 싶지 않았다. 그냥 잘하는 사람. 잘하는 개발자이고 싶다. 그런데 멘토님들께 이런 질문을 하는 순간 누구보다 학생다웠고 인턴다웠다. 인턴이라는 이름으로 어리광부리지 말자.

그렇다면 질문을 아예 하지 않는게 좋을까? 섣불리 선택했다가 낭패를 볼 수도 있지 않을까? 그런 일을 방지 하기 위해서 일일 미팅이 있다고 생각한다. 어떤 선택을 했을 때, 일일 미팅 때 작업 상황과 나의 상황을 잘 공유하자. 이제는 책임 전가의 대가가 아닌 상황 공유의 대가로 거듭나리라

인턴십의 목적은 성장이다

사실 지금 인턴으로 일하고 있는 팀이 썩 마음에 든다. 정직원으로 일해보고 싶다. 그래서 그런지 어느순간 어떻게 하면 전환이 될 수 있을까? 라는 생각을 하게 되었다. 그리고 모든 의사 결정 전 전환에 유리한 것 을 찾아서 의사 결정을 하고 있었다. 매번 이렇게 하면 좋은 평가를 받겠지? 라는 생각을 하게 되었다. 어이가 없다. 나답지 않았다.

전략적인 인턴생활이 나쁜건 아니다. 그런데 너무 과하면 의사 결정이 편향적으로 변하는 것 같다. 비즈니스 문제를 해결하기 위한 의사 결정이 아닌, 전환을 위한 의사결정. 정말 멋이 없다.

인턴십을 처음 시작할 때만 해도 전환 신경 쓰지 말고 항상 최선을 다해서 임하자는 마인드였다. 이런 마음으로 인턴을 수료하게 된다면 전환에 실패해도 다른 기업에서 탐내는 인재로 성장할 수 있을 것 같았다. 있을 것 같은게 아니라 확신했다. 그리고 아직도 이 확신에는 흔들림이 없다.

항상 리마인드하자. 최선을 다해서 일하고 결과에 연연하지 말자. 어딘가 나를 원하는 회사가 있지 않겠는가? 내가 떨어졌다면 나와 핏이 맞지 않는 회사일 뿐이다. 내가 일하는 방식, 내가 말하는 방식들을 가감없이 보여줘야겠다. 내가 당신들의 팀에 어울리는 사람인지는 당신들이 판단할 몫이다. 마음이 한결 편해진다.

내 생각과 동료의 생각을 동기화하자

프로젝트 중간에 코드가 대규모로 개편된 적이 있다. 작업 중 상당한 conflict가 예상 되었다. 실제로 작업을 마치고 동료의 코드와 내 코드를 master로 머지를 했을 때 무수한 conflict가 발생했다. conflict를 해결하고 머지를 했는데 (머지가 완료된 코드의) 애플리케이션은 동작하지 않았다. 애플리케이션이 실행되지 않는 문제를 해결하기 위해서도 시간을 많이 썼다. 어쩌다 이런 일이 발생했을까?

서로의 생각을 동기화 하지 못한 것이 가장 큰 이유라고 생각한다. 생각을 동기화? 무슨 소리지?

작업을 분배할 때 A기능 , B기능 이렇게 분배했다. 그런데 어디까지가 A기능 인지는 사람마다 다르게 인식하고 있다. 내가 인지하고 있는 A기능은 10이었다. 반면에 동료가 인지하고 있는 A기능은 50이었다.

그래서 동료가 10까지 작업하고 머지하겠지? 라는 생각으로 가득차있었다. 내 예상과는 다르게 동료는 50까지 작업을 하고 있었다. 앞으로는 더 구체적이고 명시적인 작업 분배를 할 생각이다. 10까지 작업 부탁드립니다. 처럼. 10까지 작업하시겠지? 라는 안일한 생각을 버리자.

나의 생각을 동료의 생각과 동기화하자.

코드 리뷰라는 이름의 Disrespect

동료 인턴분을 보며 배우는 점이 참 많다. 기능 구현들을 시원시원하게 잘하시는 것 같다. 일을 정말 잘한다. 사실 객체지향적인 코드를 작성하지는 않으신다. 하나의 함수에서 여러가지 일을 하기도 한다. 여러가지 일을 하다보니 함수가 정말 길어지기도 한다. 그래도 논리적 오류 없이 구현을 뚝딱뚝딱 잘 해내신다. 반면에 나는 객체지향, 클린 코드를 핑계로 작업 속도를 못내는 것 같다.

나만 속도를 못내는 것도 문제인데 코드리뷰를 하며 동료의 생산성도 갉아먹었다. 이건 클래스로 분리하면 어떨까요?, 이 로직은 단일 책임 원칙을 어긴 것 같아요 등등.. 작업 속도는 한 없이 느려졌다. 동료님께서는 나의 무례한 코드리뷰에 수긍하시고 군말없이 수정해주셨다.

물론 코드리뷰하며 유지보수하기 좋은 코드를 작성하는 것은 참 좋은 행위이다. 그런데 문제는 내가 객체지향을 이해하고 있는 수준이 낮다는 것이다. 수준이 비슷한 사람들끼리 리뷰를 하니 드라마틱하게 개선되는 점은 없다. 그저 작업 속도가 느려질뿐이다.

객체지향을 흉내내다가 일정을 못 맞추는 프로그래머 vs 우아하지는 않지만 일정 내에 구현 해내는 프로그래머

누가 더 프로다울까? 당연히 후자다. 한국에서 자바/스프링 스택을 공부하는 학생들이라면 당연히 이동욱님, 김영한님, 박재성님(자바지기)의 영향을 많이 받았을테다. 나도 그랬다. 나는 영향을 너무 많이 받은 나머지 주화입마에 빠져버린 것 같다.

프로그래머는 클린코드, 객체지향적인 코드를 짜는 사람들이 아니다. 프로그래머는 문제를 해결하는 사람들이다. 어떤 코드를 작성하던지, 비즈니스를 일정에 맞게 해결하면 그만이다. 나중에 기술 부채가 되어서 돌아올꺼라고? 부채는 갚으면 그만이다. 나중에 갚자.

앞으로는 코드리뷰의 목표를 재설정할 생각이다. 객체지향적 코드를 유지하자 가 아닌, 논리적 오류가 없는 코드를 유지하기 위한 리뷰를 하자.