면접에서 이 질문을 받은 적이 있다. "왜 개발을 선택하셨어요?"

준비해둔 답을 했다. "문제를 해결하는 과정이 재미있어서요. 제가 만든 것이 사용자에게 가치를 줄 때 보람을 느낍니다." 틀린 말은 아니었다. 그런데 면접이 끝나고 돌아오는 길에 생각했다. 저 말, 진심이었나?

당시에는 개발이 재미있다는 감각이 한동안 사라져 있었다.

동기부여가 사라지는 과정#

처음 코딩을 배웠을 때는 모든 게 신기했다. "Hello, World"가 화면에 찍히는 것, 버튼을 누르면 색깔이 바뀌는 것, API를 호출하면 데이터가 화면에 나타나는 것. 작은 성공 하나하나가 짜릿했다.

경력이 쌓이면서 그 감각이 무뎌졌다. 새 프로젝트를 시작해도 "또 CRUD를 만드는구나"라는 생각. 기술이 발전해도 "어차피 1~2년 뒤에 또 바뀔 텐데"라는 냉소. 출근해서 코드를 쓰고, 퇴근하고, 반복. 왜 하는지 모르겠는데 습관적으로 하고 있는 상태.

번아웃과는 좀 달랐다. 일이 과도하게 많아서 지친 게 아니라, 일의 의미를 잃어버린 것에 가까웠다.

"왜"를 잃어버리는 이유#

몇 가지 원인이 있었던 것 같다.

성장 정체. 초기에는 모르는 게 많아서 매일 배웠다. 어느 수준에 도달하면 새로운 걸 배우는 빈도가 줄어든다. 같은 패턴을 반복하게 되고, 도전의 감각이 사라진다.

비교. 트위터에서 멋진 프로젝트를 만드는 사람, 오픈소스에 기여하는 사람, 컨퍼런스에서 발표하는 사람을 보면서 나는 뭐 하고 있나 싶어졌다. 비교는 동기부여를 죽이는 가장 확실한 방법이다.

보이지 않는 기여. 프론트엔드 작업의 상당 부분은 유지보수다. 버그 수정, 성능 개선, 기술 부채 정리. 이런 일은 잘 해도 눈에 안 띈다. "새 기능을 만들었다"는 성취감과 "기존 기능이 안 깨지게 유지했다"는 성취감은 질이 다르다.

다시 이유를 찾은 방법#

정답이 있었던 건 아니고, 여러 시도 중 효과가 있었던 것들이다.

작은 사이드 프로젝트. 회사 프로젝트는 요구사항이 정해져 있고, 기술 선택에도 제약이 있다. 사이드 프로젝트에서는 내 맘대로 할 수 있다. 써보고 싶었던 기술을 쓰고, 만들고 싶었던 걸 만든다. 규모가 작으니까 부담도 없다. 만드는 과정 자체의 즐거움을 되찾는 데 도움이 됐다.

누군가를 가르치는 것. 주니어 팀원의 코드 리뷰를 하거나, 기술을 설명해줄 때 "아, 나 이거 알고 있구나"라는 자각이 생긴다. 내가 당연하게 아는 것도 누군가에게는 새로운 지식이다. 가르치면서 내가 쌓아온 것의 가치를 재확인했다.

사용자의 반응을 직접 보는 것. 배포한 기능에 대한 사용자 피드백을 직접 읽었다. CS팀을 통해서가 아니라 직접. "이 기능 덕분에 작업이 편해졌어요"라는 한 줄이 한 달 치 동기부여가 됐다. 코드 뒤에 사람이 있다는 걸 잊으면 일이 기계적으로 된다.

블로그 쓰기. 글을 쓰면서 내 경험을 정리하니까, 의미 없는 CRUD처럼 보였던 작업에도 배움과 이야기가 있었다는 걸 발견했다. 겪은 것을 글로 쓰면 경험이 납작한 반복이 아니라 의미 있는 서사가 된다.

지금의 답#

"왜 개발하세요?"에 대한 답이 바뀌었다.

예전에는 "재미있어서"였고, 한동안은 "모르겠다"였고, 지금은 "내가 만든 게 누군가에게 쓰이니까"에 가깝다.

거창한 이유가 아니어도 된다. "생계를 위해서"도 충분한 이유다. 다만 그 위에 뭔가 하나라도 얹을 수 있으면, 월요일 아침이 조금 덜 무겁다.

동기부여는 항상 있는 게 아니라 오고 가는 거라는 것도 알았다. 사라졌을 때 당황하지 말고, 그냥 기다리면서 작은 것들을 시도해보면 된다. 어느 순간 다시 키보드를 두드리는 게 즐거워지는 날이 온다.