무슨 이야기냐면요
요즘 AI한테 '로그인 기능 만들어줘' 하면 코드를 뚝딱 만들어주죠. 테스트 코드까지 알아서 짜주고요. 그런데 한 개발자가 '유닛 테스트로는 안목(taste)을 검증할 수 없다'는 주제로 글을 썼는데, 많은 개발자들이 '맞아, 이거였어' 하고 고개를 끄덕이고 있어요.
먼저 유닛 테스트가 뭔지부터 짚고 갈게요. 유닛 테스트는 내가 짠 작은 코드 조각(함수)이 제대로 동작하는지 기계가 자동으로 확인해주는 검사 코드예요. 예를 들어 더하기(2, 3)을 실행했을 때 정말 5가 나오는지 컴퓨터가 대신 체크해주는 거죠. 이게 통과하면 '적어도 기능은 의도대로 돌아간다'는 안심을 얻을 수 있어요.
그런데 글쓴이가 던지는 질문이 날카로워요. '기능이 동작하는 것'과 '잘 만들어진 것'은 전혀 다른 문제 아니냐는 거죠.
안목이라는 게 뭐길래
여기서 말하는 안목(taste)은 추상적인 감성 얘기가 아니에요. 개발자가 매일 내리는 수많은 판단을 말해요. 예를 들면 이런 것들이죠.
- 이 함수 이름을
process()라고 할까,validateAndSave()라고 할까? - 이 로직을 한 군데 몰아넣을까, 여러 조각으로 나눌까?
- 에러가 났을 때 그냥 죽게 둘까, 친절한 메시지를 보여줄까?
- 지금 당장은 안 쓰지만, 6개월 뒤 후임이 봤을 때 이해할 수 있을까?
글쓴이의 핵심 주장은 이거예요. AI는 테스트를 통과하는 코드는 정말 잘 만들어요. 하지만 테스트가 검증해주지 못하는 영역, 즉 '왜 이렇게 짰는지', '이게 6개월 뒤에도 유지보수하기 좋은지', '팀의 다른 코드와 일관성이 있는지' 같은 부분은 결국 사람의 안목이 필요하다는 거죠.
왜 지금 이 이야기가 중요할까
이 글이 지금 와닿는 이유는 분명해요. AI 코딩 도구가 폭발적으로 늘면서 '이제 개발자 필요 없는 거 아니야?'라는 불안이 퍼지고 있잖아요. 실제로 AI는 보일러플레이트(매번 똑같이 반복되는 뻔한 코드)나 단순 CRUD 같은 건 사람보다 빠르게 만들어요.
하지만 현장에서 일해본 사람들은 알아요. 진짜 어려운 건 '코드를 짜는 것'이 아니라 '어떤 코드를 짜야 하는지 결정하는 것'이라는 걸요. 요구사항이 모호할 때 진짜 의도를 캐묻고, 여러 설계안 중 트레이드오프를 따져 고르고, 나중에 발목 잡힐 결정을 미리 피하는 것. 이게 안목이고, 이건 테스트 케이스로 환원되지 않아요.
비슷한 논의는 예전부터 있었어요. '코드 리뷰는 왜 자동화가 안 되나' 같은 이야기죠. 린터(코드 스타일을 자동으로 잡아주는 도구)나 정적 분석 도구가 아무리 발전해도 시니어 개발자의 리뷰를 완전히 대체하지 못하는 이유와 똑같아요. 규칙으로 만들 수 있는 건 기계가 잡지만, 맥락과 판단이 필요한 건 결국 사람 몫이거든요.
한국 개발자에게 주는 시사점
주니어라면 이 글에서 방향을 얻을 수 있어요. 'AI가 코드를 다 짜주는데 나는 뭘 공부하지?'라는 고민, 다들 한 번쯤 하잖아요. 답은 명확해요. 문법이나 API 외우기에만 매달리지 말고, '왜 이렇게 설계했는가'를 설명할 수 있는 안목을 길러야 해요. 좋은 코드와 나쁜 코드를 구별하는 눈, 그게 AI 시대의 차별화 포인트예요.
실무에서는 AI가 짠 코드를 그냥 받아들이지 말고, '이 이름이 적절한가', '이 구조가 6개월 뒤에도 괜찮을까'를 검토하는 습관을 들이는 게 좋아요. AI는 빠른 초안을 만드는 도구로 쓰고, 최종 판단은 사람이 내리는 거죠. 자연스럽게 코드 리뷰 문화가 더 중요해진다는 뜻이기도 하고요.
마무리
한 줄로 정리하면, AI는 '동작하는 코드'를 만들 수 있지만 '좋은 코드'를 판단하는 안목은 여전히 사람의 영역이라는 거예요. 테스트는 정답을 검증할 뿐, 좋은 질문을 던지지는 못하니까요.
여러분은 어떻게 생각하세요? AI가 짠 코드를 그대로 쓰는 편인가요, 아니면 꼭 다시 손보는 편인가요? '코드 보는 안목'은 어떻게 길러왔는지 경험담도 궁금해요.
🔗 출처: Hacker News