Showing Posts From

일상

대학 동기들 단톡방: 1년에 한 번 보는 우리의 현재

대학 동기들 단톡방: 1년에 한 번 보는 우리의 현재

대학 동기들 단톡방: 1년에 한 번 보는 우리의 현재 스탠프만 남기는 채팅창 단톡방 알림. 어제 온 거 같은데 이제 봤다. '안녕하세요 ^^' 누구지? 이름이 안 띄어 있다. 멤버 목록을 본다. 13명. 왜 13명이지? 졸업 당시엔 11명이었는데. 아, 누군가의 남편. 아니면 여자친구. 이제 그 정도 사이가 됐구나. 'ㅇㅈㅇㅇ님이 입장했습니다.' '어어어 환영한다 형!!' 이 문장 뒤에 슬랙 이모지가 3개 따라붙는다. 너희도 개발자네. 그 느낌 안다. 회사에서 슬랙에 이모지 스팸하는 그 문화. 여기까진 따라온 거다. 대학 때는 달랐다. 2020년. 코로나 이전. 우리는 학년 올라가면서 자연스럽게 모였다. 학식, 도서관 앞 벤치, 밤새 과제 하는 호실. 2시간마다 카톡으로 '뭐해?' 쓰고, 1분 안에 답장 왔다. 지금은 이거다. 스탠프.'언제 봐?'만 오고 가다 단톡방 검색. 지난 6개월. '언제 봐?' '진짜 봐야겠다' '시간 되면 봐요!' '언제 모여?' '다음 달?' '그 다음 달?' 이 대사들만 15개. 실제로 만난 적? 없다. 작년 명절. 누군가가 '내려간다' 했다. 아, 그때 한 명 봤나? 아니. 그건 전전년도다. 우리는 시간이 없다. 모두가. 금요일 밤. 그게 유일한 기회다. 근데 누구는 배포를 해야 한다고 했다. 누구는 주말에 고쳐야 할 버그가 있다고. 누구는 신입이라 휴가를 못 낸다고. '다음에 진짜 봐' 다음은 언제지? 리더보드를 본다. 채팅 횟수로 순위를 매기는 개발자들만의 오만한 작은 게임이 우리에게도 있었나? 없다. 근데 누가 말을 많이 하는지 본다. 'ㅇㅇ' - 어제 온 스탠프 3개 'ㅈㅇ' - 한 달 전 '안녕' 'ㅎㅅ' - 3개월 전 '요즘 뭐해' 스탠프만 남기는 애들도 있다. 이제 감정 표현도 패킹하는 거네. 최적화. 우리가 배운 게 단톡방까지 왔다. 회사에서 9시부터 6시까지 벨이 9시에 울린다. 9시가 아니라 8시 50분에 나가기 시작한다. '출근한다' 이 한 단어를 누구에게 건넬까? 아내? 아내도 같은 시간에 나간다. 엄마? 엄마는 딸은 신경 쓰고 아들은 알아서 한다고 생각한다. 대학 동기? 아, 그들도 지금 자신의 회사에서 로그인하고 있을 거다. 2023년. 우리는 학교를 나왔다. 그 다음부터가 다항식이었다. 누군가는 대기업 들어갔다. 근데 스트레스 받다가 작년에 스타트업 갔다. 단톡방에 '이직했어요'라고만 적었다. 누군가는 프리랜서가 됐다. '자유롭다'고 했는데, 3개월 뒤에는 '부스러기처럼 산다'고 했다. 누군가는 공무원 된다고 했는데 지금도 시험 치고 있다. 나? 난 동기들보다 좀 더 일찍 들어갔다. 지금 테크 리드다. 직책은 아니지만.공통분모는 한 가지 더 이상 공통분모가 없다. 학교 있을 때 공통분모는 뭐였나. 과제. 시험. 축제. 밥 먹을 때 갈 식당. 서로의 로맨틱한 관심사. 프로젝트 팀. 동아리. 다 외부 강제였다. 제도가 우릴 한곳에 모았다. 지금 공통분모는? "우린 다 개발자야." 그게 다다. 근데 그 안에서도 나뉜다. 프론트엔드 vs 백엔드. Java vs JavaScript. 대기업 vs 스타트업. 계약직 vs 정규직. 우리가 대학에 갔을 때 배운 게 뭔지 생각해본다. 자료구조? 알고리즘? 네트워크? 잘못 배웠다. 우리가 배워야 했던 건 이거다. '떨어져 나가는 방법'. 그래도 가끔 미안한 마음 '형 생일 축하해!' 단톡방에 올라온다. 누가 사실 봤을까? 한 3명. 알람 설정 안 했으니까. 'ㅇㅇ님이 이모지를 보냈습니다' 이모지면 충분하다. 충분해야 한다. 근데 왜 미안한 마음이 생길까. 마치 우리가 함께 늙어가는 게 아니라 각자 다른 타임라인으로 살아가고 있다는 생각이 들 때. 한 명은 서울에서 일하고, 한 명은 경주로 내려가고, 한 명은 리모트다. 한 명은 결혼했다. 한 명은 결혼할 생각이 없다. 한 명은 고민 중이다. 한 명은 승진했다. 한 명은 계약 끝났다. 한 명은 유학 간다고 했는데 아직 가지 않았다. 우린 같은 시간에 태어났다. 같은 학교에 갔다. 근데 시간이 더 이상 같지 않다. 네트워크 에러다. 패킷이 너무 멀리 떨어져 있다. '언제 봐?' 그 이후 어제 카톡이 울렸다. '모임 가능한 사람?' 이 문장이 올 때마다 우리의 심장이 철렁 내려간다. '언제?' '이번 달 25일?' 계산한다. 이번 달. 지금 8월이니까. 8월 25일은? 금요일이다. 그 금요일에 배포가 있나? 없나? 구글 캘린더를 본다. 팀 회의. 스프린트 플래닝. 1:1 미팅. 백로그 정제. '그 날 좀 바쁠 거 같은데...' 누군가는 이미 같은 답을 보냈다. '다음 달?' 대화는 여기서 끝난다. 다음 달은 다음 달이니까. 지금은 생각하지 않는다.그런데도 누구는 왔다 작년 가을. 누군가는 정말 왔다. 단톡방에 사진 올렸다. 우리가 다니던 학교. 정문 앞. '돌아왔다' 그 사진 밑에 반응이 확 달라붙었다. '오오오!!' '어디?? 갈께!!' '너 미쳤나? 왜 와??' 반가운 거였다. 정말로. 그 사람은 미국 출장 갔다가 서울 들었다고 했다. 이틀밖에 없다고 했다. 우리는 만났다. 진짜로. 밥 먹으면서 5년을 말했다. 5시간에 5년을 압축했다. 누가 떠나갔고, 누가 들어갔고, 누가 계속 같은 자리 있고, 누가 변했고, 누가 안 변했고. 그리고 그 사람이 떠날 때 우리는 일렬로 버스 정거장까지 따라갔다. 아무말도 하지 않고. 버스가 떠났다. 그 다음 날 단톡방에 사진이 올라왔다. 비행기 창밖이었다. '또 언제 봐?' 아, 그거요 아, 그거요. 시간이 없어서가 아니다. 시간은 있다. 부족하지 않다. 우리가 두려워하는 건 다른 거다. 만나면 뭘 말해야 하지? 하는 두려움. 회사 얘기만 할 수도 없고. 그 얘기 하면 한 명은 스트레스 받고, 한 명은 자존심 상하고. 연봉이 나올까봐. 직급이 나올까봐. 결혼 얘기가 나올까봐. 아이 얘기가 나올까봐. 전월세 얘기가 나올까봐. 부모님이 아직 돈 달라고 하냐는 얘기가 나올까봐. 우린 모두가 어쨌든 조금씩 불안하다. 그래서 스탠프만 남긴다. 스탠프는 거짓말을 하지 않는다. 미소. 엄지. 불꽃. 더 이상 말할 게 없으니까. 근데 나는 가끔 생각해 만약 우리가 아직도 같은 학교에 있었다면? 과제 같이 하고, 밥 같이 먹고, 밤 10시에 갑자기 누구 기숙사로 모였을 거다. 그런데 우린 여기 있다. 나는 서울에서, 누군가는 대구에서, 누군가는 싱가포르에서, 누군가는 여전히 "취직할 거예요"라고 말하고 있고. 단톡방은 여전히 켜져 있다. 알림은 여전히 울린다. 근데 우린 누구도 댓글을 달지 않는다. 웃음이라도 표현하고 싶을 땐 스탠프를 남긴다. 이게 우리 세대의 우정인가? 아니면 이게 수도권 백엔드 개발자들의 현실인가? 아마도 둘 다. 내일도 같은 알림 내일도 같은 시간에 알림이 울릴 거다. 혹은 주말에. 누군가가 '요즘 뭐해?'라고 쓸 거다. 난 커피를 마시면서 생각할 거다. 뭐라고 답해야 할까? '일해요' 이것만 쓸 거다. 스탠프 하나 붙이고. '다음에 봐' 이렇게 닫을 거다.언제 봐? 모르겠다. 모두가 바쁘니까.

