neozest : neo+zest

트윗으로 단편적인 생각을 바로바로 적는 편인데... 블로그에 옮겨서 조금 장문의 글 소재로 활용해 볼까 함. 

• 애플이 새로운 MacOS인 GoldenGate에 로컬 모델을 배포한다. 이를 활용할 수 있는 CLI인 fm이 함께 배포된다. 우선 fm을 설치했는데, 모델이 로컬에 전송되지 않아서 대기중인 상태. fm을 이용하면 파이썬 스크립트를 작성하여 간단한 일을 로컬 모델로만 처리할 수 있게 된다. 그러면 파이썬은 bash script의 역할을 담당하지 않을까. 예전에 유닉스 빌드를 만들기 위해 Makefile 대신 혼자서 파이썬 스크립트를 작성하던 신입때가 생각이 났다.
• PHP를 시작으로 AI발 보안사고가 터지기 시작했다. 언어의 장단점과 언어의 호불호는 나눠서 판단해야 겠다. PHP가 처음 등장했을때는 엄청난 혁신이었다. Pro*C와 Perl로 CGI 개발해 본 사람들은 이해할 것. 그리고 여전히 돈을 벌어다주는 기술이기도 하고.. 언어적인 측면에서 부족한 점이 많은 언어일 수 있으나,.완벽한 언어라는게 있을 수 있을까? 적재적소에 필요한 기술을 선택해야 하는데, 개발자들은 논리를 다루는 습관때문에 Binary Thinking을 의도치 않게 하게 되는 것 같다.
• 상도동계의 후계자였던 최형우 의원이 사망했다. 무라카미 류 작가도 사망했다. 아폴로 프로젝트의 마가렛 헤밀턴도 돌아가셨다. 점점 우리가 어른으로 생각했던 분들의 시대가 저물고 있다.
• AI로 여러가지 인생을 체험해 보는 게임이 등장했다. https://1in8b.life/en/ 삶이라는 여정에 대해 다시 한번 생각해 보는 게임. 그런데 이걸 AI가 뒤에서 처리하는걸까? 
• 오픈소스의 소멸? 웹 프록시인 Fiddler도 상업적 이용에는 요금을 내야 하는 구조로 바뀜. mimtproxy는 불편해서 다른 것을 알아보다가 브라우저의 har 파일을 이용하면 되겠다라는 생각으로 마무리.
• 에이전트 오케스트레이션 구조에 대해 고민해 보는 중: 똘똘한 조율자+좀떨어지는조력자들...vs 저돌적이고 좀 떨어지는 조율자+똘똘한 조력자들. 어떤 구조가 더 뛰어난지라는 관점보다는 어떤 경우에 각 구조가 더 힘을 발휘하는가로 고민해 본다. 현실에서도 한 구조가 압도적인 성과를 내는 것은 아니므로...
• 황민호님 하네스 특강에 참석하고 뒷풀이까지 참석. 팀이 크다고 무조건 일을 잘하는 건 아니고,. 효율적인 크기의 팀으로 일을 잘하는 구조를 만드는 것이 중요하며, 하네스/서브 에이전트 구조도 마찬가지라는 생각을 해보았다. 하네스의 후속 주제가 무엇일것인가에 대해 의견이 분분했지만, 하네스가 올 연말/내년 초까지는 이어질 것이라는 중론.
• 미국 로또 시스템 중 Pick3라는 방식도 있다. 000부터 999까지의 숫자를 선택하고, 맞으면 총 로또 판매 금액과 무관한 정액 당첨금을 주는 방식. 그런데 수년만에 당첨번호가 000이 되었고, 당첨자수는 5천명. 그래서 복권회사에서 지급한 당첨금액은 20억 규모. 000을 기본적으로 베팅하는 사람이 매회 5천명이라는데에서 놀랐다. 인생 역전은 아니겠지만, 재미있게 지낼 수 있는 방식이라 생각.
• 케라스 책을 여전히 읽고 있는데, 속도도 쳐진다. 예전같으면 오프라인 모임 만들어서 같이 읽고 이야기 나누고 했을텐데. 독립적인 학습 공동체와 개방형 기술을 바탕으로 서로 돕고, 기술을 이해하고, 모범 사례와 지식을 공유하는 사람들의 연결망이 필요하다. 그래도 꾸준히 책 읽어야겠다. 여든 이후에도 책을 1400권 읽은 할머니도 계신다. 사람이 언제까지 살아있을지 모르니, 하고싶은게 있다면 하루라도 빨리 행동에 옮기는 것이 좋다.
• IT인물 열전 블로그 글을 짬짬이 적고 있는데, 그분들의 삶을 살펴보면 결국 모든 것이 같춰져 있지 않았음에도 꿈과 에너지, 삶에 대한 고민 등으로 노력한 결과임을 알게 된다. 그것때문에 나 자신을 가다듬기 위해 블로그 글을 적는 느낌.
• 새로운 회사에서의 업무 시작을 축하해 준다면서 건네받은 자이탄소샤프펜. 사각사각..쓰여진다. 다만 HB는 옅은 느낌이라. 2B 연필심을 구해서 바꿀 생각인데.. 문제는 이게 광고 문구대로라면 평생 원래 받은 HB 심을 쓸일이 없게 될거라는 사실이다.
• 이재명 대통령의 트윗을 보고, 줄여라라는 의견도 있던데.. 말이 많아지면 실수를 하게 마련이다. 그렇다고 리더에게 말을 하지 말라고 주장한다면 리더가 어떤 말도 하지 않게 될 것이다. 결국엔 폭군이나 아집쟁이가 되겠지. 실수하면 사과하고, 사과하면 진의를 받아주고 이렇게 시스템이 성숙되어 가야 한다고 생각했다. 생각이 다른 것을 누르려는 우리나라 문화때문에 그냥 할 말이 있어도 참고 넘어가버리면서 스트레스가 내적으로 쌓여가는 것 같다.
• Manning 시리즈에서 한국인 저자 책이 종종 보인다. 데이터 AI 활용은 확실히 우리가 잘하는 분야이긴 한 것 같다. Agent 책도 샀으니 읽어야 하는데, Financial AI는 분야와는 상관없지만, 한번 휘리릭 볼 생각이긴 하다. 금융/재무 쪽은 할루시네이션이 있으면 안되는 분야인데, 어떤 식으로 해결하는 것인지에 대한 궁금함이 있다.
•  LAX 갈일 있으면 근처 인앤아웃으로 가서 햄버거 먹고 우버로 이동해보자. 공항이 아니라서 공항 픽업 수수료가 안붙는다고 한다.

 책은 다른 사람의 사고나 경험을 간접 체험할 수 있는 매우 저렴한 수단이다. AI에 대한 감각을 계속 갱신하기 위해 여러 가지 책을 읽어보는 중이다. 하지만 여전히 눈에 거슬리는 몇몇 단어들이 전면에 있는 책 표지는 불편하다. 나에게는 하네스와 AI 루프, ○ ○ ○ 엔지니어링이 그러하다. 이 책은 그중 두 개를 제목에 내세웠다. 하네스, AI 루프.

