Showing Posts From

코드

• 10 Dec, 2025
• • 시니어

옛날에 짠 코드 다시 보면서 '이때가 좋았지' 하는 감정

토요일 오후의 발견 회사 레포지토리를 뒤지다가 10년 전 코드를 발견했다. 프로젝트명: CRM v2.0 마지막 커밋: 2014년 3월 15일 커밋 메시지: "결제 모듈 리팩토링 완료. 테스트 통과." 파일을 열었다. 스크롤을 내렸다. "아, 이거..."깨끗했다. 정말 깨끗했다. 메서드 하나가 20줄. 주석도 적절히. 변수명도 명확하고. 테스트 커버리지 85%. 지금 내가 짜는 코드는 이렇지 않다. 2014년의 나 당시 나는 35살이었다. 선임 개발자. 팀원 3명. 관리 업무는 거의 없었다. 회의는 주 2회. 나머지는 다 코딩. 그때는 시간이 있었다. 아침 10시에 출근해서 저녁 7시까지. 점심 1시간 빼고 전부 코딩. 회의 끝나면 바로 IDE 켰다. 슬랙 알림은 10개도 안 왔다. 코드 리뷰는 내가 받는 입장이었다. 부장님이 꼼꼼하게 봤다. "여기 왜 이렇게 했어?" 물으면 설명했다. 고칠 건 고쳤다. 지금은 내가 리뷰하는 입장이다. 하루에 PR 5개. 제대로 보려면 2시간. 하지만 회의 때문에 10분씩 쪼개서 본다. "LGTM" 달고 승인. 미안하다.그때는 리팩토링할 시간이 있었다. "이 부분 좀 이상한데?" 싶으면 바로 고쳤다. 3시간 걸려도 괜찮았다. 완벽하게 만들 수 있었다. 지금은 "일단 돌아가게" 하고 넘어간다. 리팩토링은 다음 스프린트에. 하지만 다음 스프린트에는 새 기능이 들어온다. 리팩토링은 또 미뤄진다. 기술 부채가 쌓인다. 코드를 읽으면서 오래된 코드를 한 줄씩 읽었다. public class PaymentService { private final PaymentGateway gateway; private final TransactionRepository repository; public PaymentResult process(PaymentRequest request) { validateRequest(request); Transaction transaction = createTransaction(request); PaymentResponse response = gateway.charge(transaction); return saveAndReturn(transaction, response); } }단순했다. 명확했다. 한눈에 들어왔다. 요즘 코드는 이렇지 않다. 어노테이션 10개. 추상화 레이어 3개. "확장성을 위해서" 라고 했는데 결국 안 쓴다. 그때는 필요한 것만 만들었다. YAGNI. You Aren't Gonna Need It. 그 원칙을 지켰다. 지금 필요한 기능만. 나중에 필요하면 그때 추가. 지금은 "나중에 이거 필요할 수도..." 하면서 미리 만든다. 기획자가 "혹시 이것도..." 하면 "네" 한다. 시간 없다고 하면 "파트장님이 안 된대요" 소리 듣는다. 그래서 코드가 복잡해진다.테스트 코드도 있었다. @Test public void 결제_성공_테스트() { // given PaymentRequest request = createValidRequest(); // when PaymentResult result = service.process(request); // then assertThat(result.isSuccess()).isTrue(); }Given-When-Then. 깔끔했다. 요즘은 테스트 코드 짤 시간이 없다. "일정이 빡빡해서요." 후배들한테 "테스트 좀 써" 하면서 나도 안 쓴다. 이중잣대다. 알고 있다. 그때가 좋았던 이유 커밋 로그를 더 봤다. 2014년 3월 한 달간 커밋 60개. 거의 매일. 주말에도 몇 번. 지금은? 한 달에 10개. 대부분 "회의록 업데이트", "문서 수정". 실제 코드 커밋은 3개. 관리자가 되면서 달라졌다. 파트장 달고 나서 회의가 늘었다. 일정 조율. 리소스 배분. 타 부서 협업. 임원 보고. 코딩은 "남는 시간에" 하는 거다. 하지만 남는 시간은 없다. 오전 10시: 데일리 스탠드업 오전 11시: 주간 계획 회의 오후 1시: 점심 오후 2시: 기획팀 미팅 오후 4시: 임원 보고 준비 오후 5시: 임원 보고 오후 6시: 1on1 (후배 2명) 코딩은 언제? 저녁 8시. 사무실 조용해지면. 하지만 집중력이 예전 같지 않다. 한 시간 하면 피곤하다. 그때는 4시간도 했는데. 코드가 아니라 시간 사실 코드가 문제가 아니었다. 10년 전 코드가 더 좋은 게 아니다. 그때 나한테 시간이 있었던 거다. 생각할 시간. 설계할 시간. 리팩토링할 시간. 테스트 짤 시간. 지금은 그 시간이 없다. "파트장님 잠깐만요." 하루에 10번. "이거 언제까지 되나요?" 하루에 5번. "회의 하나 잡아도 될까요?" 하루에 3번. IDE 켜고 5분 지나면 누가 부른다. 집중은 불가능하다. 깊은 작업(Deep Work)은 옛날 얘기다. 지금은 얕은 작업(Shallow Work)만 가능하다. 10분씩 쪼개서. 그래서 코드 품질이 떨어진다. 시간 부족은 핑계가 아니다. 현실이다. 후배들의 코드 팀 후배들 코드를 봤다. 김 대리 코드: 깔끔하다. 주석도 있다. 테스트도 있다. 이 사원 코드: 최신 기술 잘 쓴다. 코틀린 코루틴까지. 부럽다. 걔네는 시간이 있다. 회의 적다. 관리 업무 없다. 순수하게 개발만. 나도 그랬다. 10년 전에. "대리님, 이 부분 어떻게 생각하세요?" 김 대리가 물었다. 페이먼트 모듈 설계. "음... 이렇게 하면 어때?" 조언했다. 20년 경력의 노하우. 설계 패턴. 예외 처리. "오, 좋네요!" 김 대리가 구현한다. 내가 조언한 대로. 더 잘 만든다. 기쁘기도 하고 씁쓸하기도 하다. 내 지식으로 후배가 좋은 코드를 짠다. 나는 직접 못 짠다. 이게 관리자의 역할인가? 임원이 되면 부장님이 말했다. "박 파트장, 내년에 임원 트랙 타면 어때?" 임원. 연봉 1억 2천. 스톡옵션. 전용 주차. 사무실도 따로. 대신 코딩은 완전히 못 한다. "생각해보겠습니다." 거짓말이다. 이미 답은 정했다. 안 한다. 임원 되면 개발자 아니다. 경영자다. 숫자 보고 사람 관리하고 전략 짜고. 코드는 안녕이다. 그건 싫다. 차라리 지금처럼 반반이 낫다. 관리 50%, 개발 50%. 비록 개발 시간이 부족하지만 아예 없는 것보단 낫다. 10년 전 코드를 보면서 생각했다. "그때로 돌아갈 순 없지." 35살로 돌아가면? 지금의 연봉은 포기. 지금의 직급도 포기. 지금의 영향력도 포기. 대신 코딩 시간은 얻는다. 안 할 거다. 현실적이지 않다. 하지만 가끔 상상한다. 타협점 완벽한 코드는 못 짠다. 인정한다. 하지만 아예 안 짤 순 없다. 최근에 규칙을 정했다.주 2회, 2시간씩 "개발 시간" 캘린더 블락 그 시간엔 회의 안 잡음 (임원 부르면 어쩔 수 없지만) 작은 거라도 직접 구현 (버그 수정, 리팩토링) 한 달에 최소 5개 실제 코드 커밋완벽하진 않다. 10년 전처럼은 못 한다. 그래도 안 하는 것보단 낫다. 어제 작은 기능 하나 구현했다. 로그 포맷 개선. 2시간 걸렸다. PR 올렸다. 후배들이 리뷰했다. "오 깔끔하네요!" "역시 파트장님" 기분이 좋았다. 10년 전만큼은 아니지만, 그래도 좋았다. 레거시와 향수 저녁 9시. 회사 불 껐다. 10년 전 코드 파일을 닫았다. "그때가 좋았지." 사실이다. 그때가 더 좋았다. 하지만 그때로는 못 돌아간다. 지금의 나는 관리도 하고 개발도 하는 사람이다. 둘 다 완벽하게는 못 한다. 타협하면서 산다. 그게 45살 파트장의 현실이다. 집에 가는 길. 핸드폰을 봤다. 김 대리가 PR 올렸다. "결제 모듈 v3.0 - 리팩토링 완료" 코드를 열어봤다. 깔끔했다. 내가 조언한 대로. 아니, 더 잘했다. "Approve" 눌렀다. 댓글 달았다. "Good job. 10년 전 내 코드보다 낫네요." 김 대리가 답했다. "ㅋㅋㅋ 과찬이십니다. 파트장님 코드 보고 배웠습니다." 웃었다. 내 코드는 예전만 못하다. 하지만 내 지식은 후배들에게 간다. 그것도 나쁘지 않다.옛날 코드는 박물관에 두고, 오늘 할 수 있는 거라도 한다.

