무엇을 알아야 충분한가
요즘은 내가 읽지 않은 코드가 머지된다.
에이전트와 여러 차례 계획을 맞추고 테스트를 돌리고 실제 기기에서도 확인한다. 그래도 모든 줄을 직접 쓴 것도, 예전처럼 모든 변경을 순서대로 읽은 것도 아니다.
그러다 보면 가끔 묻게 된다.
내가 읽지 않은 코드를 머지하면서도 엔지니어라고 할 수 있나?
비슷한 질문들이 따라온다. 내가 아니어도 이 일을 할 수 있지 않나. 코드를 쓰지 않는다면 나는 무엇을 하는 사람인가.
한동안은 역할의 이름을 바꿔 답해보려 했다. 에이전트가 작성하고 나는 설계와 검증을 맡는다고. 하지만 이름만 바꾼다고 내가 실제로 내리는 판단까지 설명되지는 않았다.
질문을 받으면 설명할 수 있을까
작업을 돌아보니 반복해서 하는 일이 있었다. 누군가 이 변경을 보고 무엇을 물어볼지 먼저 생각하는 거다.
왜 이렇게 고쳤어요? 다른 화면은 괜찮아요? 이 의견은 왜 반영하지 않았어요?
나도 이해하지 못했는데 질문을 받으면 설명할 수 있을까. 막히는 부분이 있으면 다시 화면을 보고 코드를 읽고 AI에게 묻는다. 그러다 보면 처음에는 괜찮다고 생각했던 결과물을 다시 고치기도 한다.
최근 실험실 기능의 화면을 다듬는 작업을 했다. 처음 안에서는 사용자가 추가 버튼을 누르면 바로 기능 선택 화면이 열렸다. 아직 안정성을 보장하기 어려운 기능인데도, 무엇을 감수해야 하는지는 행동을 시작한 뒤에야 알 수 있었다.
“추가할 때 그냥 바로 화면이 뜨는 건 걱정인데. 실험실 기능이잖아.”
내가 묻자 AI는 그제야 문제를 인정했다. 같은 화면에서 위험을 먼저 설명하고 동의를 받은 다음 선택으로 넘어가도록 흐름을 바꿨다.
다시 화면을 보다가 또 물었다.
“사용자 정의 네트워크란 뭔데? 이 설명은 어디 있지?”
설명은 있었다. 다만 사용자가 결정을 내린 다음에야 만나는 위치에 있었다. AI도 순서가 뒤집혔다고 인정했고 설명을 선택보다 앞으로 옮겼다.
이후 자동 검토에서는 안내 문구가 잘 보이지 않고 설명과 버튼이 너무 멀다는 지적도 나왔다. 나는 처음엔 괜찮아 보였지만 듣고 보니 맞는 말이었다. 그 부분도 고쳤다.
내가 먼저 알아챈 것도 있고 AI의 지적을 듣고 받아들인 것도 있었다. 처음부터 완성된 기준을 갖고 검토한 것은 아니었다. 화면을 보고 질문하고 고치는 동안 무엇이 필요한지도 조금씩 분명해졌다.
확인하다 보니 문제가 달라졌다
다른 작업에서는 뒤로 가기를 했을 때 직전 화면의 탭과 스크롤 위치가 사라지는 문제를 고쳤다. 한 화면의 상태를 저장하면 끝날 것 같았다.
살펴보니 같은 구조를 쓰는 다른 페이지에서도 스크롤 복원이 작동하지 않았다. 화면을 이동하는 방식에 따라 복원해야 할 때와 초기화해야 할 때도 달랐다.
그러니 처음 문제가 보였던 화면만 고쳐서 끝낼 수 없었다. 질문이 늘어났다.
다른 화면에서도 괜찮을까. Android에서 뒤로 가기를 누르거나 iOS에서 스와이프할 때는 어떨까.
이걸 고치다가 기존 이동 규칙까지 깨뜨리는 건 아닐까.
Android와 iOS 실기기에서 확인했고 같은 계열의 화면과 기존 이동 규칙은 테스트로 살폈다. 수정한 핵심 코드를 되돌렸을 때 대상 테스트가 다시 실패하는지도 확인했다. 이번에 발견한 문제를 실제로 잡는 테스트인지 보고 싶었다.
AI 리뷰에서는 모든 화면 전환마다 스크롤 추적 값을 맞추자는 제안도 나왔다. 얼핏 안전해 보였다. 하지만 그대로 반영하면 저장해둔 위치를 0으로 덮어쓸 수 있었다. 새 위치를 읽기 전의 값이었기 때문이다.
원래 고치려던 버그를 다시 만드는 셈이었다. 제안은 새 화면으로 교체하는 이동에만 적용하도록 범위를 좁혔다.
내가 놓친 부분을 보려고 리뷰를 받는다. 실제로 놓친 것도 많다. 그렇다고 모든 지적을 반영할 수는 없었다. 같은 제안도 어떤 화면 이동에 적용하느냐에 따라 버그를 막기도 하고 다시 만들기도 했다. 무엇을 확인했고 아직 무엇을 모르는지 알아야 그 의견을 받아들일지 설명할 수 있었다.
무엇을 문제로 보고 있었나
처음에는 이 경험을 품질 기준의 문제라고 생각했다. 어느 정도까지 확인하고 내보낼 것인가. 그런데 확인할 항목을 고르기 전부터 이미 선택하고 있는 게 있었다. 이번 작업에서 무엇을 문제로 볼 것인가.
실험실 기능에서 내가 걱정한 것은 사용자가 무엇을 감수하는지 모른 채 기능을 추가하는 일이었다. 그래서 설명이 어딘가에 있다는 것만으로는 부족했다. 선택하기 전에 읽을 수 있어야 했다.
문제 프레이밍이라는 말을 내 경험에 대입하면 이런 일에 가까웠다. 무엇을 지키려는지, 어디까지를 같은 문제로 볼지 정하는 일. 화면이 뜬다는 사실은 같아도 사용자가 이해한 뒤 선택하는지를 물으면 고쳐야 할 것이 달라진다.
물론 범위를 넓히는 게 항상 답은 아니다. AI가 일을 너무 크게 잡으면 이번에 필요한 만큼으로 줄이기도 한다. 반대로 한 화면만 확인하다가 공통 문제를 발견하면 더 넓게 봐야 한다. 처음에 문제를 잘 정의했다고 해서 끝까지 그대로 가는 것은 아니었다.
더 확인하면 무엇이 달라질까
그렇다고 계속 범위를 넓히며 모든 것을 확인할 수는 없다. 코드도 많고 화면도 많다. 리뷰를 더 받으면 새로운 의견은 계속 나온다. 어디부터 확인해야 할까.
iOS에서 동작이 다르면 수정이 더 필요하다. 같은 구조의 다른 화면도 깨져 있다면 지금 잡은 범위로는 부족하다. 이런 질문은 답에 따라 다음에 할 일이 달라진다. 그래서 먼저 확인할 이유가 있다.
확인했는데 아무 문제가 없을 수도 있다. 코드 한 줄 바꾸지 않았어도 그 확인은 필요했다. iOS에서도 동작하는지 몰랐던 상태와 실제로 확인한 상태는 다르다. 수정 방향이 그대로여도 내보내겠다는 판단에는 근거가 하나 더 생긴다.
정보 가치라는 개념을 내 일에 적용하면 이런 뜻으로 이해하게 된다. 이걸 알아보는 데 드는 시간에 비해, 그 답이 지금의 결정을 얼마나 도와주는가. 방향을 바꿔야 한다는 걸 알려줄 수도 있고 지금 방향으로 진행할 근거를 줄 수도 있다.
반대로 전체 테스트가 통과해도 이번에 문제가 된 이동 경로를 다루지 않는다면 그 동작을 믿을 근거로는 부족하다. 통과한 테스트의 수보다 무엇을 확인한 테스트인지가 중요했다.
문제 프레이밍과 정보 가치는 작업 중에 계속 맞물렸다. 한 페이지의 버그라고 생각해서 확인을 시작했다가 다른 화면도 깨진 것을 보고 문제를 다시 잡았다. 그러면 새롭게 확인할 것이 생겼다. 처음부터 알아야 할 것의 목록이 완성돼 있었던 게 아니다.
내가 계속 하던 일은 이 질문을 고치는 일이었던 것 같다. 지금 풀고 있는 문제가 맞는지. 다음으로 무엇을 확인하면 되는지.
나는 무엇을 하는 사람인가
이제는 설계자나 검증자라는 이름을 붙여도 마음이 완전히 편해지지는 않는다. AI도 문제를 다시 정의하고 무엇을 확인할지 제안한다. 판단만은 내 몫이라고 선을 긋기에는 이미 도움을 받는 부분이 많다.
그래도 실제 작업에서 내가 하는 일은 전보다 구체적으로 설명할 수 있다. 너무 커진 계획을 줄이고 놓친 영향을 확인한다. 괜찮아 보였던 화면도 지적이 맞으면 고친다. 회귀를 나중에 대응하자는 제안에는 지금 해결해야 하는 이유를 설명한다. 어느 쪽이 제안했든 제품에서 지켜야 할 것에 맞춰 선택을 조율한다.
그 과정에서 알아낸 것을 테스트로 남기기도 한다. 뒤로 돌아왔을 때 위치가 유지되는지, 새 화면에서는 초기화되는지. 이번에 한 번 고민한 일을 다음 변경에서 처음부터 다시 고민하지 않도록.
아직 화면에서 느낀 어색함까지 전부 테스트로 옮기지는 못한다. 그 부분은 여전히 직접 보고 묻는다.
나는 누구인지 먼저 정하고 이런 판단을 하는 것이 아니었다.
무엇을 문제로 보고 어떤 정보를 중요하다고 여기며 어디까지 책임지는지를 통해 내가 어떤 사람인지 드러내고 있었다.
지금의 나는 그 일을 엔지니어링이라고 생각한다.