소속·담당·무용담을 능력으로 오인하지 않기 위한 엔지니어 평가 설계 - 구조로 키우는 프로덕트 조직 부록 17

평가에서는, 단서와 능력 그 자체를 구분한다

구조로 키우는 프로덕트 조직 시리즈에서는, 프로덕트 조직을 「사람의 모임」이 아니라, 관측·판단·실행·회고가 흐르는 구조로 바라보았습니다.

엔지니어를 평가할 때, 우리는 많은 대리 지표 (Proxy Indicator)를 사용합니다.

유명 기업에 있었다.

대규모 프로덕트를 담당했다.

유명 서비스에 관여했다.

고트래픽 (High Traffic) 기반을 담당했다.

대규모 이전을 경험했다.

AI를 사용하여 빠르게 개발할 수 있다.

유명 커뮤니티에서 평가받고 있다.

기술 발신으로 많은 반응을 얻고 있다.

이것들은 무의미하지 않습니다.

오히려, 중요한 단서입니다.

채용에서도, 업무 위탁에서도, 강연에서도, 기술 발신에서도, 우리는 한정된 정보로부터 상대의 능력을 추측합니다.

그때, 소속, 담당, 실적, 발신, 추천, 평판과 같은 정보는 일정한 가치를 가집니다.

하지만, 단서라는 것과 능력 그 자체라는 것은 다릅니다.

소속은 문맥입니다.

담당은 접점입니다.

무용담은 사건입니다.

유명세는 분포상의 눈에 띄는 정도입니다.

AI 활용은 도구의 사용법입니다.

커뮤니티 내 평가는, 그 자리에서 통용되는 평가 측면입니다.

그것들은 능력을 추측하는 재료는 됩니다.

하지만, 그것만으로 현재의 관측 능력, 판단 능력, 책임 능력, 재현성, 학습 능력을 직접 나타내지는 않습니다.

이 기사에서는, SNS나 커뮤니티에서 유통되기 쉬운 「강한 엔지니어」 상을, 평가 설계의 관점에서 분해합니다.

이 기사에서 다루는 문제

이 기사는, 유명 기업 출신자나 대규모 프로덕트 경험자를 부정하는 것이 아닙니다.

유명 기업에 있었다는 것은, 많은 경우 의미가 있습니다.

대규모 프로덕트를 담당했다는 것도, 중요한 경험입니다.

대규모 이전이나 장애 대응을 경험한 사람으로부터 배울 수 있는 것도 많습니다.

AI를 능숙하게 다룰 수 있는 사람이, 실제로 높은 생산성을 내기도 합니다.

문제는, 그것들을 능력 그 자체로 취급해 버리는 것입니다.

예를 들어,

유명 기업에 있었다

그래서 강하다

라는 추론은, 상당히 거칠 (Rough) 입니다.

정확하게는,

유명 기업에 있었다

그래서, 특정 환경에서 일정한 경험을 했을 가능성이 있다

다만, 그 사람이 무엇을 관측하고, 무엇을 판단하며, 어떤 책임을 지고, 다른 환경에서 무엇을 재현할 수 있는지는, 별도로 볼 필요가 있다

입니다.

마찬가지로,

대규모 프로덕트를 담당했다

그래서, 대규모 설계가 가능하다

라고도 단정할 수 없습니다.

담당한 범위, 책임, 판단 권한, 주변의 지원, 조직의 성숙도, 본인이 남긴 판단 기준을 볼 필요가 있습니다.

평가에서 중요한 것은, 대리 지표를 버리는 것이 아닙니다.

대리 지표를, 대리 지표로서 다루는 것입니다.

소속을 볼 때는, 환경 의존성과 재현성을 본다

소속은 강력한 시그널 (Signal) 입니다.

유명 기업에 있었던 사람은, 일정한 채용 기준을 통과했을 가능성이 있습니다.

성숙한 개발 프로세스를 경험했을 가능성이 있습니다.

