← Season 1

SEASON 1 · EP 03 OF 10

프로젝트는 진행됐는데, 그때의 판단 근거와 맥락은 남지 않았다

끝없이 이어지는 업무와 이를 기록할 Workflow가 없는 환경에서, 판단의 근거와 경험은 조직의 자산이 되기 전에 증발한다

김용연Season 1Episode 03
프로젝트는 진행됐는데, 그때의 판단 근거와 맥락은 남지 않았다 — Season 1 key visual

Project에는 많은 것이 남는다.

RTL, Script, Spec, Report, Simulation Result, Review Material, Issue/Ticket, Email, Configuration, 최종 적용 값.

그런데 시간이 지난 뒤 그 자료를 다시 보면 이상하게도 가장 중요한 질문에 답하기 어려울 때가 있었다.

“왜 이렇게 했지?”

결과는 남아 있는데, 그 결과에 도달한 판단의 맥락이 남아 있지 않은 것이다.

Project Artifact ≠ Knowledge Asset

당시 어떤 Assumption을 가지고 있었는지, 무엇을 비교했는지, 어떤 Alternative를 버렸는지, 어떤 Risk를 Accept했는지, 왜 처음 판단을 바꾸었는지, 어떤 Exception을 허용했는지.

이런 내용은 최종 Script나 Report만 봐서는 알기 어려운 경우가 많았다.

몇 주나 몇 달 뒤에도 “왜 그렇게 판단했는가”를 다시 이해하기 위해 필요한 Rationale(Spec, Datasheet, Standard, Paper 등), 적용한 Criteria, 당시 Assumption, 검토한 Alternative, 허용한 Exception, 받아들인 Risk와 당시 조건 같은 정보(이후 Decision Context로 표현)가 Final Result와 함께 남아 있어야 했다.

이 문제는 SoC로 개발 범위가 넓어지면서 더 민감하게 느껴졌다.
내가 IP나 ASIC의 일부 영역을 중심으로 일하던 시기에는 한 Engineer가 주요 History와 판단 기준의 상당 부분을 기억하고 있는 방식도 어느 정도 동작할 수 있었다.
하지만 SoC처럼 Block과 Interface, Constraint와 Decision의 연결이 많아질수록 ‘그 사람이 기억하고 있다’는 방식 자체가 점점 취약해진다.
한 사람의 기억이 Project Memory 역할까지 맡으면, 그 사람이 Available하지 않을 때 드러나는 Knowledge Loss의 크기도 커질 수 있다.
그리고 Knowledge Loss는 사람이 회사를 떠나는 순간에 갑자기 시작되는 것이 아니라는 생각도 하게 됐다.

Decision Context가 Workflow에 남지 않는 순간부터 이미 일부 Knowledge는 사람의 기억에 의존하기 시작한다.

다만 그 사람이 계속 옆에 있으면 손실이 잘 보이지 않을 뿐이다.

“그때 왜 이렇게 했어요?”라고 물으면 답을 들을 수 있기 때문이다.

특정 Block의 History, 과거 Failure, 왜 특정 Rule이 생겼는지를 가장 잘 아는 사람(이후 Knowledge Holder로 표현)이 Project마다 생겼다.
문제는 그 사람이 필요한 순간에도 항상 현재 업무에 참여할 수 있는 것은 아니라는 점이다.

다른 Project로 이동할 수도 있고, Role이 바뀔 수도 있고, 여러 Project를 동시에 지원할 수도 있고, 조직 개편이나 장기 공백이 생길 수도 있다.
이직과 퇴사는 그중 일부다.

그 사람이 Available하지 않은 순간, Artifact는 그대로 있는데 왜 그렇게 판단했는지를 설명하기 어려운 상태가 드러난다.

나는 이것을 Knowledge Loss가 그때 시작된 것이라기보다, 사람의 기억으로 가려져 있던 손실이 그때 보이기 시작한 것이라고 생각한다.

왜 Context를 남기지 못했을까?

내 경험에서는 대부분 “정리하지 않으려고”가 아니었다.

“이 Issue부터 해결하고 정리해야지.” “이번 Run 끝나면 정리해야지.” “Project 끝나면 한번 정리해야지.”

그런데 SoC Project는 Block이 끝나면 Integration이 시작되고, Verification이 이어지고, Issue와 Change, Re-verification, Handoff가 계속된다.

“끝나고 정리할 시점”이 생각보다 잘 오지 않는다.

판단의 이유와 Context를 남기는 일이 정식 Engineering Workflow에 포함되지 않고 시간이 남으면 하는 추가 업무라면 계속 뒤로 밀리기 쉽다.

나 역시 몇 주 뒤 예전 자료를 다시 보며 “내가 왜 이렇게 했지?”를 복원한 적이 있다.

Report를 찾고, Email을 찾고, Commit을 보고, Result를 다시 비교하고, 당시 참여자에게 물어본다.

이미 한 번 했던 판단의 이유를 처음부터 다시 복원하는 것이다.

이렇게 Context가 남지 않으면 다음 사람도 비슷한 일을 반복한다.

자료 찾기 → 사람에게 묻기 → 결과 비교 → 이유 추정 → 판단 맥락 복원 → 다시 확인

가장 빠른 방법은 기존 Knowledge Holder에게 다시 묻는 것이고, 그럴수록 그 사람의 시간은 또 과거 설명에 사용된다.

2편에서 말한 Effective Decision Capacity가 다시 줄어드는 Loop가 생긴다.

그래서 해결책을 “문서를 더 열심히 쓰자”라고만 말하고 싶지는 않다.

문서화 자체는 중요하다.
하지만 이미 일이 끝난 뒤 기억을 되짚어 문서를 만드는 방식은 또 사람의 시간을 요구하고, 그 사이 일부 Context는 사라졌을 수도 있다.

내가 궁금해진 것은 다른 것이었다.

판단이 만들어지는 순간에 그 이유와 Context도 함께 남길 수는 없을까?

그리고 그렇게 남긴 것을 다음 업무에서 다시 사용할 수 있다면, 사람에게 같은 설명과 과거 판단 복원을 반복해서 요구하지 않아도 되지 않을까?

이 질문이 내가 AI를 업무에 직접 적용해 보기 시작한 출발점 중 하나가 됐다.

다음 편 — 판단의 이유와 경험을 Workflow 안에서 남긴다면, AI Agent가 그 일을 도울 수 있을까?