다시 아무도 모르는 시대
5장
요즘은 일을 시작하기 전에 해야 할 일이 많았다.
티켓을 확인하고, 요구사항을 읽고, 관련 문서를 찾고, 브랜치를 만들고, 작업 범위를 적었다.
코드를 다 만들고 나면 끝이 아니었다.
테스트를 하고, 커밋을 하고, 풀 리퀘스트를 만들고, 리뷰를 받고, 보안 점검을 확인하고, 배포 일정을 기다렸다.
예전 같으면 오전에 고치고 오후에 올렸을 법한 코드 한 줄도 이제는 여러 사람의 눈을 지나갔다.
좋아진 것이 많았다.
누가 언제 무엇을 바꿨는지 알 수 있었고, 문제가 생기면 이전 버전으로 돌아갈 수도 있었다.
예전처럼 누군가 운영 서버에 들어가 파일 하나를 몰래 덮어쓰고 아무도 모르는 일은 드물었다.
적어도 원칙상은 그랬다.
나는 오전 내내 티켓 하나를 보고 있었다.
내용은 짧았다.
특정 조건에서 주문 완료 후 포인트 적립이 누락됨.
재현 절차가 붙어 있었다.
테스트 계정도 있었고, 관련 화면 캡처도 있었고, 발생 시간도 적혀 있었다.
예전 같으면 부러울 만큼 친절한 자료였다.
그런데 한 시간이 지나도 원인은 보이지 않았다.
주문 서비스에서는 정상적으로 처리되고 있었다.
포인트 서비스 호출도 성공이었다.
로그에도 오류가 없었다.
나는 관련 코드를 따라갔다.
주문 완료.
이벤트 발행.
포인트 서비스 호출.
결과 저장.
모든 것이 정상처럼 보였다.
옆자리 젊은 개발자가 물었다.
“아직 보고 계세요?”
“응.”
“AI한테 물어봤어요?”
“벌써 물어봤지.”
“뭐래요?”
“코드만 보면 문제없대.”
그 친구가 웃었다.
“제일 무서운 답인데요.”
“그러게.”
나도 웃었다.
AI는 몇 가지 가능성을 알려줬다.
트랜잭션 문제.
비동기 처리 실패.
재시도 로직.
이벤트 유실.
캐시 불일치.
그럴듯했다.
그리고 다 아니었다.
나는 티켓을 다시 읽었다.
특정 조건.
그 말이 마음에 걸렸다.
“이 조건이 정확히 뭐지?”
젊은 개발자가 화면을 들여다봤다.
“쿠폰 사용 주문이요.”
“쿠폰이면 전부?”
“아니요. 특정 쿠폰이라고 되어 있는데요.”
나는 기획 문서를 찾았다.
링크가 있었다.
문서는 잘 정리돼 있었다.
제목.
변경 이력.
담당자.
관련 티켓.
문서를 읽다가 이상한 문장을 발견했다.
프로모션 쿠폰의 경우 적립 정책은 기존 정책을 따른다.
기존 정책.
나는 그 말을 한참 바라봤다.
개발하면서 가장 싫어하게 된 말 중 하나였다.
기존과 동일.
현행 유지.
기존 정책 적용.
그 안에 무엇이 들어 있는지 아무도 적어놓지 않는 말.
“기존 정책이 뭔데.”
내가 중얼거렸다.
AI에게 문서를 붙여 넣어도 알 수 없는 일이었다.
AI는 문서에 있는 것만 읽을 수 있었다.
문서에 없는 것은 나보다 더 몰랐다.
나는 오래된 티켓을 검색했다.
3년 전.
5년 전.
검색어를 바꿨다.
포인트.
쿠폰.
프로모션.
적립 제외.
한참 뒤 오래된 티켓 하나가 나왔다.
제휴 프로모션 쿠폰 사용 시 포인트 미적립 처리.
나는 내용을 열었다.
담당자는 이미 퇴사한 사람이었다.
댓글이 여러 개 달려 있었다.
맨 아래쪽에 짧은 문장이 있었다.
기획 협의 결과 일부 제휴 쿠폰에 대해서만 예외 적용. 추후 정책 정리 예정.
추후 정책은 정리되지 않은 모양이었다.
나는 쿠폰 코드를 확인했다.
문제가 발생한 쿠폰은 그때 만들어진 제휴 쿠폰 중 하나였다.
“찾았다.”
나도 모르게 말했다.
젊은 개발자가 의자를 밀고 다가왔다.
“뭔데요?”
“버그가 아니네.”
“네?”
“원래 적립 안 되는 쿠폰이야.”
“근데 왜 티켓이 버그로 들어왔어요?”
“지금 기획 쪽에서 이 정책을 모르는 거겠지.”
그 친구는 잠시 화면을 보더니 말했다.
“그럼 문서가 잘못된 거네요.”
“문서가 없는 거지.”
“이런 걸 어떻게 찾아요?”
나는 대답하려다가 멈췄다.
어떻게 찾았지.
특별한 방법이 있었던 건 아니었다.
그저 예전에도 이런 일이 많았다는 걸 알고 있었다.
코드가 맞는데 결과가 이상하면 코드 밖을 봐야 한다는 것.
그리고 ‘기존 정책’이라는 말 뒤에는 대개 설명하지 않은 무언가가 있다는 것.
“오래 하면 알게 돼.”
말하고 나니 내가 싫어하던 선배들 말투 같았다.
젊은 개발자가 웃었다.
“제일 도움 안 되는 답인데요.”
“그렇지.”
나도 웃었다.
티켓에 조사 결과를 적었다.
관련 과거 티켓을 링크하고, 현재 정책과 문서 내용이 다르다고 남겼다.
담당 기획자를 태그했다.
잠시 뒤 답이 왔다.
확인해보겠습니다.
그리고 한 시간쯤 지나 다시 댓글이 달렸다.
기존 예외 정책이 현재에도 유효한 것으로 확인했습니다. 버그가 아닌 것으로 종료합니다.
나는 티켓 상태를 닫았다.
코드는 한 줄도 바꾸지 않았다.
오전이 다 갔다.
예전 같았으면 이런 날은 일을 안 한 것 같은 기분이 들었다.
지금은 아니었다.
아무것도 바꾸지 않는 것도 개발자의 일이 될 수 있다는 걸 오래전에 배웠다.
잘못 고치는 것보다 안 고치는 편이 나은 경우가 많았다.
오후에는 다른 작업의 코드 리뷰가 있었다.
젊은 개발자가 만든 코드였다.
AI를 사용한 흔적이 보였다.
코드는 깔끔했다.
메서드 이름도 좋았고, 예외 처리도 되어 있었고, 테스트 코드도 있었다.
예전 신입 개발자가 만든 코드와는 달랐다.
신입이 처음부터 이런 코드를 만든다는 게 아직도 조금 이상했다.
나는 코드를 읽다가 한 부분에서 멈췄다.
외부 API 호출이 실패하면 세 번 재시도하도록 되어 있었다.
코드만 보면 합리적이었다.
나는 댓글을 달았다.
이 API는 결제 승인 API라 자동 재시도하면 중복 승인 가능성 확인 필요합니다.
몇 분 뒤 답이 왔다.
AI가 네트워크 오류 대응으로 retry 넣는 게 좋다고 해서 추가했습니다. 확인해보겠습니다.
나는 모니터를 한동안 바라봤다.
틀린 말은 아니었다.
네트워크 오류에는 재시도가 흔한 방법이었다.
다만 모든 호출을 다시 해도 되는 것은 아니었다.
그걸 AI가 모른다고 탓하기도 어려웠다.
우리가 알려주지 않았으니까.
조금 뒤 젊은 개발자가 내 자리로 왔다.
“선배님, 이건 재시도 빼는 게 맞겠네요.”
“응. 아니면 조회 API로 승인 여부 확인한 다음에 해야지.”
“근데 이런 건 문서에 없어요?”
“있을 수도 있고.”
“어디요?”
“나도 찾아봐야 돼.”
그 친구가 웃었다.
“결국 또 찾는 거네요.”
“그러게.”
예전에는 자료가 없어서 찾았다.
지금은 자료가 너무 많아서 찾았다.
문서는 위키에 있었고, 티켓은 몇 년치가 쌓여 있었고, 코드는 수십 개 저장소로 나뉘어 있었다.
회의 기록도 있었고, 메신저 기록도 있었고, 설계 문서도 있었다.
없는 것보다 나았다.
분명히 나았다.
그런데 필요한 답이 어디에 있는지는 여전히 모를 때가 많았다.
오후 회의에서는 새로운 개발 프로세스에 대한 이야기가 나왔다.
담당자가 화면을 공유하며 설명했다.
“앞으로는 개발 시작 전에 기술 검토 문서를 먼저 작성해주시고요. 영향도 분석하고 테스트 시나리오까지 포함해주시면 됩니다.”
누군가 물었다.
“간단한 수정도요?”
“원칙적으로는 그렇습니다.”
“문구 하나 바꾸는 것도요?”
회의실에서 웃음이 났다.
담당자도 웃었다.
“그건 상황 봐서 하시죠.”
나는 그 말을 듣고 웃었다.
결국 상황을 봐야 했다.
규칙은 늘어났고, 절차는 세밀해졌고, 도구는 훨씬 좋아졌다.
그런데 마지막에는 항상 비슷한 말이 나왔다.
상황을 봐서.
영향이 없으면.
필요한 경우.
적절하게.
그 말을 판단하는 건 결국 사람이었다.
퇴근 무렵 팀장이 메시지를 보냈다.
오늘 포인트 건 처리됐나요?
나는 답했다.
버그가 아니라 기존 예외 정책이었습니다. 티켓에 내용 남겼습니다.
잠시 뒤 답이 왔다.
역시 이런 건 선배님이 잘 찾으시네요.
칭찬이었다.
나는 ^^ 하나를 보냈다.
그리고 잠깐 화면을 바라봤다.
새로운 시스템을 만드는 일보다, 오래된 시스템이 왜 그렇게 되어 있는지를 알아내는 일을 잘한다.
그게 칭찬인지 아닌지 가끔 헷갈렸다.
노트북을 닫으려다 AI 창이 눈에 들어왔다.
아침에 내가 붙여놓은 로그와 질문들이 그대로 남아 있었다.
가능성 다섯 가지.
모두 그럴듯했고, 모두 틀렸다.
나는 장난삼아 마지막 질문을 하나 입력했다.
코드에는 문제가 없는데 결과가 이상하다면 뭘 확인해야 해?
답이 길게 나왔다.
데이터.
설정.
외부 시스템.
캐시.
배포 환경.
업무 규칙.
마지막에 한 줄이 붙었다.
특히 문서화되지 않은 비즈니스 규칙이나 레거시 예외 조건이 있는지 확인하는 것이 중요합니다.
나는 그 문장을 읽다가 웃었다.
“이제 너도 아네.”