수준 높은 동료와 일했을 가능성이 있습니다.

큰 고객 영향이나 운영 책임을 접했을 가능성이 있습니다.

이것은 평가상, 무시할 수 없습니다.

다만, 소속을 볼 때의 중심은, 「그 사람이 어디에 있었는가」가 아닙니다.

그 환경에서 얻은 경험 중, 무엇이 다른 환경에서도 재현 가능한가입니다.

성과는, 개인의 능력만으로 결정되지 않습니다.

주변의 리뷰 문화.

채용 수준.

문서화 기반.

CI/CD.

SRE 체제.

프로덕트의 시장 지위.

고객으로부터의 신뢰.

기존의 설계 자산.

매니저나 테크 리드 (Tech Lead)의 지원.

이러한 것들이 강력한 환경에서는, 개인의 성과도 내기 쉬워집니다.

반대로, 이것들이 약한 환경에서는, 같은 사람이라도 성과가 나오는 방식은 달라집니다.

따라서, 소속을 볼 때는 다음과 같이 물어야 합니다.

그 사람은, 그 환경에서 무엇을 관측하고 있었는가.

어떤 의사결정에 관여했는가.

어떤 판단 기준을 자신의 것으로 만들었는가.

강력한 환경에 지탱되었던 부분은 어디인가.

다른 환경으로 가져갈 수 있는 구조는 무엇인가.

소속을 부정할 필요는 없습니다.

다만, 소속으로 평가한다면, 「그곳에서 무엇을 얻었는가」와 「그곳으로부터 무엇을 가져올 수 있는가」를 나누어 볼 필요가 있습니다.

담당을 볼 때는, 판단 권한과 책임 범위를 본다

「담당했다」라는 말도 편리합니다.

인증 기반을 담당했다.

결제 기능을 담당했다.

검색 기반을 담당했다.

머신러닝 (Machine Learning) 기반을 담당했다.

대규모 이전을 담당했다.

퍼포먼스 개선을 담당했다.

이것들은 중요한 경험입니다.

다만, 담당을 볼 때의 중심은, 「무엇에 관여했는가」가 아닙니다.

그 안에서, 어떤 판단 권한과 책임 범위를 가졌는가입니다.

같은 「결제 기반을 담당했다」라도, 의미는 상당히 다릅니다.

일부 구현을 담당했는가.

설계 판단을 내렸는가.

장애 발생 시 1차 대응을 했는가.

운영 책임을 가졌는가.

릴리스 (Release) 판단에 관여했는가.

롤백 (Rollback) 조건을 결정했는가.

고객 영향이나 CS 부하까지 고려했는가.

이전(Migration) 후에 동일한 문제를 일으키지 않을 기준을 남겼는가.

이 부분을 확인하지 않으면, 「담당했다는 사실」이 그대로 능력으로 보이고 맙니다.

직무경력서에서는 담당한 프로젝트 명이나 기술 영역이 눈에 띕니다.

하지만 평가에서 정말로 알고 싶은 것은, 그 안에서 무엇을 판단했는가입니다.

담당 경험은 입구입니다.

평가하기 위해서는, 그 담당 안에서 무엇을 관측하고, 무엇을 판단하며, 어떤 책임을 지고, 무엇을 조직에 남겼는지를 볼 필요가 있습니다.

무용담을 볼 때는 조건과 사후 학습을 본다

SNS에서는 무용담이 유통되기 쉽습니다.

혼자서 만들었다.

단기간에 만들었다.

불타는 프로젝트를 구했다.

대규모 장애를 복구했다.

레거시 (Legacy)를 쇄신했다.

거대한 이전을 완수했다.

AI로 개발 속도를 크게 높였다.

이것들은 이해하기 쉽습니다.

읽는 사람에게도 잘 전달됩니다.

쓰는 사람도 말하기 쉽습니다.

채용이나 강연에서도 강력한 에피소드가 되기 쉽습니다.

단, 무용담을 볼 때의 중심은 「무엇을 완수했는가」가 아닙니다.

