엔지니어의 리더십: 파이썬 뗐다? 상태는 O/X 대신 범위로

작성자:

얼마 전 아내가 아이 친구 엄마와 아이들 학교 공부에 관해 이야기하던 중에, ‘정보’ 과목을 어떻게 준비하는지 물었다고 합니다. 그때 들은 답은 “초등학교 때 파이썬 한 번 뗐어요. 그때 잘했고요. 더 준비 안 해도 될 것 같아요.”였습니다.

당연히 그분이 완전히 마스터했다고 주장한 것은 아닐 것입니다. 아마 어떤 과정이나 단계를 마쳤다는 뜻일 텐데, 그 구체적인 단계가 문장에서 빠졌습니다. 문제는 ‘뗐다’라는 표현입니다. 구체적인 단계가 빠진 ‘뗐다’는 표현을 들으면, 듣는 사람은 그 빈자리를 자기 기준으로 채웁니다.

지난 글 「엔지니어의 리더십: 목표 설정, 스칼라 대신 벡터로」에서 목표와 계획을 말하는 방법을 다뤘다면, 이번 글에서는 상태를 어떻게 판단하고 상태 보고를 어떻게 해야 하는지를 정리해 보려고 합니다.

목차

‘미적분’을 뗄 수 있는가?

미적분, 대부분의 공대에서 매우 중요한 과목입니다. 하지만 이름이 같다고 해서 같은 내용을 뜻하지는 않습니다.

고등학교에서 배우는 미적분, 대학 공학수학에서 다루는 미적분, 대학원에서 다루는 해석학은 이름은 같지만 다루는 대상이 다릅니다. 어느 하나를 마쳤다고 해서 미적분을 다 뗐다고 말할 수는 없습니다.

‘파이썬’도 마찬가지입니다. 문법을 익히는 일, 동작하는 프로그램을 만드는 일, 다른 사람이 쓸 것을 만드는 일은 서로 다른 일입니다. 특히 다른 사람이 사용할 프로그램을 만들 때는 각종 예외 처리와 검증, 배포 같은 작업이 따라오는데, 이는 문법을 안다고 해결되지 않습니다.

그런데 부정확한 표현 하나가 이 차이를 전부 제거해 버립니다. 말하는 사람은 자기 단계를 기준으로 말하고, 듣는 사람은 자기 단계로 해석합니다. 실제로는 둘 다 거짓말을 하지 않았는데 서로 다른 정보를 주고받게 됩니다.

사실 조직에서도 비슷한 표현을 자주 들을 수 있습니다.
“그 아이디어 예전에 해봤어요.” “작년에 교육 다 들었습니다.” “그 시스템은 이미 검증됐습니다.”
전부 단계가 없는 표현입니다.

O/X는 정보를 담지 못한다

‘뗐다’는 표현을 다르게 생각해보면 상태를 O/X로 말한 것으로 볼 수 있습니다.

지난 글에서는 목표를 숫자로만 말하면 방향이 사라진다고 썼듯이, 상태를 단순히 O/X로 말하면, 방향이나 크기 같은 진짜 필요한 정보가 모두 사라집니다.

학습이나 작업은 연속적인 과정입니다. 그런데 ‘뗐다’는 이 과정을 두 개의 값으로 압축합니다. 압축된 값은 이미 필요한 정보가 다 제거된 상태이기 때문에, 다시 펼칠 수 없습니다. 듣는 사람은 원래 값을 알 길이 없으니 본인의 경험이나 추측으로 채워 넣습니다.

우리는 소프트웨어 엔지니어링의 ‘회귀 테스트’에서 인사이트를 얻을 수 있습니다. 어제 빌드가 통과했다는 사실은 오늘 코드에 대해 아무것도 말해주지 않습니다. 그래서 변경사항이 생길 때마다 회귀 테스트를 돌려야 합니다. 하지만 단순히 테스트를 통과했다는 사실만으로는 무엇을 확인했는지 알 수 없기 때문에, 테스트 커버리지를 함께 보아야 합니다.

