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

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

회의 중 노트북으로 딴 짓하는 척 코드 보는 기술: 개발자의 이중생활 가이드 프롤로그: 슬랙 알림과 함께 시작되는 악몽 월요일 오전 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 리스트도 모두 준비했다. 그리고 준비했다. "이거 구현할 때 이쪽에서 이렇게 해야겠네"라는 생각을 하면서, 동시에 기획자의 말을 듣는 준비를. 이건 개발자의 숙명이다. 우리는 이런 회의들과 함께 살아간다. 그리고 우리는 이렇게 생존해왔다. 내일 또 다른 회의가 있을 것이다. 그리고 나는 또 다시 노트북으로 코드를 볼 것이다. 외적으로는 회의에 참여하면서, 내적으로는 코드와 함께. 이게 우리의 이중생활이다. 그리고 이제는 이것이 자연스럽다.결국 회의는 피할 수 없지만, 회의 중 코드는 피할 수 있다는 게 우리의 비밀이다.

배포일 10시까지 야근하다 보니 생각해본 것들

배포일 10시까지 야근하다 보니 생각해본 것들

배포일 10시까지 야근하다 보니 생각해본 것들 6시가 뭐길래? 오늘은 배포일이다. 매달 한두 번 돌아오는 그 날. 아침에 일어날 때부터 이미 피곤했다. 왜냐하면 나는 이미 알고 있으니까. 원칙상 6시 퇴근, 하지만 배포일엔 그런 원칙은 없다. 그냥 일종의 전설일 뿐이다. 마치 "한 달에 딱 한 번만 야근"처럼 들리는 말 같은 거. 사무실 형광등 아래 앉아 있다 보니, 저 멀리 6시의 시간이 자꾸 떠오른다. 6시는 그냥 시간이 아니다. 그건 자유다. 퇴근의 신호음이고, 개인 시간의 시작이고, "이제 코드는 내 것이 아니다"라는 선언이다. 그런데 배포일엔 그게 안 된다. 6시가 되고 또 7시가 되고, 어느새 8시가 되는데 화면엔 여전히 빨간 에러 로그가 떠 있다.오늘 아침 기획자가 말했었다. "이번 배포에 새로운 결제 기능이랑 추천 알고리즘 들어가니까 좀 유의해주세요." 유의해주세요. 그 말이 뭔지 아는가? 그건 "뭔가 터질 가능성이 있다"는 뜻이다. 기획자 입에서 "유의해주세요"가 나오면 현업 개발자들은 절대 편할 수 없다. 그래서 오후 2시부터 배포 준비에 들어갔다. 데이터베이스 마이그레이션 스크립트 돌려보고, 로컬에서 엔드 투 엔드 테스트도 몇 번 해봤다. 쿠키도 먹었고, 물도 마셨다. 준비는 다 했다. 그런데 뭔가 늘 빠진 게 있다. 7시, 첫 번째 에러의 등장 배포 시간 5시 50분. 마지막 체크를 하고 있었다. 슬랙에 배포 시작 메시지를 남기고, 자동화 배포 스크립트를 실행했다. 진행 중... 진행 중... 그리고 BUILD_FAILED. 아, 맞다. 내가 지금까지 몇 번을 반복했는지 세어본 적도 없다. 이 느낌. 배포 과정 중에 예상치 못한 에러를 마주하는 그 짜증나는 감정. 뭔가 왠지 모르게 나를 탓하는 기분도 들고, 세상을 탓하는 기분도 든다. 빨간 글자를 읽어보니, 테스트 코드 하나가 실패했다고 한다. 분명 로컬에선 다 통과했는데. 문제는 로컬 환경과 배포 환경의 차이다. 그 차이가 정확히 뭔지는 거의 철학 문제 수준이다. 왜냐하면 내 옆 팀은 "우리는 Docker로 일관성을 유지하려고 했는데..."라고 말하니까. 그건 나중에 할 일이고, 지금은 이 에러를 고쳐야 한다. 코드를 뒤져본다. 7시 10분. 아내는 아직 회사에 있을 거다. UI 디자인팀은 저녁 늦게까지 일하는 쪽이니까. 좋아, 그럼 최소 1시간 20분은 있다. 충분하다. 아마 8시쯤엔 집에 들어갈 수 있을 거다. 8시, 현실의 무게 에러는 하나가 아니었다. 첫 번째 에러를 고쳤더니 두 번째 에러가 튀어나왔다. 이건 마치 고래게임 같다. 한 문제를 풀면 다음 문제가 나타난다. 보스전 같은 이 과정. 8시가 되니 사무실은 거의 비어있었다. 청소 아저씨가 쓰레기통을 비우고 가셨다. 그리고 나 혼자 남았다. 모니터 화면이 자꾸 흐릿하게 보인다. 피로의 신호다. 아이 드롭스를 짜서 눈에 떨어뜨리고, 커피를 다시 마신다. 오늘의 네 번째 커피다. 카페인은 내 혈액형이다. 이제. 아내한테 문자를 보낼까. 하지만 뭐라고 보내지? "배포 중, 늦겠다" 따위의 말? 이미 내 상황을 충분히 안다. 결혼 2년차다. 매달 한두 번 이런 일이 반복되니까. 그게 가장 서글픈 부분이다. 이제 아내도 배포일을 안다. 내 마음속 달력에 배포일이 표시되듯이, 아내의 마음속 달력에도 이미 표시되어 있을 거다.8시 45분. 마침내 에러를 찾았다. 데이터베이스 쿼리에서 타임존 처리를 잘못했다. 그런데 이건 단순한 쿼리 수정이 아니라, 일부 배포된 데이터까지 롤백해야 할 수도 있다는 뜻이다. 신경이 곤두선다. 나는 펜을 돌리며 생각한다. 내 버릇이다. 가만 생각만 하는 게 아니라, 손가락으로 펜을 돌려야 생각이 잘 된다. 그게 뭐하는 짓인지도 모르지만, 여하튼 그렇다. 옆 테이블에 앉아있는 똑똑한 신입 개발자 박준호 대리가 한 번 물었었다. "개발자님, 왜 펜을 계속 돌려요?" 나는 대답했다. "모르겠는데, 이렇게 하면 버그가 적게 나오는 것 같아." 그건 과학이 아니라 신앙이다. 9시, 아내를 생각하는 마음 배포 진행 상황은 좋아졌다. 데이터 불일치를 수정하고, 다시 배포를 시작했다. 진행 중... 진행 중... 이번엔 성공했다. 프로덕션 환경에 정상 배포됐다. 하지만 아직 끝이 아니다. 배포 후 체크리스트가 남아있다. 프로덕션 DB 접속해서 몇 가지 쿼리로 데이터 검증을 한다. 캐시는 초기화됐나? 로그 에러는 없나? 트래픽 메트릭은 정상인가? 요즘 시대엔 배포하고 "좋아, 끝" 이라고 할 수 없다. 그다음이 또 있다. 9시. 아내한테 연락할 시간이다. 나는 핸드폰을 들었다 놨다를 반복한다. 지금 전화하면 회의 중일 수도 있고, 프레젠테이션 준비 중일 수도 있다. 아니면 이미 집에 와 있을 수도 있다. 그렇다면 혼자 뭐하면서 기다리고 있을까. TV를 볼까. 아니면 또 다른 프로젝트를 할까. 솔직히 말하면, 나는 지금 가정을 미안해하고 있다. 회사 일이 중요한 건 맞다. 근데 가정도 있지 않은가. 배포일이 아니면 오늘 같은 날이 또 없을 텐데, 내가 점점 그 사실에 무뎌지는 것 같다. 작년에는 배포일에 대한 스트레스로 한 달에 며칠을 고민했는데, 올해는? 이제는 그냥 일어날 일이라고 생각한다. 마치 월급이 들어오는 것처럼. 9시 30분, 테크 리드의 책임감 후배 개발자들이 자꾸 내 슬랙을 울린다. 배포 진행 상황을 묻는 것이다. 공식적으로는 테크 리드가 따로 있지만, 실제론 내가 한다. 직책 없이. 급여도 없이. 그래서 다른 사람들은 "개발자님, 이거 마이너 버그인데 괜찮은가요?"라고 물어본다. 배포 중에는 모든 경고가 최우선이다. 마이너도 메이저도 없다. 그냥 모두가 신경 쓴다. 나는 기획자한테 "지금 배포 중이니까 급할 땐 아니지만, 곧 확인 가능합니다"라고 말한다. 기획자는 "아, 그렇구나요"라고 대답한다. 하지만 그 말은 "빨리"라는 뜻이다. 모든 "구나요"는 "빨리"를 포함하고 있다. 배포 후 검증이 끝나니 9시 50분. 마지막으로 배포 로그를 정리하고, 슬랙 채널에 배포 완료 메시지를 남긴다. "#devops-alerts" 채널에. 그 메시지를 보고 회사 전체가 안심한다. 그 메시지 한 줄 때문에 내가 여기까지 왔구나 싶으면서도, 또 한편으로는 "이제 끝이다"라는 생각이 든다.10시, 다음엔 더 안정적으로 10시에 나는 사무실을 나선다. 조명을 모두 끄고, 사무실 문을 닫는다. 밤의 도시는 여전히 깨어있다. 버스를 탄다. 버스 창 밖으로는 서울의 야경이 흐른다. 사람들은 술집에 가고, 당구장에서 놀고, 또 누군가는 나처럼 집으로 돌아간다. 그들도 뭔가 일이 있을까. 아니면 그냥 퇴근한 건가. 집에 가면 아내가 기다릴 거다. "배포 잘됐어?"라고 물을 거다. 나는 "응, 잘됐어. 조금만 쉬면 돼"라고 대답할 거다. 그러면 아내는 밥을 데워줄 거고, 나는 먹을 거다. 그리고 한참을 앉아만 있을 거다. 화면을 보다가, 또 아내를 보다가. 배포일 밤 10시 버스 안에서 나는 생각했다. "다음엔 더 안정적으로 배포하자." 이 생각은 이미 3번째다. 배포가 있을 때마다 나는 이 다짐을 한다. 도커 환경을 좀 더 정확히 구성하고, 자동화 테스트를 더 촘촘히 하고, 배포 전 체크리스트를 더 자세히 만들고... 그런데 왜 이 다짐이 매번 반복될까. 그건 사실 내 능력 문제가 아니라, 시간의 문제다. 다음 배포까지 시간이 있어야 이런 것들을 개선할 수 있는데, 매일 새로운 버그 리포트가 들어오고, 새로운 기능 요청이 들어온다. 그럼 언제 개선을 하나. 주말? 하지만 주말은 치킨 시키고 넷플릭스 보는 내 유일한 쉼표다. 결국 배포는 또 다음 달에 한다. 그때도 어디선가 뭔가 빠질 거다. 그때도 내가 8시에 에러를 발견하고, 9시에 아내를 생각하고, 10시에 버스를 탈 거다. 그리고 또 다시 다짐을 한다. "다음엔 더 안정적으로." 배포일 밤 10시. 나는 버스 의자에 기대어 눈을 감는다. 오늘도 이렇게 끝난다. 내일도 일어나서 코드를 본다. 그 다음도. 그리고 또 그 다음 배포일도. 사실 배포일은 직업 개발자의 숙명이다. 피할 수 없다. 그래서 나는 이 밤을 받아들인다. 아내도 알고 있다. 경영진도 안다. 우리 팀도 안다. 이게 우리 일이라는 걸. 배포가 성공하는 그 순간, 모든 스트레스가 보상받는 느낌이 든다. 어느 정도는. 나머지는 그냥... 직업 의식이다.결국 내일이 또 있으니까, 오늘 따위는 상관없다.

