재택근무 3년 차 개발자가 처음부터 다시 한다면 바꿀 7가지 습관

1. 서론: 출퇴근 없는 삶이 주는 착각

재택근무를 시작한 지 어느새 3년이라는 시간이 흘렀다. 첫 직장에서 출퇴근을 하던 시절, 나에게 가장 큰 스트레스는 출근길 지하철에서 버티는 두 시간이었다. 그래서 재택근무로 전환된다는 소식을 들었을 때는 정말 하늘이 노랗게 보였다. 그런데 막상 몇 달이 지나고 나니 알게 되었다. 그 행복감은 생각보다 순진했다는 것을. 재택근무는 자유를 주는 대신, 스스로를 관리해야 하는 책임을 고스란히 내게 넘겨주었다. 이 글은 나처럼 개발자로 일하면서 재택근무를 하게 된 분들, 혹은 이제 막 IT 업계에 발을 들인 분들에게 내가 겪은 시행착오를 솔직하게 나누고 싶어서 쓰게 되었다. 지금 돌아보면 처음부터 알았더라면 훨씬 수월했을 것들이 분명 있다.

2. 첫째, 아침을 규칙적으로 시작하라

재택근무의 가장 큰 함정은 '출근'이라는 행위 자체가 사라진다는 점이다. 나는 첫 6개월 동안 아침 아홉 시에 일어난 날이 손에 꼽을 정도였다. 심지어 열 시까지 잠들어 있다가 화상 회의에 잠옷 차림으로 들어간 적도 여러 번 있었다. 당시에는 그것이 자유라고 착각했다. 문제는 오후였다. 밤늦게 코드를 만지다 보면 새벽 한두 시는 기본이었고, 수면 리듬이 완전히 무너지면서 낮에는 멍한 상태로 화면만 바라보는 날이 반복됐다. 그러다 어느 날 눈에 띄게 버그를 만드는 빈도가 늘어났다. 그때부터 나는 아침 여덟 시에 일어나 반드시 30분은 밖을 걷기 시작했다. 별것 아닌 습관 같지만, 이 루틴이 자리 잡으면서 오후의 집중력이 눈에 띄게 달라졌다. 사람의 몸은 생각보다 단순해서, 규칙적인 수면 주기가 유지되면 머리도 자연스럽게 따라온다는 것을 그때 배웠다.

3. 둘째, 코드부터 치지 마라

개발자라면 누구나 공감하겠지만, 기능 하나가 주어지면 손이 먼저 키보드로 향한다. 나 역시 그랬고, 그 습관 때문에 수많은 야근을 했다. 되돌아보면 내가 만들어 낸 버그의 절반 이상은 충분히 설계하지 않은 채 코드부터 작성한 데서 나왔다. 특히 문제가 복잡할수록 피해는 컸다. 고쳐야 할 것이 쌓이고, 쌓인 것을 수습하느라 시간이 또 나가고, 그러다 보니 마감은 점점 빡빡해졌다. 악순환이었다. 2년 차가 되던 해, 나는 처음으로 '코드보다 설계를 먼저'라는 원칙을 세웠다. 구체적으로는 주석으로 흐름을 정리하고, 예상되는 입력과 출력을 노트에 적어 둔 다음에야 키보드를 잡았다. 정말 놀랍게도 수정 횟수가 크게 줄었고, 퇴근 시간도 한 시간쯤 당겨졌다. 간단한 습관 하나가 이렇게 큰 차이를 만든다는 것을 그때 처음 실감했다.

4. 셋째, 문서는 미래의 나를 위한 것이다

내가 처음 담당하게 된 프로젝트는 문서가 전혀 없는 상태였다. 전임 개발자는 코드와 짧은 인수인계 몇 줄만 남기고 퇴사했다. 나는 '내가 맡으면 제대로 하겠다'고 다짐했다. 하지만 나도 일에 치여 한 달이 지나도록 문서는 손도 대지 못했다. 그러던 어느 날, 새로 합류한 동료에게 기능 구조를 설명해야 하는 일이 생겼다. 내가 반년 동안 만들고 고친 코드였는데도, 왜 이런 구조로 작성했는지 설명하는 데 목이 턱턱 막혔다. 그 순간 머리를 한 대 맞은 듯했다. 문서는 상사에게 보고하기 위한 것이 아니라, 다섯 달 뒤의 나 자신을 위한 것이라는 걸 그때 알았다. 그 후로 나는 코드를 조금이라도 고치면 관련된 문서 한 줄을 반드시 함께 남긴다. 지금은 그 습관 덕분에 인수인계 걱정 없이 프로젝트를 옮겨 다닐 수 있게 되었다.

5. 넷째, 퇴근 의식을 만들어라