통과 여부와 확인 범위는 다른 정보입니다. 우리가 코드에 대해서 이 둘을 구분해서 보듯이, 사람의 상태에 대해서도 단순히 통과 여부만 말해서는 안 됩니다.

‘범위’로 말하자

그래서, 목표는 벡터로 말해야 하듯이, 상태는 범위로 말해야 합니다. 이때 필요한 것은, 해본 것과 해보지 않은 것, 그리고 기준 시점 등의 세 가지 정보입니다.

“파이썬 할 줄 압니다”와 “CLI 스크립트로 자동화는 해봤는데, 사람이 직접 사용할 GUI 프로그램은 아직 안 만들어 봤습니다”는 완전히 다릅니다. 앞 문장은 단순한 O 하나이지만, 뒤 문장에는 해본 것과 해보지 않은 것이 함께 들어 있습니다.

차이는 일을 맡기려고 할 때 확연히 드러납니다. 앞 문장을 들은 사람은 무엇을 맡길 수 있는지 판단할 수 없어 결국 자기 기준으로 판단해야 합니다. 반면, 뒤 문장을 들으면 곧바로 어떻게 배치할 수 있을지 방안이 나옵니다. 자동화 작업은 맡길 수 있고, 화면이 필요한 일이라면 함께 볼 사람이 필요합니다.

시점도 같이 붙여야 합니다. “예전에 했었습니다”와 “한 달 전에 마지막으로 했습니다”는 다른 정보입니다. 앞 문장은 상태를 말하는 것처럼 보이지만 실제로는 단순 기록을 말하고 있습니다.

이 세 가지 정보를 포함하는 일은 조직의 특별한 제도나 합의가 없어도 말하는 사람이 지금 바로 할 수 있는 일입니다.

경계를 말할 수 있는가?

경계를 말할 수 있는 사람이 실제로 아는 사람입니다.

자기가 어디까지 아는지 모르면 경계를 말할 수 없습니다. 그래서 ‘뗐다’는 말은 많이 아는 상태보다 다음 단계를 잘 모르는 상태에서 자주 나오는 것 같습니다. 사실 경계를 안다는 것은 벡터의 원점을 아는 것과 비슷합니다. 원점을 모르면 내 위치와 나아갈 방향을 알 수 없듯이, 경계를 모르면 다음에 무엇이 있는지 알 수 없습니다.

뒤집으면 이게 점검 기준이 됩니다. 지금 하는 일의 다음 단계에 무엇이 있는지 말할 수 있는지 확인하면 됩니다. 말할 수 있으면 그 단계를 지난 것이고, 말할 수 없으면 아직 그 안에 있는 것입니다.

엔지니어에게 배우는 자세가 필요한 이유가 여기 있습니다. 겸손해야 한다는 이야기가 아니라, 자기 상태를 알 수 있어야 한다는 이야기입니다. 경계는 벽에 막힐 때 알게 됩니다. 막혔던 지점과 틀렸던 지점이 경계를 알려줍니다.

AI 시대에 범위를 말하기가 더 어려워진 이유

범위를 말하려면 자기가 어디까지 해봤는지 알아야 하는데, AI는 그 경험이 형성되는 과정을 건너뛰게 합니다. AI와 함께 일하면 막히는 구간이 줄어들기 때문입니다. 결과가 나오기는 하는데 어디서 막혔는지가 남지 않고, 정확한 경계를 알려주던 신호가 사라지는 것입니다.

이전 글 「AI시대: AI 에이전트와 인지부채, ‘딸깍’의 청구서」에서 다룬 Kosmyna 연구에 이와 관련된 관찰이 있습니다. 참가자를 LLM 사용, 검색엔진 사용, 도구 없음 세 그룹으로 나눠 에세이를 쓰게 했는데, LLM 그룹은 방금 자기가 제출한 글에서 한 문장을 정확히 인용하지 못한 경우가 대부분이었습니다. 결과물은 있는데 자기가 무엇을 썼는지 말할 수 없는 상태입니다. 이 글의 표현으로 옮기면 ‘O’는 찍혔는데 범위를 말할 수 없는 상태입니다.

