개발자에서 테크 리드로: 역할이 바뀌는 순간

처음 테크 리드라는 제안을 받았을 때 저는 좋은 개발자로 인정받았다는 생각부터 들었습니다. 어려운 문제를 빨리 풀고, 남들보다 많은 코드를 작성하면 자연스럽게 팀을 이끌 수 있을 거라고 믿었습니다. 하지만 실제로 역할이 바뀌고 나니 제가 잘하는 일과 팀에 필요한 일이 전혀 같지 않다는 사실을 금방 깨달았습니다. 손이 빠른 개발자였던 제가 이제는 다른 사람이 제대로 일할 수 있도록 방향과 환경을 마련해야 했습니다.
당시 팀에서는 결제 화면을 새로 만드는 작업을 진행하고 있었습니다. 저는 일정이 늦어지는 것을 보고 직접 핵심 부분을 맡아 며칠 동안 몰입했습니다. 결과적으로 제 작업은 빨리 끝났지만, 다른 팀원들은 제가 어떤 판단을 했는지 충분히 알지 못했고 뒤늦게 연결 작업에서 여러 문제가 생겼습니다. 저는 일을 구해냈다고 생각했지만, 실제로는 팀의 흐름을 제 쪽으로 끌어와 병목을 만든 셈이었습니다.

처음에는 가장 어려운 일을 직접 맡았다

개발자 시절에는 문제가 복잡할수록 제가 해결해야 한다는 생각이 강했습니다. 모호한 요구사항을 정리하고, 구조를 잡고, 구현까지 마치면 성과가 눈에 보였기 때문입니다. 테크 리드가 된 뒤에도 같은 방식으로 행동했습니다. 그런데 제가 중요한 일을 모두 가져가자 팀원들은 판단할 기회를 잃었고, 사소한 결정까지 제 승인을 기다리기 시작했습니다. 빠르게 움직이려던 의도가 오히려 팀 전체를 느리게 만들었습니다.
이 문제를 인정하게 된 계기는 작은 장애 대응이었습니다. 한 팀원이 작성한 기능에서 예상하지 못한 오류가 발생했는데, 저는 당시 다른 업무를 처리하느라 자세한 맥락을 파악하지 못했습니다. 평소라면 제가 직접 수정했겠지만 이번에는 원인을 찾은 팀원에게 해결 방향을 설명해 달라고 요청했습니다. 그는 처음에는 주저했지만 문제의 원인과 수정안을 차분히 발표했고, 저는 그 순간 팀원이 부족한 것이 아니라 제가 기회를 주지 않았다는 사실을 알게 됐습니다.

결정하는 사람보다 질문하는 사람이 되기

그 뒤부터 회의에서 제 의견을 가장 먼저 말하지 않으려고 노력했습니다. 예전에는 논의가 길어지면 제가 결론을 정해 주는 것이 효율적이라고 여겼지만, 먼저 말한 사람의 의견이 회의 전체를 쉽게 끌고 간다는 점을 경험으로 배웠습니다. 그래서 “지금 가장 걱정되는 부분은 무엇인가요?”, “다른 선택지는 어떤 결과를 만들까요?”처럼 질문을 던지고 잠시 기다렸습니다. 처음에는 침묵이 어색했지만, 시간이 지나면서 팀원들이 서로의 근거를 설명하기 시작했습니다.
물론 질문만 한다고 좋은 리더가 되는 것은 아니었습니다. 한 번은 팀원이 일정에 영향을 줄 수 있는 선택을 하면서도 위험 요소를 충분히 알리지 않았고, 저는 의견을 존중한다는 이유로 결정을 그대로 두었습니다. 결국 예상보다 큰 수정이 필요해졌고, 일정은 사흘 밀렸습니다. 이 경험 이후 저는 자율성을 주되 판단에 필요한 정보와 마감 시점을 분명히 정하는 것이 제 역할이라는 기준을 세웠습니다.

기술보다 중요한 것은 맥락을 나누는 일

테크 리드가 된 뒤 가장 많이 바뀐 업무는 설명의 방식이었습니다. 이전에는 “이 구조가 더 낫다”라고 말하면 충분하다고 생각했지만, 이제는 왜 그런 선택을 했는지, 무엇을 포기했는지까지 공유해야 했습니다. 팀원이 구현 방향을 바꿔야 할 때도 단순히 지시하지 않고 사용자 영향, 일정, 이후 변경 가능성을 함께 설명했습니다. 설명에 시간이 더 들었지만 같은 질문이 반복되는 횟수는 눈에 띄게 줄었습니다.
한편으로는 모든 사람이 제 방식대로 일해야 한다는 욕심도 오래 남았습니다. 문서 형식이나 작업 순서가 마음에 들지 않으면 쉽게 간섭했고, 그때마다 팀원은 결과보다 제 취향을 맞추는 데 에너지를 썼습니다. 이를 깨닫고 나서는 결과에 영향을 주는 원칙과 개인적인 선호를 구분하려고 했습니다. 반드시 지켜야 할 기준은 적게 정하고, 나머지는 각자가 더 편한 방법을 선택하도록 맡겼습니다.

성과는 개인의 속도가 아니라 팀의 지속성에서 나온다

제가 테크 리드 역할을 받아들이는 데 가장 오래 걸린 부분은 성과의 기준이 달라진다는 사실이었습니다. 예전에는 제가 맡은 기능을 얼마나 정확하고 빠르게 완성했는지가 중요했습니다. 지금은 제가 자리를 비워도 팀이 멈추지 않는지, 경험이 적은 구성원이 다음 단계로 성장하고 있는지, 중요한 판단이 특정 한 사람의 기억에만 남아 있지 않은지가 더 중요합니다. 처음에는 제 이름이 덜 보이는 것 같아 불안했지만, 팀이 스스로 문제를 해결하는 순간마다 역할의 의미를 느꼈습니다.
제가 아직도 완벽한 테크 리드는 아니라고 생각합니다. 급한 상황에서는 예전처럼 직접 해결하고 싶은 마음이 올라오고, 의견 충돌이 생기면 결론을 빨리 내리고 싶어집니다. 다만 이제는 그 충동이 팀을 위한 것인지, 제가 통제감을 느끼고 싶은 것인지 한 번 더 묻습니다. 개발자에서 테크 리드로 넘어가는 순간은 직함이 바뀌는 날이 아니라, 내 실력보다 다른 사람의 성장을 더 중요한 결과로 받아들이는 날에 가깝습니다. 역할의 변화 앞에서 혼란을 겪는 분이라면, 모든 답을 혼자 갖추려 하지 말고 팀이 더 잘 판단하도록 돕는 작은 행동부터 시작해 보시길 바랍니다.