재택근무의 또 다른 함정은 '퇴근 시간이 없다'는 것이다. 노트북을 덮어도 눈앞에는 같은 방이 있고, 집이 곧 사무실이니 마음이 좀처럼 쉬지 않는다. 새벽에 문득 아이디어가 떠올라 두 시간을 일한 날도 많았고, 주말에도 버그가 생각나면 노트북을 열었다. 당시에는 그것이 성실함의 증거라고 믿었다. 하지만 반복되면 반복될수록 번아웃이 서서히 다가왔다. 심지어 잘 자고 일어났는데도 피곤한 날이 늘어갔다. 결국 나는 한 번 정신적으로 무너지고 나서야 루틴을 만들었다. 저녁 여섯 시가 되면 무조건 컴퓨터를 끄고, 운동을 하고, 저녁을 먹는 것. 처음에는 억지로 했지만, 이제는 이 의식이 없으면 하루를 제대로 마무리한 느낌이 들지 않는다. 퇴근 의식은 생산성을 낮추는 것이 아니라, 오히려 다음 날의 생산성을 준비하는 일이다.

6. 다섯째, 리뷰는 공격이 아니라 대화다

주니어 시절 나는 코드 리뷰에서 지적받는 것을 무척 두려워했다. 내 코드가 부족하다는 말을 들으면 그날 하루가 통째로 무너졌다. 그래서 점점 리뷰 자리에 조용해졌고, 결국 실수는 더 커지고 지적은 더 많아지는 악순환에 빠졌다. 이제 생각해 보면, 그때 나는 피드백을 '나라는 사람에 대한 평가'로 받아들였던 것이다. 하지만 리뷰 코멘트는 코드를 더 좋게 만들기 위한 대화일 뿐이다. 이 마인드셋을 가지기까지 나는 3년이나 걸렸다. 지금은 리뷰 코멘트가 달리면 오히려 고마워진다. 누군가 내 코드를 진지하게 읽고 시간을 써서 코멘트를 남겨 준다는 것 자체가 귀한 일이라는 걸 알게 되었으니까. 두려움 때문에 질문을 못 하는 것보다, 부족해도 물어보고 배우는 것이 훨씬 빠른 성장의 길이다.

7. 여섯째, 작은 사이드 프로젝트를 끝까지 완성하라

유명 개발자들의 강연이나 인터뷰를 보면 빠지지 않고 나오는 조언이 '사이드 프로젝트를 하라'는 것이다. 나도 여러 번 도전했다. 그러나 매번 거창한 목표를 세우는 것으로 시작했고, 그만큼 빨리 흥미를 잃었다. 예를 들어 '인공지능 기반 투자 분석 앱' 같은 것을 목표로 잡았다가 한 달도 못 가서 접은 적이 있다. 이제 와서 생각하면 처음부터 규모를 잘못 잡은 것이다. 지금의 나라면 아주 작은 것부터 시작할 것이다. 나 혼자 쓰는 메모 도구, 가족 사진을 정리해 주는 스크립트 같은 것. 중요한 것은 규모가 아니라 '완성해서 실제로 배포해 보는 경험'이다. 작은 프로젝트 하나를 끝까지 완성해 본 경험은, 이력서에 적어 둔 화려한 프로젝트 목록보다 면접에서 훨씬 많은 것을 말해 준다.

8. 일곱째, 동료에게 먼저 다가가라

재택근무는 관계의 거리감을 키운다. 사무실에서는 점심을 같이 먹으며 나누던 사소한 잡담이, 재택에서는 자연스럽게 업무 얘기로만 좁혀진다. 어느 순간 나는 회사에서 나 혼자만 일하는 듯한 기분이 들기 시작했다. 일이 막힐 때 터놓고 상의할 사람이 없다는 것이 이렇게 외로운 일인지 그때 알았다. 그래서 나는 일부러라도 동료에게 먼저 다가가기 시작했다. 회의 시작 전에 5분 정도 안부를 묻고, 메신저에서 오늘 기분이 어떤지 물어보는 것. 아주 사소한 행동이지만, 이게 쌓이면서 사무실에서 느끼던 동료애가 조금씩 되살아났다. 기술은 결국 혼자 하는 것이 아니라 사람과 함께 하는 일이라는 것을, 개발 경력의 절반을 재택으로 보낸 나는 자신 있게 말할 수 있다.

9. 결론: 완벽한 계획보다 불완전한 실천

이 글에 담은 일곱 가지는 모두 내가 실제로 겪은 시행착오이고, 솔직하게 고백하면 지금도 완벽하게 실천하지 못하는 것들이 있다. 개발이라는 직업은 겉으로 보기보다 화려하지 않다. 버그와 씨름하고, 문서를 쓰고, 같은 코드를 반복해서 고치는 일상의 연속이다. 하지만 그 소소한 일상을 견디게 하는 힘은 결국 규율과 사람에게서 나온다는 것을 나는 3년의 시간으로 배웠다. 만약 지금 이 글을 읽는 분이 나와 비슷한 고민에 빠져 있다면, 거창한 목표보다 작은 실천부터 시작해 보길 권한다. 완벽한 계획은 아무도 세울 수 없다. 불완전한 실천이 완벽한 계획을 이긴다는 말, 이제는 나도 좀 믿는다.