자기 상태에 대한 판단을 직접 측정한 연구도 있습니다. Fernandes 연구진이 246명에게 AI를 쓰면서 논리 추론 문제 20개를 풀게 했더니, AI 없이 푼 응시자 평균은 20개 중 9.5개였는데, AI를 쓴 참가자들은 13개를 맞혔습니다. 그런데 본인 예측은 실제보다 3.5개가 더 높은 16.5개 였습니다. 자기 점수를 높게 보는 것은 AI가 없어도 나타나는 현상이지만, 보통은 실력에 따라 다르게 나타납니다. 잘 못한 사람이 크게 빗나가고 잘한 사람은 비교적 근접하는데, AI를 쓴 집단에서는 실력과 무관하게 모두가 비슷한 정도로 빗나갔습니다. 즉 본인의 경계를 파악하지 못하는 현상이 고르게 나타난다고 해석할 수 있습니다.

물론 이 연구들이 보여주는 것은 상관관계이고, AI가 자기 인식을 망가뜨린다고 단정할 수 있는 근거는 아닙니다. 다만 결과물의 품질이 올라가는 것과 자기 상태를 정확히 아는 것이 함께 따라가지 않는다는 점은 두 연구에서 공통으로 나타납니다.

중요한 것은 AI로 인해 약해지는 신호입니다. 원래 “했습니다”에는 부정확하긴 하지만, 그래도 필요한 과정을 지나왔다는 신호가 있었습니다. 하지만 AI가 그 과정을 대신하면서, “했습니다”라는 말만으로는 어떤 과정을 지나왔는지를 말해주지 못하게 되었습니다.

대응은 결과가 아니라 과정을 남기는 것입니다. 어디서 막혔고 무엇을 확인했는지가 기록되어야 경계를 알 수 있습니다.

경계를 말하면 손해 보는 조직

개인이 정확히 말하려고 해도 조직이 그걸 손해 보는 일로 만들면 소용이 없습니다.

못 해본 범위를 말하면 평가에서 깎이는 곳에서는 ‘O’가 안전한 답입니다. 듣는 쪽도 마찬가지입니다. 완료 선언을 그대로 받는 데는 아무 비용이 들지 않는데, “어디까지 해보셨어요”는 질문하는 비용도 들고, 의심처럼 들립니다. 결국 양쪽 모두 더 안전하고 비용이 싼 선택을 하게 되어서 경계를 확인하는 과정을 생략한 채 넘어가게 됩니다. 그리고 그 위에 다음 단계와 계획이 올라갑니다.

앞서 언급했듯이 엔지니어링에서는 이 문제를 자동화된 테스트 결과와 커버리지로 풉니다. 사람의 상태도 마찬가지여야 합니다. 무엇을 확인했고 어디서 막혔는지가 일하는 과정에서 자연스럽게 드러나도록 일하는 방식을 만들면, 경계를 말하는 것이 용기 낸 고백이 아니라 보고의 일부가 됩니다.

리더의 역할도 중요합니다. 리더가 먼저 자기 경계를 말해야 합니다. 또 경계를 말하지 않음으로써 생기는 문제에 대한 비용을 더 크게 볼 줄 알아야 합니다. 물론 모든 상태를 직접 확인할 수는 없습니다. 중요한 것은 확인하는 과정이 일하는 방식의 일부가 되도록 하는 것입니다.

맺음말

“뗐다”는 나쁜 말이라기보다는 정보를 담지 못하는 말입니다. 상태는 ‘있다’와 ‘없다’로 나뉘지 않고, ‘언제 어디까지 왔는지’로 표현됩니다. 상태를 범위로 말하는 것은 개인의 습관이고, 범위를 말해도 손해 보지 않게 만드는 것은 조직의 일입니다. 두 가지가 같이 가야 상태 보고가 정확한 정보가 됩니다.

상태를 O/X로 말하는 순간, 그다음이 보이지 않게 됩니다.

ChulJoo Kim (김철주)

※ 참고문헌

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

댓글 남기기