AI는 최신 트렌드를 잘 따라가고 있는가?

옛날이라고 하기에는 불과 몇 년 전까지만 해도, 사용 중인 기술이나 라이브러리의 최신 기능을 한 번씩 살펴보곤 했다. 그리고 회사에서도 서로간에 새로운 것들을 공유하고, 기술적으로 발전되는 부분들을 학습하고 프로젝트에 적용해 보며 코딩이라는 것을 했었다.

AI 의존도가 계속 높아지고 있는 지금은 AI에 대한 새로운 것들을 찾아보고, AI를 어떻게 활용할 수 있는지에 대한 관심이 대부분인 것 같다. 새로운 기술적인 부분들도 AI를 통한 작업 중 제안되는 사항들을 확인하고 적용하는 방식으로 진행하고 있다. 새로운 것들을 검토하고 프로젝트에 적용하는 것까지, 모든 것들이 AI로 쉽게 이루어지고 있다.

이전에는 새로운 것들을 직접 구현해 나가고, 문제를 해결하기 위해 생각하고 풀어나가는 과정 자체가 재미있었다. 지금은 예전과 같은 재미는 없지만, 빠르게 만들어지는 새로운 것들을 살펴보고 다시 내 것으로 만들기 위해 정리하고 학습하는 과정에 재미를 붙여 보려 하고 있다.

그러다 문득 AI는 최신 기술들을 잘 찾아서 프로젝트에 잘 적용하는지가 궁금했고, 이를 확인하기 위한 테스트를 진행해 보았다.

테스트 준비

테스트는 Claude Code로 진행했고, 같은 과제 5개를 조건만 바꿔 요청해 보았다.

조건을 정하며 참고한 글은 MDN의 Introducing the MDN MCP server였다. MDN에서는 AI가 최신 웹 기능을 정확하게 사용할 수 있도록, 문서와 브라우저 지원 데이터를 AI에게 직접 제공하는 MCP 서버를 공개했다. 그렇다면 AI에게 규칙을 알려주는 것과 최신 문서를 연결해 주는 것 중 어느 쪽이 더 효과가 있을지 궁금했다.

과제는 최근 표준이 되었거나, 아직 일부 브라우저만 지원하는 기능 위주로 골랐다.

그리고 최대한 같은 조건에서 비교하기 위해 몇 가지 원칙을 정했다.

• 프롬프트와 규칙에는 정답이 되는 API 이름을 넣지 않았다.
• 과제마다 새 세션을 열고, JS가 없는 같은 기본 페이지에서 시작했다.
• 2026년 10월, Claude Code(Claude Opus 5.5)로 조건마다 한 번씩 실행했다.
• 결과는 브라우저에서 직접 동작을 확인했고, Base64는 Hello, 안녕하세요, 😀, “따옴표”, café 5개의 입력으로 검증했다.

결과는?

결과부터 이야기하자면 20개 모두 동작은 정상적으로 했다. 차이는 어떤 방식을 선택했느냐에서 났다.

과제별 결과

아래 코드는 결과에서 핵심 줄만 간추린 것이다. 같은 방식을 쓴 조건은 A·C, B·D처럼 묶었다.

01 Base64

네 조건 모두 한글, 이모지, café까지 결과는 정확했다. café는 é가 btoa()에서 에러 없이 통과하지만 UTF-8 기준과 다른 값이 나오는 문자라 일부러 넣어 본 입력이다. unescape를 활용한 옛 우회 방법이나, 입력 문자열을 그대로 btoa()에 넘기는 코드는 없었다.

다만 표준 메서드인 toBase64()를 사용한 건 B와 D뿐이었고, A와 C는 바이트를 문자열로 바꿔 btoa에 넘기는 이전 방식을 사용했다. 결과는 같아도 방식은 한 세대 전에 머물러 있었다.

diff
  const bytes = new TextEncoder().encode(text);
- const base64 = btoa(String.fromCharCode(...bytes)); // A·C (실제로는 0x8000바이트씩 나눠 처리)
+ const base64 = bytes.toBase64();                    // B·D

- const decoded = Uint8Array.from(atob(base64), (c) => c.charCodeAt(0)); // A·C
+ const decoded = Uint8Array.fromBase64(base64);                         // B·D

