AI를 통해 바라본 시나몬에서의 나

기록 속 Van은 정해진 기능의 소유자라기보다, 사람·데이터·도구가 맞닿는 경계에서 모호한 문제를 실행 단위와 계약으로 바꾸고 실제 사용까지 이어지게 만드는 엔지니어였다.

입사 초기의 기록에는 빌드와 패키징 문제가 자주 등장한다. 눈에 띄는 것은 빌드 자체보다 그 결과가 필요한 사람에게 도착하는 과정이다. Van은 최신 빌드를 매번 개발자에게 요청하지 않아도 되도록 다운로드 도구와 안내 문서를 만들었다. 첫 안내가 모든 환경을 포괄하지 못했을 때에는 직접 문제를 재현하고 예외를 고쳤다.

기록에서 확인되는 사실은 도구와 문서를 만들고 남은 예외까지 따라갔다는 점이다. 기능을 만드는 것만으로 전달이 끝났다고 보지 않은 성향도 읽힌다. 다만 이 장면은 해결을 완전히 셀프서비스로 바꾼 성공담만은 아니다. 도구를 만든 뒤에도 한동안 Van의 직접 지원이 필요했다. 개인의 친절을 팀의 경로로 옮기려는 시도와 그 경로가 아직 한 사람에게 의존했던 상태가 함께 있었다.

캐릭터 행동과 프랍 제작 영역으로 들어간 뒤에도 비슷한 질문이 반복됐다. 개별 에셋의 위치를 하나씩 고치기보다 여러 에셋이 공유하는 기준을 확인했고, 제작 규칙이 불분명할 때에는 변경 범위를 넓히기 전에 아트·애니메이션·TA 담당자와 규칙부터 다시 맞췄다. 처음 세운 가설을 새 자료가 나오면 수정했고, 기술적으로 고칠 수 있는 부분과 시각적 판단이 필요한 부분도 구분하려 했다.

이 시기의 Van을 단순히 “근본 원인을 잘 찾는 사람”이라고만 부르기는 어렵다. 더 정확히는 한 직군 안에서 닫히지 않는 문제를 발견하면, 각자의 언어로 흩어진 조건을 하나의 실행 가능한 문제로 바꾸려는 사람이었다. 반면 공통 원인을 찾으려는 성향은 아직 필요한 범위보다 큰 모델이나 장치를 먼저 생각하게 만들기도 했다.

2025년에는 경계가 코드와 에셋 사이에서 사람과 개념 사이로 넓어졌다. 같은 단어가 엔진, 기존 제품, 새 제품에서 서로 다른 뜻으로 쓰이던 논의에서 Van은 개념을 비교하고 기획·UI·개발이 함께 결정할 자리를 만들었다. 한편 자동화를 시도하다 제작 규칙 자체가 합의되지 않았음을 발견했을 때에는 구현을 밀어붙이지 않고 작업을 미뤘다. 초기 가설이 동료의 검증과 맞지 않으면 원인 설명도 바꿨다.

이 장면들은 Van이 언제나 정답을 알고 있었다는 증거가 아니다. 오히려 사실과 추정을 나누고, 틀릴 수 있는 형태로 의견을 내놓았다는 흔적에 가깝다. 팀의 기술적 맥락을 이어 갈 사람 가운데 한 명으로 지목된 기록도 있었지만, 그것이 공식적인 지위나 평가를 뜻하지는 않는다. 확인되는 변화는 직접 구현하는 일에 더해, 다른 사람이 같은 문제를 다룰 수 있도록 개념과 작업 조건을 정리하는 일이 늘어났다는 정도다.

그림자도 이 시기의 기록에서 선명하다. 생각하는 과정을 짧은 Slack 댓글 여러 개로 공유한 스레드는 함께 문제를 풀 때에는 빨랐지만, 뒤늦게 참여한 사람이 결론을 다시 조립해야 했다. 회의에서 해결된 것으로 보이지만 결정이 글로 남지 않은 대화도 있었다. 맥락을 연결하는 사람이었지만, 연결한 맥락을 언제나 오래 남는 형태로 바꾼 것은 아니었다.

