변경된 코드가 짧으면 검토도 짧아질 것 같다. 이름을 고친 것인지, 계산을 바꾼 것인지 읽고 나면 얼추 감이 온다. 그런데 작은 공용 함수 하나는 화면 여러 곳에서 쓰일 수 있다. 변경한 줄만 따라가다 보면 그 함수를 사용하는 사람은 시야 밖에 남는다. 검토의 출발점을 코드의 길이에만 두기 어려운 이유다.
Farol의 공개 문서는 변경이 어떤 진입점으로 이어지는지, 검사 자료가 어디까지 있는지 보여주는 도구를 소개한다. 정적 분석의 한계와 점수의 경험적 성격도 함께 적혀 있다. 이 글에서는 도구의 효과를 검증하거나 설치를 권하려는 대신, 그 질문을 수작업으로 작게 옮겨보려 한다. 예시는 실제 서비스가 아닌 가상의 일정 앱이다.
고친 줄에서 사용자의 행동까지
이 앱에는 날짜를 문자열로 바꾸는 공용 함수가 있다. 이번 변경은 날짜 뒤에 붙던 공백을 없애는 것이다. 화면에서 보기에는 사소하지만, 함수의 결과를 쓰는 곳이 일정 목록, CSV 내보내기, 알림 내용이라면 확인할 길은 셋이다. 세 화면이 모두 같은 방식으로 결과를 소비한다는 보장도 없다.
종이에 변경 파일 하나를 적고, 오른쪽에 그 파일을 직접 사용하는 곳을 붙여보자. 다시 그 오른쪽에는 사용자가 시작하는 행동을 적는다. 날짜 함수에서 내보내기 모듈을 거쳐 다운로드 버튼으로 이어지는 식이다. 완벽한 그림을 그리려는 것은 아니다. 어떤 길을 이미 찾았고 어떤 길은 아직 모르는지 드러내는 정도면 시작할 수 있다.
이제 각 길 옆에 질문을 하나씩 붙인다. 목록에서는 줄바꿈과 정렬이 같은가. CSV에서는 값이 예상한 칸에 들어가는가. 알림에서는 다른 문장과 붙어 읽히지 않는가. 질문은 수정한 코드의 모양보다 실제로 잃을 수 있는 동작에 가까워야 한다. 같은 함수를 쓴다고 똑같은 확인을 복사해 붙이는 순간, 길을 그린 이유가 사라진다.
여기서 중요한 빈칸은 검사하지 않은 부분이다. 내보내기 화면을 열어보지 않았다면 그 칸에는 미확인이라고 적는다. 관련 검사가 통과했어도 검사에 들어간 입력이 무엇인지 모르면 범위를 확인해야 한다. 초록색 결과 하나가 모든 사용자 행동을 대신 설명해 주지는 않는다. 범위가 좁은 확인도 어디까지인지 적혀 있으면 다음 사람이 이어받을 수 있다.
모르는 길을 지우지 않기
연결 관계를 찾다 보면 확실하지 않은 호출도 나온다. 실행 중에 선택되는 모듈이나 외부 설정으로 바뀌는 경로가 있을 수 있다. 정적으로 보이지 않는다는 이유로 영향이 없다고 결론 내리면 편하지만, 그 편안함은 근거가 없다. 이 경우에는 알 수 없는 경로라는 표시와 확인 방법을 함께 남기는 편이 낫다.
예를 들어 알림 문구를 만드는 방식이 고객별 설정에 따라 달라진다고 하자. 현재 확인한 설정은 기본값뿐이다. 그러면 검토 기록에는 기본 설정에서의 문구와, 추가 설정은 아직 확인하지 않았다는 사실이 나란히 있어야 한다. 알림 전송 권한이 없다면 실제 발송을 시도하는 대신 미리보기나 승인된 테스트 환경에서 확인할 범위를 정하면 된다.
점수를 쓴다면 그 숫자를 확인 순서에 활용할 수는 있다. 다만 어떤 도구가 내놓은 숫자를 우리 서비스의 실제 장애 확률로 읽으려면 별도의 검증이 필요하다. 공용 파일을 건드렸고 확인 자료가 적다는 사실만으로도 자세히 볼 이유는 충분하다. 정확해 보이는 숫자가 있어야만 주의를 기울일 수 있는 것은 아니다.
반대의 경우도 있다. 파일을 여러 개 고쳤지만 서로 독립적인 안내 문구만 바뀌었다면 영향은 제한적일 수 있다. 변경 줄 수가 많다는 이유로 무조건 큰 검토를 하고, 적다는 이유로 가볍게 끝내는 방식은 둘 다 아쉽다. 사용자가 통과하는 경로와 실패했을 때의 결과를 기준으로 검토 시간을 나누는 편이 설명하기 쉽다.
다음 검토자가 이어갈 수 있는 기록
가상의 날짜 변경을 검토했다면 마지막 기록은 길 필요가 없다. 목록과 내보내기는 같은 입력으로 확인했다. 알림은 기본 설정의 미리보기만 확인했다. 고객별 설정은 담당자가 추가로 본다. 이렇게 확인한 행동, 남은 범위, 다음 담당이 보이면 된다. 코드를 읽었다는 말과 실제 화면을 확인했다는 말도 구분해서 적는다.
검토 도중 수정이 한 번 더 들어오면 이 기록을 모두 새로 쓸 필요는 없다. 추가 변경이 앞서 그린 길 어디에 닿는지 먼저 본다. 닿는 길의 확인을 다시 하고, 닿지 않는다는 판단의 근거를 남긴다. 다만 공용 설정처럼 여러 경로의 전제를 바꾸는 변경이라면 좁게 잡았던 범위를 다시 넓혀야 한다. 지난번에 확인했다는 사실만으로 이번 입력이 안전해지는 것은 아니다.
실제로 이 방식을 써본 결과를 여기서 주장할 수는 없다. 대신 검토 기록을 읽는 사람이 짧은 시간 안에 무엇을 알 수 있어야 하는지는 정할 수 있다. 무엇이 달라졌는지, 누가 영향을 받는지, 무엇을 확인했고 무엇을 모르는지다. 이 네 질문이 문장으로 남으면 특정 도구가 없어도 검토의 뼈대는 생긴다.
코드가 적게 바뀐 날에도 사용자의 행동은 여러 갈래로 이어진다. 매번 전체 서비스를 다시 볼 수 없다면, 그 갈래를 더 잘 고르는 일이 필요하다. 다음에 작은 수정 하나를 검토할 때에는 바뀐 줄 아래에 사용자 행동을 하나만 더 적어보면 좋겠다. 그 한 줄이 검토의 길이를 늘리기보다, 어디에 시간을 써야 하는지 알려줄 수도 있다.
관련 글은 Software Engineering에서 이어 읽을 수 있습니다.
공개 원문을 참고해 AI의 도움으로 구성·작성한 글입니다. 본문의 가상 예시는 실제 수행 결과와 구분했으며, 표지는 Google Gemini로 만든 개념 일러스트입니다.