이직해야 하나 고민되는데 면접 준비할 에너지가 없어요

이직해야 하나 고민되는데 면접 준비할 에너지가 없어요

이직은 하고 싶은데 면접 준비는 왜 이리 힘든가 7년차 개발자로서 받는 가장 흔한 질문이 있다. "이직은 안 해요?" 동기들은 이미 7000만원대 연봉을 받고 있고, 나는 여전히 6500만원에서 맴돌고 있다. 계산기를 두드려보면 매년 500만원씩 손해 보는 셈이다. 7년이면 3500만원이다. 자동차 한 대 값이다. 그런데도 나는 왜 자리를 뜰 생각을 못 할까? 아, 맞다. 면접 준비가 너무 피곤하니까. 슬랙 채널에서 누가 "요즘 시장 좋네, 우리 팀 사람 찾고 있어"라는 글을 봐도 마음 한구석이 철렁하면서도 동시에 한숨이 나온다. 왜냐하면 그것이 나의 인생이 바뀌는 시발점이 될 수도 있기 때문이다. 그리고 그 변화를 위해서는 LeetCode를 켜서 Medium 난이도의 그래프 문제를 50개쯤 풀어야 하고, 시스템 디자인 유튜브 영상을 보면서 '넷플릭스는 어떻게 스트리밍 인프라를 구축했을까' 같은 걸 공부해야 한다는 것을 알기 때문이다. 그런데 나는 지금 피곤하다. 진짜 피곤하다. 동기들 연봉을 마주하는 그 감정 매해 신년 회식이나 대학 동기들 단톡방에서 나오는 말들을 들으면, 이상하게 가슴이 철렁내린다. "어, 너 회사 잘하네. 근데 연봉은 괜찮아?" 이 질문이 나를 가장 킹받게 한다. 괜찮아? 괜찮은 게 아니다. 동기 A는 작년에 전직했다며 7500만원을 받고 있고, 동기 B는 스타트업에서 성공했다며 8000만원대라고 했다. 나는 여전히 6500만원이다. 7년을 같은 회사에서 일했는데, 그동안 시간만 흘렀지 연봉은 거의 오르지 않았다. 매년 300만원 정도 오르니까 인상률로 따지면 4~5% 정도? 물가상승률은 뛰어넘지 못한다. 돈 때문에 일하는 건 아니라고 자기를 속이고 싶지만, 현실은 냉혹하다. 아내가 월급 통장에서 돈을 빼갈 때 나는 항상 조금 쑥스럽다. 내가 버는 돈인데도 말이다. 아내는 좋다고 하지만, 나는 안다. 우리 또래 남편들 중에 6500만원인 사람이 몇 명이나 되는지를.이직해야 한다는 걸 알고 있다. 정말 알고 있다. 100% 확실하다. 그런데도 나는 여전히 자리에 앉아 있고, 사무실의 재미있는 것들에 적응했다. 팀장은 나를 믿고 있고, 후배들은 나를 찾는다. PR 리뷰를 잘하면 칭찬받는다. 이 모든 게 나를 붙잡고 있다. 하지만 진짜 문제는 그게 아니다. 진짜 문제는 이걸 다 뒤로하고 새로운 회사에 가기 위해 필요한 절차들이다. LeetCode 앞에서 멈춘 발걸음 이직 준비의 첫 번째 관문은 코딩 테스트다. 요즘은 대부분의 회사가 LeetCode 같은 플랫폼에서 나오는 식의 문제들을 본다. 내가 면접을 본다고 치면, 분명히 누군가는 나에게 "자, 30분 안에 이 그래프 문제를 풀어보세요"라고 할 것이다. 여기서부터 문제가 시작된다. 내 일은 그런 식의 코딩이 아니다. 나는 Spring Boot로 백엔드 서버를 짜고, 데이터베이스를 설계하고, 캐시 전략을 짠다. 내 일 중 70%는 이미 누군가 만들어놓은 프레임워크나 라이브러리를 활용하는 것이다. 알고리즘? 그런 건 면접 때만 필요한 것이다. 실무에서는 문제가 이미 구조화되어 있고, 나는 그것을 가장 효율적으로 구현하면 된다. 그런데 LeetCode를 켜면 어떻게 되는가? 동적 프로그래밍, 그래프의 DFS, BFS, 트라이(Trie), 세그먼트 트리... 이런 것들이 갑자기 나타난다. Hard 난이도의 문제들은 보자마자 머리가 복잡해진다. "이게 뭐가 필요한 거지? 왜 이렇게 복잡하지?" 하면서 해석만 10분을 날린다. 면접 준비를 위해서는 최소한 Medium 난이도의 문제를 50개 정도는 풀어야 한다고 한다. 몇몇 블로거는 100개를 푼다고 했다. 하루에 2~3개씩 풀면 한 달이 걸린다. 그리고 풀고 나서는 그 알고리즘을 다시 복습해야 한다. 퇴근하고 집에 가면 몇 시일까? 보통 6시30분이다. 식사를 하고 나면 7시30분이다. 아내와 얘기하고 나면 8시다. 여기서 30분이라도 LeetCode를 켜자니 너무 피곤하다. 브라우저 탭을 열기만 해도 피곤한데, 문제를 읽는 것부터 시작해서 풀고, 다른 사람의 솔루션을 보고, 댓글을 읽고... 이 모든 과정이 너무 길다. 차라리 넷플릭스를 킨다. 유튜브를 본다. 핸드폰에서 밈을 본다. 이게 훨씬 쉽고, 뇌가 피로를 덜 느낀다. 그리고 10시경 침대에 눕는다. 내일도 LeetCode를 해야지 하는 생각을 하면서. 그 다음날도 같은 일이 반복된다.시스템 디자인 인터뷰의 공포 LeetCode도 힘든데, 그 다음이 있다. 바로 시스템 디자인 인터뷰다. "넷플릭스는 어떻게 전 세계에서 동시에 스트리밍을 서비스할까요?" "우버는 어떻게 실시간으로 기사와 손님을 매칭할까요?" "당신이 페이스북의 뉴스피드를 설계한다면 어떻게 하겠어요?" 이런 질문들 앞에서 나는 항상 무너진다. 내 답변은 항상 비슷하다: "음... 데이터베이스는 MySQL 쓰고, 캐시는 Redis 쓰고, 로드 밸런싱은... 아, 그냥 AWS에서 해주겠죠?" 면접관의 얼굴이 굳는 것을 알 수 있다. 시스템 디자인을 제대로 준비하려면 따로 시간을 들여야 한다. 유튜브 채널도 봐야 하고, "System Design Interview" 같은 책도 읽어야 한다. 대규모 트래픽을 어떻게 처리할 것인가, 데이터 일관성은 어떻게 유지할 것인가, 네트워크 파티션이 발생했을 때는 어떻게 할 것인가... 이런 것들을 모두 체계적으로 학습해야 한다. 이건 1주일에 되는 게 아니다. 최소한 1~2개월은 걸린다. 내가 지금 준비한다면? 아, 다음 프로젝트 마감이 2주밖에 안 남았다. 레거시 코드도 봐야 하고, 후배 PR도 리뷰해야 한다. 배포 예정도 있다. 금요일에는 정말 밤 10시까지 남아있는 날도 생길 수 있다. 이런 상황에서 시스템 디자인을 1시간씩이라도 공부한다? 현실적이지 않다. 동기들의 성공담, 나의 무기력함 지난주 대학 동기들 단톡방에서 누군가가 말했다. "어, 나 이사를 했어. 이직하면서 집도 하나 더 샀어." 나는 그 메시지를 읽고 폰을 놨다. 그리고 팔을 베개에 두고 천장을 봤다. 동기 C는 정말 운이 좋은 애다. 처음부터 회사를 잘 고른 덕분에 지금 연봉이 9000만원대라고 한다. 동기 D는 스타트업에서 초기 멤버로 들어가서 이제 매니저까지 올라왔다. 동기 A는 정확히 2년 단위로 옮기면서 매번 연봉을 30~40% 올렸다고 한다. 나는? 나는 2년 전부터 "이번 연말에 이직해야지"라고 마음먹었다가 결국 다음해 초로 미뤘다. 그리고 작년 초에도 "이번 상반기에..."라고 했다가 지금은 올해 말쯤? 내년 초? 어정쩡한 상태다. 가장 좌절감을 느끼는 순간은, 누군가 나에게 "너 왜 이직 안 해?"라고 물을 때다. 그 질문 자체가 이미 답을 포함하고 있기 때문이다. "너는 왜 움직이지 않고 있니?"라는 비난이 담긴 질문이다. 그리고 나는 할 말이 없다. 연봉을 500만원 올리기 위해서는 면접을 봐야 하는데, 면접을 보려면 준비를 해야 하는데, 준비를 하려면 에너지가 필요한데, 그 에너지가 없다. 이게 악순환이다. 악순환의 늪에서 빠져나올 수 없는 것처럼 느껴진다.일이 많아서가 아니라, 일이 편해서다 여기서 인정해야 할 게 하나 있다. 내가 이직 준비를 못하는 이유가 '일이 너무 많아서'만은 아니라는 거다. 물론 일은 많다. 하루하루 할 일은 항상 넘쳐난다. 아침에 출근하면 이메일 50개가 와 있고, 슬랙 메시지 200개가 쌓여 있다. PR 리뷰를 5개, 버그 리포트를 3개 받는다. 그리고 내 일들. 배포 준비, 성능 최적화, 새로운 기능 개발. 그래도 실은 정해진 8시간 안에 거의 다 끝난다. 9시 출근 6시 퇴근이 원칙이고, 배포날 외에는 야근을 거의 하지 않는다. 그럼 내가 LeetCode를 할 시간이 없는 이유가 뭐냐고 물으면? 솔직하게 답하자면, 일이 편하기 때문이다. 내 자리는 편안하다. 내가 정말 싫어하는 사람이 없다. 팀장은 내 능력을 인정해주고, 후배들은 내 말을 듣는다. 내가 "이건 이렇게 하는 게 낫다"고 말하면, 대부분 그렇게 된다. 이 정도의 influence는 다른 회사에서 쉽게 얻을 수 없다. 그리고 무엇보다, 이 일을 하는 것이 힘들지 않다. 새로운 기술을 배울 필요도 없다. 이미 안다. Spring Boot? 7년간 써왔다. MySQL? 누구보다 잘 안다. Redis? 당연히 안다. 새로운 회사에 가면? 새로운 기술스택이 있을 수도 있다. 새로운 조직 문화도 있을 것이다. 새로운 사람들도 만나야 한다. 처음부터 다시 배우고, 적응하고, 인정받으려고 노력해야 한다. 그런데 지금 나는 이미 적응했다. 이미 인정받고 있다. 왜 이 편한 자리에서 일어나서 새로운 불편함으로 들어가야 하나? 연봉 500만원의 증가? 그건 추상적이다. 하지만 지금 이 자리의 편함? 그건 구체적이다. 만질 수 있다. 느낄 수 있다. 이것이 내가 이직을 미루는 진짜 이유다. 퇴근 후의 나는 정말 피곤한가? 그런데 한 가지 더 솔직하게 인정해야 할 것이 있다. 퇴근 후에 나는 정말 피곤한가? 사실... 피곤한 건 맞다. 하지만 피곤의 종류가 다르다. 신체적 피로는 사실 많지 않다. 나는 책상에 앉아서 마우스와 키보드를 쓰는 일을 한다. 신체를 많이 쓰지 않는다. 그런데도 6시 반쯤 되면 온몸이 무거워진다. 이건 정신적 피로다. 뇌를 계속 굴려서 나는 피로가 아니라, 선택을 계속 해서 나는 피로다. "이 코드는 어떻게 리팩토링할 것인가?" "이 버그의 원인은 뭐지?" "후배 코드의 이 부분이 문제인데, 어떻게 피드백할까?" "그 기획자의 요청은 가능할까?" 아침부터 저녁까지, 내 뇌는 계속 무언가를 결정하고 있다. 문제를 분석하고, 솔루션을 생각하고, 사람들과 커뮤니케이션한다. 6시 반에 회사를 나올 때쯤이면, 이 뇌는 진짜 더 이상 더하고 싶지 않다. 추가로 복잡한 작업을 하고 싶지 않다. 그래서 넷플릭스를 킨다. 유튜브를 본다. 핸드폰으로 밈 영상을 본다. 이런 것들은 뇌가 거의 일을 하지 않아도 된다. 정보가 일방적으로 들어오고, 나는 그냥 받으면 된다. 하지만 LeetCode? 그건 내 뇌가 또 일을 해야 한다는 뜻이다. 문제를 읽고, 로직을 생각하고, 코드를 짜고, 테스트 케이스를 생각한다. 퇴근해서 또 일을 하라는 거다. 이게 가능한가? 일단 며칠은 된다. 처음 이직을 생각할 때는 정말 열정으로 가득 차서 "일주일에 5일은 공부하겠다"고 마음먹는다. 그리고 월요일부터 수요일까지는 정말 한다. 그런데 목요일이 되면? 목요일 오후 4시쯤 기획자가 "이거 좀 빨리 봐주실래요?"라고 메시지를 보낸다. 내가 봐야 할 것 같은 느낌이 들기 시작한다. 목요일 저녁 10시에 배포 점검 메시지가 온다. 다음날 배포가 있을 수 있다는 거다. 그럼 금요일 밤이 걱정된다. 그런 불안감이 쌓이면, 목요일 밤에는 LeetCode를 케지 않는다. 차라리 숙면을 취한다. 그리고 토요일 오전? 솔직히 말해서 자고 싶다. 일주일간 일한 몸을 쉬고 싶다. 일요일? 내일 월요일이다. 월요일은 항상 힘들다. 일요일은 월요일을 위해 정신을 모아야 한다. 이렇게 한 주가 지나간다. LeetCode는 여전히 0개다. 그래도 누군가는 한다 내가 정말 고민스러운 점은, 나 같은 상황에서도 누군가는 성공한다는 거다. 내 대학 동기 중에 E라는 친구가 있다. 얘도 나랑 비슷하게 중견 회사에 다니고 있었다. 연봉도 비슷했다. 하지만 얜 결심했다. 정확히는 1년 전에 결심했다. "3개월에 이직한다. 이건 아니다." 그리고 얜 정말 했다. 평일 저녁마다 1시간씩. 주말에도 2시간씩. 3개월간 거의 모든 저녁을 LeetCode에 썼다고 했다. 내가 물었다. "힘들지 않았어?" 얜 말했다. "미쳤을 정도로 힘들었지. 근데 나는 더 이상 기다릴 수 없었어. 연봉이 올라야겠다는 생각이 집착이 됐어. 그 집착이 날 끝까지 밀어붙였어." 그리고 얜 성공했다. 유명한 스타트업으로 옮겼고, 연봉은 8500만원이 됐다. 보너스까지 치면 1억을 넘는다. 얘를 볼 때마다 나는 자책한다. 나는 왜 그정도의 집착을 가질 수 없을까? 왜 나는 편함에 안주할까? 그래서 가끔 정말 이직하기로 '결심'한다. 하지만 결심과 실행 사이의 거리가 너무 멀다. 현실은 복잡하다 솔직하게 말하자면, 이 문제는 단순하지 않다. "이직하고 싶으니까 준비하면 되지 않냐?"라고 말할 수 있지만, 현실은 그렇지 않다. 첫째, 나는 정말 이직하고 싶은가? 이 질문에 솔직한 답은 "글쎄... 그런 것 같은데?"이다. 연봉이 올랐으면 좋겠다. 하지만 지금 이 자리를 잃고 싶지는 않다. 이 두 가지를 동시에 가질 수는 없을까? 둘째, 면접 준비는 정말 필수적인가? 내가 지금의 자리에서 한 일들을 생각해보면, LeetCode에서 나올 법한 그래프 알고리즘이나 동적 프로그래밍을 쓴 적이 거의 없다. 하지만 면접관들은 그걸 묻는다. 왜냐하면 그게 '검증된 방식'이기 때문이다. 지능을 검증하는 방식. 하지만 정말 필요한 건 맞다. 나도 안다. 그리고 이것이 나를 더욱 막힌다. 선택지가 명확하기 때문이다. 면접을 본다는 것 = 준비를 한다는 것 = 저녁 시간을 포기한다는 것. 셋째, 내가 정말 피곤한가, 아니면 그냥 동기부여가 부족한가? 이건 진짜 구분하기 힘들다. 나는 정말 피곤하다고 느낀다. 하지만 동시에 나는 넷플릭스를 보면서 3시간을 보낸다. 이건 모순이다. 동기부여가 충분했다면, 나는 넷플릭스를 끄고 LeetCode를 켰을 거다. 하지만 나는 그렇게 하지 않는다. 왜냐하면 동기부여가 부족하기 때문이다. 그리고 동기부여가 부족한 이유는 뭘까? 아, 그건 내가 지금 편하기 때문이다. 혼자가 아니라는 생각 가끔 개발자 커뮤니티에 들어가서 다른 사람들의 고민을 읽다 보면, 내가 혼자가 아니라는 걸 알 수 있다. "7년차인데 연봉이 6500만원입니다. 이직해야 할까요?" 이런 글에 달리는 댓글들을 보면, 대부분 같은 조언을 한다. "이직하세요. 시장 가격보다 훨씬 적게 받고 계세요." "면접 준비가 힘들겠지만, 한 번 시작하면 가능합니다." "제 경험상 3개월이면 충분합니다." 좋은 조언들이다. 하지만 그 글을 쓴 사람도 나처럼, 그 댓글을 읽고도 행동을 취하지 못할 가능성이 높다. 왜냐하면 댓글은 힘을 주지 못하기 때문이다. 위로는 된다. 하지만 실제로 LeetCode를 켜라고 강요할 수는 없다. 내가 정말 필요한 건, 동료가 옆에서 "야, 너 진짜 하자"라고 말해주는 것이다. 아니면 팀을 꾸려서 함께 공부하는 것이다. 아니면 정말 갈등적인 상황이 닥치는 것이다. 예를 들어, "넌 이 회사에서 절대 매니저가 될 수 없어"라는 말을 들으면, 나는 행동할 것 같다. 하지만 지금은? 지금은 다 가능할 것 같다. 이대로도 괜찮을 것 같다. 5년 더 있어도 밥은 먹고 살 것 같다. 이게 나를 가장 걱정하게 만드는 부분이다. 계단을 놓친 게 아닐까 또 다른 두려움이 있다. 바로 "이미 늦지 않았을까?"라는 생각이다. 7년차면 아직 충분히 젊은 나이다. 하지만 업계에서는 이미 나를 뭔가 '정해진' 사람으로 보고 있을 수도 있다. "아, 그 사람은 중견 회사에서 7년 있던 사람이네. 그럼 안정적인데 도전을 안 한다는 뜻이겠네." 이걸 극복하려면, 새 회사에서도 빠르게 적응해야 한다. 그리고 성과를 내야 한다. 그런데 나는 지금 기반이 없는 상태다. 새 회사의 시스템도 모르고, 사람

