자신이 짠 코드에 확신이 없는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-10-10

“돌아가기는 하는데, 이게 맞는 코드인지 잘 모르겠어요.”

멘토링을 진행하면서 1~2년 차 백엔드 개발자들에게 가장 자주 듣는 고민 중 하나입니다. 기능은 분명히 동작하고 테스트도 통과합니다. 하지만 PR을 올리거나 누군가 코드를 들여다볼 때마다 마음 한구석이 불안합니다.

코드가 돌아가는데도 왜 확신이 서지 않을까요? 문법을 몰라서가 아닙니다. 코드를 작성하면서 마주친 갈림길에서 진짜 선택을 내린 적이 없기 때문입니다.

검색해서 복사한 코드는 내 코드가 되지 않습니다

200명이 넘는 멘티들을 만나면서 똑같은 모습을 수없이 확인했습니다. 요구사항을 받으면 곧바로 검색창을 켭니다. 블로그나 AI가 제안한 예제에서 작동하는 조각들을 가져와 이어 붙입니다. 실행 버튼을 눌렀을 때 에러 없이 결과가 나오면 안도하고 커밋을 찍습니다.

하지만 이 과정에서 빠진 것이 있습니다. “왜 이 방식을 골랐는가”, “다른 대안과 비교했을 때 무엇을 포기했는가”에 대한 사유입니다. 스스로 고민하고 검증한 결론 대신 남이 성공한 결과물만 옮겨왔으니, 코드 리뷰에서 “이 로직 왜 이렇게 짰어요?”라는 질문을 받는 순간 얼어붙을 수밖에 없습니다.

선택한 대가를 계산할 때 코드에 확신이 생깁니다

소프트웨어 개발에 완벽한 무결점 코드는 존재하지 않습니다. 10년 넘게 실무에서 코드를 짜면서 배운 사실은, 모든 구현은 무언가를 얻는 대신 다른 무언가를 내주는 교환이라는 점입니다.

멘토링 3주 차에 한 멘티가 조회를 빠르게 만들겠다며 Redis 캐시를 붙여왔습니다. 그 멘티에게 물었습니다. “데이터가 수정될 때 정합성은 어떻게 맞추나요?” 대답하지 못했습니다. 캐시의 빠른 응답 속도만 보고, 정합성 유지라는 비용을 계산하지 않았기 때문입니다.

코드에 확신이 있는 개발자는 결점 하나 없는 코드를 완성한 사람이 아닙니다. “조회 성능을 얻기 위해 메모리를 더 쓰고 정합성 관리 비용을 감수했다”처럼, 자신이 선택한 이득과 감당할 한계를 선명하게 아는 사람입니다.

커밋 버튼을 누르기 전 딱 한 가지 질문만 던지십시오

내 코드에 확신을 채우는 방법은 단순합니다. 코드를 완성하고 커밋하기 직전, 스스로에게 딱 한 줄만 물어보십시오.

“누군가 왜 이렇게 짰냐고 물었을 때, 다른 대안 대신 이 방식을 고른 이유를 1분 안에 설명할 수 있는가?”

이 질문에 곧바로 스스로 답하지 못한다면 아직 코드를 보낼 준비가 되지 않은 것입니다. 조금 느려도 괜찮습니다. 남의 코드를 붙여넣고 매일 불안해하는 개발자와, 단 열 줄을 짜더라도 대안과 한계를 짚고 넘어가는 개발자는 1년 뒤 완전히 다른 실력을 갖추게 됩니다. 단순히 돌아가는 코드를 넘어, 선택의 이유가 남아야 비로소 내 코드가 됩니다.