주니어에서 시니어로, 실력보다 먼저 달라진 것들

처음 개발자로 입사했을 때 저는 빨리 많은 코드를 작성하는 사람이 인정받는다고 생각했습니다. 맡은 기능을 남들보다 먼저 끝내고, 어려운 문법을 알고 있으며, 질문을 적게 하는 것이 실력의 기준이라고 여겼습니다. 하지만 몇 년이 지나고 여러 업무를 겪으면서 생각이 조금씩 바뀌었습니다. 시니어 개발자는 단순히 어려운 기술을 많이 아는 사람이 아니라, 불확실한 상황에서 문제의 방향을 잡고 주변 사람들이 일하기 편하게 만드는 사람에 가까웠습니다. 이 글에서는 제가 주니어 시절에 했던 실수와 그 실수를 고치며 업무를 바라보는 방식이 어떻게 달라졌는지 기록해 보려고 합니다.

처음에는 빠르게 만드는 것만 중요하다고 생각했다

첫 회사에서 맡은 일은 사내 관리 화면에 새로운 기능을 추가하는 업무였습니다. 저는 요구사항을 대충 읽은 뒤 바로 편집기를 열고 코드를 작성했습니다. 화면이 보이고 저장까지 되자 스스로 꽤 잘했다고 생각했지만, 며칠 뒤 실제 사용자가 입력할 수 있는 값의 범위를 제가 잘못 이해했다는 사실이 드러났습니다. 담당자는 같은 내용을 몇 번이나 설명해야 했고, 저는 이미 만든 부분을 상당히 뜯어고쳐야 했습니다. 그때 처음으로 빨리 시작하는 것과 빨리 끝내는 것은 다르다는 사실을 체감했습니다. 이후에는 작업을 시작하기 전에 제가 이해한 내용을 짧게 문서로 정리하고, 모호한 부분을 먼저 확인하는 습관을 들였습니다.
그 습관이 생긴 뒤에도 실수는 계속됐습니다. 한번은 일정에 쫓긴다는 이유로 기존 화면의 동작 방식을 충분히 살피지 않고 새로운 버튼을 추가했습니다. 제 컴퓨터에서는 자연스럽게 작동했지만, 다른 메뉴에서 같은 정보를 수정한 뒤에는 화면에 예전 값이 남는 문제가 생겼습니다. 원인은 기능 하나만 보고 주변 흐름을 확인하지 않았던 데 있었습니다. 당시에는 제 작업 범위가 작으니 영향도 작을 것이라고 판단했는데, 실제 서비스에서는 작은 변경 하나가 여러 사람의 업무 순서를 건드릴 수 있었습니다. 그 일을 계기로 저는 기능을 만들 때 성공하는 장면뿐 아니라 사용자가 어떤 순서로 접근하고, 중간에 무엇을 바꿀 수 있는지도 함께 살피기 시작했습니다.

질문을 줄이는 대신 질문의 질을 높였다

주니어 시절의 저는 질문하는 일을 약점처럼 느꼈습니다. 같은 팀 선배에게 자주 묻다 보면 준비가 부족한 사람으로 보일까 걱정했고, 그래서 한참을 혼자 붙잡고 있다가 결국 막힌 부분만 들고 갔습니다. 문제는 그때쯤이면 이미 반나절이 지나 있었다는 점입니다. 어느 날 화면 전환 오류를 해결하지 못해 퇴근 직전까지 고생하다가 선배에게 상황을 설명했는데, 선배는 제가 시도한 방법과 확인한 결과를 듣더니 몇 분 만에 원인을 좁혔습니다. 그날 이후 질문할 때는 무엇을 하려는지, 어디까지 확인했는지, 예상과 실제가 어떻게 달랐는지를 먼저 정리했습니다. 질문의 개수가 줄어든 것은 아니지만, 대화가 훨씬 짧고 선명해졌습니다.
반대로 제가 조금 익숙해진 뒤에는 후배의 질문을 성급하게 받아치는 실수를 했습니다. 이미 아는 내용이라고 생각해 결론부터 말했고, 후배는 고개를 끄덕였지만 실제로는 문제를 해결하지 못했습니다. 나중에 다시 이야기를 나누면서 그 사람이 막힌 지점은 제가 생각한 부분과 전혀 다르다는 것을 알았습니다. 저는 답을 전달하는 데만 신경 썼고, 상대가 문제를 바라보는 과정을 확인하지 않았습니다. 그 뒤부터는 먼저 상대에게 어떤 결과를 기대했는지, 실제로 어떤 현상이 나타났는지를 묻습니다. 바로 정답을 알려주는 것이 항상 가장 빠른 도움은 아니었습니다. 스스로 원인을 찾을 수 있도록 사고의 순서를 함께 정리해 주는 편이 다음 문제를 해결하는 데 더 오래 남았습니다.

작업자가 아니라 결과의 책임자로 생각하기