주말 슬랙 알림 공포증: 무음 설정의 비극

주말 슬랙 알림 공포증: 무음 설정의 비극

주말 슬랙 알림 공포증: 무음 설정의 비극 가을이 들어서니 퇴근길이 조금 더 편해졌다. 해가 일찍 지니까 야근을 하지 않는 이상 어두운 건물을 빠져나올 수 있다는 뜻이니까. 어제도 그랬다. 금요일 6시 딱 맞춰 자리에서 일어났고, 모니터를 끄고 슬랙을 열었다. 상태 메시지를 "자리 비움"에서 "주말 모드"로 바꾸고, 손가락이 거기서 멈췄다. 슬랙 알림 설정 화면. 그 초라한 체크박스들이 나를 바라보고 있었다. 금요일 저녁, 결정의 순간 보통 금요일 밤이 되면 이 문제가 터진다. 혼자만의 싸움이 아니라, 개발자라면 누구나 겪는 그 오래되고도 끝나지 않는 문제. "슬랙 무음으로 할 거야, 아니면 소리 켜둘 거야?" 회사 지친다고 늘 투덜대던 선배 개발자 김상현이는 올해 초 이렇게 말했었다. "나? 그냥 핸드폰 내려놔. 금토일 슬랙 안 본다. 죽고싶지 않으면." 그의 얼굴에선 반은 농담이고 반은 진지함이 묻어났다. 나는 한참을 생각했다. 그게 가능할까? 정말?나는 그정도까진 못하겠다고 생각했다. 온전히 손을 놓는 건 너무 무섭다. 배포 이슈라도 터지면? QA 팀에서 급한 버그를 발견하면? 아니면 시스템이 다운되면? 일단 한 번 "음소거" 버튼을 눌렀다. 휴대폰의 슬랙 앱을 열어서 알림을 모두 끐다. "세상이 아무리 떠들어도 나는 모를 일"이라는 생각으로. 그런데 마음이 놓이지 않는다. 30분을 버티더니 다시 설정 화면으로 돌아갔다. 조용할 땐 너무 조용하고, 그 조용함 속에서 내 상상만 자꾸 살아난다. 우리 서비스 메인 데이터베이스가 지금 이 순간 죽어가고 있는 건 아닐까? Redis 캐시가 터졌을지도 모르지? 아니면 저 신입 개발자 이준호가 실수로 프로덕션에 직접 핫픽스를 푸시했거나. 음... "도움말"이 라는 설정으로 바꿔봤다. 긴급 메시지만 울리게. 하지만 슬랙에서 "긴급"의 정의가 뭔지는 아무도 명확히 알지 못한다. 결국 일요일 자정을 넘길 무렵, 나는 이 설정들을 전부 다시 기본값으로 되돌렸다. 음성 알림, 배지, 데스크톱 알림 전부. "차라리 좀 울리는 게 낫지." 이렇게 중얼거리며. 월요일 아침의 악몽 실제로 그런 일이 터진 건 3주 전이었다. 정확히는 지난 8월 셋째 주 토요일이었다. 금요일 오후 4시쯤에 우리 팀에 신규 배포가 들어갔다. 여름 행사 특수 기간을 대비하는 배포였고, 내가 리뷰한 PR 3개, 다른 팀원들이 리뷰한 PR 4개가 포함되어 있었다. 보통 배포는 금요일 오전에 하는 게 회사의 암묵적인 룰인데, 이번엔 기획팀 요청으로 오후에 했다. "마지막 데이터 정합성만 한 번 더 체크하려고요."라는 명목 아래. 배포 후 한 시간 정도 모니터링을 하고 나서 나는 좀 이상한 느낌이 들긴 했지만, 에러 로그도 없고 응답 속도도 괜찮아 보였다. 금요일 6시. 회사를 나왔다. 토요일은 아내가 일찍 집에 올 예정이라서 카페를 한 바퀴 돌고 회사 근처 마트에 들렀다가 집으로 돌아갔다. 첫 번째 무음 설정을 했다. 휴대폰에서. "주말이야, 조용해지자." 토요일은 정말 조용했다. 슬랙이 울리지 않았다는 게 아니라, 나는 그걸 들을 수 없도록 설정했으니까. 아내랑 영화도 봤고, 점심에 밖에서 밥도 먹었다. 일요일도 비슷했다. 치킨을 시켜먹고, 개인 노트북으로 쓸데없는 깃허브 레포지토리도 만들어 봤다가 포기했다. 휴대폰은 책상 한구석에 놔뒀다. 월요일 아침 7시 40분. 회사로 출근하는 지하철 안에서 휴대폰의 알림을 다시 켰다. 아이폰 화면에 한 번에 터져나온 슬랙 알림. 빨간 배지에 "47"이라고 떠있었다. 47개. 토요일 오후 2시부터 일요일 밤 11시까지, 거의 36시간 동안 온 메시지들. 내 얼굴이 확 굳었다. 슬랙을 열었다. [12:47] 팀장: 배포 후 데이터 정합 이슈 감지. 회원 경험치 산정에 문제 있는 것 같음. 확인 부탁 [12:59] 이준호: 김개발님 계신가요? [13:15] 팀장: 김개발님 일하시나요? 응답 부탁 [13:47] QA담당자: 심각해보이는데 배포 롤백할까요? [14:02] 팀장: 긴급 회의실 1번방 입장 부탁 [14:15] 팀장: 김개발님 연락 안 되네요. 우선 롤백 결정 [14:33] CTO: 앞으로 변경사항 발생했을 때 담당 개발자 연락 안 되면 팀장이 직접 롤백하기로. 공지 예정 [14:47] 이준호: 형... 왜 연락이... [15:22] QA담당자: 롤백 완료. 원인 파악 필요. 코드 리뷰 다시 해야 할 것 같음 후속 메시지는 토요일 밤부터 일요일 내내 이어졌다. 동료들이 원인을 찾아내려고 한 흔적들, 몇 가지 추측들, 그리고 점점 우울해지는 톤. 내 손이 떨렸다. 원인은 결국 월요일 아침 회의에서 밝혀졌다. 내가 승인한 PR 중 하나였다. 신규 기능을 추가할 때 캐시 무효화 로직을 제대로 넣지 않아서, 기존 데이터와 새 데이터가 섞여서 나왔던 거였다. 코드만 봐도 한 30초면 문제를 찾을 수 있는 수준이었다. 나는 그날 오후 3시경 PR을 승인했고, 리뷰하면서 커피를 마셨고, 그때 화면에 다른 창을 띄웠었다. 그래서 그 부분을 놓쳤다. 팀장은 차분하게 말했다. "배포 전에 충분한 모니터링 시간이 없었고, 금요일 오후 배포가 그래서 위험한 거다. 근데 역시 배포 담당자가 주말에라도 연락은 돼야 할 것 같아. 그게 프로페셔널이니까." 내가 "죄송합니다"라고 말하는 동안, 마음속으로는 다른 생각이 맴돌고 있었다. "아, 그래. 내가 무음으로 설정하지 말았어야 했나?"트루 스토리: 다른 동료들은? 그 이후로 나는 다른 팀원들과 아주 솔직한 대화를 나눴다. "너희 금토일 슬랙은 어떻게 해?" 결과는 놀랍게도 다양했다. 먼저 박세진 선배. 15년차 벡엔드 개발자다. 그이는 "핸드폰 자체를 집에 안 가져가"라고 했다. 회사 휴대폰 따로, 개인 휴대폰 따로. 퇴근하고 회사 핸드폰을 락커에 둔다는 뜻이었다. "그렇게라도 해야 미쳐 안 된다고." 그 다음은 신입 이준호. 그이는 "뭐 어차피 내가 롤백할 권한도 없으니 음소거 해도 되겠지?"라고 했다. 면접 때는 "회사를 위해 개인 시간도 아끼겠습니다"라고 했지만, 현실은 다르다고. 밀실에서 혼잣말로 한숨을 쉬는 모습이 보였다. 그리고 QA팀의 이수영 팀장. 그이는 "그냥 개인 휴대폰엔 안 깔아. 회사 노트북이랑 회사 핸드폰은 회사 건물 밖으로 안 가져간다"고 했다. "배포 담당자랑 팀장만 음성 알림을 켜. 나머지는 배지만 켜서 나중에 확인하고, 정말 긴급하면 전화를 해." 가장 현실적인 건 아키텍처를 담당하는 김수진이었다. "배포 관리 정책을 바꿨어. 금요일 오후 배포는 원칙적으로 금지. 긴급이면 수동으로 팀장 승인 받고, 그때는 배포 담당자가 일요일 저녁까지는 깨어 있기로 계약서처럼 합의." 나는 이 대화들을 들으면서 깨달았다. 결국 "정답은 없다"는 것을. 모두가 놓친 포인트: 시스템의 문제 월요일 회의가 끝나고 나서 한 가지 더 진행된 게 있다. 신규 정책 수립이었다. CTO가 주도해서 만든 규칙:금요일 오후 3시 이후 프로덕션 배포 금지 (긴급 제외) 배포 담당자는 배포 후 최소 2시간 모니터링 필수 긴급 배포는 팀장이 반드시 동반하고, 배포 담당자 연락처 3곳 모두에 연락 배포 롤백 프로세스 자동화 (수동 롤백 시간 단축) 모니터링 대시보드 표준화 (동일한 항목을 모두가 체크)여기서 재미있는 건, 이 규칙들이 사실 "개발자의 주말을 보호하기 위한" 규칙이 아니라, "배포 이슈를 줄이기 위한" 규칙이라는 점이었다. 결과적으로 개발자 복지가 향상됐지만, 그건 부수효과였다. 내가 느낀 건 이거였다: 개발자 개인이 슬랙 음소거를 고민하는 게 아니라, 회사가 시스템을 고민해야 한다는 거. 문제는 금요일 오후 배포가 터졌을 때 개발자가 주말에 대응할 수 있는 여건이 아니었다. 문제는 배포 담당자만 원인을 알고 있어서, 다른 팀원들이 복구를 하지 못했다. 문제는 롤백 프로세스가 느려서 36시간이나 서비스가 깨진 상태로 남았다. 그 모든 게 개발자 개인의 휴대폰 음소거 설정이 해결할 수 있는 문제가 아니었다. 다음 주 월요일, 나는 슬랙 설정을 다시 만졌다. 이번엔 자신감 있게 "모든 알림 켜기"를 눌렀다. 하지만 이상하게도 마음이 불안했다. 왜냐하면 이제 토요일 오전에 알림이 울려도, 그건 시스템의 문제이지 내가 음소거를 하지 않은 문제는 아니라는 걸 알았으니까.결국 우리는 뭘 배워야 하나 지금 시점에서 돌아보면, 이 사건은 여러 층의 실수가 겹쳐진 결과였다. 첫째, 내 리뷰가 정확하지 않았다. 그건 인정한다. 오후 3시쯤 피로도가 높아진 상태에서 캐시 로직까지 한눈에 보기는 어려웠고, 나는 충분히 신경을 쓰지 않았다. 둘째, 금요일 오후 배포라는 시스템의 문제가 있었다. 팀장도, CTO도, 아무도 지적하지 않았다. "그런가보네?"라고 넘어갔다. 셋째, 배포 후 모니터링이 불충분했다. 1시간 정도만 한 후 "괜찮겠지"라고 생각했는데, 실제로는 특정한 기간대의 특정한 행동을 했을 때만 버그가 터지는 거였다. 넷째, 그리고 내가 무음 설정을 했다. 이건 앞의 세 문제를 안고도, 마지막 방어선을 없앤 셈이다. 근데 생각해보니 넷째가 가장 비난하기 쉬운 부분이어서, 결국 나만 욕먹은 거다. "휴대폰 확인 좀 해. 어른답게."라는 눈길들. 분명히 내 잘못도 있다. 50%는 내 책임이다. 근데 나머지 50%는? 그건 개발팀의 프로세스, 배포 정책, 모니터링 시스템, 회사 문화였다. 그리고 문제는, 이 50%를 개발자 개인이 해결해야 한다고 생각하는 경향이 업계 전체에 있다는 거다. "너는 열정이 있으니까, 주말도 슬랙을 체크해." "너는 시니어니까, 배포 관련 알림은 꺼도 안 된다." "너는 팀 리드니까, 팀원 문제는 언제든 해결할 수 있도록." 이런 문화들. 다들 어느 정도는 옳은 말이지만, 어느 정도는 우리를 갈아서 커피를 만드는 과정이기도 하다. 우리가 만든 새로운 규칙 회의가 계속되면서, 재미있는 일들이 생겼다. 팀원들이 하나둘 자기 생각을 말하기 시작했다. 보통 개발자들은 회의에서 조용한데, 이번엔 달랐다. 이준호: "그 금요일 오후 3시 금지 정책, 혹시 긴급 배포가 생기면 누가 판단하는 거죠?" 수진: "좋은 질문. 팀장이 하나 다 결정하기엔 너무 많으니까, 기획팀, QA팀, 개발팀 합의로." 이준호: "그럼 합의하는 과정에 제한 시간이 있어야 하지 않을까요? 왔다갔다 하다가 배포 시간이 늦어지면, 또 금요일 저녁이 될 텐데." 세진: "맞다. 결정 30분 이내. 결정이 못 나면 일단 롤백하고 월요일에 다시 배포." 김수진: "좋아. 그럼 롤백 프로세스도 표준화 해야지. 지금은 수동으로 하니까 시간이 오래 걸려." 팀장: "롤백 스크립트 만들 사람?" "..." 결국 그건 내가 하기로 했다. 하지만 이번엔 다르게 생각했다. 이 스크립트를 나만 알고 있으면 또 다음에도 나한테 물어볼 거다. 그래서 나는 문서화하기로 했고, 팀원들이 전부 롤백할 수 있도록 교육하기로 했다. "난 모르겠어"라고 말할 수 있는 환경을 만들자는 뜻이었다. 정답은 여기에 있지 않다, 하지만 8월의 일이 있은 지 지금 거의 2개월가 지났다. 금요일 오후 배포는 이제 거의 없다. 긴급으로 생기면 팀장과 CTO가 직접 와서 상황을 본다. 내 휴대폰 알림이 울려도, 그건 정말 급할 때만이다. 근데 솔직히 말해서, 나는 여전히 금요일 퇴근 후 슬랙 앱을 음소거한다. 완전히 차단하는 건 아니고, "중요" 태그가 달린 메시지들만 알람이 오도록 설정했다. 그리고 화요일부터 금요일까지는 그 설정도 안 본다. 그냥 슬랙 앱을 삭제했다. 회사 노트북은 회사에 두고, 퇴근하면서 PC를 종료한다. 아내가 최근에 물었다. "일 생각 안 하니?" 나는 "일 생각이 나면 월요일까지 기다리지 뭐."라고 대답했다. 그 대답에 아내는 웃었고, 나도 웃었다. 하지만 속으로는 이렇게 생각했다. 일이 정말 나가리면, 그건 내 책임만이 아니다. 그걸 수습할 시스템과 팀, 회사의 문제도 있다. 내가 토요일 오전 11시에 알림 하나를 못 봤다고 해서, 전체 배포 프로세스가 무너져서는 안 된다. 만약 그게 무너지는 거라면, 그건 내 휴대폰 설정이 아니라 회사의 시스템이 약한 거다. 그래서 나는 이제 다르게 생각한다. 슬랙을 음소거하는 게 죄책감이 아니라, 권리라고. 정시 퇴근이 "게으름"이 아니라 당연한 일과라고. 배포 담당자가 주말 연락이 안 돼도 롤백할 수 있는 시스템이 갖춰지는 게 "프로페셔널"이라고. 다음 달 예산 회의에서, 내가 모니터링 자동화 도구 도입을 건의하기로 했다. 그리고 배포 후 자동 테스트 강화도 건의하기로 했다. 롤백 자동화 시스템도. 왜냐하면 결국, 문제의 답은 개발자의 주말 시간에 있지 않으니까.좋은 시스템도 결국은 휴일에 음소거를 믿고 일어난다.

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

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

레거시 코드와의 전쟁: 언제까지 봐줘야 하나 월요일 아침, 또 시작된다 월요일 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년 후에 누군가에겐 "왜 이렇게 만들었어?"라는 질문을 받을 거다. 그건 피할 수 없는 운명이다. 그래서 내