어떤 조건에서 성립되었으며, 성공 후에 무엇이 학습으로서 남았는가입니다.

예를 들어, 장애 복구 무용담은 중요합니다.

하지만 평가하고 싶은 것은 「심야에 열심히 노력했다는 점」만이 아닙니다.

장애 원인을 어떻게 관측했는가.

어느 시점에서 롤백 판단을 내렸는가.

어느 시점에 고객 공지를 했는가.

복구 후에 모니터링이나 절차를 어떻게 바꾸었는가.

동일한 장애를 방지하는 메커니즘을 남겼는가.

여기까지 확인해야 비로소 무용담은 재현 가능한 능력의 단서가 됩니다.

대규모 이전도 마찬가지입니다.

이전을 완수했다는 것은 중요합니다.

하지만 그것만으로는 충분하지 않습니다.

왜 대규모 이전이 필요하게 되었는가.

어떤 부채가 축적되어 있었는가.

어떤 제약 조건 때문에 단계적 이전을 선택했는가.

어떤 리스크를 먼저 제거했는가.

이전 후, 동일한 부채를 재생성하지 않을 판단 기준은 남았는가.

사건은 눈에 띕니다.

하지만 평가하고 싶은 것은 사건 그 자체가 아니라, 그 사건을 통해 보이는 판단과 학습입니다.

「강하다」를 능력 카테고리로 나눈다

「강한 엔지니어」라는 말은 편리합니다.

하지만 평가에 사용하려면 분해가 필요합니다.

예를 들어, 강함에는 몇 가지 종류가 있습니다.

구현 속도

짧은 시간 안에 동작하는 것을 만들 수 있다.

미지의 기술이라도 조사하며 진행할 수 있다.

생성형 AI (Generative AI)를 사용하여 구현 속도를 높일 수 있다.

이것은 중요합니다.

단, 구현 속도만으로는 유지보수성이나 운영 책임까지는 알 수 없습니다.

설계 판단

경계를 나눌 수 있다.

의존 관계를 정리할 수 있다.

데이터 소유권 (Data Ownership)을 고려할 수 있다.

장래의 변경 가능성을 내다볼 수 있다.

이것도 중요합니다.

단, 설계 판단만으로는 사업상의 속도나 고객 영향과의 밸런스까지는 알 수 없습니다.

운영 책임

모니터링할 수 있다.

장애 시에 되돌릴 수 있다.

SRE나 CS의 부하를 살필 수 있다.

절차와 책임 경계를 남길 수 있다.

이것도 중요합니다.

단, 운영 책임만으로는 신규 탐색이나 고속한 가설 검증의 강함까지는 알 수 없습니다.

조직 학습

판단 이유를 남길 수 있다.

실패로부터 기준을 업데이트할 수 있다.

리뷰를 통해 다음번의 판단 기준을 전달할 수 있다.

개인 의존성 (Silo/Person-dependency)을 줄일 수 있다.

이것도 중요합니다.

단, 이것도 말로만 한다면 쉽습니다. 실제로 운용되고 있는지를 볼 필요가 있습니다.

즉, 「강하다」라고 말하려면 어떤 종류의 강함인지를 나누어야 합니다.

강함을 나누지 않고 사용하면 평가는 분위기에 휩쓸리게 됩니다.

능력 카테고리는 5가지 관점으로 본다

강함의 종류를 나누었다면, 다음은 그것을 평가하는 관점을 나눕니다.

구현 속도, 설계 판단, 운영 책임, 조직 학습은 동일한 축이 아닙니다.

하지만 각각의 능력은 다음 5가지 관점으로 볼 수 있습니다.

1. 관측

그 사람은 무엇을 보고 있었는가.

코드만 보고 있었는가.

사용자 영향을 보고 있었는가.

운영 부하를 보고 있었는가.

기술 부채를 보고 있었는가.

조직 상태를 보고 있었는가.

사업 단계 (Business Phase)를 보고 있었는가.

