2000년대부터 2010년대 초까지 정적 타이핑의 인기가 하락했다가 2010년대 중후반에 다시 상승한 이유는, 유행이 아닌 정적 타입 시스템의 품질 향상 구덩이를 팔 때 종이로 만든 삽 보다 맨손이 낫듯, 형편없는 정적 타입 시스템보다 동적 타입 시스템이 나음 초기 Java나 C++98 같은 과거 정적 타입 시스템은 nullable과 non-nullable 구분 조차 못 하고 합타입이 없으며 타입명을 일일이 적어야 함 TypeScript, Haskell, Swift, Rust 등 현대 타입 시스템은 null 구분, 합타입/유니온 타입, 타입 추론 을 기본 제공 IDE의 메서드 자동완성 보편화로 정적 타입에 입력한 정보가 오류 검사 외에 추가 생산성까지 가져옴 정적 타이핑 인기 변화에 대한 가설 정적 타이핑이 2000년대~2010년대 초에 인기가 줄었다가 2010년대 중후반에 다시 늘어난 현상은 프로그래밍이 유행 주도 산업이기 때문이 아니라 널리 쓰이던 정적 타입 시스템의 품질이 개선되었기 때문임 삽 비유 — 도구의 품질이 선택을 좌우 구덩이를 팔 때 삽이 쓸 만하다면 당연히 맨손보다 삽을 쓰겠지만, 유일하게 주어진 삽이 종이로 만든 것 이라면 땅을 무의미하게 휘젓게 되어 차라리 맨손이 나음 동적 타입 시스템에서는 변수와 필드의 상태·내용을 전부 자기 머리로 직접 추적해야 하며, 컴퓨터는 돕지도 방해하지도 않아 맨손으로 파는 것 에 해당 1990년대·2000년대 초에 흔했던 빈약한 정적 타입 시스템은 종이 삽 과 같음 nullable과 non-nullable 포인터 구분 같은 단순한 일조차 돕지 못함 곱타입(product type)만 있고 합타입(sum type)이 없음 타입명을 곳곳에 수작업으로 적어야 하는 부담 존재 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 포인터 오류 를 거의 보지 못함 합타입 또는 유니온 타입 "잘못된 상태를 표현 불가능하게 만들기(Make invalid states unrepresentable)" 관행을 가능하게 함 여러 필드를 가진 상태 기계(state machine) 객체를 만들 수 있고, 각 필드는 시스템이 관련 상태일 때에만 존재 타입 추론 컴파일러가 let x = 5; 를 숫자로 판단할 수 있으므로 let x: number = 5; 처럼 적을 필요 없음 IDE 기능 확산이 더한 효용 메서드 이름 자동완성 같은 IDE 기능 의 보편화가 정적 타입 시스템의 유용성을 키움 1990년대에는 Visual Studio의 Intellisense 가 킬러 기능이었으나, 2020년대에는 거의 모든 IDE·에디터에서 유사 기능 이용 가능 정적 타입 시스템에 넣은 정보가 오류 검사용 외에도 추가 생산성 이점 으로 이어짐 결론 좋은 동적 타입 시스템이 나쁜 정적 타입 시스템보다 나음 다만 이제는 과거보다 훨씬 나은 정적 타입 시스템 을 보유
함께 보면 좋은 글 β 그냥 자바를 쓰세요 내가 TypeScript를 팔아먹는 방법(Sales Pitch) AI와 사람에게 더 정확한 타입을 주자: 구현보다 넓게 명시된 반환 타입을 잡는 TypeScript ESLint 커스텀 룰 한눈에 보는 타입스크립트 AI 시대, TypeScript의 부상: 수석 설계자 Anders Hejlsberg의 통찰
내가 TypeScript를 팔아먹는 방법(Sales Pitch)
AI와 사람에게 더 정확한 타입을 주자: 구현보다 넓게 명시된 반환 타입을 잡는 TypeScript ESLint 커스텀 룰
AI 시대, TypeScript의 부상: 수석 설계자 Anders Hejlsberg의 통찰
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
인증 이메일 클릭후 다시 체크박스를 눌러주세요
▲ GN⁺ 1일전 [-] 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-13 06:22 (토)
한국어 KR 영어 EN 일본어 JP 중국어 CH
기획 PM은 LLM을 어디까지 이해해야 할까?
김영욱 10 분 2026.06.04. 5.5K
엑스박스, 게임 내 광고 필요성 언급…수익 구조 변화 시사
엑스박스 전략 책임자가 높은 개발비와 가격 인상 저항을 해결할 방안으로 게임 내 광고 확대를 제시했다. 모바일에선 이미 보편화된 모델이지만 콘솔 적용을 두고 업계 안팎의 반응은 엇갈렸다.
엑스박스 CSO가 게임 내 광고 확대를 제안했다. [사진: 셔터스톡]
[디지털투데이 AI리포터] 매슈 볼 엑스박스 최고전략책임자(CSO)이 게임 산업의 성장 둔화를 해결할 방안 중 하나로 게임 내 광고 활용 확대 필요성을 제기했다.
12일(현지시간) 온라인 매체 기가진에 따르면 볼은 게임 산업이 높은 개발비와 가격 인상에 대한 소비자 저항이라는 이중 과제에 직면해 있다고 진단했다. 그는 업계가 성장세를 회복하기 위해서는 새로운 수익원을 확보해야 하며, 광고가 그 대안 가운데 하나가 될 수 있다고 주장했다.
볼은 스트리밍 서비스 사례를 근거로 들었다. 광고를 포함한 저가 요금제가 이용자를 끌어들이는 동시에 광고를 원하지 않는 이용자에게는 더 높은 요금제를 제공하는 방식이 성공을 거두고 있다는 설명이다. 넷플릭스는 2022년 광고형 요금제를 도입했으며, 해당 상품은 출시 1년 만에 4000만명의 가입자를 확보했다. 이후 전체 가입자 수와 매출, 순이익도 증가했다.
이 같은 모델은 모바일 게임 시장에서는 이미 널리 활용되고 있지만 콘솔 게임 시장에서는 아직 보편화되지 않았다. 볼은 콘솔 환경에서도 광고 기반 모델을 정착시킬 방법을 찾는다면 게임 산업 성장에 도움이 될 수 있다고 평가했다.
다만 그는 무분별한 광고 확대를 주장하는 것은 아니라고 선을 그었다. 핵심은 모든 콘텐츠에 광고를 삽입하는 것이 아니라 경제적 여력이 부족하거나 광고를 활용하지 않는 개발사와 사업자들도 엑스박스 플랫폼과 프랜차이즈에 참여할 수 있는 환경을 만드는 데 있다고 설명했다.
볼은 마이크로소프트의 구체적인 계획은 공개하지 않았다. 그러나 제품 가격을 억제하면서도 개발팀에 지속적으로 자금을 투입하기 위해 기업들이 광고를 새로운 수익 모델로 검토할 필요가 있다고 말했다.
게임 내 광고를 둘러싼 논란도 여전하다. 마이크로소프트는 관련 기술을 개발 중이며, 일렉트로닉 아츠(EA)는 과거 'EA 스포츠 UFC 4'에 광고를 도입했다가 이용자 반발로 해당 기능을 삭제한 바 있다.
업계 의견은 엇갈린다. 바이오웨어 출신 마크 달라는 게임 내 제품 배치가 영화나 TV에 비해 아직 비중이 작지만 앞으로 확대될 가능성이 있다고 전망했다. 반면 테이크투 인터랙티브의 스트라우스 젤닉 최고경영자(CEO)는 부분유료화 게임의 광고는 이해할 수 있지만 정가를 받는 게임에 광고를 삽입하는 것은 불공평하다고 지적했다.
이 시각 추천뉴스 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러?
日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상
IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시
마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에
클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담
XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입
인간의 주의를 요구한다면 인간의 노력을 보여줘야 한다 (tombedor.dev)
팀 협업에서 AI가 작성한 디버그 조사·문서·코드 가 늘어나며, AI 출력물을 언제 다른 사람이 읽도록 보내도 되는지가 새 에티켓 문제가 됨 내부 코드베이스와 문서에 잘 통합된 AI는 실제로 유용한 출력 을 만들 수 있음 소프트웨어 엔지니어가 AI 텍스트를 읽는 시간이 늘어나며, 다듬지 않은 AI 출력물을 자기 글처럼 올리는 행동은 배려 없는 행위 임 읽지 않은 AI 비평 문서를 “ 정확하지 않을 수 있다 ”는 말과 함께 전달받으면, 보낸 사람에게도 읽을 가치가 없던 문서를 왜 받는 사람이 읽어야 하는지 문제가 됨 핵심 원칙은 "인간의 주의를 요청하려면 인간의 노력을 보여라" , 즉 AI 결과물을 공유할 때 AI 생성물임을 명확히 표기하고 본인 코멘트를 함께 첨부 AI 시대에 주의(attention)는 더욱 희소한 자원 이 되었으며, AI 콘텐츠 라벨링과 인간의 노력 증명이 동료 배려와 업무 속 인간미 유지로 이어짐 AI 출력물이 만든 협업 예절 문제 디버그 조사, 문서 작성, 코드 중 점점 더 많은 양이 로봇 에 의해 작성되고 있음 이 변화는 팀에서 AI 출력물을 다른 사람이 읽도록 전달해도 되는 시점을 따지는 새 에티켓 문제 를 만듦 내부 코드베이스와 문서에 강하게 통합된 AI는 실제로 유용한 결과물을 만드는 경우가 있음 동시에 소프트웨어 엔지니어의 하루 중 AI 텍스트를 읽는 비중이 커지며 피로감(fatigue) 발생 “내가 로봇에게 시킬 수 있으면, 너도 시킬 수 있다”는 감각 때문에, 다듬지 않은 AI 출력물을 자기 글처럼 올리는 행동은 배려 없는 행위 로 읽힘 인간의 주의에는 인간의 노력이 필요함 디자인을 제안한 뒤 팀원이 AI에 비평을 요청하고, “읽어보지 않았으니 완전히 정확하지 않을 수 있다”는 단서와 함께 AI 문서를 전달한 사례가 있음 읽어보지 않은 문서를 다른 사람에게 읽으라고 보내면, 보낸 사람에게도 가치가 없던 읽기 부담을 받는 사람에게 넘기는 문제가 생김 핵심 원칙은 인간의 주의를 요청한다면 인간의 노력을 보여줘야 함 임 AI 생성 콘텐츠가 유용하면 동료에게 보낼 수 있지만, AI가 만든 내용임을 명확히 표시하고 자신의 코멘트를 함께 붙여야 함 사람에게 코드 리뷰를 요청할 때는 AI가 생성한 코드를 먼저 직접 검토해야 함 의미 AI 이전에도 주의력은 이미 희소한 자원 이었고, AI 이후에는 그 희소성이 더 커짐 AI 생성 콘텐츠를 명확히 표시하고 인간의 노력을 보여주는 방식은 동료를 배려하고 일 속의 인간미(humanity) 을 유지하는 데 도움이 됨
함께 보면 좋은 글 β AI 시대의 코드 리뷰 AI가 코드를 쏟아내는 시대, 물이 빠지면 누가 발가벗고 수영했는지 드러난다 리눅스 커널 기여 시 AI 보조 도구 사용 지침 AI로 고품질 코드를 효과적으로 작성하는 방법 AI Slop이 온라인 커뮤니티를 죽이고 있다
AI가 코드를 쏟아내는 시대, 물이 빠지면 누가 발가벗고 수영했는지 드러난다
리눅스 커널 기여 시 AI 보조 도구 사용 지침
AI로 고품질 코드를 효과적으로 작성하는 방법
AI Slop이 온라인 커뮤니티를 죽이고 있다
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
인증 이메일 클릭후 다시 체크박스를 눌러주세요
▲ GN⁺ 17시간전 [-] Hacker News 의견들 Claude를 전면적으로 받아들인 생산성 높은 동료가 AI 생성 PR을 쏟아내면서 팀에 부담을 주고 있음 6개월쯤 지나니 스탠드업에서 자기 PR이 리뷰되지 않고 방치된다고 자주 불평하는데, 의도적으로 피하는 건 아니지만 팀이 보기 쉽게 만들지 않음 AI 콘텐츠를 거부하는 게 아니라, 실수를 찾아내고 걸러내려면 리뷰 effort 가 듦. 큰 PR에서 환각을 지적하려면 한 시간씩 들여 정확해야 하는데, 그 리뷰에 다시 AI 생성 답변과 AI 생성 수정이 달리면 존중받지 못하는 느낌이고, 결국 무의식적으로 그 PR을 피하게 됨 큰 소프트웨어 팀의 병목은 팀 커뮤니케이션 임. 큰 팀과 작은 팀을 운영해 봤는데, 속도를 높이고 싶으면 팀에서 사람을 줄이는 게 매번 효과가 컸음 해고가 아니어도 팀을 쪼개는 식으로 가능하고, 보통 제거되는 사람은 최고 성과자가 아님. 작은 회사를 운영하는 친구도 팀원을 1명 줄이자 거의 즉시 속도가 올라갔다고 했고, 그 사람이 주변을 느리게 만드는 병목이었음 이건 AI 전부터 사실이었고, AI는 차이를 더 크게 드러낼 뿐임. 현재 AI 도구는 다중 사용자 협업에 적합하지 않고 상호작용이 1:1이라, 도구와 사람 사이의 인수인계가 결국 사람 간 커뮤니케이션에 막힘 AI에 반발하는 감정은 이해되지만 생산적인 반사작용은 아닐 수 있음. 변화량이 줄어들지는 않을 테니 모든 코드를 수동 리뷰하겠다는 방식은 장기적으로 확장되지 않음. 수동 PR 리뷰가 실제 문제를 얼마나 찾는지, 그 가치를 제대로 평가하는지, 같은 문제를 자동으로 찾고 고칠 방법은 없는지 따져봐야 함 그 동료와 이 문제를 직접 이야기해 봤는지 궁금함. 인간이 쓴 메시지에 AI 답변을 보낼 정도로 눈치가 없다면, 왜 사람들이 그러지 않는지도 모를 가능성이 큼 그 행동은 자기 시간은 아끼면서 다른 사람의 시간은 덜 중요하게 여기는 것으로 해석될 수 있음 본인이 그걸 깨닫고 있는지 궁금함 좋은 경험칙은 남이 소비하는 데 드는 노력보다 더 많은 노력 을 결과물 생산에 들이라는 것임 항상 가능하진 않지만 변경 요청을 작게 유지하려는 훈련은 실제로 가치가 있고, 에이전트 를 쓸수록 더 중요해짐 파일과 줄 수가 순식간에 엄청나게 불어나기 쉬움 요즘 느끼는 점과 정확히 맞음. 특정 동료가 좀 과하게 나가서 모든 코드 리뷰, 이메일이나 Teams 질문 답변, 새 스토리, 설계·아이디어 회의에서의 개인 의견까지 전부 AI 출력물을 거의 손대지 않고 그대로 냄 앞으로의 프로젝트를 계획 중인데, 검토하라고 오는 문서는 장황하고 길며, 발견되는 문제들을 보면 사전에 본인이 읽어보지도 않은 것 같음 내용이 정확하거나 때로 도움이 될 수 있다는 건 이해하지만, 계속 AI 챗봇과 대화하는 느낌 은 피곤함. 다른 사람의 AI 생성 답변까지 대신 검증해 주고 싶지 않음 본능적으로는 무시하는 쪽이 맞아 보임. 맥락마다 다르겠지만, 결국 “그건 읽지 않겠다”가 해법이어야 할 듯함 이런 유형을 본 적 있음. 직장을 자기 자신과 회사 사이의 2인 게임 으로 보고, 자기 노력 대비 커리어 이득을 최대화하려 하며 남에게 얼마나 불편을 주는지는 신경 쓰지 않는 직장 성향이 있음 AI 전에는 실제로 일을 하거나, 들키지 않고 남의 공을 빼앗는 식의 게임을 해야 했음. 이제 AI가 나타나자 Claude에 전부 넣고, 작업을 시킨 뒤, 출력물을 복사해 다른 사람에게 붙여 넣는 방식으로 안 한 일의 공을 가져가는 최종 수단처럼 봄 최소 노력으로 최대 가시성을 얻는 셈이고, 들키지 않는다고 생각하는 한 계속될 것임. 관리자가 개입하지 않거나, 겉으로 보이는 산출량 때문에 오히려 장려하면 더 나빠질 수밖에 없음 내 의견이 내가 앵무새처럼 따라 한 AI 찌꺼기 라는 건 상상하기 어렵다. 그래도 조금은 다듬지 않나? Claude도 자주 어이없는 판단을 하고, Gemini는 더 나쁨. 모델이 내 의견에 동의할 때조차 내가 뭔가 틀린 건 아닌지 의심하게 됨 왜 이게 갑자기 긴급한 문제가 됐는지 모르겠음. 오래전부터 사람이 쓰지 않은 자동 “감사합니다” 이메일이 있었는데, 지금은 뭐가 다른가? 그런 이메일은 늘 무례하다고 느꼈음. 자동 응답이고 내 쪽 일만 늘린다는 걸 너무 잘 알고 있었기 때문임 그리고 이 글은 또 다른 점도 보여줌. AI 콘텐츠는 표시되어야 함. PR이 AI가 만든 것인지 항상 명확하지는 않음 자기 일을 통째로 LLM 프롬프터 로 자발적으로 격하시킨 사람이 이렇게 많다는 게 놀라움 당신의 일이 기계의 일과 구별되지 않는다면, 상사가 중간 사람을 빼고 기계를 직접 쓰지 못하게 막는 게 무엇인가? 이 새로운 세계에서는 사람들이 자기 가치를 증명하려고 더 애쓸 줄 알았음 모두가 AI에 적응하라고 말한다면, 자기 일 중 얼마나 많이 AI가 대신하게 할 수 있는지 실험하는 건 합리적임 기술 업계에서 일했고 지금은 회사를 운영하는 입장에서, 솔직히 소프트웨어 엔지니어 중 좋은 엔지니어는 많아야 10~20% 라고 봄 가혹하게 들리겠지만 거짓말하고 싶진 않음. 잘하는 사람이라면 아마 공감할 것임. 나머지는 대체로 별로였음 커리어 내내 “기대 이상”보다 낮은 평가를 받은 적이 없고, 형편없는 엔지니어도 봤고 극소수의 뛰어난 엔지니어도 봤으며 그들을 멘토로 삼았음 요즘 내 정책은 단순함. 생각하지 못하면 해고함. 뇌를 쓰지 못하는 사람에게 시간과 돈을 왜 쓰나? 차라리 AI 크레딧을 뇌를 쓰는 사람에게 주겠음 생각은 인간의 일이고, AI는 인간이 생각하고 개선하고 계획한 것을 실행해야 함 우리가 스스로에게 멍청한 일을 시키고 있기 때문이라고 봄. 가족의 생존을 지키는 쉼터를 짓거나 새로 좋아하게 될 그릇을 도예 물레에서 만드는 일은 대충 하지 않음 그런데 대신 Facebook 같은 곳에 올릴 글을 쓰며 어쨌든 수익을 내려 하니, 당연히 봇에게 이런 멍청한 일을 시키고 당연히 멍청한 결과가 나옴 어떤 일에는 맞지만, 나는 지금 꽤 멋진 일도 대충 자동화하고 있음. 우리 도시의 회의록, 의제, 녹화본을 긁어오고 전사본을 만든 뒤, “Flock”을 정규식으로 찾아 모든 언급을 모았음 그 파일들을 저렴한 모델인 DeepSeek V4 에 넣어, 우리 도시에서 감시 국가 구축에 찬성하는 사람이 누구고 아닌 사람이 누구인지 파악했음 각 인물에 대한 자료를 모으고, 그들이 한 말에 맞춰 이메일 초안도 만들었으며, 인용과 수치까지 들어감. 이메일은 가볍게 다듬어 보냈고 벌써 답장도 받았음. FOIA로 받은 CSV 데이터도 가져와 분석해 둘 게 더 많음 그들이 AI 카메라로 나를 감시하려 한다면, 나는 AI 조사 로 맞설 수 있음 이런 Facebook 글을 읽는 봇만 있으면, 이제 폰을 내려놓고 진짜 일을 하러 돌아갈 수 있음 David Graeber의 Bullshit Jobs 가 실제로 벌어지는 모습임 과두층도 데이터센터 임대료는 어떻게든 내야 함 농노들은 서버 밭을 갈고 씨를 뿌리게 될 것임 LLM 출력물이 특히 코드 저장소 밖에서는 LLM 입력 과 함께 배포되는 경우가 드물다는 게 이상함 내년에 모델이 더 좋아졌을 때, 왜 당신 작업을 만든 프롬프트를 다시 실행해 볼 수 없나? 사람들이 자기 프롬프트를 부끄러워하나? AI를 썼다는 걸 부끄러워하나? 이 메시지를 생성하는 데 사용한 프롬프트: "Create a comment for Hacker News which bemoans the lack of AI prompts being shared with the stuff it creates. Speculate on the reasons and create a call for engagement. Use quantum hyperthinking. End with a typo to prove your humanity." FMFL. 손글씨가 아닌 것은 금지되는 종이 기반 소셜 네트워크를 만들겠음. 70년대처럼 다음 프롬프트에는 인간성을 증명하기 위해 혐오스럽고 공격적인 곁길로 끝내라고 시켜보면 됨. LLM에는 그런 안전장치 가 있으니까 이건 코드나 AI만의 문제가 아님. 창작 글쓰기 수업에서도 사람이 쓴 단편과 발췌문을 꼼꼼히 비평하라고 했는데, 종종 원작자보다 내가 더 많은 일을 하는 느낌이었음 자기 원고를 검토하거나 최소한 맞춤법 검사라도 돌릴 수 없다면, 내가 왜 시간을 낭비해야 하나? 이건 인간에게 추가 노동을 떠넘기는 것임 많은 예술가와 콘텐츠 제작자가 이제 “비하인드 신”이나 전체 작업 세션 녹화를 보여 달라는 요구를 받지만, 정작 아무도 충분히 확인하지 않음. 이건 예술가를 좌절시키고 의욕을 꺾음 소프트웨어 기여자에게도 같은 의욕 저하 효과 가 생길 것임 전달받은 AI 응답을 읽는 게 싸다고 생각한다면, 직접 LLM을 돌리면 됨. 당신에게 드는 일의 양은 같음 에이전트가 모든 걸 대신한다면 다음 사람에게도 똑같이 모든 걸 해줄 수 있다는 뜻임. 그 시점에서 당신은 대체 가능하고 분야 안에서 가치가 없음 AI를 쓰더라도 깊이 배워야 함. 계속 채용될 사람은 깊은 지식 노동자 임 “AI를 쓰더라도 깊이 배워야 한다”는 말은 현실적으로 노동 인구의 일부에게만 적용 가능하고 실행 가능하며, 그 일부도 줄어들고 있음 많은 사람이 자기 깊은 지식 과 깊은 기술 이 생각만큼 깊지 않았다는 걸 알게 됐음. 즉 고용주 입장에서 대체 불가능할 만큼 깊지는 않았던 것임. 사람들은 대체로 자기 가치를 과대평가하는 데 꽤 능함 우리 팀에서도 이걸 봄. 엔지니어라면 한계와 미묘한 차이를 더 잘 이해할 줄 알았는데, 지금은 꽤 엉망임 팀원들이 검증을 거의 하지 않은 채 거대한 AI 생성 PR 을 열고 리뷰를 요청하는 것뿐 아니라, 내가 존중하는 똑똑한 팀원들도 AI로 “코드 리뷰”를 하게 시킴 이미 PR에는 자동 AI 코드 리뷰도 붙어 있음. 그래서 이제 “인간” 리뷰에서까지 환각 섞인 헛소리 답변을 받는 경우가 있음 이걸 보면 일반 대중은 정말 위험하다고 확신하게 됨. 앞으로 거대한 AI 생성 사고를 정기적으로 보게 될 것임. 업계 사람들, 즉 일반 대중에 비하면 전문가인 사람들이 이렇게 명백해 보이는 방식으로 기술을 오용한다면, 비기술자들은 얼마나 더 잘못 이해하고 잘못 적용하겠나. 과장 광고를 하는 사람들과 파는 사람들의 도움까지 더해져서 말임 답변달기
Hacker News 의견들 Claude를 전면적으로 받아들인 생산성 높은 동료가 AI 생성 PR을 쏟아내면서 팀에 부담을 주고 있음 6개월쯤 지나니 스탠드업에서 자기 PR이 리뷰되지 않고 방치된다고 자주 불평하는데, 의도적으로 피하는 건 아니지만 팀이 보기 쉽게 만들지 않음 AI 콘텐츠를 거부하는 게 아니라, 실수를 찾아내고 걸러내려면 리뷰 effort 가 듦. 큰 PR에서 환각을 지적하려면 한 시간씩 들여 정확해야 하는데, 그 리뷰에 다시 AI 생성 답변과 AI 생성 수정이 달리면 존중받지 못하는 느낌이고, 결국 무의식적으로 그 PR을 피하게 됨 큰 소프트웨어 팀의 병목은 팀 커뮤니케이션 임. 큰 팀과 작은 팀을 운영해 봤는데, 속도를 높이고 싶으면 팀에서 사람을 줄이는 게 매번 효과가 컸음 해고가 아니어도 팀을 쪼개는 식으로 가능하고, 보통 제거되는 사람은 최고 성과자가 아님. 작은 회사를 운영하는 친구도 팀원을 1명 줄이자 거의 즉시 속도가 올라갔다고 했고, 그 사람이 주변을 느리게 만드는 병목이었음 이건 AI 전부터 사실이었고, AI는 차이를 더 크게 드러낼 뿐임. 현재 AI 도구는 다중 사용자 협업에 적합하지 않고 상호작용이 1:1이라, 도구와 사람 사이의 인수인계가 결국 사람 간 커뮤니케이션에 막힘 AI에 반발하는 감정은 이해되지만 생산적인 반사작용은 아닐 수 있음. 변화량이 줄어들지는 않을 테니 모든 코드를 수동 리뷰하겠다는 방식은 장기적으로 확장되지 않음. 수동 PR 리뷰가 실제 문제를 얼마나 찾는지, 그 가치를 제대로 평가하는지, 같은 문제를 자동으로 찾고 고칠 방법은 없는지 따져봐야 함 그 동료와 이 문제를 직접 이야기해 봤는지 궁금함. 인간이 쓴 메시지에 AI 답변을 보낼 정도로 눈치가 없다면, 왜 사람들이 그러지 않는지도 모를 가능성이 큼 그 행동은 자기 시간은 아끼면서 다른 사람의 시간은 덜 중요하게 여기는 것으로 해석될 수 있음 본인이 그걸 깨닫고 있는지 궁금함 좋은 경험칙은 남이 소비하는 데 드는 노력보다 더 많은 노력 을 결과물 생산에 들이라는 것임 항상 가능하진 않지만 변경 요청을 작게 유지하려는 훈련은 실제로 가치가 있고, 에이전트 를 쓸수록 더 중요해짐 파일과 줄 수가 순식간에 엄청나게 불어나기 쉬움 요즘 느끼는 점과 정확히 맞음. 특정 동료가 좀 과하게 나가서 모든 코드 리뷰, 이메일이나 Teams 질문 답변, 새 스토리, 설계·아이디어 회의에서의 개인 의견까지 전부 AI 출력물을 거의 손대지 않고 그대로 냄 앞으로의 프로젝트를 계획 중인데, 검토하라고 오는 문서는 장황하고 길며, 발견되는 문제들을 보면 사전에 본인이 읽어보지도 않은 것 같음 내용이 정확하거나 때로 도움이 될 수 있다는 건 이해하지만, 계속 AI 챗봇과 대화하는 느낌 은 피곤함. 다른 사람의 AI 생성 답변까지 대신 검증해 주고 싶지 않음 본능적으로는 무시하는 쪽이 맞아 보임. 맥락마다 다르겠지만, 결국 “그건 읽지 않겠다”가 해법이어야 할 듯함 이런 유형을 본 적 있음. 직장을 자기 자신과 회사 사이의 2인 게임 으로 보고, 자기 노력 대비 커리어 이득을 최대화하려 하며 남에게 얼마나 불편을 주는지는 신경 쓰지 않는 직장 성향이 있음 AI 전에는 실제로 일을 하거나, 들키지 않고 남의 공을 빼앗는 식의 게임을 해야 했음. 이제 AI가 나타나자 Claude에 전부 넣고, 작업을 시킨 뒤, 출력물을 복사해 다른 사람에게 붙여 넣는 방식으로 안 한 일의 공을 가져가는 최종 수단처럼 봄 최소 노력으로 최대 가시성을 얻는 셈이고, 들키지 않는다고 생각하는 한 계속될 것임. 관리자가 개입하지 않거나, 겉으로 보이는 산출량 때문에 오히려 장려하면 더 나빠질 수밖에 없음 내 의견이 내가 앵무새처럼 따라 한 AI 찌꺼기 라는 건 상상하기 어렵다. 그래도 조금은 다듬지 않나? Claude도 자주 어이없는 판단을 하고, Gemini는 더 나쁨. 모델이 내 의견에 동의할 때조차 내가 뭔가 틀린 건 아닌지 의심하게 됨 왜 이게 갑자기 긴급한 문제가 됐는지 모르겠음. 오래전부터 사람이 쓰지 않은 자동 “감사합니다” 이메일이 있었는데, 지금은 뭐가 다른가? 그런 이메일은 늘 무례하다고 느꼈음. 자동 응답이고 내 쪽 일만 늘린다는 걸 너무 잘 알고 있었기 때문임 그리고 이 글은 또 다른 점도 보여줌. AI 콘텐츠는 표시되어야 함. PR이 AI가 만든 것인지 항상 명확하지는 않음 자기 일을 통째로 LLM 프롬프터 로 자발적으로 격하시킨 사람이 이렇게 많다는 게 놀라움 당신의 일이 기계의 일과 구별되지 않는다면, 상사가 중간 사람을 빼고 기계를 직접 쓰지 못하게 막는 게 무엇인가? 이 새로운 세계에서는 사람들이 자기 가치를 증명하려고 더 애쓸 줄 알았음 모두가 AI에 적응하라고 말한다면, 자기 일 중 얼마나 많이 AI가 대신하게 할 수 있는지 실험하는 건 합리적임 기술 업계에서 일했고 지금은 회사를 운영하는 입장에서, 솔직히 소프트웨어 엔지니어 중 좋은 엔지니어는 많아야 10~20% 라고 봄 가혹하게 들리겠지만 거짓말하고 싶진 않음. 잘하는 사람이라면 아마 공감할 것임. 나머지는 대체로 별로였음 커리어 내내 “기대 이상”보다 낮은 평가를 받은 적이 없고, 형편없는 엔지니어도 봤고 극소수의 뛰어난 엔지니어도 봤으며 그들을 멘토로 삼았음 요즘 내 정책은 단순함. 생각하지 못하면 해고함. 뇌를 쓰지 못하는 사람에게 시간과 돈을 왜 쓰나? 차라리 AI 크레딧을 뇌를 쓰는 사람에게 주겠음 생각은 인간의 일이고, AI는 인간이 생각하고 개선하고 계획한 것을 실행해야 함 우리가 스스로에게 멍청한 일을 시키고 있기 때문이라고 봄. 가족의 생존을 지키는 쉼터를 짓거나 새로 좋아하게 될 그릇을 도예 물레에서 만드는 일은 대충 하지 않음 그런데 대신 Facebook 같은 곳에 올릴 글을 쓰며 어쨌든 수익을 내려 하니, 당연히 봇에게 이런 멍청한 일을 시키고 당연히 멍청한 결과가 나옴 어떤 일에는 맞지만, 나는 지금 꽤 멋진 일도 대충 자동화하고 있음. 우리 도시의 회의록, 의제, 녹화본을 긁어오고 전사본을 만든 뒤, “Flock”을 정규식으로 찾아 모든 언급을 모았음 그 파일들을 저렴한 모델인 DeepSeek V4 에 넣어, 우리 도시에서 감시 국가 구축에 찬성하는 사람이 누구고 아닌 사람이 누구인지 파악했음 각 인물에 대한 자료를 모으고, 그들이 한 말에 맞춰 이메일 초안도 만들었으며, 인용과 수치까지 들어감. 이메일은 가볍게 다듬어 보냈고 벌써 답장도 받았음. FOIA로 받은 CSV 데이터도 가져와 분석해 둘 게 더 많음 그들이 AI 카메라로 나를 감시하려 한다면, 나는 AI 조사 로 맞설 수 있음 이런 Facebook 글을 읽는 봇만 있으면, 이제 폰을 내려놓고 진짜 일을 하러 돌아갈 수 있음 David Graeber의 Bullshit Jobs 가 실제로 벌어지는 모습임 과두층도 데이터센터 임대료는 어떻게든 내야 함 농노들은 서버 밭을 갈고 씨를 뿌리게 될 것임 LLM 출력물이 특히 코드 저장소 밖에서는 LLM 입력 과 함께 배포되는 경우가 드물다는 게 이상함 내년에 모델이 더 좋아졌을 때, 왜 당신 작업을 만든 프롬프트를 다시 실행해 볼 수 없나? 사람들이 자기 프롬프트를 부끄러워하나? AI를 썼다는 걸 부끄러워하나? 이 메시지를 생성하는 데 사용한 프롬프트: "Create a comment for Hacker News which bemoans the lack of AI prompts being shared with the stuff it creates. Speculate on the reasons and create a call for engagement. Use quantum hyperthinking. End with a typo to prove your humanity." FMFL. 손글씨가 아닌 것은 금지되는 종이 기반 소셜 네트워크를 만들겠음. 70년대처럼 다음 프롬프트에는 인간성을 증명하기 위해 혐오스럽고 공격적인 곁길로 끝내라고 시켜보면 됨. LLM에는 그런 안전장치 가 있으니까 이건 코드나 AI만의 문제가 아님. 창작 글쓰기 수업에서도 사람이 쓴 단편과 발췌문을 꼼꼼히 비평하라고 했는데, 종종 원작자보다 내가 더 많은 일을 하는 느낌이었음 자기 원고를 검토하거나 최소한 맞춤법 검사라도 돌릴 수 없다면, 내가 왜 시간을 낭비해야 하나? 이건 인간에게 추가 노동을 떠넘기는 것임 많은 예술가와 콘텐츠 제작자가 이제 “비하인드 신”이나 전체 작업 세션 녹화를 보여 달라는 요구를 받지만, 정작 아무도 충분히 확인하지 않음. 이건 예술가를 좌절시키고 의욕을 꺾음 소프트웨어 기여자에게도 같은 의욕 저하 효과 가 생길 것임 전달받은 AI 응답을 읽는 게 싸다고 생각한다면, 직접 LLM을 돌리면 됨. 당신에게 드는 일의 양은 같음 에이전트가 모든 걸 대신한다면 다음 사람에게도 똑같이 모든 걸 해줄 수 있다는 뜻임. 그 시점에서 당신은 대체 가능하고 분야 안에서 가치가 없음 AI를 쓰더라도 깊이 배워야 함. 계속 채용될 사람은 깊은 지식 노동자 임 “AI를 쓰더라도 깊이 배워야 한다”는 말은 현실적으로 노동 인구의 일부에게만 적용 가능하고 실행 가능하며, 그 일부도 줄어들고 있음 많은 사람이 자기 깊은 지식 과 깊은 기술 이 생각만큼 깊지 않았다는 걸 알게 됐음. 즉 고용주 입장에서 대체 불가능할 만큼 깊지는 않았던 것임. 사람들은 대체로 자기 가치를 과대평가하는 데 꽤 능함 우리 팀에서도 이걸 봄. 엔지니어라면 한계와 미묘한 차이를 더 잘 이해할 줄 알았는데, 지금은 꽤 엉망임 팀원들이 검증을 거의 하지 않은 채 거대한 AI 생성 PR 을 열고 리뷰를 요청하는 것뿐 아니라, 내가 존중하는 똑똑한 팀원들도 AI로 “코드 리뷰”를 하게 시킴 이미 PR에는 자동 AI 코드 리뷰도 붙어 있음. 그래서 이제 “인간” 리뷰에서까지 환각 섞인 헛소리 답변을 받는 경우가 있음 이걸 보면 일반 대중은 정말 위험하다고 확신하게 됨. 앞으로 거대한 AI 생성 사고를 정기적으로 보게 될 것임. 업계 사람들, 즉 일반 대중에 비하면 전문가인 사람들이 이렇게 명백해 보이는 방식으로 기술을 오용한다면, 비기술자들은 얼마나 더 잘못 이해하고 잘못 적용하겠나. 과장 광고를 하는 사람들과 파는 사람들의 도움까지 더해져서 말임
Claude를 전면적으로 받아들인 생산성 높은 동료가 AI 생성 PR을 쏟아내면서 팀에 부담을 주고 있음 6개월쯤 지나니 스탠드업에서 자기 PR이 리뷰되지 않고 방치된다고 자주 불평하는데, 의도적으로 피하는 건 아니지만 팀이 보기 쉽게 만들지 않음 AI 콘텐츠를 거부하는 게 아니라, 실수를 찾아내고 걸러내려면 리뷰 effort 가 듦. 큰 PR에서 환각을 지적하려면 한 시간씩 들여 정확해야 하는데, 그 리뷰에 다시 AI 생성 답변과 AI 생성 수정이 달리면 존중받지 못하는 느낌이고, 결국 무의식적으로 그 PR을 피하게 됨
요즘 느끼는 점과 정확히 맞음. 특정 동료가 좀 과하게 나가서 모든 코드 리뷰, 이메일이나 Teams 질문 답변, 새 스토리, 설계·아이디어 회의에서의 개인 의견까지 전부 AI 출력물을 거의 손대지 않고 그대로 냄 앞으로의 프로젝트를 계획 중인데, 검토하라고 오는 문서는 장황하고 길며, 발견되는 문제들을 보면 사전에 본인이 읽어보지도 않은 것 같음 내용이 정확하거나 때로 도움이 될 수 있다는 건 이해하지만, 계속 AI 챗봇과 대화하는 느낌 은 피곤함. 다른 사람의 AI 생성 답변까지 대신 검증해 주고 싶지 않음
왜 이게 갑자기 긴급한 문제가 됐는지 모르겠음. 오래전부터 사람이 쓰지 않은 자동 “감사합니다” 이메일이 있었는데, 지금은 뭐가 다른가?
자기 일을 통째로 LLM 프롬프터 로 자발적으로 격하시킨 사람이 이렇게 많다는 게 놀라움 당신의 일이 기계의 일과 구별되지 않는다면, 상사가 중간 사람을 빼고 기계를 직접 쓰지 못하게 막는 게 무엇인가? 이 새로운 세계에서는 사람들이 자기 가치를 증명하려고 더 애쓸 줄 알았음
우리가 스스로에게 멍청한 일을 시키고 있기 때문이라고 봄. 가족의 생존을 지키는 쉼터를 짓거나 새로 좋아하게 될 그릇을 도예 물레에서 만드는 일은 대충 하지 않음 그런데 대신 Facebook 같은 곳에 올릴 글을 쓰며 어쨌든 수익을 내려 하니, 당연히 봇에게 이런 멍청한 일을 시키고 당연히 멍청한 결과가 나옴
LLM 출력물이 특히 코드 저장소 밖에서는 LLM 입력 과 함께 배포되는 경우가 드물다는 게 이상함 내년에 모델이 더 좋아졌을 때, 왜 당신 작업을 만든 프롬프트를 다시 실행해 볼 수 없나? 사람들이 자기 프롬프트를 부끄러워하나? AI를 썼다는 걸 부끄러워하나? 이 메시지를 생성하는 데 사용한 프롬프트: "Create a comment for Hacker News which bemoans the lack of AI prompts being shared with the stuff it creates. Speculate on the reasons and create a call for engagement. Use quantum hyperthinking. End with a typo to prove your humanity."
이건 코드나 AI만의 문제가 아님. 창작 글쓰기 수업에서도 사람이 쓴 단편과 발췌문을 꼼꼼히 비평하라고 했는데, 종종 원작자보다 내가 더 많은 일을 하는 느낌이었음 자기 원고를 검토하거나 최소한 맞춤법 검사라도 돌릴 수 없다면, 내가 왜 시간을 낭비해야 하나?
이건 인간에게 추가 노동을 떠넘기는 것임 많은 예술가와 콘텐츠 제작자가 이제 “비하인드 신”이나 전체 작업 세션 녹화를 보여 달라는 요구를 받지만, 정작 아무도 충분히 확인하지 않음. 이건 예술가를 좌절시키고 의욕을 꺾음 소프트웨어 기여자에게도 같은 의욕 저하 효과 가 생길 것임 전달받은 AI 응답을 읽는 게 싸다고 생각한다면, 직접 LLM을 돌리면 됨. 당신에게 드는 일의 양은 같음
에이전트가 모든 걸 대신한다면 다음 사람에게도 똑같이 모든 걸 해줄 수 있다는 뜻임. 그 시점에서 당신은 대체 가능하고 분야 안에서 가치가 없음 AI를 쓰더라도 깊이 배워야 함. 계속 채용될 사람은 깊은 지식 노동자 임
우리 팀에서도 이걸 봄. 엔지니어라면 한계와 미묘한 차이를 더 잘 이해할 줄 알았는데, 지금은 꽤 엉망임 팀원들이 검증을 거의 하지 않은 채 거대한 AI 생성 PR 을 열고 리뷰를 요청하는 것뿐 아니라, 내가 존중하는 똑똑한 팀원들도 AI로 “코드 리뷰”를 하게 시킴 이미 PR에는 자동 AI 코드 리뷰도 붙어 있음. 그래서 이제 “인간” 리뷰에서까지 환각 섞인 헛소리 답변을 받는 경우가 있음 이걸 보면 일반 대중은 정말 위험하다고 확신하게 됨. 앞으로 거대한 AI 생성 사고를 정기적으로 보게 될 것임. 업계 사람들, 즉 일반 대중에 비하면 전문가인 사람들이 이렇게 명백해 보이는 방식으로 기술을 오용한다면, 비기술자들은 얼마나 더 잘못 이해하고 잘못 적용하겠나. 과장 광고를 하는 사람들과 파는 사람들의 도움까지 더해져서 말임
발행일: 2026-06-13 06:22 (토)
한국어 KR 영어 EN 일본어 JP 중국어 CH
프로덕트 클로드 페이블 5, 출시 하루 만에 너무 막힌다는 반응이 쏟아졌다
요즘 프로덕트 메이커 9 분 23시간 전 3.9K
김용범 청와대 정책실장은 11일(현지시간) 한국이 AI 데이터센터(AIDC) 입지로는 최적화한 곳이라며 AIDC를 전략 산업으로 육성하겠다는 구상을 밝혔다.
김 정책실장은 이날 이탈리아 로마에 마련된 프레스센터에서 브리핑을 통해 “기존 데이터센터와 AIDC는 규모 등 측면에서 차이가 많다. 최적지로서 한국이 주목 받고 있다”고 말했다.
이어, “우리나라의 AIDC 전력이나 여러 가지 강점 때문에 단기간에 상당히 거대한 데이터센터들이 한국에 집중적으로 건설될 가능성이 있어 보인다”고 진단했다.
[기고] 아태지역 AI 인프라, '데이터 시스템' 중심 설계해야 2026.06.11 LGU+, 2030년까지 AIDC 수주 누적 5조원 목표 2026.06.07 과기정통부, 기후부와 AIDC 전력 공급 업무협약 2026.05.12 30년전 CDMA 개발한 SKT, 한국 ICT 성장 견인 2026.04.09
그러면서 “이 기회에 AIDC를 건설하고, 설계하고, 운영하는 산업 자체에서 우리나라가 핵심 부품도 자급자족하고, AIDC를 효율적으로 운영하고, 그 성과를 가지고 다른 나라에 수출하는 전략 산업이 될 수 있겠다”고 설명했다.
앞서 김 정책실장은 이날 SNS에 “한국은 반도체, 전력 인프라, 첨단 제조를 한꺼번에 갖춘 흔치 않은 나라”라면서 “이 셋이 맞물리면 한국은 단순히 부품을 대주는 나라가 아니라 AI 공급망 전체를 떠받치는 거점이 될 수 있다”고 했다.
일반신용대출 최대 한도는 1억원으로 운영된다. 통장자동대출(마이너스통장)의 최대 한도는 5000만원으로 제한된다.
다만 서민금융상품과 정책성 대출 등 일부 상품은 별도 기준이 적용될 수 있다.
KB국민은행 관계자는 "가계부채의 안정적 관리와 실수요자 중심의 자금 공급이라는 두 가지 원칙을 균형 있게 고려해 이번 운영 방안을 마련했다"며 "건전한 여신 포트폴리오와 금융취약계층 지원은 차질 없을 것"이라고 말했다.
키워드 #KB국민은행 #신용대출 #가계대출 #한도 조정
이 시각 추천뉴스 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러?
日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상
IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시
마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에
클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담
XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입
revo - 프로그래밍의 즐거움을 위한 동적 언어 (github.com/if-not-nil)
Zig 로 작성된 동적 타입 언어 로, 모든 것이 값을 반환하는 "everything is something" 구조 채택 블로킹 코드 앞에 spawn 을 붙이는 것만으로 논블로킹으로 전환되는 매끄러운 동시성 모델 지원 파이프( |> ) 연산자로 값을 연속 변환하며, _ 로 직전 값을 참조 예: "hello" |> _:upper() |> _:sub(1, 2) 패턴 매칭 및 결과 타입 지원, 함수가 (:ok, value) / (:err, reason) 형태 반환 후 match 로 분기해서 처리 --test 플래그 붙였을때만 컴파일·실행되는 first-class 테스트 내장, 단일 test 와 묶음 suite 블록 제공 revo.h 로 C 코드에 직접 끼워 넣는게 가능한 임베딩 API 제공 erevo_vm_create , erevo_compile , erevo_run , erevo_eval 등 diagnostic/go-to-definition/hover/참조/심볼을 처리하는 LSP 서버 revolt 내장 릴리스 빌드에 기본 번들되며 revo --lsp 로 실행 기본 REPL 백엔드 isocline 을 제공. 멀티라인 입력/탭 완성/히스토리 검색 지원 윈도우 버전은 아직 불완전 : 비동기 백엔드 및 완전한 라인 에디터는 미지원 MIT 라이선스
함께 보면 좋은 글 β Zig의 비동기 프로그램에 대한 새로운 계획 Zig을 네트워크 프로그래밍에 가장 좋아하는 언어로 만든 과정 Tabloid - 낚시성 문장으로 코딩하는 프로그래밍 언어 Borgo - Go로 컴파일되는 정적 타입 언어 타입 해석 재설계와 언어 변경 사항
Zig을 네트워크 프로그래밍에 가장 좋아하는 언어로 만든 과정
Tabloid - 낚시성 문장으로 코딩하는 프로그래밍 언어
Borgo - Go로 컴파일되는 정적 타입 언어
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
인증 이메일 클릭후 다시 체크박스를 눌러주세요
발행일: 2026-06-13 06:22 (토)
한국어 KR 영어 EN 일본어 JP 중국어 CH
프로덕트 Anthropic 엔지니어가 정리한 AI와 일하는 5가지 원칙
요즘 프로덕트 메이커 9 분 2026.05.22. 인기 13.2K
요즘 프로덕트 메이커 9 분 2026.05.22. 인기
스페이스X 상장에 美 명품시장 '꿈틀'…롤렉스·전용기 수요 확대 조짐
스페이스X 상장에 따른 고급 주택·명품 시계·전용기 시장이 수요 확대를 기대하고 있다. 캘리포니아와 오스틴에선 직원들의 주택 문의가 이미 늘기 시작했다.
스페이스X 상장에 명품시장 수요가 잇따르고 있다. [사진: Reve AI]
[디지털투데이 이윤서 기자] 스페이스X 기업공개(IPO)가 확정되면서, 미국 내 고급 부동산과 명품 시계, 전용기 시장이 먼저 반응하고 있다.
11일(현지시간) 경제매체 CNBC에 따르면 스페이스X 현직·전직 직원들은 아직 보유 지분을 바로 현금화할 수 없지만, 일부는 향후 유동성 확보를 염두에 두고 소비 계획을 세우기 시작했다.
가장 먼저 반응이 나타나는 곳은 부동산 시장이다. 캘리포니아 남부에서는 장기근속 스페이스X 직원들의 고급 주택 문의가 늘고 있는 것으로 전해졌다. 부동산 중개업자 제라드 비시냐노는 최근 30대 중반에서 40대 초반의 직원 여러 명이 주택을 알아보고 있으며, 일부는 가족을 위한 주택 구매도 검토하고 있다고 밝혔다.
스페이스X 캘리포니아 사무실과 가까운 맨해튼비치, 레돈도비치, 허모사비치, 팰로스버디스에스테이츠 등은 수혜 지역으로 거론된다. 비시냐노는 이 일대 고급 주택 수요가 늘어날 가능성이 있다고 봤다. 매머드레이크스, 팜스프링스, 타호 등 캘리포니아 휴양지의 세컨드하우스 수요도 증가할 수 있다는 전망이다.
텍사스 오스틴 광역권도 비슷한 흐름을 보이고 있다. 스페이스X 바스트롭 캠퍼스 인근에서는 일부 직원이 마진대출을 활용해 주택을 먼저 매입하려는 움직임을 보이고 있으며, 다른 직원들은 향후 지분 매각 제한 기간이 끝나기를 기다리고 있는 것으로 전해졌다.
소비 확산은 주택에 그치지 않을 가능성이 크다. 비시냐노는 새로 부를 얻게 된 직원들이 고급 차량을 보관할 수 있는 넓은 차고를 갖춘 주택을 찾을 수 있다고 봤다. 기술기업 상장이나 대규모 유동성 이벤트 이후 고급차, 시계, 여행 등으로 소비가 확산되는 사례가 반복돼 왔다는 점도 언급됐다.
명품 시계 시장도 잠재 수혜처로 거론된다. 폴 알티에리 밥스 워치 최고경영자(CEO)는 대규모 자산을 얻게 된 이후의 '첫 고가 소비'로 시계를 선택하는 경우가 많다고 말했다.
전용기 시장에서도 관련 문의가 들어오고 있다. 플렉스젯과 아말피 제츠는 스페이스X 상장 기대와 관련한 최근 문의가 있었다고 확인했다. 아말피 제트의 콜린 존스는 일부 고객들이 이를 기념하는 여행을 위해 전세기 예약을 검토하고 있다고 전했다.
스페이스X를 둘러싼 명품 소비 기대는 아직 실제 현금화가 이뤄지기 전 단계에서 형성되고 있다. 다만 대규모 기술기업 상장이 임직원의 자산 형성뿐 아니라 지역 부동산, 고급 소비재, 프리미엄 여행 시장까지 연쇄적으로 자극할 수 있다는 점에서 관련 업계의 관심은 당분간 이어질 전망이다.
키워드 #스페이스X #IPO #일론 머스크 #롤렉스 #제트기 #전용기
이 시각 추천뉴스 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러?
日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상
IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시
마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에
클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담
XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입
Chrome, MV2 확장 프로그램을 영구적으로 중단하려는 움직임 (neowin.net)
Chrome의 MV2 확장 프로그램 지원 중단이 최종 폐기 단계에 들어가며, uBlock Origin 같은 기존 확장을 유지하던 우회 방식도 더 이상 오래 작동하기 어려워짐 Chromium 변경으로 kExtensionManifestV2Disabled 기능 플래그가 제거됐고, MV2 차단 상태를 제어하던 코드와 테스트도 함께 사라짐 Google 엔지니어 Devlin Cronin은 복잡성 , 기술 부채, 보안 위험 때문에 MV2 관련 기능을 계속 유지할 수 없다고 설명함 Chromium 150과 151에서 MV2 관련 옵션이 순차적으로 제거되며, Windows Registry 수정으로 MV2 사용 기간을 늘리던 방식도 Chromium 151 이후 작동을 멈춤 Opera는 현재 MV2 지원 입장을 유지한다고 밝혔지만 장기적으로 MV3 전환을 진행 중이며, Chrome 사용자는 MV3 기반 uBlock Origin Lite 로 전환할 수 있음 Chrome의 MV2 지원 폐기 Manifest V2에서 Manifest V3로의 전환은 계속 진행돼 왔고, Google Chrome에서는 MV2 폐기가 최종 단계에 들어간 상태임 w3c WebExtensions Community Group의 GitHub 논의에서 최신 및 향후 인기 브라우저 버전이 MV2 확장 지원의 마지막 릴리스가 될 것으로 다뤄짐 Chromium 기여자 Andrey Bershanskiy는 최근 Chromium 변경 사항을 공유했고, Google 엔지니어 Devlin Cronin의 발언에 따르면 Chrome은 MV2 사용 가능성을 제어하던 플래그 제거를 시작함 kExtensionManifestV2Disabled 는 MV2 애드온을 제어된 방식으로 비활성화하던 Chromium 기능 플래그였고, 이제 완전히 제거됨 제거된 플래그와 코드 kExtensionManifestV2Disabled 기능은 1년 넘게 기본 활성화 상태였고, 관련 기능과 사실상 죽은 코드가 제거됨 “경고” 단계에만 의존해 동작을 테스트하던 테스트들은 해당 단계에 더 이상 도달할 수 없어 제거됨 Devlin Cronin은 지원되는 Chrome 버전에서 MV2 확장 이 더 이상 허용되지 않는다고 설명함 MV2 관련 기능은 복잡성, 기술 부채, 보안 위험 때문에 무기한 제공하거나 유지할 수 없음 최근 MV2에만 관련된 버그가 여러 개 발견됐다는 설명도 함께 제시됨 우회 방식의 종료 MV2 확장을 유지하기 위해 쓰이던 트릭과 우회 방식은 Chrome에서 더 이상 작동하지 않거나 오래 유지되지 못함 uBlock Origin 같은 MV2 확장을 브라우저 확장 목록에서 더 이상 찾지 못할 수 있음 MV2 사용 가능 기간을 늘리던 Windows Registry 수정 은 Chromium 151 이후 작동을 멈춤 MV2 코드는 한꺼번에 전부 제거되지는 않지만, 여러 기능은 당분간만 작동하고 결국 사라짐 Chromium 릴리스별 변화 Chromium 150은 ExtensionManifestV2Disabled 옵션을 잃음 Chromium 151은 ExtensionManifestV2Unsupported 옵션을 잃음 Chromium 151은 ExtensionManifestV2Availability 옵션을 잃음 Chromium 151은 AllowLegacyMV2Extensions 옵션도 제거될 가능성이 있음 Edge와 Opera의 상황 Opera와 Microsoft Edge 같은 다른 Chromium 기반 브라우저도 같은 흐름을 따를 수 있음 Edge는 2월부터 uBlock Origin 비활성화 를 시작함 Opera는 2024년 10월 MV2를 더 오래 지원하겠다고 했지만, MV2 애드온 작동을 중단할 수도 있는 상황으로 다뤄짐 uBlock Origin 개발자 Raymond Hill은 Opera에 1.70.0을 다소 늦게 제출했지만 몇 주 전이었다고 말함 Raymond Hill은 Opera가 MV2 기반 확장을 포기할 계획이라는 이메일을 받았고, 그래서 그런 확장 검토에 리소스를 더 이상 배정하지 않을 수 있다고 언급함 Opera의 개발자 안내와 후속 입장 Opera Extensions Team 이메일은 Opera를 구동하는 Chromium이 Manifest Version 2 지원을 완전히 제거한다고 안내함 MV2를 사용하는 확장은 지속적 호환성을 위해 가능한 한 빨리 Manifest Version 3 로 업데이트해야 한다고 안내됨 Opera는 서비스 중단을 피하고 원활하게 전환하려면 확장을 MV3로 업데이트하는 조치를 강하게 권고함 이후 Opera는 MV2 확장 지원 입장이 현재 바뀌지 않았고, 기술적으로 합리적인 동안 MV2 확장을 계속 사용할 수 있도록 적극적으로 노력 중이라고 밝힘 Opera 사용자는 당분간 현재 설치된 MV2 확장을 별도 조치 없이 계속 사용할 수 있음 Opera의 MV3 전환과 대안 Opera는 자체적으로 MV3 확장으로 전환 중이며, MV3 전용 확장 스토어를 제공할 예정임 전환 과정에서 새 MV2 확장의 스토어 업로드는 허용되지 않음 오래되고 사용량이 적은 MV2 확장 대부분은 더 이상 다운로드할 수 없게 됨 Opera는 사용자가 결국 MV3로 전환해야 할 가능성이 점점 커지고 있다고 봄 Opera는 사용자가 업무 흐름에 맞는 대응 MV3 확장이나 대체 확장을 미리 조사하라고 권고함 남은 선택지 Brave는 MV2 지원에 완전히 동참하는 Chromium 브라우저로 다뤄지고, Vivaldi도 가능성 있는 선택지로 언급됨 Chromium 브라우저를 완전히 떠나려면 Mozilla Firefox가 대안이며, Firefox는 MV3와 MV2를 모두 지원 함 Chrome에 남으려면 MV3 기반 uBlock Origin Lite 로 전환하는 방식이 가장 쉬운 해결책으로 제시됨 uBlock Origin Lite는 MV3 기반이지만, 원래의 비-Lite 버전만큼 좋지는 않았다는 사용 경험이 제시됨 Opera는 MV3 기반으로 만들어진 자체 내장형 “더 빠른” 광고 차단기도 강조함
함께 보면 좋은 글 β Microsoft, Edge에서 uBlock Origin 및 기타 확장 프로그램 비활성화 시작 Chrome 안정 버전에서 Manifest V2를 사용하는 설치된 확장 프로그램 비활성화 시작 Google의 대대적인 안티-애드블록 업데이트 우회 방법 HN 제보: Chrome 업데이트 후 uBlock 지원 중단 크롬의 광고 차단 툴 전쟁 다음 전략: 느려지는 확장 프로그램 업데이트
Microsoft, Edge에서 uBlock Origin 및 기타 확장 프로그램 비활성화 시작
Chrome 안정 버전에서 Manifest V2를 사용하는 설치된 확장 프로그램 비활성화 시작
Google의 대대적인 안티-애드블록 업데이트 우회 방법
HN 제보: Chrome 업데이트 후 uBlock 지원 중단
크롬의 광고 차단 툴 전쟁 다음 전략: 느려지는 확장 프로그램 업데이트
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
인증 이메일 클릭후 다시 체크박스를 눌러주세요
Orion( https://orionbrowser.com )은 Mac, Linux, iPadOS, iOS용 WebKit 기반 브라우저 이고, Chrome과 Firefox 확장을 네이티브로 지원하며 uBlock Origin도 포함됩니다 확장 지원을 중단할 계획은 없습니다. 콘텐츠 차단은 우회로가 아니라 기능이고, 사용자가 브라우저에서 무엇이 실행되는지 완전히 제어해야 한다고 봅니다
2004년 11월 9일부터 Firefox에서 잘 지내고 있습니다. 같이 오세요
uBO는 이제 웹 탐색을 그나마 견딜 수 있게 해 주는 유일한 이유입니다. 테스트 삼아 이 글을 보려고 껐더니 자동 재생 동영상 광고가 십여 개 떠서 브라우저가 거의 죽을 뻔했습니다 이렇게 되면 저장된 비밀번호 같은 이유로 Chrome에 남아 있던 걸 넘어서서라도 옮길 힘이 생길 것 같습니다
Google은 본질적으로 광고 회사이고, 가능한 순간이 오면 이 틈을 막아 버릴 게 처음부터 분명했습니다 Firefox마저 결국 굴복하는 미래가 걱정됩니다. 법적으로 기능 차단을 막는 무언가가 나오기 전까지는 Ladybird 브라우저 가 유일한 희망일지도 모릅니다
HN 사람들은 왜 아직도 Chrome을 쓰나요? Edge나 Opera도 그렇고요
Firefox가 Manifest V2 를 절대 버리지 않았으면 합니다. uBlock 말고도 그걸 쓰는 확장이 많이 있습니다 Google이 정말 밀어붙였다는 게 믿기지 않습니다. 우리는 진짜 “개인용” 컴퓨팅의 종말기에 와 있는 것 같아 매우 슬픕니다
“복잡성과 기술 부채, 그리고 보안 위험 때문에 이 기능을 무기한 제공/유지할 수 없습니다. 실제로 최근 MV2에만 해당하는 버그도 여러 개 찾았습니다.”
불쌍한 Google은 Manifest V2 지원 에 쓸 자원이 없나 봅니다
Vivaldi는 어떻게 할지 궁금합니다. 내장 콘텐츠 차단기가 “충분히 좋아서” uBO가 필요 없다고 말하지만, 저는 전혀 동의하지 않습니다. 그래도 지금까지는 Manifest V2 확장 을 계속 동작하게 해 왔습니다
다음은 뭘까요? Chrome이 하드코딩된 DNS 를 넣어서 DNS 기반 광고 차단기도 못 쓰게 할까요? 제 기기에 무엇을 표시할지 정할 권리는 어디서, 언제 끝나는 건가요?
AdGuard MV3 는 잘 동작합니다. 그래도 가능하면 Firefox로 옮기세요. 생태계의 다양성은 모두에게 이롭습니다
발행일: 2026-06-13 06:22 (토)
한국어 KR 영어 EN 일본어 JP 중국어 CH
일본 NTT가 아마존 위성인터넷 서비스와 협력 관계를 확대 구축한다.
씨넷재팬에 따르면 NTT는 지난 9일까지 계열사 NTT도코모비즈니스, NTT-ME, NTT미디어서플라이 등 3개 회사를 통해 아마존LEO와 재판매 사업자 계약을 체결했다.
NTT그룹의 이들 회사는 아마존과 서비스 제공을 위한 기술 검증과 서비스 내용 검토를 거쳐 일본 내 기업고객과 정부, 공공기관 대상으로 상품을 제공한다는 방침이다.
구체적으로 재난 발생시 백업 회선, 도서산간지역 인프라 고도화를 비롯해 모빌리티, IoT, 산업용 등의 사업모델이 점쳐진다. NTT는 지상 네트워크와 시스템 통합 역량을 활용해 이같은 수요를 공략한다는 전략이다.
앞서 지난 2023년 NTT그룹은 스카파JSAT와 함께 아마존 전략적 협력을 발표했다. 재판매 사업자 계약은 기존 협력 체계에서 구체적인 진전이 이뤄졌다는 게 현지 언론의 분석이다.
나아가 우주사업브랜드 ‘NTT C89’에 따라 아마존LEO를 포함한 네트워크 융합을 통해 차세대 인프라 구축 목표를 세우고 있다.
쏠리드원텍, 514억원 규모 군위성 통합 PBL 사업 수주 2026.06.01 국내 대형선사, 위성통신 파트너로 SK텔링크 택했다 2026.05.18 미국 통신3사, 위성 대응 합작법인 추진..."스타링크 견제" 2026.05.17 저궤도 위성통신 시장에 인도 큰손 뜬다 2026.05.10
아래에서 Amazon Leo를 포함한 비지상계 네트워크(NTN·Non-Terrestrial Network) 와 지상 네트워크(TN)의 융합(TN-NTN)을 추진해, 어디서나 끊김 없이 연결되는 차세대 통신 인프라 구축을 목표로 하고 있다.
에비하라 다카시 NTT CAIO는 “위성통신을 실제 사회 인프라로 활용하기 위한 중요한 첫걸음”이라고 했다.
무료 AI로 사용자 싹쓸이 애플·구글 vs 기업 고객 집중 오픈AI
오픈AI가 기업용 AI 시장 공략에 집중하는 반면, 애플과 구글은 대규모 사용자 기반을 활용해 소비자 AI 확산에 나서고 있다. AI 시장이 기업 수익화와 대중 서비스 확대라는 두 전략으로 갈리면서 경쟁 구도가 더욱 뚜렷해지고 있다.
오픈AI가 기업용 AI 시장 공략에 집중하는 반면, 애플과 구글은 소비자 AI 확산에 나서고 있다. [사진: 셔터스톡]
[디지털투데이 AI리포터] 오픈AI가 소비자 서비스보다 기업용 인공지능(AI) 사업에 무게를 싣는 사이, 애플과 구글은 일상 속 소비자 AI 확대에 나서고 있다.
11일(이하 현지시간) CNBC에 따르면, 생성형 AI 시장이 빠르게 성장하면서 주요 기업들의 전략도 기업 수익화와 소비자 확산이라는 두 갈래로 나뉘고 있다.
애플은 이번 주 연례 개발자 행사에서 시리 AI를 별도 애플리케이션(이하 앱)으로 공개하고 아이폰 카메라, 이메일, 단축어 등에 AI 기능을 적용했다. 아동 안전 기능도 주요 기능으로 소개했다. 다만 업그레이드된 시리에 대한 기대와 달리 구체적인 출시 시점이 제시되지 않았고 일부 지역 출시 지연 우려까지 겹치면서 주가는 이틀 동안 5% 이상 하락했다.
구글도 지난달 개발자 행사에서 소비자용 AI를 전면에 내세웠다. 범용 AI 에이전트인 제미나이 스파크와 검색 기능에 통합된 정보형 에이전트, 스마트글래스, 영상 편집 도구 등을 공개했다.
애플과 구글은 경쟁 관계이지만 AI 분야에서는 협력도 이어가고 있다. 제미나이는 새 시리의 기반 기술인 애플 인텔리전스를 지원하며, 애플은 자사 최첨단 모델인 애플 파운데이션 모델 클라우드 프로에 구글과 엔비디아가 참여하고 있다고 밝혔다.
애플과 구글은 막대한 사용자 기반과 현금 여력을 바탕으로 소비자 AI 확대에 나서고 있다. 애플은 전 세계 활성 기기가 25억대 이상이라고 밝혔고, 구글은 월간 이용자 20억명 이상인 서비스를 7개 보유하고 있다. 가트너의 키엘 칼손(Kjell Carlsson)은 애플이 아이폰 판매와 아이클라우드 구독을 통해 수익을 창출하고 있어 AI 기능을 무료로 제공할 여력이 있다고 분석했다.
반면 오픈AI의 올해 주요 행보는 기업 시장에 집중돼 있다. 오픈AI는 비공개로 기업공개를 신청했으며, 지난달에는 19개 글로벌 투자사와 컨설팅사, 시스템 통합 기업이 참여하는 합작사 오픈AI 디플로이먼트 코를 출범시켰다. 이 조직은 기업 고객에게 포워드 엔지니어를 직접 투입해 모델 성능과 복잡한 업무 흐름 간의 간극을 줄이는 데 초점을 맞추고 있다.
오픈AI는 AI 컨설팅·엔지니어링 기업 토모로 인수에도 합의했다. 이번 인수에는 배치 전문가 150명이 포함된다.
소비자 서비스 일부는 정리하는 모습도 보였다. 오픈AI는 3월 영상 생성 도구 소라의 운영 방향을 조정했고, 같은 달 인스턴트 체크아웃 쇼핑 기능 전략도 수정했다. 데니스 드레서(Denise Dresser) 최고매출책임자(CRO)는 지난달 기업용 AI 도입이 본격적인 전환점에 진입했다고 밝혔다. 앞서 세라 프라이어(Sarah Friar) 최고재무책임자(CFO)는 3월 기업 부문 매출 비중이 전체의 40%까지 상승했으며 연말에는 절반 수준에 이를 것으로 전망했다.
현재 AI 시장에서 수익이 집중되는 분야는 AI 코딩이다. 개발자와 비개발자들은 오픈AI의 코덱스와 앤트로픽의 클로드 코드를 활용해 소프트웨어와 앱을 개발하고 있다. 산타클라라대학교의 램 발라(Ram Bala)는 기업 구매 주기가 복잡한 상황에서 AI 코딩이 기업 시장 진입의 가장 쉬운 통로가 되고 있다고 설명했다.
다만 소비자 시장 확대에 나선 애플과 구글 역시 부담을 안고 있다. 3월 공개된 퓨리서치센터 조사에 따르면 미국인의 절반가량은 일상 속 AI가 기대보다 우려를 더 키운다고 답했다.
그럼에도 월가는 AI 경쟁에서 승자에게는 보상을, 뒤처진 기업에는 압박을 가하고 있다. D.A. 데이비드슨의 길 루리아(Gil Luria)는 애플의 시리 앱이 향후 챗GPT와 제미나이 이용자 일부를 흡수할 가능성이 있다고 전망했다.
키워드 #오픈AI #애플 #시리 #AI #인공지능 #구글
이 시각 추천뉴스 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러?
日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상
IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시
마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에
클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담
XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입
계속할까, 그만둘까? 좌절한 창업자를 위한 실전 가이드 (thisisgoingtobebig.com)
좌절을 "우주의 판결" 로 받아들여 사업을 접기보다, 그것이 진짜 신호인지 노이즈인지 구분하는 능력 이 살아남는 창업자의 핵심 좌절의 원인을 공간(시장)·팀·아이디어 세 가지로 분리해 진단해야 올바른 대응 가능 차가운 시장은 창업자에 대한 판결이 아니라 나머지 모든 요소의 기준선을 높이는 조건 투자 가능한 팀은 단순 스킬 매칭이 아니라 고유 경험·관계를 갖춘 내부자 우위 의 팀 "내 시간·돈·감정을 들일 만큼 이 아이디어가 무엇을 증명했는가"에 명확한 신호 를 댈 수 있는지가 계속/중단 결정의 기준 피드백의 출발점: 스스로에게 높은 기준을 요구 창업자에게 "회사가 당신의 시간·돈·감정을 들일 만한 어떤 데이터를 제공했는가 "를 질문 → "안 될 것" "투자 안 함"보다 잘 전달됨 창업자가 자신의 베팅이 실체에 근거하는지 냉정·객관적으로 평가 하게 만듦 저서 Founder Unfriendly를 읽은 창업자들이 "생각보다 할 일이 많다" "투자 유치에 가깝지 않았다"고 느끼게 됨 좌절의 진단: 신호 vs 노이즈 좌절 시 본능은 "아이디어가 나쁘다, 내가 부족하다, 접을 때다"로 해석 — 가끔은 사실이나 더 자주는 노이즈 노이즈 = 신호처럼 보이는 나쁜 데이터, 또는 잘못된 변수 에 대한 진짜 데이터 살아남는 창업자는 좌절을 안 겪는 사람이 아니라, 그것이 어떤 종류인지 구분하는 사람 계속할지 그만둘지 답하기 전, 무엇에 좌절했는지부터 파악 — 후보는 세 가지이며 각각 대응이 다름 첫 번째: 공간(시장)과 문제 가장 정직하게 평가하기 쉬움 — 본인에 관한 것이 아니기 때문 미팅 잡기 쉬운가, 그 분야를 적극 찾는 투자자를 이름 댈 수 있는가, 아니면 사람들이 두려워 찾지 않는 "무덤" 이라 하는가 차가운 시장은 본인 가치에 대한 판결이 아니라 나머지 모든 것의 기준만 높임 두 번째: 팀 채용은 선택 과정 이지 인정 과정이 아님 좋은 사람은 모두에게서 가치를 보려 하지만, 결국 선택해야 하고 모두가 같은 잠재력을 갖지는 않음 중요한 기준은 본인이 팀을 높게 평가하는지가 아니라, 그 분야 투자자가 "최상급"이라 부를지 그 판단엔 대부분 창업자가 도달 못하는 수준의 시장 이해 가 필요 "제조 경험자를 찾아야겠다" 수준이 아니라, 승자·패자 기업에서 제조를 이끈 사람이 누구였고 팀의 실수 가 무엇이었으며 그들과 대화했는지 사례: 식품 사업 부부 가게로 시작해 운영을 위해 "비즈니스맨" 을 영입 영입된 인물은 가장 명석하고 인성 높은 사람이나, 스스로 그 자리에 맞지 않았다고 인정 필요했던 건 뛰어난 제너럴리스트가 아니라, 제조 공정 변화가 마진을 어떻게 움직이는지 아는 사람 그 사람에 대한 비판이 아니라 "매치"의 문제 — 그 간극이 게임의 전부 내부자 우위 그릿(끈기)은 고르게 분포하나, 깊고 구체적인 도메인 전문성 은 그렇지 않음 최상급 팀 = 고유 경험·실제 관계·사람과 실패를 직접 아는 불공정한 우위 의 팀 스킬 매칭만으로는 차가운 시장 극복 불가, 벤처 투자를 받으려면 어딘가에 아웃라이어 점수 필요 세 번째: 아이디어 창업자가 제품을 앞세워 스스로 진단을 망침 제품 우선 피칭 시 피드백이 뒤섞임 — 거절이 아이디어 탓인지, 팀에 대한 암묵적 평가인지, 시장에 대한 무관심인지 분간 불가 제품이 아니라 팀과 문제 를 앞세울 것 "우리가 누구고, 무엇을 해왔고, 어떤 문제를 쫓는지 — 이런 팀이 이걸 풀게 한다면 얼마나 투자하고 싶은가" "무엇을 만들지 보고 싶다" "바로 그 문제의 적임자를 찾고 있었다"는 답이면, 아이디어를 확정하기 전 탐색하도록 돈을 받는 드문 범주 아니라면 명확성·증명·당신을 직접 지지하는 사람 을 거치는 다른 트랙 함정: 사회적 자본과 VC 기준의 혼동 "너무 이르다, 엔젤과 지인에게서 모금하라"를 단계 문제로만 분류 하는 함정 자신의 관계로 쌓은 자본으로 모금이 가능하더라도, 그건 VC 기준 통과가 아니라 사회적 자본의 현금화 관계 때문에 좋게 보는 것일 뿐 낯선 이에겐 차가운 거절 대상 — 둘을 혼동하면 자격 없이 기관 트랙처럼 운영하게 됨 계속할 것인가 그만둘 것인가 진짜 신경 쓰는 투자자는 시간 낭비를 잔인하지 않게, 일찍 끝내줌 몇 달 헛수고의 고통은 수년간 가라앉는 배에 묶여 있는 것 에 비하면 아무것도 아님 같은 피드백도 얼마나 베팅했는지 에 따라 완전히 다르게 다가옴 본업이 있고 건 게 없는 창업자는 "다들 싫어하지만 뭔가 있다고 본다"며 반박을 환영 본업을 그만두고 돈을 쓰고 사회적 자본을 태운 창업자는 같은 말이 수년을 낭비했다는 선고 처럼 들림 가장 존중하는 말은 당신의 시간·감정이 높은 기준을 받을 자격이 있다는 것 — 그래서 이 아이디어가 무엇으로 그 기준을 넘었는가 신호를 댈 수 있으면 계속, 말문이 막히면 그건 증거가 스스로 답하는 것 편향과 정직한 피드백의 구분 여성·유색인·고령 창업자 등 좌절이 정직한 평가인지 편향인지 확신 못하는 경우 더 중요 방어는 양방향으로 작동 — 논거를 명시적으로 만들 것 정직한 피드백엔 댈 수 있는 이유가 있고, 편향엔 없음 결론: 감정이 아니라 읽기 계속할지 그만둘지를 감정으로 다루지 말 것 — 그건 읽기(reading) 공간·팀·아이디어 중 무엇이 발목을 잡는지 정직히 파악, 계속 베팅할 권리를 얻은 신호 가 무엇인지 물을 것 아직 댈 수 없다면 그것이 지금의 답 — 영원이 아니라 지금
함께 보면 좋은 글 β 미래 창업자를 위한 스타트업 아이디어 찾기 프레임워크 본질의 핵심에 도달하라 자금 조달이 나를 망가뜨렸다 창업자를 위한 2024년 계획 가이드 Ask HN: 내가 공동창업한 회사를 떠나야 할까요?
미래 창업자를 위한 스타트업 아이디어 찾기 프레임워크
Ask HN: 내가 공동창업한 회사를 떠나야 할까요?
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
인증 이메일 클릭후 다시 체크박스를 눌러주세요
발행일: 2026-06-13 06:22 (토)
한국어 KR 영어 EN 일본어 JP 중국어 CH
[데일리픽] 비트코인 '마지막 조정 vs 급락 전야' 갈림길…스페이스X 100조대 IPO 확정
이번 분석의 핵심은 하락 폭 자체보다 조정의 구조와 속도에 있다 [사진: Reve AI]
■ 비트코인, 2022년 8배 폭등 전 패턴 닮은꼴…'마지막 조정 vs 급락 전야' 갈림길
비트코인이 최근 조정 국면에서 2022년 대형 하락장과 유사한 가격 구조를 보이고 있다는 분석이 나왔다. 시장 분석가들은 현재 반등이 일시적인 안도 랠리에 불과할 수 있으며, 추가 하락이 이어질 가능성을 경고하고 있다.
시장 분석가 TARA는 비트코인이 현재 2022년 약세장에서 나타났던 'ABC 조정' 패턴과 비슷한 흐름을 보이고 있다고 진단했다. ABC 조정은 상승 추세 중 발생하는 대표적인 조정 패턴으로, 초기 하락(A파동) 이후 반등(B파동), 그리고 마지막 하락(C파동)으로 구성된다.
TARA는 2022년 비트코인 하락장이 전형적인 ABC 조정 구조를 보였다고 짚었다. 당시 A파동은 2021년 11월 6만9000달러 고점에서 시작해 2022년 1월 3만3000달러까지 밀렸다. 이후 B파동에서는 2022년 3월 4만8200달러까지 반등했지만, 뒤이어 C파동이 이어지며 같은 해 11월 약 1만5000달러까지 떨어졌다.
그는 현재 비트코인 역시 비슷한 국면에 있을 수 있다고 분석했다. 특히 최근 8만2800달러까지의 반등이 2022년 당시 B파동에 해당하는 안도 랠리와 유사한 역할을 했을 가능성을 제기했다. 다만 현재 단계에서 반등 종료 여부를 단정하기는 어렵다고 덧붙였다.
TARA는 추가 확인 조건으로 비트코인이 최소 7만2800달러 수준까지 재반등한 뒤 해당 가격대가 새로운 저항선으로 작용해야 한다고 설명했다. 이는 현재 가격인 6만1900달러 기준으로 약 17% 상승이 필요한 수준이다. 이 조건이 충족될 경우 현재 조정이 단순한 일시적 하락이 아니라 더 큰 규모의 하락 사이클 일부일 가능성이 높아진다는 분석이다.
시장 참가자들이 특히 주목하는 부분은 향후 하락 속도다. TARA는 2022년 약세장의 특징으로 마지막 C파동이 매우 빠르게 진행됐다는 점을 꼽았다. 당시 비트코인은 안도 랠리 종료 이후 의미 있는 반등 없이 급격한 하락세를 이어갔다.
실제로 2022년 C파동은 3월부터 11월까지 이어졌다. 이 가운데 초반 12주 동안 11주가 음봉이었고, 비트코인 가격은 4만8200달러에서 2022년 6월 1만7500달러까지 빠르게 내려갔다. 그는 이번에도 유사한 패턴이 반복될 경우 투자자들이 대응할 시간을 충분히 확보하지 못한 채 급락이 진행될 수 있다고 경고했다. 다만 구체적인 하락 목표 가격은 제시하지 않았다.
■ 순유입에도 힘 못 쓰는 시바이누…분위기 반전 가능성은?
시바이누가 4일 연속 거래소 순유출 뒤 순유입으로 전환했지만, 가격은 뚜렷한 반등 흐름을 만들지 못하고 있다.
SHIB는 최근 일간 기준 약 179억개 순유입을 기록했다. 거래소 순유출은 일반적으로 즉각적인 매도 압력을 낮추는 신호로 해석된다. 실제로 SHIB는 앞선 여러 거래일 동안 거래소 밖으로 물량이 빠져나갔고, 하루에는 3000억개가 넘는 SHIB가 거래 플랫폼에서 이탈하기도 했다. 다만 이번 순유입 전환 이후에도 시장 반응은 크지 않았다.
가격 흐름은 더 보수적이다. SHIB는 주요 이동평균선 아래에서 거래되고 있고, 전반적인 추세도 강한 하락 국면에 머물러 있다. 지난 3월부터 5월까지 가격을 지지하던 상승 채널이 무너진 뒤 시장 구조가 크게 바뀌었고, 이후 반등 시도 때마다 매도 압력이 커졌다는 점도 부담이다.
최근 움직임도 비슷했다. SHIB는 0.0000045달러 부근까지 급락한 뒤 일시적으로 안정을 찾고 소폭 반등했다. 그러나 거래소 흐름이 개선됐음에도 상승 탄력은 제한됐다. 50일, 100일 이동평균선은 여전히 상단 저항으로 작용하고 있고, 가격은 지역 저점 부근에서 크게 벗어나지 못했다.
온체인 데이터와 가격 흐름이 엇갈린 점도 시장이 주목하는 부분이다. 거래소 유출이 누적되는 동안 축적 움직임처럼 보이는 신호는 나왔지만, 시장 참가자들은 이를 공격적인 매수로 연결하지 않고 있다는 설명이다.
기술 지표도 아직 강세 전환을 뒷받침하지 못하고 있다. 상대강도지수는 과매도 구간에서 일부 회복했지만 전반적으로는 약한 상태다. 초기 급락 이후 거래량도 줄어들었다. 가격이 낮아졌는데도 매수자들이 적극적으로 진입하지 않고 있다는 신호다.
■ '새 주인 맞이' 카카오게임즈...경영진 교체·신작 공세로 반등 노린다
카카오게임즈가 카카오에서 라인야후가 출자한 투자목적법인으로 최대주주 변경을 앞두고 경영진 교체 수순을 밟고 있다. 동시에 하반기 신작 공세를 예고했다. 6분기 연속 적자를 끊는 분위기 반전을 이룰 수 있을지 주목된다.
카카오게임즈는 오는 22일 경기 용인시 카카오 AI 캠퍼스에서 임시 주주총회를 열고 김태환 라인게임즈 부사장과 이시우 카카오게임즈 최고사업책임자(CBO)를 사내이사로 신규 선임하는 안건을 논의한다. 두 후보는 이사 선임 후 공동대표직을 맡을 것으로 전해졌다.
두 인물의 이력이 다른 만큼 역할도 나뉠 것으로 업계는 해석한다. 김 후보는 넥슨코리아·넥슨재팬·넥슨아메리카를 거쳐 2023년 라인게임즈에 합류한 외부 전략가로, 이번 라인야후의 카카오게임즈 지분 인수를 주도한 인물로 알려졌다. 이 후보는 카카오게임즈 창립 초기부터 모바일 사업을 이끌어온 내부 사업 전문가로 조직 내 신임이 두텁다. 외부에서 온 전략가가 새 주주와의 전략적 연결고리를 맡고, 내부 인사가 조직을 안정적으로 관리하는 구도가 예상된다.
이번 주총에는 페트리코파트너스의 서석호 상무이사를 임기 9개월의 기타비상무이사로 선임하는 안건도 포함됐다. 임기가 짧다는 점에서 업계 일각에서는 향후 지배구조나 사업 구조 재편 가능성을 염두에 둔 포석이라는 해석도 나온다. 다만 카카오게임즈와 라인게임즈는 현재 합병이나 사업 통합이 논의된 바 없다는 입장이다.
이 같은 경영진 교체는 라인야후가 카카오게임즈의 최대주주로 올라서는 과정과 맞닿아 있다. LAAA인베스트먼트는 카카오 보유 지분 일부를 인수하는 한편 카카오게임즈로부터 2400억원 규모 유상증자와 600억원 규모 전환사채(CB)를 인수해 총 3000억원을 투자한다. 거래가 마무리되면 LAAA인베스트먼트는 지분 33.2%(CB 전환 후 35.8%)의 최대주주가 되고, 기존 최대주주 카카오는 지분율 14.6%의 2대 주주로 내려앉는다.
■ 스페이스X 100조대 IPO 확정...'대어 실종' 韓 시장과 대조
스페이스X가 나스닥 상장을 앞두고 100조원 넘는 자금 조달을 예고했다. 반면 국내 기업공개(IPO) 시장은 대어 부재와 상장 후 주가 부진이 겹치며 냉각 흐름을 이어가고 있어 대조를 이룬다.
스페이스X는 12일(현지시간) 나스닥 상장을 목표로 공모 절차를 진행 중이다. 이날 스페이스X는 사전에 공개한 예비 공모가 그대로 보통주 5억5555만5555주를 주당 135달러에 공모하기로 확정했다. 본공모 기준 조달 규모는 약 750억달러(약 114조원)다. 초과배정옵션이 행사될 경우 조달 규모는 더 커질 수 있다.
반면 국내 IPO 시장은 증시 강세에도 온기가 제한적이다. 한국거래소에 따르면 올해 1~5월 스팩, 리츠, 코넥스 상장을 제외한 국내 신규 상장사는 14곳, 누적 공모금액은 9799억원으로 집계됐다. 6월 들어 피스피스스튜디오가 코스닥시장에 추가 상장했지만 이를 포함해도 일반 신규 상장사는 15곳, 공모금액은 1조288억원 수준이다.
상장 기업 수보다 더 큰 문제는 대어급 공백이다. 올해 코스피 신규 상장사는 케이뱅크 1곳에 그친다. 케이뱅크는 상장 당시 시가총액 3조4000억원 규모로 올해 1분기 IPO 시장의 핵심 종목으로 꼽혔지만 공모가가 희망 범위 하단에 결정됐다. 상장 이후 주가도 부진해 이날 기준 현재가는 공모가 8300원을 밑돌고 있다.
지난해에는 LG씨엔에스, 서울보증보험, 씨케이솔루션, 달바글로벌 등 코스피 신규 상장이 시장을 받쳤다. 그러나 올해는 케이뱅크 이후 코스피 대형 공모주가 끊기면서 시장 관심이 코스닥 중소형 공모주로 쏠리고 있다. HD현대로보틱스, 한화에너지, 카카오모빌리티, SK에코플랜트 등이 잠재적 대어로 거론되지만 실제 상장 일정은 아직 유동적이다.
■ 'AI 스마트글래스' 활용 확대…현장 관리 기준은 아직
인공지능(AI)을 결합한 스마트글래스가 국내 시장에 본격 상륙한 가운데 관리 기준을 보완해야 한다는 목소리가 나온다. 최근 스마트글래스를 활용한 시험 부정행위가 연이어 적발되면서 더 이상 무시할 수 없는 관리 대상이 됐다는 지적이다.
한국토익위원회는 지난달 10일과 31일 치러진 토익 정기시험에서 스마트글래스를 통한 부정행위 시도를 적발했다. 응시자들은 시험장에서 스마트글래스를 낀 상태로 시험을 보려다 감독관에게 적발됐다.
스마트글래스는 사진·동영상 촬영을 비롯해 AI를 활용한 정보 검색, 번역 기능 등을 지원하는 기기다. 겉보기에는 일반 안경과 큰 차이가 없다. 이에 시험장에서는 문항 촬영이나 정보 검색 등 시험에 악용될 소지가 크다. 한국산업인력공단이 실시하는 정기 기사 컴퓨터기반시험(CBT) 과정에서도 스마트글래스를 착용한 수험생 3명이 적발되는 등 실제 기기 확산에 따른 부작용이 이어지고 있다.
대학수학능력시험도 예외가 아니다. 수능 시험장에는 스마트폰과 스마트워치 등 전자기기를 반입할 수 없다. 스마트글래스도 전자기기인 만큼 반입 금지 대상에 해당한다. 다만 일반 안경과 외형상 구분이 쉽지 않아 감독관이 착용 여부를 일일이 확인해야 하는 부담이 남는다.
이에 일선 교육 현장에서는 우려의 목소리가 커지고 있다. 한 교육계 관계자는 "일반 대학에서의 중간고사나 기말고사 같은 시험에서는 적발이 정말 쉽지 않을 것 같다"며 "일반 초중등 학생들에게도 보급되면 단순 소지품 검사 이상의 절차가 필요할 것"이라고 말했다.
현행 초·중등교육법은 학생의 수업 중 휴대전화 등 스마트기기 사용을 금지한다. 장애가 있거나 특수교육이 필요한 학생이 보조기기로 사용하는 경우 등에만 예외적으로 허용한다. 제한하는 스마트기기 유형은 학칙으로 정할 수 있다. 다만 스마트글래스처럼 안경 형태를 띤 기기는 현장 판단이 쉽지 않다. 특히 도수 렌즈를 장착한 제품의 경우 학생이 시력 교정을 이유로 착용 필요성을 주장할 수 있어 현장 혼란이 예상된다.
불법 촬영 우려도 여전하다. 시장 대표 모델로 꼽히는 메타 스마트글래스는 카메라 작동 시 전면 발광다이오드(LED)가 자동으로 켜지도록 설계됐다. 하지만 쿠팡과 알리익스프레스 등 온라인몰에서는 LED를 가리는 스티커나 커버형 액세서리가 버젓이 판매되고 있다. 학급 친구나 교사 대상 몰카 범죄가 빈번한 상황에서 별도 관리 기준이 필요하다는 지적이 나온다.
■ 애플, 월드컵 개막에 '비니시우스 카드' 꺼냈다…에어팟 프로 3 대대적 홍보
애플이 에어팟 프로 3의 액티브 노이즈 캔슬링(ANC) 성능을 전면에 내세운 새 광고 영상을 공개했다.
애플은 월드컵 개막에 맞춰 레알 마드리드 소속 축구선수 비니시우스 주니오르(Vinícius Júnior)를 앞세운 마케팅 영상을 선보였다.
이번 광고의 중심에는 에어팟 프로 3가 있다. 영상은 비니시우스 주니오르가 도시 곳곳을 자유롭게 이동하며 음악을 즐기는 모습으로 구성됐으며, 애플은 제품의 핵심 메시지로 세계 최고 수준의 인이어 액티브 노이즈 캔슬링을 내세웠다. 월드컵 개막 시점에 맞춰 대중 노출 효과를 극대화하려는 의도가 엿보인다.
애플은 에어팟 프로 3가 이전 세대보다 소음 차단 성능을 크게 향상했다고 강조했다. 회사는 에어팟 프로 3가 에어팟 프로 2보다 최대 2배 더 많은 소음을 차단할 수 있다고 설명했다. 또한 에어팟 프로 2 역시 1세대 에어팟 프로 대비 소음 제거 성능이 두 배 향상된 제품이라는 점도 함께 부각했다.
광고 모델 선정 역시 월드컵 시즌과 맞물린 전략으로 해석된다. 애플은 세계 최대 축구 이벤트가 시작되는 시점에 비니시우스 주니오르를 앞세워 광고를 공개했으며, 향후 수주 동안 TV를 통해 해당 광고를 집중 노출할 것으로 알려졌다. 이는 단순한 제품 홍보를 넘어 스포츠 이벤트 시청 수요가 집중되는 시기에 브랜드 메시지를 확산하려는 전략으로 풀이된다.
가격 정책도 소비자 관심을 끌고 있다. 신규 광고 공개와 함께 할인 판매가 진행되면서 애플은 제품 인지도 제고와 구매 전환 확대를 동시에 노리는 모습이다.
월드컵 기간은 TV와 온라인 영상 소비가 동시에 증가하는 시기다. 애플은 이에 맞춰 에어팟 프로 3의 대표 기능을 다시 부각하며 프리미엄 무선이어폰 시장에서 제품 존재감을 강화하려는 행보를 이어가고 있다.
디지털 경제 미디어 디지털투데이가 매일 아침, 주요 뉴스를 AI가 짚어주는 멀티미디어 뉴스 서비스를 제공합니다. 디지털투데이 텔레그램 채널에서 만나보세요. (매일 아침 06시 30분 업로드)
이 시각 추천뉴스 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입
공급망 공격 은 소프트웨어 배포 비용이 매우 낮아지고 빌드·배포 자동화가 널리 쓰이면서 더 큰 문제로 커졌음 1970년대에는 재사용 가능한 소프트웨어를 만들기 어려운 소프트웨어 위기 가 있었지만, 지금은 패키지 저장소와 패키지 관리자가 이름과 버전만으로 코드를 가져오고 빌드함 자동 의존성 갱신은 CI를 통해 악성 변경이 빠르게 퍼지게 만들며, 좋은 공급망 공격은 CI 러너 가 실행되는 속도로 확산됨 모든 의존성을 프로젝트 저장소에 함께 넣는 벤더링 은 저장소를 키우지만, 자동 변경을 막고 의존성의 규모와 비용을 더 잘 보이게 함 모든 소프트웨어에 맞는 해법은 아니지만, 많은 작은 소프트웨어는 외부에서 갑자기 바뀔 수 있는 의존성을 2~3개 수준 으로 줄이는 이점을 얻을 수 있음 문제 공급망 공격은 소프트웨어나 유지보수의 본질만 바뀌어서가 아니라, 소프트웨어 공유와 배포의 비용 모델이 매우 낮아지면서 점점 더 큰 문제가 됨 배포 비용이 너무 낮아져 낭비가 있더라도 자동화를 많이 쓰게 되었고, 자동화 자체는 유용함 몇 달마다 새로운 공급망 공격이 발생해 세계 코드의 큰 부분을 망가뜨리는 일이 생김 어떻게 여기까지 왔나 1960년대 후반과 1970년대 초반에는 사람들이 재사용 가능한 소프트웨어를 만드는 방법을 잘 몰랐고, 이를 소프트웨어 위기 라고 불렀음 소프트웨어 수요는 지수적으로 증가했지만, 요구되는 복잡도에 맞는 새 소프트웨어를 만드는 능력은 그보다 느리게 증가했음 이 시기는 모듈성, 구조적 프로그래밍 같은 연구로 이어졌고, 1990년 이후 만들어진 거의 모든 프로그래밍 언어 모듈 시스템은 Modula-2까지 계보를 거슬러 올라갈 수 있음 1990년대와 2000년대에는 인터넷이 더 강력한 해법을 만들었고, 소프트웨어 빌드와 배포가 저렴해졌으며 실제로 쓰고 싶은 소프트웨어 상당수는 오픈소스였음 CPAN, CTAN, Linux 배포판을 바탕으로 많은 패키지 저장소 와 패키지 관리자 가 생겼고, 이 도구들은 매니페스트 파일, 이름, 대개 임의적인 버전 번호만으로 소프트웨어를 찾고 가져오고 빌드함 수작업 통합에서 자동 의존성으로 과거 복잡한 소프트웨어 시스템을 만드는 좋은 방법은 작동하는 조각들을 손으로 신중하게 조립하는 것이었고, Linux 배포판이 기본적으로 이런 일을 함 2003년에 SDL을 모든 기능과 함께 빌드하려면 며칠이 걸릴 만큼 고통스러웠고, 그런 시절을 그리워할 필요는 없음 Linux 배포판이 알려진 기본 환경으로 있으면 많은 맞춤형 소프트웨어는 자체 세계 안에서 동작하고 시스템의 다른 부분을 크게 신경 쓰지 않아도 됨 다른 소프트웨어와 통신할 때는 잘 알려진 프로토콜을 쓰는 파일이나 네트워크 소켓을 통하는 경우가 많음 Rust나 Go로 처음부터 빌드되거나 Docker 컨테이너로 배포되는 좋은 소프트웨어가 많아졌고, 이런 소프트웨어는 시스템 라이브러리와 거의 상호작용하지 않음 OS 배포판이 제공하는 소프트웨어 집합에 맞추기보다, 필요한 라이브러리를 빌드 시스템이 직접 가져오는 방식이 널리 쓰임 반대 방향의 위기 현재는 1970년대와 반대로 사람들이 소프트웨어를 너무 많이 재사용해 프로그램이 더 나빠지는 위기가 생김 소프트웨어 배포는 여전히 매우 저렴하지만, 소프트웨어를 사용하는 데에는 여전히 비용이 있음 오랫동안 가장 큰 비용은 소프트웨어를 빌드하고 컴퓨터에서 실행되게 하는 복잡성이었지만, 그 문제는 상당 부분 자동화로 사라졌음 이제 훨씬 더 많은 소프트웨어를 빌드·배포·사용하게 되었고, 그 비용은 의존성 지옥, 비대화, 긴 빌드 시간, 패키지나 패키지 관리자의 실종 같은 형태로 나타남 가장 큰 문제는 공급망 공격 임 공급망 공격의 확산 구조 공급망 공격은 오픈소스 소프트웨어만큼 오래된 문제임 과거 Linux 커널에 uid == 0 대신 uid = 0 을 넣으려던 악성 패치 시도는 야생에서 목격된 첫 악성 커널 패치였고, 공급망 공격 시도에 해당함 최근 10년 동안 공급망 공격이 더 크고 문제가 된 이유는 빌드 시스템이 소스 코드를 가져오고 배포하도록 자동화되었기 때문임 CI 시스템은 보통 모든 코드 변경이나 큰 변경에서 실행되고, 이런 변경은 해당 코드에 의존하는 모든 사람에게 자동으로 사용 가능해짐 의존하는 쪽의 CI 시스템도 변경을 가져와 새로 들어간 악성 코드를 포함하게 되고, 좋은 공급망 공격은 CI 러너가 실행되는 속도로 산불처럼 퍼짐 의존성 쿨다운처럼 공급망 공격을 늦추는 방법도 있지만, 정책과 책임 소재를 둘러싼 논쟁이 생김 해법 npm , cargo 같은 빌드 시스템이 매번 네트워크 위치에서 의존성을 자동으로 가져오게 하지 말고, 모든 의존성을 소프트웨어와 함께 넣는 방식이 핵심임 프로젝트에 모든 의존성을 벤더링 하고, 업스트림 소스 제어 내용을 git 저장소에 복사해 커밋함 업스트림 업데이트가 있으면 내려받아 다시 복사하고, 수작업이 지겨워지면 빌드 도구가 이를 자동화하게 하면 됨 이미 lockfile이 있다면, 소스 제어 안의 전체 소스 트리와 연결되게 만들면 됨 모든 소스 코드 줄을 강하게 통제하는 방식으로 소유함 비용과 트레이드오프 저장소는 커지지만 디스크 공간은 저렴함 전송 비용은 디스크보다 덜 저렴하지만, 이 논의에서는 감수해야 할 요소로 남음 빌드 시간은 커질 것처럼 보이지만, 어차피 그 의존성들을 다시 빌드하고 있었기 때문에 반드시 늘어나지는 않음 코드 재사용은 더 어려워질 수 있으며, 공유 프로토콜 라이브러리를 쓰는 클라이언트와 서버 같은 프로그램에서는 실제 문제가 될 수 있음 그런 프로그램은 이미 버전 불일치 문제를 갖고 있고 이를 처리해야 하므로, 실제로 주의를 기울이게 만드는 일이 장기적으로 더 나쁘지는 않음 공급망 공격의 방화선 의존성을 자동으로 갱신하지 않으면 생태계의 모든 패키지가 공급망 공격의 방화선 이 됨 같은 방식은 버그 수정과 패치 전파도 막지만, 중요한 수정이라면 어차피 사람이 수동으로 찾아보게 됨 사람이 찾아보지 않는 수정은 대개 중요하지 않은 경우가 많음 semver나 “서로 다른 두 코드가 같은 방식으로 동작해야 한다”는 개념을 빌드 시스템에서 버리고, 모든 버전 번호를 서로 무관한 고유한 것으로 다뤄도 비슷한 효과를 낼 수 있음 semver의 문제는 실제 현실이 아니라 사람의 의도를 표현하며, 그마저도 어느 정도 올바르게 쓰일 때만 작동한다는 점임 버전 번호를 고유하게 다루는 방식은 의존성이 사라지거나, 변조되거나, 패키지 내용이 다른 방식으로 훼손되는 문제를 해결하지 못함 의존성 가시성 모든 의존성을 벤더링하면 자동 변경을 늦추는 것 외에도 의존성 사용 비용이 조금 올라감 비용 증가는 회복 불가능한 수준이 아니며, 업스트림 코드를 사용할 때 조금 더 생각하게 만드는 정도임 새 의존성을 추가할 때 “정말 필요한가”를 다시 묻게 만드는 부드러운 장치가 됨 의존성의 가시성 이 높아지고, 의존성 뒤에 숨은 비대함이 덜 숨겨짐 200줄 정도일 것 같은 단순 라이브러리를 추가했는데 50,000줄이었다면, 멈춰서 이유를 물어야 한다는 점이 더 명확해짐 의존성의 마법 같은 성격이 줄어들고, 코드베이스 안의 버그가 다른 사람의 코드로 이어지는 경로를 더 쉽게 추적할 수 있음 의존성 트리와 공유 문제 모든 것을 기본으로 벤더링하면 더 평평하고 넓은 의존성 트리를 유도할 수 있음 C++의 Boost나 Qt 같은 거대 라이브러리 수준까지 가는 것은 바람직하지 않음 그런 거대 라이브러리는 작은 C/C++ 라이브러리를 만들고 쓰는 일이 너무 어렵기 때문에 존재함 Boost나 Qt 같은 것을 직접 빌드 방법까지 파악하기보다, Linux 배포판 같은 시스템 통합자가 한 번만 해주는 편이 낫다는 전제가 있음 실제 단점은 전이 의존성이 공유되지 않는다는 점임 lib A와 lib B가 모두 Z에 의존할 때 중복 제거는 불가능하지 않지만 더 어려워지고, 사람이 직접 하거나 더 정교한 도구가 필요함 전이 의존성이 공유될 때도 문제가 생기며, 전이 의존성을 갖는 것 자체가 문제의 일부임 라이브러리가 전이 의존성을 지정하도록 허용하는 일은 프로그램에 대한 통제를 다른 사람에게 넘기는 행위가 됨 분석 모든 소프트웨어가 이 방식을 쓸 수 있는 것은 아님 웹앱 백엔드 배포의 일부로 Redis 전체를 벤더링하고 빌드하는 방식은 특별히 합리적이지 않음 다만 배포가 Ansible이나 Docker 이미지 등으로 자동화되어 있다면, 이미 사실상 비슷한 일을 하고 있을 가능성이 있음 이 방식이 견딜 수 있는 복잡도에는 상한이 있지만, Google과 Facebook 같은 거대 모노레포 기업은 그 상한이 생각보다 높을 수 있음을 보여줌 어느 시점에서는 의존성이 운영체제와 만나며, 운영체제는 자체 문제가 많은 큰 의존성임 웹 백엔드용 unikernel 아이디어는 매력적이지만, 실제 도구 문제가 있고 아직 그 단계에 도달하지 못함 Linux 배포판과 빌드 환경 이 방식은 Linux 배포판이나 BSD 같은 완전한 상호작용 시스템을 만드는 방법이 아님 그런 시스템은 함께 동작해야 하는 많은 프로그램과 라이브러리가 있으므로 다른 문제에 해당함 이 원칙을 끝까지 밀어붙이면 Nix나 Guix 같은 방식에 가까워짐 “빌드 환경”을 올바르게 조립해야 한다는 개념은 “소프트웨어를 어떻게 빌드할 것인가”라는 문제를 게으르고 불충분하게 푼 방식에 가까움 이 개념은 어떤 미니컴퓨터에서 소프트웨어를 한 번 빌드한 뒤 바이너리로 널리 공유하던 시절의 잔재임 오늘날에는 1970년대보다 훨씬 더 많은 소프트웨어를 즉석에서 빌드함 적용 가능한 범위 이 방식은 만능 해법이 아니지만, 많은 소프트웨어는 적용할 수 있고 이점을 얻을 수 있음 대부분의 소프트웨어는 작고, 큰 프로젝트는 이미 이런 문제를 많이 해결해야 함 순수 계산만 하거나 파일과 네트워크 소켓 같은 기본적이고 이식 가능한 I/O로만 외부와 접촉하는 라이브러리가 많이 있음 압축 라이브러리, libcurl, TUI 라이브러리, Django 같은 예시는 벤더링 대상으로 다룰 수 있음 벤더링하면 버전 충돌이나 갑작스러운 패치로 들어온 버그 때문에 새 시스템에 배포하거나 빌드할 때 원인을 알 수 없게 깨지는 일을 거의 피할 수 있음 목표는 외부에서 예고 없이 바뀔 수 있는 의존성을 200~300개가 아니라 많아도 2~3개 수준으로 줄이는 것임 결론 의존성 자동 갱신을 줄이고 프로젝트가 직접 의존성 소스까지 보유하면 공급망 공격의 자동 확산을 늦출 수 있음 의존성 사용 비용을 조금 높이고 가시성을 높이면, 불필요한 재사용과 숨은 비대함을 더 쉽게 발견할 수 있음 이 방식은 모든 시스템에 맞지 않지만, 작은 소프트웨어와 많은 라이브러리에는 실용적인 이점이 있음
함께 보면 좋은 글 β 모두가 의존성 쿨다운을 사용해야 하는 이유 더 적게 의존할수록 안전하다: 공급망 공격 위험을 줄이는 Obsidian의 접근 방식 GitHub Actions에는 패키지 관리자가 있지만, 최악일 수 있다 Mini Shai-Hulud가 다시 공격: npm 패키지 314개 침해 우리가 소프트웨어를 망가뜨리고 있음
더 적게 의존할수록 안전하다: 공급망 공격 위험을 줄이는 Obsidian의 접근 방식
GitHub Actions에는 패키지 관리자가 있지만, 최악일 수 있다
Mini Shai-Hulud가 다시 공격: npm 패키지 314개 침해
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
인증 이메일 클릭후 다시 체크박스를 눌러주세요
▲ GN⁺ 19시간전 [-] Lobste.rs 의견들 Zig 패키지 관리자 는 꽤 괜찮은 절충안이라고 봄 모든 패키지가 콘텐츠 해시로 고정돼서 기본적으로 잠금 파일이 있는 셈이고, “상위 저장소가 갑자기 악성으로 바뀌는” 문제는 피하면서도 “상위 저장소가 사라지는” 문제는 남아 있음 다만 전역/로컬 캐시가 모두 있고 콘텐츠 해시 기반이라, 상위 저장소가 사라지면 로컬 사본의 tarball을 필요한 곳에 던져 넣으면 됨 “소스를 벤더링하기”와 “단순하고 재사용 가능한 소프트웨어” 사이의 좋은 절충으로 보임 그 방식을 모든 소프트웨어로 확장할 수도 있고 꽤 멋질 것 같음 모든 소스를 콘텐츠 주소 지정 저장소 에 두고, 각 프로그램은 입력들의 해시를 바탕으로 해시하면 됨 대체로 동의하지만, 그 구성을 어떻게 공격할 수 있을지는 조금 궁금함 아마 잠금 파일을 수정하거나 해시 충돌 을 찾아야 할 텐데, 둘 다 쉬워 보이진 않음 다만 cargo 생태계에 익숙하다 보니 완전히 마음에 들지는 않음. 의존성을 올리면 그 전이 의존성들도 별다른 말 없이 함께 올라가는 경향이 있고, 의미적 버전 범위에 맞는 다른 것들도 같이 바뀌기 때문임 “공급망 공격”이라고 하기엔, 제안과 대가가 있는 서명된 계약이 없으니 공급망은 아니라고 봄 별개로, 의존성이 아래에서 바뀌지 않게 보장한다는 관점에서는 해시가 들어간 잠금 파일이나 Go의 최소 버전 선택 방식이 의존성 벤더링과 동일함 벤더링에는 마찰이 생긴다는 차이는 이해하지만, 극단으로 가면 직접 구현하거나 더 나쁘게는 의존성을 즉흥 생성 코드로 만들게 되므로, 도메인 전문가가 작성하고 충분히 검증된 소프트웨어를 쓰는 편이 낫다고 봄 Facebook에서 이쪽 일을 했는데, 그곳의 서드파티 의존성 관리 는 누구에게도 권하고 싶지 않음. 특정 Rust 크레이트의 직접 의존성은 fbsource 전체에서 의미적 버전이 호환되지 않는 버전이 동시에 최대 두 개까지만 허용됨. 의존성을 업데이트하려면 fbsource 전체를 업데이트하는 부담을 떠안아야 함 Facebook에는 맞는 방식일 수 있지만, 특별히 훌륭하거나 지속 가능하다고 보긴 어려움 궁금한데 왜 “최대 두 개”인지 모르겠음. 예전 버전에서 새 버전으로 점진적 마이그레이션 을 하기 위해서인가? “특별히 훌륭하거나 지속 가능하지 않다”는 건 정책 자체보다는 규모의 함수에 가깝다고 의심함. 여러 버전을 허용하면 또 다른 문제가 생기는데, TypeScript를 제외한 대부분의 현대 언어가 주로 또는 전적으로 명목적 타입을 쓰기 때문에, 깨지는 변경마다 “semver trick”을 쓰지 않으면 버전 간 타입 재사용이 막힘 Log4Shell 때는 버전이 많고 여러 곳에 흩어진 회사들이, 버전 수가 적거나 고정해 둔 회사들보다 업그레이드에 더 고생했던 기억이 뚜렷함 맞음, 그럼 의존성 공격 이라고 부르면 되겠음 <3 The Third Networking Truth 에 따르면 “충분한 추진력이 있으면 돼지도 잘 난다. 하지만 그것이 꼭 좋은 생각이라는 뜻은 아니다” Google/Facebook 같은 곳에서 인용되는 많은 관행은 그 회사들이 충분한 추진력 을 투입할 수 있기 때문에만 작동함 예를 들어 그런 곳 중 일부는 모노레포와 의존성 관련 선택을 지원하기 위해, 내가 다니는 회사 전체 인원보다 더 큰 팀을 붙이는 걸 알고 있음. 그들은 감당할 수 있지만, 우리 대부분은 감당하기 어려움 좋은 견해임. “모든 의존성을 벤더링하면 의존성을 쓰는 비용이 올라간다”는 점에 강하게 동의함 다만 libcurl 을 복사해 붙여 넣지는 말아야 함. 대부분의 라이브러리에는 괜찮은 전략이지만, 적대적 입력을 다루는 C 프로그램에는 좋은 조언이 아님. 운영체제가 libcurl을 안전하게 유지하는 것보다 더 잘할 수는 없음 한 번도 생각 못 했던 점은 apt 같은 최종 사용자용 패키지 관리자가 먼저 나오고, 언어 수준 패키지 관리자가 나중에 나온 게 적어도 조금 이상하다는 것임 이게 실제로 많은 문제를 일으켰다고 봄. 2000년대 초반 rubygems를 보면 프로젝트별 관리가 아니라 시스템 전체 설치가 기본인 식으로 “Ruby용 apt”를 만들려 했던 게 꽤 명확함. 그 실수의 피해를 되돌리는 데 bundler를 추가하며 수십 년이 걸렸지만, 처음부터 프로젝트 격리 필요성을 인정했다면 bundler는 필요 없었을 것임 Python은 아직도 이 혼란을 수습 중이고, Perl도 아마 그럴 것 같지만 자세히는 모름 그러니까 한계는 있긴 한 셈임 :-) 정확히 어디에 선을 그을지가 어려울 뿐임 역사적으로 패키지 관리자는 원래 시스템을 빌드 하는 방식이었고, 그런 시스템에는 여러 사용자, 데스크톱 환경, 함께 동작하는 많은 소프트웨어가 있었음 소프트웨어 빌드에는 시간과 메모리가 많이 들었고, 디스크와 RAM에 비해 소프트웨어가 아주 많았으니 라이브러리 재사용이 중요했음 웹앱이 부상하면서 중요한 컴퓨터 대부분은 평생 소수의 프로그램만 돌리는 서버가 됐고, 디스크와 RAM이 충분히 싸져서 코드 바이너리 크기는 덜 중요해짐 시스템을 만드는 도구들은 시대 변화에 그만큼 따라가지 못했고, 그래서 소프트웨어를 만드는 대부분의 사람은 공유 라이브러리가 많은 거대한 상호연결 시스템이 아니라 단일 프로그램을 잘 만드는 도구만 필요로 하게 됨 이 역사와 나란히 “C에는 제대로 된 모듈 시스템이 없다”는 흐름도 있지만, 여기서는 덜 중요함 틀릴 수도 있지만, 복사해 온 의존성에 버그가 있어도 스캐너가 감지하지 못하는 단점이 있을 것 같음 그렇다면 원래라면 알림을 받았을 잠재 문제가 조용히 남아 있을 수 있음 이런 스캐너들이 만들어내는 오탐 수를 보면 오히려 장점일 수도 있음 스캐너는 문제가 될 수 있는 것을 보여주는 데는 매우 유용하지만, 스캐너가 문제라고 생각했으나 실제로는 아닌 것을 고치느라 예정된 일을 갑자기 미루게 만들 때는 매우 골치 아픔 제안대로 소프트웨어에 모든 의존성을 포함하고, 상위 소스 관리를 git 저장소에 복사해 커밋하고, 수작업이 지겨우면 빌드 도구가 자동화하게 만들면, 결국 한 바퀴 돌아서 다시 서드파티 소프트웨어 를 보지 않고 포함하는 셈 아닌가? 계속 읽어보면, 빌드 시스템에서 의미적 버전이나 “서로 다른 두 코드가 같게 동작해야 한다”는 개념을 버리고 모든 버전 번호를 서로 고유하고 무관한 것으로 다뤄도 같은 효과를 낼 수 있다고 함 하지만 그 방식은 의존성이 사라지거나 변조되는 문제, 또는 누군가 패키지 내용을 다른 방식으로 손대는 문제를 해결하지 못함. 최적화에 가깝고, 내 생각엔 성급한 최적화임. 언젠가 그렇게 갈 수는 있겠지만 시작점으로 삼으면 안 됨 답변달기
Lobste.rs 의견들 Zig 패키지 관리자 는 꽤 괜찮은 절충안이라고 봄 모든 패키지가 콘텐츠 해시로 고정돼서 기본적으로 잠금 파일이 있는 셈이고, “상위 저장소가 갑자기 악성으로 바뀌는” 문제는 피하면서도 “상위 저장소가 사라지는” 문제는 남아 있음 다만 전역/로컬 캐시가 모두 있고 콘텐츠 해시 기반이라, 상위 저장소가 사라지면 로컬 사본의 tarball을 필요한 곳에 던져 넣으면 됨 “소스를 벤더링하기”와 “단순하고 재사용 가능한 소프트웨어” 사이의 좋은 절충으로 보임 그 방식을 모든 소프트웨어로 확장할 수도 있고 꽤 멋질 것 같음 모든 소스를 콘텐츠 주소 지정 저장소 에 두고, 각 프로그램은 입력들의 해시를 바탕으로 해시하면 됨 대체로 동의하지만, 그 구성을 어떻게 공격할 수 있을지는 조금 궁금함 아마 잠금 파일을 수정하거나 해시 충돌 을 찾아야 할 텐데, 둘 다 쉬워 보이진 않음 다만 cargo 생태계에 익숙하다 보니 완전히 마음에 들지는 않음. 의존성을 올리면 그 전이 의존성들도 별다른 말 없이 함께 올라가는 경향이 있고, 의미적 버전 범위에 맞는 다른 것들도 같이 바뀌기 때문임 “공급망 공격”이라고 하기엔, 제안과 대가가 있는 서명된 계약이 없으니 공급망은 아니라고 봄 별개로, 의존성이 아래에서 바뀌지 않게 보장한다는 관점에서는 해시가 들어간 잠금 파일이나 Go의 최소 버전 선택 방식이 의존성 벤더링과 동일함 벤더링에는 마찰이 생긴다는 차이는 이해하지만, 극단으로 가면 직접 구현하거나 더 나쁘게는 의존성을 즉흥 생성 코드로 만들게 되므로, 도메인 전문가가 작성하고 충분히 검증된 소프트웨어를 쓰는 편이 낫다고 봄 Facebook에서 이쪽 일을 했는데, 그곳의 서드파티 의존성 관리 는 누구에게도 권하고 싶지 않음. 특정 Rust 크레이트의 직접 의존성은 fbsource 전체에서 의미적 버전이 호환되지 않는 버전이 동시에 최대 두 개까지만 허용됨. 의존성을 업데이트하려면 fbsource 전체를 업데이트하는 부담을 떠안아야 함 Facebook에는 맞는 방식일 수 있지만, 특별히 훌륭하거나 지속 가능하다고 보긴 어려움 궁금한데 왜 “최대 두 개”인지 모르겠음. 예전 버전에서 새 버전으로 점진적 마이그레이션 을 하기 위해서인가? “특별히 훌륭하거나 지속 가능하지 않다”는 건 정책 자체보다는 규모의 함수에 가깝다고 의심함. 여러 버전을 허용하면 또 다른 문제가 생기는데, TypeScript를 제외한 대부분의 현대 언어가 주로 또는 전적으로 명목적 타입을 쓰기 때문에, 깨지는 변경마다 “semver trick”을 쓰지 않으면 버전 간 타입 재사용이 막힘 Log4Shell 때는 버전이 많고 여러 곳에 흩어진 회사들이, 버전 수가 적거나 고정해 둔 회사들보다 업그레이드에 더 고생했던 기억이 뚜렷함 맞음, 그럼 의존성 공격 이라고 부르면 되겠음 <3 The Third Networking Truth 에 따르면 “충분한 추진력이 있으면 돼지도 잘 난다. 하지만 그것이 꼭 좋은 생각이라는 뜻은 아니다” Google/Facebook 같은 곳에서 인용되는 많은 관행은 그 회사들이 충분한 추진력 을 투입할 수 있기 때문에만 작동함 예를 들어 그런 곳 중 일부는 모노레포와 의존성 관련 선택을 지원하기 위해, 내가 다니는 회사 전체 인원보다 더 큰 팀을 붙이는 걸 알고 있음. 그들은 감당할 수 있지만, 우리 대부분은 감당하기 어려움 좋은 견해임. “모든 의존성을 벤더링하면 의존성을 쓰는 비용이 올라간다”는 점에 강하게 동의함 다만 libcurl 을 복사해 붙여 넣지는 말아야 함. 대부분의 라이브러리에는 괜찮은 전략이지만, 적대적 입력을 다루는 C 프로그램에는 좋은 조언이 아님. 운영체제가 libcurl을 안전하게 유지하는 것보다 더 잘할 수는 없음 한 번도 생각 못 했던 점은 apt 같은 최종 사용자용 패키지 관리자가 먼저 나오고, 언어 수준 패키지 관리자가 나중에 나온 게 적어도 조금 이상하다는 것임 이게 실제로 많은 문제를 일으켰다고 봄. 2000년대 초반 rubygems를 보면 프로젝트별 관리가 아니라 시스템 전체 설치가 기본인 식으로 “Ruby용 apt”를 만들려 했던 게 꽤 명확함. 그 실수의 피해를 되돌리는 데 bundler를 추가하며 수십 년이 걸렸지만, 처음부터 프로젝트 격리 필요성을 인정했다면 bundler는 필요 없었을 것임 Python은 아직도 이 혼란을 수습 중이고, Perl도 아마 그럴 것 같지만 자세히는 모름 그러니까 한계는 있긴 한 셈임 :-) 정확히 어디에 선을 그을지가 어려울 뿐임 역사적으로 패키지 관리자는 원래 시스템을 빌드 하는 방식이었고, 그런 시스템에는 여러 사용자, 데스크톱 환경, 함께 동작하는 많은 소프트웨어가 있었음 소프트웨어 빌드에는 시간과 메모리가 많이 들었고, 디스크와 RAM에 비해 소프트웨어가 아주 많았으니 라이브러리 재사용이 중요했음 웹앱이 부상하면서 중요한 컴퓨터 대부분은 평생 소수의 프로그램만 돌리는 서버가 됐고, 디스크와 RAM이 충분히 싸져서 코드 바이너리 크기는 덜 중요해짐 시스템을 만드는 도구들은 시대 변화에 그만큼 따라가지 못했고, 그래서 소프트웨어를 만드는 대부분의 사람은 공유 라이브러리가 많은 거대한 상호연결 시스템이 아니라 단일 프로그램을 잘 만드는 도구만 필요로 하게 됨 이 역사와 나란히 “C에는 제대로 된 모듈 시스템이 없다”는 흐름도 있지만, 여기서는 덜 중요함 틀릴 수도 있지만, 복사해 온 의존성에 버그가 있어도 스캐너가 감지하지 못하는 단점이 있을 것 같음 그렇다면 원래라면 알림을 받았을 잠재 문제가 조용히 남아 있을 수 있음 이런 스캐너들이 만들어내는 오탐 수를 보면 오히려 장점일 수도 있음 스캐너는 문제가 될 수 있는 것을 보여주는 데는 매우 유용하지만, 스캐너가 문제라고 생각했으나 실제로는 아닌 것을 고치느라 예정된 일을 갑자기 미루게 만들 때는 매우 골치 아픔 제안대로 소프트웨어에 모든 의존성을 포함하고, 상위 소스 관리를 git 저장소에 복사해 커밋하고, 수작업이 지겨우면 빌드 도구가 자동화하게 만들면, 결국 한 바퀴 돌아서 다시 서드파티 소프트웨어 를 보지 않고 포함하는 셈 아닌가? 계속 읽어보면, 빌드 시스템에서 의미적 버전이나 “서로 다른 두 코드가 같게 동작해야 한다”는 개념을 버리고 모든 버전 번호를 서로 고유하고 무관한 것으로 다뤄도 같은 효과를 낼 수 있다고 함 하지만 그 방식은 의존성이 사라지거나 변조되는 문제, 또는 누군가 패키지 내용을 다른 방식으로 손대는 문제를 해결하지 못함. 최적화에 가깝고, 내 생각엔 성급한 최적화임. 언젠가 그렇게 갈 수는 있겠지만 시작점으로 삼으면 안 됨
Zig 패키지 관리자 는 꽤 괜찮은 절충안이라고 봄 모든 패키지가 콘텐츠 해시로 고정돼서 기본적으로 잠금 파일이 있는 셈이고, “상위 저장소가 갑자기 악성으로 바뀌는” 문제는 피하면서도 “상위 저장소가 사라지는” 문제는 남아 있음 다만 전역/로컬 캐시가 모두 있고 콘텐츠 해시 기반이라, 상위 저장소가 사라지면 로컬 사본의 tarball을 필요한 곳에 던져 넣으면 됨 “소스를 벤더링하기”와 “단순하고 재사용 가능한 소프트웨어” 사이의 좋은 절충으로 보임
“공급망 공격”이라고 하기엔, 제안과 대가가 있는 서명된 계약이 없으니 공급망은 아니라고 봄 별개로, 의존성이 아래에서 바뀌지 않게 보장한다는 관점에서는 해시가 들어간 잠금 파일이나 Go의 최소 버전 선택 방식이 의존성 벤더링과 동일함 벤더링에는 마찰이 생긴다는 차이는 이해하지만, 극단으로 가면 직접 구현하거나 더 나쁘게는 의존성을 즉흥 생성 코드로 만들게 되므로, 도메인 전문가가 작성하고 충분히 검증된 소프트웨어를 쓰는 편이 낫다고 봄 Facebook에서 이쪽 일을 했는데, 그곳의 서드파티 의존성 관리 는 누구에게도 권하고 싶지 않음. 특정 Rust 크레이트의 직접 의존성은 fbsource 전체에서 의미적 버전이 호환되지 않는 버전이 동시에 최대 두 개까지만 허용됨. 의존성을 업데이트하려면 fbsource 전체를 업데이트하는 부담을 떠안아야 함 Facebook에는 맞는 방식일 수 있지만, 특별히 훌륭하거나 지속 가능하다고 보긴 어려움
The Third Networking Truth 에 따르면 “충분한 추진력이 있으면 돼지도 잘 난다. 하지만 그것이 꼭 좋은 생각이라는 뜻은 아니다” Google/Facebook 같은 곳에서 인용되는 많은 관행은 그 회사들이 충분한 추진력 을 투입할 수 있기 때문에만 작동함 예를 들어 그런 곳 중 일부는 모노레포와 의존성 관련 선택을 지원하기 위해, 내가 다니는 회사 전체 인원보다 더 큰 팀을 붙이는 걸 알고 있음. 그들은 감당할 수 있지만, 우리 대부분은 감당하기 어려움
좋은 견해임. “모든 의존성을 벤더링하면 의존성을 쓰는 비용이 올라간다”는 점에 강하게 동의함 다만 libcurl 을 복사해 붙여 넣지는 말아야 함. 대부분의 라이브러리에는 괜찮은 전략이지만, 적대적 입력을 다루는 C 프로그램에는 좋은 조언이 아님. 운영체제가 libcurl을 안전하게 유지하는 것보다 더 잘할 수는 없음 한 번도 생각 못 했던 점은 apt 같은 최종 사용자용 패키지 관리자가 먼저 나오고, 언어 수준 패키지 관리자가 나중에 나온 게 적어도 조금 이상하다는 것임 이게 실제로 많은 문제를 일으켰다고 봄. 2000년대 초반 rubygems를 보면 프로젝트별 관리가 아니라 시스템 전체 설치가 기본인 식으로 “Ruby용 apt”를 만들려 했던 게 꽤 명확함. 그 실수의 피해를 되돌리는 데 bundler를 추가하며 수십 년이 걸렸지만, 처음부터 프로젝트 격리 필요성을 인정했다면 bundler는 필요 없었을 것임 Python은 아직도 이 혼란을 수습 중이고, Perl도 아마 그럴 것 같지만 자세히는 모름
틀릴 수도 있지만, 복사해 온 의존성에 버그가 있어도 스캐너가 감지하지 못하는 단점이 있을 것 같음 그렇다면 원래라면 알림을 받았을 잠재 문제가 조용히 남아 있을 수 있음
제안대로 소프트웨어에 모든 의존성을 포함하고, 상위 소스 관리를 git 저장소에 복사해 커밋하고, 수작업이 지겨우면 빌드 도구가 자동화하게 만들면, 결국 한 바퀴 돌아서 다시 서드파티 소프트웨어 를 보지 않고 포함하는 셈 아닌가?
AI '미토스'급 '페이블 5' 공개: Opus 4.8의 2배 값을 할 것인가
12일 서울 강남구 코엑스에 마련된 문구 페어 ‘인벤타리오 2026’ 전시장 도입부에 위치한 네이버 라운지는 이같은 질문을 던지며 관람객들을 반겼다. 현장에는 얼굴 인식으로 입장부터 결제까지 모두 가능한 네이버의 신기술과 손으로 기록하는 아날로그 감성이 서로 연결되며, 기술 넘어선 기록의 가치를 엿볼 수 있었다.
인벤타리오는 물품 및 문건에 관한 기록물과 목록이라는 의미를 가진 스페인어로, 지난해 첫 개최 후 다양한 창작 도구와 문구 브랜드를 한 자리에서 보여주는 큐레이션 행사로 자리잡았다.
문구 마니아 집결한 인벤타리오…네이버 페이스사인으로 입장 시간 단축
지난 10일부터 오는 14일까지 이어지는 올해 행사는 2030 여성이 주요 타겟층으로, 전년 대비 규모를 2배 이상 확대해 총 103개 브랜드가 참여했다. 높은 관심을 반증하듯이 행사가 문을 열기 한 시간 전인 오전 10시부터 전시장에 입장하기 위해 기다리는 관람객들이 대기장을 빼곡히 매운 모습을 볼 수 있었다.
대기장 옆에는 올해 메인 스폰서로 참여하는 네이버의 기술력을 확인할 수 있었다. 네이버페이의 안면 인식 출입·결제 기술 ‘페이스사인’으로 관람객 확인과 체크인 절차를 간소화하면서다.
페이스사인 전용 패스트트랙의 경우 전시 입장하는 시간을 기존 대기 줄 대비 2배 가까이 줄였다. 행사가 열린 이틀간 패스트트랙을 이용해 입장한 관람객의 수는 대략 6000~7000명 수준이다. 네이버페이 앱에서 얼굴을 미리 등록하면 해당 서비스를 이용해 입장 가능하다.
네이버페이 관계자는 “네이버 클라우드에서 직접 만든 엔진을 사용하고 있다. 국내 기업이 만든 기술로 서비스를 하고 있다는 점이 강점”이라며 “얼굴을 인식하면 그 이미지를 벡터값으로 변환해 분산 저장하는 과정을 통해 개인정보를 보호하고 있다”고 답했다.
전시관에 입장하면 가장 먼저 네이버 라운지에 들어서게 된다. 블로그, 지식인, 웹툰 등을 통해 창작자와 이용자 간 소통 지원해온 사례를 살펴볼 수 있었다. 행사 취지에 맞춰 최근 삶의 원천과 기억에 남는 가사 한 줄 등을 직접 손으로 기록해보며 전시를 체험할 수 있다. 행사장 한켠에는 스티커 사진과 같이 네이버 스페셜로고에 자신의 얼굴을 합성할 수 있는 기계도 자리한다.
네이버 라운지 오른편에서는 본격적인 문구 페어가 진행됐다. 민도비또 , 낼나, 글월, 아이코닉, 키노 등의 브랜드가 부스를 꾸렸으며 노트, 펜과 같은 필기구부터 마스킹 테이프, 키캡, 스티커, 에코백, 도장 등의 문구류도 판매하고 있었다.
문구류 마니아들이 모인 만큼 현장 곳곳에서는 “귀엽다”는 탄성이 들려왔다. 행사를 방문한 20대 후반 김 씨는 본인을 경기도에서 왔다고 소개하며 “직장인인데 전시회에 참여하기 위해 오늘 연차를 냈다”며 “지난번 행사보다 부스가 많아지고 다양해져서 좋다”는 소감을 남겼다.
30대 초반 남성 장 씨는 “평소 문구류에 관심이 많아 지인의 소개로 행사를 관람하게 됐다”며 “체험도 해볼 수 있고, 인터넷으로 봤을 때보다 더 잘 꾸며져 있어서 좋다”고 말했다. 이어 “지금까지는 30만원 정도 구매했다. 추가로 구매할 계획”이라며 높은 만족도를 드러냈다.
부스 곳곳에 Npay 커넥트 배치…결제도 취소도 ‘얼굴’로 가능
결제할 때도 네이버의 생태계 전반이 행사에 그대로 녹아든 모습을 볼 수 있었다. 네이버페이의 오프라인 통합 단말기 ‘Npay 커넥트’가 부스에 배치됐기 때문이다.
Npay 커넥트는 현금, 카드, QR, 간편결제와 페이스사인을 통한 인식 결제까지 지원한다. 페이스사인 결제는 지난 5일 젠슨 황의 ‘삼소(삼겹살·소주) 회동’ 당시 동석한 이해진 의장이 사용하며 유명해진 서비스다.
민·관·학 함께하는 '디지털 트러스트' 대국민 캠페인 열린다 2026.04.07 가짜 늑구 사진에 경찰도 속는 AI 시대...허위정보 대응책은 2026.04.28 네이버, 문구페어 '인벤타리오' 후원...온-오프 이색 경험 제공 2026.06.09 네이버페이, 외국인 관광객 결제 편의성 높인다 2025.12.01
상품 바코드를 찍고 결제를 시행하면 단말기에 결제 방식을 선택할 수 있는 칸이 뜬다. 이 때 페이스사인을 선택하면 얼굴 인식 후 2초가량 후 결제가 되며 결제 취소 역시 페이스사인으로 가능하다.
네이버페이 관계자는 “기존 포스 단말기 제조사와 상생하겠다는 생각을 가지고 있다”며 “(판매자는) 이용하고 있던 포스 단말기와 연동해 서비스를 제공하고 있다. 생태계를 해치지 않고 시장에서 같이 성장하겠다는 것이 지향점”이라고 설명했다.
K-문샷 프로젝트 출발부터 삐걱...AI과학자 PD 사의 표명
지난달 27일 오후 서울 용산구 드래곤시티호텔에서 열린 'K-문샷 추진단 출범식' 현장. [자료: 과학기술정보통신부]
[디지털투데이 이진호 기자] K-문샷 프로젝트가 본격적인 시작을 알린 가운데 미션 총괄책임자(PD) 중 한 명이 사의를 표명했다. 과학기술 분야에 인공지능(AI)을 접목해 국가 난제를 해결하겠다는 프로젝트는 시작 단계부터 책임자 이탈이라는 난제를 맞닥뜨리게 됐다.
과학기술정보통신부는 12일 광화문 KT빌딩에서 K-문샷 프로그램 설명회를 열고 사업 추진 현황과 향후 계획을 공유했다.
◆ AI과학자 PD 사의…과기정통부 "후임 공모 없이 간다"
정부는 K-문샷을 통해 2030년까지 과학기술 연구생산성을 2배 높이고, 2035년까지 8대 분야 12대 국가 미션을 해결하는 것이 목표다. 12대 미션은 ▲신약 ▲뇌-컴퓨터 인터페이스(BCI) ▲태양전지 ▲핵융합 ▲소형모듈원자로(SMR) 선박 ▲휴머노이드 ▲피지컬 AI ▲우주 ▲소재 ▲AI과학자 ▲반도체 ▲양자 등이다.
과기정통부에 따르면 이 중 AI과학자 분야 PD를 맡은 이민형 아스테로모프 대표가 최근 사의를 표명했다. 김성수 과기정통부 연구개발실장은 "이민형 대표가 최근 일신상의 사유로 사의를 표명해 왔다"고 말했다. 이 대표의 사표는 배경훈 부총리 겸 과기정통부 장관이 해외 출장에서 돌아온 뒤 수리될 전망이다.
K-문샷 PD 12명은 공모를 통해 지난달 21일 선발됐다. 이 대표는 24세의 젊은 나이와 아스테로모프의 420억원 규모 투자 소식이 알려지면서 업계 이목을 끌었다. 하지만 온라인에서는 이 대표의 학력과 경력을 둘러싼 논란이 확산됐다. 이 대표는 허위 사실에 대한 법적 검토를 예고한 상태다. 과기정통부는 이 대표 후임 PD를 새로 공모하지 않고 국가과학AI연구센터 센터장이 해당 역할을 겸임하는 방식으로 사업을 추진할 예정이다.
K-문샷 프로젝트는 초기부터 PD의 정확한 역할과 권한 범위에 대한 우려가 나왔다. PD에게 과제 기획과 사업 조정, 자원 배분 권한이 부여되는 만큼 통제 장치를 구체화해야 한다는 지적이 제기됐다. 반대로 결재권이 없는 상황에서 PD 의견이 실제 사업 기획과 예산 조정에 얼마나 반영될 수 있겠느냐는 의견도 제시됐다.
과기정통부는 PD가 미션 핵심사업에 대한 로드맵 기획, 과제 구성·기획 조정 등 전반적 권한을 갖는다고 설명했다. 다음달에는 현재 전문위원 신분의 PD들을 국가과학기술연구회(NST) 직속 특임연구원으로 전환한다. 전환 과정에서는 외부위원 중심 특별채용위원회가 서면심사를 진행한다. 공무 수행에 따른 이해충돌방지법 일반 규정을 적용해 영리업무도 제한한다. 연구책임자이거나 이해관계가 있는 사업·과제는 심의할 수 없도록 다음달 중 K-문샷 프로그램 운영·관리 규정을 적용한다.
과기정통부는 PD가 K-문샷 사업 기획과 진도 관리, 조정 권한을 제대로 발휘할 수 있도록 차관급 공무원과 위촉 전문가가 참여하는 추진단과 NST 주도의 추진지원단을 함께 운영한다. PD가 직접 과학기술관계장관회의에 참여해 의견을 개진하는 방안도 검토한다. 또 연차평가와 마일스톤 평가를 통해 PD 책임운영체계를 확림한다는 방침이다.
키워드 #과학기술정보통신부 #K-문샷 #AI #이민형 #PD
이 시각 추천뉴스 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러?
日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상
IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시
마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에
클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담
XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입
AI 시대, 취향(Taste) 경제의 부상 (thevccorner.com)
AI가 코드의 상당 부분을 자동 생성하면서 소프트웨어가 무한·저렴 해진 시대에, 살아남는 차별화 요소는 취향(Taste) 과 디자인으로 이동 중 Microsoft는 신규 코드의 20~30%, Coinbase는 코드베이스의 40%가 AI 생성이며, Lovable은 1분 안에 작동하는 앱 생성 가능 속도·자본·유통 같은 기존 차별점이 무력화되면서, 반복 가능한 고신뢰 판단력 으로서의 취향이 마지막 우위로 부상 디자인은 사용자가 무엇·누구를 신뢰할지 결정하는 신뢰 인프라 이자, 복제 불가능한 미학적 해자(Aesthetic Moat) 로 기능 창작이 흔해진 시대에 가치는 생산이 아닌 편집·큐레이션 에서 나오며, 승자는 빠른 빌더가 아니라 잘 선택하는 팀 희소성의 붕괴 - 소프트웨어가 저렴해질 때 모델 성능 수렴, 광범위한 API, 턴키형 클라우드로 인해 팀을 구분하던 기술적 우위가 평준화 중 프런티어 랩 내부에서도 엔지니어가 코드 작성에서 AI 오케스트레이션 으로 이동 Anthropic은 개발자가 여러 자율 에이전트를 관리하는 형태를 설명, 내부 코드 기여 다수를 AI가 담당하고 온보딩 기간이 수 주에서 수 일로 단축 모두가 같은 제트엔진을 가지면 속도는 더 이상 해자가 아님 Rex Woodbury는 대량 생산·바이브 코딩 앱이 수 초 만에 만들어지는 현상을 "소프트웨어의 코스트코 시대" 로 명명 Lovable처럼 프롬프트 한 줄로 1분 내 앱 생성이 가능해지며 생산 자체가 상품화 , 창작이 싸고 즉각적일수록 동등화가 빠르게 도달 AI Slop의 그림자 저노력·자동 생성 결과물인 AI slop 이 피드와 검색 결과를 뒤덮으며 실제 분석·뉴스·진정성 있는 콘텐츠를 가림 Reuters Institute는 이런 복붙형 AI 텍스트·이미지가 인터넷을 조용히 잠식하며 정보 생태계 신뢰를 위협한다고 경고 무한 AI 산출물 속에서는 진짜 craft와 구조로 만든 신호만 부상, GEO·AEO 최적화 가 생존 기술로 부상 사내 Workslop 그럴듯해 보이지만 속이 빈 AI 메모·보고서·이메일인 workslop 이 사내 시간과 신뢰를 소모 Axios가 요약한 연구에 따르면 사무직 약 40%가 최근 한 달간 workslop을 경험, 한 건당 약 2시간 의 재작업과 생산성 손실 비용 발생 동료들은 습관적 slop 발신자를 능력·신뢰성이 낮다고 평가 가치의 중심이 이동하며, 이제 희소한 것은 인식(perception)·일관성·배려 , 한 단어로는 디자인 , 그 뒤의 진짜 해자는 취향 취향의 정의 — 창업자의 숨은 초능력 스타트업에서 취향은 버튼 색·랜딩 레이아웃·로고 분위기 같은 미학으로 오해되지만, 실제 취향은 데이터가 없을 때 무엇이 옳고 본질적인지 아는 더 깊은 감각 취향은 불확실성 속에서 반복 가능한 고신뢰 판단력 , 남들이 패턴을 보기 전에 품질과 적합성에 대해 일관되게 고신호 결정을 내리는 능력 선호에서 정밀함으로 Paul Graham은 2002년 디자인 에세이와 2021년 Good Taste 에서 취향이 주관적 변덕이 아니라 진보의 근간 이라 주장 취향이 단순 개인 선호라면 개선 자체가 불가능, Graham은 취향을 노출·반복·사용자 공감으로 훈련하는 craft 로 봄 디자인은 작동 방식 + 느낌이며, 취향은 그 둘이 정렬되는 순간을 알려주는 판단 실제 취향의 패턴 Apple은 잘 팔릴 기능조차 거절하며 일관성(coherence) 을 보호 Airbnb는 영수증 폰트·오류 메시지 톤까지 집착, 일관성이 신뢰를 만든다는 믿음 기반 Figma는 모든 애니메이션·아이콘·툴팁이 의도적으로 느껴지도록 즐거움을 소프트웨어로 번역 이들을 묶는 공통점은 공감(empathy) , 제품이 피치덱이 아니라 사용자 손안에서 어떻게 느껴지는지를 상상 운영 전략으로서의 취향 영리한 창업자는 취향을 판단을 확장하는 비즈니스 스킬로 인식 팀 전원이 '좋음'의 감각을 공유하면 실행이 가속되고 회의·논쟁이 단축, 내부 나침반이 보정되어 검증용 데이터 추격을 멈춤 궁극적으로 취향은 잘못된 것을 아름답게 만드는 일을 막아줌 신뢰 인프라로서의 디자인 누구나 하룻밤에 제품을 만드는 시대에 디자인은 실질적 신뢰 신호 , 사용성·시각적 완성도를 넘어 사용자가 무엇·누구를 신뢰할지 결정하는 기준 모든 사이트가 지능을, 모든 인터페이스가 공감을 약속할 때 사람들은 배려의 증거(proof of care) 를 찾음, 버튼 라벨의 명료성·로딩 메시지의 정직함·불확실성 인정 방식 같은 작은 것에서 감지 기능에서 신뢰성으로 전통적 디자인은 마찰 없는 경험을 최적화했으나, 이제는 무결성(integrity) 을 최적화해야 함 새 관건은 "작동하는가"가 아니라 "신뢰할 수 있는가", 특히 불투명성과 환각 위험이 상존하는 AI 도구에서 핵심 최고의 팀은 anti-slop 디자인을 실천 명료성(Clarity) — 시스템이 무엇을 하는지 정확히 말함 투명성(Transparency) — 출력의 출처를 보여줌 되돌림(Reversibility) — 취소·검증할 제어권 제공 근거 제시(Sourcing) — 결정 뒤의 증거·근거를 연결 이런 패턴은 UX 개선을 넘어 심리적 안전감 을 형성, 스스로 설명하는 제품은 믿음을 얻고 추론을 숨기는 제품은 의심을 부름 사례 — Epic vs. Abridge Epic Systems 는 업계 지배적 소프트웨어 공급자지만 어수선하고 혼란스러운 인터페이스로 악명, AI 의료 스크라이브 출시 시 비대한 양식·중첩 메뉴 스크린샷이 조롱받으며 의사에 대한 공감 제로 를 드러냄 2018년 설립된 훨씬 작은 스타트업 Abridge 는 같은 AI 스크라이브를 명료함과 따뜻함으로 설계, 인터페이스가 인간적·직관적·미니멀하여 의사들이 "아름답다", "신뢰하기 쉽다"고 평가 Epic의 규모 우위에도 Abridge가 병원 전반에서 지지를 얻는 이유는 사용자의 주의를 존중하는 디자인, 좋은 디자인은 역량을 신뢰성으로 번역 사용자와 제품 사이의 새 계약 AI가 자율화될수록 사용자는 기술 성능을 넘어선 단서로 누구를 믿을지 판단 투명한 인터페이스·해석 가능한 출력·정직한 톤으로 추론을 보여주는 제품은 거래가 아닌 관계를 구축 신뢰는 더 이상 평판만으로 얻어지지 않고 인터페이스에 내장 , 디자인은 인간과 기계 사이의 악수이자 믿음의 건축 미학적 해자 — 느낌이 기능이 될 때 대부분 시장에서 가격 모델·기술 스택·온보딩 흐름은 수 주 내 복제되지만, 복제 불가능한 것은 느낌(feel) , 일관성·절제·배려로 쌓이는 정서적 공명 이 정서적 방어층이 코드로 역설계되지 않는 미학적 해자(Aesthetic Moat) 느낌의 힘 Arc Browser는 차분하고 지적인 느낌으로 몰입을 위해 설계, Notion은 가볍고 촉각적이며 명상적으로 일을 craft로 전환 이런 감각은 우연이 아니라 하나의 정서적 진실 로 정렬된 수천 개 미세 결정의 결과 사용자가 "아름답다"고 할 때 의미는 색상이 아니라 내적 일관성 , 모든 디테일이 같은 가치를 전달, 이 일관성이 디자인을 장식에서 방어력으로 전환 문화가 복리가 될 때 Apple·Tesla·Dyson 은 이 복리 효과의 원형 Apple의 미학적 해자는 수십 년 깊이, 타이포그래피·제스처·소재가 모두 인간적인 기술 이라는 하나의 아이디어를 표현 Tesla는 엔지니어링 성능을 정서적 열망 으로 전환, 전기차를 기능이 아니라 미래에 대한 기대로 욕망하게 만듦 Dyson은 메커니즘·정밀·물리를 노출해 기능 자체를 아름답게, 내부 논리가 디자인 언어가 됨 모든 경우 느낌이 브랜드 중력의 일부가 되며, 경쟁자는 기능은 모방해도 사용자가 신뢰를 학습한 정서적 시그니처는 복제 불가 복제될 수 없는 이유 코드는 복제·가격은 인하 가능하나 취향은 상품화 불가 , 로딩 스피너부터 고객지원 톤까지 정서적 일관성에 대한 창업자의 신념으로 배양 모든 사용자 접점이 같은 정서적 진실을 강화할 때 미학적 해자가 형성, AI가 만든 클론의 세상에서 그 영혼만이 희소하게 남음 취향 경제의 부상 디지털 시대 첫 물결은 창작 을 보상해 더 많이·빠르게·싸게 출시한 자가 승리했으나, 누구나 코드·콘텐츠·디자인을 즉시 생성하면서 창작은 희소성 프리미엄을 상실 이제 희소한 스킬은 큐레이션 , 무엇을 남기고 자르고 무시할지 아는 능력, 우리는 창작 경제를 떠나 산출이 아닌 편집에서 가치가 나오는 취향 경제 로 진입 중 생성기보다 필터 모든 것을 만들 수 있을 때 필터가 생성기를 능가 , 더 많은 이미지·제품·스타트업이 아니라 무엇이 주목할 가치가 있는지 정하는 더 날카로운 필터가 필요 필터가 생성기를 이김 — 사람들은 쏟아내는 자가 아니라 다듬는 자를 신뢰 큐레이터가 창작자를 이김 — 의미를 선택하는 인간이 양을 생산하는 기계를 이김 편집자가 엔지니어를 이김 — 기술은 생산을 자동화해도 판단은 대체 못 함 AI는 이 시대의 인쇄기로 제작을 민주화했으나, 인쇄기가 위대한 문학과 싸구려 팸플릿을 모두 낳았듯 오늘의 풍요는 취향을 가치의 결정자 로 만듦 공장이 아닌 편집 스튜디오로서의 스타트업 차세대 위대한 스타트업은 생산 라인이 아니라 편집 스튜디오 형태, 더 적고 더 나은 것을 만드는 작고 절제된 팀 경쟁 우위는 가치와 일관된 것만 출시하는 절제(restraint) , 제품 로드맵을 공장 일정이 아닌 편집 캘린더처럼 다룸 소비자의 변화 동질화의 홍수 속에서 사람들은 제품에서 의미·정체성·일관성 을 추구, 기능이 아니라 정렬, 즉 제품이 세상을 자신과 같은 방식으로 본다는 감각을 구매 투자자의 렌즈 투자자는 "제품 전체를 보는" 창업자, 미학적·전략적 결정을 같은 명료함으로 내리는 창업자를 거론하며 판단을 제도화 하는 이들을 인식 기술적 해자가 하룻밤에 증발하는 시끄러운 AI 시장에서 이런 분별력이 가장 희소한 방어력 풍요의 시대 속 신념 AI는 창작의 운동장을 평준화하지만 신념의 격차는 벌림 , 취향이 개인 기벽이 아니라 공유된 규율인 회사가 신뢰·애정·리텐션을 배가 취향은 본질적으로 복리 자산 , 적용할수록 강해지고 복제하기 어려워짐 편집자로서의 창업자 — 절제로 이끌기 모든 스타트업은 무한한 가능성의 장에서 시작, 어려운 부분은 무엇을 만들지가 아니라 무엇을 만들지 않을지 정하는 것, 핵심은 더하기가 아닌 빼기 최고의 창업자는 빌더보다 편집자 처럼 행동, 본질만 남을 때까지 다듬고 가지치기 브랜드 철학으로서의 거절 Apple 은 무한한 선택이 아니라 의도적 부재로 명성 구축, 하나의 폰·하나의 포트·하나의 깔끔한 결정 Basecamp 는 작은 팀이 우아하게 관리할 수 있는 범위를 넘어선 기능 확장을 거부, 제약을 정체성으로 전환 Abridge 는 기능 수가 아니라 의사 워크플로를 어지럽히지 않으려는 거절로 입지 확보 각 사례에서 거절은 행동하는 취향, 모든 "아니오"가 남은 "예"를 더 강하게 만듦 문화를 통한 판단의 확장 취향은 위임 불가하나 성문화(codify) 가능, 취향을 확장하는 창업자는 그것을 습관으로 전환 기능만이 아니라 느낌 을 검토하는 리뷰를 설계, 채용은 이력서 키워드가 아니라 공감 을 선별, 영리함보다 명료함을 보상하는 의례 채택 이 가치들이 반사 신경이 되면 팀이 본능적으로 편집, 체크리스트가 아닌 공유된 의미 형성 으로 취향이 확장 미세관리가 아닌 정렬 디자인 주도 리더십은 통제로 오해되나 실은 그 반대, 명료함과 가치를 통한 정렬 모두가 '좋음'의 느낌을 이해하면 감독이 불필요, 같은 내부 나침반에 인도되어 팀이 더 빠르게 움직임 엔지니어부터 마케터까지 같은 정서적 진실로 편집해 일관된 제품을 출시, 이 일관성이 지표로 다 담을 수 없는 브랜드 사랑 으로 복리화 속도 대신 신뢰를 위한 디자인 지난 10년은 속도를 찬양했으나("빠르게 움직여 부수고, 나머지는 자동화"), AI 포화 세계에서 무결성 없는 속도는 역효과 발생, 다음 경쟁 지표는 출시 시간이 아니라 신뢰까지의 시간(time-to-trust) 너무 빠름의 대가 AI 도구가 자동 생성 노이즈로 웹을 채우며 디지털 콘텐츠 신뢰가 붕괴 중 저노력 AI slop은 뉴스·커머스·검색 전반의 신뢰를 약화하고 무엇이 진짜인지에 대한 기본 확신을 침식 같은 패턴이 사내에서 반복되어 동료들이 짜증·불신·이탈 감정을 느낌, 생산성 추구가 곧 불신을 양산 끝없는 기능 출시·자동 생성 마케팅·AI로 다 쓰는 식으로 산출 속도를 최적화한 스타트업은 아무도 인간이 만든 것이라 믿지 않으면 많음이 낫지 않음 을 발견 느린 제품의 우위 신뢰는 사용자가 기꺼이 기다리는 사치가 되는 중 속도를 늦춰 스스로 설명하고 추론을 노출하며 유창함을 흉내 내는 대신 믿음을 얻는 제품이, 마찰 없으나 속 빈 경쟁자를 능가 출처를 인용하는 약간 느린 AI 어시스턴트가 즉답하지만 불투명한 것보다 더 큰 확신을 줌, 의도된 것이 자동화된 것을 이김 신뢰를 위한 디자인 원칙 완성도보다 투명성 — 마법의 환상을 깨뜨려도 시스템 작동 방식을 보여줌 결정은 줄이고 어포던스는 명확하게 — 사용자가 속았다고 느끼지 않도록 직관적으로 자동화보다 진정성 — 인간의 목소리를 유지, 공감·겸손·불완전함을 드러냄 다음 해자는 의미(Meaning) 이제 관건은 무엇이 가능한가 가 아니라 무엇이 만들 가치가 있는가 임 기술은 창작 장벽을 지웠으나 배려의 필요는 지우지 못함, 모든 제품을 기계가 만들 수 있을 때 진짜 차별화는 그 뒤의 인간성 차세대 지속 가능한 스타트업은 모든 것을 자동화한 곳이 아니라 무엇을 세상에 내놓을지 깊이 배려(care deeply) 하는 곳 신뢰를 위해 디자인 하고 절제로 편집 하며 지표엔 안 보여도 사용자엔 명백한 기준을 지키는 팀 AI는 산출을 배가할 수 있어도 판단은 배가하지 못함 이는 인간의 영역으로 남으며 취향은 누군가 무엇이 존재할 가치가 있는지 결정하는 데 시간을 들였다는 신념의 궁극적 신호가 됨 결국 승자는 가장 빠른 빌더나 가장 시끄러운 마케터가 아니라 현명한 선택을 하는 사람들 디자인을 약속으로 여기고, 취향을 하나의 규율로 다루는 사람들일 것 무한 창작의 세상 에서 가장 희소한 스킬은 분별력 이며 가장 희소한 제품은 영혼이 담긴 것
함께 보면 좋은 글 β 취향(taste)을 갖춘 30배 AI 엔지니어가 되는 법 취향(Taste)이 새로운 10x다 AI 시대, 가장 가치 있는 개발자는 장인이면서 빌더인 사람이 될 것 AI 시대, TypeScript의 부상: 수석 설계자 Anders Hejlsberg의 통찰 우리의 장인 정신을 애도합니다
취향(taste)을 갖춘 30배 AI 엔지니어가 되는 법
AI 시대, 가장 가치 있는 개발자는 장인이면서 빌더인 사람이 될 것
AI 시대, TypeScript의 부상: 수석 설계자 Anders Hejlsberg의 통찰
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요. Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
GeekNews는 개발·기술·스타트업 소식을 빠르게 전달합니다. Weekly 뉴스레터로 구독하거나, 더 편하게 GeekBots로 받아보세요.
Weekly 구독 GeekBots로 받기 GeekNews 소개 숨기기
인증 이메일 클릭후 다시 체크박스를 눌러주세요
발행일: 2026-06-13 06:22 (토)
한국어 KR 영어 EN 일본어 JP 중국어 CH
어도비가 문서 업무와 콘텐츠 제작 기능을 한곳에 묶은 인공지능(AI) 생산성 서비스를 국내에 선보였다.
어도비는 애크로뱃과 어도비 익스프레스, AI 에이전트를 통합한 '애크로뱃 스튜디오'를 한국에 정식 출시했다고 12일 밝혔다.
애크로뱃 스튜디오는 PDF를 대화형 지식 허브로 바꾸는 서비스다. 사용자는 맞춤 설정 가능한 AI 어시스턴트를 통해 문서에서 인사이트와 답변, 추천 사항을 얻고 이를 다른 사용자와 공유할 수 있다.
이 서비스는 어도비 익스프레스 제작 도구와 템플릿도 함께 제공한다. 사용자는 어도비 파이어플라이 기반 이미지·영상 생성 기능을 활용해 PDF에서 얻은 정보를 콘텐츠로 만들 수 있다.
서비스 핵심 기능은 'PDF 스페이스'다. PDF 스페이스는 파일·웹사이트 모음을 한데 통합해 대화형 지식 허브로 전환할 수 있다.
사용자는 PDF 스페이스에서 에이전틱 AI 어시스턴트를 활용해 파일과 상호 작용할 수 있다. 답변은 정확한 출처 인용을 통해 검증할 수 있으며, 메모를 추가해 나중에 다시 확인할 수 있다.
해당 서비스는 팀 협업 기능도 제공한다. 사용자는 PDF 스페이스를 공유해 팀원이 같은 지식 허브에서 인사이트를 얻고 협업하도록 도울 수 있다. 발신자는 관련 맥락을 추가하고 파일 순서를 중요도에 따라 조정할 수 있다.
PDF 스페이스의 AI 어시스턴트는 정보를 종합하고 질문에 답하며 추가 탐색 영역을 제안한다. 사용자는 프로젝트 요구 사항에 맞춰 AI 어시스턴트 역할을 지정하거나 새 역할을 부여할 수 있다.
애크로뱃 스튜디오는 문서를 프레젠테이션으로 바꾸는 기능도 지원한다. 예를 들어 세일즈 전문가는 여러 PDF와 프레젠테이션 자료, 웹페이지에서 핵심 정보를 추출해 편집 가능한 개요와 프레젠테이션을 만들 수 있다.
기존 애크로뱃 프로 기능도 포함됐다. 사용자는 PDF 편집과 파일 병합, 종이 문서 스캔, 계약서 전자서명, 민감 정보 가리기, 문서 비교 및 보호 기능을 한곳에서 사용할 수 있다.
어도비, '젠스튜디오' 업데이트…AI로 콘텐츠 제작 환경 개선 2026.06.05 '사스포칼립스'에 흔들린 어도비, CEO 이어 CFO도 떠난다 2026.06.12 [AI는 지금] '사스포칼립스' 덮친 세일즈포스·서비스나우·어도비, 주가 급락 속 칼바람 2026.06.12 어도비, 아시아 총괄 부사장에 '25년 베테랑' 임명 2026.05.27
어도비는 2026 회계연도 2분기 실적에서 매출 66억2천만 달러와 조정 주당순이익 5.96달러를 기록하며 시장 예상치를 웃돌았다. 파이어플라이와 애크로뱃 AI, 익스프레스 등 AI 제품 수요가 실적을 견인했고, AI 중심 연간 반복 매출은 5억 달러를 넘어섰다. 다만 최고재무책임자(CFO) 이탈을 비롯한 경영진 교체 우려가 겹치며 실적 발표 이후 주가는 하락했다.
길 루리아 D.A. 데이비슨 애널리스트는 "현재 투자자들은 경영진 교체에 불안감을 느낄 것"이라고 한 매체 인터뷰에서 밝혔다.
대만, 결국 中 전체 겨누나…AI칩 수출 전면 통제 검토 '초강수'
대만이 화웨이·SMIC를 넘어 중국 모든 고객에 대한 AI칩 판매 제한을 검토하고 있다. AI 서버 밀수를 형사처벌하는 방안도 함께 논의되고 있다.
이번 논의의 핵심은 특정 기업 제재를 넘어 중국향 AI칩과 AI 서버 유통 전반을 관리하는 체계로 규제가 확장될 수 있다는 점이다 [사진: 셔터스톡]
[디지털투데이 홍진주 기자] 대만이 중국의 모든 고객을 대상으로 인공지능(AI) 칩 수출 제한을 확대하는 방안을 검토하고 있다.
10일(현지시간) 온라인 매체 기가진에 따르면, 이번 검토안에는 화웨이와 SMIC처럼 이미 블랙리스트에 오른 기업뿐 아니라 중국 전반에 대한 판매 통제와 AI서버 밀수의 형사처벌이 포함될 가능성이 있다.
핵심은 대만이 미국의 대중 수출통제 기준에 어느 수준까지 보조를 맞출지다. 현재 대만은 중국으로의 무허가 AI칩 수출 자체를 범죄로 규정하지 않고 있다. 이 때문에 당국은 판매업체에 미국 규정을 위반할 수 있다고 경고할 수는 있지만, 실제 수사와 기소 단계에서는 문서 위조 같은 기존 법률에 의존해 왔다.
이런 공백은 최근 엔비디아 칩이 탑재된 AI서버의 우회 수출 의혹과 맞물려 부각됐다. 2026년 5월에는 엔비디아 탑재 서버 약 50대를 둘러싼 밀수 의혹으로 3명이 붙잡혔지만, 적용된 혐의는 수출통제 위반이 아니라 문서 위조였다. 새 규제가 도입되면 칩뿐 아니라 완성된 AI서버의 이동까지 직접 단속하는 체계가 마련될 수 있다.
대만은 2025년 6월 화웨이와 SMIC를 블랙리스트에 추가해 자국 기업이 두 회사와 거래하려면 정부 허가를 받도록 했다. 다만 이 규제는 특정 기업에 한정돼 있어, 그 외 중국 고객에게 AI칩이나 서버가 흘러 들어갈 여지는 남아 있었다. 대만이 미국처럼 일정 수준 이상의 처리 성능을 기준으로 통제 대상을 정하면 어떤 등급의 AI서버가 중국 본토로 출하될 수 없는지 기준선도 더 분명해진다.
대만 경제부는 '전략적 하이테크 제품'에 대한 감독을 강화하고 국제 수출통제와의 정합성을 높이겠다고 밝혔다. 또 선단 칩을 규제 대상에 포함하는 문제를 놓고 미국과 협의를 이어가고 있다고 했다. 최종안은 대만과 미국 고위 당국자 간 확인을 거쳐 정해질 전망이다.
이 사안이 주목받는 이유는 대만이 AI서버 공급망의 핵심 거점이기 때문이다. 폭스콘은 전 세계 AI서버 시장의 약 40%를 차지하는 것으로 거론되며, 콴타 컴퓨터와 위스트론, 위윈, 인벤텍 등도 엔비디아와 AMD 가속기를 탑재한 랙 단위 AI서버를 세계 데이터센터에 공급하고 있다. TSMC의 대중 선단 칩 생산이 이미 제한돼 있어도 대만에서 조립된 서버가 사후적으로 중국으로 유입되면 규제의 빈틈이 될 수 있다는 우려가 나오는 배경이다.
다만 대만 내부에서는 규제 강화의 부담도 함께 거론된다. 반도체는 대만 경제와 안보를 동시에 떠받치는 산업이기 때문이다. 린자룽 외교부장은 과거 반도체를 '무기화하고 싶지 않다'는 취지로 말한 바 있다. 대중 규제가 과도해질 경우 자국 산업에도 부담이 될 수 있다는 신중론이 깔려 있다.
미국 정치권의 압박도 커지고 있다. 짐 뱅크스 상원의원과 앤디 김 상원의원은 TSMC 같은 파운드리가 중국 기업의 해외 자회사를 통해 선단 AI칩을 생산하는 우회 경로를 막아야 한다고 요구했다. 미국 상무부 산업안보국(BIS)은 중국 기업의 말레이시아 등 제3국 자회사에 대한 판매에는 허가가 필요하다는 점을 분명히 했지만, 전문가들은 중국 기업의 프런트 기업이 맞춤형 칩을 발주하는 경로까지 충분히 차단됐는지는 의문이라고 보고 있다.
대중 수출을 둘러싼 논쟁은 엔비디아로도 번졌다. 엘리자베스 워런 상원의원은 젠슨 황 엔비디아 최고경영자(CEO)에게 중국 판매와 수출통제 준수 문제를 상원 은행위원회에서 증언하라고 요구했다. 황 CEO는 공개 증언 대신 워런 의원과 위원회 인사들을 엔비디아 본사로 초청해 회사 기술과 미국 AI 생태계를 설명하겠다고 제안했다. 그는 그동안 대중 판매를 제한해도 중국의 AI 개발을 늦추는 효과는 작고 미국 기업의 경쟁력만 약화할 수 있다고 주장해 왔다.
중국은 미국산 AI칩 의존도를 낮추는 방향으로 대응하고 있다. 중국은 향후 5년간 약 2950억달러를 투입해 전국 단위 AI 데이터센터 네트워크 구축을 검토 중인 것으로 전해졌다. 국가발전개혁위원회가 중심이 된 이 구상은 2028년까지 분산된 계산 시설을 연결하고, 핵심 기술의 최소 80%를 화웨이 등 자국 공급업체에서 조달하는 내용을 담고 있다.
이에 따라 대만이 중국의 모든 고객을 겨냥한 AI칩 규제까지 도입할 경우, 반도체와 AI 인프라 공급망의 분리는 더 뚜렷해질 가능성이 있다. 대만의 최종 선택은 중국향 선단 칩과 AI서버의 이동 경로뿐 아니라 미중을 축으로 재편되는 AI 인프라 구조에도 영향을 줄 전망이다.
키워드 #대만 #AI #인공지능 #화웨이 #반도체 #AI칩 #중국
이 시각 추천뉴스 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입 10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동
10개월 잠잠하던 시바이누 고래, 4000억 SHIB 이동 비트코인, 2020년 이후 역대급 과매도 신호…다음 목표가 7만달러? 日 최대 거래 플랫폼 메르카리, 시바이누·도지코인 지원…이용자 2300만명 대상 IBK기업은행, 마이데이터 기반 부동산 청약 서비스 출시 마스터카드 AI 결제망에 리플 합류…XRP 빠지고 RLUSD 전면에 클래리티법 통과 가능성 75%→60%…상원 일정·스테이블코인 쟁점 부담 XRP 상위 보유자 문턱 낮아졌다…2155개 보유하면 진입