결혼 2년차, 아내와의 개발자 부부 생활

결혼 2년차, 아내와의 개발자 부부 생활

결혼 2년차, 아내와의 개발자 부부 생활 그렇게 야근은 만난다 퇴근 시간이 따로 없다는 건 뭐 하는 말인가. 회사에 나가기 전부터 이미 결정되어 있다. 아내 이수진은 UI 디자이너고, 나 김개발은 백엔드 개발자다. 둘 다 IT 회사. 둘 다 서로 다른 회사. 그런데 오늘따라 야근 문화는 똑같다. 결혼 2년 차가 되니까 알게 된 게 있다. 지인들한테 "아, 개발자랑 디자이너 부부 축하해요"라고 들을 때 정말 감동했는데, 3개월 정도 지나니까 '아, 이게 축하할 일만은 아니구나' 싶었다.월요일 오전 10시. "어제 몇 시까지 있었어?" 하는 인사말로 날이 시작된다. 나는 배포 건으로 10시까지 있었다고 했고, 아내는 "어? 나 11시까진 있었는데?"라고 대답한다. 이게 우리의 일상 인사다. 어떻게 된 일인지 모르겠지만, 한 사람이 퇴근할 때쯤이면 다른 한 사람이 야근 전화를 받는다. 처음 이 생활이 반복되고 1년이 지났을 때, 나는 정말 미칠 뻔했다. 회사에서 스트레스를 받고 집에 와서도 쉬지 못하는 거다. 아내도 디자인 피드백으로 예민하고 있고, 나도 레거시 코드 때문에 모니터를 노려보고 있다. 저녁 8시, 집에는 침묵만 흐른다. 각자 슬랙을 본다. 각자 메일을 확인한다. "밥 먹었어?" "응, 너도?" 이런 식의 대화가 하루의 전부다. 라면 냄새가 나는 밤 아내가 야근이 예정되어 있다고 했던 어느 날. 나는 혼자 집에 남았다. 회사 근처 김치찌개집에서 퇴근한 지 1시간이 안 되는데, 벌써 배가 고팠다. 이쯤 되면 밥을 먹으러 나가는 게 아니라 시간을 보내러 나가는 건 같다. 일단 냉장고를 열었다. 계란 두 개, 파 한 단, 라면 3개. 그리고 나머지는 아내가 아직 손도 못 댄 반찬들. 아내가 주말에 만들어두는 반찬은 나를 위한 배려인데, 정작 함께 먹을 시간이 없어서 냉장고에 처박혀만 있다. 라면을 끓으면서 계란을 풀고 파를 썬다. 냄비에서 치직거리는 소리, 몬순이 올라오는 소리. 이게 내 저녁이다. 맛있는 요리도, 함께할 누군가도 없이 그냥 배를 채우기 위한 밤의 의식.그런데 신기한 거, 아내가 집에 와서 그 라면을 마주칠 때마다 웃는다. "또 라면이야?" 라고 묻지만 웃고 있다. 내가 "그래, 또 라면이야"라고 대답해도 웃는다. 이 웃음이 뭔지 알게 된 건 이제다. 고독하지만, 그 고독 속에서도 누군가를 생각하고 있다는 그 감정이다. 내가 먼저 집에 있을 때는 좀 다르다. 나는 집에 와서 TV를 켜고 누워 있다. 넷플릭스 화면이 보조 모니터처럼 변해버린 지는 언제였을까. 퇴근해서 이것도, 퇴근해서 저것도 하고 싶지 않은데 시간은 자꾸 흘러간다. 그럼 아내가 들어온다. "밥 먹었어?" "냉장고 밥 있잖아." "아, 반찬도 남아있고..." 이런 대화를 나누면서도, 아내는 나를 휙 지나간다. 자기 가방을 던지고, 신발을 벗고, 휴대폰을 본다. 업무 슬랙이 얼마나 쌓였나. 요청 건은 몇 개나 들어왔나. 내일 아침 회의 준비는 되어 있나. 그런 아내의 모습을 보면서 이상하게도 나는 덜 외로워진다. 서로 알기 때문에 나약해질 수 있다 일반인 부부들이 부러워하는 말을 들은 적이 있다. "개발자랑 디자이너라니, 쟤들은 서로의 일을 이해할 수 있겠네"라는 둥, "일이 많으면 서로 도와줄 수 있고 좋겠다"는 둥 말이다. 반은 맞고 반은 틀렸다. 아내가 야근하는 날, 나는 그 이유를 안다. 클라이언트가 갑자기 UI를 바꿔달고 했거나, 디자인 시스템 문서를 다시 정리해야 했거나, 개발팀과의 협의가 자꾸 꼬인 거거나. 나는 이런 상황들을 정확히 안다. 내 직업에서도 매일 일어나니까. "어? 나도 이런 일을 당하잖아" 이렇게 생각하면서 아내에게 공감을 건넨다. 그냥 말로만 하는 공감이 아니다. 피부로 느끼는 공감이다. 그런데 문제는, 이 공감이 때로는 둘 다를 나약하게 만든다는 것이다. "이거 봐, 기획자가 또 마지막 날에 요구사항을 바꿨어." "어? 우리 PM도 그랬거든. 완성했다고 생각했는데 '아, 그런데 이것도 해야겠는데?'라고." 이런 식으로 불만을 나누다 보면, 그게 위로가 되는 동시에 서로의 스트레스를 증폭시킨다. 공감이 공명이 되는 거다. 우리 둘 다 최악의 상황을 경험하고 있다는 확인이 오히려 답답함을 키운다. 그럼 이건 뭐할까? 쿠션처럼 작동해야 할 배우자가 같은 난로에 있는 불장난이 되어버리는 거다.그런데 웃긴 일이 생겼다. 2년 차에 접어들면서, 우리는 어떤 방식을 터득했다. "야, 오늘 하루는 그냥 아무 말도 하지 말자." 이 말이 나올 때마다 우리는 웃는다. 웃고 있지만 진지하다. 업무 얘기는 하지 말고, 서로가 일으킨 스트레스에 대해 공명하지 말고, 그냥 침묵 속에서 함께 있자는 뜻이다. 그리고 가끔, 정말 가끔 아내가 나를 본다. "개발자 공부하는 거 봤어. 좋아 보이더라." 이렇게 나의 사이드 프로젝트를 먼저 챙기거나, 나도 그렇게 한다. "그 디자인 포트폴리오 사이트, 예뻤어." 이런 식으로 서로의 작은 노력을 본다. 누군가는 이걸 당연하다고 할지도 모르지만, 둘 다 출장지에서 야근하는 생활을 하는 입장에선, 상대방의 사이드 프로젝트를 봐줄 여유가 생긴다는 것만으로도 고마운 일이다. 결국은 옆에 있다는 것 나는 솔직하게 말할 거다. 개발자 부부 생활이 로맨틱한 건 아니다. 집에 와서도 각자의 모니터를 본다. 침실에서 자기 전까지도 휴대폰 화면을 본다. 주말에는 늦잠을 자지만, 평일에는 서로 다른 시간에 출근하고 다른 시간에 퇴근한다. 만약 모두가 9시 출근 6시 퇴근이라면, 주말에 함께할 시간도 많겠지만, 우리는 그렇지 않다. 그렇지만 남은 것이 있다. 라면을 끓을 때, 아내가 온다는 걸 알고 있어서, 나는 두 그릇을 준비한다. 한 그릇은 내 것이고, 한 그릇은 그 언젠가 아내가 늦게 와서 먹을 것이다. 그러다가 아내가 집에 일찍 온 날이면, 그 라면이 두 사람이 먹는 대신 냉장고에 들어간다. 그것도 좋다. 왜냐하면 아내가 이제 있을 거니까. 기획자가 또 마지막 날에 요구사항을 바꾸면, 나는 한숨을 쉰다. 그리고 아내가 같은 한숨을 쉬고 있다는 걸 느낀다. 그럼 우리는 침묵한다. 말이 필요 없다. 그 침묵 속에서도 '난 너를 알아'라는 신호가 오간다. 주말에 치킨을 시킬 때, 나는 한 마리를 시키지 않는다. 아내가 조각을 집어갈 걸 알고 있으니까. 아내는 "야, 너 혼자 다 먹어도 돼"라고 말하지만, 우리는 모두 알고 있다. 그 말은 표면의 말일 뿐이다. 이게 개발자 부부 생활의 핵심이다. 일이 많고, 야근이 많고, 때론 침묵이 집을 채운다. 하지만 그 모든 것을 견딜 수 있는 건, 상대방이 나와 같은 고민을 하고 있다는 걸 알고, 그래도 옆에 있다는 걸 느끼기 때문이다. 나는 출장 가는 날, 아내에게 슬랙을 보낸다. "야, 밥은 먹어?" 아내도 답한다. "응, 너도 뭐 좀 먹고 자." 이 메시지는 8글자도 안 되지만, 이건 '난 네가 어디에 있든 너를 생각하고 있어'라는 뜻이다. 우리의 사랑의 언어는 업무 얘기가 아니라, 끼니를 챙기는 것이다. 개발자 부부 생활? 별로 로맨틱하지 않다. 하지만 누구보다 솔직하고, 누구보다 따뜻하다. 우리는 밤 11시에 집에 도착해서, 난로 옆에 앉은 것처럼 서로를 데운다. 전자기기의 불빛 속에서 말이다. 그리고 내일도 또 다시, 각자의 야근 문화는 만난다. 결국 가장 좋은 건, 누가 먼저 오든 라면을 함께 끓일 수 있다는 거 아닐까.