관측할 수 없는 것은 판단할 수 없습니다.

2. 판단

그 사람은 무엇을 판단하고 있었는가.

채택할 것인가.

기각할 것인가.

뒤로 미룰 것인가.

실험으로서 통과시킬 것인가.

운영 환경에 투입할 것인가.

사람의 리뷰를 거치게 할 것인가.

중단할 것인가.

판단이란 단순한 의견이 아닙니다.

제약 조건 속에서 어떤 리스크를 감수할지를 결정하는 것입니다.

3. 책임

그 판단의 책임은 어디에 있었는가.

개인인가.

팀인가.

리뷰어인가.

승인자인가.

운영 담당자인가.

조직 전체인가.

책임이 모호한 채로 "강한 사람이 판단했다"라고 넘어가 버리면, 실패했을 때 학습할 수 없습니다.

4. 재현성 (Reproducibility)

그 능력은 다른 환경에서도 재현할 수 있는가.

소속되어 있던 회사의 시스템에 의존하고 있었는가.

주변의 강한 멤버들에게 지탱받고 있었는가.

자금이나 시간, 혹은 브랜드가 있었기에 성립된 것인가.

본인이 다른 환경에서도 가지고 나갈 수 있는 구조인가.

이것은 매우 중요합니다.

5. 학습 (Learning)

실패 후에 무엇이 업데이트되었는가.

리뷰 관점이 바뀌었는가.

운영 절차가 바뀌었는가.

문서(Document)가 바뀌었는가.

설계 판단이 바뀌었는가.

다음에 같은 실수를 하기 어려워졌는가.

성공 경험만으로는 강함을 알 수 없습니다.

실패 후의 업데이트를 통해 능력의 깊이를 볼 수 있습니다.

이렇게 보면, "강하다"는 하나의 능력이 아닙니다.

어떤 능력 카테고리가 강한가.

그 능력은 무엇을 관측하고, 무엇을 판단하며, 어떤 책임을 지고, 어디까지 재현할 수 있으며, 실패 후에 어떻게 업데이트되었는가.

평가에서는 이 정도로 세분화하는 것이 좋습니다.

대리 지표에는 주장 가능한 범위가 있다

소속, 담당, 무용담, 유명성, 커뮤니티 내 평가는 능력의 대리 지표(Proxy Indicator)입니다.

대리 지표는 편리합니다.

한정된 시간 내에 평가할 때는 완전한 관측을 할 수 없습니다.

따라서 소속이나 담당, 실적을 보는 것 자체는 자연스럽습니다.

문제는 대리 지표를 성과나 능력 그 자체로 취급하는 것입니다.

예를 들어,

유명 기업에 있었다

라고 직접적으로 말할 수 있는 것은,

유명 기업에 있었다

까지입니다.

거기서부터,

현재도 좋은 판단을 내릴 수 있다

다른 환경에서도 재현할 수 있다

조직을 강하게 만들 수 있다

AI 시대에도 안전하게 변경 사항을 통과시킬 수 있다

라고 주장하기 위해서는 추가적인 관측이 필요합니다.

마찬가지로,

대규모 프로덕트를 담당했다

라고 직접적으로 말할 수 있는 것은,

대규모 프로덕트에 관여했다

까지입니다.

거기서부터,

대규모 설계를 할 수 있다

복잡한 조직에서 판단할 수 있다

사업 영향력을 볼 수 있다

운영 책임을 질 수 있다

라고 주장하기 위해서는 역시 추가적인 관측이 필요합니다.

대리 지표는 사용해도 좋습니다.

다만, 그 지표를 통해 무엇을 말할 수 있는지 구분할 필요가 있습니다.

이 글에서 보고 있는 것은 바로 이 '주장 가능한 범위'입니다.

소속은 환경 경험의 단서입니다.

담당은 접점의 단서입니다.

무용담은 사건의 단서입니다.

유명성은 가시성의 단서입니다.

