오늘 근무하면서 혼났다. 여기서 생존에 유리한 진화 경험을 한거 같아 적어본다. 오늘 왜 혼났냐면 신입사원에게 내가 뭘 잘못 가르쳤기 때문이다. 이 때문에 따로 불려가서 1대1로 혼났다. 내용은 다음과 같다. "너가 알고있는건 잘못되었고 이게 맞는거다. 잘못된걸 가르치다. 그 신입사원이 다른 신입에게 잘못된걸 가르칠 수 있기에 다음부턴 이렇게 가르쳐라." 대충 이런 말을 내게 했다. 지금까지 그 사람에게 혼난걸 생각하면 혼난 것도 아니였다. 오히려 다음부터는 잘 할거라는 믿음(?)이 있었기에 쉬쉬하며 넘어가 주었다. 마무리 내가 잘못했고, 적당히 맞는 말만 해주셨고, 적당히 넘어가주었다. 그런데 왜 나는 1대1로 대화할때 울컥하고 눈물이 나려고 했던걸까. 이는 악어의 눈물이 아니였을까? 위기 상황을 눈물로 동정심을 유발하고 빠져나갈려는 인류 진화의 산물이 아니였을까 싶다.
모델을 바꾸거나 추론을 여러 보드에 나누거나 개발 환경을 분리할 때, 먼저 결정할 질문은 같다. 지금 바꾸려는 대상에 맞춰 무엇을 검증할 것인가? 토큰 사용량, 장치의 메모리, 노드 간 전송, 호스트와의 연결은 각각 다른 근거를 요구한다. Google DeepMind가 2026년 7월 21일 발표로 표시한 Gemini 3.6 Flash·3.5 Flash-Lite·3.5 Flash Cyber 소개 , ESP32S3 추론 클러스터, Linux 개발 환경 도구 NSL을 이 질문에 맞춰 읽어 보자. 모델 제품군의 목표, 소형 보드의 실행 구성, 개발 환경의 설계를 같은 성능 순위에 놓을 수는 없다. 모델 교체를 검토한다면 업무 결과와 대기 시간을 함께 본다 Google은 운영 환경에서 AI 에이전트를 개발하는 고객과 개발자의 요구로 토큰 효율 개선, 지연 시간 단축, 안정적인 성능을 제시한다. 소개된 발표 내용에는 모델별 가격, 벤치마크 결과, 지연 시간 측정값이 나오지 않는다. 따라서 Flash-Lite라는 이름으로 비용 절감 폭을 계산하거나 Flash Cyber라는 이름에서 구체적인 보안 기능을 추정할 근거는 부족하다. 모델 교체를 검토하는 경우, 이 글의 제안은 자체 업무의 결과 적합성에 응답 시간과 재시도 발생 여부를 붙여 평가하는 것이다. 결과가 업무에 맞아야 교체할 이유가 생기고, 응답 시간과 재시도 기록이 있어야 발표에서 강조한 대기 시간과 안정성을 서비스 요구에 대조할 수 있기 때문이다. 토큰 효율이라는 목표 역시 가격 정보와 업무별 사용량 없이 곧바로 비용 절감액으로 옮기지 않는다. ESP32S3에서는 연산 경로와 데이터 형식을 구분한다 GeekNews의 ESP32S3 기반 1.58비트 BitNet 언어 모델 클러스터 소개 에는 0.5B 모델을 마스터 보드 1대와 연산 노드 6대에 분할한 구성이 나온다. 마스터는 토큰화와 임베딩을 맡고, 연산 노드는 각각 트랜스포머 블록 4개를 실행한다. 전체 24개 블록의 처리는 순차적으로 진행된다. 다음은 소개된 구성에서 다음 토큰을 선택하기까지의 처리 순서다. 마스터: 토큰화·임베딩 → 연산 노드 6대: 노드마다 트랜스포머 블록 4개를 순차 실행 → 마스터: 최종 RMSNorm·LM Head → 탐욕적 샘플링으로 다음 토큰 선택 노드 사이의 은닉 상태는 고속 SPI 데이지 체인을 통해 이동한다. 이때 모델 이름에 붙은 ‘1.58비트’를 저장과 전송 전반의 형식으로 받아들이면 실제 메모리 구성을 놓친다. 적용 대상 소개된 형식 또는 저장 위치 어텐션과 MLP의 투영 연산 1.58비트 연산 임베딩 INT4 마스터가 첫 연산 노드로 보내는 은닉 상태 FP32 KV 캐시 PSRAM 임베딩은 플래시에서 약 14MB를 사용하며, LM Head와 가중치를 공유한다. 이 구성을 제한된 메모리의 추론 후보로 검토한다면, 실행 시간의 검토 항목에 노드별 계산 시간, 은닉 상태 전송 시간, KV 캐시 접근 시간을 넣는 것이 이 글의 제안이다. 블록을 순서대로 실행하는 동안 계산뿐 아니라 전달과 메모리 접근도 일어나기 때문이다. 소개된 내용에는 초당 생성 토큰 수와 소비 전력 측정값이 없으므로, 속도나 경제성을 선택 기준으로 삼으려면 해당 측정이 추가로 필요하다. 보드에 올리기 전의 모델 준비도 검토 대상이다 이 프로젝트는 ESP-IDF 펌웨어와 함께 PC에서 사용하는 전처리 도구도 제공한다고 소개되어 있다. 준비 작업에는 어휘를 32K 토큰으로 축소하는 도구, BitNet 양자화 인지 학습 미세 조정, INT4 임베딩 가중치 패킹, 토크나이저 규칙의 바이너리 직렬화가 포함된다. 가중치의 형식과 물리적 정렬을 맞추는 작업도 여기에 속한다. 펌웨어 쪽에는 어셈블리로 최적화한 연산, 조회 테이블 활용, SPI DMA 송수신 구현이 등장한다. 소형 보드에서의 실행을 검토할 때는 펌웨어와 함께 모델 변환 및 배치 작업도 개발 범위에 넣어야 한다. 장치에서 실행되는 코드 외에 준비할 도구와 데이터 형식이 있기 때문이다. 어휘 축소와 양자화 이후의 생성 품질은 소개된 내용만으로 판단하기 어렵다. 이 구성을 실제 업무에 적용하려는 경우에는 변환된 모델의 결과 적합성을 검토 항목에 포함할 만하다. 보드에 배치하는 데 필요한 준비와 업무에 사용할 결과를 얻는 조건을 함께 평가하기 위해서다. NSL에서는 필요한 호스트 연결을 먼저 정한다 GeekNews의 NSL Linux 개발 환경 소개 에 따르면, NSL은 공유 VM 내부의 systemd-nspawn 컨테이너에서 각 Linux 머신을 실행한다. 설치한 패키지와 서비스, 파일은 세션 종료 후에도 남는다. 개발 도구를 호스트와 분리해 설치하면서 작업 공간을 이어 쓰는 방식이다. 일반 환경은 호스트와의 연결을 제공한다. 프로젝트 디렉터리에서 시작하면 같은 파일을 사용하고, 사용자 이름과 UID·GID를 호스트에 맞춰 파일 소유권을 유지한다. 개발 서버는 포워딩된 포트로 접근하며, Wayland 앱의 창은 Waypipe를 통해 호스트 데스크톱에 표시한다. 신뢰하지 않는 소프트웨어를 대상으로 하는 --isolated 모드는 전용 VM에서 실행하며, 설명상 호스트 파일·데스크톱·호스트 동작에 대한 접근을 차단한다. 구성 VM 사용 방식 호스트 연결 일반 환경 공유 VM 안의 컨테이너 프로젝트 파일 공유와 데스크톱 연동 제공 --isolated 모드 전용 VM 호스트 파일·데스크톱·호스트 동작 접근 차단 NSL을 검토할 때 이 글의 제안은 작업에 필요한 호스트 연결부터 적는 것이다. 같은 프로젝트 파일을 편집하거나 호스트에 앱 창을 띄워야 하는 작업이라면 그 연결이 개발 편의의 일부다. 신뢰하지 않는 소프트웨어를 실행하려는 경우에는 --isolated 가 설명하는 접근 차단 범위를 기준으로 검토한다. 소개된 v0.4.0은 현재 설계의 첫 릴리스이며, 당시에는 안정 버전이 없는 상태다. NSL 자체는 호스트에 패키지를 설치하지 않지만 필수 구성 요소는 미리 갖춰야 한다. 도입 작업을 잡을 때는 이 사전 준비와 개발 환경 내부의 도구 설치를 구별해 범위에 반영한다. 다음 검증을 고르는 기준 이 글의 제안은 ‘효율적’이라는 표현보다, 바꾸려는 대상에서 아직 답하지 못한 검증 항목을 우선하는 것이다. 그 답이 도입 결정을 바꿀 때 다음 실험이나 환경 구성을 진행할 이유가 생긴다. 원문: webi 기술 블로그 참고한 자료: Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber 1.58비트(BitNet) 언어 모델을 실행하는 ESP32S3 클러스터 Show HN: NSL - Linux용 WSL
서론(넘겨도 됨) it 분야를 포기하고 반도체로 노선을 바꾸고 다행히도 취업에 성공했다. 반도체 공장이다 보니 3교대 근무로 인해 심신의 여유가 없어 기숙사>회사>기숙사>회사>기숙사>회사 이런 생활을 하다 슬슬 익숙해지고 퇴사하고 다른 것도 할 여유가 생겨 지금까지 회사 다니면서 깨달은 삶의 지해를 공유하기 위해 글을 적어본다. 내가 깨달은 것을 알기 위해선 일단 내가 뭘 하는지를 알아야한다. 대충 내가 하는 일을 요약하면 1)전 공정에서 넘어온 자재를 준비 2)내 공정의 장비에 넣기 3)장비에서 나온 자재 정리해서 다음 공정으로 넘기기 이외)장비에서 뜬 오류 고치기, 장비에서 사용하는 부 자재 준비, 위에걸 장비를 2개를 돌리면서 약 6시간 동안 서서 하면 된다. 일어서서 근무하는게 아프긴 했지만 익숙해졌고, 처음 혼자할때는 바쁘긴 해도 장비를 멈추거나 하지 않아서 아웃풋은 잘 나왔고 또 식사시간(1시간) 휴식시간(30분)을 쉴 수 있기에 할만했다. 여기가까지는 좋았다. 문제는 다음이다. 식사 교대라는 벽을 느끼기 전까지 본론 식사교대는 옆 사람이 밥먹고 올때까지 그 사람의 장비를 내가 돌리는 것이다. 쉽게 말해 장비 2개 돌리다가 옆사람이 밥먹으러 가면 장비 4대를 내가 혼자 돌려야 한다. 할 일이 2배로 느는 것이다. 이 떄 옆사람 욕을 진짜 많이 했다. 준비하고 갈 수 있는데도 안해주고 가고, 오류 꺼주고 갈 수 있는데도 안꺼주고, 자재 넘기고 갈 수 있는데도 안 넘겨주고 내 장비 하기도 바빠서 못해주면 왜 안해주냐고 꼽주고 시발련 그 때도 식사교대때 옆사람 원망하면서 돌리고 있는데 오류가 진짜 많이 떴다. 자재 준비하고 있으면 오류뜨고, 오류 끄고 다른거 하러가면 또 똑같은 오류 뜨고, 동시에 3 장비에서 오류뜨고, 정리 안하고 간거 정리할때 오류 뜨고...(그때 생각하면 아직도 아찔하다.) 그렇게 멘탈 나가서 속으로 욕하면서 오류 끄고 있을때 순간 머리가 깨끗해졌다. 다른 사람이 된 듯 속에 있던 분노가 지워지고 '왜 화내고 있지? 그냥 하면 되잖아'라며 스스로에게 되뇌였고. 속으로 욕하는 날 보고 결국에는 나만 욕먹는 다는 사실에 한심해 했다.(왜 이런 현상이 일어났는지는 지금도 모르겠음) 그 뒤로 씩씩하게 하기로 했다. 어차피 해야할거 욕하고 불만만 해봤자 결국 나한테만 들리는 거고, 아무도 보지 않는다 생각해도 결국 나 스스로가 지켜보고 있었고, 씩씩하게 했기때문에 누가 뭐라해도 전혀 분하지 않았다. 이때 "피할 수 없다면 즐겨라"라는 말의 참 뜻을 몸으로 실감했다. 마무리 흔히들 많이쓰는 말인 "피할 수 없으면 즐겨라" 솔직히 이거 말 안된다 생각한다. 말이 된다 하더라도 이걸 할 수있는 사람은 진짜 극 소수의 마인드를 가진 사람이라 단정 지을 수 있다. 그럼 우리 같은 범인들은 우째해야 할까 바로 씩씩한 태도를 가지는게 포인트다. 세상살이 불만불평한다고 변하지 않는다. 변하는건 세상을 바라보는 우리의 시선이다. 스스로에게 부끄럼 없는 씩씩한 인생을 산다면 자연스럽게 즐길 수 있다 생각한다.
고객에게 맞는 답을 하려면 정보를 많이 모으기만 하면 될까요? 가입 상품과 이용 상황은 더 적절한 답에 도움이 됩니다. 개인화 서비스에는 필요한 정보를 골라 쓰고, 실제 업무를 처리하며, 허용된 범위에서 멈추는 구조가 함께 필요합니다. 고객이 로밍 요금을 물을 때 필요한 것은 자신의 가입 상품과 이용 상황에 맞는 안내입니다. 고객 정보를 얼마나 확보했는지만으로는 개인화 서비스의 설계를 설명하기 어렵습니다. 매출 22% 증가와 이탈 9% 감소를 읽는 법 성과를 비교하려면 언제, 어떤 고객을 대상으로 측정했는지 알아야 합니다. OpenAI가 공개한 고객 사례에는 이 조건들과 다른 사업 변화의 영향이 제시되지 않아, 개인화 기술의 기여를 따로 구분하기 어렵습니다. 가입자당 평균 매출을 뜻하는 ARPU는 고객 한 명당 매출을 보는 지표입니다. OpenAI는 Circles의 싱가포르 사례에서 이 값이 22% 늘었다고 소개합니다. AI 추천을 도입한 뒤 이탈이 9% 줄었다는 수치도 보고합니다. 이탈 감소의 단위는 9%로 제시됐으며, 이를 9%포인트로 바꿔 읽을 근거는 없습니다. 고객 지원을 맡는 CareX에는 자율 해결률 65%라는 수치가 제시됩니다. 다만 세 수치 모두 기술 공급사가 소개한 고객 사례의 보고값입니다. 다른 통신사가 같은 모델을 사용할 때 얻을 성과로 그대로 옮겨 잡기는 어렵습니다. 요금 조회와 상품 변경은 실패의 의미가 다릅니다 전문 에이전트가 요청을 넘겨받은 뒤에는 무엇을 구분해야 할까요? AI Concierge는 검색·계정 관리·지원·추천을 묶고 요청을 전문 에이전트로 전달합니다. 조회 지연은 재요청할 수 있지만 변경의 중복 실행은 고객 상태를 잘못 바꿀 수 있습니다. 중복 방지·결과 확인·상담원 인계 맥락은 설계 과제이며, 공개된 설명만으로 CareX의 구체적인 거래 처리 구조를 확인하기는 어렵습니다. 상품 변경 기능을 붙일 때는 요청을 전달한 뒤 고객 상태가 어떻게 바뀌었는지까지 살펴야 합니다. 따라서 실제 처리 기능에는 중복 실행을 막는 장치와 결과 확인이 필요합니다. 실패할 때 상담원에게 어떤 맥락을 넘길지도 함께 설계할 과제입니다. Circles에서는 AI Concierge가 요청을 전문 에이전트에 전달하고 CareX가 이를 뒷받침하지만, 공개된 설명에는 에이전트 간 통신과 구체적인 거래 처리 구조가 드러나지 않습니다. 기술 부채와 기술 중력을 구분하는 이유 오래된 청구 시스템과 출시를 서두르며 생략한 검증을 같은 문제로 봐도 될까요? ITWorld 글이 제안한 관점에서는 승인받은 지름길은 기술 부채, 승인 없는 지름길은 섀도 기술 부채, 당시 합리적이었으나 현대화가 필요해진 시스템은 기술 중력입니다. 오래된 청구 시스템의 의존성을 옮기는 일과 생략한 권한 검사·결과 검증을 복구하는 일에는 서로 다른 작업 계획이 필요합니다. 청구 시스템의 나이만 살펴서는 무엇을 고쳐야 하는지 정하기 어렵습니다. 당시에는 합리적이었던 시스템을 현대화하는 작업과, 출시를 서두르며 빠뜨린 권한 검사나 결과 검증을 복구하는 작업은 다릅니다. ITWorld 글은 이 차이를 설명하기 위해 선택 당시의 사정과 승인 여부를 구분합니다. 일정과 비용 때문에 승인받은 지름길에는 기술 부채라는 이름을 붙입니다. 승인 없는 지름길은 섀도 기술 부채로, 시간이 지나 현대화가 필요해진 시스템은 기술 중력으로 구분합니다. 이 관점에서 보면 기존 시스템의 의존성을 옮기는 계획과 새로 생략한 검증을 되살리는 계획을 따로 세워야 합니다. 정보 출처 설명과 실제 접근 기록은 별개입니다 데이터 출처를 확인할 때 필요한 것은 실제로 정보를 읽은 과정의 기록입니다. GeekNews의 요약에 따르면 Muse가 설명한 출처와 이후 확인됐다는 동기화 내역 사이에 차이가 있었습니다. 이 논쟁에서 살펴볼 설계 문제는 모델의 출처 설명을 어떻게 검증하느냐입니다. 어떤 연결 도구가 데이터를 읽었는지, 그때 어떤 권한을 사용했는지 기록해야 설명과 접근 내역을 대조할 수 있습니다. GeekNews는 Jason Aten의 사례를 인용해 허가하지 않은 Apple Messages 기록이 동기화됐다는 주장을 전합니다. 같은 페이지에는 이전에 부여한 권한과 다른 기기의 설정을 살펴야 한다는 반론도 있습니다. 주장과 반론이 함께 제시된 상태여서, 이 논쟁만으로 권한 우회가 있었는지와 그 원인을 확정하기는 어렵습니다. 통신 서비스에 적용할 설계 원칙으로는 요청에 필요한 데이터 범위를 먼저 정하는 방법이 있습니다. 사용량, 청구, 위치 정보에 접근할 수 있어도 로밍 문의에 모두 쓸 이유는 없습니다. 조회 권한과 변경 권한을 나누고, 도구가 실행되는 지점에서 허가받지 않은 데이터 접근을 막는 방식도 검토 대상입니다. 개발 효율 29% 향상과 고객 문제 해결을 따로 측정합니다 자율 해결률을 비교하려면 먼저 무엇을 해결로 셌는지 정해야 합니다. 답변을 생성한 요청을 세는 방식과 고객의 문제가 끝난 요청을 세는 방식은 측정 대상이 다릅니다. 같은 이름의 지표라도 이 기준이 달라지면 수치를 바로 비교하기 어렵습니다. 따라서 고객 지원의 성과를 읽을 때는 해결이라는 말이 가리키는 상태부터 정의해야 합니다. OpenAI는 Circles가 Codex를 설계, 코딩 보조, 단위 테스트에 활용해 개발 효율을 29% 높였다고 보고합니다. 그러나 계산 방식은 제시하지 않았습니다. 코드 작성에 걸린 시간을 줄였다는 뜻인지, 전체 개발 주기가 짧아졌다는 뜻인지 구분하기 어려워 팀의 생산성 목표로 바로 삼기는 어렵습니다. 개발 효율은 개발 활동을, 자율 해결률은 고객 지원 활동을 측정합니다. 고객에게 도입 효과가 있었는지 판단하기 위한 관찰 항목으로는 문제 해결 여부, 처리 지연, 재문의, 권한 밖 접근의 차단 여부를 제안합니다. 완료 조건은 고객의 일이 제대로 끝나는 것입니다 앞서 살펴본 조회와 변경은 실패했을 때의 영향이 달랐습니다. 기존 시스템을 현대화하는 일과 출시 과정에서 생략한 검증을 복구하는 일도 작업 계획을 달리해야 했습니다. 이런 차이를 구분해야 실제 처리 기능에 필요한 작업을 구체적으로 정할 수 있습니다. 데이터 접근은 연결 도구와 권한의 기록으로 살펴야 합니다. 성과 수치에는 무엇을 측정했는지에 대한 정의가 필요합니다. 특히 개발 효율과 고객 지원의 해결률은 각각의 활동을 기준으로 해석해야 합니다. 다음에 해 볼 것 — 적용을 시작할 때는 고객 요청 하나를 골라 처리 경로를 끝까지 정리합니다. 읽을 데이터, 실행할 변경, 실패 시 인계 대상을 연결하면 필요한 시스템 통합 작업을 구체화할 수 있습니다. 원문: webi 기술 블로그 참고한 자료: Circles powers telco personalization with OpenAI technology “모든 낡은 시스템이 부채는 아니다” 기술 부채라는 이름의 함정 놀랍지도 않게, Meta의 새 Muse AI 에이전트가 사용자 권한 설정을 노골적으로 무시함