오늘 팀 전체에 메시지를 하나 보냈다.
AI 쓰지 말라는 얘기는 아니다. 나도 매일 쓴다. 다만 요즘 기획이든 개발이든, AI가 만들어준 걸 그대로 올리는 경우가 자주 보였다. 스펙으로, 티켓으로, 코드로. 읽어보면 말이 되게 생겼는데 왜 그렇게 했냐고 물으면 답이 안 나온다.
그래서 이렇게 썼다. 각 줄이 왜 거기 있는지 설명 못 하면 아직 네 것이 아니라고.
보내고 나서 이게 정확히 무슨 문제인지 좀 더 생각해봤다.
문제는 틀린 게 아니다
AI가 틀린 걸 말하는 건 사실 큰 문제가 아니다. 틀린 건 검증하면 걸러진다. 원래 사람도 틀린다.
진짜 문제는 틀렸다는 신호가 같이 사라졌다는 거다.
사람이랑 일할 때 우리는 내용만 보는 게 아니다. 주니어가 확신 없는 얘기를 하면 말끝이 흐려진다. 누가 자기 영역 밖의 얘기를 하면 어조가 조심스러워진다. “아마도”, “확인은 안 해봤는데” 같은 게 붙는다. 그걸 듣고 우리는 무의식적으로 검증 강도를 조절한다. 이건 배운 게 아니라 그냥 몸에 있는 거다.
AI는 그게 없다. 확실히 아는 것과 그냥 맞춰본 것을 완전히 같은 톤으로 말한다. 우리 정산 규칙을 모르는데도 모른다고 말하지 않고, 있을 법한 걸 채워서 내놓는다. 문장의 자신감은 내용의 정확도랑 아무 상관이 없다.
그러니까 우리가 평생 써온 오류 감지 장치가 통째로 무력해진 상태에서 읽게 되는 거다. 그리고 대부분은 그 장치가 꺼졌다는 것도 모른 채로 읽는다.
그럴싸한 게 맞는 것보다 위험한 이유가 여기 있다. 틀린 건 눈에 걸리는데 그럴싸한 건 안 걸린다.
안목이라는 게 결국 뭔가
이 얘기를 하다 보니 내가 요즘 계속 다시 돌아오는 질문이 하나 있다. 판단을 잘한다는 게 뭔가. 정답을 많이 아는 건가.
아닌 것 같다. 정답을 많이 아는 건 이제 나보다 AI가 낫다. 내가 정산 로직의 예외 케이스를 다 기억하는 것보다, AI한테 물어보는 게 커버리지는 더 넓을 거다.
내가 아직 나은 부분은 다른 데 있다. 지금 나온 답이 그럴싸한지 맞는지를 가르는 것. 그리고 여러 개가 다 말이 되게 보일 때, 지금 이 상황에서 뭐가 제일 나은지를 고르는 것.
둘은 비슷해 보이는데 다른 능력이다. 앞엣건 걸러내는 눈이고, 뒤엣건 최적화하는 눈이다. 앞엣건 “이게 맞나”를 묻고, 뒤엣건 “이게 지금 여기서 제일 나은가”를 묻는다.
AI가 잘하는 건 후자처럼 보이는 걸 계속 만들어내는 거다. 문법적으로 맞고, 논리적으로 이어지고, 그럴싸한 후보를 빠르게 여러 개 뽑아준다. 근데 그 후보들 중에 지금 우리 팀 상황, 지금 이 정산 데이터의 특성, 지금 이 사용자층한테 뭐가 맞는지는 AI가 판단하는 영역이 아니다. 그건 맥락을 실제로 몸으로 겪어본 사람만 할 수 있는 일이다.
그러니까 요즘 나한테 안목이라는 단어는 정답을 아는 것과는 거리가 멀어졌다. 그럴싸한 것들을 늘어놓고 그중에 지금 여기에 맞는 걸 골라내는 능력, 그리고 그 판단 근거를 설명할 수 있는 능력. 이 둘이 안목이다.
내가 팀원들한테 요구한 것도 결국 이거였다. 왜 그렇게 했냐고 물었을 때 답을 한다는 건, AI가 준 여러 후보 중에 이걸 고른 이유를 자기가 갖고 있다는 뜻이다. 이유가 없으면 그건 고른 게 아니라 그냥 받은 거다.
근데 나도 똑같은 걸 했다
메시지를 다시 읽어보니 하나 걸리는 게 있다.
나는 기준을 던졌다. 설명할 수 없으면 아직 네 것이 아니다. 좋은 문장이라고 생각한다.
근데 그걸 어떻게 지킬지는 안 만들었다. “스스로 물어봐라”고 썼는데, 스스로 묻는 건 마감이 다가오면 제일 먼저 버려지는 종류의 일이다. 여유 있을 때만 작동하는 규칙은 사실 규칙이 아니다.
여기서 좀 웃긴 게, 이 메시지 자체도 나한테는 그럴싸한 답이었다는 거다. “설명할 수 없으면 네 것이 아니다”는 문장은 옳게 들리고, 논리도 맞고, 보낸 순간에는 뭔가 해결한 기분이 든다. 근데 이게 지금 우리 팀 상황에 맞는 답인지는 따로 물어본 적이 없다. 다들 마감에 쫓기고, 오프쇼어 팀이라 시차 때문에 리뷰 사이클도 느리고, 이 상황에서 “각자 스스로 검증해라”는 최적화된 해법이 아니라 그냥 내가 떠올리기 쉬운 해법이었다.
지난번에 리소스 때문에 미뤘다고 정리했던 게 사실은 설득이 피곤해서였다는 걸 쓴 적이 있는데, 이것도 비슷한 자리인 것 같다. 기준을 공지하는 건 쉽고 절차를 바꾸는 건 피곤하다. 나는 그럴싸하고 쉬운 쪽을 골랐고, 그게 지금 이 팀에 최적화된 답인지는 확인 안 하고 넘어갔다.
내가 팀원들한테 요구한 거랑 똑같은 실패다. 왜 이 방법을 골랐냐고 나한테 물으면, 사실 답이 궁색하다.
그래서 뭘 바꿔야 하나
실제로 작동하게 하려면 개인의 성실함이 아니라 팀의 기본 동작으로 옮겨야 한다. 리뷰할 때 “이 줄 왜 이렇게 했어요”를 묻는 게 트집이 아니라 그냥 정상 절차가 되는 것. 그러면 설명할 수 있는 상태로 가져오는 게 각자의 다짐이 아니라 기본값이 된다.
이건 아직 안 했다. 메시지 보낸 걸로 뭔가 한 것 같은 기분이 들었는데, 생각해보면 아무것도 안 바뀌었다.
그리고 이번엔 나부터 같은 질문을 스스로한테 해봐야 할 것 같다. 리뷰 절차를 리뷰 타이밍에 넣는 것, 시차 있는 오프쇼어 팀 구조에 맞게 비동기로 돌아가게 만드는 것, 이런 여러 개의 그럴싸한 방법 중에 지금 우리 팀 규모와 운영 방식에 뭐가 실제로 맞는지. 이건 아직 안 골랐다.
한 가지 모르겠는 것
그 기준을 어디까지 적용할지도 아직 못 정했다.
정산 로직이나 GPS 처리처럼 틀리면 돈이나 신뢰가 걸리는 데는 당연히 전부 설명 가능해야 한다. 근데 설정 파일이나 반복되는 형식 코드까지 한 줄 한 줄 이해하고 넘어가라고 하면, 그건 AI를 쓰기 전보다 더 느려지는 거다. 그러면 안 쓰느니만 못하다.
선이 있을 텐데 그걸 규칙으로 쓸 수 있을 만큼 정리하지는 못했다. 지금은 “틀렸을 때 되돌리는 비용이 큰 곳”이라고밖에 못 말하겠는데, 이건 판단하는 사람이 이미 경험이 있어야 쓸 수 있는 기준이다. 경험 없는 사람한테는 도움이 안 된다.
결국 이것도 같은 문제다. 되돌리는 비용이 크다, 작다 사이에 여러 그럴싸한 기준선이 있을 거고, 그중 뭐가 지금 우리 팀한테 맞는 선인지는 나도 아직 모른다. 한동안은 내가 리뷰에서 직접 물어보는 걸로 채워야 할 것 같다. 몇 번 하다 보면 어디가 선인지, 그리고 그 선이 지금 우리한테 왜 맞는지도 좀 더 말할 수 있게 될 것 같다.
지금은 여기까지다.