커뮤니티 내 평가는 그 자리에서 통용되는 평가 측면의 단서입니다.

어느 것도 무의미하지 않습니다.

하지만 각각이 나타내는 범위를 넘어 능력을 추론하면 평가는 왜곡됩니다.

예: 유명 SaaS 기업에서 결제 기반을 담당한 A씨

여기서 가상의 예를 들어보겠습니다.

A씨는 어떤 SaaS 기업에서 결제 기반의 일부를 담당했습니다.

그 후 대규모 이관 프로젝트에도 참여했으며, 생성형 AI를 사용한 개발 속도가 높다는 점으로 사내에서 주목받고 있습니다.

기술 발신도 활발하여 외부에서도 일정 수준의 반응을 얻고 있습니다.

이 정보만 보면 상당히 강해 보입니다.

실제로 강할 가능성도 있습니다.

하지만 평가에서는 여기서 멈추지 않습니다.

먼저 소속에 대해 본다면, A씨가 그 기업의 강력한 시스템에 얼마나 의지하고 있었는지를 확인합니다.

리뷰 문화.

SRE 체제.

결제 기반의 기존 설계.

장애 대응 절차.

보안 리뷰.

프로덕트의 시장 지위.

이러한 것들이 갖춰진 환경에서 성과를 낸 것과, 미정비된 환경에서 동일한 성과를 재현할 수 있는 것은 같지 않습니다.

다음으로 담당에 대해 본다면, A씨가 어떤 판단 권한을 가지고 있었는지를 확인합니다.

단순히 구현을 담당했는가.

설계 방침을 결정했는가.

이관 절차를 설계했는가.

롤백(Rollback) 조건을 결정했는가.

릴리스 판정에 관여했는가.

장애 발생 시 운영 책임을 지고 있었는가.

나아가 무용담에 대해 본다면, 성공한 사건의 조건과 사후 학습을 봅니다.

왜 대규모 이관이 필요했는가.

어떤 제약이 있었는가.

어떤 판단이 효과적이었는가.

어떤 판단은 우연히 잘 맞아떨어진 것인가.

이관 후, 동일한 부채를 재생성하지 않기 위한 기준은 남았는가.

그 기준은 팀에 공유되었는가.

마지막으로 AI 활용에 대해 본다면, 단순히 빠르게 만들 수 있는가가 아니라 AI 출력을 어떻게 다루고 있는지를 봅니다.

어떤 출력을 채택하는가.

어떤 출력을 기각하는가.

어떤 변경 사항을 인간 리뷰로 올리는가.

어떤 실패 상황에서 되돌리는가.

결과로부터 판단 기준을 어떻게 업데이트하는가.

이렇게 분해하면 A씨에 대한 평가는 단순한 라벨이 아니게 됩니다.

유명 기업에 있었기 때문에 강하다, 가 아닙니다.

결제 기반을 담당했기 때문에 강하다, 도 아닙니다.

AI를 사용할 수 있기 때문에 강하다, 도 아닙니다.

어떤 맥락에서, 무엇을 관측하고, 무엇을 판단하며, 어떤 책임을 지고, 무엇을 재현할 수 있으며, 무엇을 학습으로서 남겼는가.

그 단계까지 들여다봐야 비로소 평가에 가까워집니다.

공유된 평가면에서는, 질문(問い直し)이 장(場) 전체에 대한 비판으로 보이기 쉽다

SNS나 폐쇄적인 커뮤니티에서는, 같은 평가면(evaluation surface) 위에 있는 사람들이 서로 비슷한 반응을 보일 때가 있습니다.

이는 개인 간의 동료 의식만으로는 다 설명할 수 없습니다.

평가의 토대가 공유되어 있는 장에서는, 그 토대에 대한 질문이 개인에 대한 비판이 아니라 장 전체에 대한 비판으로 받아들여지기 쉽기 때문입니다.

유명 기업에 있었다.

유명 서비스를 담당했다.

AI를 능숙하게 다룬다.

기초 체력(地力)이 있다.

