일정은 관리됐지만 기술은 관리되지 않았다

최근 몇 달의 업무 기록을 바탕으로 썼다. 특정 조직과 사람, 제품을 알아볼 수 있는 이름은 제거했고 수치는 집계 범위를 설명하는 데 필요한 수준으로 반올림했다.

최근 내가 일하고 싶은 환경을 생각하다가 이런 문장을 적었다.

최신 기술의 흐름과 현재 시스템의 사정을 함께 이해하고, 더 나은 방향으로 따라갈 의지를 가진 팀.

처음에는 조금 추상적인 말처럼 보였다. 최신 기술을 많이 도입하는 팀을 원한다는 뜻인지, 기술을 잘 아는 관리자를 원한다는 뜻인지도 모호했다.

내가 원하는 것은 둘 다 아니었다.

새 기술을 유행처럼 가져오는 팀도 아니고, Engineering Manager가 팀에서 가장 코드를 잘 쓰는 환경도 아니다. 내가 원한 것은 기술이 개인의 취향이나 선의에 기대지 않고 관리되는 환경이었다.

이 생각에 도달하기까지 최근 몇 달의 기록을 다시 살펴봤다. 기능 개발, 결함 수정, 성능 측정, 코드 리뷰, 기술 부채 정리와 배포 대응이 뒤섞여 있었다. 일정은 정해졌고 담당자도 있었다. 릴리스 절차와 QA 과정도 움직였다.

그런데 그 안에서 이런 질문은 자주 주인을 잃었다.

이 구조를 계속 유지해도 되는가?
지금 고쳐야 할 기술 부채는 무엇인가?
이 실험은 효과가 없을 때 어디서 멈출 것인가?
리뷰에서 발견한 위험을 누가 팀의 규칙으로 바꿀 것인가?
다음 분기에도 같은 문제가 반복되지 않게 하려면 무엇을 남겨야 하는가?

누가 언제 할지는 관리됐지만, 왜 해야 하고 무엇을 하지 않을지는 충분히 관리되지 않았다.

EM이 코드를 써야 한다고 생각하지 않는다

먼저 분명히 하고 싶은 것이 있다.

나는 Engineering Manager가 직접 코드를 써야 한다고 생각하지 않는다.

나도 예전에 팀장 역할을 맡았을 때 코드를 계속 썼다. 지금처럼 AI 도구가 있었다면 아마 더 많이 만들고, 더 넓게 리뷰하고, 더 빠르게 검증했을 것이다. 하지만 그것은 내가 선택한 일하는 방식이지, 모든 Engineering Manager에게 적용할 기준은 아니다.

팀의 규모가 커질수록 관리자가 직접 코드를 쓰는 것이 오히려 병목이 될 수도 있다. 관리자의 구현이 핵심 경로가 되면 회의와 조율이 늘어날 때 작업이 멈춘다. 직급의 영향 때문에 다른 개발자가 설계에 이견을 내기 어려워질 수도 있다. 관리자가 급한 마음으로 만든 우회로가 리뷰 없이 사실상의 표준이 되는 경우도 있다.

그래서 중요한 것은 커밋 수가 아니다.

Engineering Manager가 모든 기술의 답을 직접 만들 필요는 없다. 대신 다음은 책임져야 한다.

• 지금 팀이 풀어야 할 기술적 질문이 무엇인지 구분한다.
• 그 질문을 판단할 사람을 정한다.
• 판단에 필요한 정보와 시간을 확보한다.
• 결정한 방향이 실제 실행과 검증으로 이어지는지 확인한다.
• 잘못된 선택을 중단하고 다시 결정할 수 있는 구조를 만든다.

코드를 쓰지 않아도 된다. 하지만 이름에 붙은 Engineering까지 사라져서는 안 된다.

이 책임을 EM 혼자 수행해야 한다는 뜻도 아니다. 팀에 별도의 Tech Lead나 Staff Engineer가 있다면 기술 판단은 충분히 나눌 수 있다. 중요한 것은 누가 맡았는지 명확하고, 그 사람이 판단할 권한과 시간을 실제로 가지고 있는가다. 기술의 답은 위임할 수 있지만, 답이 만들어질 구조를 세우는 책임까지 공중에 띄울 수는 없다.