처음에는 그냥 트렌드 추적용으로 생각하고 별 기대없이 책을 펼쳤는데, 다른 책들에서는 접하기 어려운 저자 자신만의 소프트웨어 개발 하네스와 루프에 대한 경험과 생각이 잘 정리되어 있어서 좋았다. 대부분의 책이 루프는 이런 것이야, 하네스는 이런 것이야에 머물러 있다면 현업에서 적극적으로 도입해 보면서 실제로 겪은 일을 기반으로 생각을 정리했다는 점에서 이 책은 가치가 있다고 생각한다. 저자의 생각에 100%까지는 동의하지 못하지만, 고민의 방향은 100% 동의한다. 저자분은 게임 개발을 근 20년 가까이하신 개발자. 나의 생각과 같든 다르든, 자신의 경험을 용기 있게(?) 공개하고 의견을 나누는 책들이 많이 출간되면 좋겠다.

이 책은 켄트백이었나 엉클밥이었나, 여튼 두 사람 중 한 명이 소개했던 Cucumber를 살펴보면서 스쳐지나갔던 Gherkin을  소개한다. 잘 사용하시는 분인 것 같다. 사고의 프레임워크로도 괜찮아 보이는데, 다시 한번 신규 서비스 개발 과정에 적극적으로 시도해 봐야겠다.  As.... I want to... So that.....처럼 Given... When.. Then..으로 요구사항을 검토하는 것도 왠지 전체적인 명세를 명확히 만들어가는데 도움이 될 것 같다.

