AI가 코드를 더 많이 만들수록 ‘덜 만드는 판단’이 중요해지는 이유

2026. 7. 7 · 약 12분 · 뉴스에서 내 일로

AI가 코드를 더 많이 만들수록 ‘덜 만드는 판단’이 중요해지는 이유

AI에게 기능 하나를 더 만들어 달라고 말하는 일은 쉬워졌다. 어려운 일은 그 기능이 정말 필요한지, 매일 쓰는 사람을 방해하지 않는지 판단하는 것이다. Jetendard 폰트의 작은 조정부터 제품 애니메이션, AI 시대 개발자의 역할까지 읽어보니 세 소식은 모두 추가보다 맥락이 먼저라는 결론으로 이어졌다.

먼저 보는 결론

• Jetendard는 새 기능이 아니라 한글과 영문의 어긋남이라는 오래된 마찰을 줄였다.
• AI가 추가 비용을 낮춰도 사용자의 시간과 인지 비용은 사라지지 않는다.
• 개발자의 희소한 역할은 코드 생산보다 문제 정의·맥락 보존·검증으로 이동한다.

왜 함께 읽었나

폰트의 자간, 메뉴 애니메이션 300ms, AI가 남긴 코드의 변경 이유는 서로 다른 문제처럼 보인다. 하지만 셋 모두 기능이 작동하는지만 봐서는 품질을 판단할 수 없다. 실제 사용 환경에서 무엇이 거슬리고, 얼마나 자주 반복되며, 나중에 누가 유지보수할지를 알아야 좋은 선택이 된다.

오늘의 뉴스 3개

1. GeekNews

Show GN: Jetendard 폰트 (JetBrains Mono Nerd Font + Pretendard)

이 폰트는 여밀 폰트의 소스코드를 거의 그대로 사용했습니다. 여밀 폰트와 다른 점은 Geist mono font 대신 JetBrains Mono Nerd Font Mono를 사용했다는 것입니다.

이 폰트를 만들게 된 이유는 다음과 같습니다.

대부분의 코딩용 고정폭 폰트에는 한글 폰트가 포함되어 있지 않아 IDE나 터미널에서 대체 문자로 표시될 때 유니코드 박스 그리기 문자가 미묘하게 밀려 보기 흉해지는 현상이 발생합니다.

일반적으로 코딩용 고정폭 폰트에 한글 폰트를 포함하면 영문 2자가 한글 1자보다 현저하게 커서 한글 폰트 주변에 불필요한 공백이 생기고, 이는 한글 띄어쓰기 공백과 시각적으로 혼동되어 한글을 읽을 때 피로도를 증가시킵니다.

1번을 만족하면 2번의 문제가 생기고, 2번을 만족하면 1번의 문제가 생기는 상충되는 면이 있어, 이 두 가지 문제를 어느 정도 해결하고자 이 폰트를 만들게 되었습니다.

한글 폰트의 스케일을 조금 더 키워 한글의 불필요한 자간 공백을 최대한 줄이는 방법을 선택했습니다. 어차피 공백으로 버려지는 공간에 글자를 좀 더 꽉 채워 넣는 방식입니다. 한글 글자가 좀 커 보이는 현상은 있지만, 띄어쓰기가 더 명확히 구분되어 한글을 읽기 편하고, 글자를 키웠기에 한글 폰트 자체도 더 선명하게 보입니다.

원문 보기

728x90

 

2. GeekNews

덜한 것이 더 낫다, 대체로

AI 시대의 양과 질

AI로 모든 아이디어, 새 기능, 애니메이션이 몇 번의 프롬프트만으로 구현 가능해져, 이전에 몇 시간·며칠·몇 주 걸리던 작업이 몇 분으로 단축되었습니다. 더 많은 사람이 더 많은 것을 더 빠르게 만들 수 있게 되었으나, 더 많이 만들어진다고 해서 더 나은 것이 만들어지는 것은 아닙니다. 좋은 제품에서 훌륭한 제품으로 넘어갈 때 그 차이를 느낄 수 있으며, 대개 단일 요소가 아니라 작은 결정과 디테일이 쌓여 훌륭한 경험을 만듭니다.