공개된 조직의 운영 방식에서도 비슷한 구분을 볼 수 있다. GitLab의 Engineering Management 안내는 기술 리더십과 사람을 이끄는 리더십을 서로 다른 경로로 설명한다. 동시에 Tech Lead 역할 안내에서는 Tech Lead와 EM이 책임 범위를 합의해 필요한 역할이 빠지지 않게 해야 한다고 적는다. 역할을 나누는 것과 기술을 방치하는 것은 다른 일이다.

일정은 분명히 관리되고 있었다

돌아보면 모든 것이 방치된 것은 아니었다.

기능 요청이 들어오면 담당자가 정해졌다. 대략적인 일정과 배포 시점이 잡혔다. 기획 검토, 작업 크기 산정, QA와 배포 승인 같은 절차도 있었다. 급한 운영 이슈가 생기면 누가 확인할지 정했고, 여러 프로젝트의 일정이 겹치면 우선순위를 다시 조정했다.

이런 일은 중요하다. 제품 개발은 좋은 코드만으로 움직이지 않는다. 여러 직군의 일정을 맞추고, 불확실한 요구사항을 출시 가능한 크기로 줄이고, 사용자에게 전달할 시점을 결정해야 한다. 이 부분을 관리하지 않으면 아무리 좋은 설계도 운영에 도착하지 못한다.

문제는 이 관리가 기술의 안쪽까지 충분히 이어지지 않았다는 데 있었다.

어떤 작업은 한두 문장의 요청만 있는 채 담당자에게 넘어왔다. 왜 지금 필요한지, 기존 구조와 어떤 관계인지, 앱과 웹 중 어디까지가 범위인지, 다른 시스템의 변경을 기다려야 하는지 정리되지 않았다. 담당 개발자는 코드를 쓰기 전에 과거 대화와 문서, 저장소 이력을 뒤져 사실상 요구사항부터 복원해야 했다.

기술 부채도 비슷했다. 큰 유지보수 항목 아래에 여러 문제가 모였지만, 무엇부터 해결할지 결정하는 정기적인 장치는 약했다. 잘게 나눈 작업이 목록에는 있어도 모두 낮은 우선순위와 미지정 상태라면, 그것은 실행 계획이라기보다 잘 정리된 대기실에 가깝다.

성능 개선도 측정하는 사람이 직접 중단 기준까지 만들어야 했다. 개선처럼 보이는 코드가 실제로는 수 밀리초 차이에 불과하거나 새로운 렌더링 비용을 만들 때, 이를 멈추는 판단은 일정표에서 자동으로 나오지 않는다.

일정 관리는 일을 앞으로 보낸다. 기술 관리는 올바르지 않은 방향으로 빠르게 가는 일을 멈춘다. 둘 중 하나만으로는 부족하다.

기록을 숫자로 펼쳐봤다

감정만으로 판단하고 싶지 않아 최근 약 3개월의 작업 기록을 펼쳐봤다.

집계 범위는 내가 주로 일한 프론트엔드 저장소와 해당 팀의 업무 티켓이다. PR을 얼마나 잘게 나눴는지에 따라 숫자가 달라지고, 리뷰 댓글 수가 곧 품질을 뜻하지도 않는다. 따라서 아래 수치는 생산성을 평가하려는 점수가 아니다. 어떤 종류의 판단이 어디에 모였는지 확인하기 위한 흔적이다.

• 작성한 PR은 약 140건이었고, 그중 120건 이상이 병합됐다.
• 제목을 기준으로 거칠게 분류하면 구조 개선·리팩터링·마이그레이션·의존성 정리가 60건 안팎이었다.
• 결함 수정은 50건 이상, 기능 작업은 30건 안팎, 배포·QA 관련 작업은 20건 안팎이었다.
• 성능을 직접 측정하거나 실험한 작업도 10건 이상이었다.
• 하나의 유지보수 묶음 아래에서 약 90개의 기술 항목을 찾아 기록했고, 그중 약 70개가 종료됐다.
• 다른 사람이 작성한 PR 14개에 60건이 넘는 인라인 리뷰를 남겼고, 확인 가능한 범위에서 최소 9개의 구체적인 결함이 실제 수정으로 이어졌다.