아내가 야근하는 밤, 혼자 라면을 끓이며 생각한 것

아내가 야근하는 밤, 혼자 라면을 끓이며 생각한 것

아내가 야근하는 밤, 혼자 라면을 끓이며 생각한 것 저녁 8시 47분. 슬랙 메시지가 울렸다. 아내였다. "디자인 수정 요청 또 들어왔어. 늦을 것 같아 :(" 아. 또 그 시간이구나. 휴. 나는 모니터를 꺼고 의자에서 일어났다. 회사 근처 편의점 가면서 휴대폰으로 "밥 뭐 먹을까" 검색해봤는데, 깊은 밤에 나 혼자 밥을 챙겨먹는다는 게 좀 이상했다. 미안한 마음도 들었고. 그냥 라면 사 왔다. 신라면과 진라면 중에 고민하다가 신라면으로. 아내는 매운 거 잘 못 먹으니까, 이건 순전히 내 선택이다.혼자가 된 주방의 감정 기복 집에 돌아와서 냄비에 물을 부었다. 가스불을 켰다. 이 순간이 가장 낯설다. 보통 우리는 함께 집에 들어온다. 아내가 "오늘 뭐 먹을까?" 하고, 나는 "뭐든 좋아" 하고, 그러면 아내가 "좀 구체적으로 말해" 한다. 그 루프. 근데 오늘은 그 대화가 없다. 물이 끓으면서 김이 피어오르는데, 혼자 서 있는 주방이 유독 크게 느껴진다. 냄비 옆에 아내의 멀티탭 정리기 같은 거 보이고, 냉장고 문에 붙은 우리 둘이 찍은 사진 보인다. 여행 가서 찍은 거였나. 1년 전? 2년 전? 기억이 안 난다. 라면을 끓이면서 생각한 것들: "밥을 해야 하나?" - 라면만 먹어도 괜찮지 않나? 밥까지 하면 너무 번거롭지 않나? 근데 밥 없이 라면만 먹는 게 좀 이상하지 않나? 아내 귀가했을 때 "저 혼자 라면만 먹었어" 라고 말하면 뭐라고 할까? "야근이 많은 아내가 나한테서 뭘 기대하나?" - 내가 밥을 해놓고 있었으면 좋았을 텐데. 근데 오늘 배포일이었잖아. 코드 리뷰도 많았고. 내가 야근하는 날은 아내가 라면을 끓이는데, 그럼 아내가 야근하는 날은... 나도 뭔가를 챙겨야 하는 건 아닐까? "우리가 이렇게 살기로 한 건가?" - 신혼집에 와서 가장 많이 들은 말이 "집을 좀 챙겨야 하지 않나?" 였는데, 난 여전히 회사만 챙기고 있다. 아내의 야근이 길어질수록, 내가 라면을 끓일 때마다 이 질문이 자꾸 떠오른다.슬로우 라이프는 꿈이고, 우린 패스트푸드의 주인 라면이 끓는 동안 나는 생각했다. 요즘 유튜브에 자주 떠오는 영상들 말이다. "조용하고 평화로운 일상" 이런 거. 영상 속 주인공은 보통 시골에 작은 집을 짓고, 정성스럽게 밥을 짓고, 밤에는 촛불 아래 책을 읽는다. 가끔 그런 삶에 끌려본다. 심지어 댓글도 "이런 삶을 살고 싶어요" 로 가득 찬다. 근데 현실은 어떤가. 난 7년 차 백엔드 개발자고, 아내는 UI 디자이너다. 우린 서울에 작은 전세를 얻고 살고 있다. 그 전세금도 부모님 도움으로 겨우 마련했다. 정성스러운 밥은커녕, 우리 저녁의 대부분은 "이거 간단하게 먹을까?" 로 시작된다. 화요일 점심? 회사 근처 김치찌개집. 목요일? 배달음식. 금요일? "아 오늘은 치킨 시킬까" 가 뭔가 특별한 일처럼 느껴진다. 주말 아침? 늦잠 자고 두 시간 뒤에 치킨. 이게 우리의 삶이다. 그런데 문제는, 이게 싫다고 느껴지면서도 바꿀 에너지가 없다는 거다. 후배 PR 리뷰하고, 슬랙 알림에 정신없고, 주말에도 "혹시 모르니까" 노트북을 켜둔다. 아내는? 밤 11시에 "마진 수정이 또 나왔대" 하고, 자정이 넘어서 "이제 끝났어" 한다. 우린 정성스러운 밥을 지을 여유가 없는 사람들이다. 그래서 라면이다. 라면은 8분이면 된다. 신라면이 끓는 동안 나는 다른 생각을 할 수 있다. 예를 들면, "내가 이렇게 살아도 되나?" 이런 생각들. 밥 대신 라면을 선택하는 순간, 그게 책임감인가 미안함인가 물론 나도 안다. 아내가 들어왔을 때 밥이 있으면 좋겠다는 걸. 따뜻한 국과 반찬이 있으면, 아내가 "오, 고마워" 하면서 얼굴이 부드러워질 거 같다. 근데... "근데"가 문제다. 회사에서 배포일이었다. 배포일은 언제나 예측 불가능이다. 8시에 끝날 줄 알았는데 9시까지 간다. 이틀 전부터 "내일 배포 있으니까 좀 일찍 집에 갈게" 라고 말해놓고도, 정작 배포날 오전 9시에 "어? 이게 왜 이래?" 하면서 시작된다. 그 와중에 아내는 밥 준비할 생각을 해야 하나? 아니다. 그 정도의 여유는 없다. 그래서 라면이 합리적인 선택지가 된다. 아내가 야근하는 걸 어쩔 수 없으니까, 나도 자기 밥이라도 챙기자는 마음으로. 근데 이게 정말 책임감일까? 아니면 그냥 무책임함의 다른 표현일까? 가끔 생각해본다. "밥을 해야 하나?" 라는 질문은 사실 "내가 가정에 대해 뭘 해야 하나?" 라는 더 큰 질문의 축소판인 거 같다. 밥 하나 못 하면서 무슨 남편이냐고 생각할 때도 있다. 근데 또 다시 생각해보면, 난 지금 이 순간도 피곤하다. 일도 많고, 머리도 복잡하고, 뭔가를 결정할 에너지가 남아있지 않다.결국 우린 서로에게 미안해하는 사람들이다 밤 11시 32분. 아내가 집에 들어왔다. "오..." 하면서 신발을 벗었다. 피곤한 목소리였다. "라면 먹었어?" 라고 물었다. "응. 너는?" 이라고 대답했다. 아내는 "회사에서 라면 먹었어" 라고 했다. 둘 다 라면이었다. 그 순간, 정말 이상한 감정이 들었다. 미안했다. 왜? 정확하게는 모르겠다. 아내가 회사에서 라면을 먹으면서까지 일을 했을 거고, 나도 집에서 라면을 먹으면서 자기 자신을 챙겼고 (라고 생각했고), 우리 둘 다 피곤해서 아무것도 제대로 챙길 수 없었다는 게 미안했던 것 같다. "내일 좀 일찍 들어올 수 있어?" 라고 아내가 물었다. 내일도 배포가 있나? 아. 없긴 한데, 후배 오인턴이 새로운 모듈을 올렸고, 코드 리뷰를 해야 한다. "아마도?" 라고 대답했다. 아내는 웃었다. "뭐 하나 제대로 안 되네" 라고. 그건 우리 둘 다를 비난하는 게 아니었다. 우린 이런 사람들이니까. 계획해도 안 되는 사람들. 라면 끓일 때마다 "밥도 해야 하지 않을까?" 고민하는 사람들. 내가 "밥 먹을래?" 라고 물었다. 아내는 "그냥 좀 누워있고 싶어" 라고 했다. 나도 알겠다. 그 피곤함. 밥을 해야 하는데, 밥을 하려면 장을 봐야 하고, 준비를 해야 하고, 씻어야 하고... 그 모든 과정이 산처럼 느껴지는 그 피곤함. 라면 한 그릇의 철학 결국 이거다. 우리는 라면 끓이는 수준의 인생을 사는 사람들이다. 8분이면 된다. 깊이 생각할 필요가 없다. 물 끓이고, 면 넣고, 스프 넣고, 계란 삶은 거 넣고, 파 올리고, 먹는다. 그게 끝이다. 반대로 밥은 복잡하다. 밥을 준비하려면 마음가짐부터 다르다. "오늘 뭘 할까" "반찬은 뭐로 할까" "누가 먹을까" 이런 식으로. 밥은 누군가를 생각하는 음식이다. 라면은 나를 생각하는 음식이다. 근데 결혼했으니까, 밥을 해야 하는 거 아닐까? 난 계속 이 질문의 루프에 빠진다. 매번 아내가 야근하는 밤, 라면을 끓이면서. "좀 더 성숙해져야 하나?" 라는 생각도 든다. 다른 남편들은 어떻게 할까? 아내가 야근하는 밤, 밥을 해두고 반찬까지 챙기고 있을까? 난 못하는 게 당연한가? 아니면 나만 못하는 걸까? 혼자가 아니라는 확인 그런데 아내가 "고마워" 라고 했다. 왜 감사의 말을 했을까? 나는 뭘 한 거도 아닌데. 그냥 라면을 끓였을 뿐인데. "뭐가?" 라고 물었다. 아내는 "뭐든. 혼자가 아니라서. 함께 있어서" 라고 했다. 아. 그게 그 말이었구나. 우리는 둘 다 바쁘다. 우리는 둘 다 피곤하다. 우린 둘 다 밥을 챙길 여유가 없다. 그래서 둘 다 라면을 먹는다. 회사에서 하나, 집에서 하나. 하지만 적어도 우린 같은 시간대에, 같은 음식을 먹고 있었다. 그리고 그 사실만으로도, 혼자가 아니라는 걸 확인하는 거였다. 밥을 해야 한다는 미안함과 라면을 끓여야 한다는 현실 사이에서, 우린 그렇게 함께하고 있었다. 완벽하지는 않지만, 그래도 옆에 있다는 것. 그 밤, 나는 라면 국물을 마시면서 생각했다. "내일은 밥을 해야겠다" 고. 하지만 그 생각도 마음속 어딘가에서는 알고 있었다. 내일도 무언가는 일어날 거고, 내일도 우린 바쁠 거고, 내일도 라면을 끓일 수도 있다는 걸. 그래도 괜찮을 거라는 걸. 왜냐하면, 우린 함께니까.결국 밥인지 라면인지는 중요하지 않았다, 옆에 있다는 것 하나면 충분했다.