본질을 알고 있다.

강한 사람은 결국 강하다.

이러한 이야기들이 공통의 평가면이 되어 있는 장에서는, 그 이야기를 세밀하게 분해하는 질문은 단순한 평가 방법의 확인이 아니라, 장의 질서를 흔드는 것으로 처리되기 쉽습니다.

예를 들어,

그 소속은 무엇을 나타내고 있으며, 무엇을 나타내지 않는가

그 담당 경험에서는 어떤 판단 권한을 가지고 있었는가

그 무용담으로부터 다른 환경에서 재현할 수 있는 능력은 어디까지 읽어낼 수 있는가

그 '기초 체력'은 관측·판단·책임·재현성·학습 중 무엇을 가리키는가

라는 질문은 형식상으로는 평가의 정밀도를 높이기 위한 질문입니다.

하지만 그곳에서 통용되는 평가면이 거기에 의존하고 있는 경우, 질문 자체를 공격처럼 느끼게 됩니다.

여기서 주의해야 할 점은, 분해를 싫어하는 반응이 모두 불건전하다는 뜻은 아니라는 것입니다.

논의의 목적이 다른 경우도 있습니다.

단순히 그 장이 초보자용이라 과도한 추상론을 피하고 싶은 경우도 있습니다.

과거의 논란(炎上) 경험 때문에 유사한 논의를 피하고 있는 경우도 있습니다.

모더레이션(Moderation) 부하의 문제도 있습니다.

그럼에도 불구하고, 평가의 토대가 공유되어 있는 장에서는 그 토대를 분해하는 질문이 장 전체에 대한 비판으로 취급되기 쉽습니다.

이 현상은 엔지니어 평가를 고민할 때 유심히 살펴볼 가치가 있습니다.

커뮤니티의 경계에는 목적 경계와 평가면 경계가 있다

Discord 등의 폐쇄적인 커뮤니티가 배타적이 되는 이유도 이 구조로 설명할 수 있습니다.

물론 커뮤니티에는 경계가 필요합니다.

트롤(荒らし)을 방지한다.

초보자를 보호한다.

목적 외의 논의를 피한다.

인격 공격을 방지한다.

안심하고 상담할 수 있는 장을 만든다.

모더레이션 부하를 낮춘다.

이러한 경계는 건전합니다.

이는 목적을 지키기 위한 경계입니다.

반면, 경계에는 다른 기능이 섞일 때가 있습니다.

내부에서 통용되는 평가면이 외부로부터의 분해에 의해 흔들리는 것을 피하는 방향으로 작동하는 것입니다.

그 커뮤니티에서는 어떤 기술에 해박한 것이 가치일 수 있습니다.

어떤 인물과 가깝다는 것이 가치일 수 있습니다.

초기부터 참여했다는 것이 가치일 수 있습니다.

특정 회사나 프로덕트에 관여했다는 것이 가치일 수 있습니다.

특정 견해에 동의하고 있다는 것이 가치일 수 있습니다.

이것들이 멤버의 자기상(self-image)이나 서열과 결합하면, 평가면에 대한 질문은 단순한 논의가 아니라 장의 질서를 흔드는 것으로 보이기 쉽습니다.

그곳에 외부에서,

그것은 정말 능력인가

그것은 재현 가능한 판단 능력인가

그 주장은 무엇을 관측하고, 무엇을 판단하며, 무엇을 책임으로서 가지고 있는가

라고 물으면, 내용이 옳은지 여부를 떠나 '이 장에 가져와서는 안 될 질문'으로 처리되는 경우가 있습니다.

그 결과,

장을 어지럽혔다

분위기가 나빠졌다

건설적이지 않다

맥락을 파악하지 못하고 있다

라는 형태로 외부로부터의 분해가 거부될 수 있습니다.

물론 정말로 트롤인 경우도 있습니다.

그렇기에 구분할 필요가 있습니다.

목적을 지키기 위한 경계인가.