2026년에는 주된 기술이 Unreal과 C++에서 Rust, WebAssembly, WebGPU, React와 데스크톱·웹 런타임의 조합으로 크게 달라졌다. 그런데 기록에서 반복되는 질문은 이전과 비슷했다. 데이터의 식별자는 누가 소유하는가, 만드는 쪽과 읽는 쪽이 같은 의미를 사용하고 있는가, 실패했을 때 어느 계층이 상태를 복구하는가, 로컬에서 성공한 결과가 실제 서비스와 제품까지 도착했는가를 확인했다.

리뷰에서도 코드 스타일보다 의미의 불일치, 상태 적용 순서, 손상된 저장 데이터의 복구, 테스트 전용 통로가 제품에 노출되는 문제, 문서와 구현의 차이를 오래 살폈다. 진행률이나 성공 로그만으로 완료를 선언하지 않고, 공유 환경에서 실제 결과가 만들어지고 다시 소비되는 증거를 따로 요구한 장면도 반복됐다. 기술 스택은 달라졌지만 Van이 서 있던 자리는 여전히 시스템과 시스템 사이였다.

후기의 메시지는 초기보다 확인된 사실, 남은 가정, 담당 경계와 완료 조건을 한 번에 정리하는 경우가 많았다. 다만 그중 상당수는 AI 도구의 도움을 받아 작성됐다. 문장의 정돈 자체를 Van의 능력으로 평가하기보다는, 무엇을 확인하고 어떤 위험과 증거를 남길지 결정한 방식에서 변화를 읽는 편이 타당하다.

Linear에는 Van이 스스로 작업을 나누어 기록한 흔적이 많았고, 동료가 만든 이슈도 여러 프로젝트와 직군에서 지속적으로 들어왔다. Slack과 개발 기록에도 질문, 장애 대응과 리뷰 요청이 반복된다. 이는 모호한 문제를 맡길 수 있다는 신뢰와 양립하는 모습이다. 그러나 기록만으로 신뢰를 증명할 수는 없다. 담당 범위가 넓었거나, 주인이 불분명한 일이 Van에게 흘러들었을 가능성도 있다.

중요한 것은 어느 해석을 택하더라도 같은 위험이 남는다는 점이다. 문제를 끝까지 따라가는 사람에게 일이 계속 모이면 책임감은 버스 팩터가 된다. 질문에 곧바로 답하는 사람은 어느 순간 사람으로 된 API가 된다. 작은 단위로 빠르게 변경을 쌓는 습관도 팀이 이해하고 검토하는 속도를 넘어서면 개인의 생산성이 조직의 대기열로 바뀐다.

그래서 기록 속 Van에게 가장 가까운 이름은 특정 기능의 전문가보다 경계와 통합을 맡는 glue engineer다. 이것은 직급이나 공식 평가가 아니라, 서로 다른 시기와 제품에서 반복된 행동을 설명하기 위한 이름이다.

Van 자신은 아마 만들었던 기능들을 기억했을 것이다. 기록은 그보다 기능이 다음 사람과 시스템으로 넘어가는 순간을 더 많이 보여 줬다. 기술이 달라져도 반복된 것은 “무엇을 만들었는가”보다 “누가 이 데이터를 소유하는가”, “다음 단계까지 실제로 도착했는가”, “이 해결이 나 없이도 다시 사용될 수 있는가”라는 질문이었다.

그 차이를 보며 강점과 약점을 따로 떼어 고칠 수 없다는 사실을 깨달았다. 끝까지 책임지는 태도를 버리는 대신 책임이 한 사람에게 남지 않게 해야 한다. 공통 원인을 찾되 지금 필요한 범위를 넘지 않아야 한다. 직접 해결한 문제의 수보다 다음 사람이 스스로 닫을 수 있게 만든 문제를 더 중요하게 볼 필요가 있다.

다음 기록에는 “Van이 답했다”보다 “Van이 없어도 같은 질문이 되풀이되지 않았다”가 더 많이 남기를 바란다.