엔지니어의 리더십: 목표 설정, 스칼라 대신 벡터로

작성자:

연말이나 연초, 혹은 새 과제를 시작할 때면 과제의 목표를 설정해야 합니다. 그럴 때 자주 듣는 이야기가 숫자로 정리해 오라는 말입니다. 그러면 대개 “성능 10% 개선”과 같은 큼직한 숫자 하나가 올라옵니다.

리더 입장에서는 이때부터 스무고개가 시작됩니다. 어떤 성능입니까? 속도? 메모리? 소모전력? 10%의 기준은 무엇입니까? SOTA? 경쟁사? 아니면 자체 기준? 만약 SOTA(State of the Art)라고 답이 오면 질문은 더 늘어납니다. 어떤 데이터셋에서의 SOTA입니까? 어떤 환경에서 측정한 수치입니까? 끝이 없습니다.

사실, 질문이 끝나지 않았던 이유는 보고자가 답을 몰라서라기보다는 애초에 답하기가 어려운 형태의 목표를 들고 왔기 때문입니다. 숫자는 있는데 그 숫자가 어디서 어디로 가는 것인지에 대한 설명이 부족한 거죠.

그래서 저는 같이 일하는 연구원들과 이야기할 때 목표 설정을 하거나 계획을 세울 때는 스칼라가 아니라 벡터로 세워야 한다는 말을 자주 했습니다. 이번 글에서는 관련 내용을 정리해 보았습니다.

목차

벡터 vs 스칼라

벡터와 스칼라, 수학 시간에 처음 배운 개념입니다. 스칼라는 크기만 있고, 벡터는 크기와 방향을 함께 가집니다.

그런데, 목표라는 것은 현재 상태에서 다른 상태로 옮겨가는 일이므로, 크기만으로는 설명되지 않습니다.

“성능 10% 개선”은 크기만 있는 목표입니다. 숫자가 붙어 있어서 마치 정량적인 구체적 목표처럼 보이지만, 무엇을 해야 하는지가 표현되지 않습니다. 이 목표를 받은 사람이 할 수 있는 일은 그럴듯한 작업 목록을 만드는 것뿐입니다. 그리고 과제가 끝났을 때 그 목록에서 적당히 달성한 것들을 골라 10%에 맞춰 넣으면 됩니다.

목표를 정량화하라는 요구를 의도와 다르게 적용한 전형적인 경우입니다. 숫자를 채워 넣는 것만으로 계획이 끝났다고 여기는 상태입니다. 사실 숫자를 통한 정량화 자체가 문제는 아닙니다. 하지만 방향을 먼저 정하고 크기를 붙이는 것과, 크기부터 정한 후에 방향을 채우는 것은 전혀 다른 일입니다.

제가 생각할 때 계획을 세운다는 것은 “어디서 출발하는지(원점)”, “어느 쪽으로 가는지(방향)”, “얼마나 가는지(크기)” 를 함께 다룬다는 뜻입니다. 즉 목표를 설정하고 계획을 세우는 일은 스칼라 대신 벡터로 세워야 한다는 말입니다.

원점 찾기, 모판 식별

방향을 말하려면 먼저 어디서 출발하는지를 말할 수 있어야 합니다.

가령 “SOTA 대비 10% 개선”이라는 목표를 예로 들어보겠습니다. 이 말이 성립하려면 SOTA가 하나의 상태여야 합니다. 그런데 대부분의 SOTA는 특정 조건(데이터셋, 하드웨어, 입력 값 등)에서 달성한 결과입니다.

그래서 만약 그 조건을 바꾼다면 이야기는 달라집니다. 실제로 많은 엔지니어들과 이야기해 보면, (우리에게 유리한) 특정 상황에서는 우리의 기술이 이미 SOTA보다 나은 경우가 흔합니다. 오랜 기간 동안 다뤄온 도메인의 데이터, 우리 제품에 실제로 전달되는 입력 값들에서는 그럴 수 있다는 뜻입니다. 하지만 SOTA 기술이 적용한 조건을 똑같이 적용하면 전혀 다른 결과가 나옵니다.

숫자를 먼저 정하고 조건을 나중에 고를 수 있다면, 이는 “목표가 사후에 정당화될 수 있다”는 뜻이 됩니다. 좀 더 유리한 조건을 찾고, 실험 결과를 도출한 후에 그걸 바탕으로 목표를 달성했다고 보고할 수 있고, 실제로 그렇게 됩니다. 하지만 이렇게 하는 건 문제가 됩니다. 기준이 다른 두 값을 비교했기 때문에 기술적으로 무의미한 비교가 될 수 있습니다. 기준점이 명확하지 않으면, 목표는 평가할 수 있는 대상이 아니라 해석의 영역으로 넘어가 버립니다.

원점을 정하는 일은 단순히 숫자를 고르는 일이 아니라 조건을 정하는 일입니다. 어떤 데이터에서, 어떤 환경에서, 어떤 입력 값에서 결론을 도출할 것인가 정하는 일입니다. 이것이 정해지고 나서야 비로소 “10%”라는 크기가 의미를 가집니다.