단순함과 명료함

인간은 단순하고 예측 가능한 것을 선호하는데, 이는 뇌가 일종의 에너지 절약 기계이기 때문입니다. 단순함은 불필요한 인지 부하를 줄이고 처리를 쉽게 하며 경험을 덜 압도적으로 만듭니다. 심리학의 처리 유창성(processing fluency) 개념에 따르면, 처리하기 쉬울수록 더 친숙하고 유쾌하며 신뢰할 만하게 느껴집니다. Jony Ive의 인용을 통해, 단순함은 단순히 잡동사니를 제거하는 것을 넘어 깊은 이해를 바탕으로 본질만 남기는 것임을 설명합니다.

추가는 쉽고 제거는 어렵다

AI는 추가를 그 어느 때보다 쉽게 만들며, 에이전트로는 눈을 감고 무언가를 더한 뒤 잘되기를 바라는 방식이 가능합니다. 반면 제거할 때는 의도적이어야 하고 모든 함의를 끝까지 고려해야 합니다. 에이전트를 멈추지 않고 돌려 수백만 줄의 코드를 생성할 수 있으나, 그 결과가 좋을 것이라는 보장은 없습니다.

애니메이션 사례

무언가를 애니메이션하는 것과 잘 애니메이션하는 것은 전혀 다른 문제이며, 예시의 애니메이션 변형은 보기 좋지만 실제로 말이 되지는 않습니다. 컨텍스트 메뉴 비교에서 한쪽은 열릴 때와 닫힐 때 모두 움직이고 항목 hover 시 background-color 변화까지 애니메이션하지만, 다른 쪽은 그렇지 않습니다. macOS 우클릭 메뉴처럼 하루에 수백~수천 번 쓰이는 동작임을 이해하면, 진입과 종료를 모두 애니메이션하는 것이 좋은 선택이 아님을 알게 됩니다. 하루 200번 열고 애니메이션 길이가 300ms라면, 하루 약 1분, 연간 6시간 이상을 애니메이션 재생을 지켜보는 데 소비하게 되어 방해가 되고 성가십니다. 무엇을 풀고 있는지, 사람들이 어떻게 쓰는지 이해하면 애니메이션하지 않는 것이 당연한 결정이 됩니다. 에이전트는 실행에는 뛰어나지만 아직 이해와 판단을 온전히 갖추지 못했고, 바로 이 점이 제품을 훌륭하게 만드는 요소입니다.

엔지니어링에서의 판단과 이해

누구나 많은 코드를 작성할 수 있게 되면서, 엔지니어의 결과물 품질이 코드의 양으로 결정되던 시대는 끝났습니다. Interfere에서는 해야 할 일을 가능한 한 적은 코드로 해내는 pull request를 높이 평가합니다. 코드를 리뷰하고 좋은 코드와 나쁜 코드를 구분하며 비판적으로 사고하는 능력이 코드 작성 능력보다 더 중요해지고, 동시에 더 희소해집니다. 지식과 이해가 부족한 채 바로 만들기로 넘어가면, 에이전트의 결과물이 좋은지 나쁜지 판단하기 어려워 좋은 방향으로 이끌기 힘듭니다.

codebase-standards 스킬

높은 품질 기준을 유지하고 에이전트와 사람 모두가 따를 원칙을 공유하기 위해, 자체 /codebase-standards 스킬을 제작했습니다. 이를 코드를 기준에 맞춰 검토하는 /interfere-review 명령과 함께 사용해, 이해와 판단을 팀원과 에이전트 모두 활용할 수 있는 형태로 인코딩합니다.

에이전트와 일하는 원칙

사고를 에이전트에 외주화하지 않기, 에이전트가 쓴 것을 기본적으로 옳다고 가정하지 않고 비판적으로 대하기, 에이전트가 추가한 각 줄이 무엇을 하는지 최소한 대략적으로라도 설명할 수 있게 하기, 추가하는 모든 것이 최종 결과를 더 낫게 만드는지 생각하기, 에이전트는 자신의 연장선이며, 어떤 일을 잘할수록 에이전트도 그만큼 잘하게 됨, 스킬·명령·MCP를 활용해 최대한 많은 컨텍스트를 주고 원하는 방식을 분명히 제시하기, 이해되지 않는 것이 있으면 AI로 설명받기 — 가장 강력한 학습 도구 중 하나.