분류는 서로 겹친다. 결함을 고치면서 구조를 바꾼 PR도 있고, 배포 검증을 포함한 기능 PR도 있다. 티켓 하나의 크기도 모두 다르다. 숫자를 단순히 더해 “얼마나 많이 했다”고 말할 수는 없다.

그럼에도 방향은 보였다.

나는 기능을 구현하는 개발자 역할만 하고 있지 않았다. 오래된 구조를 조사해 작업 단위로 나누고, 효과가 작은 실험을 중단하고, 다른 변경에서 운영 위험을 찾아내고, 발견한 규칙을 다시 타입과 검사 도구에 넣는 일을 함께 하고 있었다.

직함과 별개로 Tech Lead에 가까운 판단과 운영 안전망 역할을 상당 부분 수행하고 있었다.

실제로 했던 기술 작업들

숫자보다 중요한 것은 그 안의 일이다. 외부에 공개할 수 있는 수준으로 일반화하면 이런 작업들이 있었다.

타입 검사를 통과한 런타임 오류를 리뷰에서 찾았다

한 변경에서는 데이터 요청 클라이언트를 객체 전개로 복사해 감싸고 있었다. 타입은 그럴듯하게 유지됐지만, 원본 인스턴스의 프로토타입 메서드와 내부 상태는 복사되지 않았다. 빌드와 타입 검사가 통과해도 실제 호출 시점에는 메서드가 사라지거나 this 바인딩이 깨질 수 있었다.

리뷰는 단순히 “객체 전개를 쓰지 마세요”로 끝나지 않았다. 소비처와 라이브러리 구현을 따라가며 어떤 메서드가 동적으로 호출되는지 확인했고, 결국 원본의 동작을 보존하는 프록시 방식으로 수정됐다.

이 문제를 발견하는 데 필요한 것은 문법 지식만이 아니었다. 타입 시스템이 보장하는 범위와 런타임 객체의 성질이 어디서 갈라지는지 판단해야 했다.

가격 계산의 경계를 다시 확인했다

다른 변경에서는 할인과 마진 계산을 조합하는 과정에서 최종 가격이 소비자가를 넘어갈 수 있는 경로가 있었다. 특정 할인율에서는 이전 값이 남아 잘못된 마진이 표시될 가능성도 있었다.

화면의 숫자는 정상처럼 보일 수 있지만 가격은 도메인 불변식을 가져야 한다.

최종 판매가는 허용된 상한을 넘지 않는다.
할인 조건이 바뀌면 파생 값도 같은 기준으로 다시 계산된다.

리뷰에서는 구현의 모양보다 이 불변식이 모든 분기에서 유지되는지를 확인했다.

필터링된 목록과 탭의 인덱스가 어긋나는 문제를 찾았다

목록을 조건에 따라 걸러낸 뒤 원본 배열의 인덱스를 탭 상태에 그대로 사용한 코드도 있었다. 화면에 보이는 탭 순서와 데이터 조회에 쓰는 인덱스가 달라져 특정 조건에서 상품이 사라질 수 있었다.

각 줄은 단순했고 테스트하기도 쉬워 보였다. 문제는 두 배열이 같은 좌표계를 공유한다는 암묵적인 가정이었다. 이런 결함은 타입으로 잡기 어렵고, 상태가 만들어지는 순서와 소비되는 위치를 함께 읽어야 보인다.

화면 표시용 비동기 데이터가 저장 상태를 더럽히는 문제를 막았다

서버에서 늦게 도착한 표시용 데이터가 폼의 변경 감지에 포함되면서, 사용자가 아무것도 수정하지 않아도 “저장되지 않은 변경”으로 판단되는 흐름이 있었다. 불필요한 갱신 요청까지 발생할 수 있었다.

