개발 멘탈이 무너지는 순간은 예고 없이 찾아옵니다. 이 글은 개발을 하며 멘탈이 완전히 흔들렸던 실제 경험을 바탕으로, 단순한 휴식이나 긍정 마인드가 아닌 조금은 의외의 방식으로 생산성을 회복했던 과정을 정리한 이야기입니다. 전문적인 척하지 않지만, 가볍지도 않은 현실적인 이야기로 풀어봅니다.
1. 아무 문제도 없는데, 아무것도 손에 안 잡히던 시기
개발을 오래 하다 보면 이상한 시기가 한 번쯤은 옵니다. 분명 코드가 어렵지도 않고, 일정이 갑자기 폭증한 것도 아닌데 키보드 앞에 앉아 있는 것 자체가 버거운 순간 말입니다. 저에게 개발 멘탈이 처음으로 크게 흔들렸던 때가 바로 이런 시기였습니다. 오히려 프로젝트는 잘 돌아가고 있었고, 주변에서도 “요즘 잘 나간다”는 말을 들을 때였습니다. 겉으로 보기엔 아무 문제가 없었지만, 정작 저는 IDE를 켜는 순간부터 이유 없는 피로감이 몰려왔습니다.
처음엔 단순히 컨디션 문제라고 생각했습니다. 며칠만 버티면 괜찮아질 거라고 스스로를 설득했죠. 하지만 이상하게도 하루 이틀이 지나도 나아지지 않았습니다. 코드를 읽는 속도가 눈에 띄게 느려졌고, 평소라면 30분이면 끝낼 작업에 한참을 붙잡혀 있었습니다. 이때부터 저는 막연하게 “이거 좀 이상하다”는 느낌을 받기 시작했습니다.
지금 돌아보면, 이 시기의 가장 큰 문제는 원인을 찾으려 하지 않았다는 점이었습니다. 개발자는 문제가 생기면 원인을 파악하고 해결하려는 직업인데, 정작 자신의 상태에는 그 논리를 적용하지 않았던 겁니다. 그냥 “다들 이런 시기 있지”라고 넘겨버렸죠. 솔직히 말하면, 그때는 제 개발 멘탈이 무너지고 있다는 사실을 인정하고 싶지 않았던 것 같습니다.
이런 상태가 이어지면 작은 실수가 잦아집니다. 사소한 버그 하나에 과도하게 짜증이 나고, 코드 리뷰 코멘트 하나에도 마음이 쉽게 상합니다. 평소라면 “아, 그럴 수 있지” 하고 넘겼을 일들이 그때는 유난히 크게 느껴졌습니다. 개발 자체가 문제가 아니라, 개발을 대하는 제 태도가 서서히 망가지고 있었던 거죠.
개인적으로 이 시기에 가장 힘들었던 건, 겉으로는 아무도 눈치채지 못했다는 점입니다. 결과물은 나왔고, 일정도 맞추고 있었으니까요. 하지만 속에서는 계속해서 에너지가 빠져나가고 있었습니다. 마치 배터리가 천천히 방전되는 느낌이랄까요. 이때 알았습니다. 개발 멘탈 문제는 반드시 ‘큰 실패’나 ‘명확한 사건’ 뒤에만 오는 게 아니라는 걸요.
2. 쉬면 해결될 줄 알았던 착각, 그리고 더 커진 공백
멘탈이 흔들린다는 걸 어렴풋이 느끼고 나서, 제가 처음으로 선택한 해결책은 아주 흔한 방법이었습니다. 바로 ‘쉬기’였습니다. 며칠 쉬면 괜찮아질 거라 생각했죠. 실제로 많은 글과 영상에서도 번아웃의 해법으로 휴식을 이야기하니까요.
그래서 주말에는 노트북을 아예 열지 않았고, 평소 보지 않던 예능도 보면서 최대한 개발 생각을 안 하려고 했습니다.
처음 하루 이틀은 나쁘지 않았습니다. 머리가 조금 가벼워진 느낌도 있었고, “역시 쉬니까 낫네”라는 생각도 들었습니다. 그런데 문제는 그 다음이었습니다. 다시 월요일이 되어 노트북을 켜는 순간, 오히려 이전보다 더 큰 거부감이 올라왔습니다. 이때 저는 꽤 당황했습니다. 쉬었는데 왜 더 힘들어졌을까요.
곰곰이 생각해보니 이유는 단순했습니다. 휴식은 피로를 줄여주긴 했지만, 문제의 구조 자체를 바꾸지는 못했기 때문입니다. 저는 여전히 같은 방식으로 일해야 했고, 같은 패턴으로 생각해야 했습니다. 쉬는 동안 잠시 잊고 있었던 불편함이 다시 한꺼번에 밀려온 거죠.
이 과정에서 제 개발 멘탈은 오히려 더 불안정해졌습니다.
이때부터 저는 ‘쉬기만으로는 안 되겠다’는 생각을 하게 되었습니다. 그렇다고 무작정 더 열심히 할 수도 없었습니다. 이미 집중력이 바닥난 상태였으니까요. 여기서 중요한 전환점이 하나 생겼습니다. “지금 문제는 개발 실력이 아니라, 개발을 대하는 구조다”라는 생각이었습니다.
개인적으로 이 깨달음이 꽤 컸습니다. 그전까지 저는 계속 제 자신을 탓하고 있었거든요. “내가 약해졌나?”, “집중력이 떨어진 건가?” 같은 생각 말입니다. 하지만 문제를 개인의 의지로만 돌리면 해결책이 보이지 않습니다.
그래서 그때부터는 조금 다르게 접근하기 시작했습니다. 이 방식이 훗날 개발 멘탈을 회복하는 데 결정적인 역할을 하게 됩니다.
3. 생산성은 의외로 ‘덜 하는 순간’에서 돌아왔다
많은 사람들이 생산성을 올리기 위해 새로운 툴이나 공부법을 찾습니다. 저도 한때는 그랬습니다. 하지만 멘탈이 무너진 상태에서는 그 어떤 방법도 제대로 작동하지 않습니다. 그래서 저는 완전히 다른 선택을 했습니다.
일의 양을 줄이되, 기준을 바꾸는 것이었습니다.
구체적으로 말하면, 하루에 해야 할 개발 작업을 아주 작게 쪼갰습니다. ‘오늘은 이 기능을 완성한다’가 아니라, ‘이 함수 하나만 정리한다’ 정도로 목표를 낮췄습니다. 처음에는 스스로가 한심하게 느껴질 정도로 작은 목표였습니다.
그런데 아이러니하게도, 이 방식이 제 개발 멘탈을 조금씩 안정시켜주기 시작했습니다.
작은 목표는 실패할 확률이 낮습니다. 실패하지 않으니 자책도 줄어듭니다. 자책이 줄어드니 다시 키보드 앞에 앉는 게 덜 무서워집니다. 이 선순환이 생각보다 강력했습니다. 저는 이때 처음으로 “생산성은 의욕에서 나오지 않는다”는 걸 체감했습니다. 오히려 안정감에서 나오는 경우가 많았습니다.
또 하나 의외였던 건, 일을 덜 한다고 해서 결과가 나빠지지 않았다는 점입니다. 오히려 코드 품질이 좋아졌고, 리뷰 피드백도 긍정적으로 바뀌었습니다. 마음이 급하지 않으니 사소한 부분까지 신경 쓸 여유가 생겼기 때문입니다. 이 과정에서 저는 개발 멘탈과 생산성이 서로 반대편에 있는 게 아니라는 걸 깨달았습니다.
물론 이 방법이 하루아침에 모든 걸 해결해주진 않았습니다. 여전히 힘든 날도 있었고, 다시 예전 패턴으로 돌아가고 싶을 때도 많았습니다. 하지만 최소한, “아무것도 못 하겠다”는 상태에서는 벗어날 수 있었습니다. 개인적으로 이 정도만 돼도 엄청난 진전이라고 느꼈습니다.
✅함께 보면 좋은 글✅