무엇을 만들지 말아야 하는가

AI는 더 많은 기능·코드·애니메이션을 그 어느 때보다 쉽게 추가하게 하지만, 굳이 만들 필요 없는 것까지 만들기 쉽게 만듭니다. 이제의 질문은 만들 수 있는가가 아니라 무엇을 어떻게 만들어야 하는가입니다. 도구가 강력해질수록 이해·판단·취향(taste) 의 가치가 커지며, 제품·사용자·문제에 대한 이해, 관점, 비전은 여전히 사람의 몫입니다. 단순함은 우연히 생기지 않으며, 무엇을 제거하고 무엇을 그대로 두고 무엇을 아예 만들지 말지 아는 깊은 이해에서 나옵니다. 요소·애니메이션·기능을 추가할 때마다 왜 추가하는지, 그것이 최종 결과를 더 낫게 하는지 비판적으로 따져야 하며, AI 시대에는 무엇을 만들지 않을지 아는 것이 가장 중요한 역량일 수 있습니다.

원문 보기

3. GeekNews

AI 코딩 시대의 개발자 역할 변화: 코딩 실행자에서 맥락·검증·제품화 설계자로

요약 개요

AI가 코드를 직접 작성·수정·테스트하는 수준에 도달하면서, 개발자의 역할은 단순 코딩 중심에서 문제 정의, 작업 설계, 검증, 맥락 관리, 제품화 지원으로 이동하고 있다.

AI는 코드 생산 속도를 크게 높였지만, 코드가 곧바로 좋은 제품이 되는 것은 아니다. 요구사항, 문서, 테스트, 구조화, UX 판단, 유지보수 가능성 같은 비코딩 영역의 중요성이 더 커졌다.

서론

게시글은 “사람이 직접 코딩하지 않는 시대에 개발자는 무엇을 해야 하는가”라는 질문에서 출발한다. 작성자는 과거에는 AI가 환각과 실수를 일으키기 때문에 최종 판단은 사람이 해야 한다고 보았다. 그러나 최근 AI 모델의 성능 향상으로 인해, AI가 이슈 파악, 파일 탐색, 코드 수정, 테스트 통과까지 수행하는 수준에 도달했다고 평가한다.

AI가 코드를 잘 작성하게 되었지만, 이것이 개발자의 역할이 사라진다는 뜻은 아니다. 오히려 코딩이 자동화될수록 개발의 다른 요소들이 더 뚜렷하게 드러난다. 요구사항 정리, 의사결정 기록, 테스트 설계, 코드 구조 관리, 제품 경험 검수 등이 개발자의 핵심 과제로 부상한다.

본론

작성자는 AI가 단순 코드 조각을 생성하는 수준을 넘어, 실제 개발 작업 흐름을 처리할 수 있게 되었다고 본다. 과거에는 AI의 결과물을 사람이 계속 감시하고 수정해야 했지만, 이제는 AI에게 작업을 맡기고 결과를 검수하는 방식이 가능해졌다.

AI는 여전히 항상 성공하지는 않는다. 에러가 반복되거나, 수정했다고 했지만 실제 화면에서 문제가 남아 있는 경우가 발생한다. 작성자는 처음에는 사람이 에러를 복사해 AI에게 전달하는 방식으로 대응했다. 이후 Playwright를 사용해 AI가 브라우저를 직접 열고 테스트하도록 만들면서, 사람이 하던 검증 절차도 AI에게 맡길 수 있음을 깨달았다.

작성자는 AI를 단순 보조 도구로 쓰는 관점에서 벗어나, 자신이 하던 절차 전체를 AI가 수행하게 만드는 방향으로 전환한다. 반복 작업을 커맨드, 스킬, 워크플로우로 만들고, 자신의 암묵지를 명세화하려고 시도한다. 중요한 점은 AI에게 단순히 “코드를 짜라”고 하는 것이 아니라, 언제 질문하고, 언제 멈추고, 언제 검증할지까지 규칙화하는 것이다.