검증에 사용한 다섯 입력은 각각 다음을 확인하기 위한 것이다.

• Hello: 1바이트 ASCII 문자만 있는 기준 입력이다. 어떤 방식이든 통과해야 한다.
• 안녕하세요: 한글은 UTF-8에서 한 글자가 3바이트다. 문자열을 그대로 btoa()에 넘기면 에러가 난다.
• 😀: UTF-8에서 4바이트이고, JS 문자열에서는 두 칸(서로게이트 쌍)을 차지한다. 글자 단위로 쪼개 처리하면 깨진다.
• “따옴표”: "처럼 보이지만 ASCII가 아닌 3바이트 문자다. 겉모양만 보고 ASCII로 취급하면 놓친다.
• café: é는 1바이트 범위 안이라 btoa()가 에러 없이 통과하지만, UTF-8과 다른 값이 나온다.

02 textarea

네 조건 모두 field-sizing: content를 사용했다. 그런데 A와 C는 JS 대체 코드를 함께 붙였고, A는 주석에 "Safari 등 미지원"이라고까지 적었다.

확인해 보니 Safari는 26.2부터 지원하고 있었고, 2026년 6월 Firefox 152를 끝으로 모든 주요 브라우저가 지원하는 Baseline이 된 상태였다. 이전의 지식이 그대로 코드에 남아 있었던 셈이다.

B는 CSS 2줄로 끝냈고, D는 네 조건 중 유일하게 최대 높이(max-height)까지 지정했다.

css
textarea {
  field-sizing: content;        /* 네 조건 공통 */
  min-height: calc(3lh + 18px); /* 최소 3줄 (B는 min-block-size) */
  max-height: 50vh;             /* D만 */
}
/* A·C는 여기에 scrollHeight로 높이를 맞추는 JS 대체 코드를 더 붙였다 */

03 모달 열기

프롬프트에 "JS는 최소한으로 써줘"를 덧붙인 과제다. 네 조건의 결과가 글자 하나까지 같았고, 모두 Invoker Commands로 JS 없이 처리했다.

html
<button commandfor="confirm-dialog" command="show-modal">삭제</button>
<dialog id="confirm-dialog">
  <button commandfor="confirm-dialog" command="close">취소</button>
</dialog>

04 모달 바깥 클릭

가장 큰 차이가 났던 과제다. A와 C는 클릭한 좌표가 모달 박스 밖인지 직접 계산하는 익숙한 방식을 사용했다.

js
// A·C
dialog.addEventListener('click', (event) => {
  if (event.target !== dialog) return;
  const rect = dialog.getBoundingClientRect();
  const isOutside =
    event.clientX < rect.left || event.clientX > rect.right ||
    event.clientY < rect.top || event.clientY > rect.bottom;
  if (isOutside) dialog.close();
});

재미있었던 건 A와 C 모두 바로 앞 과제(03)에서는 command / commandfor로 JS 없이 모달을 열었다는 점이다. 그런데 "JS는 최소한으로"라는 말이 빠지고 과제가 "바깥 클릭"으로 바뀌자 그마저도 사용하지 않고 addEventListener로 돌아갔다. 마치 질문의 모양에 따라 손에 익은 습관이 먼저 튀어나오는 것 같았다.

반면 B와 D는 속성 하나로 처리했고, 아직 Safari가 지원하지 않는다는 점까지 짚어 기능 감지 후 대체 코드를 붙였다.

html
<!-- B·D -->
<dialog id="confirm-dialog" closedby="any">

js
// closedby 미지원 브라우저(Safari)에서만 대체 코드 실행
if (!('closedBy' in HTMLDialogElement.prototype)) {
  // 바깥 클릭 처리
}

05 번역

네 조건 모두 Translator API를 사용했고, 기능 감지와 언어 조합 확인, 모델 다운로드 진행률 표시까지 공식 문서의 흐름을 그대로 따랐다. 처음에는 AI가 최신 기능들을 아예 모를 것이라 생각했는데, 생각보다 많이 알고 있었다.

js
if ('Translator' in self) {
  const translator = await Translator.create({ sourceLanguage: 'ko', targetLanguage: 'en' });
  output.textContent = await translator.translate(input.value);
}

