일을 잘한다는 허상

이것은 잃어버린 10주... 의 기록이다... 

Week 6 이후로 갑자기 회사 일도 많아지고 개인적인 일도 계속 밀려와 정신이 없었다. 

지난 주에 큰 일 하나를 치르고 드디어 마음에 여유가 조금 생겨 다시 신입 적응기에 힘을 써보려 한다. 

많이 밀린 만큼 지난 시간 동안 느꼈던 점들, 그리고 크게 배웠던 점들 위주로 기술하며 다시 개발자로서의 성찰을 해보자. 

 

 

🌟 신입 개발자 적응기 / Week 7 ~ 16 : 일을 잘한다는 허상

 

 

💫 초보들이 일을 두 번 하는 이유

보통 일을 잘하는 사람들은 한 번에 빠르고 정확하게 처리하며, 그렇지 않은 사람들은 시간을 더 들여도 결과물이 그에 못 미치는 경우가 많다. 그리고 보통 초보들은 일을 잘 못한다. 아직 개발 주니어로써, 그리고 업무에 익숙해져 가는 신입으로써 나도 "초보" 에 속한다고 생각한다. 이게 단순히 생각에만 그쳤으면 좋았겠지만 당연한 섭리로 (?) 나 역시 초보들이 저지르는 흔한 실수를 경험했기에 기록해본다. 

 

지난 12월에 진행했던 스프린트에서 있었던 일이다. 당시 연말이라 다들 휴가도 많이 쓰고 재택근무자의 비율도 높은 시기였다. 그럼에도 불구하고 스프린트는 마무리 되어야 했기에 업무를 계속 이어나가기는 했지만, 기존에 쌓였던 기술 부채를 해결할 수 있는 만큼의 여유가 있었다. 애석하게도 나는 이전까지는 큰 실수 없이 일을 진행해왔기에, 다른 사람들이 해결하지 않고 백로그에 쌓아두었던 건들도 무리 없이 처리할 수 있을거라고 생각했다. 응 그거 착각이야. 

 

오랫동안 쌓아둔 것처럼 보이는 티켓 하나를 보고, 관련 티켓 내용과 히스토리를 보고, 문제의 범위와 도입 가능한 해결책을 고민해 보았다. "이 정도면 이번 배포 때 충분히 나갈 수 있겠는데?" 싶어 사수에게 노티스를 한 후 작업을 시작했다. 예상했던대로 문제되는 로직을 수정하는 데는 오랜 시간이 걸리지 않았고, 뿌듯함을 느끼려던 찰나 우연히 사내 메신저에서 관련 히스토리를 발견하게 되었다. 그곳에는 무엇이 있었을까. 

 

이미 몇 달도 전에 내가 진행한 작업에 대해 다른 사람들이 작업을 추진하자고 하는 논의가 있었고, 이 작업이 좋은 방향이 아닌 이유를 제시하는 팀장님의 의견과 그에 대한 근거가 적혀 있었다. 그러니 이 로직 자체만을 해결하는 것은 쉬운 일이었지만, 전체 서비스 운영 차원에서는 아니었기에 모두가 이 일을 쉽게 건들지 못했던 것이었다. 

 

Aㅏ... 다행히 난 내가 틀리면 인정이 빠른 편이기에 바로 상황을 파악하고 PR 날렸던 코드를 다시 회수했다. 물론 눈물도 함께 머금었다. 새삼 허탈해 있으려니, 뭣도 모르고 룰루랄라 작업을 이어가던 내 모습이 부끄러웠다. (우리는 이것을 근자감이라고 하기로 했어요.)  

 

그리하여 생각해보건데, 초보들이 일을 하며 실수하는 경우는 다음 두 케이스가 많은 것 같다. 

1. 히스토리 충분히 파악하지 않고 시작

2. 이 작업이 영향을 미치는 범위가 어디일지 생각하지 않고 시작 

 

위의 두 포인트는 동시에, "좋은 작업 결과를 내기 위해서는, 요구사항만 깊게 파지 말고 좀 더 둥글게 볼 수 있어야 한다"는 것을 알려주고 있기도 하다. 사실 좀 억울하기도 하다. a 를 하라고 해서 a 를 했는데, b c d 까지 파악했어야 한다고? 이거 완전 latte 마인드 아닌가? 싶을 수 있는데, 어쩔 수 없다. 개발이라는 게 그렇다. 코드 뭉치가 커지고 많아질수록 부수효과(side-effect) 는 많아지기 마련인데, 이 사실을 항상 top of the mind 에 두어야 실수를 줄이고 버그를 예방할 수 있다. 

 

개발자가 된 이상, 그리고 앞으로 계속 개발을 하기로 한 이상, 부수효과를 경계하며 한 줄 코드라도 잘 짜려는 노력과 성의를 갖추어야 할 것이라고 생각한다. 

 

 

💫 개발자가 할 수 없는 것 === 남 탓

이것은 git blame 와 log 에 관한 이야기다.

 

첫 개발 프로젝트를 했을 때 제일 신기하고 두려웠던 존재가 바로 git log 였다. 내가 작성한 모든 코드가 다 기록으로 남고, 한 번 master branch 에 머지된 코드에 대한 log 는 지워지지도 않았다. 서비스를 테스트하는데 발견된 버그를 추적했을 때 코드 작성자가 전부 나인걸 알게 되었을 때의 허망함이란... 실수를 극도로 싫어하는 내가 완벽주의를 내려놓기 시작한 것이 바로 그때부터였다. 

 

