퇴근 후에도 노트북을 여는 개발자의 진짜 하루를 옆에서 지켜봤더니
친구가 개발자가 되고 나서 달라진 것들
얼마 전 개발자로 일하는 친구를 만났는데, 카페에 앉자마자 노트북부터 펼치더라고요. 저는 그냥 커피 마시고 근황 얘기나 하려던 참이었는데, 친구는 “배포가 하나 걸려 있어서 10분만 볼게”라고 했습니다. 10분이라고 했지만 실제로는 34분이 걸렸고, 그 사이 저는 아이스 아메리카노 얼음이 반쯤 녹는 걸 구경했습니다.
그때 살짝 궁금해졌습니다. 개발자는 정말 하루 종일 코딩만 할까. 주변에서 개발자라고 하면 연봉, 재택근무, 이직, 야근 같은 단어를 먼저 떠올리는데, 실제 생활은 생각보다 더 복잡해 보였습니다. 그래서 개발자 친구 3명에게 평일 루틴을 물어보고, 옆에서 일하는 모습도 조금 지켜봤습니다. 솔직히 말하면 제가 상상했던 ‘키보드 두드리는 멋진 직업’과는 꽤 달랐습니다.
코딩보다 먼저 하는 일: 문제를 정확히 읽기
가장 의외였던 건 개발자가 하루의 대부분을 코드 작성에 쓰지 않는다는 점이었습니다. 친구 한 명은 8시간 근무 중 실제로 코드를 치는 시간이 2~3시간 정도라고 했습니다. 나머지는 회의, 기획서 확인, 버그 재현, 동료 코드 리뷰, 배포 확인 같은 일로 채워진다고 하더군요.
예를 들어 쇼핑몰 앱에서 “장바구니 수량이 이상하게 보여요”라는 문제가 생겼다고 해도 바로 코드를 고치는 게 아니었습니다. 먼저 어떤 휴대폰에서 생겼는지, 앱 버전은 몇인지, 로그인 상태였는지, 쿠폰을 적용했는지 같은 조건을 확인했습니다. 근데 이 과정이 생각보다 길었습니다. 같은 문제처럼 보여도 원인이 5개쯤 될 수 있어서요.
옆에서 보니 개발자는 빠르게 답을 내는 사람이라기보다, 질문을 잘게 쪼개는 사람에 가까웠습니다. “왜 안 되지?”에서 멈추지 않고 “언제부터 안 됐지?”, “누구에게만 안 되지?”, “어떤 조건에서 반복되지?”를 계속 묻는 식입니다. 일상에서도 이 습관이 튀어나와서, 친구는 식당 키오스크가 멈췄을 때도 버튼을 막 누르지 않고 화면 상태부터 관찰했습니다.
개발자에게 장비는 사치가 아니라 피로 관리였다
개발자 책상도 궁금해서 사진을 몇 장 받아봤습니다. 공통적으로 모니터가 2대 이상이었고, 키보드와 마우스에 꽤 신경을 쓰고 있었습니다. 처음엔 장비 욕심인가 싶었는데, 이야기를 들어보니 이유가 현실적이었습니다.
- 모니터 2대: 코드와 결과 화면을 동시에 보기 위해 사용
- 기계식 또는 저소음 키보드: 손가락 피로와 소음 사이에서 선택
- 노트북 거치대: 목이 앞으로 빠지는 자세를 줄이기 위해 사용
- 손목 받침대: 장시간 타이핑할 때 통증을 줄이기 위해 사용
한 친구는 손목이 아파서 병원에 간 뒤 마우스를 바꿨다고 했습니다. 가격은 7만 원대였고, 처음엔 비싸다고 느꼈지만 한 달 정도 쓰고 나니 손목 저림이 확실히 줄었다고 합니다. 개발자의 장비 이야기는 멋내기보다 ‘하루 8시간 이상 같은 자세로 버티는 법’에 가까웠습니다.
저도 이 얘기를 듣고 집에서 노트북 받침대를 써봤는데, 생각보다 체감이 컸습니다. 화면이 눈높이에 가까워지니까 고개를 덜 숙이게 됐고, 2시간 정도 글을 써도 어깨가 덜 뻐근했습니다. 개발자만의 문제가 아니라 오래 앉아서 일하는 사람이라면 꽤 참고할 만한 부분이었습니다.
야근보다 무서운 건 ‘머릿속에 남은 오류’
개발자 친구들이 공통으로 말한 스트레스는 야근 자체보다 해결되지 않은 문제가 계속 머릿속에 남는다는 점이었습니다. 퇴근을 해도 “그 에러가 왜 났지?”라는 생각이 샤워할 때나 자기 전에 다시 올라온다고 합니다. 실제로 한 친구는 산책하다가 원인을 떠올리고 집에 와서 메모장에 적어둔 적도 있다고 했습니다.
이게 신기하면서도 조금 피곤해 보였습니다. 일반적인 일은 퇴근하면 어느 정도 끊기는 느낌이 있는데, 개발 문제는 퍼즐처럼 남아 있다가 갑자기 튀어나오는 경우가 많다고 하더군요. 특히 오류 메시지가 애매할 때가 제일 답답하다고 했습니다. “안 됩니다”라는 말만 듣고 고쳐야 하는 상황과 비슷하다고 보면 됩니다.
그래서 개발자들은 의외로 기록을 많이 했습니다. 무슨 문제였는지, 어떤 방법을 시도했는지, 결국 무엇이 원인이었는지 적어둡니다. 같은 실수를 줄이기 위한 생활 습관인 셈입니다. 저는 이 방식이 집안일에도 쓸 만하다고 느꼈습니다. 예를 들어 세탁기에서 냄새가 났을 때 언제 청소했는지, 어떤 세제를 썼는지 적어두면 다음에 덜 헤매니까요.
개발자처럼 문제를 다뤄보니 편했던 순간
친구들을 보고 나서 저도 작은 실험을 해봤습니다. 집 와이파이가 자꾸 끊기는 문제가 있었는데, 예전 같으면 공유기를 껐다 켜고 “왜 이래” 하고 말았을 겁니다. 이번에는 개발자처럼 조건을 적어봤습니다. 끊기는 시간, 사용하는 기기, 공유기와의 거리, 전자레인지 사용 여부를 3일 정도 기록했습니다.
그랬더니 밤 10시 이후, 거실이 아니라 방에서만 끊김이 심하다는 걸 알게 됐습니다. 공유기 문제가 아니라 방문을 닫았을 때 신호가 약해지는 쪽에 가까웠습니다. 공유기 위치를 선반 위로 60cm 정도 올리고 방향을 바꿨더니 끊김 횟수가 하루 5~6번에서 1번 이하로 줄었습니다. 엄청난 기술을 쓴 건 아니지만, 원인을 추측으로만 대하지 않은 게 차이를 만들었습니다.
개발자의 사고방식이 꼭 컴퓨터 앞에서만 필요한 건 아니었습니다. 문제를 작게 나누고, 조건을 확인하고, 바꾼 내용을 기록하는 방식은 일상에서도 꽤 쓸모가 있었습니다. 냉장고 소음, 휴대폰 배터리 소모, 청소기 흡입력 저하 같은 문제도 막연히 짜증내기보다 하나씩 따져보면 원인이 보이는 경우가 많습니다.
직업으로서의 개발자, 생각보다 생활형 직업이었다
개발자라는 직업은 밖에서 볼 때 꽤 화려하게 포장되는 편입니다. 높은 연봉 사례도 있고, 재택근무 이미지도 강하고, 노트북 하나로 일하는 자유로운 모습도 자주 보입니다. 그런데 가까이에서 본 개발자는 계속 배우고, 계속 확인하고, 계속 고치는 사람에 가까웠습니다.
물론 장점도 분명했습니다. 만든 기능이 실제 사용자에게 바로 닿는다는 점, 실력이 쌓이면 선택지가 넓어진다는 점, 문제를 해결했을 때의 성취감은 꽤 커 보였습니다. 반대로 단점도 선명했습니다. 기술 변화가 빠르고, 모르는 것을 계속 마주해야 하고, 작은 실수가 큰 장애로 이어질 수 있다는 부담이 있었습니다.
개발자를 꿈꾸는 사람이라면 “코딩이 재미있는가”도 중요하지만 “막힌 문제를 오래 붙잡고 있을 수 있는가”를 같이 생각해보면 좋겠습니다. 제가 본 개발자의 진짜 능력은 천재적인 타이핑 속도가 아니라, 잘 안 되는 상황을 견디면서 원인을 좁혀가는 태도였습니다. 그건 직업을 떠나 일상 속 작은 문제를 다룰 때도 꽤 든든한 기술처럼 느껴졌습니다.