데이터가 같은 화면에 있다는 이유만으로 같은 생명주기를 가져서는 안 된다. 사용자가 편집한 값과 조회 후 채워지는 표시용 값의 책임을 분리해야 했다.

API 전환 과정의 호환성 문제를 확인했다

새 응답 형태로 넘어가는 과정에서 일부 필드가 비어 있을 때 기존 이미지가 사라질 수 있는 경로도 있었다. 새 계약만 보면 올바른 구현이었지만, 전환 기간에 남아 있는 이전 데이터와 함께 보면 파괴적인 변경이었다.

마이그레이션의 완성도는 새 타입이 얼마나 깔끔한지가 아니라, 기존 데이터가 안전하게 지나갈 수 있는지로 결정된다.

이런 문제들은 모두 “코드를 많이 썼다”는 문장으로 설명되지 않는다. 실제 기여는 어떤 가정을 의심했고, 어디서 멈췄고, 무엇을 팀의 다음 판단으로 남겼는가에 가까웠다.

기술 부채를 작업 가능한 형태로 바꿨다

기술 부채는 대개 모두가 존재를 안다. 그러나 “언젠가 정리해야 한다”는 문장만으로는 일이 시작되지 않는다.

최근에는 유지보수 묶음 아래에서 코드와 운영 흔적을 다시 조사해 작업 단위로 나눴다.

• 더 이상 도달할 수 없는 UI와 코드 묶음
• 기능 출시 뒤 남은 임시 분기와 플래그
• 사용하지 않는 의존성과 중복된 데이터 요청 코드
• 특정 도구를 위해 남았다가 역할을 잃은 Provider
• 브라우저 저장소에 직접 접근해 팀 정책을 우회하는 코드
• 여러 위치에 흩어진 개발 문서
• 현재 연결이 불분명하지만 바로 삭제하면 위험한 오류 보고 경로

각 항목에는 가능한 한 근거를 붙였다. 파일과 소비처, 예상 삭제 범위, 검증 방법과 완료 조건을 적었다. 바로 지워도 되는 코드와 먼저 실제 호출 여부를 조사해야 하는 코드를 나눴다.

특히 마지막 유형은 “안 쓰는 것 같으니 삭제”가 아니라 조사 티켓으로 남겼다. 기술 부채 정리는 삭제량 경쟁이 아니다. 모르는 것을 모른다고 표시하고, 안전하게 확인할 순서를 만드는 일도 정리의 일부다.

이렇게 만든 작업 중 상당수는 실제로 끝냈다. 하지만 최근 새로 정리한 항목들은 여전히 낮은 우선순위와 담당자 없는 상태로 남아 있었다.

여기서 개인의 발견과 조직의 결정은 갈라진다.

개발자는 부채를 발견하고 근거와 범위를 만들 수 있다. 그러나 제품 일정과 비교해 언제 갚을지, 어떤 위험을 먼저 줄일지, 이를 위해 누구의 시간을 확보할지는 개인이 혼자 결정할 수 없다. 그 목록을 실행 가능한 포트폴리오로 바꾸는 것이 기술 리더십의 일이다.

잘못된 실험을 멈추는 것도 기술 리더십이다

성과는 흔히 병합된 코드로 남는다. 하지만 최근 작업 중 의미가 컸던 것에는 병합하지 않은 변경도 있었다.

화면 렌더링을 크게 개선할 것으로 예상한 방법을 실제 환경과 비슷하게 측정했다. 가장 무거운 영역은 생각한 방식으로 건너뛰어지지 않았고, 미리 확보한 높이와 실제 높이의 차이가 새로운 스크롤 보정 비용을 만들었다. 주장했던 개선 폭과 달리 차이는 수 밀리초에서 수십 밀리초 수준이었고 측정 노이즈와도 가까웠다.

코드는 이미 있었고 설명도 그럴듯했다. 그래도 병합하지 않았다.

