신입 개발자 시절에 알았더라면 좋았을 일곱 가지

처음 개발자로 입사했을 때 저는 빨리 인정받고 싶은 마음이 컸습니다. 선배가 사용하는 단축키를 그대로 외우고, 어려워 보이는 기술 이름을 대화 중에 한두 번씩 꺼내면 실력이 있어 보일 거라고 생각했습니다. 그래서 업무를 받으면 내용을 충분히 이해하기 전에 편집기부터 열고 손을 움직였습니다. 결과적으로 속도는 빠른 듯했지만, 며칠 뒤 제가 만든 기능에서 작은 문제가 연달아 발견됐습니다. 그때 알았습니다. 신입에게 필요한 것은 남보다 많은 것을 아는 태도가 아니라, 모르는 부분을 정확히 확인하고 하나씩 줄여 가는 습관이라는 사실을요.

▲ 관련 컬러 사진

처음부터 완벽하게 이해하려는 욕심을 내려놓기

입사 초기에 맡은 일은 화면에 간단한 목록을 보여 주는 기능이었습니다. 저는 별것 아니라고 판단하고 바로 작업을 시작했는데, 나중에 확인해 보니 목록의 정렬 기준과 빈 화면일 때의 처리 방식이 이미 팀 안에서 정해져 있었습니다. 질문 한 번이면 알 수 있는 내용이었지만, 준비가 부족해 보일까 봐 혼자 추측한 것이 문제였습니다. 그 뒤부터는 업무를 시작하기 전에 제가 이해한 내용을 짧게 정리했습니다. 입력은 무엇인지, 결과는 어떤 모습이어야 하는지, 예외 상황은 무엇인지 적어 두고 담당자에게 확인했습니다. 질문이 많아지는 것이 부끄러운 일이 아니라, 엉뚱한 방향으로 오래 달리지 않는 방법이라는 걸 배웠습니다.

작은 기록이 실수를 줄여 준다

저는 예전에는 머리가 좋으면 회의 내용을 모두 기억할 수 있다고 믿었습니다. 실제로는 회의가 끝난 뒤 세부 조건의 절반도 정확히 기억하지 못했습니다. 한 번은 숫자 표시 단위를 잘못 기억해 결과 화면을 수정했고, 다음 날 다시 원래 방식으로 되돌리는 일을 겪었습니다. 그 이후부터는 회의 중에 결정된 내용과 아직 결정되지 않은 내용을 구분해 메모했습니다. 하루가 끝나면 오늘 한 일, 막힌 이유, 내일 가장 먼저 확인할 일을 세 줄 정도로 정리했습니다. 거창한 문서가 아니어도 기록은 제 기억을 대신해 주었고, 다른 사람에게 상황을 설명할 때도 훨씬 차분해졌습니다. 신입 시절의 기록은 실력을 과시하는 자료가 아니라 실수를 반복하지 않기 위한 안전장치에 가깝습니다.

막혔을 때 오래 버티는 것이 능사는 아니다

제가 가장 많은 시간을 낭비했던 순간은 오류 원인을 혼자 붙잡고 있던 때였습니다. 어느 날 화면이 특정 조건에서만 제대로 표시되지 않았는데, 저는 한 줄씩 수정하며 세 시간 가까이 버텼습니다. 결국 선배에게 상황을 설명하자 선배는 제가 처음 확인한 조건과 실제 실행 조건이 다르다는 점을 몇 분 만에 찾아냈습니다. 당시에는 도움을 요청하는 일이 실력 부족을 인정하는 것처럼 느껴졌지만, 지금 생각하면 문제를 정리하지 않은 채 고집을 부린 시간이 더 아깝습니다. 도움을 청할 때는 무작정 안 된다고 말하기보다, 무엇을 시도했고 어떤 결과가 나왔는지, 제가 예상한 결과는 무엇이었는지를 함께 전달하는 편이 좋습니다. 이렇게 말하면 상대도 원인을 훨씬 빠르게 좁힐 수 있고, 저 역시 같은 문제를 다시 만났을 때 생각할 기준을 얻게 됩니다.

속도보다 흐름을 먼저 익히기

신입 때는 한 번에 많은 일을 처리하는 사람이 유능해 보였습니다. 저도 여러 업무를 동시에 잡고 조금씩 건드리는 방식을 따라 했지만, 실제로는 어느 것도 제대로 마무리하지 못했습니다. 오전에는 화면을 고치다가 점심 뒤에는 문서 내용을 수정하고, 오후에는 다른 기능의 문제를 살피는 식으로 움직이니 하루가 끝나도 완료된 일이 없었습니다. 특히 중간 상태를 정확히 기억하지 못해 같은 부분을 다시 살피는 일이 자주 생겼습니다. 그 뒤에는 할 일을 중요도와 마감 시점에 따라 나누고, 한 가지를 일정 수준까지 끝낸 다음 다음 일로 넘어갔습니다. 빠르게 보이는 것보다 지금 무엇을 마무리하고 있는지 분명히 아는 편이 장기적으로 더 빠릅니다. 업무의 흐름을 이해하면 낯선 일이 들어와도 우선순위를 스스로 판단하기 쉬워집니다.