책 읽으면서 밑줄친 부분...

• 우리의 의도가 AI라는 컴파일러를 거쳐 기계가 실행할 수 있는 형태로 바꾸니 산출물에 가깝다.... 무엇을 만들 것인가에 대한 인간의 명확한 의도인 명세(Spec)와, 그 의도를 논리적으로 구조화한 설계(Design)가 본체이다.... 코드는 원본은 아니지만, 여전히 우리가 책임져야 할 결과물이다... 원본을  쥐고 있는 자가 시스템을 통제한다... 개발의 중심은 문법(syntax)에서 의도(Intent)로 이동했다.
• 설계하려는 기능의 동작 의도를 Context, Trigger, Reaction으로 나누어 구조화된 명세에 담아야 한다.... 우리가 무심코 생략한 빈칸은 소프트웨어 결함의 서식지이자 AI의 추정이 시작되는 자리이다.... 빈칸은 엔지니어 먼저 채워야 한다. 그래야 AI도 우리가 정한 경계 안에서 코드를 만든다... AI는 인간이 정한 WHAT을 바탕으로 HOW의 실행(execution)을 맡는다.
• Gherkin: Given/When/Then의 3단 구조는 기능의 동작을 조건, 행위, 결과로 나누어 작성하게 한다... 자연어 명세를 Gherkin 시나리오로 바꾸는 변환과정에서 작성자 스스로도 미처 인지하지 못했던 논리의 구멍을 발견할 수 있기 때문,.
• 엔지니어의 실력은 AI가 추론해야 할 작업과 기계적으로 검증해야 할 작업을 명확히 분리하여 루프를 배치하는데에서 드러난다... 엔지니어는 흩어진 단서를 연결해 문제를 정의하는 지능이었고, 이슈 시스템과 터미널, IDE사이에서 데이터를 옮기는 하네스였으며, 가설을 세우고 검증을 반복하는 루프 그 자체였다... 흔적을 남기지 않는 루프는 같은 실수를 반복한다.
• 하나의 태스크가 끝나면 세 종류의 기억이 남는다. 제품 코드가 어떤 경로로 실행되었는지, 에이전트가 어떤 과정을 거쳐 작업했는지, 다음 태스크가 무엇을 믿고 이어갈지를 각각 기록한다.
• AI는 전달받은 코드와 문맥 안에서 논리적으로 타당한 결과를 만들었을 뿐이다. 문제는 제품의 역사적 배경과 암묵적인 비즈니스 규칙을 전송하지 않은 채 결과를 운영에 반영한 데 있다.... 아무리 부조리해 보이는 코드라도 운영 환경에서 실제로 어떻게 동작하는지 증거를 확보하기 전까지는 손대지 않아야 한다.
• Mock을 많이 만든다고 해서 테스트하기 쉬운 구조가 되는 것은 아니다. 중요한 것은 외부 시스템과의 경계를 얼마나 작고 명확하게 통제하느냐다.... 절개선은 코드를 예쁘게 다듬기 위한 추상화가 아니다. 기존 동작을 검증하기 위해 테스트가 개입할 최소한의 통로이다.
• 사람의 기억 속에 잠들어 있는 비즈니스 규칙을 기계가 넘지 못할 가드레일로 바꾸려면 누구나 읽을 수 있는 명확한 문장으로 선언해야 한다.