반대로 다른 데이터 프리페치 실험은 전후 분포가 분명히 갈렸고 사용자가 기다리는 구간을 실제로 줄였다. 그 작업은 진행했다.

두 결과 모두 성과다.

효과가 확인된 변경은 통과시킨다.
효과가 없거나 새 위험이 큰 변경은 중단한다.
중단 이유와 측정값은 다음 시도를 위해 남긴다.

이 기준이 없다면 AI 시대의 개발 속도는 위험을 더 빨리 쌓는 능력이 될 수 있다. 코드를 만드는 비용이 낮아질수록, 만들지 않을 것을 고르는 능력은 더 중요해진다.

문제는 내가 많이 했다는 데 있지 않았다

이 기록을 정리하며 “내가 이렇게 많이 했다”는 결론을 내리고 싶지는 않았다.

오히려 질문은 반대였다.

왜 이런 종류의 판단이 한 개인에게 이렇게 많이 모였을까?

기술적으로 궁금한 것을 지나치지 못하는 내 성향도 있다. 문제가 보이면 원인을 찾고, 다시 생기지 않게 규칙으로 옮기는 일을 좋아한다. AI 도구 덕분에 예전보다 훨씬 넓은 범위를 읽고 여러 작업을 동시에 검증할 수도 있었다. 앞서 사람과 코드의 경계를 정리한 기록에서도 비슷한 피로를 적었다.

하지만 개인의 역량이 커졌다는 이유만으로 구조의 빈칸까지 개인 책임이 되어서는 안 된다.

역할이 명확하지 않은 기술 리더십은 흔히 그림자 노동이 된다.

• 중요한 리뷰는 하지만 리뷰할 시간이 일정에 잡히지 않는다.
• 기술 부채를 찾고 쪼개지만 실행 우선순위를 정할 권한은 없다.
• 위험한 변경을 막지만 출시가 늦어진 이유로만 보일 수 있다.
• 장애를 예방하면 아무 일도 일어나지 않아 결과가 드러나지 않는다.
• 여러 팀의 맥락을 연결하지만 공식 역할과 평가는 기능 구현에 머문다.

이 구조는 개인에게도 팀에게도 위험하다.

한 사람이 쉬거나 떠나면 판단의 맥락이 사라진다. 다른 개발자는 누가 결정권자인지 몰라 같은 질문을 반복한다. 기술 방향은 일관된 기준보다 그때 여유가 있는 사람의 취향에 가까워진다. 그리고 빈칸을 계속 메우던 사람은 자신이 잘해서 일이 모이는 것인지, 조직이 기대고 있는 것인지 구분하기 어려워진다.

책임은 있는데 권한과 시간이 없다면 그것은 리더십 위임이 아니다. 개인의 책임감을 운영 방식으로 사용하는 것이다.

기술을 관리한다는 것

그렇다면 Engineering Manager가 직접 코드를 쓰지 않으면서 기술을 관리하려면 무엇을 해야 할까.

거대한 기술 전략 문서부터 만들 필요는 없다고 생각한다. 먼저 판단이 생기고 실행되는 작은 구조를 만들면 된다.

1. 기술 결정의 주인을 명시한다

모든 질문에 EM이 답할 필요는 없다. 영역별 Tech Lead, Staff Engineer, 장기적으로 맥락을 가진 개발자에게 판단을 위임할 수 있다.

다만 “알아서 봐주세요”는 위임이 아니다.

누가 선택지를 정리하는가?
누가 최종 결정을 내리는가?
어떤 범위까지 자율적으로 바꿀 수 있는가?
제품 일정과 충돌할 때 누가 조정하는가?
결정 결과는 어디에 남기는가?

이 질문에 답할 수 있어야 한다. 책임을 맡겼다면 그에 맞는 권한과 시간을 함께 줘야 한다.

2. 기술 부채를 제품 포트폴리오와 함께 본다

기술 부채 목록을 별도의 창고에 두면 대부분 영원히 낮은 우선순위로 남는다.