• 02 Dec, 2025
• • 세대차이

후배 코드 리뷰, '이게 뭐지?' 하는 순간들

후배 코드 리뷰, '이게 뭐지?' 하는 순간들 출근했다. 10시 30분. 회의 3개 캔슬했다. 코드 리뷰 하는 날이니까. 후배 준호가 PR 올렸다. 제목은 "Next.js 마이그레이션 - ISR 최적화". 나는 Java 개발자다. Spring 안에서 20년을 살았다. 그게 자랑스러웠다. 한때는. 지금은 이 PR 앞에서 마우스만 움직인다. 화면 켰을 때의 그 느낌 export async function getStaticProps(context) { const { revalidate } = context.params; const data = await fetchUserData(revalidate); return { props: { data }, revalidate: parseInt(revalidate) || 3600, }; }뭐다? ISR? Incremental Static Regeneration? 스프링에서는 요청 올 때 마다 컨트롤러 탄다. 그게 맞다고 생각했다. 20년간. 근데 이건 빌드 타임에 정적으로 생성하고 주기적으로 리제너레이트 한다고? 부분적으로? 콤마 몇 개 더 치고 '음, 좋은 시도'라고 댓글 달 수도 있다. 근데 난 팀장이다. 파트장이다. 이게 맞는 구조인지 왜 이렇게 했는지 물어봐야 한다. 그런데 물어보면 내가 모르는 게 탄로난다. 좋다. 조금 더 읽어보자.과신은 어제의 나 작년만 해도 나는 싹싹했다. 후배들 코드 봐도 '아, 이건 이렇게 하면 더 좋지', '동시성 이슈 여기 있네', 이 정도면 지적했다. 경험에서 나오는 당당함. 그게 리더십이라고 생각했다. 근데 지금은 다르다. 준호의 코드를 보고 있으면 다섯 가지가 동시에 일어난다. 첫째, '오, 이건 좋네'라는 생각. 둘째, '근데 이게 맞나?'라는 의심. 셋째, '혼자 공부하기엔 시간이 없는데?'라는 패배감. 넷째, '물어봐도 되나?'라는 초초함. 다섯째, '내가 리드할 수 있나?'라는 불안감. 다섯 가지가 한 번에 온다. 커피 한 모금 마신다. 세 번째 커피다. 아직 11시 30분. 리뷰를 달아야 한다. 뭔가 말을 해야 한다. 팀장이 조용히만 있으면 그게 더 이상하다. 그래서 일반적인 조언을 단다. "성능 고려했으니 좋네", "테스트 코드는?", "에러 핸들링 여기 확인해봐". 이건 모든 코드에 통하는 말이다. 경험의 본질인 척 하면서 실은 피하는 것 같은 느낌. 싫다. 모르는 게 쌓일 때 슬랙에 핑. 수진이다. 러스트로 뭔가 새로 만들고 있다고. 성능이 좋다고. 러스트는 뭐야? 뭐 하는 언어야? 동료들은 이미 다 안다. 20대 개발자들은 당연히 안다. 심지어 인턴도 안다. 나만 모른다. 모르는데 일이 자꾸 몰려온다. "박시니어, 이 러스트 코드 한번 봐주실래요? 성능 체크." 봐줄까? 못 봐줄까? 봐줄 수도 없으니 못 봐주지. 근데 말을 해야 한다. "일단 올려봐. 주말에 한번 봐볼게." 거짓말이다. 주말엔 아들 수학 봐주고, 딸 학원 픽업하고, 아내 병원 동반 가고. 주말에 새로운 언어 배울 시간은 없다. 근데 그렇게라도 말해야 팀장 자리를 지킬 수 있다. 이게 뭐하는 짓인가. 책임과 무지의 타협점 회의실. 4시간 스프린트 계획 회의. 아, 내일 기술 스택 결정 회의도 있다. 마이크로프론트엔드 도입 검토. 누가 주도할 거냐고? 당연히 나다. 파트장이니까. 근데 난 마이크로프론트엔드 논문 안 읽었다. 사례 연구도 안 했다. 유튜브 영상 하나 봤나? 그것도 작년 영상이다. 명일 회의에 가서 뭐 할 거냐고? 다들 한 바퀴 말하게 듣고, 좋은 질문 하는 척 몇 개 던지고, "좋은 의견들 많네요. 이건 좀 더 깊게 검토하고 주 목요일에 최종 결정"이라고 말할 것 같다. 이게 리더십이 아니라는 건 안다. 근데 이 정도면 일은 돌아간다. 팀이 움직인다. 후배들은 '아, 파트장이 고민 중이시네' 정도로 생각한다. 내가 무엇을 모르는지는 누도 모른다. 왜냐면 나도 내가 뭘 모르는지 모르니까.정직하고 싶은데 리더는 못 할까 어제 준호한테 따로 말했다. 커피 마시면서. "준호, ISR 구현 좋네. 근데 왜 이 방식으로 했어? 다른 옵션도 생각했어?" 준호가 웃었다. "파트장님도 궁금하신 거죠? 저도 처음엔 몰랐거든요. 회사에서 한 프로젝트 봤는데, 우리 상황하고 비슷해서." 그럼 돼. 정직했다. 난 몰랐고, 준호는 알았다. 그게 끝이다. 그래서 더 물었다. "그럼 성능 개선은 얼마나 됐어?" "로딩이 40% 빨라졌어요." "숫자 좋네. 모니터링은?" "대시보드 연결했습니다." 이래. 이 정도면 충분하다. 내가 이 기술을 완벽하게 몰라도, 준호는 알고 있고, 결과는 나왔고, 리스크는 모니터링하고 있다. 이게 리더십 아닐까. 모든 걸 아는 리더가 아니라, 모르는 걸 인정하고 팀을 믿는 리더. 근데 이게 얼마나 오래갈까. 5년? 10년? 기술은 계속 변한다. 매 6개월마다 뭔가 새로 나온다. 모르는 게 자꾸만 쌓인다. 언젠가는 이 불안감이 팀에 들릴 거다. "파트장님, 이건 어때요?" 물을 때, 내 대답이 자꾸 일반적일 거다. 구체적이지 않을 거다. 경험에서 나오는 자신감이 없을 거다. 그럼 내가 뭐냐. 그냥 세션 잡는 관리자냐. 싫다. 뒤처진다는 건 틀렸다는 게 아니고 금요일. 야근 했다. 준호 코드 다시 봤다. 이번엔 프리젠테이션 영상 보고. 유튜브에서 ISR 강의 찾아서 봤다. 30분짜리 영상인데, 처음 10분만 봤다. 졸렸다. 그런데 조금 느껴졌다. ISR이 뭔지. 왜 필요한지. 준호가 왜 이렇게 했는지. 모든 걸 이해하진 못했다. 상세한 메커니즘은 여전히 모호하다. 근데 충분히 이해했다. 월요일 회의 때 질문할 수 있을 정도로는. 좋은 질문을요. 정직한 질문을. 아, 그리고 깨달았다. 20년 경력이 무색한 게 아니라, 개발 방식이 달라진 거다. 내가 배운 건 서버 중심. 요청-응답. 상태 관리. 이건 클라이언트 중심. 정적 생성. 캐시 전략. 완전 다른 세상이다. 근데 컴퓨터 공학의 본질은 같다. 효율성, 확장성, 안정성. 그것만 봐도 된다. 도구는 바뀌어도 사고 방식은 통한다. 이 정도면, 리더일 수 있을 것 같다. 그런데 이게 계속 될까. 매번 이렇게 주말에 공부해야 하나. 야근하고 영상 봐야 하나. 음. 일단은 그런 것 같다. 이 세상에서 살아가려면. 근데 한 가지 확실한 건, 내가 모른다고 팀이 멈추진 않는다는 거다. 준호는 준호대로 커간다. 수진이는 러스트로 뭔가 만든다. 후배들은 후배들 속도대로 간다. 나는 내 속도대로 따라가면 된다. 모를 때도 있지만, 가끔 알 때도 있으니까.모르는 게 있으면, 아는 척하지 말고 배우자. 그게 리더다.