세상에 나쁜 코드는 없다 - 개발자 협업
더 원만한 협업을 위하여
안녕하세요. 프론트엔드 리드 엔지니어와 그로스 엔지니어로써 크몽이라는 서비스를 만들고 있는 bk입니다. 개발은 2015년부터 시작하여 지금 6년 차에 접어들었네요. react-native를 이용한 서비스 개발기로 글을 썼던 게 엊그제 같은데 벌써 1년 반이 다 되어 가네요. (2019년에 글 4개 쓰겠다고 CTO님께 말씀드렸었던 것 같은데..)
여하튼 오랜만에 이렇게 허접한 글을 쓰게 된 이유는.. 그냥 요즘 개발하며 현타가 오기도 하고 연차가 지나면 지날수록 기술과 실력보다 협업이 더 중요하다는 것을 깨닫고 머리 좀 잠깐 리프레쉬할 겸 개발자들에게 협업은 결국 코드이고 이것이 얼마나 중요한지와, 코드로서 협업에 대한 이야기를 크몽에서의 경험을 통해 조금이나마 도움이 될까 하고 써보는 글입니다.
혼잣말하는 방식으로 써 내려갔기에 음슴체 주의
개발 왜 함?
대부분의 개발자는 회사를 다닌다. 웹이든 앱이던 결국엔 서비스라는 형태가 있을 것이고 우리는 그것을 개발한다. 회사에선 내 서비스라고 생각하라지만 사실 쫌 까놓고 말해선 누군가의 서비스를 만들고 있다. (창업자 제외 ㅋ) 아니 내 서비스도 아닌데 왜 그리 열심히 개발을 해? 이제 여기에서 자신만의 목적이 다양하게 나뉜다.
자기만족
더 높은 직책
내년 연봉협상
그냥(?)
그냥을 제외하고, 뭐든 동기부여로 인해 개발을 한다는 있다는 것은 매우 바람직한 상황이라고 생각된다. 그렇다면 좀 더 나아가, 각자의 목적을 이루기 위해 어떻게 일을 해야 할까? (정치 극혐)
손을 더 빨리 움직인다? 밤을 새운다? 뭐 맞는 말일 수도 있겠지만 협업이야 말로 목표를 위한 가장 빠른 지름길이라 생각한다. 심지어 혼자 개발해도 과거의 나 자신과 협업을 해야 한다(?). 한때 아~ 그림자 분신술로 나랑 똑같은 분신 10명만 있으면 얼마나 좋을까? 라는 생각을 자주 하곤 했다.
현실은 협업이 안된다고 투덜대는 분신 2~3마리는 꼭 있을 것 같다협업
절대 완벽한 협업은 없겠지만 최대한 같은 팀원끼리 같은 생각을 하고 같은 지향점을 바라보는 것이 협업이 가장 잘되는 케이스라고 생각한다. 그래서 요즘 eslint 같은 코드 규칙이라던지, 코드 리뷰, 테스트 같은 개발 문화가 발전하고 있는 게 아닌가 싶다.
자라온 환경도 다르고, 생각도 다르다면 함께 하는 코드만이라도 최대한 같은 생각을 하자!
코드에 규칙이 생기니 자신의 코드를 검증하기 위해 코드 리뷰가 생기고, ci/cd로 좀 더 코드에 집중하는 환경이 조성되고.. 현재 크몽도 그렇게 협업을 함께 만들어가고 있다. 물론 아직 완벽하지 않다.
스타2의 명언클린 코드라는 책은 개발자의 입문서라고 할 만큼 유명하고 클린 코드를 모르는 개발자는 많지 않을 것이다. 이 책에서 권장하는 규칙들은 정말 많다. 정말 너무 많다. 때문에 클린 코드에 관한 책이나 포스팅 몇 권씩 읽었다 한들 한 순간에 클린 코드 천재 개발자가 될 순 없다. (천재라면 가능.. 적어도 난 안됨)
하지만 내 생각은 클린 코드에서 권장하는 룰조차 완벽이란 없다고 생각한다. 수많은 코드 규칙들도 시대에 따라, 기술의 변화에 따라 발전되고 있다. 오늘 "옳다"라고 생각했던 룰들이 내일은 바뀌어있을 수도 있다. 이렇게 계속 바뀌고 방대한 규칙들을 업무시간 내에 하다간 일 못한다. 업무외 시간에 해야 하나? 하지만 퇴근하고 나서는 개발 말고도 하고 싶은 것들이 너무 많다. (글 다 쓰고 와우 하러 가야 됨)
혼자 하기 힘들다면 같이 하면 된다. 나에겐 훌륭한 팀원이 있지 않은가? 코드 리뷰를 통해 하나 하나씩 내가 아는 것과 네가 아는 것을 합쳐서 조심씩 누적해서 배워나가는 것이다...
그렇게 조금씩 Best practice를 배워나가며 팀원들의 성능(?)의 향상되어 서비스를 더 빨리, 더 적은 오류로 안정적이게 개발해 나갈 수 있다. 하지만 내가 이 글에서 말하고자 하는 건 좋은 코드를 쓰자가 아니다. 좋은 코드를 쓰자와 관련된 글을 나의 이런 못난 글보다 훨씬 뛰어난 글들이 많다. 내가 하고 싶은 말은 좋지 못한 코드를 어떻게 바라보고 피드백을 주어야 하는가이다. 위에서 잠시 언급했듯 개발자에게 협업이란 결국은 동료가 좋은 코드를 짜도록 도와주는 것이다. 코딩에 틀린 방법은 없다고 생각한다. 하지만 확실한 건 더 나은 방법은 있다.
세상에 나쁜 코드는 없다 하지만 좋아질 코드는 있다. 이게 뭔 개소리냐? 그게 그거지 라고 생각하는 분들도 있겠지만 그럼에도 난 이렇게 생각한다. (진지 빨면 오류 나는 코드는 잘못된 코드임ㅋ)
아니.. 왜 이렇게 했어요?
그 방법은 틀렸어. 이 방법이 정답이야
하.. 이거 누가 개발했어??? 와.. 진짜
ㅋㅋ 이 세상 코드가 아니다.
(물론 나도 이런 말을 한다. 오늘의 내가 어제의 나에게만..)
서울에서 부산 가는 방법은 정말 많다. 누구는 1등석 비행기를, 누구는 ktx 타고, 좀 힘들지만 자차로 가는 게 마음 편한 사람이 있을 수도 있고, 느긋하게 가족과 드라이브 즐기며 해안도로로 가는 것을 즐길 수도 있다. 단순히 코드 몇 줄로 판단하여 이거 보단 이게 정답이야!라고 단번에 말할 수는 없다. 다른 예외적인 케이스 때문에 가장 효율적인 방법을 사용하지 못했을 수도 있다. 협업의 과정에서 피드백은 의견을 주고받는 자리이다. 내가 옳다 네가 옳다가 아니다. 꼭 코드리뷰가 아니더라도 심지어 개발자가 아니더라도 마찬가지다. 업무의 능력과는 별개로, 자신이 너무 뛰어나 팀원의 사기를 떨어뜨리거나, 발전 하려는 노력의 모습도 보이지 않는 팀원이 있다면? 개선의 여지가 없다면? 당장 그곳을 탈출해야 한다. 그 정도 상태만 아니라면 왠만하면 대화를 통해 개선이 가능하다고 생각된다. 그렇다면 좋은 더 나은 코드를 위해 피드백을 주고 받을땐 어떻게 해야할까? 최소 이정도면 충분하다 생각한다
피드백 주는 개발자: 위의 극단적인 예의 경우에도 사실 피드백을 준 당사자의 속마음은 정말 동료와 함께 좋은 코드를 나누고 싶어서 주는 소중한 피드백일 가능성이 매우 매우 높다. (형이 애정이 있어서 까는 거다) 하지만 그 표현의 방법이 오해를 불러일으킬 충분한 마법의 단어를(와..하..아니..) 사용을 하지 않았는지?, 내가 더 나은 코드를 제안한 것이 맞는지, 상황에 맞는 코드를 제안한 것인지? 그래서 나는 웬만하면 피드백을 의문문으로 작성을 하곤 한다.
A가 아닌 B를 사용한 다른 이유가 있을까요?
피드백 받는 개발자: 반대로 리뷰를 받는 개발자 또한 피드백을 주는 방식이 조금은 강려크하고 감정선이 흔들리더라도 함께 좋은 코드를 나누고 싶어 하는 팀원의 그 따뜻한 마음을 받아들여야 한다. 아니면 자신의 코드에 과한 자부심을 가지고 있는지 아닌지? (감히 내 코드를 까??? X) 되뇌어보아야 한다. 함께하는 더 나은 코드를 위해 시간을 쏟아 피드백을 준 리뷰어에게는 가능한 한(시간이 허락한다면) 자세히 설명을 해주길 바란다. 그게 최소한의 예의이자 매너다.
감사합니다 (따봉 이모티콘)
공통: 동료를 까내리려는 의도를 가지고 피드백을 주는 놈이 있거나, 좋은 피드백을 줘도 항상 삐뚤게 받아들이는 그런 머저리는 개발자 때려치워야 한다. (내 주위에 절대 없음)
레거시 코드들은 지금도 계속 생성되고 있다. 아무리 최신 기술의 집약체로 작성한 어제의 코드도 언젠가, 누군가에겐 레거시가 된다. 솔직히 나도 수년 전에 만들어진 js 파일들을 보면서 보기도 불편하고 파악하기 힘들다. 하지만 그 코드가 잘못된 코드다? 라고는 절대 생각하지 않는다. 복잡하고 길기만 한 회사의 몇 년 전 과거 코드들은 쓰레기, 나쁜 코드가 아니라 지금의 내가 다니는 이 회사를 있게 해 준 소중한 코드들이다. 난.. ㄱㅏ끔 그 코드들에게 존중을 표한다.(점점 미쳐가는 듯)
사실 내가 개발 2년 차 까지는 남이 짠 코드는 다 보기 힘들고 내가 짠 코드만 보기 편하다고 생각했다. 잘 짜여진 유명한 라이브러리를 뜯어봐도 대충 좀 읽다가 "뭐가 이리 복잡해~" 하고 창을 닫았던 것 같다. 그러다 스터디 그룹에서 간단히 토이 프로젝트의 코드 리뷰를 받게 되었는데, 내가 작성한 코드가 잘 안 읽히고 이해가 잘 안 된다고 하는 것이었다. 처음엔 이게 왜 어려워요? 이러케 이러케 되고 간단하지 않아요?라고 되물었는데, 스티디 팀원 거의 전원이 이해 잘 안 된다고.. ㅋㅋ 그때 처음으로 아 내가 짠 코드가 가독성 좋았던 게 아니라 그냥 많이 봐서 눈에 익은 거구나.. 내가 겁나 오만했구나라는 생각이 들었다..
그래서 뭐 어쩌라고?
남에게 관대하고 자신에게 엄격해라 (누군가 말함)
꽤 오래전에 본 글귀인데 인생에 어디서든 적용이 가능한 말인 것 같다. 물론 관대하라는 말이 동료에 대한 피드백을 하지 말라는 절대 말이 아니다. (그건 무관심) 한국말은 참 대단하게도 같은 말을 할지라도 아 다르고 어 다르듯이 충분히 좋은 단어의 사용으로 착한 피드백을 날릴 수 있다고 믿는다.
사실 코드 리뷰 문화가 크몽에 자리 잡아갈 때 혼자 이런 우려를 많이 했었는데, 지금 와서 생각해보면 과한(괜한X) 우려였던 것 같다. 하지만 언제나 예의 주시해야 할 큰 이슈라고 생각한다. 코드 고치는 건 아주 쉽지만 마음 상한 건 고치기 매우 어렵다..
님 이글 코드 리뷰 까이고 빡쳐서 올린 거 아님?
네 아닙니다. 아닙니다. 절대 아닙니다...
아무쪼록 이 글을 보고 계시는 모든 개발자님들, 동료와 함께 더 나은 코드를 작성하고 함께 개개인의 성능 향상을 이루어 내년 연봉협상 회의실을 웃으며 나갈 수 있기를 희망하겠습니다. 감사합니다.
전 이만 와우 하러
혹시 css 가 힘드세요? 고급 스타일링 도입을 고려하시는 분들께 추천!