분기 계획에서 기능과 기술 작업을 같은 표 위에 놓고 봐야 한다. 장애 가능성, 변경 빈도, 개발 속도 저하, 사용자 영향과 제거 비용을 기준으로 비교할 수 있다. 팀 상황에 맞게 유지보수에 쓸 개발 여력을 미리 정하는 방식도 출발점이 될 수 있다. 최소한 매번 긴급한 기능 뒤로 자동 밀리지 않도록 명시적인 예산이 필요하다는 뜻이다.

3. 결정과 중단 기준을 짧게 남긴다

긴 아키텍처 문서보다 다음 다섯 줄이 더 유용할 때가 많다.

문제: 무엇이 실제로 불편하거나 위험한가?
선택지: 어떤 방법들을 비교했는가?
결정: 무엇을 선택했고 왜 선택했는가?
측정: 성공을 어떤 값으로 확인하는가?
중단: 어떤 결과가 나오면 되돌리거나 멈추는가?

이 기록이 있으면 담당자가 바뀌어도 같은 논의를 처음부터 반복하지 않는다. AI가 새로운 구현을 제안할 때도 기존 결정과 충돌하는지 검증할 수 있다.

4. 리뷰와 장애에서 나온 지식을 규칙으로 바꾼다

좋은 리뷰 한 번으로 결함을 막는 것은 중요하다. 하지만 같은 위험을 다음 리뷰어도 다시 찾아야 한다면 팀은 아직 학습하지 않은 것이다.

반복되는 문제는 가능한 범위에서 타입, 린트, 테스트, 배포 스모크와 런북으로 옮겨야 한다. 자동화하기 어려운 도메인 불변식은 체크리스트나 짧은 설계 원칙으로 남길 수 있다.

개인의 눈썰미를 시스템의 실패 방식으로 바꾸는 일에는 시간이 든다. 이 시간을 기능 개발의 방해가 아니라 다음 기능의 안전 비용으로 인정해야 한다.

5. 보이지 않는 기술 리더십을 평가에 포함한다

병합된 기능만 세면 위험을 막은 리뷰, 실패한 실험의 중단, 기술 부채의 구조화와 동료의 의사결정 지원은 사라진다.

평가에는 다음과 같은 결과도 들어가야 한다.

• 팀의 중요한 기술 결정을 더 명확하게 만들었는가?
• 다른 사람이 안전하게 변경할 수 있는 규칙과 도구를 남겼는가?
• 운영 위험을 발견하고 실제 수정으로 연결했는가?
• 효과가 낮은 작업을 근거를 가지고 중단했는가?
• 특정 개인에게 있던 지식을 팀이 사용할 수 있게 만들었는가?

이것을 인정하지 않으면 기술 리더십은 공식 역할이 아니라 야근과 호의의 형태로만 남는다.

AI가 있는 지금은 더 많이 코딩할 수 있다

예전에 관리자로 일할 때도 나는 코드를 놓지 않았다.

지금의 AI 도구가 그때 있었다면 어땠을까 생각해본다. 회의 사이에 작은 수정만 하는 수준을 넘어, 여러 저장소의 영향을 조사하고, 작업을 나눠 병렬로 검증하고, 배포 뒤 핵심 경로를 확인하는 것까지 훨씬 빠르게 했을 것 같다. AI 에이전트와 병렬로 일하면서도 판단은 직렬로 남았던 경험처럼, 관리자의 확인 범위도 크게 넓어졌을 것이다.

그렇다고 “이제 EM도 AI로 코딩해야 한다”는 결론을 내리고 싶지는 않다.

AI는 구현의 한계보다 판단의 한계를 먼저 드러낸다. 한 사람이 만들 수 있는 변경의 수가 늘면 리뷰해야 할 선택도 함께 늘어난다. 기술 방향이 없는 팀에서 AI는 각자의 국소 최적화를 더 빠르게 만들 수 있다. 반대로 기준과 책임이 분명한 팀에서는 탐색, 구현, 검증의 비용을 크게 낮춘다.

따라서 AI 시대의 Engineering Manager에게 더 필요한 것은 직접 생성한 코드의 양이 아니다.