AI는 작성자가 과거에는 비용과 시간 때문에 시도하지 못했던 대형 아이디어를 실제로 실험하게 만든다. 핵심은 AI가 완성품을 즉시 만들어준다는 것이 아니라, 시작의 허들을 낮춰준다는 점이다. 개발자는 “이걸 만들 수 있을까?”에서 “일단 어디까지 만들어볼 수 있을까?”로 사고를 전환하게 된다.

AI로 코드 생산량이 증가하면, 개발자는 모든 코드를 직접 읽고 맥락을 머릿속에 저장하기 어려워진다. 직접 코딩할 때는 자연스럽게 축적되던 맥락, 판단, 구조 이해가 AI에게 코딩을 맡기면 자동으로 남지 않는다. 따라서 문서, 테스트, 이슈, 작업 보고서, 변경 이유 기록이 중요해진다. 코딩 능력만큼이나 맥락과 판단을 보존하는 능력이 중요해진다는 점이 강조된다.

AI로 만든 결과물은 겉보기에는 좋지만 내부 코드 구조가 취약할 수 있다. 개발자의 역할은 이런 결과물을 무조건 낮게 평가하거나 폐기하는 것이 아니다. 동시에 그대로 제품화해서도 안 된다. 개발자는 가능성 있는 결과물이 더 멀리 갈 수 있도록 구조를 정리하고, 위험을 표시하고, 테스트 가능한 단위를 만들고, 맥락을 남겨야 한다. 즉, 개발자는 “끝까지 혼자 만드는 사람”에서 “AI와 사람이 만든 결과물을 지속 가능한 제품으로 이어주는 사람”으로 역할이 확장된다.

결론

AI가 코딩을 수행할 수 있게 된 만큼, 개발자는 AI에게 무엇을 맡기고 무엇을 직접 판단해야 하는지 경험적으로 익혀야 한다. 특히 문제를 더 크게 설정하는 능력, 반복 절차를 스킬과 워크플로우로 만드는 능력, 요구사항, 문서, 테스트, 이슈를 구조화하는 능력, AI 산출물을 검수하고 부족한 부분을 재지시하는 능력, 거친 결과물을 지속 가능한 제품으로 다듬는 능력, 코드 밖의 도구와 업무 흐름까지 AI와 연결하는 능력이 중요해진다.

원문 보기

기초상식 · 운영체제

오늘의 정처기 문제

운영체제에서 가상 메모리 관리 기법 중, 프로세스가 필요로 하는 페이지만 메모리에 적재하고 나머지는 보조 기억 장치에 두는 방식은?

1. 세그먼테이션(Segmentation)
2. 페이징(Paging)
3. 스와핑(Swapping)
4. 단편화(Fragmentation)

정답과 해설 보기

정답 2번 · 페이징(Paging)

해설 페이징은 가상 메모리를 고정된 크기의 페이지로 나누어 관리하는 기법입니다. 프로세스가 당장 필요한 페이지만 물리 메모리에 적재하여 메모리 효율성을 높이고, 더 큰 가상 주소 공간을 제공할 수 있습니다. 세그멘테이션은 가변적인 크기의 논리적 단위인 세그먼트로 나누어 관리하는 방식입니다.

오늘의 IT · 개발 · 기획 용어

• 멱등성 (Idempotency) 개발
  동일한 연산을 여러 번 수행하더라도 결과가 항상 같거나 시스템의 상태가 동일하게 유지되는 특성을 의미한다.
• CDN (Content Delivery Network) IT
  사용자의 지리적 위치와 가까운 서버에서 콘텐츠를 제공하여 웹 서비스의 전송 속도를 높이는 분산 네트워크 시스템이다.
• 퍼널 (Funnel) 기획
  사용자가 특정 목표를 달성하기까지 거치는 일련의 단계를 시각적으로 표현한 것으로, 각 단계에서 이탈하는 사용자 수를 분석하는 데 사용된다.

공개 뉴스와 원문을 바탕으로 사실·주장·개인 해석을 구분해 정리했습니다. 수치와 제품 정보는 각 원문에서 최신 내용을 다시 확인하세요.