회의 중에 노트북으로 딴 짓하는 척 코드 보는 기술

회의 중에 노트북으로 딴 짓하는 척 코드 보는 기술

회의 중 노트북으로 딴 짓하는 척 코드 보는 기술: 개발자의 이중생활 가이드 프롤로그: 슬랙 알림과 함께 시작되는 악몽 월요일 오전 10시, 평화로운 개발 시간이 끝난다. 슬랙에 떴다. "다들 회의실로 모여주세요. 분기별 로드맵 공유 회의입니다." 심장이 철렁 내려앉는다. 로드맵 공유? 1시간은 족히 걸린다. 기획자는 항상 '이건 빠르게 끝낼 거예요'라고 하지만, 실제로는 파워포인트의 각 슬라이드마다 10분씩 설명한다. 그사이 서버에서는 뭔가 돌아가고 있다. 어제 배포한 API의 응답 시간이 괜찮은지, Redis 캐시가 제대로 워밍업됐는지, 에러 로그에 뭔가 쌓여있지 않은지. 회의실에 들어가는 순간, 그 모든 게 나를 부르고 있는 것 같다. 아, 그래서 우리는 이 기술을 터득했다. 회의 중에 노트북으로 딴 짓하는 척 코드 보는 기술. 7년 경력 개발자인 나도 처음엔 서툴렀다. 회의 중 슬랙을 봤다가 팀장한테 "김개발, 뭐 하냐?"라고 들었다. 기획자 앞에서 IDE 창을 켜려다가 키보드 백라이트가 반짝여서 눈에 띴다. 하지만 지금은 다르다. 이건 단순한 기술이 아니라, 생존 기술이다.회의의 정체: 우리가 피할 수 없는 현실 먼저 인정해야 할 것이 있다. 모든 회의가 쓸모없진 않다. 그런데 우리가 참석하는 대부분의 회의는... 음, 쓸모없다. 우리 회사 달력을 보면 이해할 수 있다:월요일 조회: "이번 주 계획을 얘기하는" 회의인데, 결국 지난주 결과를 재탕한다 수요일 동기화: "크로스펑셔널 커뮤니케이션"이라는 명목의 30명 대회의, 내가 할 말은 없다 목요일 회고: 아직도 회고가 끝나지 않았다는 게 신기하다 금요일 플래닝: 점심 때문에 자리를 비운 사람이 반 이상이다그리고 여기 추가로, 갑자기 소집되는 기획 회의들. "개발팀이 빨리 끝낼 수 있을 것 같아서요"라는 말과 함께. 요청사항은 언제나 간단해 보인다. "그냥 이거 버튼 추가해 주시고, 데이터베이스에 컬럼 하나만 더하면 되겠네요?" 그런데 나는 안다. 그 "버튼 하나"가 얼마나 많은 것들을 건드리는지. 마이그레이션, 롤백 전략, 캐시 무효화, 테스트 케이스... 아무도 이걸 모른다. 그래서 회의 중에 나는 코드를 본다. 실제로 그 "버튼 하나"를 어디에 어떻게 붙일지 생각하면서, 동시에 기획자의 말을 들었다는 척한다. 이건 이중생활이 아니라 생존 기술이다. 기본기: 외적 완벽성의 추구 이 기술의 핵심은 한 가지다. 보이는 것이 전부다. 처음 시작할 때 실수하기 쉬운 부분부터 말하자면: 1단계: 각도 조절의 중요성 노트북 화면을 옆 사람이 볼 수 없도록 해야 한다. 각도는 약 45도가 최적이다. 정면에 가까워지면 정신을 차리고 있는 것처럼 보이고, 너무 누우면 진짜 딴짓하는 것처럼 보인다. 45도에서는 "열심히 정리하고 있는 척"하는 완벽한 각도가 된다. 내 팀의 시니어 개발자 이준호는 이걸 마스터한 사람이다. 그의 노트북은 항상 기울어져 있고, 카메라가 정면을 향하고 있으며, 그의 손은 언제나 마우스패드나 트랙패드 근처에 있다. 누군가 다가올 때면 갑자기 손을 이동시켜서 "아 이거요"라고 대응할 수 있는 준비 자세를 유지한다. 2단계: 표정과 제스처 코드를 보면서 이 표정을 지켜야 한다:미간에 조금의 주름이 있어야 한다 (생각하는 모습) 눈은 화면에 집중하되, 2분마다 한 번씩 회의 진행자를 본다 마우스를 매 30초마다 움직인다 (살아있는 커서) 가끔 고개를 끄덕인다이건 마치 배우가 역할을 하는 것처럼 보일 수도 있지만, 실제로는 우리 뇌의 일부가 진짜 회의를 듣고 있다. 기획자가 "이 기능의 우선순위는?"이라고 나에게 질문을 던지면, 우리의 뇌는 동시에 여러 스레드를 실행한다: Thread 1: Redis 응답 시간 분석 Thread 2: 기획자의 말 파싱 Thread 3: "아 그거요"라는 말이 자연스러울지 판단 Thread 4: 다음 슬라이드 준비다중 작업 처리 능력이 정말로 개발됐다. 3단계: 음성 신호 "음", "네", "맞아", "그렇네" 같은 짧은 음성 신호를 정기적으로 발생시킨다. 이건 피드백이다. 아무말도 하지 않으면 이상하다. 하지만 너무 자주 말하면, 회의에 다른 사람들이 자신에게 말을 걸어야겠다는 신호가 된다. 최적의 주기는 약 1분 30초에 한 번. 회의가 진행되고 있고 누군가 발표하고 있을 때, 나는 코드 리뷰를 열어본다. 어제 PR에서 한 후배가 올린 커밋을 본다. "왜 이 부분에서 Optional을 사용했지? NPE 가능성이 있는데..."라고 생각하면서 동시에 "정확해요"라고 중얼거린다. 이건 회의에도 참여하는 것처럼 보이고, 실제로는 기술 부채를 갚고 있는 중이다.심화 기술: 다양한 회의 상황별 가이드 모든 회의가 같지는 않다. 각 상황에 맞는 전략이 필요하다. 기획 회의 (위협 레벨: 매우 높음) 기획자가 발표하는 회의는 가장 위험하다. 자신이 준비한 것을 보여주는 상황이기 때문에, 기획자는 누가 집중하고 있는지 본능적으로 감지한다. 마치 고양이가 움직임을 감지하듯이. 이때는 깊은 참여가 필요하다. 노트북을 너무 많이 사용할 수 없다. 대신 그림을 그려야 한다. 종이에, 기획 내용을 다이어그램으로 그린다. 이건 매우 영리한 방법이다. 왜냐하면:기획자 입장에서 보면 "오, 이 개발자는 내 말을 정말 진지하게 받아들이고 있네?"라고 생각한다 실제로는 우리는 그리면서 기술적 구현 방법을 생각하고 있다 나중에 "여기 이 부분은 기술적으로..."라고 말할 때 그림이 있으니까 권위 있어 보인다내 노트북 옆에는 항상 A4 종이와 펜이 있다. 기획 회의 직후 휴지통에 들어가는 그 다이어그램들. 하지만 그건 훌륭한 투자다. 기획자의 신뢰를 얻고, 동시에 기술 분석까지 하는 일석이조의 효과. 스탠드업 회의 (위협 레벨: 낮음) 스탠드업은 가장 쉽다. 왜냐하면 다들 서 있기 때문이다. 앉아서 노트북을 할 수 없다. 이때는 진짜로 슬랙을 본다. 아무도 상관하지 않는다. 회고 회의 (위협 레벨: 중간) 여기는 감정이 섞여있다. 좋은 것도 있고, 개선해야 할 것도 있다. 이때 노트북을 사용하면 "저 사람 이미 다음 스프린트 생각해?"라는 인상을 줄 수 있다. 좋은 인상이다. 실제로 나는 항상 회고 회의 중에 다음 스프린트 백로그를 정리한다. 이건 회의의 목적과도 맞는다. CEO 타운홀 (위협 레벨: 극도로 높음) 모든 직원이 참석하는 회의다. CEO가 발표한다. 이때는 절대 노트북을 켤 수 없다. 왜냐하면 회의실 전면의 스크린에 참석자 명단이 떠 있거나, 누군가가 녹화를 하고 있기 때문이다. 이때는 핸드폰을 본다. 그리고 손에는 메모지를 든다. 메모지에는 아무것도 쓰지 않는다. CEO 발표는 항상 비슷하다. "올해는 AI 기술에 집중합니다", "고객 만족도를 높여야 합니다", "비용 절감을 목표로 합니다". 우리 개발팀은 안다. 이게 뭘 의미하는지. 더 짧은 마감시간으로 더 많은 기능을 만들라는 뜻이다. 도구와 준비물: 프로 설정 이 기술을 제대로 하려면 환경 설정이 중요하다. 노트북 세팅 내 MacBook Pro는 전술적으로 배치되어 있다:배경화면: 회사 프로젝트 이름이 있는 네이비 + 회사 로고. 너무 개인적이면 의심받는다 독(Dock): 일 관련 앱만 보이도록. Slack, IDE, 브라우저, 노션 데스크탑: 깔끔하게. 파일이 많으면 산만해 보인다 키바인딩: 빠른 전환을 위해 커맨드+탭을 마스터해야 한다회의 5분 전에, 나는 이 루틴을 한다:IDE 열기 → 어제 작업하던 브랜치 열기 Datadog 또는 NewRelic 열기 (서버 모니터링) 슬랙 음소거 (슬랙 핑 소리만 들으면 회의 집중력이 떨어진다) 밝기 조절 (너무 밝으면 눈에 띈다)추가 도구외장 마우스: 트랙패드보다 자연스럽다. 손가락으로 탭탭 거리는 것보다 마우스를 들었다 놨다 하는 게 더 "일하는 느낌"을 준다 종이와 펜: 위에서 언급했듯이, 기획 회의에서 필수 헤드폰: 회의 직후 슬랙 메시지를 받을 때 사용. 회의 중에는 안 쓴다. 회의에 참여하지 않는 것처럼 보인다 커피/물: 들었다 놨다를 반복하면 "바쁜 사람" 이미지를 준다윤리적 경계선: 우리는 완전히 나쁘지만은 않다 여기서 중요한 걸 말해야 한다. 이 기술은 악의는 아니다. 예를 들어, 내가 어제 배포한 마이크로서비스의 응답 시간이 평소보다 300ms 높아졌다면? 나는 회의 중에 그걸 봐야 한다. 왜냐하면 사용자가 경험하는 시간이 증가하고 있기 때문이다. 이건 긴급하다. 회의보다 우선순위가 높다. 또는 후배가 올린 PR에서 심각한 SQL injection 취약점을 발견했다면? 나는 회의 중에 코멘트를 남겨야 한다. 왜냐하면 그게 프로덕션에 들어가면 회사 데이터가 위험해지기 때문이다. 그런데 그게 아니라면? 예를 들어, 회의는 진짜 중요하고, 내 의견이 필요한 상황이라면? 그럼 노트북을 덮어야 한다. 이건 기술의 올바른 사용법이다. 내 경험상, 회의의 80%는 정말로 불필요하고, 20%는 정말로 중요하다. 문제는, 시작할 때 어느 것인지 모른다는 것이다. 그래서 우리는 이 기술을 개발했다. 처음 10분은 준비 자세를 유지하다가, 정말로 불필요하다는 것을 확인한 후에 코드를 본다.실제 상황: 회의 중 코드로 문제를 푼 날들 이 기술이 정말로 가치를 발휘한 순간들이 있다. 사건 1: 쿼리 최적화가 필요했던 날 분기 기획 회의 중이었다. 기획자가 새로운 대시보드 기능에 대해 설명하고 있었다. "사용자별 통계를 실시간으로 볼 수 있는 기능입니다." 내 뇌는 두 가지를 동시에 생각했다:기획 내용 파싱: "리얼타임 대시보드, 차트 표시, 필터링" 기술 부채 감지: "어제 배포한 사용자 통계 쿼리가 30초 걸렸는데..."그래서 나는 조용히 IDE에서 그 쿼리를 열었다. 회의가 진행되는 동안, 내 손은 인덱스를 추가하고 있었다. 그리고 로컬에서 다시 실행했다. 3초. 회의가 끝났을 때, 기획자가 물었다. "김개발, 이 기능 구현 난이도는?" 나는 대답했다. "쿼리 최적화가 필요한데, 제가 이미 일부를 테스트했습니다. 내일까지 프로토타입을 만들 수 있을 것 같아요." 기획자의 표정이 밝아졌다. 나는 "진짜로 집중하고 있었나봐"라는 인상을 주었다. 실제로는 회의 중 거의 모든 개발을 끝낸 것이다. 사건 2: 후배의 실수를 회의 중에 발견 월요일 회의에서, 지난주 배포 리뷰를 하고 있었다. 팀장이 "배포가 순조롭게 진행되었다"고 얘기했다. 나는 슬랙에서 배포 로그를 봤다. 그리고 발견했다. 후배가 올린 코드에서 트랜잭션 롤백이 제대로 설정되지 않았다. 데이터베이스 연결이 끊기면 부분 처리된 데이터가 남아있을 수 있는 상황이다. 나는 회의가 끝나고 즉시 PR을 닫고, 후배를 불러서 설명했다. "다음 배포에서 이 부분을 수정해야 해. 지금은 문제 없지만, 트래픽이 증가하면 이슈가 터질 거야." 후배는 고마워했다. 만약 회의 중에 코드를 보지 않았다면, 이 버그는 한두 달 뒤에 프로덕션에서 터졌을 것이다. 사건 3: 기획자의 불가능한 요청을 기술적으로 거절하기 "이 기능 이번 스프린트에 가능할까요?" 기획자의 질문에, 나는 노트북으로 현재 진행 중인 작업들을 확인했다. 동시에 기획자가 설명하는 새 기능의 복잡도를 머릿속으로 계산했다. 스토리 포인트: 13 (충분히 크다) 현재 용량: 32 포인트 (이미 꽉 참) 남은 포인트: 5 "아, 이번 스프린트에는 용량이 부족할 것 같습니다. 다음 스프린트는 어떨까요?" 기획자는 동의했다. 왜냐하면 나는 "아무래도 어려울 것 같은데"가 아니라, 구체적인 포인트와 이유로 설명했기 때문이다. 회의 중에 노트북으로 정보를 수집했기에 가능했던 일이다. 주의할 점: 들킬 수도 있다 사실 이 기술에도 리스크가 있다. 리스크 1: 카메라 요즘은 온라인 회의가 많다. 화상 회의에서는 카메라가 활성화되어 있다. 내 화면이 보이지는 않지만, 내 손과 시선이 보인다. 이때는 매우 조심해야 한다. 눈이 화면을 본다면, 사람들은 내가 뭘 보고 있는지 궁금해한다. 해결책: 화상 회의 중에는 덜 한다. 또는 화면을 공유하는 사람의 스크린을 보는 척하면서 동시에 폰으로 슬랙을 본다. 리스크 2: 팀장 우리 팀장은 "이 회의 필요해?"라는 타입이다. 즉, 회의를 싫어한다. 그런데 회의는 여전히 많다. 회의 중에 내가 코드를 본다는 것을 알지만, 팀장은 나한테 뭐라고 하지 않는다. 왜냐하면 팀장도 회의 중에 이메일을 본다. 우리 회사 문화는 "정직한 불만족"을 허용한다. 일이 불가능하면 불가능하다고 말한다. 회의가 불필요하면 불필요하다고 말한다. 그 대신 권장사항은, 회의를 최대한 짧게 만드는 것이다. 리스크 3: 진짜로 필요한 의견이 필요할 때 가끔 기획자가 정말로 기술 의견이 필요한데, 나는 화면만 보고 있다. 이때 순간적인 반응 시간이 0.5초 길어진다. 이건 매우 어색해 보인다. "어라, 왜 대답이 없지? 아, 화면 보고 있구나" 이런 생각을 하게 된다. 그래서 나는 중요한 회의는 정말로 집중한다. 처음부터 끝까지. 이건 신뢰 관계다. 더 깊은 고민: 이게 맞는 걸까? 요즘 들어 이런 생각이 든다. 정말로 회의가 필요 없는 걸까, 아니면 내가 회의 문화에 적응하지 못하는 걸까? 아니다. 회의는 정말로 필요 없다. 우리 회사는 3일마다 "동기화" 회의를 한다. 동기화? 우리는 슬랙에서 이미 동기화되어 있다. 하지만 인간관계가 필요하다고 생각한다. 그래서 회의가 있다. 인간관계를 원하면서, 동시에 "회의는 쓸모없다"고 느끼는 우리의 이중성. 이건 현대 업무 문화의 모순이다. 하지만 현실은 현실이다. 그래서 우리는 이 기술을 계속 사용할 것이다. 회의 중에 코드를 본다. 동시에 회의에 참여하는 척한다. 이건 악의 없는 생존 전략이다. 그리고 언젠가, 누군가가 "회의 시간을 50% 줄여봅시다"라고 제안할 때, 우리는 손을 들고 동의할 것이다. 하지만 그때까지는, 우리의 이중생활이 계속된다. 에필로그: 내일도 같은 방식으로 오늘 오후에도 "긴급 기획 회의"가 있다. 새로운 스타트업 파트너의 API 연동에 대한 것이다. 기획자는 "30분만 할 거예요"라고 했다. 30분. 나는 이 말을 이제 믿지 않는다. 그래서 노트북을 준비했다. IDE도, 모니터링 대시보드도, PR 리스트도 모두 준비했다. 그리고 준비했다. "이거 구현할 때 이쪽에서 이렇게 해야겠네"라는 생각을 하면서, 동시에 기획자의 말을 듣는 준비를. 이건 개발자의 숙명이다. 우리는 이런 회의들과 함께 살아간다. 그리고 우리는 이렇게 생존해왔다. 내일 또 다른 회의가 있을 것이다. 그리고 나는 또 다시 노트북으로 코드를 볼 것이다. 외적으로는 회의에 참여하면서, 내적으로는 코드와 함께. 이게 우리의 이중생활이다. 그리고 이제는 이것이 자연스럽다.결국 회의는 피할 수 없지만, 회의 중 코드는 피할 수 있다는 게 우리의 비밀이다.