개발자는 남 탓을 할 수 없다. 내 모든 흔적이 기록으로 남기 때문이다. 심지어 한 군데에만 남는 것도 아니다. 로컬 저장소에도 남고, upstream (원격) 저장소에도 남고, 슬랙 알림 플러그인도 사용한다면 거기에도 남고, 다른 사람이 upstream 을 pull 받았다면 그 사람의 Local 에도 남고, 아무튼 안 남는 곳이 없다고 생각하는 편이 빠르다. 

 

학부 때는 문과생이었기에 프로젝트를 한다는 것은 보고서를 작성하고 발표를 한다는 것에 가까웠고, 누군가가 보고서 취합 과정에서 자료 하나를 빼트리거나 문단을 하나 통째로 지운다 해도 누구인지 알아낼 방법이 없었다. 설령 가능했다 해도 몇 십 페이지에 달하는 보고서가 전부 다른 시점에 취합되었을 것이기에 수정본을 전부 추적해가며 누가 누락했는지를 따지느니 그 시간에 새로 쓰는 게 훨씬 효율적이었기 때문에 그러지 않았다.

 

그런데 개발자의 세계는 다르다. 모두가 내가 무슨 작업을 했는지 알고 있다 (또는 알아낼 수 있다). 버그가 생기거나 에러 알림이 뜰 때, 원인 제공자가 나라면, "저 아니에요" 하고 발뺌하는 게 아~~~무런 소용이 없다. 최선의 대처는 "제가 어떤 로직을 작성할 때 어떤 것을 빠트렸습니다. 죄송합니다 금방 수정할게요." 하고 빠르게 인정 + 원인 설명 + 해결책 제시까지 해버리는 것이다. 

 

사실 나쁘게 표현했지만 나는 git blame 은 좋은 문화에 가깝다고 생각한다. 개발자들이 자신의 코드에 책임감을 가지도록 하며, 말 그대로 서로를 비난 (blame) 하기보다는 문제 해결을 더 잘 하기 위해 원인을 추적 (track) 할 수 있도록 한다. 결과적으로 이것은 진실성 (integrity) 를 겸비한 작업 문화를 만들어주고, 이슈들에 대해 개인의 문제가 아닌 팀 공통의 도전 과제로 인식되게끔 한다. 실제로 나는 이러한 환경 덕분에 개발자가 된 이후로 "완벽해야 한다" 는 강박을 많이 벗어났고, 스스로의 실수에 더 잘 대처하는 사람이 되었다. 이처럼 개발자가 남 탓을 할 수 없다는 말은 곧, 요행을 바라지 않고 스스로의 결과를 책임진다는 것이라는 의미를 담고 있지 않나 싶다.

 

+) 아래는 인터넷에서 찾은 git blame 관련 밈들... ㅎ

 

💫 일을 잘한다는 것은 개발을 잘한다는 것이 아닐진대

요즘 나에게 가장 큰 화두는, '일을 잘하는 사람' 과 '개발을 잘하는 개발자'가 같은 것인지? 이다. 스스로 평가하기에 "일을 잘하냐?" 고 묻는다면 "나쁘지 않다" 고 대답할 것 같다. 하지만 "개발을 잘하냐?" 고 묻는다면 아쉽지만 아직은 아니라고 답해야 할 것 같다. 

 

내가 생각하는 일과 개발의 차이점은 soft skill 과 hard skill 의 차이점이기도 하다. 흔히 말하는 커뮤니케이션 능력, 업무 추진 능력, 문서 작성 능력 등은 soft skill 에 속하고, architecture, clean code, debugging 등의 능력이 hard skill 에 가까울 것이다. 수많은 대외활동, 알바, 인턴 경험 덕분인지, soft skill 을 연단하고 기를 시간은 과거에 많았기에 지금으로써는 큰 문제가 되지 않고 있다. 하지만 hard skill 은 아직 많이 부족하다고 느낀다. 

 

장애 한 건을 처리할 때도, 타 부서와의 회의에 들어갈 때도, 새로운 툴을 도입할 때도, 내가 아직 미숙한 개발자라는 것을 자각한다. 모르는 용어나 개념이 등장하기도 하고, 간단한 문제를 오래 붙들고 결국 원인을 발견하지 못하기도 하고, 원인을 알아도 해결책을 떠올리지 못할 때도 있다. 

 

윗 문단을 쓰면서 급 깨달은 건데, 사실 개발을 못하는 것은 괜찮다. 지식이 부족하면 공부하면 되고, 경험이 부족하면 경험을 쌓으면 된다. 하지만 문제는 내가 "일을 잘한다" 는 주위의 평에 속아, 개발 공부를 소홀히 하고 있었다는 것이다. 사람들의 평가는 보여지는 것에 의한 것이기 때문에, 거품과 허상을 걷어낸 진실된 모습은 나 자신밖에 모른다. 그리고 그 모습은 현재로써는 구멍이 송송 뚫린 나뭇가지 같다. 이걸 내가 잠시 잊고 있었던 것 같다. 다시 정신 차리고, '개발을 잘하는 개발자' 가 되기 위해 다시 공부에 성실히 임해야겠다. 그렇게 하여 나뭇가지가 두꺼운 고목나무가 되어 그 위에 무엇을 더 쌓아도 흔들리지 않게 되는 날이 오길 바래본다.