직급이 올라가며 가장 부담스러웠던 변화는 제 작업만 잘하면 된다는 생각을 버리는 일이었습니다. 예전에는 맡은 화면을 완성하고 제 부분에서 문제가 없으면 업무가 끝났다고 여겼습니다. 하지만 어느 순간부터 일정이 늦어지는 이유를 찾고, 다른 팀의 준비 상황을 확인하고, 출시 이후 사용자가 겪을 불편까지 신경 써야 했습니다. 한번은 기능 자체는 제때 끝냈지만 관련 안내가 늦어 사용 부서가 준비하지 못한 일이 있었습니다. 저는 개발 일정만 지켰다고 생각했지만, 조직의 관점에서는 업무가 완료되지 않은 상태였습니다. 그 경험은 결과를 코드의 완성 여부로만 판단하면 안 된다는 점을 분명히 알려주었습니다.
그렇다고 모든 일을 혼자 끌어안는 것이 책임감은 아니었습니다. 한 프로젝트에서 제가 일정과 구현을 모두 통제하려고 하다가 작은 결정까지 제게 몰렸고, 결국 중요한 작업의 확인이 늦어진 적이 있습니다. 팀원들은 제가 바쁜 것을 알면서도 어디까지 맡아도 되는지 판단하기 어려워했습니다. 당시에는 제가 직접 확인해야 품질이 유지된다고 믿었지만, 실제로는 정보가 한 사람에게만 모여 속도가 떨어졌습니다. 이후에는 업무를 나눌 때 결과물의 기준과 마감 시점을 먼저 합의하고, 진행 중인 사람이 스스로 판단할 수 있는 범위를 함께 정했습니다. 시니어의 역할은 모든 답을 들고 있는 것이 아니라, 팀이 각자의 판단으로 앞으로 나아갈 수 있게 만드는 데 있다는 생각이 자리 잡았습니다.

기술보다 오래 남은 성장의 기준

제가 지금도 중요하게 보는 능력은 문제를 작게 나누는 힘입니다. 큰 요청을 받으면 예전에는 완성된 결과만 상상하며 막막해했지만, 이제는 사용자가 가장 먼저 필요한 부분과 나중에 추가해도 되는 부분을 구분합니다. 예를 들어 업무 승인 절차를 바꾸는 일을 맡았을 때 처음에는 모든 예외 상황을 한 번에 처리하려고 했습니다. 그러나 실제 담당자들과 이야기를 나누니 당장 필요한 것은 승인 상태를 명확히 보여주는 기능과 잘못 눌렀을 때 되돌릴 수 있는 방법이었습니다. 우선순위를 다시 잡은 덕분에 핵심 흐름을 먼저 안정시킬 수 있었고, 이후의 세부 요구도 훨씬 구체적으로 논의할 수 있었습니다. 복잡한 문제를 한 번에 해결하려는 태도보다, 확인 가능한 작은 단위로 나누는 습관이 제 성장을 크게 앞당겼습니다.
돌이켜보면 주니어에서 시니어로 가는 과정은 어느 날 갑자기 실력이 폭발한 경험이 아니었습니다. 잘못 이해한 요구사항을 다시 확인하는 법을 배웠고, 실패를 숨기기보다 영향 범위와 다음 조치를 먼저 설명하려고 노력했습니다. 모르는 것을 인정하는 데 익숙해졌고, 혼자 해결한 결과보다 팀 전체가 같은 방향을 이해하는 결과를 더 중요하게 생각하게 됐습니다. 여전히 낯선 문제 앞에서는 긴장하고, 판단이 틀릴 때도 있습니다. 다만 예전처럼 실수를 능력의 부족으로만 받아들이지는 않습니다. 무엇을 놓쳤는지 기록하고 다음 작업의 기준을 바꾸면, 실패도 경력 안에서 쓸모 있는 자료가 된다고 믿습니다.

성장은 직함보다 일하는 방식에서 드러난다

저는 시니어라는 호칭을 얻는 순간 성장의 목표가 끝난다고 생각하지 않습니다. 오히려 이제는 제가 무엇을 아는지보다, 불분명한 문제를 어떻게 정리하고 다른 사람과 어떤 방식으로 협력하는지가 더 중요해졌습니다. 아직 주니어라서 부족하다고 느끼는 분이라면 모든 것을 혼자 해내려 하기보다, 자신의 판단 과정을 기록하고 작은 약속을 지키는 것부터 시작해도 충분합니다. 오늘 만든 결과물 하나, 동료와 나눈 질문 하나, 실패 뒤에 남긴 짧은 메모 하나가 시간이 지나면 일하는 사람의 색깔을 만듭니다. 저 역시 완성된 개발자와는 거리가 멀지만, 어제보다 더 정확하게 듣고 더 책임 있게 설명하는 사람이 되려 합니다. 커리어의 다음 단계는 직함이 정해주는 것이 아니라, 매일 문제를 대하는 태도가 조금씩 바뀌며 만들어진다고 믿습니다.