대부분의 문제는 커뮤니케이션 문제임을 느꼈음
엔지니어는 제품 비전이나 고객과 단절되어 있고, 제품팀은 엔지니어를 단순한 사내 외주팀처럼 다룸
영업과 CS는 자신들의 약속이 제품 로드맵에 어떤 영향을 주는지 이해하지 못함
결국 목표와 성공 지표가 엇갈려 모두가 제각각 노를 젓는 상황이 됨
해결책은 “더 나은 사람”이 아니라, 모두가 같은 목표에 몰입하고 각자의 역할이 전체와 어떻게 맞물리는지 이해하게 하는 것임
오래된 기술 부채도 마찬가지로, 무시한다고 사라지지 않음. 그 부채가 회사에 주는 비용과 리스크를 수치화해 다른 목표와 균형을 잡고 갚아나갈 계획을 세워야 함
그래서 나는 BigCo 내부 툴링 팀을 위해 Shadow Sessions 프로그램을 만들었음
사용자가 바로 옆에 있으니 직접 만나 친구가 되고, 그들의 일상과 맥락을 배우는 세션임
3주마다 자동으로 스케줄링되고, 별도의 액션 아이템 없이 진행됨. 매번 사람들이 놀라워하며 작은 버그들이 해결되고 연결이 생김
Slack API와 연동되는 자동 스케줄러를 만들어 운영 중이며, 가장 어려운 부분은 일정 조율과 참여 유도임
회사들이 서로 경청하도록 인센티브를 주지 않기 때문이라 생각함
경영진은 하급자의 말을 듣지 않고, 하급자는 주목받기 위해 경쟁함
최근 우리 부서에서도 컨설턴트가 새 플랫폼으로 전환하자고 했는데, 아무도 동의하지 않았지만 멈출 수 없었음. 결국 아무도 듣지 않음
“그 기술 부채가 회사에 주는 비용을 산출하라”는 말이 인상적이었는데, 구체적으로 어떻게 하는지 궁금함
물론 “더 나은 사람”이 많은 문제를 해결하긴 함. 전부는 아니지만, 꽤 많은 부분을 해결함
제품팀이 엔지니어를 외주처럼 다루는 이유는 “이건 내 아이디어고 너희가 실행한 거야”라는 우월감 때문임
“왜 이걸 하죠?”라는 질문엔 “믿어봐, 형을” 식의 답만 돌아옴
이런 PM 행동은 바뀌지 않을 것 같음. 그래서 엔지니어들이 직접 제품 역할을 맡으며 커뮤니케이션 격차를 없애고 있음
많은 사람들이 실제로는 일에 자부심을 느끼지 않음을 깨달았음
어떤 사람에게는 그저 월급일 뿐임
특히 나이 많은 동료들은 시스템이 무너지는 걸 본 경험이 있어, 다시 그런 상황이 오지 않게 하려 함
새로운 직장에 갈 때마다 90일 계획 안에 명확한 가이드라인을 세우려 하지만, 결국 핵심은 팀임
어떤 팀은 변화에 목말라 있고, 어떤 팀은 변화를 방해함
리더가 무지하거나 가장 빠르고 싼 선택만 고르면 더 어려워짐
영국의 Post Office 스캔들처럼, 내부에서 문제를 알았지만 막힌 사례도 떠오름
사람들이 일에 자부심을 잃은 이유는 소유권 상실 때문임
과거에는 절반 이상이 자영업자였지만 지금은 10% 남짓임
이제 우리가 만드는 건 “우리 것”이 아니라 “고용주의 것”임
더 열심히 일해도 보상받지 못하고, 오히려 더 많은 일을 떠안게 됨
결국 사람들은 자원으로 취급되고, 필요 없으면 버려짐
대부분의 회사는 직원에게 관심이 없음, 직원들도 그걸 앎
위기 시 가장 먼저 해고되는 건 직원이고, CEO는 수백만 달러를 받음
이런 구조에서 직원이 회사를 위해 헌신하길 기대하는 건 불가능함
자부심이 사라진 이유는 명확함
덜 일하는 사람이 더 많은 급여를 받고, 당신은 절반 급여의 대체 인력 때문에 해고될 수 있음
인터뷰는 점점 까다로워지고, 공로는 도둑맞고, 인플레이션은 급여를 잠식함
결국 “왜 자부심이 사라졌는가”는 미스터리처럼 보이지만 사실 답은 명확함
“자부심”으로는 식료품을 살 수 없고, 열심히 일해도 급여는 그대로임
사람들이 일에 흥미를 느껴야만 신경을 씀
하지만 기업은 대부분의 사람이 원하는 일을 하지 못한다는 걸 알고, 대신 프로세스와 워크플로우에 집중함
개인에게는 자신이 좋아하는 일을 하면서 좋은 보수를 받는 게 최선임
“새로운 걸 배우고 싶지 않다”는 개발자의 말이 꼭 나쁜 건 아님
JavaScript 생태계처럼 매일 바뀌는 프레임워크 피로감과, Go나 LTS 기반의 기술적 안정성은 다름
안정성은 제품 민첩성에도 도움이 됨
오래된 C++ 코드베이스를 다루는 시니어 엔지니어와 협상해야 할 수도 있지만, 그걸 단순히 기술 부채라 부르는 건 편견임
기술 부채 여부는 코드베이스를 책임지는 리드 IC와 그를 관리하는 매니저만이 판단할 수 있음
인터뷰에서 인간적인 문제를 언급하면 불합격하기 좋은 방법임
많은 면접관이 기술적 답변만 정답으로 여기고, 인간적 통찰을 무시함
나는 오히려 그런 관점을 높이 평가하지만, 동료들과 설득 싸움을 해야 함
다행히 블로그 글은 면접처럼 평가받을 필요가 없어서 좋음 :)
최근 면접에서 모든 면접관이 합격을 줬지만 한 명만 반대했음
메시지 처리량에 따라 배치 프로세싱이 충분할 수도 있다고 하자, 그가 “큐를 모른다”고 단정함
10년 넘게 페타바이트급 데이터 제품을 다뤘다고 말했지만, 그의 시스템 설계에 맞지 않는다는 이유로 거절당함
결국 지금 그 팀은 모든 마이크로서비스를 단일 API 뒤로 묶는 작업을 하고 있음
나는 인터뷰에서 양쪽 트레이드오프를 함께 제시하는 방식을 씀
팀이 그 균형을 이해하지 못한다면, 그 팀에 합류하지 않아도 됨
여담이지만, Graph DB는 멋져 보여서 과하게 쓰이는 경우가 많음
Big Tech의 데이터 엔지니어로서 가장 어려운 문제는 두 가지임
첫째, Conway’s Law로 인해 부서마다 다른 툴체인과 데이터 철학을 가짐
둘째, 각 사일로가 자기 방식만 옳다고 주장하면서도 서로의 데이터를 원함
표준화가 불가능한 이유는 각 부서의 리더들이 자신들의 방식만이 유일한 해법이라 믿기 때문임
실제로 보면 대부분의 접근은 옳기도 하고 틀리기도 함
겉보기엔 기술 문제 같지만, 결국 사람 문제임
여기에 더해, 요구사항이 처음부터 명확하지 않고, 자동화가 부족해 사소한 요청에 파묻힘
상류 시스템의 변경 통보가 없어, 하류에서 알람이 울릴 때야 알게 됨 스프린트가 무의미할 정도로 즉흥 요청이 많고, 문서화되지 않은 지식이 넘침
이런 경험 덕분에 더 낮은 수준의 컴퓨터 과학을 공부할 동기가 생김
이런 문제는 IT에서 가장 근본적인 사람 중심 문제임
변화를 이끌려면 네트워크를 만들고, 사람들을 묶고, 투명하게 변화를 전파해야 함
하지만 진짜 변화를 위해선 디렉터나 VP 같은 상위 리더의 지원이 필요함
AWS가 이런 조직 변화를 위한 가이드를 냈는데, AWS Prescriptive Guidance는 훌륭한 청사진임
대규모 기관 시스템을 구현할 때 가장 큰 장애물은 부서 간 불신임
“모두를 하나의 솔루션으로 묶자”로 시작하지만, 곧 각 부서별 프로젝트로 분리됨
이를 막으려면 강력한 권한을 가진 리더가 필요함
특히 공공 부문은 서로를 싫어하는 경우가 많아 더 어렵고, 민간은 최소한 일자리 유지라는 공통 목표라도 있음
Jerry Weinberg의 『Secrets of Consulting』에서 말했듯,
“겉보기엔 기술 문제 같아도, 항상 사람 문제임”
기술적 문제의 뿌리는 결국 사람의 선택, 커뮤니케이션, 관리, 역량에 있음
나도 이 말을 하려고 왔음. 그의 통찰은 세월이 지나도 변치 않음
시스템 교체 프로젝트에서 분석가로 일했음
기존 시스템은 단순한 라운드 로빈 방식으로 업무를 배분했지만, 새 시스템은 각자의 업무량을 고려해 공정하게 배분했음
그런데 일부 직원이 시스템을 조작해 바쁘게 보이도록 만들었고, 결과적으로 성실한 직원이 더 많은 일을 떠맡게 됨
우리는 문제의 본질이 기술이 아니라 감독 부재임을 명확히 설명했지만, 결국 기술적 해결책을 강요받았음
이건 두 기술적 선택지 간의 문제였다고 생각함
인간의 본성상 일은 주어진 시간만큼 늘어나기 마련이고, 이런 역인센티브를 기술적으로 제어해야 함
이상적인 인간을 전제로 시스템을 설계하면 실패함
Jerry Weinberg는 『The Psychology of Computer Programming』(1971)부터
“겉보기엔 기술 문제라도, 항상 사람 문제다”라는 원칙을 강조했음
그의 저서들은 지금 읽어도 가치가 큼
제목을 보자마자 Jerry가 떠올랐음
나는 “직무에 자부심이 없다”고 비난하는 태도를 싫어함
대부분의 직원은 일의 주인이 아니고, 회사가 주인임
회사가 특정 방향을 강요하고, 반대하면 불이익을 준다면 왜 싸워야 하나
우리는 그저 기계의 톱니바퀴일 뿐이고, 그렇게 대우받는다면 그에 맞게 행동할 뿐임
글쓴이의 자기중심적 태도가 불쾌하게 느껴짐
선진국이 아닌 곳에서 일해보면 이게 더 명확함. 모두 그냥 생계를 위해 일할 뿐임
나는 지금 꽤 시니어로, 자금 스폰서와 요구사항 담당자와 직접 일함
그들은 “이걸 해줘, 얼마야?”라고 묻지만, 나는 30분 회의 중 18분 만에 대략적인 견적을 내야 함
그들은 기술은 모르지만, 돈과 정치의 언어를 완벽히 앎
어떤 문제는 문자 한 통으로 해결했는데, 예산은 600만 달러였음
또 어떤 프로젝트는 다른 팀이 가져가 3,500만 달러를 태우고 실패함
예산을 쥔 스폰서들은 대부분 정치가 우선이고, 목표는 “다음 자리”임
그들의 커리어를 보면 “어떻게 저 자리에 갔을까” 싶을 때가 많음
Hacker News 의견
대부분의 문제는 커뮤니케이션 문제임을 느꼈음
엔지니어는 제품 비전이나 고객과 단절되어 있고, 제품팀은 엔지니어를 단순한 사내 외주팀처럼 다룸
영업과 CS는 자신들의 약속이 제품 로드맵에 어떤 영향을 주는지 이해하지 못함
결국 목표와 성공 지표가 엇갈려 모두가 제각각 노를 젓는 상황이 됨
해결책은 “더 나은 사람”이 아니라, 모두가 같은 목표에 몰입하고 각자의 역할이 전체와 어떻게 맞물리는지 이해하게 하는 것임
오래된 기술 부채도 마찬가지로, 무시한다고 사라지지 않음. 그 부채가 회사에 주는 비용과 리스크를 수치화해 다른 목표와 균형을 잡고 갚아나갈 계획을 세워야 함
사용자가 바로 옆에 있으니 직접 만나 친구가 되고, 그들의 일상과 맥락을 배우는 세션임
3주마다 자동으로 스케줄링되고, 별도의 액션 아이템 없이 진행됨. 매번 사람들이 놀라워하며 작은 버그들이 해결되고 연결이 생김
Slack API와 연동되는 자동 스케줄러를 만들어 운영 중이며, 가장 어려운 부분은 일정 조율과 참여 유도임
경영진은 하급자의 말을 듣지 않고, 하급자는 주목받기 위해 경쟁함
최근 우리 부서에서도 컨설턴트가 새 플랫폼으로 전환하자고 했는데, 아무도 동의하지 않았지만 멈출 수 없었음. 결국 아무도 듣지 않음
“왜 이걸 하죠?”라는 질문엔 “믿어봐, 형을” 식의 답만 돌아옴
이런 PM 행동은 바뀌지 않을 것 같음. 그래서 엔지니어들이 직접 제품 역할을 맡으며 커뮤니케이션 격차를 없애고 있음
많은 사람들이 실제로는 일에 자부심을 느끼지 않음을 깨달았음
어떤 사람에게는 그저 월급일 뿐임
특히 나이 많은 동료들은 시스템이 무너지는 걸 본 경험이 있어, 다시 그런 상황이 오지 않게 하려 함
새로운 직장에 갈 때마다 90일 계획 안에 명확한 가이드라인을 세우려 하지만, 결국 핵심은 팀임
어떤 팀은 변화에 목말라 있고, 어떤 팀은 변화를 방해함
리더가 무지하거나 가장 빠르고 싼 선택만 고르면 더 어려워짐
영국의 Post Office 스캔들처럼, 내부에서 문제를 알았지만 막힌 사례도 떠오름
과거에는 절반 이상이 자영업자였지만 지금은 10% 남짓임
이제 우리가 만드는 건 “우리 것”이 아니라 “고용주의 것”임
더 열심히 일해도 보상받지 못하고, 오히려 더 많은 일을 떠안게 됨
결국 사람들은 자원으로 취급되고, 필요 없으면 버려짐
위기 시 가장 먼저 해고되는 건 직원이고, CEO는 수백만 달러를 받음
이런 구조에서 직원이 회사를 위해 헌신하길 기대하는 건 불가능함
덜 일하는 사람이 더 많은 급여를 받고, 당신은 절반 급여의 대체 인력 때문에 해고될 수 있음
인터뷰는 점점 까다로워지고, 공로는 도둑맞고, 인플레이션은 급여를 잠식함
결국 “왜 자부심이 사라졌는가”는 미스터리처럼 보이지만 사실 답은 명확함
하지만 기업은 대부분의 사람이 원하는 일을 하지 못한다는 걸 알고, 대신 프로세스와 워크플로우에 집중함
개인에게는 자신이 좋아하는 일을 하면서 좋은 보수를 받는 게 최선임
“새로운 걸 배우고 싶지 않다”는 개발자의 말이 꼭 나쁜 건 아님
JavaScript 생태계처럼 매일 바뀌는 프레임워크 피로감과, Go나 LTS 기반의 기술적 안정성은 다름
안정성은 제품 민첩성에도 도움이 됨
오래된 C++ 코드베이스를 다루는 시니어 엔지니어와 협상해야 할 수도 있지만, 그걸 단순히 기술 부채라 부르는 건 편견임
기술 부채 여부는 코드베이스를 책임지는 리드 IC와 그를 관리하는 매니저만이 판단할 수 있음
인터뷰에서 인간적인 문제를 언급하면 불합격하기 좋은 방법임
많은 면접관이 기술적 답변만 정답으로 여기고, 인간적 통찰을 무시함
나는 오히려 그런 관점을 높이 평가하지만, 동료들과 설득 싸움을 해야 함
메시지 처리량에 따라 배치 프로세싱이 충분할 수도 있다고 하자, 그가 “큐를 모른다”고 단정함
10년 넘게 페타바이트급 데이터 제품을 다뤘다고 말했지만, 그의 시스템 설계에 맞지 않는다는 이유로 거절당함
결국 지금 그 팀은 모든 마이크로서비스를 단일 API 뒤로 묶는 작업을 하고 있음
팀이 그 균형을 이해하지 못한다면, 그 팀에 합류하지 않아도 됨
Big Tech의 데이터 엔지니어로서 가장 어려운 문제는 두 가지임
첫째, Conway’s Law로 인해 부서마다 다른 툴체인과 데이터 철학을 가짐
둘째, 각 사일로가 자기 방식만 옳다고 주장하면서도 서로의 데이터를 원함
표준화가 불가능한 이유는 각 부서의 리더들이 자신들의 방식만이 유일한 해법이라 믿기 때문임
실제로 보면 대부분의 접근은 옳기도 하고 틀리기도 함
겉보기엔 기술 문제 같지만, 결국 사람 문제임
상류 시스템의 변경 통보가 없어, 하류에서 알람이 울릴 때야 알게 됨
스프린트가 무의미할 정도로 즉흥 요청이 많고, 문서화되지 않은 지식이 넘침
이런 경험 덕분에 더 낮은 수준의 컴퓨터 과학을 공부할 동기가 생김
변화를 이끌려면 네트워크를 만들고, 사람들을 묶고, 투명하게 변화를 전파해야 함
하지만 진짜 변화를 위해선 디렉터나 VP 같은 상위 리더의 지원이 필요함
AWS가 이런 조직 변화를 위한 가이드를 냈는데, AWS Prescriptive Guidance는 훌륭한 청사진임
“모두를 하나의 솔루션으로 묶자”로 시작하지만, 곧 각 부서별 프로젝트로 분리됨
이를 막으려면 강력한 권한을 가진 리더가 필요함
특히 공공 부문은 서로를 싫어하는 경우가 많아 더 어렵고, 민간은 최소한 일자리 유지라는 공통 목표라도 있음
Jerry Weinberg의 『Secrets of Consulting』에서 말했듯,
“겉보기엔 기술 문제 같아도, 항상 사람 문제임”
기술적 문제의 뿌리는 결국 사람의 선택, 커뮤니케이션, 관리, 역량에 있음
시스템 교체 프로젝트에서 분석가로 일했음
기존 시스템은 단순한 라운드 로빈 방식으로 업무를 배분했지만, 새 시스템은 각자의 업무량을 고려해 공정하게 배분했음
그런데 일부 직원이 시스템을 조작해 바쁘게 보이도록 만들었고, 결과적으로 성실한 직원이 더 많은 일을 떠맡게 됨
우리는 문제의 본질이 기술이 아니라 감독 부재임을 명확히 설명했지만, 결국 기술적 해결책을 강요받았음
인간의 본성상 일은 주어진 시간만큼 늘어나기 마련이고, 이런 역인센티브를 기술적으로 제어해야 함
이상적인 인간을 전제로 시스템을 설계하면 실패함
Jerry Weinberg는 『The Psychology of Computer Programming』(1971)부터
“겉보기엔 기술 문제라도, 항상 사람 문제다”라는 원칙을 강조했음
그의 저서들은 지금 읽어도 가치가 큼
나는 “직무에 자부심이 없다”고 비난하는 태도를 싫어함
대부분의 직원은 일의 주인이 아니고, 회사가 주인임
회사가 특정 방향을 강요하고, 반대하면 불이익을 준다면 왜 싸워야 하나
우리는 그저 기계의 톱니바퀴일 뿐이고, 그렇게 대우받는다면 그에 맞게 행동할 뿐임
글쓴이의 자기중심적 태도가 불쾌하게 느껴짐
나는 지금 꽤 시니어로, 자금 스폰서와 요구사항 담당자와 직접 일함
그들은 “이걸 해줘, 얼마야?”라고 묻지만, 나는 30분 회의 중 18분 만에 대략적인 견적을 내야 함
그들은 기술은 모르지만, 돈과 정치의 언어를 완벽히 앎
어떤 문제는 문자 한 통으로 해결했는데, 예산은 600만 달러였음
또 어떤 프로젝트는 다른 팀이 가져가 3,500만 달러를 태우고 실패함
예산을 쥔 스폰서들은 대부분 정치가 우선이고, 목표는 “다음 자리”임
그들의 커리어를 보면 “어떻게 저 자리에 갔을까” 싶을 때가 많음