평가면을 지키는 형태로 작동하는 경계인가.

이 두 가지는 비슷하지만 같지는 않습니다.

건전한 커뮤니티 경계는 목적을 명확히 합니다.

이곳은 초보자 지원을 위한 장이다.

이곳은 구현 상담을 위한 장이다.

이곳은 심리적 안전성을 우선하는 장이다.

이곳은 논의가 아니라 작업 공유를 위한 장이다.

반면, 평가면에 대한 질문을 피하기 위한 경계는 종종 목적 경계의 언어를 빌려옵니다.

따라서 경계 그 자체를 부정할 필요는 없습니다.

보아야 할 것은 그 경계가 무엇을 지키고 있는가입니다.

AI 시대에는 대리 지표의 한계가 보이기 쉬워진다

생성형 AI에 의해 후보 생성은 평준화됩니다.

코드 안은 나온다.

설계 안은 나온다.

테스트 안은 나온다.

리뷰 관점은 나온다.

리스크 후보는 나온다.

판단 축의 후보도 나온다.

그러면 능력 평가에서 보아야 할 지점도 바뀝니다.

AI를 사용할 수 있다는 것 자체는 점차 전제가 됩니다.

AI로 구현 안을 낼 수 있는 것도 점차 전제가 됩니다.

AI로 비교표나 리뷰 관점을 낼 수 있는 것도 점차 전제가 됩니다.

그때 질문되는 것은,

AI가 낸 후보를 어떻게 채택할 것인가

어떻게 기각할 것인가

어디서 멈출 것인가

어디서 인간 리뷰(Human Review)로 넘길 것인가

실패하면 어떻게 되돌릴 것인가

결과로부터 판단 기준을 어떻게 업데이트할 것인가

그 책임을 누가 질 것인가

입니다.

즉, AI 시대에는 강력한 개인 신화만으로는 부족합니다.

AI를 포함한 변경 루프(Change Loop)를 개인의 기술이 아니라 조직의 구조로서 설계할 수 있는지가 관건입니다.

「변경 루프」도 편리한 말(Buzzword)로 만들지 말 것

여기서 주의해야 할 점은, 「변경 루프를 설계한다」라는 말도 그대로 두면 편리한 말(Buzzword)이 된다는 것입니다.

본질이 중요하다.

기초 체력이 중요하다.

사업 이해가 중요하다.

변경 루프가 중요하다.

이렇게 말만 한다면 모두 똑같습니다.

변경 루프라고 말하려면, 적어도 다음을 구분해야 합니다.

무엇을 관측할 것인가.

누가 채택 판단을 갖는가.

기각 기준은 무엇인가.

어떤 변경을 인간 리뷰로 넘길 것인가.

어떤 실패를 롤백(Rollback)할 것인가.

어떤 결과를 보고 판단 기준을 업데이트할 것인가.

업데이트한 판단 기준을 어디에 남길 것인가.

여기까지 내려가야 비로소 「변경 루프를 설계한다」라는 말에 의미가 생깁니다.

그렇지 않다면 그것 또한 새로운 편리한 말(Buzzword)일 뿐입니다.

평가하는 쪽도 대리 지표로 요령을 피우기 쉽다

지금까지 평가받는 쪽의 이야기를 해왔습니다.

하지만 똑같은 일이 평가하는 쪽에게도 되돌아옵니다.

평가하는 쪽도 대리 지표(Proxy Indicator)로 요령을 피우기 쉽기 때문입니다.

전 직장.

학력.

GitHub star 수.

강연 경력.

팔로워 수.

유명인으로부터의 추천.

소속 커뮤니티.

과거에 관여했던 프로덕트명.

이것들은 편리합니다.

짧은 시간 안에 판단해야 하는 채용이나 업무 위탁에서는 이러한 대리 지표를 완전히 버리는 것이 현실적으로 불가능합니다.

하지만 대리 지표를 사용한다면, 평가하는 쪽에게도 책임이 있습니다.

