새로운 모델이 나올 때마다 우리가 도대체 무엇에 환호하는 것인가

본문보다는 제목에 더 공감해서 답글 남김. 나는 개발자가 아니라 CFO임.

2월에 Claude Cowork에 손익계산서 50개를 넣고 분석을 요청했더니, 우리 중기 계획을 분석한 아주 인상적인 8페이지짜리 워드 문서를 만들어줬음. 정말 환상적이었음.

하지만 엑셀로 비교나 분석을 요청했을 때는 내가 직접 하는 것만큼 잘하지 못했음. 어제는 총 79개의 손익계산서를 Claude Cowork에 넣고 비교를 요청했더니, 5분 만에 내가 원했던 모든 논리적 비교 항목이 포함된 15개 탭짜리 엑셀 통합 문서를 만들어줬음. 내가 직접 했으면 4~5시간은 걸렸을 텐데 5분 만에 끝난 거임.

6개월 전 구버전 Claude는 이게 불가능했다고 생각함. 그래서 내 생각에 새로운 릴리즈는 확실히 실질적인 점진적 개선을 가져오고 있음. 프론티어 모델이 나올 때마다 향상된 능력을 확실히 체감함.

이 모델들을 코드 작성에만 쓰고 있는 거임? 배포, SRE, 모니터링, 성능 튜닝이나 PDLC의 다른 부분에는 아무도 안 쓰는 거임? 이 모델들은 이제 소프트웨어 엔지니어링 라이프사이클 전반을 훨씬 더 잘 이해하고 있음.

리뷰와 머지 단계에서 병목 문제가 있는 건 맞지만, 감당 못 할 수준은 아님. 모든 PR 리뷰가 정밀 조사를 필요로 하는 건 아님.

진짜 문제는 다운스트림에서 버그가 계속 발생한다면 문서화가 부족하다는 거임. 가장 잘 아는 사람들에게 모든 걸 문서로 정리하게 하고, LLM이 기능을 구현할 때 컨텍스트로 참조하게 하셈.

솔직히 말하자면, 우리는 원래 제약 사항이 아니었던 부분에 환호하고 있는 거임. 예전에는 코드 작성이 업무의 5분의 1 정도였는데, 그걸 10배 빠르게 만든다고 해서 전체 시스템이 조금 빨라질 뿐, 오히려 속도가 안 나는 리뷰, 테스트, '이게 꼭 필요한가'라는 논의 단계에 과부하가 걸림. 아무도 좋아하지 않겠지만, 생성 속도가 빨라진 만큼 더 작은 단위의 변경에 집중해야 함. 30분 만에 만든 기능은 인간이 리뷰할 때 머릿속에 담을 수 있는 수준일 때만 가치가 있음. 팀들이 리뷰 역량을 예산처럼 관리하지 않는 한, 모든 릴리즈는 그저 물 높이만 높일 뿐임.

소위 말하는 '잉여 인력'인 프로덕트 오너로서 웃음밖에 안 나옴. 내 역할이 해야 할 모든 일은 그저 코드를 찍어내는 데 방해물로 취급받았음. 이제 코드가 너무 빨리 나오니까 사람들이 만들어진 결과물을 검증할 방법을 찾고 싶어 하는 거임.

이래서 명확하고 측정 가능한 수용 기준(AC)을 만드는 게 중요함. 왜 그 AC가 로드맵의 장기 목표로 이어져야 하는지, 왜 AC가 새로운 기능뿐만 아니라 변경해서는 안 될 부분까지 다뤄야 하는지 말임.

더 중요한 건 이 모든 것 뒤에 있는 인간적인 연결임. 해결하려는 문제가 무엇인가? 우리 모두가 그게 문제라는 데 동의하는가? 문제와 해결책의 영향을 어떻게 측정할 것인가? 누군가 기존 도구 대신 이 해결책을 실제로 사용할 것인가?

나는 AI에 꽤 찬성하는 편이지만, 현대 소프트웨어 개발이라는 모닥불에 기름을 붓고 있다고 봄. 나쁜 습관들은 가속화되고 있고, 경영진은 가속 페달을 점점 더 세게 밟고 있음.

8000줄짜리 리뷰 문제는 진짜 심각함. 어떤 사람이 '작은 리팩토링'이라며 40개 파일을 건드렸는데, 스테이징 환경이 죽을 때까지 아무도 눈치채지 못한 통합 오류를 2개나 냈음.

병목 현상이 타이핑에서 판단력으로 옮겨갔는데, 판단력은 모델 릴리즈와 함께 확장되지 않음. 새로운 모델이 나올 때마다 그럴듯해 보이는 코드 더미만 커질 뿐임.

나를 미치게 하는 건 리뷰 피로도임. 하루에 세 번째 AI PR을 보고 나면, 사람들은 8000줄의 컨텍스트를 머릿속에 담을 수 없어서 그냥 승인 버튼을 누르기 시작함. 그러고 나면 버그의 원인은 'AI가 쓴 거니까'가 되고 아무도 책임지지 않음.

우리는 AI PR을 올릴 때 인간이 쓰는 것처럼 설계 문서를 먼저 작성해야 한다는 규칙을 추가했음. 속도는 느려졌지만, 적어도 채팅창에 문단 하나 입력해서 만들어진 기능들을 무작정 머지하는 짓은 멈췄음.