그리고 그 조건을 특정하려면 해당되는 기술 도메인의 전체 판을 알고 있어야 합니다. 지금 이 분야가 어디까지 왔는지, 어떤 조건에서 누가 강한지, 우리의 위치는 어디인지 등 전반적인 트렌드와 객관적인 현황 파악이 되어야 합니다. 이걸 모르면 SOTA는 그저 “우리보다 잘하는 누군가”라는 막연한 우상이 됩니다.

리더가 도메인을 알아야 하는 이유가 바로 여기 있습니다. 목표를 숫자로 요구하는 데는 도메인 지식이 필요한 건 아니지만, 모판을 파악하고 원점을 세워주는 데는 반드시 필요합니다.

벡터는 분해된다

방향이 정해지면 목표는 벡터를 구성하는 성분으로 나뉩니다.

선호도를 예측하는 모델을 개발하는 과제를 예로 들어보겠습니다. “예측률 70% 달성”이라는 목표를 세웠습니다.

역시 질문이 시작됩니다. 무엇의 70%입니까? 정확도입니까? 재현율입니까? 정밀도입니까? 어떤 데이터에서입니까? 학습셋입니까? 검증셋입니까? 운영 데이터입니까? 그리고 지금은 얼마입니까? 등 수많은 질문이 쏟아집니다.

사실 이 질문들에 답이 채워진 벡터형 목표는 이런 형태가 되어야 합니다.
“운영 데이터에서 재현율을 55%에서 70%로 올린다. 응답 지연은 현 수준을 유지한다.”

이 상태에서는 목표를 구성 성분으로 나눌 수 있습니다. 재현율을 끌어올리는 일은 데이터 품질, 피처, 모델 구조라는 성분으로 분해됩니다. 각 팀이 자기 성분을 맡고, 성분들이 모여 전체를 구성합니다. 각 팀은 자기가 맡은 성분이 전체의 어느 부분인지 알고 있습니다.

반면 “예측률 70%”는 나눌 수가 없습니다. 팀이 셋이면 각각 70%를 하라고 말하거나 팀별로 23%씩 하라는 것이 전부입니다. 이것은 엄밀한 의미에서 분해라고 볼 수 없습니다. 세 팀이 같은 일을 중복해서 하거나, 각자 다른 해석으로 각자의 일을 하거나, 혹은 둘 다 일어나겠죠.

주의할 점은, 목표를 잘게 쪼갠다는 말과 목표를 분해한다는 말이 서로 다르다는 것입니다. 쪼개는 것은 크기를 단순히 나누는 일이고, 분해하는 것은 방향을 성분으로 나누는 일입니다.

벡터는 합성된다

스칼라는 더하면 커지지만, 벡터는 방향에 따라 증폭되기도 하고 상쇄되기도 합니다.

소프트웨어의 결함을 검출하는 정적 분석기 개발을 예로 들어보겠습니다. 목표는 “검출 정확도 개선”입니다.

한 팀은 오탐을 줄이는 일을 맡습니다. 오탐을 줄이려면 확실한 것만 잡아야 하므로, 결함을 검출하는 체커의 종류는 늘리지 않고 기존 체커의 판정 정확도를 올립니다. 애매한 경고는 제외합니다.

다른 팀은 미탐을 줄이는 일을 맡습니다. 놓치는 결함을 잡으려면 검출 범위를 넓혀야 하므로, 새로운 결함을 검출하는 체커의 종류를 늘립니다. 새로 추가한 체커는 아직 성숙하지 않으므로 애매한 경고를 함께 만들어냅니다.

두 팀 모두 각자의 목표를 달성했습니다. 오탐율이 내려갔고, 미탐율도 내려갔습니다. 각자의 지표는 개선되었습니다. 그런데 사용자가 실제로 보는 경고 목록은 이전과 다를 바가 없습니다. 한쪽에서 열심히 애매한 경고들을 제외했지만, 다른 쪽에서 다시 채워 넣었기 때문입니다.

여기서 중요한 것은 두 팀 모두 틀리지 않았다는 점입니다. 오탐과 미탐은 보통 상충되는 관계이고, 각 팀은 각자의 관점에서 정확히 옳은 일을 했습니다. 문제는 목표를 나눌 때 방향을 고려하지 않았다는 데 있습니다. 오탐과 미탐을 서로 다른 팀에 떼어 주는 순간, 두 작업은 같은 벡터의 성분이 아니라 반대 방향의 벡터가 됩니다.

방향을 먼저 정하고 일을 나누기 위해서는, 먼저 어떤 결함 유형에서 미탐을 줄일 것인가를 정하고, 그때 오탐율의 허용 상한은 얼마인가를 정해야 합니다. 그렇게 원점과 방향이 정해지고 나면 두 팀의 작업은 같은 방향의 성분이 되고, 합쳐졌을 때 상쇄되지 않습니다.

