iOS 클라이언트는 강한 대비의 헤드라인 목록, 웹을 읽기 어렵게 만든 요소를 제거하는 리더 모드, 선택적으로 기사를 요약하는 “intelligence” 뷰를 포함함
핵심은 요약이 Apple의 로컬 모델 API를 통해 온디바이스에서 생성된다는 점임
서버 우회, 프롬프트나 사용자 로그, 벤더 계정, “콘텐츠를 30일 보관한다”는 식의 각주가 필요 없음
모든 AI 사용이 서버 측에서 일어난다고 받아들이는 흐름이 너무 자연스러워졌고, 이를 되돌리려면 업계 차원의 노력이 필요함
일부 사용 사례는 클라우드 호스팅 모델만 제공할 수 있는 지능을 요구하지만, 모든 사용 사례가 그런 것은 아니므로 신중한 판단이 필요함
Apple 생태계의 로컬 AI 도구
Apple 생태계에서는 최근 1년 동안 개발자가 내장 로컬 AI 모델을 쉽게 활용할 수 있도록 투자가 이뤄짐
기본 흐름은 FoundationModels를 가져오고, SystemLanguageModel.default의 사용 가능 여부를 확인한 뒤, LanguageModelSession으로 프롬프트를 구성해 응답을 받는 방식임
import FoundationModels
let model =SystemLanguageModel.default
guard model.availability == .available else { return }
let session =LanguageModelSession {
"""
Provide a brutalist, information-dense summary in Markdown format.
- Use **bold** for key concepts.
- Use bullet points for facts.
- No fluff. Just facts.
"""
}
let response =tryawait session.respond(options: .init(maximumResponseTokens: 1_000)) {
articleText
}
let markdown = response.content
긴 콘텐츠는 일반 텍스트를 약 1만 자 단위로 나누고, 각 청크에서 간결한 “facts only” 노트를 만든 뒤, 두 번째 패스로 최종 요약을 결합할 수 있음
이런 작업은 로컬 모델에 잘 맞음
입력 데이터는 사용자가 이미 읽고 있는 콘텐츠라서 기기에 있음
출력은 가벼움
빠르고 비공개로 처리됨
사용자가 방금 불러온 페이지를 요약하는 작업이지, 세계 지식을 새로 만들어내는 작업이 아니므로 초인적 수준의 지능이 필요하지 않음
로컬 AI는 모델의 역할이 우주 전체를 검색하는 것이 아니라, 사용자가 소유한 데이터를 변환하는 일일 때 빛남
신뢰를 만드는 방식
이메일 요약, 노트에서 할 일 추출, 문서 분류 같은 AI 기능은 사람들이 원하지만 신뢰하지 못하는 기능에 속함
일반적인 클라우드 방식은 이런 기능을 모두 “데이터를 서버로 보내도 괜찮은지”를 묻는 신뢰 문제로 바꿈
로컬 AI는 이미 기기에 있는 데이터를 그 자리에서 처리하게 해 이 구조를 바꿈
사용자 신뢰는 2,000단어짜리 개인정보 처리방침으로 만들어지지 않음
애초에 그런 개인정보 처리방침이 필요 없도록 만드는 방식이 신뢰를 만듦
구조화된 출력과 타입 기반 AI
Apple이 최근 잘한 선택 중 하나는 “AI output”을 구조 없는 텍스트 덩어리에서 타입이 있는 데이터로 옮긴 점임
“모델에게 JSON을 요청하고 잘 나오길 바라는” 방식 대신, 원하는 결과를 나타내는 Swift struct를 정의하는 방식이 더 새롭고 나은 패턴임
각 필드에 자연어 가이드를 주고, 모델에게 해당 타입의 인스턴스를 생성하게 함
import FoundationModels
@GenerablestructArticleIntel {
@Guide(description: "One sentence. No hype.") var tldr: String@Guide(description: "3–7 bullets. Facts only.") var bullets: [String]
@Guide(description: "Comma-separated keywords.") var keywords: [String]
}
let session =LanguageModelSession()
let response =tryawait session.respond(
to: "Extract structured notes from the article.",
generating: ArticleIntel.self
) {
articleText
}
let intel = response.content
이 방식이면 UI가 Markdown의 불릿을 긁어내거나 모델이 JSON 스키마를 기억했기를 기대할 필요가 없음
앱은 실제 필드를 가진 실제 타입을 받아 일관되게 렌더링할 수 있음
앱이 실제로 사용할 수 있는 구조화된 출력을 만들며, 이 과정 전체가 로컬에서 실행됨
단순히 편리한 인터페이스가 아니라 엔지니어링 품질 개선
로컬 퍼스트 앱에서 “AI는 신기한 기능”이 아닌 “신뢰할 수 있는 서브시스템” 으로 기능하게 만드는 차이가 됨
“로컬 모델은 덜 똑똑하다”에 대한 반론
로컬 모델이 클라우드 모델만큼 똑똑하지 않다는 점은 맞지만, 대부분의 앱 기능에는 해당하지 않음
대부분의 기능이 요구하는 것은 셰익스피어를 쓰거나 양자역학을 설명하는 능력이 아니라, 요약, 분류, 추출, 재작성, 정규화 중 하나를 안정적으로 수행하는 능력
이런 작업에 로컬 모델은 충분히 뛰어남
로컬 모델을 인터넷 전체의 대체물로 쓰면 실망하지만, 앱 내부의 “데이터 변환기” 로 사용하면 왜 서버에 보냈는지 의문이 들 정도
클라우드 모델은 진짜 필요할 때만 사용하고, 사용자 데이터는 제자리에 둬야 함
AI를 사용할 때 채팅 박스를 붙이는 것이 아니라, 타입 출력과 예측 가능한 동작을 갖춘 실제 서브시스템으로 활용해야 함
프라이버시와 신뢰 구축
이메일 요약, 노트에서 액션 아이템 추출, 문서 분류 등 사람들이 원하지만 신뢰하지 않는 AI 기능이 다수 존재
클라우드 방식은 이 모든 것을 신뢰 실험으로 전환: “데이터를 서버로 보내주세요, 잘 다루겠습니다”
로컬 AI는 이를 근본적으로 바꿈 — 기기에 이미 데이터가 있고, 기기에서 바로 처리
2,000단어짜리 개인정보 보호정책을 작성해서가 아니라, 애초에 그런 정책이 필요 없는 구조로 신뢰 구축
AI 확산으로 청년 일자리 감소
젊은이들이 실무 경험 못 쌓으면
고령화 속에 산업현장 허리 끊겨
사람·기술 공존할 구조 갖춰야
4월 20일 서울 마포구 서울서부고용복지플러스센터에서 구직자가 상담을 기다리고 있다. /뉴스1
2023년 아빈드 크리슈나 IBM 최고경영자는 5년간 7800명의 일자리를 AI(인공지능)로 대체하겠다는 계획을 내놨다. 대대적인 인력 감축과 채용 축소의 신호탄으로 여겨졌다. 하지만 지난 2월 IBM은 올해 미국 내 신입 사원 채용 규모를 3배로 늘리겠다고 발표했다. 니클 라모로 IBM 최고인사책임자는 “신입 채용에 대한 투자를 계속하지 않으면 3~5년 후에는 인재 공급망이 붕괴하고 인재 풀이 고갈될 것”이라고 했다. 단순 업무를 AI가 처리하더라도 사람을 뽑아 키우지 않으면 장차 책임자급 인재 수급에 차질이 생길 수 있다는 IBM 내 위기감이 반영된 것이라는 분석이 나왔다.
세계경제포럼(WEF)이 3월 공개한 AI 관련 분석에도 이와 비슷한 문제의식이 깔려 있다. 이에 따르면, 최근 18개월간 미국 내 신입 채용 공고가 35% 줄었는데 주된 원인은 AI였다. 그런데 기업이 AI 도입으로 신입 채용을 줄여 얻는 단기적 효율이 실상은 장기적인 위험을 가리는 것에 불과하다고 했다. 신규 인력 유입 시스템이 제대로 작동하지 않으면 인재 육성 체계의 균열, 지식 전수의 중단, 조직 문화 쇄신 동력의 약화 등 다양한 부작용이 나타나고 기업이 AI 혁신을 통해 기대했던 미래 역시 실현되기 어려울 수 있다는 것이다.
해외에서는 AI 확산에 따른 인적 자원 공백 위험을 이토록 고민하는데 우리는 어떤가. 어느 조직이든 사람이 성장하고 숙련되는 과정은 크게 다르지 않다. 신입 직원은 오랜 기간에 걸친 학습과 훈련, 시행착오와 실전 경험을 통해 전문가로 거듭난다. 이런 축적의 시간을 지나며 중견의 단계에 올라서고, 조직의 중추를 담당하는 핵심 인력으로 자리 잡는다. 조직은 이 같은 인적 자원의 선순환을 동력으로 삼아 지속된다. AI가 신규 인재 유입의 통로를 봉쇄한다면 그 결과는 불 보듯 뻔하다. 인적 자본의 축적을 가로막고 조직의 내재 역량은 결국 고갈될 것이다.
이는 한국 산업 구조상 더 치명적인 문제일 수 있다. 경직된 고용 제도로 해고가 어려운 우리나라에서는 AI로 인한 일자리 충격이 주로 신규 채용의 문을 닫는 방식으로 나타나고 있다. 기존 직원을 내보내지 못하니 비용과 효율성을 따져 AI 활용은 늘리되 새로 사람을 뽑지는 않는 것이다. AI 전환의 비용을 청년들이 다 부담하는 셈이다. 올해 1분기 청년 실업률은 5년 만에 가장 높았다. 주력 산업 일자리가 줄어든 가운데, 전문직·IT 등 AI 확산에 따른 일자리 대체 효과가 큰 업종의 구직난이 겹친 결과다. 기회의 사다리가 끊긴 청년들은 계속 미숙련자로 남게 될 처지다.
이 상태가 방치되면, 우리 사회의 고령화가 가속화하는 가운데 10~20년 후 산업 현장의 허리가 끊어지게 된다. 가뜩이나 제조업 경쟁력이 떨어지는 상황에서 인력 구조의 질적 저하까지 맞물리는 최악의 시나리오에 직면하는 것이다. 특히 노하우 전수가 수직적으로 이루어지는 연공 서열 중심의 한국 기업 문화 특성상, 신입 사원의 부재는 조직의 핵심 자산인 현장 경험의 단절로 이어질 수 있다.
AI의 파고를 거스를 수는 없다. 관건은 사람과 기술이 공존하는 구조를 만드는 데 있다. 정부는 고용 제도를 유연하게 다듬는 한편 현장 경험의 단절을 메울 새로운 인재 양성 트랙을 구축해야 한다. 기업은 당장의 효율에만 매몰되지 말고 미래 인재를 육성하는 데 책임감을 가져야 한다. 노동계의 태도 변화도 절실하다. 일부 노조처럼 생산 현장의 AI 도입을 통제하겠다는 발상은 시대착오적이다. 기술을 막아 세우는 것으로는 일자리를 지켜낼 수 없다.
판교는 늘 미래를 이야기하는 도시다.
하지만 그 미래를 만드는 사람들의 하루는 의외로 소박하고, 반복적이며, 자주 외롭다.
잘 만든 서비스 뒤에는 아무도 기억하지 못하는 야근이 있고, 매끄러운 화면 뒤에는 수십 번의 수정이 있으며, “빠른 대응 감사합니다”라는 짧은 문장 뒤에는 누군가의 긴 하루가 숨어 있다.
《판교맨은 오늘도 성장 중입니다》은 바로 그 보이지 않는 하루들을 담은 콩트 모음집이다.
거창한 사건보다 작은 균열, 대단한 성공보다 미묘한 감정, 화려한 성장보다 “그래도 오늘은 조금 괜찮았다”는 마음을 따라간다.
이 책 속 인물들은 특별하지 않다.
그래서 더 오래 남는다.
회의실 이름은 근사하지만 공기는 건조한 회사, 퇴근 후에도 쉽게 끝나지 않는 하루, 회사 얘기를 하지 않기로 해놓고 결국 또 회사 얘기를 하게 되는 사람들.
그 익숙한 풍경 속에서 독자는 자기 마음의 일부를 발견하게 된다.
이 책은 직장생활의 고단함을 고발하기보다, 그 안에서 끝내 사라지지 않는 작은 온기를 보여준다.
지친 직장인에게는 공감이 되고, 아직 회사 생활을 잘 모르는 사람에게는 현실적인 감정의 풍경이 된다.
무너지지 않기 위해 오늘도 자기만의 방식으로 하루를 건너는 사람들에게, 이 책은 조용한 위로가 되어줄 것이다.
지몬테는 20여 년 동안 컴퓨터 개발자이자 공학자로 살아오며 코드와 회로, 네트워크 속에서 인간과 기술의 경계를 지켜봐 왔습니다. 영화와 게임, 그리고 별과 우주를 향한 상상을 바탕으로, 일상의 작은 균열 틈에서 시작되는 과학적 상상과 인간적인 이야기를 단편 SF로 풀어내고 있습니다. 현실적인 디테일 위에 미래의 가능성을 덧입혀, “조금은 가까운 미래”를 독자와 함께 탐사하는 이야기를 쓰고자 합니다.
Anthropic의 코딩 에이전트 연구자 Eric이 바이브 코딩(AI에게 코드 작성을 전적으로 맡기는 방식)을 실제 서비스 환경에서 어떻게 안전하게 활용할 수 있는지를 다룬 발표입니다. 단순히 AI로 코드를 많이 생성하는 것과 바이브 코딩은 다르며, Andrej Karpathy의 정의처럼 “코드가 존재한다는 사실 자체를 잊는 것”이 핵심이라고 설명합니다. AI가 처리할 수 있는 작업 규모가 7개월마다 두 배로 늘고 있는 상황에서, 이 흐름을 활용하지 못하면 경쟁에서 뒤처질 수밖에 없다는 문제의식에서 출발합니다.
핵심 주장
바이브 코딩의 원칙은 “코드는 잊되, 제품은 잊지 말 것”입니다. 컴파일러가 생성한 어셈블리를 일일이 읽지 않듯, AI가 작성한 코드 자체보다 결과물의 품질과 정확성을 검증하는 데 집중해야 한다고 봅니다.
개발자의 역할이 직접 구현하는 사람에서 Claude의 프로덕트 매니저(PM)로 전환되어야 합니다. 신입 엔지니어에게 업무를 맡길 때처럼, 요구사항과 코드베이스 맥락, 제약조건을 충분히 정리해 AI에 전달하는 과정이 15~20분 이상 소요되더라도 그 투자가 성공률을 크게 높인다고 합니다.
바이브 코딩은 코드베이스의 리프 노드(다른 코드가 의존하지 않는 말단 기능)에 집중해야 합니다. 핵심 아키텍처나 다른 모듈이 의존하는 근간 코드는 여전히 사람이 깊이 이해하고 관리해야 합니다.
검증 가능성 설계가 필수적입니다. Anthropic 내부에서 22,000줄 규모의 강화학습 코드를 Claude로 작성해 프로덕션에 머지한 사례에서, 스트레스 테스트와 입출력 기반 검증 체크포인트를 설계해 코드를 전부 읽지 않고도 안정성과 정확성을 확인했다고 합니다.
현재의 한계
기술 부채(tech debt)는 코드를 직접 읽지 않고는 측정하거나 검증할 좋은 방법이 아직 없습니다. 이 점이 바이브 코딩을 리프 노드에 한정해야 하는 가장 큰 이유입니다.
비개발자가 보안이나 결제 같은 민감한 영역까지 바이브 코딩으로 프로덕션 시스템을 구축하는 것은 위험합니다. 올바른 질문을 던질 수 있는 기술적 판단력이 전제되어야 합니다.
차별점
바이브 코딩을 단순한 유행이 아닌 소프트웨어 산업의 구조적 전환으로 프레이밍하고, CTO가 전문가를 관리하거나 CEO가 회계사의 업무를 검증하는 것처럼 “구현을 모르면서도 결과를 검증하는 문제”는 문명만큼 오래된 과제라는 점을 짚은 것이 인상적입니다.
시사점
소프트웨어 엔지니어에게 요구되는 역량이 코드 한 줄 한 줄을 쓰는 능력에서, 요구사항을 정밀하게 정의하고 결과를 구조적으로 검증하는 능력으로 이동하고 있습니다. AI 도구의 성능 향상 속도를 고려하면, 이 전환에 적응하는 시점이 빠를수록 유리할 것으로 보입니다.
Anthropic의 코딩 에이전트 연구자 Eric이 바이브 코딩(AI에게 코드 작성을 전적으로 맡기는 방식)을 실제 서비스 환경에서 어떻게 안전하게 활용할 수 있는지를 다룬 발표입니다. 단순히 AI로 코드를 많이 생성하는 것과 바이브 코딩은 다르며, Andrej Karpathy의 정의처럼 “코드가 존재한다는 사실 자체를 잊는 것”이 핵심이라고 설명합니다. AI가 처리할 수 있는 작업 규모가 7개월마다 두 배로 늘고 있는 상황에서, 이 흐름을 활용하지 못하면 경쟁에서 뒤처질 수밖에 없다는 문제의식에서 출발합니다.
핵심 주장
바이브 코딩의 원칙은 “코드는 잊되, 제품은 잊지 말 것”입니다. 컴파일러가 생성한 어셈블리를 일일이 읽지 않듯, AI가 작성한 코드 자체보다 결과물의 품질과 정확성을 검증하는 데 집중해야 한다고 봅니다.
개발자의 역할이 직접 구현하는 사람에서 Claude의 프로덕트 매니저(PM)로 전환되어야 합니다. 신입 엔지니어에게 업무를 맡길 때처럼, 요구사항과 코드베이스 맥락, 제약조건을 충분히 정리해 AI에 전달하는 과정이 15~20분 이상 소요되더라도 그 투자가 성공률을 크게 높인다고 합니다.
바이브 코딩은 코드베이스의 리프 노드(다른 코드가 의존하지 않는 말단 기능)에 집중해야 합니다. 핵심 아키텍처나 다른 모듈이 의존하는 근간 코드는 여전히 사람이 깊이 이해하고 관리해야 합니다.
검증 가능성 설계가 필수적입니다. Anthropic 내부에서 22,000줄 규모의 강화학습 코드를 Claude로 작성해 프로덕션에 머지한 사례에서, 스트레스 테스트와 입출력 기반 검증 체크포인트를 설계해 코드를 전부 읽지 않고도 안정성과 정확성을 확인했다고 합니다.
현재의 한계
기술 부채(tech debt)는 코드를 직접 읽지 않고는 측정하거나 검증할 좋은 방법이 아직 없습니다. 이 점이 바이브 코딩을 리프 노드에 한정해야 하는 가장 큰 이유입니다.
비개발자가 보안이나 결제 같은 민감한 영역까지 바이브 코딩으로 프로덕션 시스템을 구축하는 것은 위험합니다. 올바른 질문을 던질 수 있는 기술적 판단력이 전제되어야 합니다.
차별점
바이브 코딩을 단순한 유행이 아닌 소프트웨어 산업의 구조적 전환으로 프레이밍하고, CTO가 전문가를 관리하거나 CEO가 회계사의 업무를 검증하는 것처럼 “구현을 모르면서도 결과를 검증하는 문제”는 문명만큼 오래된 과제라는 점을 짚은 것이 인상적입니다.
시사점
소프트웨어 엔지니어에게 요구되는 역량이 코드 한 줄 한 줄을 쓰는 능력에서, 요구사항을 정밀하게 정의하고 결과를 구조적으로 검증하는 능력으로 이동하고 있습니다. AI 도구의 성능 향상 속도를 고려하면, 이 전환에 적응하는 시점이 빠를수록 유리할 것으로 보입니다.
