무슨 이야기인가요
개발자 마이클 힙이 블로그에 'I don't want the details', 그러니까 '세부사항은 원하지 않아요'라는 제목의 글을 올렸어요. 제목만 보면 좀 무례하게 들리죠. 그런데 내용을 따라가 보면 요즘 개발자라면 한 번쯤 느꼈을 감정을 솔직하게 꺼낸 글이에요. 누가 나에게 뭔가를 전달할 때, 그게 동료의 작업 보고든 AI 코딩 도구가 쏟아내는 설명이든, 나는 그 일이 어떤 경로로 진행됐는지를 듣고 싶은 게 아니라는 거예요. 결과가 뭔지, 내가 뭘 결정하면 되는지, 위험한 건 없는지. 그것만 알면 된다는 거죠.
이 이야기가 왜 지금 나오냐면요, AI 에이전트가 코드를 대신 짜주는 시대가 되면서 '세부사항'의 양이 폭발했기 때문이에요. 예전에는 동료 한 명이 하루에 만들어내는 변경이 PR 한두 개였다면, 지금은 에이전트가 몇 시간 만에 파일 수십 개를 고치고 그 과정을 장황하게 설명해요. 그걸 다 읽는 게 맞을까요? 글쓴이의 답은 '아니오'에 가까워요. 컴파일러가 어셈블리를 어떻게 만드는지 안 보고 사는 것처럼, 어느 정도 신뢰가 쌓인 도구나 동료의 과정은 안 봐도 된다는 거예요.
이게 뭐냐면: 추상화 계층과 신뢰의 경계
여기서 핵심 개념은 추상화예요. 프로그래밍에서 추상화는 '안이 어떻게 돌아가는지 몰라도 쓸 수 있게 감싸는 것'이에요. 여러분이 HTTP 요청을 보낼 때 TCP 패킷이 어떻게 쪼개지는지 생각 안 하잖아요. 그건 무지가 아니라 잘 만들어진 경계 덕분이에요. 글쓴이의 주장은 사람 사이의 협업과 AI와의 협업에도 같은 경계를 만들자는 거예요. 경계 안쪽은 맡기고, 경계에서 오가는 건 '결과, 위험, 요청'이라는 세 가지로 압축하자는 거죠.
이걸 실제 상황으로 풀어볼게요. 장애가 났을 때 팀장에게 보고한다고 해봐요. 나쁜 보고는 이렇게 시작해요. '어제 배포하고 나서 로그를 보니까 이상한 게 있어서 확인해봤는데요, 처음엔 캐시 문제인 줄 알았는데...' 듣는 사람은 결론이 언제 나오나 조마조마하죠. 좋은 보고는 거꾸로예요. '결제 실패율이 올라갔고, 원인은 파악됐고, 롤백하면 10분 안에 정상화돼요. 롤백 승인해주세요.' 그리고 궁금하면 그때 세부사항을 물어보게 두는 거예요. 이걸 두괄식이라고 하는데, 글쓴이가 말하는 '세부사항은 원하지 않는다'는 결국 '세부사항을 없애라'가 아니라 '세부사항을 뒤로 보내고, 필요한 사람이 꺼내 보게 하라'는 뜻이에요.
AI 도구에 적용하면 이렇게 돼요. 에이전트가 작업을 끝냈을 때 나에게 필요한 건 '뭘 바꿨고, 테스트는 통과했고, 이 부분은 확신이 없으니 봐달라'는 세 줄이에요. 어떤 파일을 열어봤고 어떤 시도가 실패했는지는 로그에 남겨두면 되고요. 실제로 요즘 코딩 에이전트들이 작업 요약을 먼저 보여주고 상세 로그는 접어두는 방향으로 UI를 바꾸는 것도 같은 맥락이에요.
반대 의견도 만만치 않아요
그런데 이 주장에 불편함을 느끼는 개발자도 많을 거예요. 이유가 타당하거든요.
첫째, 세부사항을 안 보면 배우지 못해요. 주니어가 AI가 짠 코드를 결과만 보고 넘기면, 몇 년 뒤에 그 코드가 왜 그렇게 생겼는지 아무도 모르는 팀이 돼요. 컴파일러를 신뢰하는 건 수십 년 검증됐기 때문이지, AI 에이전트는 아직 그 수준의 신뢰를 쌓지 못했어요.
둘째, 문제는 항상 세부사항에서 터져요. '테스트 통과했어요'라는 결과는 테스트가 뭘 검증하는지 모르면 의미가 없어요. 결과만 받는 사람은 결국 그 결과가 틀렸을 때 책임질 능력도 잃게 돼요.
셋째, 결과만 원하는 문화는 위로 갈수록 위험해요. 관리자가 세부사항을 거부하면 현장에서 나쁜 소식이 올라오지 않게 돼요. 한국 조직에서 특히 익숙한 장면이죠.
그래서 균형점은 아마 이쯤일 거예요. 결과를 앞에 두되 세부사항은 언제든 꺼내볼 수 있게 남겨두고, 신뢰가 쌓이지 않은 대상에게는 세부사항을 더 자주 열어본다. 신뢰는 '안 봐도 되는 권리'가 아니라 '봤더니 계속 괜찮아서 덜 보게 된 상태'라는 거죠.
한국 개발자에게 주는 시사점
당장 써먹을 수 있는 게 몇 가지 있어요. PR 설명을 쓸 때 첫 세 줄에 '무엇을, 왜, 리뷰어가 특히 봐야 할 곳'을 넣어보세요. 리뷰 속도가 달라져요. 슬랙으로 보고할 때도 결론과 요청을 먼저 쓰고 상세는 스레드에 다는 습관이 좋아요. AI 에이전트를 쓸 때는 반대로 하세요. 처음 몇 주는 세부사항을 일부러 다 읽으면서 어디서 자주 틀리는지 파악하고, 그다음에 어디까지 안 봐도 되는지 스스로 경계를 정하는 거예요. 그리고 팀장이라면 '세부사항은 필요 없다'는 말을 조심해서 써야 해요. 그 말이 '나쁜 소식은 가져오지 마'로 들릴 수 있거든요.
정리
한 줄로 정리하면, 세부사항을 원하지 않는다는 건 게으름이 아니라 신뢰의 경계를 어디에 그을지에 대한 질문이고, 그 경계는 상대와 상황마다 달라야 한다는 거예요.
여러분은 AI가 짠 코드의 과정을 어디까지 읽고 계세요? 그리고 팀에서 보고받을 때 결론부터 듣고 싶은 쪽인가요, 아니면 과정을 같이 듣고 싶은 쪽인가요?
🔗 출처: Hacker News