Closed kymr closed 5 years ago
조직의 테크리드는 무엇을 해야 하는가?
당연히 코딩을 해야 한다.
코드로 제품이 나오는 조직의 리더는 당연히 코딩을 손에서 놓지 말아야 한다.
중요한건, 무엇을 코딩해야 하는가?
...
제품 그 자체에 대한 코딩은 안해도 괜찮다. 제품 하나를 더 정교하고 더 깔끔한 코드로 만드는 건 팀원들이 잘 하고 있다.
하지만, 하나의 제품이 시간이 지날 수록 더 빨리 더 높은 수준으로 나오려면, 제품을 쓰는 입장이나 제품과 연관된 파트너와의 관계나 제품의 다음 방향에 대해 코딩하는 것이 필요하다.
테크리드는 기술자 중 가장 밖으로 많이 돌아다니는 사람이기 때문에, 가장 넓은 시야를 가졌고 팀을 둘러싼 생태계 관점에서 관찰할게 많고 좋은 인사이트를 가질 수 있다.
그러므로 다른 팀과 협업하거나 유저와 직접 부딪히면서 어떻게 제품을 둘러싼 제품 외의 문제를 엔지니어링으로 풀 수 있는지 고민하고, 이를 코드로 해결해야 한다.
이 역할은 개발자 한 명 뽑고 '너가 해보렴'이라고 해봤자 인사이트가 만들어지지 않기 때문에 제대로 할 수도 없고, 그만큼 테크리드가 제일 잘 할 수 있는 일이기도 하다.
나는 철저하게 나의 포지션을 janitor로 잡고 있다.
쉽게 말해 카페 앞에 낙엽을 쓸거나 화장실을 매 시간마다 깨끗하게 유지해서, 동료들이 다른거 신경쓰지 않고 더 웃는 얼굴로 손님을 맞이하거나 더 커피 만드는데 집중하도록 하는게 나의 일이다.
예를 들어,
빌드서버 설정을 닦아서 '딱 누르면 딱 나오게' 한다거나,
2주 걸리던 일을 자동화 해서 1시간으로 줄인다거나,
lint 한 줄 더 추가해서 빌드 결과를 믿을 수 있게 하거나,
협력사와의 코드 공유를 늘려서 커뮤니케이션을 줄인다거나,
디버깅 메뉴를 많이 만들어서 다른 팀도 쓰기 좋게 하거나,
입력창에 설명을 더 써넣는다거나, 그런 소소한 일들이다.
DevOps도 아니다. 그저 업무프로세스를 엔지니어링으로 해결하는 잡무일 뿐이다.
이 역할은 대부분의 개발팀에서 비어있다.
딱히 하고 싶어하지도 않는다. 제품과 별 상관도 없고 알아주지도 않고 성취감도 없기 때문이다.
게다가, 괜히 시작했다가 끝없이 유지보수해야 하기 때문이다. 그러다보면 본업에 코딩할 시간도 빼앗기니까 좋을게 없다.
하지만 프로세스 엔지니어링을 등한시한 팀을 밖에서 보면 한심할 정도로 비효율적으로 일하고 있다 - 이 책임은 테크리드에 있다고 본다. 나는.
테크리드는 뭔가 아키텍처를 그린다거나 코드리뷰를 하거나 스펙 정의만 신경쓰거나 신기술검토를 하는거라고 생각하는 경우가 많은데,
그건 기본이고 그 이상을 해야한다.
최근 반년간 내가 하는 코딩의 70%는 업무 프로세스에 대한 엔지니어링이었다. 이 정도 하니까 팀과 그 주변의 agility가 살아나는게 느껴지더라.
테크리드가 제품을 넘어서 팀의 환경을 위한 코딩을 하면 팀 자체가 강해진다. 그러면 어떤 제품이든 자신있게 만드는 팀이 된다. #
조직의 테크리드는 무엇을 해야 하는가?
당연히 코딩을 해야 한다.
코드로 제품이 나오는 조직의 리더는 당연히 코딩을 손에서 놓지 말아야 한다.
중요한건, 무엇을 코딩해야 하는가?
...
제품 그 자체에 대한 코딩은 안해도 괜찮다. 제품 하나를 더 정교하고 더 깔끔한 코드로 만드는 건 팀원들이 잘 하고 있다.
하지만, 하나의 제품이 시간이 지날 수록 더 빨리 더 높은 수준으로 나오려면, 제품을 쓰는 입장이나 제품과 연관된 파트너와의 관계나 제품의 다음 방향에 대해 코딩하는 것이 필요하다.
...
테크리드는 기술자 중 가장 밖으로 많이 돌아다니는 사람이기 때문에, 가장 넓은 시야를 가졌고 팀을 둘러싼 생태계 관점에서 관찰할게 많고 좋은 인사이트를 가질 수 있다.
그러므로 다른 팀과 협업하거나 유저와 직접 부딪히면서 어떻게 제품을 둘러싼 제품 외의 문제를 엔지니어링으로 풀 수 있는지 고민하고, 이를 코드로 해결해야 한다.
이 역할은 개발자 한 명 뽑고 '너가 해보렴'이라고 해봤자 인사이트가 만들어지지 않기 때문에 제대로 할 수도 없고, 그만큼 테크리드가 제일 잘 할 수 있는 일이기도 하다.
...
나는 철저하게 나의 포지션을 janitor로 잡고 있다.
쉽게 말해 카페 앞에 낙엽을 쓸거나 화장실을 매 시간마다 깨끗하게 유지해서, 동료들이 다른거 신경쓰지 않고 더 웃는 얼굴로 손님을 맞이하거나 더 커피 만드는데 집중하도록 하는게 나의 일이다.
예를 들어,
빌드서버 설정을 닦아서 '딱 누르면 딱 나오게' 한다거나,
2주 걸리던 일을 자동화 해서 1시간으로 줄인다거나,
lint 한 줄 더 추가해서 빌드 결과를 믿을 수 있게 하거나,
협력사와의 코드 공유를 늘려서 커뮤니케이션을 줄인다거나,
디버깅 메뉴를 많이 만들어서 다른 팀도 쓰기 좋게 하거나,
입력창에 설명을 더 써넣는다거나, 그런 소소한 일들이다.
DevOps도 아니다. 그저 업무프로세스를 엔지니어링으로 해결하는 잡무일 뿐이다.
...
이 역할은 대부분의 개발팀에서 비어있다.
딱히 하고 싶어하지도 않는다. 제품과 별 상관도 없고 알아주지도 않고 성취감도 없기 때문이다.
게다가, 괜히 시작했다가 끝없이 유지보수해야 하기 때문이다. 그러다보면 본업에 코딩할 시간도 빼앗기니까 좋을게 없다.
하지만 프로세스 엔지니어링을 등한시한 팀을 밖에서 보면 한심할 정도로 비효율적으로 일하고 있다 - 이 책임은 테크리드에 있다고 본다. 나는.
...
테크리드는 뭔가 아키텍처를 그린다거나 코드리뷰를 하거나 스펙 정의만 신경쓰거나 신기술검토를 하는거라고 생각하는 경우가 많은데,
그건 기본이고 그 이상을 해야한다.
최근 반년간 내가 하는 코딩의 70%는 업무 프로세스에 대한 엔지니어링이었다. 이 정도 하니까 팀과 그 주변의 agility가 살아나는게 느껴지더라.
테크리드가 제품을 넘어서 팀의 환경을 위한 코딩을 하면 팀 자체가 강해진다. 그러면 어떤 제품이든 자신있게 만드는 팀이 된다. #