그 지표로부터 무엇을 말해도 되는가.

어디서부터 과잉 추론인가.

어떤 질문으로 판단 능력을 확인하러 갈 것인가.

어떤 실적을 재현성 있는 능력으로 다룰 것인가.

어떤 정보가 단순한 가시성에 불과한가.

이 부분을 설계하지 않은 채 평가하면, 결국에는 라벨의 강도로 판단하게 됩니다.

유명 기업에 있었으니 안심.

강연 경력이 있으니 강하다.

GitHub star가 많으니 우수하다.

유명인이 추천하고 있으니 신뢰할 수 있다.

이것들은 전혀 무의미하지 않습니다.

하지만 그것만으로 판단을 종결한다면, 평가하는 쪽이 대리 지표에 의존하고 있을 뿐입니다.

평가하는 쪽에게 필요한 것은 대리 지표를 버리는 것이 아닙니다.

대리 지표로부터 무엇을 읽고, 무엇을 읽지 않을지를 결정하는 것입니다.

이 기사에서 가져갈 수 있는 것

엔지니어의 능력을 평가할 때는 대리 지표를 그대로 능력으로 변환하지 않는 것이 좋습니다.

소속을 본다면, 환경 의존성과 재현성을 본다.

담당을 본다면, 판단 권한과 책임 범위를 본다.

무용담을 본다면, 성립 조건과 사후 학습을 본다.

「강하다」라고 말한다면, 어떤 능력 카테고리의 이야기인지 구분한다.

AI 활용을 본다면, 생성 속도가 아니라 채택·기각·롤백(Rollback)·책임을 본다.

커뮤니티 내 평가를 본다면, 그 자리의 평가 측면이 무엇에 의존하고 있는지를 본다.

대리 지표는 버릴 필요가 없습니다.

다만, 대리 지표에는 주장 가능한 범위가 있습니다.

그 범위를 넘어 추론하면 평가는 왜곡됩니다.

가져갈 질문은 다음과 같이 압축할 수 있습니다.

그 정보는 무엇의 단서인가.

그로부터 무엇을 말해도 되고, 무엇을 말해서는 안 되는가.

현재의 관측·판단·책임·재현성·학습은 어디에서 확인할 수 있는가.

이 질문을 두는 것만으로도 평가의 오차는 상당히 작아집니다.

요약

SNS나 커뮤니티에서는 강력한 엔지니어상이 유통되기 쉽습니다.

유명 기업에 있었다.

유명 서비스를 담당했다.

대규모 인프라에 관여했다.

AI를 능숙하게 다룬다.

대규모 이전을 완수했다.

강한 사람은 결국 강하다.

이러한 이야기는 이해하기 쉽고 확산되기 쉽습니다.

하지만 그것들은 능력 그 자체가 아니라, 능력을 추측하기 위한 대리 지표입니다.

대리 지표는 중요합니다.

다만, 대리 지표에는 주장 가능한 범위가 있습니다.

소속은 환경 경험의 단서입니다.

담당은 접점과 책임 범위의 단서입니다.

무용담은 사건과 학습의 단서입니다.

유명성은 가시성의 단서입니다.

커뮤니티 내 평가는 그 자리에서 통용되고 있는 평가면 (evaluation surface)의 단서입니다.

정말로 보아야 할 것은, 그 사람이 무엇을 관측하고, 무엇을 판단하며, 어떤 책임을 지고, 어떤 실패로부터 무엇을 배우며, 다른 환경에서 무엇을 재현할 수 있는가 하는 점입니다.

AI 시대에는 후보 생성 (candidate generation)이 더욱 평준화될 것입니다.

그렇기에 평가해야 할 중심은 단순한 생성 속도나 소속 라벨에서 채용·기각·책임·롤백 (rollback)·학습으로 이동합니다.

강함을 소속이나 담당, 혹은 무용담에만 맡기지 마십시오.

그것이 개인에게도, 조직에게도 평가의 오차를 줄이는 길입니다.

Discussion