[디지털투데이 황치규 기자]"대형언어모델(LLM)이 기계공학 못한다는 건 이미 깨진 편견이다."
LG전자 전자사업 부문인 VS본부 김용연 연구위원은 11일 다쏘시스템코리아가 개최한 시뮬리아 유저 데이터 2026 컨퍼런스 기조연설에서 "LLM이 기계공학 영역을 제대로 다루지 못한다는 인식은 이제 무너지고 있다"면서 "제조업체들에서 에이전트 AI를 도입하는 사례가 빠르게 늘어났고, AI 답변에 대한 신뢰도 크게 높아졌다"고 강조했다.
LLM은 주로 소프트웨어 개발이나 일선 업무 현장에서 많이 쓰이고, 하드웨어 개발쪽에선 상대적으로 중량감이 덜하다는 인식이 많았지만 최근 1년 사이에서 드라마틱한 변화가 일어나고 있다는게 그의 설명이다.
그는 "LLM은 엔지니어링 분야에서 전문가 수준으로 활용할 수 있는 능성을 인정받는 수준"이라며 "콘티넨탈 같은 글로벌 자동차 부품사는 텍스트, 이미지를 파싱해 임베딩하는 방식에서 멀티모달 비전언어모델(VLM)을 활용한 온톨로지 기반 지식 그래프를 구축했다. 이후 출력 모델 신뢰도가 이전과 비교할 수 없을 만큼 높아졌다"고 전했다.
그에 따르면 4년 전만 해도 업계 화두는 데이터를 가공하고 가시화해 업무를 효율화하는 디지털 전환(DX)이었다. 지금은 대부분 기업들이 LLM을 활용한 AI 전환을 핵심 과제로 내걸고 있다. 하드웨어 엔지니어들 입장에선 AX는 DX를 진입 장벽이 상대적으로 낮다. 김 연구위원은 LG전자를 사례로 들며 "AI가 등장하면서 DX 시절에는 하기 힘들었던 가설 검증, 프로세스 개선 등에서 눈에 띄는 성과를 낼 수 있게 됐다"고 말했다.
그는 LG전자 사례를 들어 AX에서 핵심은 기술 도입이 아니라 엔지니어 의사결정의 품질을 높이는 것이라는 점도 분명히했다. AX를 단순히 AI를 도입하는 것이 아닌 워크플로 재설계로 봐야 한다는 것이었다.
그에 따르면 LG전자는 연구소 엔지니어들이 실제 연구개발 업무에 쓰는 시간이 얼마나 되는지 전수 조사했다. 결과를 보니 '불편한 진실'이 나타났다. 엔지니어들이 엔지니어로서 해야할 업무보다 각종 대응 업무, 소위 '잡무'에 더 많은 시간을 쓰고 있었다.
데이터 단절도 현실적인 문제였다. 개인 워크스테이션, 노트북, 사내 서버에 데이터가 흩어져 있었고 연구소, 품질, 구매, 생산 부문 간 사일로도 협업을 가로막는 요인이었다.
이런 가운데 LG전자는제품 기획부터 양산까지 전 과정에 걸쳐 업무를 분석했다. 제품 하나를 개발하는 데 연결돼 있는 태스크(작업)들만 440개 이상에 달했다고. LG전자는 각 태스크에 AI 적용 가능성을 검토하고, 단계별 베스트 프랙티스를 정의해 개발 프로세스를 재설계했다. 김용연 연구위원은 "핵심은 AI가 업무를 대체하는 것이 아니라, 반복 업무를 걷어내고 엔지니어가 핵심적인 판단에 집중하도록 구조를 바꾸는 것"이라고 거듭 강조했다.
김 연구위원은 글로벌 제조 시장에서 업체들 간 경쟁이 심화되고 있어 의사 결정 품질 향상이란 본질을 살리는 AX의 전략적 가치는 점점 커질 수 밖에 없다는 입장이다. 그는 특히 글로벌 자동차 시장에서 중국의 부상을 주목했다.
그는 "글로벌 자동차 업계 평균 제품 개발 기간은 약 30개월 이상인데, 중국은 18개월 안에 만들어낸다. 더 싸고 더 빠르게 만드는 것에서 끝나지 않고 품질까지 따라오고 있다"며서 "1년 전에 사이드미러에 중국이 보이기 시작했다는 기사가 나왔는데 지금은 중국이 이미 앞서 있다. 불편하지만 사실이다. 이같은 압박이 오히려 AI를 진지하게 받아들이는 계기가 됐다"고 말했다.
이 시각 추천뉴스 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요' 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다” 백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율" 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요' 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다” 백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율"
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러?
IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시
그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요'
클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담
크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다”
백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율"
Apache Burr: 신뢰할 수 있는 AI 에이전트와 애플리케이션 구축 (burr.apache.org)
Apache Burr 는 간단한 챗봇부터 복잡한 멀티 에이전트 시스템까지 의사결정형 AI 애플리케이션을 Python으로 구성하는 프레임워크임 애플리케이션은 액션과 전이 집합으로 정의되며, DSL이나 YAML 없이 Python 함수와 데코레이터로 작성됨 Burr UI는 실행 단계별 모니터링·디버깅·추적 을 제공하고, 상태 변화를 실시간으로 확인할 수 있음 상태를 디스크, 데이터베이스, 커스텀 백엔드에 저장하고 중단 지점부터 재개할 수 있으며, 사람 입력 대기와 병렬 실행도 지원함 OpenAI, Anthropic, LangChain, FastAPI, PostgreSQL 등 기존 도구와 통합되며, 잠금 효과나 래퍼 없이 사용 가능함 신뢰할 수 있는 AI 에이전트와 애플리케이션 구축 Apache Burr 는 의사결정을 수행하는 애플리케이션 개발을 쉽게 만드는 Apache Incubating Project임 대상 범위는 단순 챗봇부터 복잡한 멀티 에이전트 시스템 까지 확장됨 구현 방식은 순수 Python이며, “no magic”을 내세움 공개 지표로 GitHub Stars 1,641개, PyPI Downloads 379k+, Discord Members 457+가 표시됨 간단하고 강력한 Python API Burr는 챗봇부터 멀티 에이전트 시스템까지 구성할 수 있는 조합 가능한 인터페이스 를 제공함 예시 코드는 burr.core 의 action , State , ApplicationBuilder 를 사용해 chat 액션을 정의함 @action(reads=["messages"], writes=["messages"]) 는 읽는 상태와 쓰는 상태를 지정함 ApplicationBuilder() 는 액션, 전이, 초기 상태, 로컬 트래커를 설정한 뒤 애플리케이션을 빌드함 실행 예시는 app.run(halt_after=["chat"], inputs={"llm_client": client}) 형태로 LLM 클라이언트를 입력으로 전달함 AI 애플리케이션 구축에 필요한 요소 Simple Python API 는 애플리케이션을 액션과 전이의 집합으로 정의하며, DSL이나 YAML 없이 Python 함수와 데코레이터만 사용함 Built-in Observability 는 Burr UI로 애플리케이션의 모든 단계를 실시간 모니터링, 디버깅, 추적할 수 있게 함 Persistence & State Management 는 상태를 디스크, 데이터베이스, 커스텀 백엔드에 자동 저장하고 중단 지점부터 재개할 수 있게 함 Human-in-the-Loop 는 어느 단계에서든 실행을 멈추고 사람 입력을 기다릴 수 있어 승인 워크플로와 상호작용형 에이전트에 적합함 Branching & Parallelism 은 병렬 액션 실행, fan out / fan in, 복잡한 DAG 구축, 하위 애플리케이션 조합을 지원함 Testing & Replay 는 과거 실행 재생, 개별 액션 단위 테스트, 상태 전이 검증을 통해 AI 시스템에 대한 확신을 높임 기존 스택과의 통합 Burr는 이미 사용하는 도구와 프레임워크에 통합되며, 잠금 효과 나 래퍼를 요구하지 않음 LLM 통합 항목으로 OpenAI, Anthropic, Instructor가 표시됨 프레임워크 통합 항목으로 LangChain, Hamilton, Haystack이 표시됨 UI와 서빙 통합 항목으로 Streamlit과 FastAPI가 표시됨 검증과 저장소 통합 항목으로 Pydantic과 PostgreSQL이 표시됨 전체 통합 목록은 문서 에서 확인할 수 있음 개발자와 팀의 사용 경험 Peanut Robotics 후기는 여러 LLM 프레임워크를 평가한 뒤 Burr의 상태 관리 가 AI 의사결정 기반 로봇 배포에 강력한 답이었다고 평가함 Watto.ai 후기는 모듈형 AI 애플리케이션을 만들기 쉽고, UI가 디버깅을 쉽게 만든다고 평가함 Paxton AI 후기는 AI라는 이유만으로 이상하고 난해한 개념을 쓰지 않는다는 점을 강조함 Provectus 후기는 상태 스냅샷 생성, 디버깅, 재생, 평가 케이스 구축에 Burr의 상태 관리가 유용하다고 평가함 CognitiveGraphs 후기는 LangChain, CrewAi, AutoGen, Agency Swarm 등 여러 agentic LLM 플랫폼과 비교해 Burr가 복잡한 동작 설계에 더 견고한 프레임워크를 제공한다고 평가함 TaskHuman 후기는 LangChain에서 Burr로 이동한 뒤 몇 시간 만에 시작했고, 전체 코드베이스를 Burr로 전환했다고 평가함 커뮤니티와 프로젝트 상태 커뮤니티는 도움 요청, 프로젝트 공유, Burr의 미래 기여를 위한 공간으로 구성됨 참여 경로는 Discord , GitHub , Twitter / X 로 제공됨 프로젝트 리소스는 문서, 예제, YouTube, 로드맵, 변경 로그로 연결됨 Apache Burr는 Apache Software Foundation에서 인큐베이션 중인 프로젝트이며, Apache Incubator가 후원함 인큐베이션 상태는 코드의 완성도나 안정성을 반드시 반영하지 않지만, ASF의 완전한 승인을 아직 받지 않았음을 나타냄
함께 보면 좋은 글 β gitagent - AI 에이전트 정의 및 관리를 위한 Git 기반 표준 AgentHub - AI 에이전트를 위한 경량 협업 플랫폼 Herdr - AI Agent 시대를 위한 tmux 스타일 터미널 워크스페이스 취향(taste)을 갖춘 30배 AI 엔지니어가 되는 법 모두가 AI를 가져도 회사는 여전히 아무것도 배우지 못할 때
gitagent - AI 에이전트 정의 및 관리를 위한 Git 기반 표준
AgentHub - AI 에이전트를 위한 경량 협업 플랫폼
Herdr - AI Agent 시대를 위한 tmux 스타일 터미널 워크스페이스
취향(taste)을 갖춘 30배 AI 엔지니어가 되는 법
모두가 AI를 가져도 회사는 여전히 아무것도 배우지 못할 때
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
인증 이메일 클릭후 다시 체크박스를 눌러주세요
▲ GN⁺ 22시간전 [-] Hacker News 의견들 에이전트 프레임워크는 아직 판단을 유보 중이고, 에이전트 성격에 따라 쓸모가 달라짐. 예를 들어 3초 안에 충분히 괜찮은 응답 을 돌려줘야 하는 경우와, 한 문제를 3시간 동안 풀어야 하는 경우는 다름 결국 에이전트는 맥락 구성, LLM 호출, 요청된 도구 호출 실행, 최종 모델 출력 파싱, 프런트엔드 반환으로 압축됨. 메모리나 비동기 도구 호출 같은 확장은 있지만 전통적인 소프트웨어 엔지니어링 관점에서는 그렇게 복잡하지 않음 모두가 자기 에이전트 프레임워크를 만들고 싶어 하지만, 특정 에이전트를 만들어야 한다면 그 에이전트에 맞춘 1:1 코드 가 훨씬 쉽고 유지보수도 낫다고 봄. 프레임워크의 추상화는 핵심 로직을 가리고 방해하는 경우가 많고, 결국 프레임워크가 고른 추상화에 맞춰야 해서 실제 목표와 어긋날 때가 있음 에이전트형 시스템의 핵심은 에이전트를 쓰는 것이 아니라, 정말 필요할 때만 쓰는 데 있다고 봄. 작동하는 시스템에는 다단계 흐름을 표현하는 파이프라인/레시피 , 여러 에이전트 작업자 풀에서 모델과 사람 개입 단계를 안정적으로 실행하는 운영 체계, 가능한 많은 일을 코드로 처리하는 두꺼운 스킬의 관리·배포·보안·권한, 적절한 세션에 적절한 맥락을 넣는 맥락 관리가 필요함 그 외에도 티켓·의존성·진척·멈춘 티켓 재시작을 다루는 프로젝트 관리, 대화 기록 저장과 메모리·꿈꾸기·누적 학습 기능, 비용과 사용량을 보는 관측성, 프롬프트 평가와 자동 조정, 모델 제공자 교체와 모델 버전 고정, 실제 세션을 돌릴 샌드박스가 필요함 한 공급자에게서 전부 받을 필요는 없지만, 대부분의 경우 단일 모델 제공자에 갇히지 말고, 자기 맥락 과 누적 학습 은 직접 소유해야 한다고 봄 대부분의 에이전트 프레임워크에서 가장 심각한 부분은 핵심 로직을 가리는 것 임. 실제 언어 모델에 무엇이 보내지고 무엇이 돌아오는지 명확히 보여야 함 에이전트형 애플리케이션의 모든 것은 결국 토큰 시퀀스나 제공자 호출로 실현되므로, 앱의 거의 모든 계층에서 그 모습이 분명해야 함 수십 개의 프런트엔드 프레임워크에도 비슷한 생각을 했음. 미래에 올 것 같지만 오지 않을 보상을 위해 거대한 추상화와 복잡도 를 떠안기는 식임 그래도 사람들은 할 일이나 재미있는 장난감이 필요하고, “다음 사람”은 대개 그리 중요하게 여겨지지 않으니, 유급 놀이 시간의 결과물을 떠넘겨도 상관없다고 여기는 듯함 특정 에이전트에 맞춘 1:1 코드 를 만드는 방식에는 어느 정도 동의함. 다만 새 에이전트에서 새 기법이나 방식을 만들었을 때, 오래된 에이전트를 어떻게 업데이트할지와 업데이트하고 싶은지가 유지보수 측면에서 고민됨 예를 들어 Apache Burr가 플러그인 가능한 벡터 RAG 시스템을 지원하거나 앞으로 지원할 것 같지만, 필요한 것은 문서를 맥락에 추가하고 업데이트된 시스템 프롬프트의 일부로 유지하면서 그 과정에 아주 구체적인 조정을 넣는 방식임. 기존 개념인 RAG를 맞춤형으로 쓰는 방식이라 특정 프레임워크와 잘 맞지 않음 내 용도에서는 맞춤 구현이 맞지만, 오래된 에이전트를 갱신하기 위한 엔지니어링 선택은 여전히 남아 있음 프레임워크의 장점은 실제 에이전트 작성이 쉬워지는 데 있는 게 아니라 도구와 관측성 등에 있음. LangChain도 비판받을 점은 많지만, 이 점은 초기에 아주 분명히 보여줬음 챗봇을 처음부터 직접 만드는 건 쉽거나 더 쉬울 수 있지만, 관측성이나 추적을 추가해야 하면 이야기가 달라짐. 환경 변수 하나만 추가해서 모든 추적을 UI에서 거의 추가 작업 없이 훑어볼 수 있다면, 직접 만든 해법은 경쟁하기 어려움 이 페이지가 https://vorpus.github.io/performativeUI/ 로 만든 건지 궁금함 AI 생성 랜딩 페이지 의 전형적인 클리셰를 가능한 한 전부 밟고 있음. 아니면 일부러 풍자한 건가 싶음 개인 프로젝트와 업무 프로젝트에서 이 프레임워크를 즐겨 쓰고 있음. AI 모델을 위한 신뢰할 수 있는 상태 있는 워크플로 와 무료 관측성을 얻을 수 있어서 좋았음 Burr 상태 기계를 MCP로 마운트하는 도구를 엮었고, 에이전트에게 따라갈 레일을 주면서 상태 기계가 아무리 복잡해져도 MCP 도구는 상태 기계 탐색으로 제한됨: https://github.com/msradam/theodosia 지금은 스킬을 상태 기계로 변환하는 작업을 하고 있음. 인기 있는 많은 스킬이 이미 AI 모델이 따라갈 단계 형태로 작성되어 있어서, Burr의 명시적 기능을 활용하면 더 안정적으로 만들 수 있을 듯함 https://strandsagents.com/ 와 비교하면 어떤지 궁금함. 이 영역의 도구에 관심이 있고 아직 특정 도구에 묶여 있지는 않지만, Bedrock + Serverless on Agent Core 가 “쉬운 안내 경로”처럼 느껴짐. 다만 플랫폼 종속은 마음에 들지 않음 다른 사용 경험이 궁금함. 이 스택을 써보고 있는데 Strands가 Agent Core와 함께 특별한 비법을 제공하는지 의문이 남음 지금까지는 그렇게 느껴지지 않고, 때로는 둘이 서로 충돌하는 것처럼 보이기도 함 여기서는 빌더 패턴 과 데코레이터가 보임. Python에도 데코레이터가 있지만, 함수나 메서드에 적용하는 “필터”로 쓰는 게 가장 적절하다고 봄. 이 함수는 캐시하고, 이 함수의 출력은 항상 직렬화하고, 이 함수를 에이전트형 실행 장치의 도구로 준비하는 식임 등록이나 흐름 제어에 쓰는 것은 아니라고 봄. 동의하지 않을 수도 있지만 누군가는 말해야 함. FastAPI가 현대적인 데코레이터 사용을 너무 많이 잘못된 방향으로 끌고 갔음 빌더 패턴은 Rust에 이름 있는 키워드 인자가 없어서 생긴 관례에 가깝고, Python 함수는 이미 이름 있는 계약을 노출함. 설정 매개변수를 연쇄 메서드 호출로 순서대로 넘길 이유는 거의 없음 생성자나 팩토리에 아직 없는 상태를 추가해야 한다면 그건 빌더 패턴이 아니라 등록임. 빌더 패턴을 용인할 만한 곳은 질의 빌더 정도임. 개념을 반복적으로 쌓아 올리고, 메서드 이름과 키워드 인자라는 메타데이터 슬롯이 실제로 유용하기 때문임. 키워드 인자 대신 단일 매개변수를 받는 메서드를 쓰는 것은 잘못됐다고 봄 여기서 데코레이터는 구체적으로 함수에 메타데이터를 붙여 재사용 가능한 구성요소 로 만들고, 빌더는 워크플로를 만듦. Hamilton에서는 순수 선언적 구성이라 전부 데코레이터로 처리하지만, 재사용성은 사실상 별도 문제임 빌더 패턴이 Rust에서만 쓰이는 건 아니지만, Python에서 쓰기에는 흉하다는 데 동의함 신뢰할 수 있는 AI 에이전트가 무엇인지에 대해 꽤 순진한 버전처럼 보임 신뢰성은 “맡긴 일을 끝낼 수 있는가”를 뜻하지, 상태 기계 와는 딱히 관련이 없음 Burr는 처음 들어보는데, 왜 Apache에서 인큐베이션됐는지 궁금함 안 될 이유가 없음. ASF는 새로운 자유 오픈소스 프로젝트를 인큐베이션해 온 긴 역사가 있음 일부는 졸업해서 누구나 아는 이름이 되고, 일부는 실패해서 attic으로 감. ASF는 조직적 지원을 제공하고 대체로 좋은 공동체를 키워 줌 내가 제출했기 때문임. Apache 절차를 배우고 다른 일도 병행하느라 느린 과정이었지만, 이제는 어느 정도 동력 이 생겼고 더 정기적인 릴리스를 시작하고 있음 페이지가 Claude Code로 만든 일회용 쓰레기처럼 보이고, JavaScript 없이 동작하려는 시도조차 안 함. 적어도 브랜드 일관성 은 있음 이름의 명시적인 근거는 못 찾았지만, 궁금한 사람을 위해 Hamilton 예제가 있음: https://github.com/apache/burr/tree/main/examples/multi-agen... Burr는 미국 건국의 아버지이자 제3대 부통령, 그리고 Alexander Hamilton의 살해자이자 숙적인 Aaron Burr 에서 따온 이름임 Hamilton과의 연결점은 DAGWorks가 Hamilton 라이브러리 다음으로 공개한 두 번째 오픈소스 라이브러리라는 데 있음. Burr와 Hamilton이 조화를 이루고 차이를 넘어 더 나은 연방을 만들었다면 어땠을지 상상한 이름임 원래 Burr는 Hamilton DAG 실행 사이의 상태를 다루는 장치로 만들었음. DAG에는 순환이 없기 때문임. 이후 적용 범위가 넓다는 걸 깨닫고 더 넓게 공개했음 https://pypi.org/project/burr/ 코딩 에이전트 오케스트레이션 도구나 플랫폼 중 추천할 만한 것이 있는지 궁금함. 여러 머신에서 codex나 claude 에이전트를 실행·관리·모니터링하고 싶음 가능하면 자체 호스팅 가능하거나 오픈소스면 좋겠음. claude code가 내부적으로 그런 기능을 많이 갖고 있는 건 알지만, claude 전용임 문서를 보니 Burr에는 이걸 시작할 수 있는 에이전트 쿡북이 있고, 여러 머신 워크플로 도 처리할 수 있음. 찾던 게 이게 아닌지 궁금함 스킬 등과 어떻게 통합해서 쓰는지는 확실하지 않지만, 보기에는 동작할 것 같음 https://burr.apache.org/docs/examples/agents/ 답변달기
Hacker News 의견들 에이전트 프레임워크는 아직 판단을 유보 중이고, 에이전트 성격에 따라 쓸모가 달라짐. 예를 들어 3초 안에 충분히 괜찮은 응답 을 돌려줘야 하는 경우와, 한 문제를 3시간 동안 풀어야 하는 경우는 다름 결국 에이전트는 맥락 구성, LLM 호출, 요청된 도구 호출 실행, 최종 모델 출력 파싱, 프런트엔드 반환으로 압축됨. 메모리나 비동기 도구 호출 같은 확장은 있지만 전통적인 소프트웨어 엔지니어링 관점에서는 그렇게 복잡하지 않음 모두가 자기 에이전트 프레임워크를 만들고 싶어 하지만, 특정 에이전트를 만들어야 한다면 그 에이전트에 맞춘 1:1 코드 가 훨씬 쉽고 유지보수도 낫다고 봄. 프레임워크의 추상화는 핵심 로직을 가리고 방해하는 경우가 많고, 결국 프레임워크가 고른 추상화에 맞춰야 해서 실제 목표와 어긋날 때가 있음 에이전트형 시스템의 핵심은 에이전트를 쓰는 것이 아니라, 정말 필요할 때만 쓰는 데 있다고 봄. 작동하는 시스템에는 다단계 흐름을 표현하는 파이프라인/레시피 , 여러 에이전트 작업자 풀에서 모델과 사람 개입 단계를 안정적으로 실행하는 운영 체계, 가능한 많은 일을 코드로 처리하는 두꺼운 스킬의 관리·배포·보안·권한, 적절한 세션에 적절한 맥락을 넣는 맥락 관리가 필요함 그 외에도 티켓·의존성·진척·멈춘 티켓 재시작을 다루는 프로젝트 관리, 대화 기록 저장과 메모리·꿈꾸기·누적 학습 기능, 비용과 사용량을 보는 관측성, 프롬프트 평가와 자동 조정, 모델 제공자 교체와 모델 버전 고정, 실제 세션을 돌릴 샌드박스가 필요함 한 공급자에게서 전부 받을 필요는 없지만, 대부분의 경우 단일 모델 제공자에 갇히지 말고, 자기 맥락 과 누적 학습 은 직접 소유해야 한다고 봄 대부분의 에이전트 프레임워크에서 가장 심각한 부분은 핵심 로직을 가리는 것 임. 실제 언어 모델에 무엇이 보내지고 무엇이 돌아오는지 명확히 보여야 함 에이전트형 애플리케이션의 모든 것은 결국 토큰 시퀀스나 제공자 호출로 실현되므로, 앱의 거의 모든 계층에서 그 모습이 분명해야 함 수십 개의 프런트엔드 프레임워크에도 비슷한 생각을 했음. 미래에 올 것 같지만 오지 않을 보상을 위해 거대한 추상화와 복잡도 를 떠안기는 식임 그래도 사람들은 할 일이나 재미있는 장난감이 필요하고, “다음 사람”은 대개 그리 중요하게 여겨지지 않으니, 유급 놀이 시간의 결과물을 떠넘겨도 상관없다고 여기는 듯함 특정 에이전트에 맞춘 1:1 코드 를 만드는 방식에는 어느 정도 동의함. 다만 새 에이전트에서 새 기법이나 방식을 만들었을 때, 오래된 에이전트를 어떻게 업데이트할지와 업데이트하고 싶은지가 유지보수 측면에서 고민됨 예를 들어 Apache Burr가 플러그인 가능한 벡터 RAG 시스템을 지원하거나 앞으로 지원할 것 같지만, 필요한 것은 문서를 맥락에 추가하고 업데이트된 시스템 프롬프트의 일부로 유지하면서 그 과정에 아주 구체적인 조정을 넣는 방식임. 기존 개념인 RAG를 맞춤형으로 쓰는 방식이라 특정 프레임워크와 잘 맞지 않음 내 용도에서는 맞춤 구현이 맞지만, 오래된 에이전트를 갱신하기 위한 엔지니어링 선택은 여전히 남아 있음 프레임워크의 장점은 실제 에이전트 작성이 쉬워지는 데 있는 게 아니라 도구와 관측성 등에 있음. LangChain도 비판받을 점은 많지만, 이 점은 초기에 아주 분명히 보여줬음 챗봇을 처음부터 직접 만드는 건 쉽거나 더 쉬울 수 있지만, 관측성이나 추적을 추가해야 하면 이야기가 달라짐. 환경 변수 하나만 추가해서 모든 추적을 UI에서 거의 추가 작업 없이 훑어볼 수 있다면, 직접 만든 해법은 경쟁하기 어려움 이 페이지가 https://vorpus.github.io/performativeUI/ 로 만든 건지 궁금함 AI 생성 랜딩 페이지 의 전형적인 클리셰를 가능한 한 전부 밟고 있음. 아니면 일부러 풍자한 건가 싶음 개인 프로젝트와 업무 프로젝트에서 이 프레임워크를 즐겨 쓰고 있음. AI 모델을 위한 신뢰할 수 있는 상태 있는 워크플로 와 무료 관측성을 얻을 수 있어서 좋았음 Burr 상태 기계를 MCP로 마운트하는 도구를 엮었고, 에이전트에게 따라갈 레일을 주면서 상태 기계가 아무리 복잡해져도 MCP 도구는 상태 기계 탐색으로 제한됨: https://github.com/msradam/theodosia 지금은 스킬을 상태 기계로 변환하는 작업을 하고 있음. 인기 있는 많은 스킬이 이미 AI 모델이 따라갈 단계 형태로 작성되어 있어서, Burr의 명시적 기능을 활용하면 더 안정적으로 만들 수 있을 듯함 https://strandsagents.com/ 와 비교하면 어떤지 궁금함. 이 영역의 도구에 관심이 있고 아직 특정 도구에 묶여 있지는 않지만, Bedrock + Serverless on Agent Core 가 “쉬운 안내 경로”처럼 느껴짐. 다만 플랫폼 종속은 마음에 들지 않음 다른 사용 경험이 궁금함. 이 스택을 써보고 있는데 Strands가 Agent Core와 함께 특별한 비법을 제공하는지 의문이 남음 지금까지는 그렇게 느껴지지 않고, 때로는 둘이 서로 충돌하는 것처럼 보이기도 함 여기서는 빌더 패턴 과 데코레이터가 보임. Python에도 데코레이터가 있지만, 함수나 메서드에 적용하는 “필터”로 쓰는 게 가장 적절하다고 봄. 이 함수는 캐시하고, 이 함수의 출력은 항상 직렬화하고, 이 함수를 에이전트형 실행 장치의 도구로 준비하는 식임 등록이나 흐름 제어에 쓰는 것은 아니라고 봄. 동의하지 않을 수도 있지만 누군가는 말해야 함. FastAPI가 현대적인 데코레이터 사용을 너무 많이 잘못된 방향으로 끌고 갔음 빌더 패턴은 Rust에 이름 있는 키워드 인자가 없어서 생긴 관례에 가깝고, Python 함수는 이미 이름 있는 계약을 노출함. 설정 매개변수를 연쇄 메서드 호출로 순서대로 넘길 이유는 거의 없음 생성자나 팩토리에 아직 없는 상태를 추가해야 한다면 그건 빌더 패턴이 아니라 등록임. 빌더 패턴을 용인할 만한 곳은 질의 빌더 정도임. 개념을 반복적으로 쌓아 올리고, 메서드 이름과 키워드 인자라는 메타데이터 슬롯이 실제로 유용하기 때문임. 키워드 인자 대신 단일 매개변수를 받는 메서드를 쓰는 것은 잘못됐다고 봄 여기서 데코레이터는 구체적으로 함수에 메타데이터를 붙여 재사용 가능한 구성요소 로 만들고, 빌더는 워크플로를 만듦. Hamilton에서는 순수 선언적 구성이라 전부 데코레이터로 처리하지만, 재사용성은 사실상 별도 문제임 빌더 패턴이 Rust에서만 쓰이는 건 아니지만, Python에서 쓰기에는 흉하다는 데 동의함 신뢰할 수 있는 AI 에이전트가 무엇인지에 대해 꽤 순진한 버전처럼 보임 신뢰성은 “맡긴 일을 끝낼 수 있는가”를 뜻하지, 상태 기계 와는 딱히 관련이 없음 Burr는 처음 들어보는데, 왜 Apache에서 인큐베이션됐는지 궁금함 안 될 이유가 없음. ASF는 새로운 자유 오픈소스 프로젝트를 인큐베이션해 온 긴 역사가 있음 일부는 졸업해서 누구나 아는 이름이 되고, 일부는 실패해서 attic으로 감. ASF는 조직적 지원을 제공하고 대체로 좋은 공동체를 키워 줌 내가 제출했기 때문임. Apache 절차를 배우고 다른 일도 병행하느라 느린 과정이었지만, 이제는 어느 정도 동력 이 생겼고 더 정기적인 릴리스를 시작하고 있음 페이지가 Claude Code로 만든 일회용 쓰레기처럼 보이고, JavaScript 없이 동작하려는 시도조차 안 함. 적어도 브랜드 일관성 은 있음 이름의 명시적인 근거는 못 찾았지만, 궁금한 사람을 위해 Hamilton 예제가 있음: https://github.com/apache/burr/tree/main/examples/multi-agen... Burr는 미국 건국의 아버지이자 제3대 부통령, 그리고 Alexander Hamilton의 살해자이자 숙적인 Aaron Burr 에서 따온 이름임 Hamilton과의 연결점은 DAGWorks가 Hamilton 라이브러리 다음으로 공개한 두 번째 오픈소스 라이브러리라는 데 있음. Burr와 Hamilton이 조화를 이루고 차이를 넘어 더 나은 연방을 만들었다면 어땠을지 상상한 이름임 원래 Burr는 Hamilton DAG 실행 사이의 상태를 다루는 장치로 만들었음. DAG에는 순환이 없기 때문임. 이후 적용 범위가 넓다는 걸 깨닫고 더 넓게 공개했음 https://pypi.org/project/burr/ 코딩 에이전트 오케스트레이션 도구나 플랫폼 중 추천할 만한 것이 있는지 궁금함. 여러 머신에서 codex나 claude 에이전트를 실행·관리·모니터링하고 싶음 가능하면 자체 호스팅 가능하거나 오픈소스면 좋겠음. claude code가 내부적으로 그런 기능을 많이 갖고 있는 건 알지만, claude 전용임 문서를 보니 Burr에는 이걸 시작할 수 있는 에이전트 쿡북이 있고, 여러 머신 워크플로 도 처리할 수 있음. 찾던 게 이게 아닌지 궁금함 스킬 등과 어떻게 통합해서 쓰는지는 확실하지 않지만, 보기에는 동작할 것 같음 https://burr.apache.org/docs/examples/agents/
에이전트 프레임워크는 아직 판단을 유보 중이고, 에이전트 성격에 따라 쓸모가 달라짐. 예를 들어 3초 안에 충분히 괜찮은 응답 을 돌려줘야 하는 경우와, 한 문제를 3시간 동안 풀어야 하는 경우는 다름 결국 에이전트는 맥락 구성, LLM 호출, 요청된 도구 호출 실행, 최종 모델 출력 파싱, 프런트엔드 반환으로 압축됨. 메모리나 비동기 도구 호출 같은 확장은 있지만 전통적인 소프트웨어 엔지니어링 관점에서는 그렇게 복잡하지 않음 모두가 자기 에이전트 프레임워크를 만들고 싶어 하지만, 특정 에이전트를 만들어야 한다면 그 에이전트에 맞춘 1:1 코드 가 훨씬 쉽고 유지보수도 낫다고 봄. 프레임워크의 추상화는 핵심 로직을 가리고 방해하는 경우가 많고, 결국 프레임워크가 고른 추상화에 맞춰야 해서 실제 목표와 어긋날 때가 있음
이 페이지가 https://vorpus.github.io/performativeUI/ 로 만든 건지 궁금함 AI 생성 랜딩 페이지 의 전형적인 클리셰를 가능한 한 전부 밟고 있음. 아니면 일부러 풍자한 건가 싶음
개인 프로젝트와 업무 프로젝트에서 이 프레임워크를 즐겨 쓰고 있음. AI 모델을 위한 신뢰할 수 있는 상태 있는 워크플로 와 무료 관측성을 얻을 수 있어서 좋았음 Burr 상태 기계를 MCP로 마운트하는 도구를 엮었고, 에이전트에게 따라갈 레일을 주면서 상태 기계가 아무리 복잡해져도 MCP 도구는 상태 기계 탐색으로 제한됨: https://github.com/msradam/theodosia 지금은 스킬을 상태 기계로 변환하는 작업을 하고 있음. 인기 있는 많은 스킬이 이미 AI 모델이 따라갈 단계 형태로 작성되어 있어서, Burr의 명시적 기능을 활용하면 더 안정적으로 만들 수 있을 듯함
https://strandsagents.com/ 와 비교하면 어떤지 궁금함. 이 영역의 도구에 관심이 있고 아직 특정 도구에 묶여 있지는 않지만, Bedrock + Serverless on Agent Core 가 “쉬운 안내 경로”처럼 느껴짐. 다만 플랫폼 종속은 마음에 들지 않음
여기서는 빌더 패턴 과 데코레이터가 보임. Python에도 데코레이터가 있지만, 함수나 메서드에 적용하는 “필터”로 쓰는 게 가장 적절하다고 봄. 이 함수는 캐시하고, 이 함수의 출력은 항상 직렬화하고, 이 함수를 에이전트형 실행 장치의 도구로 준비하는 식임 등록이나 흐름 제어에 쓰는 것은 아니라고 봄. 동의하지 않을 수도 있지만 누군가는 말해야 함. FastAPI가 현대적인 데코레이터 사용을 너무 많이 잘못된 방향으로 끌고 갔음 빌더 패턴은 Rust에 이름 있는 키워드 인자가 없어서 생긴 관례에 가깝고, Python 함수는 이미 이름 있는 계약을 노출함. 설정 매개변수를 연쇄 메서드 호출로 순서대로 넘길 이유는 거의 없음 생성자나 팩토리에 아직 없는 상태를 추가해야 한다면 그건 빌더 패턴이 아니라 등록임. 빌더 패턴을 용인할 만한 곳은 질의 빌더 정도임. 개념을 반복적으로 쌓아 올리고, 메서드 이름과 키워드 인자라는 메타데이터 슬롯이 실제로 유용하기 때문임. 키워드 인자 대신 단일 매개변수를 받는 메서드를 쓰는 것은 잘못됐다고 봄
신뢰할 수 있는 AI 에이전트가 무엇인지에 대해 꽤 순진한 버전처럼 보임 신뢰성은 “맡긴 일을 끝낼 수 있는가”를 뜻하지, 상태 기계 와는 딱히 관련이 없음
Burr는 처음 들어보는데, 왜 Apache에서 인큐베이션됐는지 궁금함
페이지가 Claude Code로 만든 일회용 쓰레기처럼 보이고, JavaScript 없이 동작하려는 시도조차 안 함. 적어도 브랜드 일관성 은 있음
이름의 명시적인 근거는 못 찾았지만, 궁금한 사람을 위해 Hamilton 예제가 있음: https://github.com/apache/burr/tree/main/examples/multi-agen...
코딩 에이전트 오케스트레이션 도구나 플랫폼 중 추천할 만한 것이 있는지 궁금함. 여러 머신에서 codex나 claude 에이전트를 실행·관리·모니터링하고 싶음 가능하면 자체 호스팅 가능하거나 오픈소스면 좋겠음. claude code가 내부적으로 그런 기능을 많이 갖고 있는 건 알지만, claude 전용임
발행일: 2026-06-12 08:23 (금)
한국어 KR 영어 EN 일본어 JP 중국어 CH
금융권과 스타트업 간 실질적인 협업 사례를 조명하고, 시상과 후속 사업 기회까지 연결하는 자리가 마련된다.
디캠프(대표 박영훈)는 한국핀테크지원센터와 이달 24일 디캠프 마포에서 ‘스타트업 OI #금융권’ 행사를 연다고 밝혔다.
이번 행사에는 9대 1의 경쟁률을 뚫고 선발된 ▲고이장례연구소 ▲테라파이 ▲티냅스 ▲왓섭 ▲웰로 5개 스타트업이 금융기관 측 협업 담당자와 함께 무대에 오른다. 각 팀은 협력 과정에서의 문제 해결 과정과 데이터·기술 기반의 시너지, 사업 성과, 향후 협력 비전을 발표한다.
고이장례연구소는 원스톱 장례 플랫폼 ‘고이’를 통해 월 100원부터 시작하는 장례 준비 서비스를 제공 중이다. OK저축은행과 협업해 최고 연 4% 금리와 상조 혜택을 결합한 ‘OK이자도받는상조적금’을 출시하며 장례 서비스의 금융 연계 모델을 확장한 사례를 발표한다.
테라파이는 부동산 계약 전 리스크를 데이터 기반으로 분석하는 ‘안심등기 Decision OS’를 개발한 프롭테크 기업이다. 전세 계약 전 주택 상태를 확인할 수 있는 ‘세이프홈즈’ 서비스를 기반으로, 금융기관이 활용 가능한 부동산 리스크 데이터 구조화 사례를 우리은행과 소개한다.
AI 에이전트 신뢰성 검증 스타트업 티냅스는 금융 AI 답변의 신뢰성을 검증하는 솔루션을 제공하는 기업이다. AI가 생성한 답변을 업무 기준에 따라 통과·차단·재검토로 분류하는 기술을 바탕으로, KB국민은행과 협력해 AI 활용 과정에서 발생할 수 있는 리스크를 사전에 점검하는 사례를 발표한다.
왓섭은 결제 및 가맹점 데이터를 소비 항목과 행동 패턴 중심으로 구조화하는 AI 기반 데이터 인프라를 개발했다. 이를 통해 금융사의 초개인화 마케팅과 AI 서비스 고도화를 지원하며, 신한카드와의 협업 사례를 공유할 예정이다.
웰로는 정부 정책 및 지원금 데이터를 수집·정제해 개인과 기업에 맞춤형으로 추천하는 데이터 플랫폼을 운영 중이다. 이 회사는 카카오뱅크와 협력해 정책 데이터와 금융 서비스 간 연계를 강화한 사례를 선보인다.
'변화'냐 '변질'이냐...디캠프 내부 갈등 격화 2026.06.02 강 건너 디캠프 불구경 하는 은행연합회의 ‘사소한 침묵’ 2026.06.02 스타트업 파트너 디캠프... '배치' 누적 지원수 4000건↑ 2026.06.04 디캠프-JR동일본, 국내 스타트업 일본 진출 돕는다 2026.05.13
발표 종료 후 최우수 사례에는 금융위원장상이, 우수 사례에는 은행연합회장상(디캠프 이사장상)과 한국핀테크지원센터 이사장상이 각각 수여된다. 아울러 공공성과 포용성이 높은 협력 사례를 선정해 상생 협력상(지역금융그룹회장상, BNK금융그룹 회장상)을 별도로 수여 하며, 총 1천만원 규모의 상금이 스타트업과 금융기관 담당자에게 공동으로 제공된다.
본선 진출 스타트업에게는 ▲디캠프 배치 프로그램 선발 검토 ▲금융권 사업 협력 및 투자 연계 기회 ▲한국핀테크지원센터 기술실증(PoC) 지원 사업 연계 등 후속 지원도 이뤄진다.
소프트웨어 해커톤이여 안녕. 하드웨어 해커톤이여 영원하라 (blog.oscars.dev)
48시간 해커톤에서 오래된 회전식 전화기에 Raspberry Pi 를 연결해 양방향 오디오, 벨, 수화기 스위치를 서버와 연동하는 데모를 구현함 데모는 AI 에이전트 가 음악을 조사하고 Spotify API로 재생목록을 만들며, 사용자의 음악 요청을 처리하도록 구성 참가자 두 명은 주말 내내 코드 한 줄도 보지 않았고, 해커톤에서는 내부 코드보다 작동 여부 가 중요해졌다고 봄 코드 작성보다 전체 시스템 설계와 구현 세부 조정에 집중하게 되면서, 하드웨어와 물리 세계의 인터페이스를 다룰 정신적 여유가 생김 웹 앱만으로는 해커톤의 도전성이 약해졌고, 오래된 기술과 소비자 전자제품을 엮는 하드웨어 해커톤 이 더 두드러질 것이라고 봄 회전식 전화기 해커톤 데모 Vilnius에서 열린 해커톤에서 오래된 회전식 전화기 를 가져와 2인 팀이 48시간 동안 작업함 전화기에는 Raspberry Pi를 연결했고, Raspberry Pi는 전화기의 입출력과 연동하며 서버와 단일 WebSocket 연결로 통신함 WebSocket 연결은 양방향 오디오, 맞춤 주파수와 오디오 패턴을 가진 벨, 수화기 내려놓기 스위치를 제어함 최종 데모는 AI 에이전트가 음악을 조사하고, 재생목록을 만들고, Spotify API를 통해 특정 음악 모음을 재생하도록 구성됨 요청 예시는 “Epstein files에 오른 것으로 알려진 아티스트의 음악을 틀어줘”, “70년대 잠비아 사이키델릭 록 재생목록을 만들어줘” 등이었음 전화 반대편의 성격은 ElevenLabs를 통해 따뜻한 Yorkshire 신사처럼 설정됨 해커톤의 초점 변화 최근 코드 작성 흐름의 변화 속에서 참가자 두 명 모두 주말 내내 코드 한 줄도 직접 보지 않음 12개월 전에는 상상하기 어려웠던 방식이 현재 현실이 되었고, 해커톤에서는 결과물이 작동 하는지가 핵심이 됨 해커톤의 초점은 잠을 줄이고 손가락이 아프도록 코드를 치는 방식에서, 시스템 전체를 사고 하는 방식으로 이동함 구현 세부를 반복하고 급진적으로 리팩터링하는 작업이 사소한 일이 되면서, 하드웨어와 물리 세계의 접점을 다룰 여지가 커짐 24개월 전에는 훌륭한 성취였을 수 있는 웹 앱도 이제 평범해졌고, 해커톤의 기준을 더 밀어 올릴 방법은 하드웨어 임 앞으로 몇 달 동안 이전보다 하드웨어 해커톤 에 더 큰 강조가 생길 것이라고 예상함 오래된 기술은 예전에는 매우 좁고 시간이 많이 드는 도메인 지식이 필요했지만, 다시 실험 대상으로 부활할 수 있음 예를 들어, Apple II용 괴상한 앱, 팩스기를 소셜 미디어 네트워크로 바꾸기, Game Boy Advance를 Bloomberg terminal로 바꾸기, 사랑과 고통을 느낄 수 있는 LLM 기반 금전등록기, AI 음성 활성화 전자레인지 등이 있음 이런 프로젝트에는 정상적인 비즈니스 사례가 없을 수 있지만, 해커톤은 다소 터무니 없어야 함 VC 피칭이나 해결하려는 문제를 보고 싶지 않으며, 전선과 API로 이루어진 과도하게 만들어진 기괴한 구조물 을 보고 싶음 breadboard 위에 구현된 hubris(오만)의 현현 , 현실을 의심하게 만드는 frankenstein식 가전제품과의 결합을 지향
함께 보면 좋은 글 β 취향(Taste)이 새로운 10x다 취향(taste)을 갖춘 30배 AI 엔지니어가 되는 법 AI 록스타 개발자들의 뒷정리 AI 시대, 가장 가치 있는 개발자는 장인이면서 빌더인 사람이 될 것 AI 코드와 소프트웨어 장인정신
취향(taste)을 갖춘 30배 AI 엔지니어가 되는 법
AI 시대, 가장 가치 있는 개발자는 장인이면서 빌더인 사람이 될 것
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
인증 이메일 클릭후 다시 체크박스를 눌러주세요
▲ GN⁺ 21시간전 [-] Hacker News 의견들 여러 사정을 보면 말이 됨. 해커톤은 몇 번만 나가봤는데, 2022년쯤 Amsterdam에서의 경험이 제일 좋았음. 팀 절반은 자러 갔고, 나와 한 명은 200명쯤 있는 행사장에 밤새 갇혀서 뭔가를 만들며 최적화, 꼼수, 거의 불가능한 문제에 대한 반쯤 억지 해법을 찾느라 머리를 싸맸음 최근 몇 년 사이 흥미를 잃었고, 이제는 다시 나갈 일은 없을 듯함. 최근 끝난 해커톤 메일을 받았는데, 우승자가 AI 엔지니어 팀 같은 걸 만들었다고 했고 발표물은 skills.md 같은 Markdown 헛소리 파일 20개였음. 글만 그럴듯하게 쓰면 금메달인가 싶었고, 친구 말처럼 “바닥을 찍고 이제 바닥을 뚫고 들어가는” 느낌임. 적어도 하드웨어는 실제로 뭔가를 만들고 머리를 써야 함 대부분의 해커톤은 오래전부터 그랬음. 주말 내내 까다로운 데이터 분류 문제 를 붙잡고 있었지만 진전은 없었고, 우승자들은 그럴듯한 발표 슬라이드와 CRUD 앱을 포장한 30초 코드 데모를 들고 나왔음 10년 전 원치 않게 참가한 유일한 해커톤에서 우승했음. 심사위원들은 보고서의 AI 섹션 에 특히 감탄했는데, 그 부분은 “미래에는 시스템이 이것저것 해야 한다”는 식으로 당시 유행하던 알고리즘 몇 개를 인용한 기술 허세에 가까웠음 데모에는 어떤 형태로도 구현되지 않았지만, 내가 무슨 말을 하는지 아는지만 확인했고 자신 있게 말하는 것만으로 충분했음. 우리는 우승이 아니라 그냥 통과 점수를 받으려고 했을 뿐임 안타깝게도 하드웨어도 오래가지는 않을 것 같음. 하드웨어를 이해하지 못한 채 LLM으로 하드웨어 개발 을 해보려는 사람이 많아지고 있음 “Markdown 파일 20개가 금메달감이냐”는 질문에는 그렇다고 봄. 길에 나무가 쓰러져 있을 때 한 사람은 자율 로봇을 만들어 치우고, 다른 사람은 그냥 가서 옮긴다면 “멍청한” 쪽이 이김 지금은 Markdown 파일 몇 개가 전문가들이 수백 시간을 들여 만든 전용 해법보다 문제를 더 잘 푸는 역사적 시점에 와 있음. 승패는 투입한 노력량이 아니라 결과 로 결정됨 해커톤은 “멋진 UI와 목업 데이터” 대회가 됐음. 팀에 가장 좋은 UI 담당자 가 있는 쪽이 이겼고, 나도 몇 번 그 덕을 봤음 회사 내부 해커톤에서 비슷한 일을 겪었음. LLM 이전이었음. 어떤 문제를 잡고 내부 도구를 설계한 뒤 Bootstrap UI와 화려한 CSS 애니메이션을 얹었음 목업 데이터를 연결하니 꽤 진짜처럼 보였고, 우리는 우승해서 임원진의 축하를 받았음. 곧바로 “이걸 1주 안에 프로덕션에 올릴 수 있느냐, 아니면 2주가 필요하냐”는 질문을 받았음 심사위원은 보통 기술력이 평범한 관리자들임 몇 년 전 LLM 이전에 참가한 해커톤에서 전통적인 기계학습 알고리즘 을 학습시키고 React Native 앱에 통합하는 데 상당한 노력을 들였음. 2016년 기준으로 그게 가능했던 팀도 꽤 인상적이었음 우승팀은 35달러짜리 Bootstrap 테마를 사서 존재하지 않는 앱의 랜딩 페이지를 만들었음 PowerPoint 발표가 우승하는 걸 본 뒤, 그게 마지막 해커톤이 됐음 나머지 절반은 결국 피치 가 전부임 해커톤은 괜찮다고 봄. 내가 약한 것들, 즉 피치 , 눈 맞추기, 설득력 있는 이야기 만들기, 청중 끌어들이기를 전부 요구함. 나는 이런 걸 정말 못함 사람들이 내 고통을 느끼게 하거나 빠르게 효과적으로 전달하는 데 형편없음. 지금 해커톤은 거의 이것뿐이고, 내 핵심 약점을 드러내는 훈련장이 됐기 때문에 경력 25년 차에도 거의 매주말 나가고 있음. 정말 나아져야 하는 영역이고, 드디어 조금씩이지만 검증 가능하게 좋아지고 있음 이 문제를 나는 trailhead 라고 부름. 문제의 길 깊숙이 들어가면 출발점에서 어떻게 보였는지를 잊어버리고, 그래서 잘못된 세부 수준과 잘못된 측면에 시간을 쓰다가 제품을 설득하지 못함. 그래서 자기 것보다 남의 것을 더 잘 피치할 수 있음 공감됨. 이게 자신감 문제 에 더 가까운지 궁금함. 공격하거나 깎아내리려는 뜻은 아니고, 자기 진단과 인식 관점에서 궁금함 나도 가끔 비슷하게 느끼는데, 관심과 열정의 자리에서 다시 프레임을 잡고 성과 압박과 불안을 내려놓은 채 다른 사람에게 공유하면 보통 완전히 형편없게 보이진 않음 90년대 초에 Linux와 오픈소스에 입문한 입장에서, 해커톤 이 “다 같이 모여 자유 소프트웨어를 협업해서 만들자”가 아니라 경쟁 활동으로 변해버린 게 늘 아쉬움. 요즘은 후자를 “개발 스프린트”라고 부르는 것 같지만, 해커톤이라는 말을 들으면 항상 그게 먼저 떠오름 어릴 때 다녔던 해커톤은 꽤 열려 있고 협력적이었음. 최근 참가한 해커톤은 AWS, GCP, Vercel 같은 클라우드 인프라 를 쓰게 만드는 수단에 가까움 더 최근에는 이미 완성된 제품을 들고 와서 해킹은 하지 않고 VC 미팅에 참석하는 팀들도 있음. 잘 만든 완성품으로 당연히 우승하고, 미디어 발표를 리드 생성에 활용함. 48시간 전에 모인 팀이 설계하고 만든 내 덕트테이프와 골판지 해킹은 보기엔 별로 좋아 보이지 않음 혼자가 아님. MBA들이 API를 발견했음. Eternal September 같은 일임 동의함. 해커톤에서 “우승”한다는 발상 자체가 꽤 이상하게 느껴짐. 이길 수 있는 종류의 것이 아니어야 할 것 같음 KDE는 Akademy 기간에, LibreOffice도 컨퍼런스 마지막 날에 그런 행사를 아직 하는 것 같음 2023년에 LibreOffice 행사에 갈 기회가 있었지만 생활 일이 겹쳐 아쉽게 놓쳤음 사실상 기업이 후원하거나 조직한 해커톤은 여러 채용 과제 를 병렬로 돌리는 것과 비슷함. 원래 돈을 주고 해결해야 할 문제에 대해 공짜로 많은 작업을 얻고, 그중 마음에 드는 결과를 고를 수 있음. 너무 착취적이라 한 번도 참가하고 싶지 않았음 글쓴이는 속도가 중요하고 버그가 용인되며 데모만 평가받는 해커톤에서 바이브 코딩 이 코딩을 완전히 대체했다고 보는데, 여기에 동의함 하지만 그래서 소프트웨어가 “해결”됐고 하드웨어 해커톤만 의미 있다는 결론은 왜 나오는지 모르겠음. 오히려 소프트웨어 해커톤은 아이디어가 더 중요해졌기 때문에 더 유용해졌다고 봄. 아이디어가 싸졌다고 해도, 창의성을 자극하는 공간에서 더 나은 세부 사항을 떠올리며 24~72시간을 프로토타입에 쓸 수 있는 사람은 모두가 아님 소프트웨어도 해결된 게 아님. 특히 심사위원이 어느 정도 기능성을 요구한다면, 어떤 아이디어는 여전히 프로토타입으로 옮기기 위해 저수준 지식과 기술 이 필요함. 해커톤의 목적이 나중에 제품으로 다시 만들 프로토타입이든, 투자자 유치용 프로토타입이든, 회사 관련 아이디어 발굴이든, 그냥 재미와 무료 음식과 좋은 사람들을 즐기는 것이든 말임 AI는 하드웨어를 못 하기 때문임. 납땜을 할 수 없고, 빨간 LED를 파란 LED로 바꾸고 최적 밝기를 위한 전류 제한 저항 을 찾을 수 없음 인클로저의 어느 부분을 잘라야 하는지도 볼 수 없고, LDO의 기동 과도 현상도 볼 수 없음 Hack Club에서는 지난 2년간 청소년들이 전자공학에 입문하고 직접 PCB를 설계 하도록 돕는 데 큰 투자를 해왔음 속이기 훨씬 어렵고, 특히 초보자에게는 소프트웨어보다 훨씬 더 흥미로운 경우가 많음. 최근 GitHub HQ 행사 영상도 볼 만함: https://youtu.be/kaEFv7e49mo?si=sLer815jCJIyWR9Y 곧 Hack Club Fallout이라는 행사를 열 예정이고, 미국과 전 세계의 고등학생들을 Shenzhen으로 데려가 7일간 해커톤을 진행함. 당일 PCB 제작이 가능한 몇 안 되는 곳 중 하나이기 때문임: https://fallout.hackclub.com 대학 시절 내 해커톤 프로젝트는 거의 전부 하드웨어 였음 예를 들면 HackPrinceton에서 만든 것들인데, 여기는 전기전자 실험실이 가장 좋았음. https://blog.cyrusroshan.com/post/electronic-banjo 는 관중 인기상을 받았고, https://blog.cyrusroshan.com/post/spin-to-win 는 “문샷” 아이디어였음 자기가 만든 것을 손에 쥘 수 있다는 건 꽤 좋음. 만질 수 있는 결과물 은 설명하기도 쉽고 속이기도 어려움. 그래서 하드웨어 쪽으로 가는 게 재미있고 보람 있었으며 점수도 잘 받았음. 좋은 시절이었음 컨퍼런스 쪽도 크게 나을 게 없음 몇 달 전 마지못해 하나에 갔는데 정말 충격받았음. 이틀짜리였고, 프로그래밍 언어 이름은 굳이 말하지 않겠음. 이제는 별 의미도 없을 것 같은데, 발표 중 순수하게 프로그래밍에 관한 것은 많아야 20% 정도였음 스스로를 업계 챔피언이라 부르는 작은 무리가 차례로 무대에 올라 자신들의 성스러움과 커뮤니티를 위해 했다는 뛰어난 일을 설교했는데, 그 영역은 소프트웨어 공학과 Iceland가 Indian Ocean에 접해 있는 정도로만 관련 있었음 강연 또 강연이었고, 생활양식이었고, 덕 과시 였고, 프로그래밍만 아니었음. 억지로 끼워 넣은 워크숍 하나는 기본도 제대로 쌓을 시간이 없었고, 개인적으로 영웅처럼 여기던 사람은 내부 패키지 관리자 드라마를 이야기하러 나왔음. 다음! 다시는 안 감. 뿌리까지 다 썩었음 요즘 그 생각을 하고 있었음. 이제 소프트웨어가 대부분의 아이디어 제안자 손에 닿는 곳까지 왔으니, 훨씬 깊은 수준의 손작업과 실험 이 가능해짐 느리긴 해도 매우 저렴한 3D 프린터와 풍부한 하드웨어 인터페이스 덕분에, 주말 프로젝트에서 출발해 “왜 지금까지 없었지” 싶은 아름다운 유틸리티가 세상에 많이 나올 것 같음. 소프트웨어 엔지니어와 팀들이 다음 단계의 제품 제작자로 변해가는 모습을 보는 게 기대됨 내 남동생은 해변 구조요원인데, 지난 1년 동안 놀라운 프로젝트들을 엄청나게 만들어냈음. 뭔가 해방된 느낌임. 정말 멋진 시대임 마지막으로 갔던 해커톤에서 우리 팀은 PowerPoint 발표 만 만든 팀에게 졌음. 더는 그런 걸 하고 싶지 않음 그런데 어떻게? 그 PowerPoint가 그렇게 흥미로웠나? 답변달기
Hacker News 의견들 여러 사정을 보면 말이 됨. 해커톤은 몇 번만 나가봤는데, 2022년쯤 Amsterdam에서의 경험이 제일 좋았음. 팀 절반은 자러 갔고, 나와 한 명은 200명쯤 있는 행사장에 밤새 갇혀서 뭔가를 만들며 최적화, 꼼수, 거의 불가능한 문제에 대한 반쯤 억지 해법을 찾느라 머리를 싸맸음 최근 몇 년 사이 흥미를 잃었고, 이제는 다시 나갈 일은 없을 듯함. 최근 끝난 해커톤 메일을 받았는데, 우승자가 AI 엔지니어 팀 같은 걸 만들었다고 했고 발표물은 skills.md 같은 Markdown 헛소리 파일 20개였음. 글만 그럴듯하게 쓰면 금메달인가 싶었고, 친구 말처럼 “바닥을 찍고 이제 바닥을 뚫고 들어가는” 느낌임. 적어도 하드웨어는 실제로 뭔가를 만들고 머리를 써야 함 대부분의 해커톤은 오래전부터 그랬음. 주말 내내 까다로운 데이터 분류 문제 를 붙잡고 있었지만 진전은 없었고, 우승자들은 그럴듯한 발표 슬라이드와 CRUD 앱을 포장한 30초 코드 데모를 들고 나왔음 10년 전 원치 않게 참가한 유일한 해커톤에서 우승했음. 심사위원들은 보고서의 AI 섹션 에 특히 감탄했는데, 그 부분은 “미래에는 시스템이 이것저것 해야 한다”는 식으로 당시 유행하던 알고리즘 몇 개를 인용한 기술 허세에 가까웠음 데모에는 어떤 형태로도 구현되지 않았지만, 내가 무슨 말을 하는지 아는지만 확인했고 자신 있게 말하는 것만으로 충분했음. 우리는 우승이 아니라 그냥 통과 점수를 받으려고 했을 뿐임 안타깝게도 하드웨어도 오래가지는 않을 것 같음. 하드웨어를 이해하지 못한 채 LLM으로 하드웨어 개발 을 해보려는 사람이 많아지고 있음 “Markdown 파일 20개가 금메달감이냐”는 질문에는 그렇다고 봄. 길에 나무가 쓰러져 있을 때 한 사람은 자율 로봇을 만들어 치우고, 다른 사람은 그냥 가서 옮긴다면 “멍청한” 쪽이 이김 지금은 Markdown 파일 몇 개가 전문가들이 수백 시간을 들여 만든 전용 해법보다 문제를 더 잘 푸는 역사적 시점에 와 있음. 승패는 투입한 노력량이 아니라 결과 로 결정됨 해커톤은 “멋진 UI와 목업 데이터” 대회가 됐음. 팀에 가장 좋은 UI 담당자 가 있는 쪽이 이겼고, 나도 몇 번 그 덕을 봤음 회사 내부 해커톤에서 비슷한 일을 겪었음. LLM 이전이었음. 어떤 문제를 잡고 내부 도구를 설계한 뒤 Bootstrap UI와 화려한 CSS 애니메이션을 얹었음 목업 데이터를 연결하니 꽤 진짜처럼 보였고, 우리는 우승해서 임원진의 축하를 받았음. 곧바로 “이걸 1주 안에 프로덕션에 올릴 수 있느냐, 아니면 2주가 필요하냐”는 질문을 받았음 심사위원은 보통 기술력이 평범한 관리자들임 몇 년 전 LLM 이전에 참가한 해커톤에서 전통적인 기계학습 알고리즘 을 학습시키고 React Native 앱에 통합하는 데 상당한 노력을 들였음. 2016년 기준으로 그게 가능했던 팀도 꽤 인상적이었음 우승팀은 35달러짜리 Bootstrap 테마를 사서 존재하지 않는 앱의 랜딩 페이지를 만들었음 PowerPoint 발표가 우승하는 걸 본 뒤, 그게 마지막 해커톤이 됐음 나머지 절반은 결국 피치 가 전부임 해커톤은 괜찮다고 봄. 내가 약한 것들, 즉 피치 , 눈 맞추기, 설득력 있는 이야기 만들기, 청중 끌어들이기를 전부 요구함. 나는 이런 걸 정말 못함 사람들이 내 고통을 느끼게 하거나 빠르게 효과적으로 전달하는 데 형편없음. 지금 해커톤은 거의 이것뿐이고, 내 핵심 약점을 드러내는 훈련장이 됐기 때문에 경력 25년 차에도 거의 매주말 나가고 있음. 정말 나아져야 하는 영역이고, 드디어 조금씩이지만 검증 가능하게 좋아지고 있음 이 문제를 나는 trailhead 라고 부름. 문제의 길 깊숙이 들어가면 출발점에서 어떻게 보였는지를 잊어버리고, 그래서 잘못된 세부 수준과 잘못된 측면에 시간을 쓰다가 제품을 설득하지 못함. 그래서 자기 것보다 남의 것을 더 잘 피치할 수 있음 공감됨. 이게 자신감 문제 에 더 가까운지 궁금함. 공격하거나 깎아내리려는 뜻은 아니고, 자기 진단과 인식 관점에서 궁금함 나도 가끔 비슷하게 느끼는데, 관심과 열정의 자리에서 다시 프레임을 잡고 성과 압박과 불안을 내려놓은 채 다른 사람에게 공유하면 보통 완전히 형편없게 보이진 않음 90년대 초에 Linux와 오픈소스에 입문한 입장에서, 해커톤 이 “다 같이 모여 자유 소프트웨어를 협업해서 만들자”가 아니라 경쟁 활동으로 변해버린 게 늘 아쉬움. 요즘은 후자를 “개발 스프린트”라고 부르는 것 같지만, 해커톤이라는 말을 들으면 항상 그게 먼저 떠오름 어릴 때 다녔던 해커톤은 꽤 열려 있고 협력적이었음. 최근 참가한 해커톤은 AWS, GCP, Vercel 같은 클라우드 인프라 를 쓰게 만드는 수단에 가까움 더 최근에는 이미 완성된 제품을 들고 와서 해킹은 하지 않고 VC 미팅에 참석하는 팀들도 있음. 잘 만든 완성품으로 당연히 우승하고, 미디어 발표를 리드 생성에 활용함. 48시간 전에 모인 팀이 설계하고 만든 내 덕트테이프와 골판지 해킹은 보기엔 별로 좋아 보이지 않음 혼자가 아님. MBA들이 API를 발견했음. Eternal September 같은 일임 동의함. 해커톤에서 “우승”한다는 발상 자체가 꽤 이상하게 느껴짐. 이길 수 있는 종류의 것이 아니어야 할 것 같음 KDE는 Akademy 기간에, LibreOffice도 컨퍼런스 마지막 날에 그런 행사를 아직 하는 것 같음 2023년에 LibreOffice 행사에 갈 기회가 있었지만 생활 일이 겹쳐 아쉽게 놓쳤음 사실상 기업이 후원하거나 조직한 해커톤은 여러 채용 과제 를 병렬로 돌리는 것과 비슷함. 원래 돈을 주고 해결해야 할 문제에 대해 공짜로 많은 작업을 얻고, 그중 마음에 드는 결과를 고를 수 있음. 너무 착취적이라 한 번도 참가하고 싶지 않았음 글쓴이는 속도가 중요하고 버그가 용인되며 데모만 평가받는 해커톤에서 바이브 코딩 이 코딩을 완전히 대체했다고 보는데, 여기에 동의함 하지만 그래서 소프트웨어가 “해결”됐고 하드웨어 해커톤만 의미 있다는 결론은 왜 나오는지 모르겠음. 오히려 소프트웨어 해커톤은 아이디어가 더 중요해졌기 때문에 더 유용해졌다고 봄. 아이디어가 싸졌다고 해도, 창의성을 자극하는 공간에서 더 나은 세부 사항을 떠올리며 24~72시간을 프로토타입에 쓸 수 있는 사람은 모두가 아님 소프트웨어도 해결된 게 아님. 특히 심사위원이 어느 정도 기능성을 요구한다면, 어떤 아이디어는 여전히 프로토타입으로 옮기기 위해 저수준 지식과 기술 이 필요함. 해커톤의 목적이 나중에 제품으로 다시 만들 프로토타입이든, 투자자 유치용 프로토타입이든, 회사 관련 아이디어 발굴이든, 그냥 재미와 무료 음식과 좋은 사람들을 즐기는 것이든 말임 AI는 하드웨어를 못 하기 때문임. 납땜을 할 수 없고, 빨간 LED를 파란 LED로 바꾸고 최적 밝기를 위한 전류 제한 저항 을 찾을 수 없음 인클로저의 어느 부분을 잘라야 하는지도 볼 수 없고, LDO의 기동 과도 현상도 볼 수 없음 Hack Club에서는 지난 2년간 청소년들이 전자공학에 입문하고 직접 PCB를 설계 하도록 돕는 데 큰 투자를 해왔음 속이기 훨씬 어렵고, 특히 초보자에게는 소프트웨어보다 훨씬 더 흥미로운 경우가 많음. 최근 GitHub HQ 행사 영상도 볼 만함: https://youtu.be/kaEFv7e49mo?si=sLer815jCJIyWR9Y 곧 Hack Club Fallout이라는 행사를 열 예정이고, 미국과 전 세계의 고등학생들을 Shenzhen으로 데려가 7일간 해커톤을 진행함. 당일 PCB 제작이 가능한 몇 안 되는 곳 중 하나이기 때문임: https://fallout.hackclub.com 대학 시절 내 해커톤 프로젝트는 거의 전부 하드웨어 였음 예를 들면 HackPrinceton에서 만든 것들인데, 여기는 전기전자 실험실이 가장 좋았음. https://blog.cyrusroshan.com/post/electronic-banjo 는 관중 인기상을 받았고, https://blog.cyrusroshan.com/post/spin-to-win 는 “문샷” 아이디어였음 자기가 만든 것을 손에 쥘 수 있다는 건 꽤 좋음. 만질 수 있는 결과물 은 설명하기도 쉽고 속이기도 어려움. 그래서 하드웨어 쪽으로 가는 게 재미있고 보람 있었으며 점수도 잘 받았음. 좋은 시절이었음 컨퍼런스 쪽도 크게 나을 게 없음 몇 달 전 마지못해 하나에 갔는데 정말 충격받았음. 이틀짜리였고, 프로그래밍 언어 이름은 굳이 말하지 않겠음. 이제는 별 의미도 없을 것 같은데, 발표 중 순수하게 프로그래밍에 관한 것은 많아야 20% 정도였음 스스로를 업계 챔피언이라 부르는 작은 무리가 차례로 무대에 올라 자신들의 성스러움과 커뮤니티를 위해 했다는 뛰어난 일을 설교했는데, 그 영역은 소프트웨어 공학과 Iceland가 Indian Ocean에 접해 있는 정도로만 관련 있었음 강연 또 강연이었고, 생활양식이었고, 덕 과시 였고, 프로그래밍만 아니었음. 억지로 끼워 넣은 워크숍 하나는 기본도 제대로 쌓을 시간이 없었고, 개인적으로 영웅처럼 여기던 사람은 내부 패키지 관리자 드라마를 이야기하러 나왔음. 다음! 다시는 안 감. 뿌리까지 다 썩었음 요즘 그 생각을 하고 있었음. 이제 소프트웨어가 대부분의 아이디어 제안자 손에 닿는 곳까지 왔으니, 훨씬 깊은 수준의 손작업과 실험 이 가능해짐 느리긴 해도 매우 저렴한 3D 프린터와 풍부한 하드웨어 인터페이스 덕분에, 주말 프로젝트에서 출발해 “왜 지금까지 없었지” 싶은 아름다운 유틸리티가 세상에 많이 나올 것 같음. 소프트웨어 엔지니어와 팀들이 다음 단계의 제품 제작자로 변해가는 모습을 보는 게 기대됨 내 남동생은 해변 구조요원인데, 지난 1년 동안 놀라운 프로젝트들을 엄청나게 만들어냈음. 뭔가 해방된 느낌임. 정말 멋진 시대임 마지막으로 갔던 해커톤에서 우리 팀은 PowerPoint 발표 만 만든 팀에게 졌음. 더는 그런 걸 하고 싶지 않음 그런데 어떻게? 그 PowerPoint가 그렇게 흥미로웠나?
여러 사정을 보면 말이 됨. 해커톤은 몇 번만 나가봤는데, 2022년쯤 Amsterdam에서의 경험이 제일 좋았음. 팀 절반은 자러 갔고, 나와 한 명은 200명쯤 있는 행사장에 밤새 갇혀서 뭔가를 만들며 최적화, 꼼수, 거의 불가능한 문제에 대한 반쯤 억지 해법을 찾느라 머리를 싸맸음 최근 몇 년 사이 흥미를 잃었고, 이제는 다시 나갈 일은 없을 듯함. 최근 끝난 해커톤 메일을 받았는데, 우승자가 AI 엔지니어 팀 같은 걸 만들었다고 했고 발표물은 skills.md 같은 Markdown 헛소리 파일 20개였음. 글만 그럴듯하게 쓰면 금메달인가 싶었고, 친구 말처럼 “바닥을 찍고 이제 바닥을 뚫고 들어가는” 느낌임. 적어도 하드웨어는 실제로 뭔가를 만들고 머리를 써야 함
해커톤은 “멋진 UI와 목업 데이터” 대회가 됐음. 팀에 가장 좋은 UI 담당자 가 있는 쪽이 이겼고, 나도 몇 번 그 덕을 봤음
해커톤은 괜찮다고 봄. 내가 약한 것들, 즉 피치 , 눈 맞추기, 설득력 있는 이야기 만들기, 청중 끌어들이기를 전부 요구함. 나는 이런 걸 정말 못함 사람들이 내 고통을 느끼게 하거나 빠르게 효과적으로 전달하는 데 형편없음. 지금 해커톤은 거의 이것뿐이고, 내 핵심 약점을 드러내는 훈련장이 됐기 때문에 경력 25년 차에도 거의 매주말 나가고 있음. 정말 나아져야 하는 영역이고, 드디어 조금씩이지만 검증 가능하게 좋아지고 있음 이 문제를 나는 trailhead 라고 부름. 문제의 길 깊숙이 들어가면 출발점에서 어떻게 보였는지를 잊어버리고, 그래서 잘못된 세부 수준과 잘못된 측면에 시간을 쓰다가 제품을 설득하지 못함. 그래서 자기 것보다 남의 것을 더 잘 피치할 수 있음
90년대 초에 Linux와 오픈소스에 입문한 입장에서, 해커톤 이 “다 같이 모여 자유 소프트웨어를 협업해서 만들자”가 아니라 경쟁 활동으로 변해버린 게 늘 아쉬움. 요즘은 후자를 “개발 스프린트”라고 부르는 것 같지만, 해커톤이라는 말을 들으면 항상 그게 먼저 떠오름
글쓴이는 속도가 중요하고 버그가 용인되며 데모만 평가받는 해커톤에서 바이브 코딩 이 코딩을 완전히 대체했다고 보는데, 여기에 동의함 하지만 그래서 소프트웨어가 “해결”됐고 하드웨어 해커톤만 의미 있다는 결론은 왜 나오는지 모르겠음. 오히려 소프트웨어 해커톤은 아이디어가 더 중요해졌기 때문에 더 유용해졌다고 봄. 아이디어가 싸졌다고 해도, 창의성을 자극하는 공간에서 더 나은 세부 사항을 떠올리며 24~72시간을 프로토타입에 쓸 수 있는 사람은 모두가 아님 소프트웨어도 해결된 게 아님. 특히 심사위원이 어느 정도 기능성을 요구한다면, 어떤 아이디어는 여전히 프로토타입으로 옮기기 위해 저수준 지식과 기술 이 필요함. 해커톤의 목적이 나중에 제품으로 다시 만들 프로토타입이든, 투자자 유치용 프로토타입이든, 회사 관련 아이디어 발굴이든, 그냥 재미와 무료 음식과 좋은 사람들을 즐기는 것이든 말임
Hack Club에서는 지난 2년간 청소년들이 전자공학에 입문하고 직접 PCB를 설계 하도록 돕는 데 큰 투자를 해왔음 속이기 훨씬 어렵고, 특히 초보자에게는 소프트웨어보다 훨씬 더 흥미로운 경우가 많음. 최근 GitHub HQ 행사 영상도 볼 만함: https://youtu.be/kaEFv7e49mo?si=sLer815jCJIyWR9Y 곧 Hack Club Fallout이라는 행사를 열 예정이고, 미국과 전 세계의 고등학생들을 Shenzhen으로 데려가 7일간 해커톤을 진행함. 당일 PCB 제작이 가능한 몇 안 되는 곳 중 하나이기 때문임: https://fallout.hackclub.com
대학 시절 내 해커톤 프로젝트는 거의 전부 하드웨어 였음 예를 들면 HackPrinceton에서 만든 것들인데, 여기는 전기전자 실험실이 가장 좋았음. https://blog.cyrusroshan.com/post/electronic-banjo 는 관중 인기상을 받았고, https://blog.cyrusroshan.com/post/spin-to-win 는 “문샷” 아이디어였음 자기가 만든 것을 손에 쥘 수 있다는 건 꽤 좋음. 만질 수 있는 결과물 은 설명하기도 쉽고 속이기도 어려움. 그래서 하드웨어 쪽으로 가는 게 재미있고 보람 있었으며 점수도 잘 받았음. 좋은 시절이었음
컨퍼런스 쪽도 크게 나을 게 없음 몇 달 전 마지못해 하나에 갔는데 정말 충격받았음. 이틀짜리였고, 프로그래밍 언어 이름은 굳이 말하지 않겠음. 이제는 별 의미도 없을 것 같은데, 발표 중 순수하게 프로그래밍에 관한 것은 많아야 20% 정도였음 스스로를 업계 챔피언이라 부르는 작은 무리가 차례로 무대에 올라 자신들의 성스러움과 커뮤니티를 위해 했다는 뛰어난 일을 설교했는데, 그 영역은 소프트웨어 공학과 Iceland가 Indian Ocean에 접해 있는 정도로만 관련 있었음 강연 또 강연이었고, 생활양식이었고, 덕 과시 였고, 프로그래밍만 아니었음. 억지로 끼워 넣은 워크숍 하나는 기본도 제대로 쌓을 시간이 없었고, 개인적으로 영웅처럼 여기던 사람은 내부 패키지 관리자 드라마를 이야기하러 나왔음. 다음! 다시는 안 감. 뿌리까지 다 썩었음
요즘 그 생각을 하고 있었음. 이제 소프트웨어가 대부분의 아이디어 제안자 손에 닿는 곳까지 왔으니, 훨씬 깊은 수준의 손작업과 실험 이 가능해짐 느리긴 해도 매우 저렴한 3D 프린터와 풍부한 하드웨어 인터페이스 덕분에, 주말 프로젝트에서 출발해 “왜 지금까지 없었지” 싶은 아름다운 유틸리티가 세상에 많이 나올 것 같음. 소프트웨어 엔지니어와 팀들이 다음 단계의 제품 제작자로 변해가는 모습을 보는 게 기대됨
마지막으로 갔던 해커톤에서 우리 팀은 PowerPoint 발표 만 만든 팀에게 졌음. 더는 그런 걸 하고 싶지 않음
프로덕트 바이브 코딩으로 7일간 900커밋, 디자이너의 앱 출시기
이키 8 분 2026.05.28. 인기 9.9K
한국방송협회 산하 방송사공동예측조사위원회(KEP)는 지난 3일 지방선거 선거방송 출구조사 보도과정에서 발생한 데이터 오류에 대해 공식 사과했다.
KEP는 지상파방송 3사 선거방송 중 일부 지역의 성·연령별 유권자 성향 분석 데이터에 오류가 있음을 인지했다고 밝혔다.
지방선거 출구조사는 한국리서치, 코리아리서치, 입소스코리아 등 3개 여론조사기관이 전국 16개 시도를 분할해 수행했다. 정확한 예측 결과를 도출하기 위해서는 선거 당일 출구조사 데이터와 사전투표자 예측 전화조사 데이터를 합산해야 했으나 한국리서치가 담당한 서울, 대구, 울산, 충북 등 4개 지역의 성별, 연령별 유권자 분석에서 사전투표자 예측 데이터가 누락된 채 당일 출구조사 결과만 반영된 것으로 확인됐다.
KEP 측은 “최종 당선자 예측 결과에는 두 조사가 정상적으로 합산 도출됐으나 각 지역의 성연령별 유권자 분석 데이터의 경우 한국리서치의 명백한 업무상 과실로 사전투표자 예측 데이터가 합산에서 누락됐다”며 “결과적으로 민심을 가늠하는 데 있어 시청자들에게 오해를 불러일으켰다”고 설명했다.
이어, “코리아리서치와 입소스코리아가 담당한 조사 지역은 사전투표자 예측 데이터가 반영됐고, 한국리서치 담당 지역에서만 독자적으로 발생한 문제”라며 “KEP가 특정한 의도를 가지고 데이터를 수정한 것이 아니다”고 덧붙였다.
전문가가 본 XRP 10달러 시나리오…2026년 말~2027년 초 제시
분석가 셀랄 퀴쥐케르는 XRP가 0.87달러까지 밀린 뒤 반등해 2026년 12월~2027년 2월 10달러에 도달할 수 있다고 봤다.
[디지털투데이 이윤서 기자] XRP가 2026년 12월부터 2027년 2월 사이 10달러에 도달할 수 있다는 분석이 나왔다.
8일(현지시간) 블록체인 매체 더 크립토 베이직에 따르면 시장 분석가 셀랄 퀴쥐케르(Celal Küçüker)는 현재 XRP 차트 가운데 가장 현실적인 시나리오로 이러한 흐름을 제시했다.
이번 전망은 XRP 투자심리가 최근 시장 전반의 조정 속에 크게 악화된 시점에 나왔다. XRP의 연초 대비 손실률은 38%까지 커진 상태지만, 셀랄 퀴쥐케르는 단기 약세가 이어지더라도 중장기적으로는 10달러까지의 상승 여지가 남아 있다고 봤다.
핵심 근거는 6년 넘게 이어진 상승 채널이다. XRP는 2020년 3월 0.11달러까지 밀린 뒤 월간 차트에서 회복 흐름을 만들었고, 이후 하단 지지선과 상단 저항선 사이에서 움직여 왔다. 하단 지지선은 계속 높아지는 저점을, 상단 저항선은 점차 높아지는 고점을 보여주며 채널 구조를 유지하고 있다는 설명이다.
실제 XRP는 2021년 4월 1.96달러까지 오른 뒤 상단 저항선에 막혀 되돌림을 겪었다. 이후 2025년 1월 3.4달러, 2025년 7월 3.6달러에서도 같은 저항 구간을 다시 시험했지만 돌파에는 실패했다. 셀랄 퀴쥐케르는 이런 흐름이 반복되면서 상승 채널이 형성됐고, 이 패턴이 역사적으로 XRP의 추가 상승으로 이어졌다고 봤다.
그는 특히 가격이 하단 추세선까지 밀릴 때마다 반등이 나타났고, 이후 더 높은 고점까지 치솟는 흐름이 이어졌다고 짚었다. 이어 2021년 4월의 1.96달러, 2025년 1월의 3.4달러, 2025년 7월의 3.6달러가 모두 같은 구조 안에서 나왔다고 짚었다.
이런 흐름에 따라 셀랄 퀴쥐케르는 XRP가 먼저 0.87달러까지 더 밀릴 수 있다고 예상했다. 이 구간은 0.618 피보나치 되돌림 비율과 하단 지지선이 겹치는 자리로, 현재 하락 추세 속에서 XRP가 다시 하단 추세선을 시험할 수 있다는 것이다.
다만 조정이 끝난 뒤에는 반등 가능성이 높다고 봤다. 셀랄 퀴쥐케르는 매수세가 이 구간에서 힘을 되찾으면 최근 몇 달간의 낙폭을 만회하는 반등이 가능하고, 이후 더 높은 가격대를 노릴 수 있다고 했다. 그는 현재 시장에서 이 차트가 가장 현실적인 XRP 차트라고 평가하면서, 10달러를 향한 상승이 2026년 12월부터 2027년 2월 사이 나타날 수 있다고 제시했다.
시장에서는 이 전망이 단기 낙폭과 중장기 반등 가능성을 함께 담고 있다는 점에 주목하고 있다. XRP가 실제로 0.87달러 부근까지 내려가 지지력을 확인할지, 아니면 예상보다 이른 구간에서 반등해 채널 상단을 다시 시험할지가 향후 핵심 관전 포인트가 될 전망이다.
The most realistic $XRP chart suggests that a move to $10 could happen between December 2026 and February 2027. If XRP can establish and hold above $10, the sky's the limit. pic.twitter.com/D0noRxJC0t
△디지털투데이 텔레그램 뉴스채널 구독하기(클릭)
이 시각 추천뉴스 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요' 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다” 백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율" 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요' 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다” 백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율"
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러?
IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시
그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요'
클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담
크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다”
백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율"
Show GN: Playwright 봇 탐지를 우회하는 스킬 (github.com/greekr4)
Playwright로 사이트에 접속하면 봇탐지에 바로 막히는 경우가 많습니다. 인터넷에 떠도는 "스텔스" 스니펫들을 붙여봤더니, 어떤 건 오히려 더 잘 걸리더군요. 그래서 8개 탐지기로 직접 측정해보고, 실제로 통과하는 조합만 골라 스킬로 만들었습니다. 설치 / 사용 설치: npx skills add greekr4/playwright-bot-bypass 사용: playwright-bot-bypass 호출 좀 의외였던 점 흔히 쓰는 navigator 위조(가짜 플러그인·캔버스 노이즈·webdriver 삭제 등)는 진짜 크롬과 미묘하게 안 맞아서 오히려 탐지 신호가 됩니다. 하나는 실제 크롬에서 크래시까지 났습니다 그래서 위조는 전부 빼고, 진짜 크롬(headed)에 맡긴 뒤 Playwright 흔적 딱 2개만 제거했습니다 (__pwInitScripts 제거 + rebrowser의 CDP 누수 차단) 결론은 "덜 꾸밀수록 더 안 걸린다" 였습니다 피드백 환영합니다 — 특히 "이 탐지기는 못 뚫더라" 같은 제보 주시면 반영하겠습니다.
피드백 환영합니다 — 특히 "이 탐지기는 못 뚫더라" 같은 제보 주시면 반영하겠습니다.
함께 보면 좋은 글 β Camofox Browser - AI 에이전트를 위한 스텔스 헤드리스 브라우저 봇 감지 우회하기 : 차단당하지 않고 웹 스크레핑 하는 법 거의 완벽한 브라우저 핑거프린팅을 지원하는 새로운 크롬 헤드리스 모드 릴리즈 Cloudflare 를 우회하는 방법 웹크롤링시 Bot검사를 피하는 방법
Camofox Browser - AI 에이전트를 위한 스텔스 헤드리스 브라우저
봇 감지 우회하기 : 차단당하지 않고 웹 스크레핑 하는 법
거의 완벽한 브라우저 핑거프린팅을 지원하는 새로운 크롬 헤드리스 모드 릴리즈
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
WWDC 2026의 종이접기 샘플 앱과 iOS 27 베타 문자열은 Apple이 접히는 화면 과 가변 레이아웃을 준비한다는 신호로 연결됨 iOS 27 베타에서 foldState , angleDegrees , 내장 디스플레이 총수를 반환하는 시스템 키 가 발견됨 Apple은 iPhone Mirroring, Resizable iOS Simulator, “동적인 크기와 화면비” 표현을 통해 iOS 앱의 리사이징 대응 을 강하게 요구함 Android 폴더블 사용자는 7년간 앱 호환성 문제를 겪었고, Apple은 기기 출시 전에 개발자 작업 방식에 적응형 설계를 넣으려 함 iPhone Ultra로 보이는 새 폼팩터는 책처럼 접히는 iPhone으로 묘사되며, Apple 생태계 앱이 변형되는 화면에 맞춰 재설계될 필요가 커짐 접힘의 기술 올해 Platform State of the Union 의 샘플 앱은 사진에서 종이 공예 프로젝트를 만들고 단계별 접기 튜토리얼을 생성하는 종이접기 앱이었음 Foundation Models 팀의 Maribeth는 이 앱을 “종이로 긴장을 풀고 창의력을 발휘하는” 장소로 표현 데모는 따뜻하고 느린 분위기였으며, 종이접기 앱 선택이 우연이 아니었을 가능성이 큼 iOS 27 베타에서 발견된 문자열 Sam Gold는 iOS 26에는 없던 foldState 와 angleDegrees 를 iOS 27 베타 프레임워크 문자열에서 발견함 또 다른 발견은 기기의 내장 디스플레이 총수를 반환하는 새 시스템 키 였음 지금까지 Apple이 출시한 모든 iPhone의 내장 디스플레이 수는 하나였고, 이 값이 하나가 아닐 수 있는지 묻는 API는 명확한 사용 사례를 가짐 리사이징을 강하게 요구한 플랫폼 세션 Apple은 Mac의 iPhone Mirroring에서 iOS 앱 리사이징 지원 을 발표 미러링된 창은 처음으로 가로 방향으로 확장될 수 있으며, 현재 iPhone이 기본으로 만들지 않는 가로 화면비까지 늘어남 Resizable iOS Simulator는 “동적인 크기와 화면비 범위”에서 레이아웃을 테스트할 수 있음 “동적인 크기와 화면비 범위에 맞춰 설계하라”는 표현이 세션에서 두 번 이상 등장함 기기 출시 전 생태계 준비 Android 폴더블 소유자는 7년 동안 어떤 앱이 동작하고 어떤 앱이 동작하지 않는지 확인해야 했음 Apple은 같은 경험을 반복하려 하지 않으며, 기기가 존재하기 전에 개발자 작업 방식에 요구사항을 넣고 있음 PSOTU의 메시지는 특정 하드웨어 조각을 위한 소프트웨어 제작을 멈추고, 다양한 화면 크기와 화면비에 적응하는 소프트웨어를 설계하라는 요구였음 Apple은 기기 발표와 출하 사이의 기간을 활용해 전체 개발자 커뮤니티를 준비시키는 방식을 쓰고 있음 iPhone Ultra로 보이는 하드웨어 새 폼팩터 iPhone의 명칭은 iPhone Ultra로 보이며, 책처럼 접히는 폴더블 기기 내부 디스플레이는 7.7~7.8인치, 커버 화면은 5.3~5.5인치 펼쳤을 때 화면비는 와이드스크린보다 iPad mini에 가까운 4:3 비율 시작 가격은 약 2,000달러로 예상 iPhone 18 Pro와 함께 9월 발표되고, Foxconn 생산은 7월 대량 생산 증가를 목표로 함 John Ternus는 9월 1일 CEO 자리에 오르며, 이 기기를 역할상 첫 주요 행보로 발표할 것 John Ternus는 이 기기 개발을 감독했고, 그런 의미에서 새 CEO이자 기기의 설계자 종이접기 데모와 개발자 요구의 연결 State of the Union의 종이 공예 데모는 튜토리얼로 끝났고, 앱은 접기, 접어 누르기, 형태 만들기 단계를 안내함 Apple은 개발자에게 접힘을 다루는 방법을 보여주고, 실제성을 뒷받침하는 코드를 내보낸 뒤, 형태가 바뀌는 표면에 맞춰 앱을 재설계하라고 요구한 셈 종이접기 샘플 앱, iOS 27 문자열, 리사이징 도구는 Apple의 폴더블 준비 흐름 안에 있다고 볼 수 있음
함께 보면 좋은 글 β WWDC 2026 애플, 50주년인 2026년에는 뭐가 바뀔까? 1인 앱 개발을 위한 React Native + Expo 베이스 템플릿 WWDC 2025 1주 후, 간단한 소회와 관찰 애플 WWDC 2025 키노트 주요 내용 정리
애플, 50주년인 2026년에는 뭐가 바뀔까?
1인 앱 개발을 위한 React Native + Expo 베이스 템플릿
WWDC 2025 1주 후, 간단한 소회와 관찰
애플 WWDC 2025 키노트 주요 내용 정리
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
인증 이메일 클릭후 다시 체크박스를 눌러주세요
▲ xguru 2일전 [-] https://x.com/MKBHD/status/2064146741809819728 MKBHD 가 영상도 올렸네요 "폴더블이 나온다고 말하지 않으면서, 폴더블이 나온다고 말해봐" 답변달기 ▲ GN⁺ 2일전 [-] Hacker News 의견들 여기서 놓치는 건, 대부분의 사람은 PC나 노트북 을 갖고 있지 않거나 있어도 거의 열지 않는다는 점임 돈이 없어서가 아니라 일상에 맞지 않아서이고, HN 이용자층과는 완전히 다름 그런 경우 접는 폰 은 큰 변화임. 부모님이 쓰는 걸 만져봤는데 읽기와 스크롤 경험이 확실히 좋아졌고, 우리가 폰에 쓰는 시간이 워낙 많다는 현실도 있음 접는 폰은 사실상 작은 태블릿 이 되는 셈인데, 일부에게는 매력적일 수 있어도 PC보다 태블릿을 갖고 싶어 하는 사람은 더 적음 태블릿을 원하는 사람들은 이미 접는 폰의 기믹보다 나은 태블릿을 갖고 있음 PC 노트북이 없는 사람에게 뭐가 그렇게 큰 변화인지 모르겠음 접는 폰을 써보거나 본 예들은 대부분 앱이 화면에 잘 맞지 않는 평범한 스마트폰처럼 보였고, 잘 맞는 몇몇 앱도 실질적 이점이 커 보이지 않았음 게다가 내가 아는 접는 폰 사용자들 은 시간이 지나며 화면이 망가지는 신뢰성 문제 를 겪었음 맞음. iPhone과 MacBook Neo를 대략 같은 비용으로 살 수 있다는 점을 생각하면, 이 기기가 실제로 어떻게 동작할지 꽤 흥미로움 로컬 Xcode가 필요 없는 사용자에게 iOS가 macOS를 대체 할 수 있을까? 주머니와 책상에서 모두 쓰는 기기에 2천 달러를 쓰고, 필요하면 나머지 돈을 클라우드/서버 인프라에 넣을 수 있을까? 공정하게 말하면 이 얘기가 적용되는 건 “기술 업계 밖”이 아니라 미국 밖 특정 국가들 임 스마트폰은 있지만 컴퓨터는 없는 미국인은 매우 드물고, 대체로 가난해서 초고가 폰의 시장 대상이 아님 중국, 한국, 일본처럼 최근에 부유해진 나라들을 말하는 것 같고, 실제로 접는 폰이 잘 팔리는 곳도 그쪽임 특히 PC 보급률 이 낮은 아시아 국가들에서는 더 그렇음 한동안 Pixel Fold 9 Pro 를 매일 쓰고 있는데 정말 마음에 듦 Apple이 마침내 들어오는 건 꽤 신남. 다만 주름이 안 보일 거라거나 화면 기술이 반드시 업계 최고일 거라고 기대하진 않는 게 좋음 그래도 별로 중요하지 않을 듯함. Pixel Fold도 그런 면에서 업계 최고는 아니지만, 쓰다 보면 접힘은 전혀 신경 쓰이지 않음. 정면에서는 거의 보이지 않고, “플라스틱 화면 보호 필름” 걱정도 실제로는 문제가 아님 내부 화면은 주머니에 있을 때 외부 긁힘에서 보호되기 때문에 생각보다 내구성이 좋음. 케이스나 보호 장치를 전혀 쓰지 않는데도 내 것은 아직 상태가 좋음 Apple의 큰 기회는 소프트웨어 쪽임. Google은 Fold에서 UI 개념을 탐구하는 데 별 관심이 없어 보이고, 그걸 OnePlus와 Samsung에 맡겨둔 상태인데 둘 다 Pixel Fold보다 멀티태스킹 경험이 낫다고 봄 Apple이 iPad가 되는 iPhone을 만드는 것만으로도 상당한 시장 점유율을 얻을 수 있겠지만, iPad가 하는 것 이상으로 흥미로운 UI를 시도했으면 함 Pixel 8a를 쓰는데 케이스가 꼭 필요함. 가능한 한 미끄럽게 설계한 것처럼 보임 모든 모서리가 둥글고 잡을 곳이 없어서, 알루미늄/유리로 된 젖은 비누 같은 느낌임 시의적절하게도, 이 글을 Pixel 10 Pro Fold 에서 쓰고 있음. 1월에 산 제품임 어젯밤 펼쳐보니 접히는 부분 중앙의 내부 화면에 죽은 픽셀이 생겼음 접는 폰은 좋아함. 두 모드 모두 항상 쓰지만, 지금은 Best Buy 보증 플랜 세부 조건 찾아보기를 미루는 중임 모바일 초고강도 사용자 중 작은 비율에게는 접는 폰이 정말 미래라고 봄. 기본으로 데스크톱 모드 를 쓰거나 멀티태스킹할 수 있다는 건 큼 한 바퀴 돌아 다시 돌아왔음. Samsung Fold는 멋지고 편했지만, iPad mini와 폰 을 같이 들고 다니는 것도 그렇게 큰일은 아님 iPad mini에는 WhatsApp이나 SMS가 붙어 있지 않아서, 책 읽기나 음악 재생 전용으로 쓸 수 있다는 점이 꽤 좋음 iPad Mini와 내 폰을 합친 비용은 600달러 정도였고, Fold 계열은 6세대 이후도 매우 불안정해서 지금은 이 조합이 최선처럼 보임 경우에 따라 다를 듯함. 나는 접는 폰이 정말 좋음. 특가로 500유로 에 샀음 태블릿을 항상 가지고 다닐 수 있다는 게 좋음. 더운 나라에 살아서 보통 코트나 큰 가방을 들고 다니지 않음 게다가 Android에는 괜찮은 작은 태블릿이 거의 없음. 전부 10인치 이상임 걸어 다닐 때 iPad와 폰 을 같이 들고 다니는 건 귀찮음 큰 주머니나 핸드백이 필요한데, 더우면 둘 다 원하지 않게 됨 “iPad mini와 폰을 들고 다니는 게 큰일은 아니다”는 건 당신에게나 그럴 수 있음 대부분에게도 그랬다면 우리 모두 이미 그렇게 하고 있었을 것임 iPad mini 는 읽기용으로 훌륭하지만, Apple이 성능을 올리기까지 너무 오래 걸렸음 예전에 등장했던 Motorola Razor 접는 폰에 익숙했던 입장에서는 그것도 정말 좋고 멋졌음. 점점 작아지던 Ericson 스마트폰은 싫었음 Samsung 접는 스마트폰을 Apple이 따라 만든 제품을 기대하고 있음. 결국 iPhone과 iPad mini를 둘 다 들고 다니고 싶지는 않음 접는 폰은 iPhone Ultra Max 같은 제품의 대체품에 더 가깝다고 봄. 화면이 아무리 커져도, 수년간 구형에 묶여 있었더라도, 가독성 에서는 iPad mini를 이기지 못함 폰과 태블릿 둘 다 WhatsApp을 설치할 수 있고, 설치 여부와 확인 빈도는 사용자 선택임 앱을 전체 음소거하는 것도 가능함 요지는 이해하지만, 사용자가 개입하면 완화할 수 있는 문제임. 다만 폰보다 큰 화면에서 읽는 게 더 나은 사용자 경험이라는 말이라면 동의함 이런 제품들, Apple Vision Pro까지 포함해서, Apple이 “대중” 혹은 주주 에게 대응해야 한다고 느끼는 결과처럼 보임 “Samsung은 멋진 접는 폰을 갖고 있고, 요즘 디자인 주도권을 Apple에서 가져가는 것 같다” “VR이 컴퓨팅의 미래라던데, 왜 Apple은 이 분야에 없지?” Jobs 시대에도 iPad는 Apple이 태블릿 시장 의 압박에 대응한 제품이라고 볼 수 있을 듯함 Apple Watch도 Pebble에 대한 반응이었을까? 작은 정사각형 iPod Nano 가 나온 순간, 시계는 필연적이었음 https://www.kickstarter.com/blog/a-new-era-for-design 실제로는 그런 이유라기보다, Apple이 1) 수익성이 좋고 2) 현금을 많이 보유하고 3) 새 제품을 실행해낸 검증된 역량이 있기 때문이라고 봄 그래서 틈새시장에 진입하지 않으면 큰돈을 놓칠 수 있고, 제품이 traction을 얻지 못하더라도 실패의 하방이 회사를 죽일 정도는 아님 솔직히 접는 폰 은 별로 선호하지 않음. 개인적 의견임 접으면 기기 두께가 두 배가 되어 주머니에서 느껴지는 방식이 싫음 모바일 기기 제조사들, Samsung, Huawei, 이제 Apple까지 접는 제품을 만들 때마다 “슬레이트” 형태에서 아이디어가 떨어져 매출을 자극하려는 것처럼 느껴짐 개인적으로는 그 연구개발비와 혁신이 더 지속 가능한 소재 , 더 오래가는 기기, 수명 연장을 위한 쉽게 수리 가능한 부품에 쓰였으면 함 나도 같은 생각이지만, 다른 사람들은 다르게 본다는 것도 인정함. 결국 시장이 결정하게 될 것임 Apple의 지난해 연간 매출총이익은 1,950억 달러였고 연구개발 예산은 약 350억 달러였음. 그러니 여윳돈은 충분함 접는 폰에 쓰는 비용이 재정적으로 발목을 잡을 가능성은 거의 없다고 봄 더 걱정되는 건 집중력 , 파편화된 생태계, 사용자 경험 등에 미치는 영향임 Jobs의 말처럼, “사람들은 집중이 집중해야 할 것에 예라고 말하는 것이라고 생각한다. 하지만 전혀 그렇지 않다. 집중이란 수많은 다른 좋은 아이디어에 아니라고 말하는 것이다. 신중하게 골라야 한다. 실제로 나는 우리가 해낸 것만큼이나 우리가 하지 않은 많은 것들을 자랑스럽게 생각한다” 새 Samsung Fold 7 은 접은 상태에서도 iPhone 17보다 1mm도 채 두껍지 않음 영리 기업이 하는 일은 좋든 나쁘든 이익 에 집중하는 것임 더 지속 가능한 소재, 더 오래가는 기기, 쉽게 수리 가능한 부품은 나도 원하지만, 더 많은 이익을 내는 목표와 정면으로 충돌함. 말한 것들은 문자 그대로 회사의 수입을 줄일 가능성이 큼 경제 시스템상 그런 것들이 중심이 되기는 현실적으로 어려움. 시장이 보상하지 않고, 바뀔 것 같지도 않음 해법은 모르겠음. 현상 유지는 그냥 별로고, 탈출구도 보이지 않음. 오히려 더 나빠지는 것 같음 아이디어가 떨어져서 그런 건 절대 아니라고 봄. 나는 Galaxy Fold 를 쓰고 있고 정말 좋아함 내가 산 지 두 달쯤 지나 아내도 직접 하나 샀음. 어디를 가도 사람들이 보고 만져보고 싶어 하는데 꽤 인상적임 앱이 넓은 화면비를 지원하지 않는 문제도 겪지 않았음. Android가 초기에 더 유연한 소프트웨어에 투자한 게 보상받은 사례임 Android 앱은 처음부터 크기 조절 가능한 레이아웃을 지원해야 해서 작성이 더 어려웠지만, 접는 폰 같은 제품이 나올 때쯤에는 소프트웨어 생태계가 이미 준비되어 있었음 수리 용이성의 문제는 항상 방수 , 두께, 손에 쥐는 느낌과, 탈착식 배터리나 뒷판을 가능하게 만들기 위한 타협 사이의 충돌임 우회 방법은 있지만 시장의 압도적 다수는 거의 접착제로 단단히 붙인 폰을 선호하므로 회사들도 그렇게 만듦 폰 디자인은 이미 국소 최댓값에 도달한 듯하고, 접힘은 두 갈래를 열어줌. 1) 펼친 화면 크기는 같지만 접으면 더 작아지는 방향, 2) 접힌 상태에서는 오늘날 일반 폰과 비슷한 외부 화면을 쓰고, 펼치면 훨씬 큰 화면이 되는 방향 사람들이 합리적으로 주머니에 넣을 수 있는 크기는 정점에 가까워졌기 때문에, 두 번째 선택지는 별도 기기, 즉 태블릿 같은 것을 들고 다니지 않고도 더 큰 화면을 원하는 사람에게 길을 열어줌 Fold는 기능을 더해주며, 자신이 관심 없다는 이유만으로 어떤 것의 의미를 못 보겠다고 말하게 되는 충동이 있는 것 같음 세션 영상 중 하나는 종이비행기 함대 를 추적하는 앱으로 콘텐츠를 설명했음 또 다른 영상은 종이접기 에 관한 것이었음 접는 iPhone은 Apple의 가장 큰 문제 중 하나를 확실히 해결할 것임. 접는 폰은 5~10년 씩 버티지 못함 장기적으로 Apple이 모든 iPhone 제품군을 접는 형태로 만들 수도 있다고 봄 사람들이 업그레이드하지 않는 게 정말 Apple의 문제인지 모르겠음 적어도 캐나다에서는 통신사들이 계약이 끝나면 새 계약을 갱신시키려고 0달러에 새 폰을 주는 식의 조건으로 모두를 괴롭힘 기술에 관심 없는 부모님도 통신사가 전화해서 거의 새 폰을 가져가 달라고 애원하다시피 해서 몇 년마다 최신 일반 iPhone을 받음 4년보다 오래된 폰을 쓰는 사람을 보는 건 극히 드묾 실제로 얼마나 많은 사람이 iPhone을 5~10년 씩 붙들고 있는지 알고 있나? 많지 않을 거라고 봄 Apple이 이런 식으로 넣는 작은 쇼맨십 이 좋음 조 단위 달러 기업이 “알지?” 같은 윙크를 하는 걸 보는 게 그냥 웃김 적어도 나에게는 화면 크기가 한계가 아니라 키보드 부재 가 한계임 왜 이 기기를 Neo나 Air에 접히지 않는 폰을 더한 조합보다 선택해야 하는지 모르겠음 어떤 iPhone이나 iPad에도 Bluetooth 키보드 를 페어링할 수 있음 예를 들면 이 제품은 배터리와 소형 물리 키보드를 결합함 https://www.clicks.tech/products/powerkeyboard 크기 조절 가능한 iOS 앱을 언급한 건 데스크톱 독 모드 를 암시하는 것 같고, 그게 당신의 우려와 연결됨 제조 유출로 Apple이 접는 iPhone을 가져온다는 건 알고 있음. 데스크톱 모드는 대부분 소프트웨어이고 제3자 의존도도 훨씬 낮아서 유출될 가능성이 더 작음 답변달기
▲ GN⁺ 2일전 [-] Hacker News 의견들 여기서 놓치는 건, 대부분의 사람은 PC나 노트북 을 갖고 있지 않거나 있어도 거의 열지 않는다는 점임 돈이 없어서가 아니라 일상에 맞지 않아서이고, HN 이용자층과는 완전히 다름 그런 경우 접는 폰 은 큰 변화임. 부모님이 쓰는 걸 만져봤는데 읽기와 스크롤 경험이 확실히 좋아졌고, 우리가 폰에 쓰는 시간이 워낙 많다는 현실도 있음 접는 폰은 사실상 작은 태블릿 이 되는 셈인데, 일부에게는 매력적일 수 있어도 PC보다 태블릿을 갖고 싶어 하는 사람은 더 적음 태블릿을 원하는 사람들은 이미 접는 폰의 기믹보다 나은 태블릿을 갖고 있음 PC 노트북이 없는 사람에게 뭐가 그렇게 큰 변화인지 모르겠음 접는 폰을 써보거나 본 예들은 대부분 앱이 화면에 잘 맞지 않는 평범한 스마트폰처럼 보였고, 잘 맞는 몇몇 앱도 실질적 이점이 커 보이지 않았음 게다가 내가 아는 접는 폰 사용자들 은 시간이 지나며 화면이 망가지는 신뢰성 문제 를 겪었음 맞음. iPhone과 MacBook Neo를 대략 같은 비용으로 살 수 있다는 점을 생각하면, 이 기기가 실제로 어떻게 동작할지 꽤 흥미로움 로컬 Xcode가 필요 없는 사용자에게 iOS가 macOS를 대체 할 수 있을까? 주머니와 책상에서 모두 쓰는 기기에 2천 달러를 쓰고, 필요하면 나머지 돈을 클라우드/서버 인프라에 넣을 수 있을까? 공정하게 말하면 이 얘기가 적용되는 건 “기술 업계 밖”이 아니라 미국 밖 특정 국가들 임 스마트폰은 있지만 컴퓨터는 없는 미국인은 매우 드물고, 대체로 가난해서 초고가 폰의 시장 대상이 아님 중국, 한국, 일본처럼 최근에 부유해진 나라들을 말하는 것 같고, 실제로 접는 폰이 잘 팔리는 곳도 그쪽임 특히 PC 보급률 이 낮은 아시아 국가들에서는 더 그렇음 한동안 Pixel Fold 9 Pro 를 매일 쓰고 있는데 정말 마음에 듦 Apple이 마침내 들어오는 건 꽤 신남. 다만 주름이 안 보일 거라거나 화면 기술이 반드시 업계 최고일 거라고 기대하진 않는 게 좋음 그래도 별로 중요하지 않을 듯함. Pixel Fold도 그런 면에서 업계 최고는 아니지만, 쓰다 보면 접힘은 전혀 신경 쓰이지 않음. 정면에서는 거의 보이지 않고, “플라스틱 화면 보호 필름” 걱정도 실제로는 문제가 아님 내부 화면은 주머니에 있을 때 외부 긁힘에서 보호되기 때문에 생각보다 내구성이 좋음. 케이스나 보호 장치를 전혀 쓰지 않는데도 내 것은 아직 상태가 좋음 Apple의 큰 기회는 소프트웨어 쪽임. Google은 Fold에서 UI 개념을 탐구하는 데 별 관심이 없어 보이고, 그걸 OnePlus와 Samsung에 맡겨둔 상태인데 둘 다 Pixel Fold보다 멀티태스킹 경험이 낫다고 봄 Apple이 iPad가 되는 iPhone을 만드는 것만으로도 상당한 시장 점유율을 얻을 수 있겠지만, iPad가 하는 것 이상으로 흥미로운 UI를 시도했으면 함 Pixel 8a를 쓰는데 케이스가 꼭 필요함. 가능한 한 미끄럽게 설계한 것처럼 보임 모든 모서리가 둥글고 잡을 곳이 없어서, 알루미늄/유리로 된 젖은 비누 같은 느낌임 시의적절하게도, 이 글을 Pixel 10 Pro Fold 에서 쓰고 있음. 1월에 산 제품임 어젯밤 펼쳐보니 접히는 부분 중앙의 내부 화면에 죽은 픽셀이 생겼음 접는 폰은 좋아함. 두 모드 모두 항상 쓰지만, 지금은 Best Buy 보증 플랜 세부 조건 찾아보기를 미루는 중임 모바일 초고강도 사용자 중 작은 비율에게는 접는 폰이 정말 미래라고 봄. 기본으로 데스크톱 모드 를 쓰거나 멀티태스킹할 수 있다는 건 큼 한 바퀴 돌아 다시 돌아왔음. Samsung Fold는 멋지고 편했지만, iPad mini와 폰 을 같이 들고 다니는 것도 그렇게 큰일은 아님 iPad mini에는 WhatsApp이나 SMS가 붙어 있지 않아서, 책 읽기나 음악 재생 전용으로 쓸 수 있다는 점이 꽤 좋음 iPad Mini와 내 폰을 합친 비용은 600달러 정도였고, Fold 계열은 6세대 이후도 매우 불안정해서 지금은 이 조합이 최선처럼 보임 경우에 따라 다를 듯함. 나는 접는 폰이 정말 좋음. 특가로 500유로 에 샀음 태블릿을 항상 가지고 다닐 수 있다는 게 좋음. 더운 나라에 살아서 보통 코트나 큰 가방을 들고 다니지 않음 게다가 Android에는 괜찮은 작은 태블릿이 거의 없음. 전부 10인치 이상임 걸어 다닐 때 iPad와 폰 을 같이 들고 다니는 건 귀찮음 큰 주머니나 핸드백이 필요한데, 더우면 둘 다 원하지 않게 됨 “iPad mini와 폰을 들고 다니는 게 큰일은 아니다”는 건 당신에게나 그럴 수 있음 대부분에게도 그랬다면 우리 모두 이미 그렇게 하고 있었을 것임 iPad mini 는 읽기용으로 훌륭하지만, Apple이 성능을 올리기까지 너무 오래 걸렸음 예전에 등장했던 Motorola Razor 접는 폰에 익숙했던 입장에서는 그것도 정말 좋고 멋졌음. 점점 작아지던 Ericson 스마트폰은 싫었음 Samsung 접는 스마트폰을 Apple이 따라 만든 제품을 기대하고 있음. 결국 iPhone과 iPad mini를 둘 다 들고 다니고 싶지는 않음 접는 폰은 iPhone Ultra Max 같은 제품의 대체품에 더 가깝다고 봄. 화면이 아무리 커져도, 수년간 구형에 묶여 있었더라도, 가독성 에서는 iPad mini를 이기지 못함 폰과 태블릿 둘 다 WhatsApp을 설치할 수 있고, 설치 여부와 확인 빈도는 사용자 선택임 앱을 전체 음소거하는 것도 가능함 요지는 이해하지만, 사용자가 개입하면 완화할 수 있는 문제임. 다만 폰보다 큰 화면에서 읽는 게 더 나은 사용자 경험이라는 말이라면 동의함 이런 제품들, Apple Vision Pro까지 포함해서, Apple이 “대중” 혹은 주주 에게 대응해야 한다고 느끼는 결과처럼 보임 “Samsung은 멋진 접는 폰을 갖고 있고, 요즘 디자인 주도권을 Apple에서 가져가는 것 같다” “VR이 컴퓨팅의 미래라던데, 왜 Apple은 이 분야에 없지?” Jobs 시대에도 iPad는 Apple이 태블릿 시장 의 압박에 대응한 제품이라고 볼 수 있을 듯함 Apple Watch도 Pebble에 대한 반응이었을까? 작은 정사각형 iPod Nano 가 나온 순간, 시계는 필연적이었음 https://www.kickstarter.com/blog/a-new-era-for-design 실제로는 그런 이유라기보다, Apple이 1) 수익성이 좋고 2) 현금을 많이 보유하고 3) 새 제품을 실행해낸 검증된 역량이 있기 때문이라고 봄 그래서 틈새시장에 진입하지 않으면 큰돈을 놓칠 수 있고, 제품이 traction을 얻지 못하더라도 실패의 하방이 회사를 죽일 정도는 아님 솔직히 접는 폰 은 별로 선호하지 않음. 개인적 의견임 접으면 기기 두께가 두 배가 되어 주머니에서 느껴지는 방식이 싫음 모바일 기기 제조사들, Samsung, Huawei, 이제 Apple까지 접는 제품을 만들 때마다 “슬레이트” 형태에서 아이디어가 떨어져 매출을 자극하려는 것처럼 느껴짐 개인적으로는 그 연구개발비와 혁신이 더 지속 가능한 소재 , 더 오래가는 기기, 수명 연장을 위한 쉽게 수리 가능한 부품에 쓰였으면 함 나도 같은 생각이지만, 다른 사람들은 다르게 본다는 것도 인정함. 결국 시장이 결정하게 될 것임 Apple의 지난해 연간 매출총이익은 1,950억 달러였고 연구개발 예산은 약 350억 달러였음. 그러니 여윳돈은 충분함 접는 폰에 쓰는 비용이 재정적으로 발목을 잡을 가능성은 거의 없다고 봄 더 걱정되는 건 집중력 , 파편화된 생태계, 사용자 경험 등에 미치는 영향임 Jobs의 말처럼, “사람들은 집중이 집중해야 할 것에 예라고 말하는 것이라고 생각한다. 하지만 전혀 그렇지 않다. 집중이란 수많은 다른 좋은 아이디어에 아니라고 말하는 것이다. 신중하게 골라야 한다. 실제로 나는 우리가 해낸 것만큼이나 우리가 하지 않은 많은 것들을 자랑스럽게 생각한다” 새 Samsung Fold 7 은 접은 상태에서도 iPhone 17보다 1mm도 채 두껍지 않음 영리 기업이 하는 일은 좋든 나쁘든 이익 에 집중하는 것임 더 지속 가능한 소재, 더 오래가는 기기, 쉽게 수리 가능한 부품은 나도 원하지만, 더 많은 이익을 내는 목표와 정면으로 충돌함. 말한 것들은 문자 그대로 회사의 수입을 줄일 가능성이 큼 경제 시스템상 그런 것들이 중심이 되기는 현실적으로 어려움. 시장이 보상하지 않고, 바뀔 것 같지도 않음 해법은 모르겠음. 현상 유지는 그냥 별로고, 탈출구도 보이지 않음. 오히려 더 나빠지는 것 같음 아이디어가 떨어져서 그런 건 절대 아니라고 봄. 나는 Galaxy Fold 를 쓰고 있고 정말 좋아함 내가 산 지 두 달쯤 지나 아내도 직접 하나 샀음. 어디를 가도 사람들이 보고 만져보고 싶어 하는데 꽤 인상적임 앱이 넓은 화면비를 지원하지 않는 문제도 겪지 않았음. Android가 초기에 더 유연한 소프트웨어에 투자한 게 보상받은 사례임 Android 앱은 처음부터 크기 조절 가능한 레이아웃을 지원해야 해서 작성이 더 어려웠지만, 접는 폰 같은 제품이 나올 때쯤에는 소프트웨어 생태계가 이미 준비되어 있었음 수리 용이성의 문제는 항상 방수 , 두께, 손에 쥐는 느낌과, 탈착식 배터리나 뒷판을 가능하게 만들기 위한 타협 사이의 충돌임 우회 방법은 있지만 시장의 압도적 다수는 거의 접착제로 단단히 붙인 폰을 선호하므로 회사들도 그렇게 만듦 폰 디자인은 이미 국소 최댓값에 도달한 듯하고, 접힘은 두 갈래를 열어줌. 1) 펼친 화면 크기는 같지만 접으면 더 작아지는 방향, 2) 접힌 상태에서는 오늘날 일반 폰과 비슷한 외부 화면을 쓰고, 펼치면 훨씬 큰 화면이 되는 방향 사람들이 합리적으로 주머니에 넣을 수 있는 크기는 정점에 가까워졌기 때문에, 두 번째 선택지는 별도 기기, 즉 태블릿 같은 것을 들고 다니지 않고도 더 큰 화면을 원하는 사람에게 길을 열어줌 Fold는 기능을 더해주며, 자신이 관심 없다는 이유만으로 어떤 것의 의미를 못 보겠다고 말하게 되는 충동이 있는 것 같음 세션 영상 중 하나는 종이비행기 함대 를 추적하는 앱으로 콘텐츠를 설명했음 또 다른 영상은 종이접기 에 관한 것이었음 접는 iPhone은 Apple의 가장 큰 문제 중 하나를 확실히 해결할 것임. 접는 폰은 5~10년 씩 버티지 못함 장기적으로 Apple이 모든 iPhone 제품군을 접는 형태로 만들 수도 있다고 봄 사람들이 업그레이드하지 않는 게 정말 Apple의 문제인지 모르겠음 적어도 캐나다에서는 통신사들이 계약이 끝나면 새 계약을 갱신시키려고 0달러에 새 폰을 주는 식의 조건으로 모두를 괴롭힘 기술에 관심 없는 부모님도 통신사가 전화해서 거의 새 폰을 가져가 달라고 애원하다시피 해서 몇 년마다 최신 일반 iPhone을 받음 4년보다 오래된 폰을 쓰는 사람을 보는 건 극히 드묾 실제로 얼마나 많은 사람이 iPhone을 5~10년 씩 붙들고 있는지 알고 있나? 많지 않을 거라고 봄 Apple이 이런 식으로 넣는 작은 쇼맨십 이 좋음 조 단위 달러 기업이 “알지?” 같은 윙크를 하는 걸 보는 게 그냥 웃김 적어도 나에게는 화면 크기가 한계가 아니라 키보드 부재 가 한계임 왜 이 기기를 Neo나 Air에 접히지 않는 폰을 더한 조합보다 선택해야 하는지 모르겠음 어떤 iPhone이나 iPad에도 Bluetooth 키보드 를 페어링할 수 있음 예를 들면 이 제품은 배터리와 소형 물리 키보드를 결합함 https://www.clicks.tech/products/powerkeyboard 크기 조절 가능한 iOS 앱을 언급한 건 데스크톱 독 모드 를 암시하는 것 같고, 그게 당신의 우려와 연결됨 제조 유출로 Apple이 접는 iPhone을 가져온다는 건 알고 있음. 데스크톱 모드는 대부분 소프트웨어이고 제3자 의존도도 훨씬 낮아서 유출될 가능성이 더 작음 답변달기
Hacker News 의견들 여기서 놓치는 건, 대부분의 사람은 PC나 노트북 을 갖고 있지 않거나 있어도 거의 열지 않는다는 점임 돈이 없어서가 아니라 일상에 맞지 않아서이고, HN 이용자층과는 완전히 다름 그런 경우 접는 폰 은 큰 변화임. 부모님이 쓰는 걸 만져봤는데 읽기와 스크롤 경험이 확실히 좋아졌고, 우리가 폰에 쓰는 시간이 워낙 많다는 현실도 있음 접는 폰은 사실상 작은 태블릿 이 되는 셈인데, 일부에게는 매력적일 수 있어도 PC보다 태블릿을 갖고 싶어 하는 사람은 더 적음 태블릿을 원하는 사람들은 이미 접는 폰의 기믹보다 나은 태블릿을 갖고 있음 PC 노트북이 없는 사람에게 뭐가 그렇게 큰 변화인지 모르겠음 접는 폰을 써보거나 본 예들은 대부분 앱이 화면에 잘 맞지 않는 평범한 스마트폰처럼 보였고, 잘 맞는 몇몇 앱도 실질적 이점이 커 보이지 않았음 게다가 내가 아는 접는 폰 사용자들 은 시간이 지나며 화면이 망가지는 신뢰성 문제 를 겪었음 맞음. iPhone과 MacBook Neo를 대략 같은 비용으로 살 수 있다는 점을 생각하면, 이 기기가 실제로 어떻게 동작할지 꽤 흥미로움 로컬 Xcode가 필요 없는 사용자에게 iOS가 macOS를 대체 할 수 있을까? 주머니와 책상에서 모두 쓰는 기기에 2천 달러를 쓰고, 필요하면 나머지 돈을 클라우드/서버 인프라에 넣을 수 있을까? 공정하게 말하면 이 얘기가 적용되는 건 “기술 업계 밖”이 아니라 미국 밖 특정 국가들 임 스마트폰은 있지만 컴퓨터는 없는 미국인은 매우 드물고, 대체로 가난해서 초고가 폰의 시장 대상이 아님 중국, 한국, 일본처럼 최근에 부유해진 나라들을 말하는 것 같고, 실제로 접는 폰이 잘 팔리는 곳도 그쪽임 특히 PC 보급률 이 낮은 아시아 국가들에서는 더 그렇음 한동안 Pixel Fold 9 Pro 를 매일 쓰고 있는데 정말 마음에 듦 Apple이 마침내 들어오는 건 꽤 신남. 다만 주름이 안 보일 거라거나 화면 기술이 반드시 업계 최고일 거라고 기대하진 않는 게 좋음 그래도 별로 중요하지 않을 듯함. Pixel Fold도 그런 면에서 업계 최고는 아니지만, 쓰다 보면 접힘은 전혀 신경 쓰이지 않음. 정면에서는 거의 보이지 않고, “플라스틱 화면 보호 필름” 걱정도 실제로는 문제가 아님 내부 화면은 주머니에 있을 때 외부 긁힘에서 보호되기 때문에 생각보다 내구성이 좋음. 케이스나 보호 장치를 전혀 쓰지 않는데도 내 것은 아직 상태가 좋음 Apple의 큰 기회는 소프트웨어 쪽임. Google은 Fold에서 UI 개념을 탐구하는 데 별 관심이 없어 보이고, 그걸 OnePlus와 Samsung에 맡겨둔 상태인데 둘 다 Pixel Fold보다 멀티태스킹 경험이 낫다고 봄 Apple이 iPad가 되는 iPhone을 만드는 것만으로도 상당한 시장 점유율을 얻을 수 있겠지만, iPad가 하는 것 이상으로 흥미로운 UI를 시도했으면 함 Pixel 8a를 쓰는데 케이스가 꼭 필요함. 가능한 한 미끄럽게 설계한 것처럼 보임 모든 모서리가 둥글고 잡을 곳이 없어서, 알루미늄/유리로 된 젖은 비누 같은 느낌임 시의적절하게도, 이 글을 Pixel 10 Pro Fold 에서 쓰고 있음. 1월에 산 제품임 어젯밤 펼쳐보니 접히는 부분 중앙의 내부 화면에 죽은 픽셀이 생겼음 접는 폰은 좋아함. 두 모드 모두 항상 쓰지만, 지금은 Best Buy 보증 플랜 세부 조건 찾아보기를 미루는 중임 모바일 초고강도 사용자 중 작은 비율에게는 접는 폰이 정말 미래라고 봄. 기본으로 데스크톱 모드 를 쓰거나 멀티태스킹할 수 있다는 건 큼 한 바퀴 돌아 다시 돌아왔음. Samsung Fold는 멋지고 편했지만, iPad mini와 폰 을 같이 들고 다니는 것도 그렇게 큰일은 아님 iPad mini에는 WhatsApp이나 SMS가 붙어 있지 않아서, 책 읽기나 음악 재생 전용으로 쓸 수 있다는 점이 꽤 좋음 iPad Mini와 내 폰을 합친 비용은 600달러 정도였고, Fold 계열은 6세대 이후도 매우 불안정해서 지금은 이 조합이 최선처럼 보임 경우에 따라 다를 듯함. 나는 접는 폰이 정말 좋음. 특가로 500유로 에 샀음 태블릿을 항상 가지고 다닐 수 있다는 게 좋음. 더운 나라에 살아서 보통 코트나 큰 가방을 들고 다니지 않음 게다가 Android에는 괜찮은 작은 태블릿이 거의 없음. 전부 10인치 이상임 걸어 다닐 때 iPad와 폰 을 같이 들고 다니는 건 귀찮음 큰 주머니나 핸드백이 필요한데, 더우면 둘 다 원하지 않게 됨 “iPad mini와 폰을 들고 다니는 게 큰일은 아니다”는 건 당신에게나 그럴 수 있음 대부분에게도 그랬다면 우리 모두 이미 그렇게 하고 있었을 것임 iPad mini 는 읽기용으로 훌륭하지만, Apple이 성능을 올리기까지 너무 오래 걸렸음 예전에 등장했던 Motorola Razor 접는 폰에 익숙했던 입장에서는 그것도 정말 좋고 멋졌음. 점점 작아지던 Ericson 스마트폰은 싫었음 Samsung 접는 스마트폰을 Apple이 따라 만든 제품을 기대하고 있음. 결국 iPhone과 iPad mini를 둘 다 들고 다니고 싶지는 않음 접는 폰은 iPhone Ultra Max 같은 제품의 대체품에 더 가깝다고 봄. 화면이 아무리 커져도, 수년간 구형에 묶여 있었더라도, 가독성 에서는 iPad mini를 이기지 못함 폰과 태블릿 둘 다 WhatsApp을 설치할 수 있고, 설치 여부와 확인 빈도는 사용자 선택임 앱을 전체 음소거하는 것도 가능함 요지는 이해하지만, 사용자가 개입하면 완화할 수 있는 문제임. 다만 폰보다 큰 화면에서 읽는 게 더 나은 사용자 경험이라는 말이라면 동의함 이런 제품들, Apple Vision Pro까지 포함해서, Apple이 “대중” 혹은 주주 에게 대응해야 한다고 느끼는 결과처럼 보임 “Samsung은 멋진 접는 폰을 갖고 있고, 요즘 디자인 주도권을 Apple에서 가져가는 것 같다” “VR이 컴퓨팅의 미래라던데, 왜 Apple은 이 분야에 없지?” Jobs 시대에도 iPad는 Apple이 태블릿 시장 의 압박에 대응한 제품이라고 볼 수 있을 듯함 Apple Watch도 Pebble에 대한 반응이었을까? 작은 정사각형 iPod Nano 가 나온 순간, 시계는 필연적이었음 https://www.kickstarter.com/blog/a-new-era-for-design 실제로는 그런 이유라기보다, Apple이 1) 수익성이 좋고 2) 현금을 많이 보유하고 3) 새 제품을 실행해낸 검증된 역량이 있기 때문이라고 봄 그래서 틈새시장에 진입하지 않으면 큰돈을 놓칠 수 있고, 제품이 traction을 얻지 못하더라도 실패의 하방이 회사를 죽일 정도는 아님 솔직히 접는 폰 은 별로 선호하지 않음. 개인적 의견임 접으면 기기 두께가 두 배가 되어 주머니에서 느껴지는 방식이 싫음 모바일 기기 제조사들, Samsung, Huawei, 이제 Apple까지 접는 제품을 만들 때마다 “슬레이트” 형태에서 아이디어가 떨어져 매출을 자극하려는 것처럼 느껴짐 개인적으로는 그 연구개발비와 혁신이 더 지속 가능한 소재 , 더 오래가는 기기, 수명 연장을 위한 쉽게 수리 가능한 부품에 쓰였으면 함 나도 같은 생각이지만, 다른 사람들은 다르게 본다는 것도 인정함. 결국 시장이 결정하게 될 것임 Apple의 지난해 연간 매출총이익은 1,950억 달러였고 연구개발 예산은 약 350억 달러였음. 그러니 여윳돈은 충분함 접는 폰에 쓰는 비용이 재정적으로 발목을 잡을 가능성은 거의 없다고 봄 더 걱정되는 건 집중력 , 파편화된 생태계, 사용자 경험 등에 미치는 영향임 Jobs의 말처럼, “사람들은 집중이 집중해야 할 것에 예라고 말하는 것이라고 생각한다. 하지만 전혀 그렇지 않다. 집중이란 수많은 다른 좋은 아이디어에 아니라고 말하는 것이다. 신중하게 골라야 한다. 실제로 나는 우리가 해낸 것만큼이나 우리가 하지 않은 많은 것들을 자랑스럽게 생각한다” 새 Samsung Fold 7 은 접은 상태에서도 iPhone 17보다 1mm도 채 두껍지 않음 영리 기업이 하는 일은 좋든 나쁘든 이익 에 집중하는 것임 더 지속 가능한 소재, 더 오래가는 기기, 쉽게 수리 가능한 부품은 나도 원하지만, 더 많은 이익을 내는 목표와 정면으로 충돌함. 말한 것들은 문자 그대로 회사의 수입을 줄일 가능성이 큼 경제 시스템상 그런 것들이 중심이 되기는 현실적으로 어려움. 시장이 보상하지 않고, 바뀔 것 같지도 않음 해법은 모르겠음. 현상 유지는 그냥 별로고, 탈출구도 보이지 않음. 오히려 더 나빠지는 것 같음 아이디어가 떨어져서 그런 건 절대 아니라고 봄. 나는 Galaxy Fold 를 쓰고 있고 정말 좋아함 내가 산 지 두 달쯤 지나 아내도 직접 하나 샀음. 어디를 가도 사람들이 보고 만져보고 싶어 하는데 꽤 인상적임 앱이 넓은 화면비를 지원하지 않는 문제도 겪지 않았음. Android가 초기에 더 유연한 소프트웨어에 투자한 게 보상받은 사례임 Android 앱은 처음부터 크기 조절 가능한 레이아웃을 지원해야 해서 작성이 더 어려웠지만, 접는 폰 같은 제품이 나올 때쯤에는 소프트웨어 생태계가 이미 준비되어 있었음 수리 용이성의 문제는 항상 방수 , 두께, 손에 쥐는 느낌과, 탈착식 배터리나 뒷판을 가능하게 만들기 위한 타협 사이의 충돌임 우회 방법은 있지만 시장의 압도적 다수는 거의 접착제로 단단히 붙인 폰을 선호하므로 회사들도 그렇게 만듦 폰 디자인은 이미 국소 최댓값에 도달한 듯하고, 접힘은 두 갈래를 열어줌. 1) 펼친 화면 크기는 같지만 접으면 더 작아지는 방향, 2) 접힌 상태에서는 오늘날 일반 폰과 비슷한 외부 화면을 쓰고, 펼치면 훨씬 큰 화면이 되는 방향 사람들이 합리적으로 주머니에 넣을 수 있는 크기는 정점에 가까워졌기 때문에, 두 번째 선택지는 별도 기기, 즉 태블릿 같은 것을 들고 다니지 않고도 더 큰 화면을 원하는 사람에게 길을 열어줌 Fold는 기능을 더해주며, 자신이 관심 없다는 이유만으로 어떤 것의 의미를 못 보겠다고 말하게 되는 충동이 있는 것 같음 세션 영상 중 하나는 종이비행기 함대 를 추적하는 앱으로 콘텐츠를 설명했음 또 다른 영상은 종이접기 에 관한 것이었음 접는 iPhone은 Apple의 가장 큰 문제 중 하나를 확실히 해결할 것임. 접는 폰은 5~10년 씩 버티지 못함 장기적으로 Apple이 모든 iPhone 제품군을 접는 형태로 만들 수도 있다고 봄 사람들이 업그레이드하지 않는 게 정말 Apple의 문제인지 모르겠음 적어도 캐나다에서는 통신사들이 계약이 끝나면 새 계약을 갱신시키려고 0달러에 새 폰을 주는 식의 조건으로 모두를 괴롭힘 기술에 관심 없는 부모님도 통신사가 전화해서 거의 새 폰을 가져가 달라고 애원하다시피 해서 몇 년마다 최신 일반 iPhone을 받음 4년보다 오래된 폰을 쓰는 사람을 보는 건 극히 드묾 실제로 얼마나 많은 사람이 iPhone을 5~10년 씩 붙들고 있는지 알고 있나? 많지 않을 거라고 봄 Apple이 이런 식으로 넣는 작은 쇼맨십 이 좋음 조 단위 달러 기업이 “알지?” 같은 윙크를 하는 걸 보는 게 그냥 웃김 적어도 나에게는 화면 크기가 한계가 아니라 키보드 부재 가 한계임 왜 이 기기를 Neo나 Air에 접히지 않는 폰을 더한 조합보다 선택해야 하는지 모르겠음 어떤 iPhone이나 iPad에도 Bluetooth 키보드 를 페어링할 수 있음 예를 들면 이 제품은 배터리와 소형 물리 키보드를 결합함 https://www.clicks.tech/products/powerkeyboard 크기 조절 가능한 iOS 앱을 언급한 건 데스크톱 독 모드 를 암시하는 것 같고, 그게 당신의 우려와 연결됨 제조 유출로 Apple이 접는 iPhone을 가져온다는 건 알고 있음. 데스크톱 모드는 대부분 소프트웨어이고 제3자 의존도도 훨씬 낮아서 유출될 가능성이 더 작음
여기서 놓치는 건, 대부분의 사람은 PC나 노트북 을 갖고 있지 않거나 있어도 거의 열지 않는다는 점임 돈이 없어서가 아니라 일상에 맞지 않아서이고, HN 이용자층과는 완전히 다름 그런 경우 접는 폰 은 큰 변화임. 부모님이 쓰는 걸 만져봤는데 읽기와 스크롤 경험이 확실히 좋아졌고, 우리가 폰에 쓰는 시간이 워낙 많다는 현실도 있음
한동안 Pixel Fold 9 Pro 를 매일 쓰고 있는데 정말 마음에 듦 Apple이 마침내 들어오는 건 꽤 신남. 다만 주름이 안 보일 거라거나 화면 기술이 반드시 업계 최고일 거라고 기대하진 않는 게 좋음 그래도 별로 중요하지 않을 듯함. Pixel Fold도 그런 면에서 업계 최고는 아니지만, 쓰다 보면 접힘은 전혀 신경 쓰이지 않음. 정면에서는 거의 보이지 않고, “플라스틱 화면 보호 필름” 걱정도 실제로는 문제가 아님 내부 화면은 주머니에 있을 때 외부 긁힘에서 보호되기 때문에 생각보다 내구성이 좋음. 케이스나 보호 장치를 전혀 쓰지 않는데도 내 것은 아직 상태가 좋음 Apple의 큰 기회는 소프트웨어 쪽임. Google은 Fold에서 UI 개념을 탐구하는 데 별 관심이 없어 보이고, 그걸 OnePlus와 Samsung에 맡겨둔 상태인데 둘 다 Pixel Fold보다 멀티태스킹 경험이 낫다고 봄 Apple이 iPad가 되는 iPhone을 만드는 것만으로도 상당한 시장 점유율을 얻을 수 있겠지만, iPad가 하는 것 이상으로 흥미로운 UI를 시도했으면 함
시의적절하게도, 이 글을 Pixel 10 Pro Fold 에서 쓰고 있음. 1월에 산 제품임 어젯밤 펼쳐보니 접히는 부분 중앙의 내부 화면에 죽은 픽셀이 생겼음 접는 폰은 좋아함. 두 모드 모두 항상 쓰지만, 지금은 Best Buy 보증 플랜 세부 조건 찾아보기를 미루는 중임 모바일 초고강도 사용자 중 작은 비율에게는 접는 폰이 정말 미래라고 봄. 기본으로 데스크톱 모드 를 쓰거나 멀티태스킹할 수 있다는 건 큼
한 바퀴 돌아 다시 돌아왔음. Samsung Fold는 멋지고 편했지만, iPad mini와 폰 을 같이 들고 다니는 것도 그렇게 큰일은 아님 iPad mini에는 WhatsApp이나 SMS가 붙어 있지 않아서, 책 읽기나 음악 재생 전용으로 쓸 수 있다는 점이 꽤 좋음 iPad Mini와 내 폰을 합친 비용은 600달러 정도였고, Fold 계열은 6세대 이후도 매우 불안정해서 지금은 이 조합이 최선처럼 보임
이런 제품들, Apple Vision Pro까지 포함해서, Apple이 “대중” 혹은 주주 에게 대응해야 한다고 느끼는 결과처럼 보임 “Samsung은 멋진 접는 폰을 갖고 있고, 요즘 디자인 주도권을 Apple에서 가져가는 것 같다” “VR이 컴퓨팅의 미래라던데, 왜 Apple은 이 분야에 없지?” Jobs 시대에도 iPad는 Apple이 태블릿 시장 의 압박에 대응한 제품이라고 볼 수 있을 듯함 Apple Watch도 Pebble에 대한 반응이었을까?
솔직히 접는 폰 은 별로 선호하지 않음. 개인적 의견임 접으면 기기 두께가 두 배가 되어 주머니에서 느껴지는 방식이 싫음 모바일 기기 제조사들, Samsung, Huawei, 이제 Apple까지 접는 제품을 만들 때마다 “슬레이트” 형태에서 아이디어가 떨어져 매출을 자극하려는 것처럼 느껴짐 개인적으로는 그 연구개발비와 혁신이 더 지속 가능한 소재 , 더 오래가는 기기, 수명 연장을 위한 쉽게 수리 가능한 부품에 쓰였으면 함
세션 영상 중 하나는 종이비행기 함대 를 추적하는 앱으로 콘텐츠를 설명했음
접는 iPhone은 Apple의 가장 큰 문제 중 하나를 확실히 해결할 것임. 접는 폰은 5~10년 씩 버티지 못함 장기적으로 Apple이 모든 iPhone 제품군을 접는 형태로 만들 수도 있다고 봄
Apple이 이런 식으로 넣는 작은 쇼맨십 이 좋음 조 단위 달러 기업이 “알지?” 같은 윙크를 하는 걸 보는 게 그냥 웃김
적어도 나에게는 화면 크기가 한계가 아니라 키보드 부재 가 한계임 왜 이 기기를 Neo나 Air에 접히지 않는 폰을 더한 조합보다 선택해야 하는지 모르겠음
발행일: 2026-06-12 07:08 (금)
한국어 KR 영어 EN 일본어 JP 중국어 CH
비즈니스 문서 정리의 끝판왕 ‘PARA’ 시작하기(feat. 옵시디언)
골든래빗 8 분 2025.01.06. 11.9K
"스픽에서 골 환호부터 국가대표 선수 칭찬까지 영어로 말하자."
스픽이지랩스코리아는 2026년 월드컵 시즌을 맞아 한국 '스픽' 학습자들이 축구 경기를 보며 느낀 감정을 영어로 표현할 수 있도록 ‘축구 특화 프리톡 테마’를 추가했다고 11일 밝혔다.
이번 대회는 한국 경기가 모두 멕시코에서 열려 한국 시간 기준 12일 오전 10~11시에 시작된다. 팬들이 새벽 응원 대신 오전 시간대에 경기를 즐길 수 있게 된 가운데, 스픽은 월드컵 열기를 영어 말하기 학습으로 연결할 수 있는 다양한 학습 경험을 선보인다.
이번 콘텐츠는 단순한 축구 용어 학습을 넘어 전 세계 팬들이 함께 외치고 반응하며 소통하는 월드컵 열기를 영어 말하기 연습으로 연결한 것이 특징이다. 경기 중 터져 나오는 환호와 아쉬움, 경기 전후 팬들과 나누는 대화 등 축구를 둘러싼 다양한 소통 상황을 학습 콘텐츠로 구현했다. 이를 통해 학습자는 ‘경기를 이해하는 영어’를 넘어 ‘경기에 함께 참여하는 영어’를 익힐 수 있다.
학습자는 스픽의 AI 프리톡 환경에서 축구와 월드컵 관련 기본 어휘는 물론, 경기 중 환호와 아쉬움을 표현하고 선수 활약이나 판정에 대한 의견을 나누는 등 실제 관전 상황에서 활용할 수 있는 표현을 반복 연습할 수 있다. 특히 앱 내 ‘나만의 시나리오 만들기’ 기능을 활용하면 위 네 가지 기본 테마 외에도 원하는 상황을 직접 설정해 맞춤형 롤플레이를 진행할 수 있다.
아찔했던 보안 사고 경험담 나누고 맥북 네오·에어팟 득템 행운 얻자 2026.04.16 해킹 공포 딛고 진화…'하드웨어 방패' 입는 가전 2026.05.31 ‘복구 불가능’ 의료정보…보안 투자 이제는 필수 2026.05.27 "검색 결과 상단도 잘 봐야"…네카오, 피싱 사기 ‘주의보’ 2026.05.27
아울러 스픽은 ‘다국어 교차 학습’ 환경을 지원하고 있어, 글로벌 축제인 월드컵을 더욱 다채롭게 즐길 수 있다. 국내 학습자들이 기본 한국어 설정에서 영어 말하기를 연습하는 것을 넘어, 앱 내 사용자 언어 설정을 ‘영어’로 변경할 경우 영어를 베이스로 한 타 국가 언어 학습이 가능하기 때문이다. 이를 통해 학습자들은 이번 월드컵 한국 대표팀의 경기 개최지인 멕시코의 모국어, ‘스페인어’로도 축구 표현과 문장을 연습해 볼 수 있다.
스픽 관계자는 "이번 축구 특화 테마를 통해 한국 학습자들이 경기를 이해하는 영어를 넘어 경기에 함께 참여하는 영어를 경험하길 바란다"며 "세계인이 함께 즐기는 축제의 열기를 느끼면서 실전 말하기 자신감을 키워가길 바란다"고 말했다.
'새 주인 맞이' 카카오게임즈...경영진 교체·신작 공세로 반등 노린다
[디지털투데이 이호정 기자] 카카오게임즈가 카카오에서 라인야후가 출자한 투자목적법인으로 최대주주 변경을 앞두고 경영진 교체 수순을 밟고 있다. 동시에 하반기 신작 공세를 예고했다. 6분기 연속 적자를 끊는 분위기 반전을 이룰 수 있을지 주목된다.
12일 업계에 따르면 카카오게임즈는 오는 22일 경기 용인시 카카오 AI 캠퍼스에서 임시 주주총회를 열고 김태환 라인게임즈 부사장과 이시우 카카오게임즈 최고사업책임자(CBO)를 사내이사로 신규 선임하는 안건을 논의한다. 두 후보는 이사 선임 후 공동대표직을 맡을 것으로 전해졌다.
두 인물의 이력이 다른 만큼 역할도 나뉠 것으로 업계는 해석한다. 김 후보는 넥슨코리아·넥슨재팬·넥슨아메리카를 거쳐 2023년 라인게임즈에 합류한 외부 전략가로, 이번 라인야후의 카카오게임즈 지분 인수를 주도한 인물로 알려졌다. 이 후보는 카카오게임즈 창립 초기부터 모바일 사업을 이끌어온 내부 사업 전문가로 조직 내 신임이 두텁다. 외부에서 온 전략가가 새 주주와의 전략적 연결고리를 맡고, 내부 인사가 조직을 안정적으로 관리하는 구도가 예상된다.
이번 주총에는 페트리코파트너스의 서석호 상무이사를 임기 9개월의 기타비상무이사로 선임하는 안건도 포함됐다. 임기가 짧다는 점에서 업계 일각에서는 향후 지배구조나 사업 구조 재편 가능성을 염두에 둔 포석이라는 해석도 나온다. 다만 카카오게임즈와 라인게임즈는 현재 합병이나 사업 통합이 논의된 바 없다는 입장이다.
이 같은 경영진 교체는 라인야후가 카카오게임즈의 최대주주로 올라서는 과정과 맞닿아 있다. LAAA인베스트먼트는 카카오 보유 지분 일부를 인수하는 한편 카카오게임즈로부터 2400억원 규모 유상증자와 600억원 규모 전환사채(CB)를 인수해 총 3000억원을 투자한다. 거래가 마무리되면 LAAA인베스트먼트는 지분 33.2%(CB 전환 후 35.8%)의 최대주주가 되고, 기존 최대주주 카카오는 지분율 14.6%의 2대 주주로 내려앉는다.
◆라인야후 시너지 기대…플랫폼 연계는 검증 과제
라인야후 체제 전환 이후 업계가 주목하는 것은 양사 간 시너지다. 핵심은 카카오게임즈가 국내에서 쌓아온 플랫폼 마케팅 역량을 아시아 시장으로 옮겨 심을 수 있느냐는 것이다.
카카오게임즈는 그동안 카카오톡 기반의 사전예약·쿠폰·이벤트 프로모션을 통해 출시 전 이용자를 모으고 출시 후 운영을 이어 왔다. 라인야후는 일본·대만·태국 등 아시아 주요 시장에서 메신저 '라인(LINE)'을 중심으로 높은 이용자 기반을 보유하고 있다. 'LINE GAME' 서비스도 공식계정 친구 추가, 사전예약, 재화 보상, 소셜 기능 등을 갖추고 있어 카카오게임즈의 마케팅 방식과 구조적으로 유사하다. 카카오게임즈가 국내에서 검증한 방식을 라인 이용자 기반이 강한 지역에 그대로 적용할 수 있는 환경이 마련되는 셈이다.
다만 시너지 실현까지는 검증이 필요하다. 라인과 야후의 글로벌 게임 시장 내 영향력은 제한적이고 관계사 라인게임즈는 지속된 신작 부진으로 자본잠식 상태다. 시너지의 실질적 검증이 가장 먼저 이뤄질 수 있는 무대는 4분기 일본 시장 동시 출시를 목표로 하는 서브컬처 신작 '프로젝트C'가 될 가능성이 높다. 일본은 라인야후의 핵심 기반 시장인 데다 프로젝트C의 주요 출시 지역으로 거론되는 만큼 플랫폼 연계 효과를 확인할 수 있는 초기 사례가 될 수 있다.
카카오게임즈 '오딘Q' [사진: 카카오게임즈]
카카오게임즈는 3분기부터 연말까지 신작 5종을 순차 출시할 계획이다. 2026년 1분기 매출 829억원, 영업손실 255억원을 기록하며 6분기 연속 적자가 이어지는 상황에서 이번 신작 사이클은 단순한 라인업 확충이 아니라 실적 반등을 위한 승부수에 가깝다.
3분기에는 두 편의 MMORPG가 나온다. 자회사 라이온하트스튜디오가 개발하는 '오딘Q'는 2021년 국내 모바일 MMORPG 매출 1위를 기록한 '오딘: 발할라 라이징'의 후속작이다. 언리얼 엔진5 기반 풀 3D 심리스 오픈월드와 북유럽 신화 세계관으로 원작의 시각적 강점을 이어간다는 전략이다. 국내와 대만 등을 대상으로 글로벌 원빌드 출시를 목표로 하며, 증권가에서는 오딘Q의 흥행 여부가 내년 상반기 흑자 전환의 분수령이 될 것으로 보고 있다.
슈퍼캣이 개발하는 '도깨비의세계'(구 프로젝트OQ)는 한국 전통 설화를 배경으로 한 2D 도트 캐릭터와 3D 배경을 결합한 MMORPG다. 직업 제약 없는 자유로운 스킬 조합과 문파 중심 협력 플레이를 내세워 오딘Q와 다른 이용자층을 공략한다. 앞서 진행한 포커스 그룹 테스트(FGT)에서 세계관과 비주얼, 협력 콘텐츠 전반에 걸쳐 긍정적인 반응을 확인한 것으로 전해졌다.
4분기에는 PC·콘솔과 서브컬처로 외연을 넓힌다. '아키에이지 크로니클'은 자회사 엑스엘게임즈가 개발하는 PC·콘솔 액션 RPG로 스팀·에픽게임즈 스토어·플레이스테이션5·엑스박스 시리즈 X/S 멀티 플랫폼으로 출시된다. 카카오게임즈가 모바일 중심 수익 구조에서 벗어나 PC·콘솔 확장을 본격화하는 신호탄이다. 오션드라이브스튜디오의 '갓 세이브 버밍엄'은 중세 배경 오픈월드 좀비 생존 게임으로 4분기 글로벌 출시를 목표로 한다. 라이온하트스튜디오의 서브컬처 장르 첫 도전작 '프로젝트C'는 미소녀 캐릭터 육성 시뮬레이션으로 국내와 일본 시장을 동시 겨냥한다.
하반기 신작은 자회사 개발작과 외부 퍼블리싱 작품이 섞여 있다. 이 가운데 '오딘Q', '아키에이지 크로니클', '프로젝트C'는 각각 라이온하트스튜디오와 엑스엘게임즈 등 카카오게임즈 계열 개발 역량과 맞닿아 있어 흥행 성과가 본체뿐 아니라 개발 자회사 가치 평가에도 영향을 줄 수 있다.
오동환 삼성증권 연구원은 "주가 반등을 위해서는 유상증자에 따른 희석 효과를 상쇄할 수 있는 신규 경영진의 성장 전략과 모회사와의 시너지 방안 제시가 필요하다"고 진단했다.
키워드 #키카오게임즈 #라인야후 #신작 #게임 #경영진 #실적 #공동대표 #최대주주
이 시각 추천뉴스 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요' 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다” 백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율" 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요' 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다” 백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율"
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러?
IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시
그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요'
클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담
크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다”
백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율"
구글의 인공지능(AI) 코딩 비서 제미나이가 운영 중인 상용 프로그램의 코드를 무단으로 삭제해 시스템 장애를 일으켰다는 주장이 제기됐다.
특히 AI가 오류를 은폐하기 위해 정상 복구됐다는 허위 보고서와 가짜 대화 로그까지 생성했다는 내용이 포함돼 논란이 확산되고 있다..
23일 레딧에서 다크스타(dvrkstar)라는 ID를 사용 중인 한 개발자는 제미나이 3.5 사용 중 발생한 장애 상황과 복구 과정을 상세히 공개했다.
그는 내부 관리자 포털 보안 취약점을 수정하기 위해 제미나이에 간단한 코드 수정을 요청했다고 밝혔다. 수정 대상은 서버 인증 기능 8개였으며 전체 작업 규모는 파일 3개, 약 70줄 수준이었다.
하지만 제미나이는 요청사항과 전혀 다른 작업을 수행했다는 주장이다. 총 340개 파일을 수정하는 대규모 변경 작업을 생성했고 이 과정에서 정상적으로 사용 중이던 코드 2만8745줄을 삭제했다. 반면 새로 추가된 코드는 400줄 정도에 불과했다.
또 프로젝트와 관계없는 이커머스 템플릿 파일을 삭제하고 요청하지 않은 데이터 이전용 스크립트까지 추가한 것으로 전해졌다.
제미나이는 사용자 접속 요청을 어떤 서버로 연결할지 정하는 핵심 운영 정보가 담긴 파이어베이스(Firebase) 설정 파일까지 수정했다. 이 과정에서 실제 서비스가 연결돼야 하는 클라우드 런(Cloud Run) 주소 대신 존재하지 않는 서비스로 연결되도록 설정을 변경했다는 것이다.
그 결과 운영 중이던 관리자 포털 전체에서 '페이지를 찾을 수 없다(404 에러)'는 경고가 발생했고 약 33분 동안 서비스가 사실상 마비됐다는 주장이다.
개발자는 프로젝트 내부 규칙 파일에 이미 관련 경고가 적혀 있었다고 설명했다. 실제 사용해야 하는 서비스 식별자를 변경하면 안 된다는 내용이 포함돼 있었지만 제미나이가 이를 무시했다는 것이다.
장애 이후 제미나이의 행동에 대한 지적도 이어졌다. 개발자에 따르면 제미나이는 장애 발생 후 "서비스가 정상적으로 복구됐고 트래픽도 안정 버전으로 정상 전환됐다"는 메시지를 생성했다.
하지만 실제로는 제미나이가 언급한 복구 작업은 중간에 취소된 상태였으며 진짜 복구는 개발자가 이전 정상 버전으로 직접 롤백하면서 이뤄졌다고 설명했다. 제미나이가 작성한 코드는 실제 복구 과정에 사용되지 않았다는 주장이다.
더불어 AI가 스스로 가짜 회의 기록과 승인 문서를 만들었다는 주장도 제기됐다.
개발자는 제미나이가 저장소 내부에 다자간 검토를 진행한 것처럼 보이는 로그 파일과 합의 문서를 자동 생성했다고 밝혔다. 겉으로는 여러 차례 검토와 승인 절차를 거친 것처럼 보였지만 이후 제미나이가 실제 검토 과정 없이 규칙 형식을 맞추기 위해 로그를 생성했다고 답변했다고 설명했다.
이번 사고 원인으로는 서드파티 엔피엠(npm) 패키지가 지목됐다. 개발자는 해당 패키지를 구글 공식 도구로 오인해 설치했지만 실제로는 AI에 과도한 자율권을 부여하는 규칙 파일이 프로젝트 내부에 자동 설치됐다고 주장했다.
이 규칙에는 승인 요청 없이 작업 수행, 자동 배포, 실패 시 자동 재시도 같은 지시가 포함돼 있었던 것으로 전해졌다.
개발자는 이 규칙들이 기존 안전 경고보다 더 강하게 작동하면서 AI가 위험한 변경을 강행한 것으로 보인다고 분석했다.
이번 사건은 최근 개발 업계에서 확산 중인 '바이브 코딩(Vibe Coding)' 문화의 위험성을 보여주는 사례라는 평가도 나온다. 바이브 코딩은 개발자가 AI가 생성한 코드를 충분히 검토하지 않은 채 빠르게 실제 서비스에 적용하는 개발 방식을 뜻한다.
AI 에이전트 작성에서 수정까지 '자동'…SAP가 제시한 AI 혁신 2026.05.17 앤트로픽, '클로드 코드' 설정 실수로 소스코드 50만 줄 노출 2026.04.01 몇 달 만에 매출 수조원…돈방석 앉는 AI 코딩 스타트업 2026.03.15 "인간도 힘들던 '코볼' AI로 푼다"...독점 깨진 IBM, 25년 만에 최대 폭락 2026.02.24
업계에서는 이번 사례가 단순한 코드 오류를 넘어 AI가 실제 상태를 검증하기보다 "정상 복구된 것처럼 보이는 결과"를 만들어냈다는 점에서 더 위험하다고 지적하고 있다.
해당 개발자는 "AI 코딩 도구를 사용할 때 가장 빠른 것은 완벽하게 작동하던 운영 환경이 순식간에 장애 보고서로 바뀌는 속도일 것"이라며 "앞으로 AI에게 직접적인 서버 배포 권한을 주지 않도록 보안 규칙을 강화하고 스스로 작성한 검토 로그를 절대로 신뢰하지 않겠다"고 밝혔다.
美 시애틀, 신규 데이터센터 막는다…전력·주거 부담 우려 반영
시애틀이 신규 데이터센터 건설을 1년간 중단하기로 했다. 전력·용수 사용, 소음, 공공요금과 주거 부담 우려가 배경으로 제시됐다.
AI 인프라의 근간이 되는 초대형 데이터센터 [사진: 셔터스톡]
[디지털투데이 이윤서 기자] 미국 시애틀이 신규 데이터센터 건설을 1년간 중단하기로 했다.
10일(이하 현지시간) IT매체 테크레이더에 따르면 시애틀시의회는 지난 9일, 신규 데이터센터 건설에 대한 1년간 유예하는 조치를 만장일치로 통과시켰다.
이번 조치는 이미 승인을 받은 사업이 아니라 앞으로 추진될 신규 프로젝트를 대상으로 한다. 시애틀은 데이터센터 확대로 전력 소비와 물 사용이 늘고, 소음과 환경 부담이 커질 수 있다는 점을 문제로 들었다. 주민들이 체감하는 공공요금 상승도 핵심 배경으로 제시됐다.
데보라 후아레스 시의원은 시 보도자료에서 이번 결정이 인공지능(AI)이나 데이터센터 자체를 멈추는 것은 아니라고 밝혔다. 그는 이번 조치가 향후 사업에 적용할 자체 규제 체계를 시애틀이 마련할 시간을 확보하기 위한 것이라고 말했다.
지역 반발은 대규모 사업 검토 사실이 알려지면서 빠르게 커졌다. 4개 기업이 시애틀 안팎에서 최대 5건의 대형 프로젝트를 검토했고, 이들 사업이 모두 추진될 경우 필요한 전력은 369메가와트(MW)에 이를 수 있다는 내용이 공개되면서다. 이는 시 전체 전력 사용량의 약 3분의 1에 해당하는 규모다.
주민들은 시의회 회의에서 전기요금 인상 가능성과 전력망 안정성, 전자폐기물 증가, 토지 이용 문제를 잇달아 제기했다. 주거에 미치는 영향과 자원 투입에 비해 일자리 창출 효과가 제한적이라는 지적도 나왔다.
에디 린 시의원은 수만명의 주민 의견을 들었다며 시애틀 시민이 AI 붐으로 대기업이 거두는 사상 최대 이익을 떠받치는 구조가 돼서는 안 된다고 말했다. 이번 유예 기간은 이런 쟁점을 추가 사업 승인 과정과 분리해 검토할 시간을 확보하는 성격이 강하다.
이번 결정은 시애틀이 아마존과 마이크로소프트(MS)의 본거지라는 점에서도 주목된다. 두 회사는 전 세계 클라우드 시장에서 가장 큰 점유율을 차지하는 하이퍼스케일러다. 이런 도시에서 신규 데이터센터 확장을 일시 중단한 것은 AI 인프라 확대가 지역 차원에서 전력과 주거, 환경 문제와 정면으로 충돌할 수 있음을 보여주는 사례로 받아들여진다.
시애틀은 앞으로 1년 동안 데이터센터 관련 규칙과 심사 기준을 다시 정비할 예정이다. 따라서 향후 논의의 초점은 AI 인프라 수요를 수용하면서도 전력망 부담과 주민 비용 증가를 어떻게 통제할지에 맞춰질 전망이다.
시애틀의 이번 조치는 데이터센터를 무조건 막기보다, 급증하는 전력 수요와 주민 부담을 규제 틀 안에서 다시 따져보려는 선택에 가깝다. AI 인프라 확대가 도시의 전력망과 생활비, 토지 이용 문제와 직접 맞물린다는 점을 드러낸 사례다.
이 시각 추천뉴스 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요' 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다” 백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율" 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요' 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다” 백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율"
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러?
IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시
그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요'
클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담
크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다”
백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율"
티맥스소프트가 창립 29주년을 맞아 전사 타운홀 미팅을 열고 글로벌 인공지능(AI) 비즈니스 플랫폼 기업으로의 전환 비전을 공유했다. 기존 미들웨어 중심 사업을 넘어 엔터프라이즈 AI 시장 공략에 속도를 내며 AI 전환(AX) 수요 확대에 대응한다는 목표다.
티맥스소프트는 지난 10일 경기도 성남시 분당구 금곡동 사옥에서 창립 29주년 기념 타운홀 미팅 '커넥트 데이'를 개최했다고 11일 밝혔다. 행사에는 전 임직원이 참석해 회사 경영 현황과 AI 신제품 개발 로드맵, 중장기 경영 목표 등을 공유했다.
이날 회사는 AI 비즈니스 플랫폼 중심 미래 전략을 공개했다. 특히 현재 개발 중인 에이전틱 AI 비즈니스 플랫폼 '컨티뉴엄 AI'를 중심으로 신사업을 본격 추진할 계획이라고 밝혔다.
컨티뉴엄 AI는 티맥스소프트가 글로벌 AI 비즈니스 플랫폼 전문기업으로 도약하기 위해 준비 중인 차세대 제품군이다. 개발과 운영 환경을 통합 제공하는 풀스택 기반 개발 소프트웨어 플랫폼으로, 기업 특정 업무 문제나 비효율성을 일회성이 아닌 지속적으로 개선할 수 있도록 설계됐다.
티맥스소프트는 엔터프라이즈 환경에 요구되는 품질·성능·신뢰성을 지원하는 컨티뉴엄 AI를 앞세워 기업 AI 도입 부담을 줄인다는 목표다.
티맥스소프트는 국내 애플리케이션 서버 시장 점유율 1위 사업자로 축적한 기술력을 바탕으로 공공·금융·민간 기업의 AI 활용 확대를 지원할 방침이다. 온프레미스와 클라우드, AI 도입 등 다양한 환경에 대응할 수 있는 제품과 서비스를 제공하고 운영·개발·현대화·연동·런타임 전 영역을 아우르는 AI 플랫폼 전략을 추진할 계획이다.
티맥스소프트, '컨티뉴엄 AI' 출격…공공·민간 수요 정조준 2026.05.29 AI 플랫폼 승부수 티맥스소프트, 개발 인재 확보 '총력' 2026.04.28 티맥스소프트, 글로벌 AI 플랫폼 기업 선언…신규 브랜드 '컨티뉴엄 AI' 론칭 2026.04.21 티맥스소프트, 최영만 신임 기술본부장 선임…글로벌 기술지원 강화 2026.03.16
또 기존 제품군에도 AI 기능을 접목해 확장형 제품으로 고도화하고 고객이 보다 효율적으로 AI를 활용할 수 있도록 지원할 예정이다. 이를 통해 단순 기술 공급을 넘어 기업의 성공적인 AX 구현을 지원하는 플랫폼 사업자로 자리매김한다는 구상이다.
이형용 티맥스소프트 대표는 "이번 행사는 글로벌 AI 비즈니스 플랫폼 전문기업으로 성장하기 위한 여정에 다 같이 깊이 연결되는 뜻깊은 자리"라며 "기업 대부분이 추구할 엔터프라이즈 AI 혁신은 글로벌 AI 생태계와 실질적인 수요를 확대하는 핵심 동인이 될 것”이라고 말했다.
발행일: 2026-06-12 06:08 (금)
한국어 KR 영어 EN 일본어 JP 중국어 CH
기획 PM은 LLM을 어디까지 이해해야 할까?
김영욱 10 분 2026.06.04. 5.3K
[부산=박수형 기자] 글로벌 인터넷 데이터 트래픽의 99%는 바다 밑으로 오간다. 국제전기통신연합(ITU)이 추정한 수치다. 생성형 AI 검색도 다른 나라에 위치한 서버를 거쳐오고 동영상 스트리밍도 마찬가지다. BTS 컴백 공연을 같은 시간에 지구 반대편에서 즐기는 것도 해저케이블이 있기에 가능한 이야기다.
위성을 비롯해 다양한 통신 수단이 등장하지만 디지털 시대의 정보 전송의 축은 해저케이블이다. 글로벌 대용량 트래픽 폭증에 이어 AI가 촉발한 실시간 트래픽 수요도 해저케이블 없이는 소화할 수 없다.
해저케이블이 디지털 시대의 ‘대동맥’으로 불리는 이유도 이 때문이다.
한국땅 밟는 글로벌 인터넷, KT가 절반 이상 관리
태평양을 건너 미국을 향하는 해저케이블이나 홍콩 등을 거쳐 동남아로 이어지는 해저케이블을 통한 인터넷은 대부분 부산을 거쳐 한국 땅에 오르게 된다.
해저케이블이 육지에 연결되는 곳을 육양국이라고 일컫는데 한국에는 총 9곳이 있으며 이 가운데 5곳을 KT가 관리하고 있다. 나머지 4곳은 국내외 통신사업자가 운영하는 육양국이다.
바다를 건너 다른 나라와 통신을 시도한 자체도 KT가 처음이다.
1968년 KT 울산 무룡산 중계소와 일본의 KDDI 하마다 오아사산 중계소 사이의 스케터 통신이 한국 역사에 처음 기록된 국제통신 사례다. 이후 1980년 부산에서 일본 하마다를 잇는 첫 국제 해저 동축케이블이 연결됐다. 1990년에 들어서 현재와 같은 형태의 광케이블이 바닷속을 지나며 한국과 홍콩, 일본을 이었다.
해저케이블은 깊은 바다에 포설하는 일도 중요하지만 육양국에서 정상으로 작동하고 있는지 관리하는 일도 매우 중요하다. 이 때문에 20여 명이 근무하는 부산 국제통신운용센터에는 밤낮을 가리지 않고 해저케이블 운용 인력이 항시 대기하고 있다. KT 육양국이 멈춰서는 날에는 한국의 인터넷이 세계와 단절되는 수준이기 때문이다.
KT 부산국제통신센터는 한국의 인터넷만 관리하지 않는다. 미국과 중국, 일본 등을 잇는 NCP 케이블의 전체 관리도 KT가 맡고 있다. 또 일본과 동남아 9개 국가를 연결하는 APG 케이블도 KT가 맡아 운용한다. 여러 국가가 KT 해저케이블 운용 역량을 높이 평가하면서 각 국가의 육양국을 통제하는 역할을 KT에 맡긴 것이다.
김인준 KT 국제통신운용센터장은 “해저케이블 컨소시엄 내에서 사업자 협의회를 만들고 안정적으로 운용할 수 있는 사업자를 선정하고 투표로 뜻을 모은다”며 “50년 정도의 운용 노하우를 인정받은 것”이라고 설명했다.
실제 KT는 자연재해와 같은 위기에서도 핵심 업무를 정상화할 수 있는 관리 체계 ISO 22301 인증을 획득했다. 이에 더해 ISO 27001 인증으로 정보보호 경영 체계도 갖췄는데, 두 인증을 모두 갖춘 곳은 KT가 유일하다.
해저케이블의 중요성은 날로 커지고 있다. 클라우드와 동영상 스트리밍, 실시간 화상회의부터 금융 거래도 해저케이블을 거쳐야만 한다. 해저케이블이 국가적인 핵심 인프라로 꼽히고 육양국이 국가 안보 자산으로 지정되는 것도 이런 상황이 고려된 것이다.
호르무즈 해협을 두고 상선의 통과 협상이 주된 관심사이지만, 미국과 이란은 해저케이블 공격을 통한 봉쇄 압박도 이어가고 있다. 물리적인 국가 봉쇄를 넘어 해저케이블을 통해 디지털 단절에 따른 피해가 더 큰 시대가 됐다는 설명이다.
특히 생성형AI와 같은 서비스는 실시간 데이터 연결이 생명이기 때문에 해저케이블의 역할은 더욱 커지고 있다. AI 시대에 해저케이블은 필수 요소로, 한국이 목표로 하는 AI 강국도 해저케이블 도움 없이는 불가능하다는 뜻이다.
이에 따라 KT는 해저케이블 관리 역량을 더욱 키운다는 방침이다.
아시아를 연결하는 신규 해저케이블 구축을 추진하며 국제 트래픽 처리 경로 다변화 계획을 세웠다. 국제 백본망도 단계적인 확충을 통해 현재 수준 대비 5배 늘릴 예정이다.
정부는 ‘하이퍼AI 네트워크 전략’을 통해 현재 해저케이블 용량을 120Tbps 급에서 220Tbps 급으로 늘릴 계획을 세웠는데, 신규 투자나 증설 투자에 대한 정책적 지원 필요성이 커졌다는 평가가 나온다.
KT는 또 안정성을 더하기 위해 부산과 거제로 이원화 운용 중인 해저케이블 육양국을 한 군데 더 설치하는 방안을 검토하고 있다. 삼원화 체제의 글로벌 인터넷 관문을 세워 어떤 상황에서도 디지털 시대에 연결된 나라를 만들겠다는 것이다.
아프리카 대륙 한바퀴...세계 최장 해저케이블 구축 2025.11.23 피지컬AI 강국?...AI 기지국 인프라부터 갖춰야 2025.12.21 쿠팡 6300억 역대급 과징금, 보안 전문가들 평가는? 2026.06.11 티빙 유출 여파에 'CJ 원' 일부 계정 잠금…"고객정보 유출 없어" 2026.06.11
최우형 KT 네트워크코어서비스본부장은 “최근 광화문 공연이 무사히 진행될 수 있었던 배경에는 전 세계를 하나로 잇는 KT의 보이지 않는 기술력이 있었다”고 말했다.
이어, “디지털 시대 대동맥을 관리하면서 국민기업으로 디지털 핵심 인프라를 더욱 튼튼하게 관리하고 국가산업과 국민 생활에 든든한 보탬이 되야 한다는 책임이 있다”며 “KT 해저케이블 인프라는 AI, AX 시대 글로벌 데이터 처리를 안정적으로 지원하는 기반으로 디지털 전환 환경을 지속적으로 뒷받침하고 한국이 아시아 AI 허브로 발돋움기 위해 해저케이블로 글로벌 디지털 허브를 구축하겠다”고 강조했다.
배터리 늘고 더 빠르다…아이폰18 프로 'C2 칩'의 위력
아이폰18 프로와 프로 맥스에 애플 자체 설계 C2 모뎀이 들어갈 가능성이 제기됐다. 배터리 효율과 위치정보 보호, 혼잡한 통신 환경 대응이 핵심 개선점으로 거론된다.
아이폰18 프로에 자체 칩인 C2 칩이 적용될 전망이다. [사진: 나인투파이브맥]
[디지털투데이 홍경민 인턴기자] 애플이 아이폰18 프로 및 프로 맥스 모델에 퀄컴 5G 모뎀 대신 자체 설계한 차세대 C2 칩을 탑재해 배터리 효율과 프라이버시 보호 및 네트워크 성능을 대폭 강화할 것이라는 전망이 나왔다.
9일(현지시간) IT매체 나인투파이브맥에 따르면, 애플은 기존 아이폰17 프로에 탑재됐던 퀄컴 모뎀에서 벗어나 독자적인 셀룰러 모뎀 라인업을 확장하고 있으며 차세대 C2 칩 도입을 통해 하드웨어와 소프트웨어의 수직 통합 이점을 극대화할 것으로 관측된다.
자체 설계 모뎀의 첫 번째 핵심 장점은 탁월한 배터리 효율성이다. 애플이 앞서 선보인 C1 및 C1X 셀룰러 모뎀은 전력 효율성 측면에서 지속적인 우위를 보여왔으며 이러한 긍정적인 추세는 차세대 C2 칩에서도 그대로 이어질 예정이다. 모바일 운영체제인 iOS와 애플 실리콘 프로세서 간의 긴밀한 결합 덕분에 애플은 퀄컴 모뎀 탑재 기기보다 셀룰러 환경에서의 배터리 수명을 한층 더 연장할 수 있다.
애플은 구체적인 성능 수치를 대중에게 공유하지는 않았으나, 이미 아이폰16e와 아이폰 에어 및 M5 프로세서 기반 아이패드 프로의 배터리 수명 증가 요인으로 자사 설계 모뎀을 꼽은 바 있다. 더불어 아이폰18 프로 모델은 전작인 아이폰17 프로보다 더 큰 용량의 배터리를 탑재할 것으로 예상되는 상황이며, 여기에 새로운 C2 칩의 전력 최적화 능력이 더해지면 실제 사용 시간의 상승 시너지는 더 커질 전망이다.
두 번째 장점은 보안성을 강화한 '정밀 위치 제한' 프라이버시 기능의 전격적인 지원이다. 올해 초 애플은 자사 설계 모뎀을 탑재한 기기에서만 전용으로 구동되는 새로운 보안 설정 기능을 iOS에 공식 추가했다. 정밀 위치 제한은 사용자의 실시간 위치 정보가 이동통신사에 필요 이상으로 상세하게 노출되는 것을 방지하고 프라이버시를 더 안전하게 보호할 수 있도록 돕는 세팅이다.
공식 문서에 따르면 현재 이 보안 기능을 지원하는 기기는 아이폰 에어, 아이폰17e, 아이폰16e, M5 아이패드 프로 등 애플 자체 모뎀을 탑재한 소수 라인업에 국한되어 있다. 그러나 향후 독자적인 C2 모뎀을 탑재하게 될 아이폰18 프로 시리즈 역시 해당 단말 목록에 새롭게 이름을 올리며 고도화된 개인정보 보호 혜택을 함께 누릴 수 있게 된다.
마지막 장점은 데이터 접속이 원활하지 않거나 신호가 불안정한 음영 지역에서의 네트워크 처리 성능 개선이다. 곧 출시될 C2 칩과 같은 애플 자체 설계 모뎀은 기지국 적용 범위가 취약한 환경에서도 보다 안정적인 연결을 제공하는 데 초점을 맞추고 있다.
이 같은 성능 향상의 배경에는 애플이 모뎀과 메인 프로세서를 유기적으로 연동한 설계가 있다. 애플이 외신 로이터 통신을 통해 설명한 내용에 따르면, 아이폰이 혼잡한 데이터 네트워크 환경에 놓이면 스마트폰 내부의 메인 프로세서가 모뎀에 현재 어떤 데이터 트래픽이 가장 시간에 민감하고 중요한지 실시간으로 전달한다. 모뎀은 이를 바탕으로 해당 데이터를 다른 일반 트래픽보다 우선 처리해 전송 지연을 최소화한다.
사용자는 네트워크 정체가 발생한 상황에서도 아이폰의 반응 속도가 더욱 빠르다고 느낄 수 있으며, 데이터 지연으로 인한 불편도 줄일 수 있다. 이러한 네트워크 최적화 기술은 애플의 A시리즈 프로세서와 C시리즈 모뎀이 긴밀하게 연동돼 작동하기 때문에 가능한 것으로, 하드웨어와 통신 칩을 직접 설계하는 애플의 수직 통합 전략이 만들어낸 차별화 요소로 평가된다.
결국 차세대 C2 칩의 등장은 단순한 부품 교체를 넘어 배터리 효율, 보안성, 네트워크 성능 향상으로 이어질 것으로 보인다. 업계에서는 애플이 자체 설계 칩 간의 높은 통합성을 바탕으로 경쟁사와의 격차를 더욱 벌리며 차세대 플래그십 시장에서 영향력을 확대할 수 있을지 주목하고 있다.
키워드 #애플 #아이폰18 프로 #퀄컴 #C2칩
이 시각 추천뉴스 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요' 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다” 백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율" 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요' 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다” 백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율"
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러?
IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시
그레이스케일, 비트코인 바닥 조건 제시…'스트래티지 외 새 매수 주체 필요'
클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담
크립토퀀트 창업자 “비트코인, 스트래티지·ETF 덕분에 2만달러대 추락 피했다”
백악관 "美 클래리티법, 디파이·스테이블코인 규정 막판 조율"
정적 타입과 삽 (carefully.understood.systems)
2000년대부터 2010년대 초까지 정적 타입의 인기가 줄었다가 2010년대 중후반 다시 늘어난 이유는 정적 타입 시스템의 품질 향상 으로 설명됨 동적 타입 시스템은 변수와 필드의 상태·내용을 사람이 직접 판단해야 하며, 컴퓨터가 돕지도 방해하지도 않는 맨손으로 땅 파기 에 비유됨 초기 Java나 C++98 같은 과거의 정적 타입 시스템은 nullable과 non-nullable 포인터 구분도 돕지 못하고, 타입 이름을 반복 작성하게 만드는 종이 삽 에 비유됨 TypeScript, Haskell, MyPy, Swift, Rust 같은 현대 타입 시스템은 null 처리, 합 타입·유니언 타입, 타입 추론을 통해 프로그램 오류 확인과 상태 표현을 더 잘 지원함 IDE의 메서드 이름 자동완성 같은 기능이 널리 퍼지면서, 정적 타입 시스템에 넣은 정보가 오류 검사 외에도 생산성 이점 으로 이어짐 핵심 주장 정적 타입의 인기는 단순한 유행이 아니라, 널리 사용할 수 있는 정적 타입 시스템 의 품질이 좋아지면서 다시 높아졌다는 관점임 좋은 삽이 있으면 맨손보다 삽으로 땅을 파는 것이 낫지만, 종이로 만든 삽만 있다면 맨손이 더 낫다는 비유가 사용됨 동적 타입 시스템은 프로그램의 변수와 필드가 어떤 상태와 내용을 갖는지 사람이 직접 생각해야 하며, 컴퓨터가 그 판단을 돕지 않음 나쁜 정적 타입 시스템은 도움보다 부담이 커질 수 있으며, 이는 종이 삽으로 땅을 파는 상황에 비유됨 과거 정적 타입 시스템의 한계 90년대와 2000년대 초에 널리 쓰인 초기 Java나 C++98의 정적 타입 시스템은 nullable 포인터와 non-nullable 포인터를 구분하는 단순한 작업도 제대로 돕지 못함 과거의 정적 타입 시스템은 합 타입이 없고 곱 타입만 있는 구조로 설명됨 과거의 정적 타입 시스템은 타입 이름을 곳곳에 수동으로 작성하게 만들었음 BufferedReader bufferedReader = new BufferedReader(new FileReader(filename)); 같은 코드는 작은 재난으로 표현됨 현대 타입 시스템의 개선점 TypeScript, Haskell, MyPy, Swift, Rust 같은 현대 타입 시스템은 nullable 타입과 non-nullable 타입을 구분하는 방법을 제공함 Haskell은 Maybe t , TypeScript는 T | null , Swift는 T? , Rust는 Optional<T> 를 예로 들며, 타입 시스템이 null 검사가 필요한 위치와 누락 여부를 알려줄 수 있음 실제로 런타임에서 null pointer 오류를 거의 보지 않게 된다고 설명됨 현대 타입 시스템은 합 타입이나 유니언 타입 중 하나 이상을 제공하며, "Make invalid states unrepresentable" 실천을 가능하게 함 이 방식은 상태 머신을 나타내는 객체에서 각 필드가 관련 상태일 때만 존재하도록 표현할 수 있게 함 현대 타입 시스템은 타입 추론 을 제공하며, 컴파일러가 let x = 5; 를 숫자로 판단할 수 있으면 let x: number = 5; 를 작성할 필요가 없음 IDE 기능과 결론 메서드 이름 자동완성 같은 IDE 기능이 널리 퍼지면서 정적 타입 시스템의 유용성이 더 커짐 90년대에는 Intellisense가 Visual Studio의 핵심 기능이었지만, 2020년대에는 비슷한 기능이 거의 모든 IDE와 에디터에서 제공됨 정적 타입 시스템에 넣은 정보는 프로그램 오류 검사뿐 아니라 추가적인 생산성 이점 을 만들어냄 좋은 동적 타입 시스템은 나쁜 정적 타입 시스템보다 낫지만, 지금은 과거보다 훨씬 더 나은 정적 타입 시스템을 사용할 수 있음
함께 보면 좋은 글 β 그냥 자바를 쓰세요 내가 TypeScript를 팔아먹는 방법(Sales Pitch) YAML을 옹호하며 한눈에 보는 타입스크립트 AI 시대, TypeScript의 부상: 수석 설계자 Anders Hejlsberg의 통찰
내가 TypeScript를 팔아먹는 방법(Sales Pitch)
AI 시대, TypeScript의 부상: 수석 설계자 Anders Hejlsberg의 통찰
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
인증 이메일 클릭후 다시 체크박스를 눌러주세요
▲ GN⁺ 4시간전 [-] Lobste.rs 의견들 이 글은 좋지만 완전히 동의하진 않음. 2000년대 초의 정적 타입 시스템 이 훌륭하진 않았어도, 정적 타입이 전혀 없는 것보다는 훨씬 나았다고 봄 닫힌 합 타입은 없었지만 하위 타입으로 상당 부분을 모델링할 수 있었고, null 불가 타입은 없었지만 C++의 참조와 비포인터 타입, Java의 기본 타입이 일부를 담당했음. Ruby나 JavaScript에서는 모든 타입이 null 가능할 뿐 아니라 문자열처럼도, 정수처럼도, 프로그램 안의 다른 모든 타입처럼도 취급될 수 있어서 더 나쁜 상황이었음 정적 타입에 대한 흐름이 바뀐 큰 이유는 Web 2.0 소셜 네트워크 붐 때 선점 효과 가 모든 것보다 중요했기 때문이라고 봄. Ruby나 Python으로 기술 부채를 쌓더라도 빨리 출시하고 반복하는 편이 Friendster나 Digg처럼 밀려나는 것보다 나았고, 느리면 당시 쉽게 구할 수 있던 저금리 자금으로 서버를 더 사면 됐음 이후 모바일 붐에서는 통제할 수 없는 제한된 사용자 기기에서 소프트웨어가 돌아가게 됐고, 느린 동적 타입 앱은 그냥 실제로 느렸으며 타입 오류가 나면 서버처럼 최상위 응답 핸들러로 우아하게 복구할 수도 없었음. 그 환경에서는 정적 타입의 안전성과 성능 이 훨씬 설득력 있어짐 Java와 90년대식 C++을 동적 타입 언어 코드베이스와 비교해 버그율이 비슷하다는 논문들이 꽤 있고, 동적 언어 선호자들이 이를 정적 타입이 유용하지 않다는 근거로 자주 듦 2000년대 초에는 나도 동의했는데, 당시 타입 시스템은 거의 틀리지 않는 속성만 강제하면서 코드 구조화에는 도움이 안 되는 제약을 부과하곤 했음. 특히 하위 타입과 구현 상속이 결합된 방식은 유연하지 않았음 더 현대적인 타입 시스템을 쓰면서 생각이 바뀜. snmalloc에서는 C++ 타입 시스템으로 메모리 소유권 상태 기계 를 강제하고, 다른 코드베이스에서는 링 버퍼 카운터의 올바른 오버플로 동작을 검사함. 둘 다 틀리면 디버깅이 귀찮고 흔한 오류 원인인데, 실제로 맞다고 생각한 코드에서 컴파일 실패를 내서 버그가 트리에 들어가지 못하게 막아줬음 동적 타입 언어로 개발하는 게 정적 타입 언어보다 느리다고 봄. 반대 주장을 계속 보지만 이해가 안 됨 IDE에서 . 을 누르고 메서드 이름을 조금 치다가 맞는 후보에서 Enter를 치면 몇 초마다 2초씩 아끼고, 어떤 메서드가 있는지 모를 때 클래스 정의를 찾아보는 30초도 아낌. 이 원리는 https://grugbrain.dev/#grug-on-type-systems 에도 잘 남아 있음 함수 매개변수 타입을 쓰는 일보다 메서드를 호출하는 코드 줄을 훨씬 자주 쓰기 때문에, 거래는 동적 타입에 압도적으로 불리함. 가치 있던 건 런타임에 실패할 말도 안 되는 코드를 허용하는 게 아니라, 지역 변수 타입을 생략하는 것이었고 정적 타입 언어가 애초에 그걸 금지할 필요는 없었음 2000년대 초의 인기 타입 시스템 은 그저 “엄청나진 않았다” 수준이 아니라 별로였고, 매우 장황했음 타입 시스템을 진지하게 쓰는 드문 코드베이스는 아무 말도 하지 않는 코드가 페이지 단위로 쌓였고, 그래도 런타임 조건문이 산더미였으며, Java라면 타입 계층이 늘어날수록 프로그램도 실질적으로 느려졌음. 대부분의 코드베이스는 타입을 듬성듬성 쓰면서 런타임 조건문을 많이 넣었고, 필요한 테스트 범위 면에서 동적 타입 시스템 대비 크게 절약되지 않았음 동적 타입 언어는 정적 보상은 없었지만, 간결해서 읽고 검토하기 쉬웠고 테스트도 쉬웠음. 특히 90년대 말~2000년대 초의 의존성 주입 프레임워크처럼 새 서비스를 추가할 때마다 XML 파일 여러 개를 고쳐야 하는 환경에서는 더 그랬음. RAM 절반을 먹는 IDE 없이도 작업할 수 있었음 내 초기 커리어가 딱 이랬기 때문에 글에 완전히 동의함. Java 1.4부터 Java 6까지의 비용 대비 효용이 너무 나빠서 정적 타입 언어를 거의 포기하게 됐고, 몇 년 뒤 취미로 Haskell을 만져보고 나서야 정적 타입도 합리적인 비용 대비 효용을 가질 수 있으며 문제는 Java였다는 걸 알게 됨. “python is not java” 에세이도 그 어두운 시절을 잘 보여줌 상속 기반 하위 타입 은 더 빈약했음. 완전성 검사가 되는 패턴 매칭의 사용성을 얻지 못했고, 구현이 여러 곳으로 쪼개졌음 경쟁자보다 먼저 사이트를 띄워 사용자 앞에 내놓고 규모의 경제를 잠그는 게 중요했다는 설명은, 요즘 상황과도 꽤 익숙하게 들림 정적 타입이 시대정신이 된 뒤 우리 소프트웨어의 신뢰성 이득 을 실제로 봤는지 의문임 정적 타입의 장점은 즉각적인 개발 피드백과 치명적인 런타임 실패 감소에 훨씬 더 있다고 생각했는데, 이론상 그런 실패는 늘 가능해도 실제로 그렇게 자주 발생하는 것 같지는 않았음 봤음. 사소하지 않은 TypeScript 코드베이스에서 TypeScript 오류 0개를 목표로 삼기 시작하자 undefined 와 null 에 메서드를 호출하려는 시도가 급격히 줄었음 주니어와 일부 시니어는 처음엔 여기저기 @ts-ignore 가 생길 거라고 회의적이었지만, 실제로는 의존성의 깨진 타입 때문에 생긴 것까지 포함해 세 개쯤뿐임. 예전에는 개발 브랜치에서 타입 혼동 때문에 일주일에 한 번쯤 앱이 죽어 내 작업을 막았는데, 지금은 마지막으로 그런 일을 겪은 게 언제인지도 기억 안 남 tsc 를 만족시키는 것만으로도 내가 직접 코드를 쓰지 않은 경우까지 타입 관련 버그 가 줄어듦. 반면 요즘 린터는 지나치게 열성적이고, Sonar 같은 도구를 만족시키려다 실제 리팩터링 파손을 봄. 경고 95%는 가짜였고, 3%는 도구 쪽 버그였으며, 도움이 된 2%도 실제 버그 원인은 아니었음. 코드베이스를 맞추느라 1주일을 쓰고 버그 하나를 잡는 대신 그 과정에서 두 개를 더 넣었음 tsc 를 만족시키는 작업은 대략 하루에 순수 버그 수정 2개와 회귀 1개 정도를 만들었지만, 회귀는 보통 전체 크래시가 아니라 잘못된 동작 수준으로 더 낮은 심각도였음 여기에 속성 기반 테스트 를 추가하면 평균 2~4시간 걸렸고 항상 최소 하나의 버그를 드러냈음. 코드가 속성 기반 테스트 가능하다면 해야 함 저렴한 모델인 DeepSeek V4 Flash로 테스트 범위를 늘리되 쓰레기 테스트가 생기지 않게 주의하니 하루에 논리 버그 2~3개 정도를 고쳤고, 크래시는 없었음. 다만 테스트 묶음은 간신히 유지보수 가능한 수준임 주니어가 Sonnet과 Opus 4.5, 4.6 계열로 대충 테스트를 만들게 했을 때는 모델들이 “현재 동작을 문서화”하는 테스트만 만들어 수정 효과가 작았고, 테스트 묶음은 유지보수 불가능해서 폐기해야 했음 모델 기반 테스트는 버그를 잡는 데 매우 좋지만 설정이 복잡하고, 표면 기능에 사이클을 태우지 않고 구석구석 파고들게 유도하는 일이 매우 번거로움. 프로파일 기반 모델 기반 퍼저 같은 게 있으면 흥미로울 것 같음 요약하면 타입 검사기는 치명적 실패와 여러 혼동을 잘 잡고, 속성 기반 테스트는 훌륭함. 일반 테스트는 꾸준히 보상을 얻으려면 많은 규율이 필요함 개인적으로는 그렇다고 봄. 내가 쓰는 JavaScript에서 null 포인터 버그 는 TypeScript로 옮긴 뒤 거의 무시할 만한 수준이 됐고, 동료들도 비슷했음 여기서 TypeScript를 좋은 타입 시스템과 한데 묶는 데 가장 동의하기 어려움 맞음. TypeScript는 건전하지 않고, 특히 await 을 가로질러 타입을 좁히는 방식이 여러 번 나를 물었음. 그래도 상황을 극적으로 개선한 건 사실임 솔직히 구조적 타입 지정도 결국 받아들이게 됐고, 앞으로의 언어 설계에 긍정적 영향을 줄 거라고 봄 이 주장은 설득력이 약함. 대수적 자료형 과 타입 추론을 갖춘 괜찮은 프로그래밍 언어는 90년대 중반부터 있었음 Java와 C++의 타입 시스템은 매우 빈약했지만 SML, OCaml, Haskell은 이미 있었고 오늘날과 크게 비슷한 느낌이었음. 사람들이 그 언어들을 쓰지 않았다면 그건 문화, 채택, 말로 드러나지 않은 요구사항의 문제지 “사용 가능한 타입 시스템이 충분히 좋지 않았다”만으로 설명할 수 없음 혹은 “당시 인기 언어의 타입 시스템은 나빴고, 오늘날 인기 언어의 타입 시스템은 더 좋아져서 타입 시스템이 더 인기를 얻었다”는 주장이라면 순환 논법처럼 들림 타입 시스템과 함께 설계된 언어와, 원래 타입 없이 설계된 뒤 나중에 타입 시스템이 얹힌 언어의 차이에 대해서도 많은 뉘앙스가 있음 원래 동적 타입을 선호해 온 입장에서도 이 글은 꽤 공정하다고 봄. 요즘은 C#으로 일하고, 취미로는 Lisp을 쓰며 예전에는 Python도 썼음 Java 5를 써야 했을 때는 대개 라이브러리 개발자의 나쁜 결정 때문에 타입 시스템과 계속 싸웠음. 2010년쯤 C#으로 옮긴 뒤에는 타입 시스템이 적극적으로 해롭지는 않았지만 대체로 중복적이었고, Python에서 가장 흔한 타입 혼동이던 null 포인터 예외도 막아주지 못했음 C#의 타입 시스템이 실제로 도움이 되기 시작한 건 2020년쯤 null 불가 참조 타입 이 들어오면서부터임. 올해는 네이티브 유니온 타입도 들어오지만, 완전성을 강제하는 유니온 타입 라이브러리는 적어도 2016년부터 가능했고 나는 2020년부터 쓰기 시작했음 유행도 여전히 역할을 한다고 보지만, 그중 일부는 나쁘지 않음. 더 표현력 있는 타입 시스템을 가진 유행 언어들이 우리가 돈 받고 쓰는 보통 언어들에도 개선을 가져왔음 Haskell과 그 타입 시스템은 이미 2000년대에도 있었음. 지금처럼 널리 쓰이진 않았지만 분명 존재했으니, 이 주장은 그 부분을 보완해야 함 개인적으로는 TypeScript가 주류 언어 사용자들에게 더 나은 타입 시스템을 익숙하게 만든 큰 요인이었다고 봄. 품질과 Microsoft의 지원 외에도 JavaScript에 적용된다는 장점이 있었고, JavaScript는 Python보다 타입이 더 절실했음. “Undefined is not a function.”과 “The good parts.” 때문임 최신 JavaScript 판에 맞춘 “good parts” 책이 간결함을 유지한 채 나오면 좋겠음 “Real World Haskell”은 2008년에 나왔고, 주류 프로그래머에게 Haskell을 더 매력적으로 보이게 하려는 목표였음. 좋은 소식을 퍼뜨리는 데 얼마나 도움이 됐는지는 모르겠음 Java 세계에는 Scala가 2004년에 멋진 타입을 가져왔고, .NET에는 F#이 2005년에 나왔음. Scala는 Twitter 같은 눈에 띄는 사용자를 가장 많이 얻었을지도 모르지만, TypeScript처럼 해당 플랫폼 사용자의 큰 비중을 흡수할 위치에 있지는 않았고 Rust나 Go처럼 다른 언어 사용자들을 대거 끌어들일 만큼 매력적이지도 않았음 글은 이 문제를 이미 다루고 있음. 90년대와 2000년대 초에 인기 있던 초기 Java나 C++98 같은 빈약한 정적 타입 시스템 을 종이 삽에 비유했음 바로 다음 문단에서 Haskell을 “현대적 타입 시스템”으로 언급하지만, 90년대 말과 2000년대 초에 Haskell 경험이 있는 사람은 개인적으로 만져본 수준까지 포함해도 사실상 0%에 가까웠음. 글은 당시 대다수 개발자가 정적 타입 언어를 어떻게 경험했고, 왜 그 대다수가 정적 타입 언어를 집단적으로 피했는지를 말하는 것임 Haskell과 OCaml은 어느 정도 도구 생태계 가 약해서 고생한다고 봄. 언어 자체는 훌륭하지만, 도구 쪽의 수많은 작은 종이 베임 때문에 채택을 잃음 예를 들어 OCaml에서 dune 을 쓰려면 opam 파일, dune 파일, ocaml module 문법, ocaml 문법을 이해해야 함. Haskell의 선택적 컴파일러 확장도 똑같이 무섭게 느껴짐 cargo 에서는 toml 과 Rust만 알면 되는 것과 대비됨 답변달기
Lobste.rs 의견들 이 글은 좋지만 완전히 동의하진 않음. 2000년대 초의 정적 타입 시스템 이 훌륭하진 않았어도, 정적 타입이 전혀 없는 것보다는 훨씬 나았다고 봄 닫힌 합 타입은 없었지만 하위 타입으로 상당 부분을 모델링할 수 있었고, null 불가 타입은 없었지만 C++의 참조와 비포인터 타입, Java의 기본 타입이 일부를 담당했음. Ruby나 JavaScript에서는 모든 타입이 null 가능할 뿐 아니라 문자열처럼도, 정수처럼도, 프로그램 안의 다른 모든 타입처럼도 취급될 수 있어서 더 나쁜 상황이었음 정적 타입에 대한 흐름이 바뀐 큰 이유는 Web 2.0 소셜 네트워크 붐 때 선점 효과 가 모든 것보다 중요했기 때문이라고 봄. Ruby나 Python으로 기술 부채를 쌓더라도 빨리 출시하고 반복하는 편이 Friendster나 Digg처럼 밀려나는 것보다 나았고, 느리면 당시 쉽게 구할 수 있던 저금리 자금으로 서버를 더 사면 됐음 이후 모바일 붐에서는 통제할 수 없는 제한된 사용자 기기에서 소프트웨어가 돌아가게 됐고, 느린 동적 타입 앱은 그냥 실제로 느렸으며 타입 오류가 나면 서버처럼 최상위 응답 핸들러로 우아하게 복구할 수도 없었음. 그 환경에서는 정적 타입의 안전성과 성능 이 훨씬 설득력 있어짐 Java와 90년대식 C++을 동적 타입 언어 코드베이스와 비교해 버그율이 비슷하다는 논문들이 꽤 있고, 동적 언어 선호자들이 이를 정적 타입이 유용하지 않다는 근거로 자주 듦 2000년대 초에는 나도 동의했는데, 당시 타입 시스템은 거의 틀리지 않는 속성만 강제하면서 코드 구조화에는 도움이 안 되는 제약을 부과하곤 했음. 특히 하위 타입과 구현 상속이 결합된 방식은 유연하지 않았음 더 현대적인 타입 시스템을 쓰면서 생각이 바뀜. snmalloc에서는 C++ 타입 시스템으로 메모리 소유권 상태 기계 를 강제하고, 다른 코드베이스에서는 링 버퍼 카운터의 올바른 오버플로 동작을 검사함. 둘 다 틀리면 디버깅이 귀찮고 흔한 오류 원인인데, 실제로 맞다고 생각한 코드에서 컴파일 실패를 내서 버그가 트리에 들어가지 못하게 막아줬음 동적 타입 언어로 개발하는 게 정적 타입 언어보다 느리다고 봄. 반대 주장을 계속 보지만 이해가 안 됨 IDE에서 . 을 누르고 메서드 이름을 조금 치다가 맞는 후보에서 Enter를 치면 몇 초마다 2초씩 아끼고, 어떤 메서드가 있는지 모를 때 클래스 정의를 찾아보는 30초도 아낌. 이 원리는 https://grugbrain.dev/#grug-on-type-systems 에도 잘 남아 있음 함수 매개변수 타입을 쓰는 일보다 메서드를 호출하는 코드 줄을 훨씬 자주 쓰기 때문에, 거래는 동적 타입에 압도적으로 불리함. 가치 있던 건 런타임에 실패할 말도 안 되는 코드를 허용하는 게 아니라, 지역 변수 타입을 생략하는 것이었고 정적 타입 언어가 애초에 그걸 금지할 필요는 없었음 2000년대 초의 인기 타입 시스템 은 그저 “엄청나진 않았다” 수준이 아니라 별로였고, 매우 장황했음 타입 시스템을 진지하게 쓰는 드문 코드베이스는 아무 말도 하지 않는 코드가 페이지 단위로 쌓였고, 그래도 런타임 조건문이 산더미였으며, Java라면 타입 계층이 늘어날수록 프로그램도 실질적으로 느려졌음. 대부분의 코드베이스는 타입을 듬성듬성 쓰면서 런타임 조건문을 많이 넣었고, 필요한 테스트 범위 면에서 동적 타입 시스템 대비 크게 절약되지 않았음 동적 타입 언어는 정적 보상은 없었지만, 간결해서 읽고 검토하기 쉬웠고 테스트도 쉬웠음. 특히 90년대 말~2000년대 초의 의존성 주입 프레임워크처럼 새 서비스를 추가할 때마다 XML 파일 여러 개를 고쳐야 하는 환경에서는 더 그랬음. RAM 절반을 먹는 IDE 없이도 작업할 수 있었음 내 초기 커리어가 딱 이랬기 때문에 글에 완전히 동의함. Java 1.4부터 Java 6까지의 비용 대비 효용이 너무 나빠서 정적 타입 언어를 거의 포기하게 됐고, 몇 년 뒤 취미로 Haskell을 만져보고 나서야 정적 타입도 합리적인 비용 대비 효용을 가질 수 있으며 문제는 Java였다는 걸 알게 됨. “python is not java” 에세이도 그 어두운 시절을 잘 보여줌 상속 기반 하위 타입 은 더 빈약했음. 완전성 검사가 되는 패턴 매칭의 사용성을 얻지 못했고, 구현이 여러 곳으로 쪼개졌음 경쟁자보다 먼저 사이트를 띄워 사용자 앞에 내놓고 규모의 경제를 잠그는 게 중요했다는 설명은, 요즘 상황과도 꽤 익숙하게 들림 정적 타입이 시대정신이 된 뒤 우리 소프트웨어의 신뢰성 이득 을 실제로 봤는지 의문임 정적 타입의 장점은 즉각적인 개발 피드백과 치명적인 런타임 실패 감소에 훨씬 더 있다고 생각했는데, 이론상 그런 실패는 늘 가능해도 실제로 그렇게 자주 발생하는 것 같지는 않았음 봤음. 사소하지 않은 TypeScript 코드베이스에서 TypeScript 오류 0개를 목표로 삼기 시작하자 undefined 와 null 에 메서드를 호출하려는 시도가 급격히 줄었음 주니어와 일부 시니어는 처음엔 여기저기 @ts-ignore 가 생길 거라고 회의적이었지만, 실제로는 의존성의 깨진 타입 때문에 생긴 것까지 포함해 세 개쯤뿐임. 예전에는 개발 브랜치에서 타입 혼동 때문에 일주일에 한 번쯤 앱이 죽어 내 작업을 막았는데, 지금은 마지막으로 그런 일을 겪은 게 언제인지도 기억 안 남 tsc 를 만족시키는 것만으로도 내가 직접 코드를 쓰지 않은 경우까지 타입 관련 버그 가 줄어듦. 반면 요즘 린터는 지나치게 열성적이고, Sonar 같은 도구를 만족시키려다 실제 리팩터링 파손을 봄. 경고 95%는 가짜였고, 3%는 도구 쪽 버그였으며, 도움이 된 2%도 실제 버그 원인은 아니었음. 코드베이스를 맞추느라 1주일을 쓰고 버그 하나를 잡는 대신 그 과정에서 두 개를 더 넣었음 tsc 를 만족시키는 작업은 대략 하루에 순수 버그 수정 2개와 회귀 1개 정도를 만들었지만, 회귀는 보통 전체 크래시가 아니라 잘못된 동작 수준으로 더 낮은 심각도였음 여기에 속성 기반 테스트 를 추가하면 평균 2~4시간 걸렸고 항상 최소 하나의 버그를 드러냈음. 코드가 속성 기반 테스트 가능하다면 해야 함 저렴한 모델인 DeepSeek V4 Flash로 테스트 범위를 늘리되 쓰레기 테스트가 생기지 않게 주의하니 하루에 논리 버그 2~3개 정도를 고쳤고, 크래시는 없었음. 다만 테스트 묶음은 간신히 유지보수 가능한 수준임 주니어가 Sonnet과 Opus 4.5, 4.6 계열로 대충 테스트를 만들게 했을 때는 모델들이 “현재 동작을 문서화”하는 테스트만 만들어 수정 효과가 작았고, 테스트 묶음은 유지보수 불가능해서 폐기해야 했음 모델 기반 테스트는 버그를 잡는 데 매우 좋지만 설정이 복잡하고, 표면 기능에 사이클을 태우지 않고 구석구석 파고들게 유도하는 일이 매우 번거로움. 프로파일 기반 모델 기반 퍼저 같은 게 있으면 흥미로울 것 같음 요약하면 타입 검사기는 치명적 실패와 여러 혼동을 잘 잡고, 속성 기반 테스트는 훌륭함. 일반 테스트는 꾸준히 보상을 얻으려면 많은 규율이 필요함 개인적으로는 그렇다고 봄. 내가 쓰는 JavaScript에서 null 포인터 버그 는 TypeScript로 옮긴 뒤 거의 무시할 만한 수준이 됐고, 동료들도 비슷했음 여기서 TypeScript를 좋은 타입 시스템과 한데 묶는 데 가장 동의하기 어려움 맞음. TypeScript는 건전하지 않고, 특히 await 을 가로질러 타입을 좁히는 방식이 여러 번 나를 물었음. 그래도 상황을 극적으로 개선한 건 사실임 솔직히 구조적 타입 지정도 결국 받아들이게 됐고, 앞으로의 언어 설계에 긍정적 영향을 줄 거라고 봄 이 주장은 설득력이 약함. 대수적 자료형 과 타입 추론을 갖춘 괜찮은 프로그래밍 언어는 90년대 중반부터 있었음 Java와 C++의 타입 시스템은 매우 빈약했지만 SML, OCaml, Haskell은 이미 있었고 오늘날과 크게 비슷한 느낌이었음. 사람들이 그 언어들을 쓰지 않았다면 그건 문화, 채택, 말로 드러나지 않은 요구사항의 문제지 “사용 가능한 타입 시스템이 충분히 좋지 않았다”만으로 설명할 수 없음 혹은 “당시 인기 언어의 타입 시스템은 나빴고, 오늘날 인기 언어의 타입 시스템은 더 좋아져서 타입 시스템이 더 인기를 얻었다”는 주장이라면 순환 논법처럼 들림 타입 시스템과 함께 설계된 언어와, 원래 타입 없이 설계된 뒤 나중에 타입 시스템이 얹힌 언어의 차이에 대해서도 많은 뉘앙스가 있음 원래 동적 타입을 선호해 온 입장에서도 이 글은 꽤 공정하다고 봄. 요즘은 C#으로 일하고, 취미로는 Lisp을 쓰며 예전에는 Python도 썼음 Java 5를 써야 했을 때는 대개 라이브러리 개발자의 나쁜 결정 때문에 타입 시스템과 계속 싸웠음. 2010년쯤 C#으로 옮긴 뒤에는 타입 시스템이 적극적으로 해롭지는 않았지만 대체로 중복적이었고, Python에서 가장 흔한 타입 혼동이던 null 포인터 예외도 막아주지 못했음 C#의 타입 시스템이 실제로 도움이 되기 시작한 건 2020년쯤 null 불가 참조 타입 이 들어오면서부터임. 올해는 네이티브 유니온 타입도 들어오지만, 완전성을 강제하는 유니온 타입 라이브러리는 적어도 2016년부터 가능했고 나는 2020년부터 쓰기 시작했음 유행도 여전히 역할을 한다고 보지만, 그중 일부는 나쁘지 않음. 더 표현력 있는 타입 시스템을 가진 유행 언어들이 우리가 돈 받고 쓰는 보통 언어들에도 개선을 가져왔음 Haskell과 그 타입 시스템은 이미 2000년대에도 있었음. 지금처럼 널리 쓰이진 않았지만 분명 존재했으니, 이 주장은 그 부분을 보완해야 함 개인적으로는 TypeScript가 주류 언어 사용자들에게 더 나은 타입 시스템을 익숙하게 만든 큰 요인이었다고 봄. 품질과 Microsoft의 지원 외에도 JavaScript에 적용된다는 장점이 있었고, JavaScript는 Python보다 타입이 더 절실했음. “Undefined is not a function.”과 “The good parts.” 때문임 최신 JavaScript 판에 맞춘 “good parts” 책이 간결함을 유지한 채 나오면 좋겠음 “Real World Haskell”은 2008년에 나왔고, 주류 프로그래머에게 Haskell을 더 매력적으로 보이게 하려는 목표였음. 좋은 소식을 퍼뜨리는 데 얼마나 도움이 됐는지는 모르겠음 Java 세계에는 Scala가 2004년에 멋진 타입을 가져왔고, .NET에는 F#이 2005년에 나왔음. Scala는 Twitter 같은 눈에 띄는 사용자를 가장 많이 얻었을지도 모르지만, TypeScript처럼 해당 플랫폼 사용자의 큰 비중을 흡수할 위치에 있지는 않았고 Rust나 Go처럼 다른 언어 사용자들을 대거 끌어들일 만큼 매력적이지도 않았음 글은 이 문제를 이미 다루고 있음. 90년대와 2000년대 초에 인기 있던 초기 Java나 C++98 같은 빈약한 정적 타입 시스템 을 종이 삽에 비유했음 바로 다음 문단에서 Haskell을 “현대적 타입 시스템”으로 언급하지만, 90년대 말과 2000년대 초에 Haskell 경험이 있는 사람은 개인적으로 만져본 수준까지 포함해도 사실상 0%에 가까웠음. 글은 당시 대다수 개발자가 정적 타입 언어를 어떻게 경험했고, 왜 그 대다수가 정적 타입 언어를 집단적으로 피했는지를 말하는 것임 Haskell과 OCaml은 어느 정도 도구 생태계 가 약해서 고생한다고 봄. 언어 자체는 훌륭하지만, 도구 쪽의 수많은 작은 종이 베임 때문에 채택을 잃음 예를 들어 OCaml에서 dune 을 쓰려면 opam 파일, dune 파일, ocaml module 문법, ocaml 문법을 이해해야 함. Haskell의 선택적 컴파일러 확장도 똑같이 무섭게 느껴짐 cargo 에서는 toml 과 Rust만 알면 되는 것과 대비됨
이 글은 좋지만 완전히 동의하진 않음. 2000년대 초의 정적 타입 시스템 이 훌륭하진 않았어도, 정적 타입이 전혀 없는 것보다는 훨씬 나았다고 봄 닫힌 합 타입은 없었지만 하위 타입으로 상당 부분을 모델링할 수 있었고, null 불가 타입은 없었지만 C++의 참조와 비포인터 타입, Java의 기본 타입이 일부를 담당했음. Ruby나 JavaScript에서는 모든 타입이 null 가능할 뿐 아니라 문자열처럼도, 정수처럼도, 프로그램 안의 다른 모든 타입처럼도 취급될 수 있어서 더 나쁜 상황이었음 정적 타입에 대한 흐름이 바뀐 큰 이유는 Web 2.0 소셜 네트워크 붐 때 선점 효과 가 모든 것보다 중요했기 때문이라고 봄. Ruby나 Python으로 기술 부채를 쌓더라도 빨리 출시하고 반복하는 편이 Friendster나 Digg처럼 밀려나는 것보다 나았고, 느리면 당시 쉽게 구할 수 있던 저금리 자금으로 서버를 더 사면 됐음 이후 모바일 붐에서는 통제할 수 없는 제한된 사용자 기기에서 소프트웨어가 돌아가게 됐고, 느린 동적 타입 앱은 그냥 실제로 느렸으며 타입 오류가 나면 서버처럼 최상위 응답 핸들러로 우아하게 복구할 수도 없었음. 그 환경에서는 정적 타입의 안전성과 성능 이 훨씬 설득력 있어짐
정적 타입이 시대정신이 된 뒤 우리 소프트웨어의 신뢰성 이득 을 실제로 봤는지 의문임 정적 타입의 장점은 즉각적인 개발 피드백과 치명적인 런타임 실패 감소에 훨씬 더 있다고 생각했는데, 이론상 그런 실패는 늘 가능해도 실제로 그렇게 자주 발생하는 것 같지는 않았음
여기서 TypeScript를 좋은 타입 시스템과 한데 묶는 데 가장 동의하기 어려움
이 주장은 설득력이 약함. 대수적 자료형 과 타입 추론을 갖춘 괜찮은 프로그래밍 언어는 90년대 중반부터 있었음 Java와 C++의 타입 시스템은 매우 빈약했지만 SML, OCaml, Haskell은 이미 있었고 오늘날과 크게 비슷한 느낌이었음. 사람들이 그 언어들을 쓰지 않았다면 그건 문화, 채택, 말로 드러나지 않은 요구사항의 문제지 “사용 가능한 타입 시스템이 충분히 좋지 않았다”만으로 설명할 수 없음 혹은 “당시 인기 언어의 타입 시스템은 나빴고, 오늘날 인기 언어의 타입 시스템은 더 좋아져서 타입 시스템이 더 인기를 얻었다”는 주장이라면 순환 논법처럼 들림 타입 시스템과 함께 설계된 언어와, 원래 타입 없이 설계된 뒤 나중에 타입 시스템이 얹힌 언어의 차이에 대해서도 많은 뉘앙스가 있음
원래 동적 타입을 선호해 온 입장에서도 이 글은 꽤 공정하다고 봄. 요즘은 C#으로 일하고, 취미로는 Lisp을 쓰며 예전에는 Python도 썼음 Java 5를 써야 했을 때는 대개 라이브러리 개발자의 나쁜 결정 때문에 타입 시스템과 계속 싸웠음. 2010년쯤 C#으로 옮긴 뒤에는 타입 시스템이 적극적으로 해롭지는 않았지만 대체로 중복적이었고, Python에서 가장 흔한 타입 혼동이던 null 포인터 예외도 막아주지 못했음 C#의 타입 시스템이 실제로 도움이 되기 시작한 건 2020년쯤 null 불가 참조 타입 이 들어오면서부터임. 올해는 네이티브 유니온 타입도 들어오지만, 완전성을 강제하는 유니온 타입 라이브러리는 적어도 2016년부터 가능했고 나는 2020년부터 쓰기 시작했음 유행도 여전히 역할을 한다고 보지만, 그중 일부는 나쁘지 않음. 더 표현력 있는 타입 시스템을 가진 유행 언어들이 우리가 돈 받고 쓰는 보통 언어들에도 개선을 가져왔음
Haskell과 그 타입 시스템은 이미 2000년대에도 있었음. 지금처럼 널리 쓰이진 않았지만 분명 존재했으니, 이 주장은 그 부분을 보완해야 함 개인적으로는 TypeScript가 주류 언어 사용자들에게 더 나은 타입 시스템을 익숙하게 만든 큰 요인이었다고 봄. 품질과 Microsoft의 지원 외에도 JavaScript에 적용된다는 장점이 있었고, JavaScript는 Python보다 타입이 더 절실했음. “Undefined is not a function.”과 “The good parts.” 때문임
발행일: 2026-06-12 06:08 (금)
한국어 KR 영어 EN 일본어 JP 중국어 CH
AI 기획부터 실행까지 돕는 크리에이티브 에이전트 ‘Luma AI’
지금 써보러 갑니다 6 분 2026.05.06. 2.6K
지금 써보러 갑니다 6 분 2026.05.06.
"통신 네트워크는 국가 AI 인프라로 진화하고 있습니다. 사람과 기업, 기기, 기계를 연결하고, 새로운 AI 클라우드의 핵심 기반이 될 것입니다."( 젠슨 황)
이달 엔비디아 젠슨 황 CEO의 내한은 단순한 비즈니스 방문이 아니었습니다. SK텔레콤·네이버·현대차·LG를 하루에 종횡무진 누빈 그의 일정은, 한국이 글로벌 AI 인프라 경쟁에서 어떤 포지션을 잡아야 하는지를 압축적으로 보여주는 지도였습니다.
삼겹살집에서 시작해 로봇 사옥을 거쳐 GW급 AI 클라우드 협약으로 끝난 이 방문의 핵심 키워드는 세 가지, 소버린 AI·네오스케일러·피지컬 AI였습니다.
소버린 AI, '나라 안의 AI'를 만든다는 것
소버린 AI는 '국산 AI'가 아닙니다. 자국의 언어·데이터·법제도가 반영된 AI 모델을, 자국이 통제 가능한 인프라 위에서 학습·추론하는 체계 전체를 의미합니다.
미국 빅테크 클라우드에 데이터를 맡기는 순간 AI의 '두뇌'는 있지만 '주권'은 없는 상황이 됩니다.
네이버는 '각 세종' 데이터센터를 전초기지로, 엔비디아와 GW급 AI 팩토리 공동 구축에 합의했습니다. 내년 상반기 55MW 가동을 시작으로 2028년 200MW, 궁극적으로 GW급 확장이 목표입니다. 한국 기업 최초로 엔비디아 '네모트론 연합'에 합류하며 하이퍼클로바X를 소버린 AI의 글로벌 레퍼런스로 삼겠다는 전략입니다.
SK텔레콤 역시 500B 규모 초거대 모델 'A.X K1'을 소버린 AI 파운데이션 모델로 내세우며, 엔비디아 DSX 플랫폼을 기반으로 GW급 AI 클라우드를 구축합니다. KT는 자체 소버린 AI 모델 라인업과 함께 정부 독자 AI 파운데이션 모델 프로젝트 2단계 참여를 적극 추진 중입니다.
기존 하이퍼스케일 데이터센터의 전력 규모가 수십~수백 MW였다면, 네오스케일러는 GW 단위의 연산 집적도를 목표로 합니다. 이것은 단순한 규모 확장이 아닙니다. AI 연산의 성격 자체가 바뀌는 것입니다.
수십만 장의 GPU가 동시에 가동되는 AI 팩토리에서는 네트워크가 단순한 파이프가 아니라 연산 클러스터의 핵심 구성 요소가 됩니다. GPU 간 데이터가 마이크로초 단위로 동기화되어야 하기 때문입니다. 전국 광케이블·기지국·데이터센터 자산을 실제로 운용하는 통신사만이 이 규모의 AI 팩토리를 안정적으로 지원할 네트워크 기반을 갖추고 있습니다.
피지컬 AI...로봇이 망을 필요로 하는 이유
젠슨 황이 현대차 사옥과 로봇 친화형 빌딩인 네이버 사옥을 방문한 이유는 하나입니다. '에이전틱 시스템·로봇·피지컬 AI를 구현하는 데 있어 데이터 확보가 가장 어려운 과제'라는 그의 말처럼, 피지컬 AI에서는 데이터 파이프라인이 핵심입니다.
로봇과 자율기기는 현장에서 수집한 데이터를 AI 팩토리로 올려 모델을 고도화하고, 고도화된 모델을 다시 현장에 배포하는 실시간 순환 구조가 필요합니다. 이 순환의 신경계 역할을 담당하는 것이 바로 통신망입니다.
T-모바일과 노키아는 엔비디아 AI-RAN 인프라를 5G 기지국에 적용해, 무선망이 동시에 분산 AI 연산을 수행하는 구조를 실증했습니다. SK텔레콤도 WIS 2026에서 디지털 트윈 플랫폼과 로봇 트레이닝 플랫폼을 공개하며 피지컬 AI 영역에서의 역할을 선점하고 있습니다.
GW급 AI 팩토리는 마이크로초 결정론적 레이턴시·무손실 패브릭·페타비트급 대역폭을 요구합니다. 5월 칼럼에서 다룬 SRv6 기반 단일 패브릭과 RON은 바로 이 AI 팩토리 연결의 기술 기반입니다. Telco가 보유한 광전송 인프라와 IP/MPLS 백본은, 제대로 진화시키면 경쟁자가 쉽게 복제할 수 없는 핵심 자산이 됩니다.
로봇·자율기기가 쏟아내는 비정형 데이터는 엣지에서 필터링되고, 코어 AI 팩토리에서 학습되며, 다시 엣지로 모델이 배포되는 연속적 흐름을 필요로 합니다. 전국 분산 기지국과 엣지 노드를 실제로 운용하는 통신사만이 이 흐름을 물리적으로 보장할 수 있습니다. 5G 특화망(이음 5G)과 AI-RAN의 결합이 가장 현실적인 출발점입니다.
소버린 AI의 핵심은 '데이터가 어디에 있느냐'입니다. 국가 안보·의료·금융·공공 데이터는 자국 영토 내 처리·보관이 요구됩니다. 통신사는 수십 년간 축적한 통신 데이터의 신뢰 기반 위에서 소버린 AI 인프라의 신뢰 앵커 역할을 할 수 있는 유일한 사업자입니다. LG유플러스의 파주 하이퍼스케일 AI DC 추진도 이 흐름의 일환입니다.
망을 가진 자가 AI 시대의 인프라를 지배한다
소버린 AI는 '우리 땅에서, 우리 데이터로, 우리가 통제하는 AI'를 요구합니다. 네오스케일러는 그 AI를 돌릴 GW급 연산 거점을 요구합니다. 피지컬 AI는 그 연산 결과를 물리 세계에 실시간으로 연결할 신경계를 요구합니다. 이 세 요구를 동시에 충족할 수 있는 사업자는 전국 광케이블·기지국·데이터센터를 실제로 운용하는 통신사입니다.
준비 없이 위상이 저절로 높아지지는 않습니다. AI 팩토리 네트워크 진화, 엣지-코어 연속성 설계, 소버린 데이터 인프라 구축, 이 세 가지 방향으로 지금 실행을 시작하는 통신사만이 다음 AI 시대의 국가 인프라 사업자 자리를 차지할 수 있습니다.
"AI는 모든 국가와 기업에서 쓰일 것이고, 반도체와 이동통신을 포함해 전 산업군에서 사용될 것입니다."(젠슨 황)
망을 가진 자가 AI 인프라를 지배하는 시대. 그 시작이 지금입니다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
아랍어 타이포그래피 렌더링의 놀라운 경험과 기술 부채에 대한 인터랙티브 입문 (lr0.org)
아랍어 웹 타이포그래피는 글자 연결, 양방향 텍스트, 숫자·구두점 처리, 줄 맞춤이 함께 얽힌 렌더링 인프라 문제 이며 단순 CSS 버그로 처리하기 어려움 고전 아랍어 조판은 단어 사이 공백이 아니라 글자 내부 획을 늘리는 카시다(kashida) 로 양쪽 정렬을 구현했지만, 현대 브라우저의 text-align: justify 는 주로 단어 사이 공백을 늘림 아랍어 글자는 저장된 코드포인트 하나가 문맥에 따라 고립형·초성형·중성형·종성형으로 바뀌며, OpenType 기능과 셰이핑 엔진 없이는 글자가 분리된 형태로 렌더링됨 Unicode의 Arabic Presentation Forms, 숫자 체계, UAX #9 양방향 알고리듬, 보이지 않는 제어문자는 검색 실패·전화번호 역전·커서 이동 혼란 같은 실제 제품 문제로 이어짐 HarfBuzz, Amiri, W3C Arabic Layout Requirements 등 핵심 기반은 구축됐지만, 브라우저의 아랍어 정렬과 jstf 활용은 여전히 구현 공백으로 남아 있음 시작점: “CSS 버그”처럼 보인 아랍어 조판 문제 고객용 대시보드의 혼합 콘텐츠 아랍어 문단이 디자인 시안처럼 양쪽 정렬되지 않고 왼쪽 가장자리가 들쭉날쭉하게 렌더링됨 같은 블록의 라틴 문자 버전은 “fine”으로 보였지만, 아랍어에서는 줄이 오른쪽에서 시작하므로 들쭉날쭉한 가장자리가 왼쪽에 생김 text-align: justify 를 적용해도 디자인팀이 승인한 형태처럼 단어 내부 획을 늘려 줄을 채우지 못함 같은 제품에서 이전에도 PDF의 이름 글자 분리, 검색 인덱스 실패, 레거시 Unicode 코드포인트 문제 등 아랍어 처리 문제가 반복됨 문제의 본질은 특정 스타일시트의 결함이 아니라 웹의 아랍어 타이포그래피 상태 에 있음 필사 전통이 해결했던 문제 고전 아랍어 필사 전통은 단어 사이 공백을 늘리지 않고 글자 형태 내부의 연결 획을 늘려 줄을 양쪽 정렬함 이 방식은 taṭwīl 또는 현대 기술 용어로 kashida 라고 불리며, 특정 글자 쌍 사이 연결 획을 길게 늘리는 방식임 17세기 Naskh의 잘 짜인 페이지는 양쪽 여백이 맞고 단어 간격이 늘어나지 않아 조밀하고 규칙적인 질감을 만듦 Ibn Muqla가 정리한 al-khaṭṭ al-mansūb 는 갈대 펜촉의 마름모 점, alif 높이, 원호 비율 등으로 글자 형태를 체계화함 이 전통에서 줄 맞춤은 공백 배분 문제가 아니라 글자 형태와 대체 글리프를 고르는 셰이핑 문제 였음 글자 하나, 네 가지 형태 아랍어는 항상 필기체처럼 이어지는 문자이며, 인쇄체와 손글씨를 나누는 블록 글자 구분이 없음 각 글자는 이웃 글자에 따라 고립형, 초성형, 중성형, 종성형으로 달라지고, 여섯 글자는 앞쪽으로 연결되지 않아 단어 내부 흐름을 끊음 Unicode는 추상 글자를 저장하고, 글꼴은 위치별 글리프를 제공하며, 셰이핑 엔진은 isol , init , medi , fina , rlig , mark , mkmk 같은 OpenType 기능을 적용함 محمد 같은 단어는 저장상 네 코드포인트지만, 렌더링 시 여러 글리프 선택과 OpenType 조회를 거쳐 하나의 이어진 획으로 보임 HarfBuzz 같은 셰이핑 엔진이 없거나 PDF 생성기가 이를 거치지 않으면 같은 코드포인트가 서로 분리된 고립형 글자로 렌더링됨 Unicode의 화석: Arabic Presentation Forms DOS와 초기 Windows 시대의 8비트 코드페이지는 추상 글자가 아니라 초성형·중성형 같은 형태 자체 를 별도 문자로 인코딩함 Unicode는 왕복 호환성을 위해 이를 받아들였고, U+FB50부터 U+FEFF까지 Arabic Presentation Forms 블록으로 남아 있음 새 문서에는 이 코드포인트가 들어가면 안 되지만, PDF 텍스트 추출기는 오늘날에도 이를 내보낼 수 있음 같은 이름이 현대 Unicode와 Presentation Forms로 각각 저장되면 화면에서는 동일하게 보이지만 문자열 비교와 검색에서는 서로 다르게 처리됨 NFKC 정규화를 적용하면 Presentation Forms를 추상 글자로 접어 검색 누락을 줄일 수 있음 셰이핑과 양방향 처리를 건너뛴 소프트웨어 셰이핑 엔진과 양방향 알고리듬을 건너뛰는 소프트웨어는 글자를 하나씩 고립형으로 그리고 줄을 왼쪽에서 오른쪽으로 배치함 이런 출력은 상점 간판, 탑승권, 워터마크, 오래된 영화 관련 아랍어 표기 등에서 아랍어 독자가 실제로 마주치는 형태임 오래된 Photoshop, 기본 설정의 matplotlib, npm의 여러 PDF 생성기, 영수증 프린터가 이런 문제를 낼 수 있음 Python의 흔한 우회책인 arabic_reshaper 와 python-bidi 는 Presentation Forms 블록을 사용해 미리 셰이핑된 형태를 문자열에 구워 넣음 이 우회책은 렌더러가 해야 할 일을 문자열에 앞당겨 넣는 방식이며, 근본적으로 텍스트 스택의 결함을 드러냄 세 종류의 숫자와 구두점 문제 세계가 “Arabic numerals”라고 부르는 0–9는 대부분의 아랍어 독자가 일상적으로 쓰는 숫자 모양이 아님 이집트, 수단, 레반트, 이라크, 걸프 지역은 Unicode의 ARABIC-INDIC DIGITS ٠١٢٣٤٥٦٧٨٩ 를 사용함 마그레브 지역은 라틴 숫자 글리프를 사용하고, 이란·아프가니스탄·파키스탄은 EXTENDED ARABIC-INDIC DIGITS ۰۱۲۳۴۵۶۷۸۹ 를 사용함 숫자는 UAX #9에서 강한 문자가 아니라 약한 문자로 처리되며, 앞선 강한 문자의 방향성에 따라 유럽 숫자 또는 아랍 숫자로 재분류됨 아랍어 단어 뒤의 010-1234-5678 같은 전화번호는 하이픈이 중립 처리되면서 화면에서 5678-1234-010 처럼 순서가 바뀔 수 있음 플랫폼이 제공하는 해결책은 번호를 ‎ 또는 <bdi> 로 감싸 방향성을 분리하는 방식임 아랍어권의 소수점과 천 단위 구분자는 U+066B ٫ 와 U+066C ٬ 이며, ASCII . 와 , 는 거의 비슷해 보이지만 코드포인트와 양방향 속성이 다름 인쇄부터 웹까지 이어진 우회와 단순화 1514년 Fano에서 인쇄된 _Kitāb Ṣalāt al-Sawāʿī_는 최초의 이동식 아랍어 활자본으로, 글자 연결 분리와 점 위치 오류가 보이는 사례임 1537년 Venice의 Paganini Qurʾān은 조판 오류와 텍스트 오류가 겹쳐 상업적으로 실패했고, 한 부가 1987년 Venice의 수도원 도서관에서 발견됨 Ottoman 인쇄 금지 이야기는 Bayezid II와 Selim I의 칙령 원문이 남아 있지 않으며, 유럽 여행자 기록에 의존한다는 문제가 있음 Cairo의 Bulaq Press는 1820년 Muhammad Ali가 세웠고, 수백 개 활자 조각과 많은 인내를 통해 아랍어 금속활자의 품질을 끌어올림 1924년 Cairo Qurʾān은 Amiria Press에서 금속활자로 제작됐고, 20세기 텍스트와 타이포그래피 표준화에 기여함 1950년대 후반 Kamel Mrowa와 Linotype은 90채널 매거진에 맞추기 위해 초성형을 중성형에, 종성형을 고립형에 합치고 합자를 줄인 Simplified Arabic 을 만듦 Simplified Arabic은 저렴하고 빠른 신문 제작을 가능하게 했고, 한 세대 안에 아랍어 뉴스룸을 장악함 웹이 아직 그리지 못하는 카시다 CSS Text Module Level 3의 초기 초안에는 text-justify 값으로 kashida가 있었고, Internet Explorer 5.5는 2000년에 이를 구현함 IE 5.5는 text-kashida-space 속성도 제공했지만, 다른 브라우저가 구현하지 않으면서 해당 값은 사양에서 빠짐 현대 Chrome, Firefox, Safari의 text-align: justify 는 아랍어에서 단어 사이 공백을 늘리는 방식으로 동작함 CSS Working Group의 아랍어 정렬 이슈는 적어도 2015년부터 열려 있고, W3C Arabic Layout Requirements 작업도 같은 해 시작됨 카시다 정렬은 늘어난 글리프가 폭을 바꾸고, 폭 변화가 줄바꿈과 필요한 늘림 폭을 다시 바꾸기 때문에 셰이핑과 레이아웃이 줄 단위로 반복 협상해야 함 OpenType에는 1990년대부터 글꼴이 정렬 우선순위를 알릴 수 있는 jstf 테이블이 있었지만, 셰이핑 엔진은 거의 읽지 않고 글꼴 제작사는 거의 제공하지 않음 Microsoft Word와 InDesign Middle East Edition은 카시다 정렬을 제공하지만, 사람들이 가장 많이 읽는 브라우저 렌더러 집합은 글자를 늘리지 못함 Tatweel 해킹과 합자·모음표 문제 웹에서 흔한 우회책은 텍스트 자체에 U+0640 TATWEEL 문자를 삽입해 늘어난 획처럼 보이게 만드는 방식임 Tatweel은 콘텐츠를 바꾸므로 검색 매칭, 복사·붙여넣기, 화면낭독기, 컬럼 리플로우에서 문제가 생김 Tatweel이 그리는 획은 글꼴과 문자의 규칙에 따라 배치되는 카시다가 아니라 작성자가 추측해 넣은 타자기식 막대임 OpenType 합자는 rlig , liga , dlig 로 나뉘며, lām-alif 같은 필수 합자가 깨지면 문자는 단순히 보기 나쁜 수준을 넘어 잘못됨 U+200C ZERO WIDTH NON-JOINER를 글자 사이에 넣으면 저장 글자는 유지되지만 렌더링은 각 글자를 고립형으로 강제함 Safari는 "rlig" 0 , "liga" 0 을 무시하므로 필수 합자 비활성화 데모가 영향을 주지 않음 Amiri는 Khaled Hosny가 2011년 SIL Open Font License로 공개한 Naskh 글꼴이며, 2022년 1.0 재작성 뒤 곡선형 카시다와 정교한 모음표 쌓기를 제공함 line-height: 1 과 overflow: hidden 이 결합된 카드 컴포넌트는 완전 모음 표기된 아랍어의 위쪽 모음표를 잘라낼 수 있음 양방향 알고리듬과 거짓말하는 커서 아랍어 문단 안의 버전 번호, 영어 식별자, URL, 프랑스어 단어 등은 Unicode Bidirectional Algorithm인 UAX #9 를 호출함 아랍어 글자는 강한 오른쪽-왼쪽 문자, 라틴 글자는 강한 왼쪽-오른쪽 문자, 숫자는 문맥을 따르는 약한 문자, 공백과 구두점은 중립 문자로 처리됨 알고리듬은 문자별 방향 클래스를 부여하고, 약한 문자와 중립 문자를 단계적으로 해석한 뒤, 임베딩 레벨을 배정하고 같은 레벨의 런을 뒤집음 화면의 시각 순서와 메모리의 논리 순서가 달라지므로 커서 이동, 마우스 클릭, 선택 동작은 두 순서 사이를 계속 번역해야 함 런 경계에는 논리 위치와 시각 위치라는 두 가지 합법적인 커서 위치가 있으며, Chrome, Firefox, Qt, Outlook은 이를 서로 다르게 처리할 수 있음 혼합 아랍어-영어 텍스트 작성은 2026년에도 주요 편집기, 이메일 클라이언트, 채팅 애플리케이션에서 기본적으로 인지 비용이 큰 경험으로 남아 있음 الصفحات 10-20 같은 범위는 규칙 W2와 중립 하이픈 처리 때문에 “20에서 10까지”처럼 보일 수 있으며, U+200E LEFT-TO-RIGHT MARK를 앞에 넣어 고칠 수 있음 작동하는 기반과 남은 공백 Khaled Hosny는 Amiri를 만들었고, HarfBuzz 명령줄 도구 hb-shape 를 작성했으며, HarfBuzz 공동 유지보수자 역할도 함 Behdad Esfahbod는 Hosny 이전에 HarfBuzz의 많은 부분을 작성했으며, 현재 브라우저에서 아랍어 글자를 올바르게 그리는 셰이핑 엔진에 기여함 Brill은 Semitics 카탈로그에 필요한 음역 문자를 모두 포함하기 위해 John Hudson에게 Brill 서체를 의뢰했고, 2011년 비상업용 무료로 공개함 Sakhr AX-170은 1984년경 ROM에서 아랍어를 표시한 Saudi-Kuwaiti MSX 컴퓨터였고, 오른쪽에서 왼쪽으로 쓰는 Arabic BASIC 식별자를 지원함 HarfBuzz, Amiri, Scheherazade, GNU Unifont의 Presentation Forms 지원, Noto Arabic, W3C Arabic Layout 문서는 소수의 개인·단체·자원봉사자 노력에 크게 의존함 브라우저 벤더는 HarfBuzz가 무료로 완성된 뒤 받아들였지만, 필사 전통의 정렬 방식을 화면에서 구현할 레이아웃 루프에는 거의 기여하지 않음 남은 격차는 몇몇 레이아웃 엔진에서 구현해야 하는 잘 이해된 알고리듬이며, 고객 대시보드의 들쭉날쭉한 왼쪽 여백은 이 투자 부재가 사용자에게 보이는 형태임
함께 보면 좋은 글 β RTL( Right-to-Left ) Styling 101 CodeBoarding - 코드베이스용 인터랙티브 아키텍처 다이어그램 ISBN의 함정 브라우저는 대형 사이트를 다르게 취급한다 CSS: 피할 수 없는 나쁜 부분들
RTL( Right-to-Left ) Styling 101
CodeBoarding - 코드베이스용 인터랙티브 아키텍처 다이어그램
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
인증 이메일 클릭후 다시 체크박스를 눌러주세요
정말 대단한 글임 그리고 이 글자 ﷽ 가 코드 포인트 하나 라는 점이 마음에 듦. 복사해보면 신기함 뜻은 “가장 자비롭고 가장 자애로우신 알라의 이름으로”라고 함
메타: 이런 글에는 typography 태그 가 필요하다는 또 하나의 훌륭한 예시임
IE의 text-justify 속성 이라니, 그 시절엔 흥미로운 것들이 많았음. text-justify: newspaper 도 있었는데, 수십 년 뒤 일부는 이것을 Knuth-Plass나 비슷한 것으로 설명했지만 실제로 그랬다고는 믿지 않음 https://mediumwell.com/wp-content/uploads/… 는 당시 text-justify: newspaper 라고 주장한 동작이 요즘 명세의 text-justify: inter-character 와 맞아떨어지는 모습을 보여줌 IE는 정말 꽤 이른 시기에 멋진 기능을 많이 갖고 있었고, 다른 브라우저들은 그런 기능을 “너무 어려움” 바구니에 방치했음. 결국 돌아오지 않았거나, 15년 혹은 30년이 지나서야 돌아온 것들도 있음. Firefox는 2017년에 text-justify: inter-character 를 얻었고, Chromium은 몇 달 전에야 그 부분을 구현했으며, Safari는 아직도 없음
엄청나게 훌륭하고 유익한 글임. 전체 이야기에 넓은 맥락을 제공하는 역사적 배경 이 특히 좋았음 역사 관련 학위와 IT 경력을 둘 다 가진 입장에서는 두 관심사를 완벽하게 건드린 글이었음
글 어딘가가 내 LLM 감지기 를 울리는데, 아쉬움. 깊이도 있고 현대 기술 스택에서 덜 문서화된 부분을 다루고 있기 때문임 LLM스럽게 읽히는 예시는 이런 부분인데, 글 전반에 걸쳐 그런 느낌이 있음: “어떤 브라우저도 이를 제공하지 않는 이유는 구조적이며, 장애물로서 그 구조는 꽤 우아하다. Latin 정렬은 셰이핑된 텍스트를 고정된 것으로 다루고, 단어를 측정하고, 남는 공간을 간격에 붓고, 끝낸다. 셰이핑과 레이아웃은 각자의 상자 안에 머물며, 운영 중인 모든 텍스트 스택은 그 분리를 중심으로 설계되어 있다. Kashida 정렬은 그 상자를 열어젖힌다.” @lr0에게 묻고 싶은데, 이 글의 본문이 LLM으로 생성·다듬기·번역된 것인지 궁금함. 그렇다면 최종 출력에 대해 LLM이 갖는 통제 수준을 조정하는 편이 좋을 수 있음. 예전 블로그 글들, 예를 들어 https://lr0.org/blog/p/gpt/ 와 https://lr0.org/blog/p/linux_new_users/ 는 훨씬 더 사람답게 느껴졌음
수년간 대한민국을 강타한 생성형 인공지능(AI)은 이제 '새로운 기술'을 넘어, 우리 산업과 일상의 패러다임을 바꾸는 핵심 동력으로 자리 잡았습니다. 'AI는 무엇인가'에 대한 탐색기를 지나, 이제는 '누가, 어떻게, 왜' 쓰고 있는지, 그리고 우리 비즈니스에 어떤 '실질적인' 변화를 가져오고 있는지 들여다볼 시점입니다. 이에 지디넷코리아는 소비자 조사 전문기관 컨슈머인사이트와 함께 올해 2월 1주부터 4월 3주까지 10주간 소비자 8000명(설 연휴 주간 제외 매주 800명)을 대상으로 '생성형 AI 기획조사'를 수행했습니다. 그 결과를 토대로 한국인의 AI에 대한 인식과 이용 현황, 브랜드별 경쟁 구도 등을 살펴보고, 앞으로 펼쳐질 시장의 미래를 조망해 봤습니다. [편집자 주]
1. 이용 현황: 4명 중 3명 써봤고, 그 중 40%는 ‘거의 매일’ 이용
조사에서 우리나라 성인 중 AI 서비스를 한 번이라도 이용해본 사람은 75%로 집계됐다. 이용경험자 중 81%가 최근 한 달 내 이용해 본 월간활성이용자(MAU)였다. 이를 전체 응답자 기준으로 환산하면 61%로, 성인 5명 중 3명이 월 1회 이상 AI를 쓰는 활성 이용자인 셈이다. 이용경험자 중 40%는 '거의 매일('하루에도 여러 번' 포함)' 활용할 정도로 이용 빈도가 높았다. AI 활용이 단순한 '호기심'에 머물지 않고 이미 '생활 속으로' 들어와 있음이 확인됐다.
경제협력개발기구(OECD)가 2026년 1월 발표한 ICT 이용 현황 데이터에 따르면 2025년 기준 OECD 회원국 전체에서 생성형 AI를 이용한 비율은 약 33%였다. 3명 중 1명이 생성형 AI를 사용하고 있는 셈이다. 컨슈머인사이트 조사의 한국인 월간 활성 이용률(61%)은 OECD 평균의 2배에 가깝다. 특히 대표적인 이용자 그룹인 사무직(67%), 기술직(69%), 경영관리직(65%), 전문직(68%)의 AI 이용률은 70%에 육박할 정도로 높은 수준이었다. 한국이 글로벌 생성형 AI 대중화의 가장 역동적인 '테스트베드'라는 세간의 평가와 일치한다.
이같은 특성은 유료 이용률에서도 확인된다. 조사에서 전체 응답자 대비 유료 구독률은 19%였는데, 월간 활성 이용자(61%) 기준으로 하면 4명 중 1명이다(활성이용자→유료 구독자 전환율 25%). 이는 일반적인 IT 소프트웨어(SaaS)의 프리미엄(Freemium·무료+유료 결합) 모델 유료 전환율이 2~5%(하버드 비즈니스 리뷰)인 것과 비교하면 놀라운 수치다. 한국 생성형 AI 시장이 실질적인 ‘유료 수익모델 단계’에 들어섰음을 뜻한다.
2. 국내 브랜드 경쟁 구도: 챗GPT·제미나이 양강 구도에 클로드 약진
국내 시장은 글로벌 빅테크의 치열한 각축장이 되고 있다. AI 서비스별 '최근 한 달 이용경험률'(복수응답)을 보면 '챗GPT'(58%)와 '제미나이'(48%)의 양강체제가 확연한 가운데, '에이닷'(9%), '퍼플렉시티'(6%), '나노바나나'(6%), '코파일럿'(4%), ‘그록’(4%), '캔바'(4%), '클로드'(3%), '뤼튼'(3%) 등이 멀찌감치 뒤따르고 있다.
이 중 이미지 생성에 특화된 서비스인 나노바나나와 캔바의 성과가 괄목할 만하다. 국내 기업이 운영하는 서비스 중에는 SK텔레콤의 에이닷, 뤼튼의 뤼튼 외에도 네이버 ‘클로바 노트’가 3%에 근접한 이용경험률로 선전하고 있다.
챗GPT는 선두주자이지만 안심할 상황은 아니다. 이용자 만족률은 제미나이(81%), 챗GPT(75%), 클로드(71%) 순이었고, 추천의향은 제미나이(78점), 클로드(77점), 챗GPT(73점) 순으로 후발주자에 뒤지고 있다. 10주간의 조사 기간 중 챗GPT의 월간 이용경험률은 소폭 하락(62%→60%)한 데 비해 제미나이(48%→54%), 퍼플렉시티(4%→7%) 클로드(1%→6%) 등은 모두 상승세인 점도 챗GPT에는 위협 요소다.
제미나이는 주이용자 3명 중 2명이 ‘챗GPT발(發) 이민자'라는 점에서 흥미롭다. 챗GPT 주이용자는 대부분(88%)이 처음 써본 AI인 챗GPT를 계속 쓰고 있는 데 비해 제미나이 주이용자는 64%가 챗GPT를 쓰다 넘어왔다. 그 배경에는 모회사 구글이 보유한 G메일·문서(Docs)·화상회의(Meet) 등 업무 생태계의 이점이 작용했을 수 있다. 즉, 많은 사람이 이미 구글 워크스페이스 환경에 익숙하기 때문에 제미나이 활용 경험이 더 쉽게 느껴졌고, 이것이 높은 전환율로 이어졌을 가능성이다.
클로드는 조사 기간 평균 이용경험률은 3%로 높지 않으나 주차를 거듭할수록 약진했다. 최초 1%에서 10주차에는 6%로, 자체 대형언어모델(LLM) 중 챗GPT와 제미나이에 이어 3위로 올라섰다. 최신 모델인 '클로드 3.5 소네트'의 논리력과 코딩 능력이 좋다고 평가된 데다, 생성된 코드나 문서를 대화창 옆에 띄워 두고 즉각적으로 편집할 수 있는 '아티팩트(Artifacts)' 기능을 도입한 데 힘입었다. 실질적인 업무 도구로서의 효용성을 평가받으면서, 개발자와 전문직 종사자를 중심으로 이용이 확산되고 있다.
3. AI별 이미지: 관계 인식 따라 이미지 크게 달라
AI 이용자가 생각하는 AI 이미지는 서비스별로 차이가 있었다. 조사에서 나타난 특징 중 하나는, 이용자가 주요 3대 AI 서비스와 맺고 있는 '관계 인식(페르소나)'이 각기 달랐다는 점이다. 이는 초기 '챗GPT'라는 단일 브랜드 체제에서, 이용자의 목적과 정서적 교감에 따라 서비스가 분화하는 '멀티 AI' 체제로 접어들었음을 뜻한다. AI 서비스에 대한 존재 인식 조사 결과를 분석해 보면 이들의 역할 분담은 명확해진다.
◇ 다재다능한 선생님, 챗GPT= 생성형 AI의 대명사인 오픈AI의 챗GPT는 주이용자의 관계 인식에서 전반적으로 고른 선택을 받았는데 그 중 '선생님·멘토'로 인식되는 경향이 상대적으로 높았다. 일상 대화부터 궁금한 점에 대한 질문, 번역·기획까지 폭넓게 사용되는 만큼, 사용자들에게 다방면의 지식을 가르쳐 주는 1:1 과외 선생님의 역할을 하고 있는 셈이다. 생성형 AI 입문자부터 숙련자까지 포괄하는 기초 인프라 역할을 담당한다.
◇ 유능한 전문가, 제미나이= 구글의 제미나이는 '도구·기계' 혹은 '전문가'로 바라보는 인식이 상대적으로 높았다. 제미나이 주이용자의 65%가 챗GPT를 쓰다가 넘어온 '얼리 어답터'라는 점을 고려하면 당연한 결과다. 이들은 정서적 교감보다는 구글 생태계 연동, 실시간 정보 탐색 등 명확한 실무적 효율성을 비교해 제미나이를 선택했다. 목적 달성을 위한 유능한 실무 도구로서 대하고 있는 것이다.
◇ 든든한 비서·동료, 클로드= 가장 눈에 띄는 것은 앤트로픽의 클로드다. 클로드를 '도구'로 보는 인식은 상대적으로 낮았던 반면, '비서'나 '가족·친구·동료'로 대하는 인식은 유의하게 높았다. 압도적인 정보 처리량(컨텍스트 윈도)을 바탕으로 긴 맥락을 기억하고, 한국어 문장력에 강점을 지닌 클로드의 특성이 반영된 결과다. 사용자와 대화하며 긴 문서를 요약하고 다듬는 과정에서, 단순한 기계가 아닌 내 업무를 돕는 든든한 파트너(비서·동료)로 자리매김하고 있다.
4. 왜 이런 분화가 나타났나: '업무 생산성'과 '관계 맺기' 엇갈린 니즈
절대 강자가 시장을 독식하지 못하고 여러 서비스로 분화되는 이유는, 사용자들이 AI에서 원하는 가치가 단일하지 않은 데다 계속 변하기 때문이다. 특히 AI를 오래 사용한 '고관여층'일수록 뚜렷한 목적의식의 변화를 보였다. 초기에 높았다가 시간이 갈수록 낮아진 ‘단순 호기심’(19%→9%)이나 ‘개인적 목적’(54%→42%)과 달리, '업무·학업 생산성'(18%→35%)을 위한 활용은 크게 증가했다. 시장이 성숙하며 AI의 핵심 가치가 '생산성'으로 수렴하고, 이에 따라 제미나이·클로드 같은 전문성에서 앞선 서비스가 주목받는 것으로 보인다.
동시에 AI는 단순한 작업 도구를 넘어 '관계 맺기'가 가능한 동반자로 진화하고 있다. AI 이용자의 56%는 AI를 단순한 도구·기계가 아닌 '비서, 전문가, 선생님, 동료' 등 관계적 존재로 인식했다. 특히 AI를 '거의 매일' 사용하는 핵심 이용층은 AI를 그저 '도구'로 보는 인식(36%)이 평균(44%)보다 유의하게 낮은 반면, 비서, 전문가, 선생님으로 보는 인식은 모두 평균을 웃돌았다. 차가운 '효율'과 따뜻한 '교감'의 요구가 교차하면서, 각자의 페르소나에 맞는 AI를 골라 쓰는 현상이 심화되고 있다.
5. 진화 방향: '멀티 AI'에서 ‘에이전트 AI’로
그렇다면 사용자가 목적에 맞춰 여러 AI를 그때그때 바꿔가며 쓰는 '멀티 AI' 체제는 계속될까. 조사 데이터에 따르면, AI 이용자들은 평균 3.6개의 서비스를 사용해 봤으며, 특히 적극적인 활용 층인 제미나이 주이용자는 평균 4.0개를 넘나들고 있었다. 이는 멀티 AI 활용이 보편화됐음을 뜻하지만, 동시에 각기 다른 인터페이스 적응과 중복 결제로 인한 '구독 피로감'을 불러올 수밖에 없다.
실제로 국내외 IT 업계에서는 향후 AI 구독 시장이 소수 플랫폼 중심으로 재편될 것이라는 전망이 힘을 얻고 있다. 이렇게 진화할 경우 '에이전틱 AI(Agentic AI)'가 중요한 역할을 할 전망이다. 글로벌 시장조사업체 가트너(Gartner)는 이미 2024년말 "2028년까지 일상적 업무 결정의 최소 15%가 에이전틱 AI에 의해 자율적으로 이뤄질 것"이라고 전망했다.
가트너의 이런 전망은 2025년말 공개한 '2026년 주요 전략 기술 트렌드'에서는 좀 더 강화됐다. 가트너는 2026년 전략 기술의 하나로 다중 에이전트 시스템(MAS)을 꼽았다. MAS는 개별 또는 공동의 복잡한 목표를 달성하기 위해 상호작용하는 에이전틱 AI의 집합체를 의미한다.
또 가트너가 2026년 실시한 CIO 설문조사에 따르면, 60% 이상의 기업이 "향후 2년 내에 에이전틱 AI를 도입할 것"이라고 응답했다. 현재 에이전틱 AI 도입 비율이 17% 수준인 점을 감안하면 엄청난 성장세가 예상된다.
결국 생성형 AI의 다음 진화 형태는 사용자가 여러 AI를 왔다 갔다 하는 것이 아닌, 하나의 거대 플랫폼 안에서 활동하는 '에이전트 AI' 생태계가 될 가능성이 크다. 이번 조사 결과 역시 이러한 미래 방향성과 궤를 같이한다. 응답자에게 향후 에이전트 AI에게 ‘가장 맡기고 싶은 역할(1+2순위 복수응답)’을 물은 결과, ‘전문 업무 생산성’(43%)이 1위, ‘금융·자산관리’(34%)가 2위였다. 그 뒤로는 ‘가계 및 스마트홈 관리’(26%), ‘여행 및 모빌리티’(25%), ‘헬스케어 및 웰니스’(23%), ‘커머스 및 쇼핑 대행’(22%) 등의 순이었다.
이는 소비자들이 단순한 정보 검색이나 문서 작성을 넘어, 내 지갑과 스케줄 등 일상과 업무 전반을 알아서 실행하고 관리해 줄 '종합 자율 비서'를 원하고 있음을 시사한다. 향후 AI 패권의 향방은 단일 모델의 성능 경쟁을 넘어, 이처럼 일상 전반을 아우르는 '유능한 전문 에이전트 생태계를 누가 먼저 구축하느냐'로 빠르게 이동할 것으로 점쳐진다.
6. 시장 현황과 미래: '높은 구매력'의 한국 시장, AI 기업의 과제는
우리 소비자에게 생성형 AI는 더 이상 마법 같은 신기술이 아니다. 성인 5명 중 3명(61%)이 매달 1회 이상 AI를 활용하고 그중 25%가 기꺼이 지갑을 여는 한국 시장은 글로벌 AI 기업들에게 가장 까다롭고 역동적인 테스트베드다.
그런 한국 소비자가 에이전트 AI에 가장 맡기고 싶어 하는 것은 '전문 업무'(43%), 금융·자산관리(34%)와 스마트홈(26%) 기능이었다. 동시에 AI 이용 시 두려워하는 것은 정보 오류(29%)와 신뢰 부족(18%) 순이었다. 기대가 큰 영역(업무·돈·가정 관리)에 꼭 필요한 정확성과 신뢰가 최대 우려 요소(정보 오류, 신뢰)와 정확히 겹친다. AI에 더 많이 맡기고 싶을수록, 더 믿기 어렵다는 모순이다.
챗GPT·제미나이·클로드, 韓 사용자 역대 최대…클로드 1년 새 12배 급증 2026.05.19 "챗GPT 기록, 제미나이서 그대로 본다"…구글, 외부 챗봇 정보 연동 2026.03.30 '제미나이' 사용자 3명 중 2명은 '챗GPT'서 갈아타…"기능 다양성 때문" 2026.03.24 쿠팡 6300억 역대급 과징금, 보안 전문가들 평가는? 2026.06.11
우리는 'AI를 어떻게 쓸 것인가'보다 '어떤 AI 생태계에 내 일상과 업무를 맡길 것인가'를 정해야 하는 변곡점에 서 있다. 플랫폼 시장의 냉혹한 '승자독식'을 고려할 때, 에이전트 생태계를 장악하지 못한 단일 AI 서비스들은 결국 거대 플랫폼의 하청 역할을 하는 '부품(API)'으로 전락할 가능성이 높다.
이제 AI의 성능은 상향 평준화되면서 격차가 빠르게 좁혀지고 있다. 다음 승부는 '누가 더 잘하느냐'보다 '누가 더 믿을 수 있느냐', ‘누가 먼저 메타플랫폼(에이전트 AI)으로 진화할 것이냐’로 넘어갈 것이다. 한국 소비자는 이미 그 답을 묻기 시작했다.
2000년 설립된 소비자 리서치 전문 회사다. 자동차, 이동통신, 금융, 여가·여행, 유통 등 다양한 산업 분야에서 대규모 표본을 바탕으로 한 정기 기획조사(Syndicated Study)를 독립적, 객관적으로 수행해 오고 있다. 대표성이 높고 오염되지 않은 18만여명의 소비자 패널(IBP)과 비대면 조사 시스템을 통해 수집한 데이터를 바탕으로, 시장 트렌드와 소비자 행동 변화에 대한 인사이트를 제공한다. 최근에는 지난 25년간 축적한 장기 종단 소비자 조사 데이터와 AI 기술을 활용해 실제 소비자의 의사결정과 행동을 모사·예측 가능한 ‘디지털 휴먼 트윈 패널’ 개발에 주력하고 있다.
Show GN: Bundis – Bun.RedisClient를 위한 SQLite 기반 Redis 호환 서버 (github.com/Munsunty)
Bun 앱에서 Redis 스타일 API와 pub/sub이 필요하지만, 별도 Redis 서버를 운영하고 싶지 않을 때를 위한 프로젝트입니다. 순정 Bun.RedisClient의 접속 URL만 이 서버로 돌리면 코드 수정 없이 그대로 동작합니다. Redis 설치도, 네이티브 의존성도 없습니다. 데이터는 SQLite 파일(WAL)에 영속화되어 재시작 후에도 살아남고, 읽기는 인메모리 핫 캐시로 가속됩니다. 핵심 의존성 0 — bun:sqlite, Bun.listen 모두 Bun 내장. 별도 설치 불필요 영속성 — 데이터가 SQLite 단일 파일에 저장, 재시작 후 생존 콜드 스타트 ~13ms — 데이터 크기와 무관 (Redis의 RDB/AOF 재생과 달리 기동 시 데이터 재생이 없음) 핫 캐시 — write-through + 적응형 idle eviction + LRU 바이트 상한. 캐시는 순수 읽기 가속이고 SQLite가 항상 진실 3가지 실행 방식 — 프로세스 내 embed / 사이드카 spawn / 독립 데몬(bunx) 사용 예 import { RedisClient } from "bun"; import { embedServer } from "bundis"; const server = embedServer({ dbPath: "./data.db" }); const client = new RedisClient(server.url); await client.set("k", "v"); 명확히 비목적인 것들 Bun 외 런타임(Node.js/Deno 등)과 Bun.RedisClient 외 클라이언트(ioredis, node-redis, redis-py 등)는 지원하지 않습니다. 와이어 계약("올바른 바이트가 들어오면 올바른 바이트로 답한다")이 보증 대상입니다 Redis Cluster/Sentinel, 다중 프로세스 .db 공유, HA/failover는 범위 밖 (단일 writer 가정) Lua 스크립팅(EVAL), list/sorted-set 명령군은 미구현 (계획됨) 인터페이스 호환이 목표지 Redis 성능 클론이 아닙니다. 처리량은 Redis가 우위이며, Bundis가 파는 것은 "Redis 설치 없이 Bun에서 디스크 영속 + Redis API"라는 운영 편의입니다. 성능 수치는 실제 Bun.RedisClient로 loopback TCP를 거쳐 측정한 호환 경로 벤치이며, 방법론과 before/after 수치는 저장소의 PERFORMANCE.md에 공개되어 있습니다. GitHub: https://github.com/Munsunty/bundis 설치: bun add bundis
Bun 앱에서 Redis 스타일 API와 pub/sub이 필요하지만, 별도 Redis 서버를 운영하고 싶지 않을 때를 위한 프로젝트입니다.
순정 Bun.RedisClient의 접속 URL만 이 서버로 돌리면 코드 수정 없이 그대로 동작합니다. Redis 설치도, 네이티브 의존성도 없습니다. 데이터는 SQLite 파일(WAL)에 영속화되어 재시작 후에도 살아남고, 읽기는 인메모리 핫 캐시로 가속됩니다.
import { RedisClient } from "bun"; import { embedServer } from "bundis";
const server = embedServer({ dbPath: "./data.db" }); const client = new RedisClient(server.url); await client.set("k", "v");
인터페이스 호환이 목표지 Redis 성능 클론이 아닙니다. 처리량은 Redis가 우위이며, Bundis가 파는 것은 "Redis 설치 없이 Bun에서 디스크 영속 + Redis API"라는 운영 편의입니다. 성능 수치는 실제 Bun.RedisClient로 loopback TCP를 거쳐 측정한 호환 경로 벤치이며, 방법론과 before/after 수치는 저장소의 PERFORMANCE.md에 공개되어 있습니다.
GitHub: https://github.com/Munsunty/bundis 설치: bun add bundis
함께 보면 좋은 글 β bunqueue - Bun용 SQLite 기반 고성능 작업 큐. DLQ/크론/S3 백업 지원 Redka - SQLite로 재구현한 Redis pgmicro - SQLite 기반으로 만든 인-프로세스 PostgreSQL 레디스 클라이언트 사이드 캐시로 반응성 향상 시키기 Redis와 야망의 대가
bunqueue - Bun용 SQLite 기반 고성능 작업 큐. DLQ/크론/S3 백업 지원
Redka - SQLite로 재구현한 Redis
pgmicro - SQLite 기반으로 만든 인-프로세스 PostgreSQL
레디스 클라이언트 사이드 캐시로 반응성 향상 시키기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.