기초를 부끄러워하지 않기

저는 입사 후 몇 달 동안 기본 문법을 다시 묻는 일을 피했습니다. 동료들이 당연하게 사용하는 표현을 이해하지 못해도 검색만 하며 넘어갔고, 그 결과 비슷한 내용을 매번 새로 찾아야 했습니다. 어느 날 간단한 동작 원리를 설명해 달라는 요청을 받았는데, 겉으로는 결과를 만들 수 있어도 왜 그렇게 동작하는지 설명하지 못했습니다. 그 일을 계기로 퇴근 후 짧은 시간을 정해 자료형, 흐름 제어, 함수의 역할처럼 이미 안다고 생각했던 내용을 다시 정리했습니다. 처음에는 초보로 돌아간 기분이었지만, 기초를 다시 살피니 복잡한 문제를 바라보는 속도가 달라졌습니다. 어려운 기술을 계속 추가하는 것보다 내가 자주 틀리는 기본 원리를 정확히 이해하는 편이 훨씬 오래 남는다는 것도 그때 체감했습니다.

사람과 일하는 능력도 개발자의 실력이다

처음에는 좋은 결과물만 내면 된다고 생각했습니다. 하지만 실제 업무에서는 사용자의 요구를 듣고, 기획자의 의도를 확인하고, 동료와 일정과 범위를 조율하는 과정이 결과만큼 중요했습니다. 저는 한 번은 요청받은 내용을 제 방식대로 해석해 기능을 만들었고, 완성 후에야 상대가 원한 방향과 다르다는 사실을 알게 됐습니다. 작업 자체는 틀리지 않았지만 목적을 놓친 셈이었습니다. 그 뒤부터는 대화할 때 제가 이해한 내용을 제 말로 다시 확인하고, 변경 사항이 생기면 짧게라도 공유했습니다. 의견이 다를 때 무조건 제 주장을 밀어붙이지 않고, 왜 그런 선택을 했는지와 어떤 문제가 생길 수 있는지를 설명하려고 했습니다. 개발자는 혼자 결과를 만드는 직업이 아니라, 여러 사람이 같은 방향을 바라보도록 연결하는 직업이라는 생각이 점점 분명해졌습니다.

성장 속도를 남과 비교하지 않기

입사 동기 중에는 새로운 내용을 빠르게 익히고 발표도 잘하는 사람이 있었습니다. 저는 그 모습을 보며 제 속도가 너무 느린 것 같아 조급해졌고, 한동안 퇴근 후에도 무리하게 공부했습니다. 하지만 피곤한 상태로 많은 내용을 밀어 넣으니 다음 날 거의 남지 않았고, 업무 집중력까지 떨어졌습니다. 이후에는 남의 공부량 대신 제가 지난달에 혼자 해결하지 못했던 일을 지금은 어디까지 이해하는지 비교하기 시작했습니다. 예전에는 오류 메시지 하나에도 당황했지만, 어느 순간부터는 상황을 나누고 확인 순서를 세울 수 있게 됐습니다. 이런 변화는 눈에 잘 띄지 않지만 분명한 성장입니다. 모든 신입이 같은 속도로 배우지 않으며, 중요한 것은 며칠 반짝하는 의욕보다 지치지 않고 계속 돌아오는 리듬을 만드는 일이라고 생각합니다.
신입 개발자에게 제가 꼭 전하고 싶은 말은 실수하지 말라는 뜻이 아닙니다. 실수는 피하기 어렵고, 저 역시 지금도 예상하지 못한 문제를 만납니다. 다만 실수한 뒤 숨기거나 대충 넘기지 말고, 왜 생겼는지 기록하고 다음 행동을 바꾸면 같은 경험이 자산으로 남습니다. 모르는 것을 인정하고 질문하는 용기, 작은 내용을 확인하는 습관, 맡은 일을 끝까지 설명할 수 있도록 정리하는 태도는 시간이 지나도 흔들리지 않는 힘이 됩니다. 처음부터 뛰어난 사람처럼 보이려고 애쓰기보다 오늘의 자신이 어제보다 한 가지라도 더 정확히 이해했는지를 살펴보셨으면 합니다. 느리더라도 스스로 생각하며 쌓은 경험은 결국 여러분만의 든든한 기반이 될 것입니다.