okldk .. techy talky

  대화 요약:  이 대화는 AI 연구의 현재와 미래, 특히 스케일링 시대의 한계와 "연구의 시대" 복귀를 중심으로 전개됩니다. Ilya Sutskever(SSI 창립자, 전 OpenAI 수석 과학자)는 AI 발전의 병목, SSI의 전략, 초지능(superintelligence)의 안전한 개발, 정렬(alignment) 문제, 그리고 자신의 연구 철학을 논의합니다. 전체적으로 AI가 컴퓨트 중심에서 아이디어 중심으로 전환될 가능성을 강조하며, 미래의 불확실성과 안전을 중시합니다. 대화는 다음과 같은 주요 섹션으로 나눌 수 있습니다. 1. 스케일링 시대의 한계와 연구 시대 복귀 Sutskever는 스케일링(대규모 컴퓨트)이 AI 커뮤니티를 지배해 아이디어를 억압했다고 비판. 이제 아이디어가 더 중요한 "연구 시대"로 돌아갈 때라고 주장. 역사적 예시: AlexNet(2 GPU), Transformer(8-64 GPU)처럼 초기 혁신은 적은 컴퓨트로 가능했음. 현재 프론티어 시스템은 컴퓨트가 과도하게 필요하지만, 연구 아이디어 증명을 위해 최고 수준의 컴퓨트가 필수는 아님. 커뮤니티 기대: 더 다양한 아이디어 탐구, 과거 논문 재검토, 컴퓨트 병목에서 아이디어 병목으로 전환. 2. SSI의 컴퓨트와 자금 전략 SSI는 30억 달러 모금했으나, 다른 회사(예: OpenAI)의 대규모 자금 대부분이 추론(inference)과 제품화에 쓰인다고 지적. SSI의 컴퓨트는 연구에 집중되어 상대적으로 경쟁력 있음. 아이디어 테스트: 50개 아이디어 중 "다음 Transformer" 식별을 위해 최고 컴퓨트가 필요 없음. SSI는 연구 중심으로, 증명 가능한 수준의 컴퓨트로 충분. 수익 모델: 현재 연구 우선, 미래에 자연스럽게 드러날 것. 시장 경쟁 피함. 3. SSI의 초지능 계획: 직행 vs. 점진적 접근 기본 계획: 초지능(superintelligence) 직행(straight shot)...

 세 가지 시각화 도구/라이브러리인 Python (주로 Matplotlib, Seaborn 같은 라이브러리), Tableau, D3.js를 다섯 가지 주요 기준  1. 개발자를 위한 개발 용이성 (Ease to develop for developers): 프로그래머가 시각화를 얼마나 빠르고 쉽게 처음부터 구축할 수 있는지. - Python/D3는 유연하고 온라인 자료가 많아 쉽다. - Tableau는 다른 둘에 비해 시작하기가 약간 더 어렵다. 2. 개발자를 위한 시각화 유지보수 용이성 (Ease to maintain the visualization for developers): 기존 시각화를 업데이트하거나 디버깅, 변경하는 데 필요한 노력. - Tableau는 자체 애플리케이션 내에서 디스플레이를 관리하므로 유지보수가 더 쉽다. - Python 및 D3는 종종 별도의 환경이나 창(예: 웹 브라우저 창)을 관리해야 하므로 상대적으로 어렵다. 3. 최종 사용자를 위한 시각화 활용성 (Usability of visualization developed for end users): 비전문가가 완성된 결과물과 얼마나 쉽게 상호작용할 수 있는지(예: 필터링, 확대/축소)를 측정. - Tableau는 대화형(interactive) 포인트 앤 클릭 동작을 위해 설계되었기 때문에 가장 사용자 친화적. - Python/D3는 최종 사용자가 데이터 디스플레이를 조작하기 위해 더 많은 기술적 지식(때로는 코딩이나 브라우저 조작)을 요구. 4.  대규모 데이터셋에 대한 시각화 확장성 (Scalability of visualization to “large” datasets): 도구가 속도 저하 없이 방대한 양의 데이터를 얼마나 잘 처리하는지 평가. - 세 도구 모두 일반적으로 잘 작동하지만 특정 병목 현상이 있다.  - Python은 고해상도 플롯에서 버벅거릴 수 있고,  - Tableau는 강력한 로컬 컴퓨터가 필요하며,  - D3...

~ 2007:  예전에 15년도 더 된 직장에서의 코드 리뷰는 주로 overflow , 문자열 배열이 포함된 구조체 등 에서 java 로 변환되던 마지막 시점이었다. 코드리뷰는 그 이후로는 그렇게 깊게 algorithm 을 봐야하는 경우는 없었던 것 같다.  HW RAS 와 battery table 을 보거나 audio sound 만 보면 되는 정도였다. 2007 ~ 2010: 아직 smartphone 이 본격화 되기 전이라서 real time OS embedded SW 가 chipset licensee 에게만 주어지는 상황이었고, 항상 유념해야 할 data type, 메모리관리, lockup , reset 에 유의해야 할 mutex, semaphore 에 대한 이해가 기본적으로 필요한 SW 직군으로 부서 복귀를 하게 되어 정신없이 디버깅을 하던 시절에는 로그를 찍을 때 조차도 printf 와 snprintf 를 구분해야 하지 않나라는 정도 강박관념이 있었던 때에는 시간차 메모리 공격을 J-TAG 디버거로 해야 했고, 고객 단말을 회수해서 재현안되는 실제 보드에 납땜을 해서 ELF 로 현지 출장 디버깅도 했었던 2008년의 기억도 있었다. 요즘은 그 기억은 저 멀리 아득하고, 아마도 특수 산업이나 kernel 을 다뤄야 하는 closed 프러덕이거나, framework SK 자체를 개발하는 HW 회사, 칩셋 회사, 플랫폼 회사 정도 만이 남아 있을 듯 하다.    2010 ~2021: 한동안 TAM, wireless standard 관련된 서비스 TPM 을 했고, 본격적으로 cloud 에 관심이 생긴 시절에는 이런 저런 demo 연습을 하면서 쉬던 시절이있는데,  2021 ~: 다시 복귀한 일종의 feature engineering , data mining 을 하다보니 확실히 주변과 소통하는 코드 리뷰에서는 mutable, immutable 이 확실해 지니까 대부분은 메모리 한계에 대한 부담감은 현저히 줄고, 성능...

 최근 MCP 로 vibe coding and query 하는 것이 유행이라, 회사에서도 지난 주에 학습 시킨 녀석이 나 대신 PBI 에서 copilot 시켜서 차트 만들 듯이 내부적으로 chat bot 이 query 결과를 도출하도록 하는 데모를 했었다. 트레이닝을 많이 시켜야 할 텐데 어쩌면 chatgpt 로 회사 내부 메일 정리 검색은 쉬우니까 바로 다들 쓰게되지만, 내부 정보와 외부 팀원을 섞어서 프로젝트를 하면 어디까지 공유를 해야 할 지가 문제다. 다들 직장에서 살아남기 위해 정보를 gitlab 에 올리지도 않는 것 같고, snowflake query 900 줄 토나올 CTE 들도 혼자만 UDTF 로 따로 떼지도 않고 있다..