AI는 찾아보았을까?

결과를 보고 나니 B와 D가 어떻게 최신 방식을 선택했는지 궁금해졌다. 그래서 Claude Code의 세션 기록에서 도구 호출 횟수를 세어 보았다.

C는 결과가 아무것도 설정하지 않은 A와 거의 같았는데, 기록을 보니 MDN MCP를 한 번도 호출하지 않았다. 사용할 수 있는 도구 목록에 이름만 올라가 있었을 뿐이다. MCP만 연결한 C의 결과는 실패였다.

더 흥미로웠던 건 B였다. B는 MDN MCP 없이 웹 검색을 했는데, 검색을 한 과제가 정확히 02와 04였다. 바로 A와 C가 예전 지식에 머물렀던 두 과제다. "확인하라"는 규칙을 받은 AI가 자기 지식이 불확실한 부분을 스스로 골라 확인한 것이 아닐까 하는 생각이 들었다.

D는 규칙대로 과제마다 MDN을 4~7번씩 조회했다. 덕분에 최대 높이 지정이나 더 구체적인 지원 버전처럼 세부적인 부분까지 가장 정확했지만, 확인이 필요 없던 03에서도 7번이나 조회했다.

규칙 3줄의 차이

정리해 보면 AI는 최신 기능을 몰랐던 것이 아니라, 확인하지 않았던 것에 가까운 것 같다. 03과 05는 모든 조건에서 정답을 맞혔고, B는 검색 없이도 toBase64()의 지원 버전까지 정확하게 적었다. 지식은 이미 가지고 있었지만, 익숙한 방식을 먼저 꺼내 들었던 것이다.

그리고 MCP를 연결하는 것만으로는 아무것도 바뀌지 않았고, 오히려 가장 효과가 컸던 건 규칙 3줄이었다. 프로젝트의 CLAUDE.md(Codex 등은 AGENTS.md)에 아래 내용을 추가하는 것만으로도 충분히 차이를 만들 수 있었다.

markdown
# 웹 프론트엔드 규칙
- JS나 라이브러리보다 HTML 속성, CSS 같은 웹 표준 기능을 먼저 검토한다.
- 모든 주요 브라우저가 지원하는(Baseline) 기능은 바로 쓰고, 아닌 기능은 지원 범위와 대체 방법을 함께 적는다.
- 코드를 쓰기 전에 사용할 API의 브라우저 지원 여부를 확인한다.

MDN MCP를 사용하고 있다면 "MDN MCP로 조회한 뒤 작성한다"는 한 줄을 더하면 된다. 다만 매번 조회하는 만큼 시간과 비용이 늘어나기 때문에, 필요한 곳만 확인하는 B와 매번 확인하는 D 중 프로젝트에 맞는 방식을 선택하면 좋을 것 같다.

물론 이번 테스트는 조건마다 한 번씩, 하나의 모델과 Claude Code로만 진행했기 때문에 정답이라고 보기는 어렵다. 같은 결과가 반복되는지는 조금 더 확인해 보아야겠다.

AI는 최신 트렌드를 잘 따라가고 있는가?

이전부터 AI의 결과물을 더 잘 생성하기 위한 여러 가지 방법이 소개되어 왔고, 나 역시 그런 방법들을 적용해 사용하고 있었다. 하지만 여러 방법을 직접 비교하며 결과를 확인해 본 것은 이번이 처음이었다. 큰 차이는 아니었지만, 생각보다 사용하는 방식에 따라 결과가 조금씩 달라진다는 것을 확인할 수 있었다.

앞으로는 AI를 사용하는 방식 역시 새로운 기술이나 라이브러리를 도입할 때 프로토타입을 만들고 여러 가지를 비교했던 것처럼, 직접 확인하고 검증하는 시간을 가져봐야겠다.

한편으로는 AI가 엄청나게 발전해 결과를 확인하고 검증하는 과정조차 무의미해지는 순간이 올지도 모른다는 생각이 든다. 그때가 온다면 또 다른 재미를 어디서 찾을 수 있을까? 걱정이 되기도 하고, 한편으로는 기대가 되기도 한다.

"Knowing is not enough; we must apply." - Johann Wolfgang von Goethe -