레거시 코드와의 전쟁: 언제까지 봐줘야 하나

레거시 코드와의 전쟁: 언제까지 봐줘야 하나

레거시 코드와의 전쟁: 언제까지 봐줘야 하나 월요일 아침, 또 시작된다 월요일 9시. 커피를 마시며 슬랙을 확인하는 순간, 그 메시지가 떴다. "개발팀, 어제 결제 모듈에서 버그 발생. 긴급 조치 필요!" 한숨을 쉬며 코드베이스로 향한다. 이미 알고 있다. 이 버그는 5년 전 누군가가 만들어놓은 레거시 코드 속에 깊이 박혀있을 것이다. 급히 작성되었을 거다. 커밋 메시지는 아마 "fix: payment bug" 정도. 당시 개발자는 이미 떠났고, 남은 건 주석 없는 코드 덩어리뿐이다.나는 7년을 이 회사에서 보냈다. 그 세월이 얼마나 길었는지는 내가 얼마나 많은 다른 사람의 코드를 봤는가로 측정된다. 입사했을 때 이미 레거시였던 것들, 3년 전에 다시 레거시가 된 것들, 내가 작성했다가 이제는 남이 보기엔 레거시인 것들... 이 모든 게 뒤섞여 있다. "김개발님, 이거 어디 고쳐야 해요?" 후배 정호가 물어본다. 나는 모니터를 보면서 펜을 돌린다. 그 동작은 이미 무의식적이다. 생각할 시간이 필요하다. 코드를 이해할 시간이 아니라, '이 코드를 어떻게 설명할 것인가'에 대한 시간이다. 레거시 코드란 무엇인가 정확히 말하면, 레거시 코드는 "이전 개발자가 작성한 코드"를 뜻하지 않는다. 사실 더 정확한 정의는 "테스트되지 않은 코드"이다. 그리고 대부분의 경우, 그 코드가 작성된 배경을 알 수 없는 코드다. 우리 회사의 결제 모듈은 2017년에 작성되었다. 당시 개발자는 신입이었을 거다. 마감이 촉박했을 거고, 리뷰는 제대로 안 됐을 거다. 그렇게 탄생한 코드가 이제 회사의 심장 부분이 되어버렸다. // payment_module_2017.java - 이런 식의 주석뿐 public class PaymentProcessor { public void processPayment(String userId, String amount, String type) { // TODO: refactor this later if(type.equals("CARD")) { // ... 50줄의 복잡한 로직 } else if(type.equals("ACCOUNT")) { // ... 30줄의 비슷한 로직 } else { // ??? } } }이런 코드를 보면 정말 묘한 감정이 든다. 분노? 아니다. 그것보다는... 안타까움? 아니, 동정심인가? 저 코드를 쓴 사람도, 나처럼 야근하고 있었을 거다. 그 사람도 "나중에 리팩토링하겠지" 하고 있었을 거다. 하지만 "나중"은 절대 오지 않는다. 긴급 이슈의 악순환 "긴급"이라는 단어만큼 개발자를 좌절시키는 단어가 있을까. 지난 3개월간 나의 캘린더를 보면, 내 일정의 60%는 긴급 이슈였다. 긴급하지 않은 계획된 작업은 20%. 나머지 20%는 회의와 리뷰다. 계산이 맞지 않는다고? 응, 내가 초과근무하는 시간이 20%라는 뜻이다. 우리 팀장은 좋은 사람이다. 나쁜 사람이 아니다. 다만 마케팅 부서의 압박을 받고 있고, 나는 그의 압박을 받고 있다. 기획팀은 "이거 간단하죠?"라고 묻는데, 그들이 모르는 건 그 "간단한" 기능이 엄청나게 복잡한 레거시 코드에 짜여있다는 거다. 지난달의 예를 들어보자. 월요일: 새로운 결제 게이트웨이 연동 요청. 마감은 금요일. "간단한 연동이니까 3일이면 되겠지?" 화요일: 기존 결제 모듈의 구조를 파악하려고 시도. 결제 처리 로직이 3개 파일에 흩어져 있음을 발견. 데이터베이스 스키마도 난장판. "누가 이렇게..." 수요일: 기존 로직을 수정하면서 다른 부분에서 버그 발생. 결제 조회 기능이 깨짐. 긴급 회의. 목요일: 야근. 밤 11시, 결국 새로운 연동을 추가했는데 테스트를 다 못 함. 금요일: 아침 10시 배포. 오후 2시 고객 불만 접수. "결제가 안 돼요." 다시 파악 중... 이게 내 리얼 스토리다. 이게 나만의 이야기는 아니겠지만.기술 부채는 이자가 붙는다 경제학에 "복리"라는 개념이 있다. 돈은 시간이 지날수록 기하급수적으로 늘어난다. 기술 부채도 마찬가지다. 초기에 시간을 들여 제대로 작성하지 않은 코드는 나중에 수십 배의 시간을 빼앗는다. 내가 개발한 기능을 테스트하는 데 3시간이 소요된다는 건, 아마 그 아래 있는 레거시 코드가 너무 뒤엉켜서일 거다. 우리 팀에서 일반적인 버그 수정 시간:새로운 기능 버그: 1-2시간 레거시 버그: 4-8시간왜일까? 왜냐하면 레거시 코드의 버그는 단순히 그 부분만 고치는 게 아니기 때문이다. 그 부분이 어디와 연결되어 있는지 파악해야 한다. 그 파악 과정이 90%의 시간을 먹는다. 한 번은 이런 일도 있었다. 아주 간단한 버그였다. 특정 상황에서 결제 시간이 잘못 저장되는 거. 나는 "이거 5분이면 끝나겠네" 했다. 한 시간 반 후, 나는 발견했다. 이 버그는 실제로는 3개의 서로 다른 부분에서 발생하고 있었고, 각각 다른 개발자가 만든 거였으며, 심지어 일부는 데이터베이스 레벨의 문제였다. 최종적으로 3시간이 걸렸다. 그리고 수정한 지 2주 후, 또 다른 버그가 터졌다. 내가 수정한 부분이 다른 모듈과 충돌했기 때문이다. 다시 2시간. 이게 기술 부채의 복리 효과다. 처음엔 5분이 3시간이 되고, 3시간이 나중엔 5시간이 된다. 리팩토링의 꿈 나는 리팩토링을 꿈꾼다. 이 모든 레거시 코드를 들어내고 깨끗하게 다시 짜는 거. 정말 깔끔한 구조. 적절한 디자인 패턴. 완벽한 테스트 커버리지. 그걸 내 팀장에게 제안했던 게 6개월 전이다. "팀장님, 결제 모듈 리팩토링 프로젝트 시작하면 좋을 것 같아요. 지금 이대로면..." 팀장: "알지. 근데 요즘 릴리즈 스케줄이 타이트해서... 나중에 이야기하자." 3개월 후에 다시 제안했다. 팀장: "그러고 싶은데 마케팅에서 새 기능 요청이 들어와서... 지금은 어렵다." 지금은? 지금도 다를 게 없다. 지금도 "긴급"이다. 이게 대부분의 회사에서 일어나는 현실이다. 리팩토링의 중요성을 아무도 부인하지 않는다. 하지만 모두가 현재의 긴급한 일에 밀린다. 그리고 몇 년이 지나면, 레거시가 더 심해진다. 나는 왜 고칠 수 없을까 가장 정직한 대답은: "시간이 없어서" 하지만 더 정직한 대답은: "우선순위가 없어서" 내가 할 수 있는 리팩토링:결제 모듈 전면 개편: 3-4주 필요 사용자 관리 모듈 정리: 2주 필요 로깅 시스템 개선: 1주 필요 에러 핸들링 통일: 3-4일 필요할 수 있는 일들은 많다. 하지만 이 중 어느 것도 직접적인 매출과 연결되지 않는다. 그래서 우선순위가 낮다. 기획팀이 "새로운 결제 수단 추가해요"라고 하면, 그건 매출과 직접 연결된다. 고객이 더 많은 결제 수단을 원하면, 그걸 만들어야 한다. 기획팀의 입장도 이해한다. 하지만 개발자의 입장에서 보면, 그 "새로운 기능"은 이미 망가진 기초 위에 또 다른 벽돌을 얹는 거다.그래도 계속하는 이유 그럼 왜 나는 여전히 여기에 있을까? 더 나은 회사로 이직하면 되지 않을까? 이 질문은 매달 한 번씩 떠오른다. 특히 야근할 때. 특히 주말에 슬랙 알림이 울릴 때. 진짜 이유는 몇 가지다. 첫째, 익숙함 이 회사의 모든 레거시 코드를 내가 안다. 5년 전 누군가가 작성한 코드의 의도를 안다. 왜 이런 식으로 짰는지 알 수 있다 (물론 여전히 이해 불가능한 부분도 많지만). 새로운 회사가면 또 다른 레거시를 만나야 한다. 차라리 이미 알고 있는 악을 택하는 게 낫다. 둘째, 내가 할 수 있는 영향력 내가 여기를 떠나면, 이 레거시 코드는 누가 고칠까? 아마 후배들이 더 힘들어할 거다. 내가 지금 할 수 있는 작은 개선들, 새로운 코드에서는 레거시를 안 만드는 것, 후배들에게 좋은 예시를 보여주는 것... 이런 게 의미 있다고 생각한다. 셋째, 충성심? 아니, 관성 더 솔직하게 말하면, 이직은 너무 힘들다. 이력서 쓰고, 포트폴리오 정리하고, 면접 봐야 한다. 지금의 피로감 속에서는 그 모든 게 산처럼 보인다. 작은 개선들의 누적 하지만 포기하지는 않았다. 대신 접근 방식을 바꿨다. 큰 리팩토링 대신 작은 개선 일주일에 한두 시간, 뭔가 하나씩 정리한다. 기능을 추가할 때마다 그 주변의 코드를 조금씩 개선한다. 이런 식의 "보이 스카우트 룰" - 도착했을 때보다 떠날 때 더 깨끗하게 - 을 적용한다. 문서화 레거시 코드의 가장 큰 문제는 "왜 이렇게 만들었는가"를 모른다는 거다. 그래서 나는 중요한 로직에 대해 몇 줄의 설명을 남기기 시작했다. 코드 리뷰할 때도 후배들에게 "왜"를 설명하려고 한다. 테스트 추가 모든 레거시 코드를 리팩토링할 수는 없지만, 테스트는 추가할 수 있다. 테스트가 있으면, 나중에 누군가 이 코드를 수정할 때 훨씬 안전하다. 기술 부채 추적 우리 팀은 이제 매달 "기술 부채" 미팅을 한다. 여기서 가장 시급한 레거시 코드들을 정리하고, 가능하면 작은 것부터 개선한다. 한 번에 다 고칠 수는 없지만, 계속 움직이면 언젠가는... 깨달음과 수용 7년을 거쳐 내가 배운 것 중 가장 중요한 건, 완벽한 코드는 존재하지 않다는 거다. 아니, 더 정확하게는: "완벽한 코드는 존재하지 않지만, 나아지는 코드는 존재한다"는 거다. 레거시 코드는 악이 아니다. 그건 과거의 결정이 현재에 남긴 흔적이다. 그 개발자가 나쁜 사람이라서 그렇게 작성한 게 아니다. 그는 당시 조건 하에서 할 수 있는 최선을 했을 거다. 마감이 촉박했고, 이해도 낮았고, 테스트할 시간이 없었을 거다. 지금의 나도 마찬가지다. 내가 지금 작성하는 코드가, 10년 후에 누군가에겐 "왜 이렇게 만들었어?"라는 질문을 받을 거다. 그건 피할 수 없는 운명이다. 그래서 내