또, 한 팀이 코드 표현이나 분석 정밀도 같은 공통 프레임워크를 개선해 주면, 다른 팀이 추가하는 새 체커들이 그 위에서 더 정확하게 동작하게 됩니다. 공통 프레임워크에서 만든 성과가 위에 쌓이는 성과의 효과를 키웁니다. 같은 방향을 바라보고 있을 때 나오는 결과입니다.

AI 시대, 커진 일감과 커진 오차

제 이전 글 「AI시대: 똑똑한 AI, 왜 안 쓸까 — 일하는 방식의 문제」에서 AI 시대에는 일감의 크기를 키워야 한다고 이야기한 적이 있습니다. 티켓 단위가 아니라 기능 단위로 위임하고, 컨텍스트를 아래로 내려서 구성원 각자가 더 큰 문제를 다룰 수 있어야 한다는 이야기였습니다.

중요한 것은 일감을 키운다는 게 각자가 만들어내는 벡터의 크기를 키우는 일이라는 뜻이고, 이때 크기가 커지면 방향이 다를 때 생기는 오차가 만드는 결과도 함께 커진다는 점입니다.

이전에는 일감이 잘게 쪼개져 있어서 방향이 조금 어긋나도 손실이 작았습니다. 리더가 매일 확인하고 조율하면서 방향을 잡아주기도 했습니다. 그런데 개인이 큰 덩어리를 들고 며칠씩 혼자 작업을 하다 보면, 어긋난 방향으로 그만큼 멀리 갑니다.

결국 개인의 생산성 지표는 좋아지는데 팀의 이동 거리는 제자리인 상황이 생깁니다. 각자 더 많이 만들었고 더 빨리 끝냈습니다. 하지만 결과를 합쳐 보면 서로를 상쇄합니다.

그래서 AI시대에 일감의 크기를 키울 때 반드시 함께 고려해야 하는 것이 목표를 벡터로 정의하는 일입니다. 그렇게 하기 위해서는 각자가 원점과 방향을 잘 알고 있어야 큰 일감을 들고도 같은 방향으로 갈 수 있기 때문에, 컨텍스트를 아래로 내리는 것이 더욱 중요해집니다. 방향 없이 크기만 키우면 팀 생산성은 오히려 나빠집니다.

벡터와 중장기 계획

기간이 길어질수록 도착 좌표를 특정하기 어렵습니다. 그래도 방향은 정할 수 있습니다.

그렇기 때문에 앞서 언급한 원점 문제가 더욱 중요해집니다. 가령 3년 뒤의 SOTA는 지금의 SOTA가 아닙니다. 경쟁사의 위치도, 시장이 요구하는 수준도 달라질 것입니다. 결국 원점 자체가 움직이는 상황에서 도착 좌표를 확정적으로 설정한다는 것, 다시 말해 숫자의 크기로만 목표를 정한다는 것은 사실상 의미가 없을 수 있습니다.

실제로 중장기 계획을 해보면, 매년 숫자가 틀어집니다. 숫자를 잘못 잡아서가 아니라, 계획을 방향으로의 이동이 아닌 특정 상태로 잡았기 때문입니다. 특정 상태를 계획으로 잡으면 환경이 바뀔 때마다 계획을 처음부터 다시 세워야 하는 거죠.

하지만 목표를 방향으로의 이동으로 잡으면 상황이 달라집니다. 방향이 정해져 있으면 환경이 바뀌었을 때 크기만 조정하면 됩니다. 올해의 목표를 절반만 이동했다면, 남은 절반을 다음 해로 넘기거나, 새로운 이동을 목표로 잡는 것으로 정리됩니다.

결국 중장기 계획에서 정말로 검토해야 하는 것은 숫자가 맞았는지가 아니라 방향이 여전히 유효한지입니다. 그런데 현실에서는 대부분 숫자만 봅니다.

맺음말

목표를 숫자로 요구하는 것 자체가 문제는 아닙니다. 숫자만 요구하는 것이 문제입니다. 크기만 있는 목표는 나눌 수 없고, 나눌 수 없으면 합칠 수도 없습니다. 각자 열심히 일하고 각자 달성했다고 보고하는데 전체는 제자리인 상황이 생기는 이유입니다.

그래서 리더가 할 일은 숫자를 받아 적는 것이 아니라 원점과 방향을 세워주는 것입니다. 어디서 출발하는지, 어느 쪽으로 가는지를 정해주면 크기는 구성원이 채울 수 있습니다. 그리고 원점과 방향을 설정하려면 리더는 그 도메인의 전체 판을 알고 있어야 합니다.

크기만 있는 숫자는 목표처럼 보일 뿐, 계획이 아닙니다.

ChulJoo Kim (김철주)

※ 참고 문헌

ckarch.kr © 2026 is licensed under CC BY-NC-SA 4.0 CC BY NC SA

댓글 남기기