코딩 권태기를 끝낸 건 결국 '주인의식'이었다
들어가며 — “카페에서 노트북 펼치면서 재밌었던 게 4년만이다”
요즘 솔직히 개발하는 게 재밌다.
주말에 굳이 노트북을 챙겨서 카페로 나오고, 자잘한 개선이나 공부 같은 걸 한참 하다가 집에 들어간다. 어느 날 그러고 있다가 문득 이상한 기시감이 들었다. 이거, 어디서 많이 해본 짓거리 … 인데?
한 4년 전이었나. 음악 작업물 믹싱한다고 노트북 들고 카페를 전전하던 시절이 있었다. 헤드셋 끼고 미친 사람처럼 같은 8마디를 백 번씩 돌려 듣던 그 시절. 결과물 들으면서 “내가 이런 걸 만들었구나, 진짜 나 개쩐다 간지난다…” 혼자 뿌듯해하던 그 느낌. 코딩하면서 그 느낌을 다시 받고 있는 거였다.
근데 솔직히 코딩이 처음부터 그런 건 아니었다. 한동안은 정말 재미없었다. 권태기 같은 게 분명히 있었다. 그러다 어느 순간부터 다시 재밌어졌는데, 왜 그런지 곰곰이 생각해 보니 답이 하나로 모이더라.
결국 내가 만든 게 ‘내 것’이라는 감각이 돌아와서였다.
이 글은 그 얘기다. 거창하게 말하면 ‘주인의식’인데, 사실 그 단어가 회사에서 가장 공허하게 들리는 단어 중 하나라는 것도 안다. “주인의식 가져라”는 말 자체가 이미 주인이 아니라는 증거 아닌가? 그래서 좀 다른 각도에서 풀어보려고 한다.
코딩이 한동안 재미없었던 이유 🔨
음악으로 비유하면 이렇다. 처음에 음악이 재밌었던 건 ‘내가 만들고 싶은 곡’을 만들었기 때문이다. 가사도 내가 쓰고, 비트도 내가 고르고, 어떤 분위기로 갈지도 내가 정했다. 결과물이 좋든 안 좋든 그게 ‘내 음악’이었다.
근데 의뢰 작업만 들어오면 얘기가 달라진다. 누군가 정해준 컨셉, 정해준 길이, 정해준 무드에 맞춰서 작업물을 뽑아내는 일은 — 물론 그것대로 배우는 게 있긴 하지만 — 끝나고 나면 묘하게 허탈하다. 잘 만들어도 “오 이거 내가 만든 거야!” 라는 감각이 잘 안 든다. 그냥 납품한 느낌이다.
코딩도 똑같았다. 가장 강하게 느꼈던 건 부트캠프 때였다. 종합프로젝트, 최종융합프로젝트 같은 큰 프로젝트들이 있었는데 주제가 다 위에서 정해져서 내려왔다. ‘통신사 요금제 추천하는 AI 챗봇’, ‘통신 혜택 추천하는 지도’, ‘OTT 서비스 추천 서비스’… 어느 하나 내가 만들고 싶어서 만든 게 아니었다. 그냥 정해진 주제에 맞춰서 기획하고, 빨리 돌아가는 거 보여주고, 발표해서 상 받는 게 목표였다.
내가 기획안을 내도 깊은 피드백 같은 건 잘 없었다. 그냥 납품 기한에 맞춰서 돌아가는 결과물을 뽑아내는 느낌이었다. 코드 짜면서도 머릿속이 비어 있었고, 끝나도 별 감흥이 없었다. 상 받아도 좀 멋쩍었다.
만든 사람의 결정이 들어가지 않은 산출물에는, 만든 사람의 애정도 잘 안 붙는다.
이게 권태기의 정체였던 것 같다. 코딩 자체가 재미없어진 게 아니라, 내가 만들고 있다는 감각이 사라진 거였다.
다시 재밌어진 결정적 순간 — “덕분에 편해졌어요”
전환점이 있었다.
회사 스태프들이 쓰는 기능 중에 ‘회사 등록’ 기능이 있다. 우리 서비스에 회사를 등록할 때 자동화로 도와주는 기능인데, 그 안에 등기부등본 내용을 파싱하는 부분이 있었다. 이게 — 솔직히 말하면 — 처음 들여다봤을 때 진짜 막막했다. 코드베이스에 익숙해지는 것부터 한참 걸렸고, 기존 로직이 왜 이렇게 짜여 있는지 이해하는 데도 시간이 꽤 들었다.
내가 한 작업은 크게 세 가지였다. 파싱 오류가 나는 특정 케이스를 추가로 커버하도록 개선했고, 새로운 항목도 파싱할 수 있게 만들었고, 자동 파싱이 불가능해서 ‘수동으로 입력해야 하는 항목’이 뭔지 등기부등본을 처음부터 끝까지 다 들여다보지 않아도 슬랙 알림으로 바로 확인할 수 있도록 바꿨다.
과정은 정말 힘들었다. 솔직히 중간에 ‘이게 되긴 할까’ 싶은 순간도 있었다. 근데 배포하고 나서 슬랙 스레드에 “덕분에 회사 등록할 때 진짜 편해졌어요, 감사합니다” 라고 스태프 분들이 한 분 한 분 답글 달아주시는 걸 보는 순간 — 뭐랄까, 그 자리에서 한 4년 치 보람이 한꺼번에 들어왔다.
음악으로 치면 사운드클라우드에 올린 음원에 좋아요랑 댓글이 달리는 순간과 똑같았다. 헤드셋 끼고 혼자 믹싱할 때는 이게 좋은 건지 어떤지 모르다가, 누군가 아 이 부분 좋다 한 줄 남겨주면 아 이게 닿긴 닿았구나 싶은 그 감각.
내가 만든 게 누군가의 일상을 실제로 바꿨다는 피드백이 직접 돌아오는 순간, 그제야 그 코드는 진짜 ‘내 것’이 된다.
물론 그 기능이 터지면 수습하는 것도 내 몫이다. 근데 신기하게도 그것마저 열받긴 하는데.. 어떤 의미에서는 받아들이게 된다. 내가 랩 하다가 가사 절거나 그러면 … 내가 분위기 살리려고 노력하는 게 당연한 것처럼.
주인의식이 코드에 남기는 흔적 — 보이스카웃이 된다
여기서부터가 좀 더 실용적인 얘기?라고 볼 수 있다. 주인의식이라는 게 단지 마음가짐의 문제만은 아니다. 실제로 코드에 흔적이 남는다.
전에 클린 코드 책의 보이스카웃 규칙에 대해 글을 쓴 적이 있다. 핵심만 다시 옮기면 이거다.
코드를 만났을 때보다 더 깨끗하게 만들어 놓고 떠나라.
캠핑장에서 보이스카웃들이 떠날 때 자기가 왔을 때보다 더 깨끗하게 청소하고 가는 그 규칙을, 코드에도 똑같이 적용하자는 얘기다. 책에서 처음 읽었을 때는 “맞는 말이긴 한데, 현실적으로 그게 되나?” 싶었다. 일정 빡빡한데 남의 코드까지 청소하고 갈 여유가 어딨냐.
근데 신기하게, 내가 만든 기능이 ‘내 것’이라는 감각이 들기 시작하니까 보이스카웃 규칙이 자연스럽게 따라오더라. 누가 시켜서가 아니라, 다음에 내가 다시 이 코드를 열었을 때 내가 편하려고 정리하게 되는 거다.
구체적으로 어떻게 달라졌냐 하면:
- 변수명/함수명을 한 번 더 본다. 6개월 뒤에 내가 봐도 이게 뭔지 알아볼 수 있을까?
- 주석에 ‘뭘 하는지’가 아니라 ‘왜 이렇게 했는지’를 적게 된다. (코드만 봐도 뭘 하는지는 알 수 있으니까)
- 엣지 케이스를 한 번 더 본다. 내가 안 보고 넘어가면 결국 새벽에 슬랙 알림 받는 것도 나다.
- 리팩토링을 미루지 않게 된다. 지금 5분 들여서 정리하는 게, 다음에 30분 헤매는 것보다 낫다는 걸 몸으로 알게 된다.
특히 등기부등본 파싱 작업할 때 이걸 몸으로 느꼈다. 처음 들어갔을 때 코드가 한참 복잡해 보였는데, 작업하면서 이왕 손대는 김에 변수명도 좀 정리하고, 분기 로직도 일부는 함수로 빼고, 주석도 새로 달았다. 누가 시킨 건 아니었다. 근데 그러고 나니 다음에 같은 코드를 열었을 때 작업이 훨씬 빨랐다.
결국 ‘내 코드’라는 감각이 들면, 정성스럽게 보살피게 된다. 그게 보이스카웃 규칙이 자연스럽게 작동하는 메커니즘이다.
반대로 말하면, 보이스카웃 규칙이 안 지켜지는 코드베이스는 기술적인 문제가 아니라 주인의식이 끊긴 코드베이스일 가능성이 높다. 만든 사람들이 다 퇴사했거나 만든 사람과 유지보수하는 사람이 단절돼 있거나.
주인의식은 어떻게 생기는가 — 강요로는 안 된다
여기까지 읽었으면 자연스럽게 드는 질문이 있을 거다. 그래서 그 주인의식이라는 거, 어떻게 가질 수 있냐?
먼저 확실한 건 이거다. “주인의식 가져라”는 말로는 절대 안 생긴다. 오히려 그 말이 자주 나오는 환경일수록 진짜 주인의식은 더 사라지는 것 같기도 하다. 말하면 할수록 도망가는 것들이 있다.
내 경험상 주인의식이 생기는 환경의 공통점은 세 가지였다. 음악할 때랑 코딩할 때랑 정확히 똑같았다.
1. 내 결정이 반영될 자리가 있는가
음악할 때는 내 아이디어가 들어갈 자리가 정말 많았다. “이 구간에서 보컬에 잠깐 음소거를 걸어볼까?”, “여기에 delay를 살짝 걸어서 잔향을 만들어볼까?”, “이 부분에 효과음 하나 넣으면 재밌지 않을까?” — 이런 고민들로 밋밋했던 트랙을 채워나가는 과정 자체가 재밌었다. 그렇게 나온 결과물은 당연히 내 거였다.
코딩에서도 똑같다. “이 자리에는 별도의 ‘변경하기’ 버튼을 만드는 게 더 좋을 것 같아요” 라고 의견을 냈는데 그게 받아들여진다거나, 주소 검색이 실패했을 때 — 검색만 성공하면 되니까 주소 문자열을 뒤에서부터 한 토큰씩 지워가며 재검색하고, 결과가 여러 개면 그중 하나를 취하는 식으로 — 내가 떠올린 방식대로 로직을 짤 수 있을 때. 이런 식으로 내 결정이 반영될 때 비로소 이 제품을 더 개선하고 싶다는 마음이 생긴다.
2. 피드백이 직접 돌아오는가
음악을 계속할 수 있었던 건 사운드클라우드에 음원을 올렸을 때 좋아요든, 이 부분이 좀 아쉽다는 댓글이든, 어떤 형태로든 피드백이 돌아왔기 때문이다. 그게 다음 곡에서 더 잘 만들고 싶다는 동기가 됐고, 음악을 더 깊게 공부하게 만드는 자극이 됐다.
코딩도 똑같다. “이 mutation 설계는 우리 팀 컨벤션이랑 좀 어긋나는데 이렇게 바꿔보자” 같은 코드 리뷰. “이 service 로직에서 CRUD 돌릴 때 N+1 쿼리가 나가고 있는데, select_related 하나 붙이면 1번으로 줄일 수 있어요” 같은 지적. 이런 피드백이 나를 계속 개발자로 발전시킨다. 받을 때는 살짝 부끄럽기도 한데, 끝나고 나면 아 그렇게 하는 거구나 싶어서 다음번엔 안 그러게 된다. 끊임없이 탐구하게 만들어주는 원동력이다.
3. 개선할 시간이 주어지는가
음악할 때는 충분히 개선할 시간이 있었다 (그땐 내가 그냥 안 바빴기 때문이기도 하다). EQ를 조절하다가 고음역대를 너무 많이 줘서 소리가 날카로워지면, “발음을 살리려면 중·고음역대를 살려야 하는데, 그러면서 날카롭지 않게 하려면 어떻게 해야 하지?” 같은 고민을 한참 했다. 그러다 보면 어느 음역대를 어떻게 깎아야 발음은 살리면서 부드럽게 나오는지에 대한 감각이 손에 붙는다. 시간이 있어야 가능한 일이다.
내가 코딩에서 한동안 재미를 못 느꼈던 건 사실 이 ‘개선할 시간’을 거의 못 가져서였던 것 같다. 부트캠프 때도, 사이드 프로젝트 때도, 회사 초창기에도 — 항상 “빨리 만들어서 제출해야 한다”, “빨리 발표해서 상을 받아야 한다” 같은 외부 압박이 너무 강했다. 그 환경에서는 코드를 다듬는 게 그냥 사치다.
근데 지금 다니는 회사는 내게 충분히 개선할 시간을 준다. “기능 하나 만드는 마감이 조금 밀리더라도, 코드가 깔끔하게 설계돼야 나중의 유지/보수 비용이 더 싸진다”는 게 팀의 기본 합의다. 그런 문화 안에서 일하다 보니, 내가 만드는 것에 점점 더 정성을 쏟게 되고, 자연스럽게 주인의식 비슷한 게 생긴 것 같다.
이 세 가지가 어느 정도 받쳐주는 환경이라면, 주인의식은 시키지 않아도 생긴다. 사람이 원래 자기 일에 의미를 붙이고 싶어하는 동물이기 때문에. 반대로 이 셋 중 하나도 없는 환경에서는 아무리 “주인의식 가져라” 외쳐도 안 생긴다.
마무리 — 만들 때보다 다듬을 때 더 애정이 생긴다
정리하면 이렇다.
코딩이 재미없었던 시기는, 내가 만든 게 ‘내 것’이라는 느낌이 끊겨 있던 시기였다. 다시 재밌어진 건 그 느낌이 돌아왔기 때문이고, 그 느낌이 돌아오니까 보이스카웃 규칙 같은 것도 자연스럽게 따라왔다. 클린 코드는 그래서 결국 마음의 문제이기도 한 것 같다. 기술의 문제이기 전에.
근데 글 쓰면서 한 가지 신기한 걸 깨달았다. 음악도 그렇고 코딩도 그렇고, 처음 만들 때보다 만들고 나서 다듬을 때 애정이 더 깊어진다는 거다. 처음 작곡할 때보다 믹싱하면서 같은 곡을 백 번 듣고, EQ를 한 음역대씩 만져가며 여기 좀 더 깎을까? 고민할 때 그 곡이 진짜 내 곡이 된다. 코드도 똑같다. 처음 PR 올릴 때보다, 그걸 운영하면서 버그 잡고, 리팩토링하고, select_related 한 줄 추가하면서 쿼리 줄여나가는 과정에서 이 코드는 내가 책임진다는 감각이 생긴다.
그래서 요즘은 유지보수가 동기부여가 된다는 역설을 실감하고 있다. 새 기능 만들 때보다, 만들어 둔 걸 다듬을 때가 더 재밌다. 4년 전 카페에서 같은 곡을 백 번씩 돌려 듣던 그 마음이랑 똑같다.
뭐, 거창하게 이런 생각을 하면서도 오늘도 카페에서 PR 하나 올리는 데 한 시간 걸렸다. 생각만 거창하지 손은 느리다. 그래도 이 글을 읽는 누군가가 맞아, 나도 그랬는데 싶다면, 그게 아마 다시 재밌어지는 신호일 거라 믿는다.
참고자료
- 로버트 C. 마틴의 보이스카웃 규칙 — 기처리의 공작소
- Clean Code — Robert C. Martin