• AI가 빠르게 만든 선택지 중 무엇을 채택할지 판단할 구조
• 생성된 코드가 지켜야 할 아키텍처와 도메인 원칙
• 자동화가 넘지 말아야 할 권한과 배포 경계
• 실패한 실험을 빠르게 접을 수 있는 측정 기준
• 늘어난 처리량이 특정 개인의 과부하가 되지 않게 하는 우선순위

AI는 기술 리더십을 대신하지 않는다. 오히려 기술 리더십이 비어 있을 때 생기는 비용을 더 빠르게 키울 수 있다.

내가 일하고 싶은 환경

이제 처음 적었던 문장을 조금 더 구체적으로 바꿀 수 있다.

내가 일하고 싶은 곳은 최신 기술을 가장 빨리 도입하는 팀이 아니다.

새 기술이 나왔을 때 그것이 해결하는 문제를 살펴보고, 현재 시스템의 제약과 비교하고, 지금 도입하지 않을 이유까지 말할 수 있는 팀이다. 오래된 구조를 무조건 부끄러워하지 않되, 유지할 이유가 사라졌다면 바꿀 의지가 있는 팀이다.

관리자가 모든 기술의 답을 아는 곳도 아니다.

답을 찾아야 할 질문을 구분하고, 누가 판단할지 정하며, 그 판단이 실행될 시간을 확보하는 곳이다. 책임을 넘길 때 권한도 함께 주고, 기술 리더 역할을 맡은 사람의 집중 시간을 보호하는 곳이다.

일정만 빠르게 정하는 곳도 아니다.

왜 지금 해야 하는지, 성공을 어떻게 확인할지, 무엇을 하지 않을지를 함께 정하는 곳이다. 근거가 약한 개선을 중단한 것도 결과로 인정하고, 장애를 막아 아무 일도 일어나지 않은 시간을 성과로 읽을 수 있는 곳이다.

그리고 개인의 책임감이 조직의 기본 인프라가 되지 않는 곳이다.

누군가가 빈칸을 잘 메운다고 계속 그 사람에게 빈칸을 보내지 않는다. 그 사람이 무엇을 반복해서 판단하고 있는지 보고 역할과 운영 방식으로 만든다. 기술 리더십이 필요하다면 이름을 붙이고, 기대와 권한과 평가를 맞춘다.

다시 기술 리더십을 생각한다

최근 몇 달의 기록을 보고 나니 내가 무엇을 해왔는지는 조금 더 분명해졌다.

기능을 만들었고 결함을 고쳤다. 성능을 측정했고 효과가 작은 실험은 접었다. 다른 변경에서 운영 위험을 찾아 수정으로 연결했다. 오래된 코드와 문서를 뒤져 기술 부채를 작업 가능한 크기로 만들었다. AI를 사용해 이 모든 탐색과 검증의 범위를 넓혔다.

나는 이런 일을 좋아하고, 앞으로도 하고 싶다.

다만 개인이 조용히 빈자리를 메우는 방식으로 계속하고 싶지는 않다. 기술 판단이 필요한 곳에 역할이 있고, 그 역할에 시간이 있으며, 결정이 팀의 다음 작업으로 이어지는 환경에서 하고 싶다.

나도 다시 팀을 이끄는 역할을 맡게 된다면 예전보다 잘할 수 있을 것 같다는 생각이 든다. AI 덕분에 직접 확인할 수 있는 범위가 넓어진 것도 이유다. 하지만 더 큰 이유는 이제 코드를 많이 쓰는 것과 기술을 관리하는 것이 다르다는 사실을 조금 더 분명히 알기 때문이다.

관리자가 모든 기술의 답을 알 필요는 없다.

하지만 답을 찾아야 할 질문을 구분하고, 누가 판단할지 정하며, 그 판단이 실행될 시간을 확보해야 한다.

내가 원하는 것은 기술을 잘 아는 척하는 리더가 아니다.

기술이 관리될 수 있는 환경을 만드는 리더다.