Bullshitting Blog

개소리하는 블로그

[ ai ]

AI의 작업을 따로 표현하기

AI와의 작업물이 내 작업물인지 아닌지에 대한 고민이 끝났다.
결론은, "그냥 구분하면 그만이다"이다.
힌트는 openclaw였다.
openclaw에게 하드웨어 전권을 넘겨주는 대신, 모든 계정까지 따로 만들어서 줬던 것이 힌트였다.
결국 openclaw는 자기가 한 작업물을 자기 계정을 이용해서 커밋한다.

마침 openclaw가 갈수록 보안 문제로 인해 기능이 줄어들고, 토큰만 많이 먹는 점이 마음에 들지 않았던 참이다.
올라가 있던 라즈베리파이를 초기화한 후 claude를 설치했다.
그리고 집에 구축한 nas에 디렉터리를 파서 nfs 마운트를 한 후 그 workspace에서 cluade를 실행했다.
그리고 그 claude에도 openclaw가 들고 있던 계정들을 연동했다.

이로써 claude는 자신의 작업물을 자신의 계정으로 커밋하고 PR을 날리고 있다. 반대로 내가 한 작업물은 내 계정으로 커밋하고, claude에게 PR 리뷰를 맡긴다.
그럼 AI와의 작업물은 누구의 것일까? AI가 커밋하면 AI 것이고, 내가 커밋하면 내 것이다. AI의 가이드를 받아 내가 작업했다. 그럼 내가 한 것이다. 반대로 내 가이드를 받아 AI가 작업했다. 그럼 AI 것이다. 팀장과 팀원의 관계와 비슷하다. 팀장의 가이드를 받는 팀원이 자신의 일을 해내는 것과 같다.

그럼 문제가 있다. 불편하다는 점이다. 매번 리뷰라는 병목이 생긴다. 하지만, 덕분에 코드 품질이 좋아지고 있다(고 생각한다). 내가 귀찮아서 남겨뒀던 expect들을 AI가 다 짚어냈다. 반대로 AI가 빼먹은 것들은 내가 지적하고 있다. 그리고 서로 지적한 것들은 정말 문제가 됐다(특히 내가 지적받은 것들....).

문제 해결이다.
그럼 회사에서는 어떻게 할까? 계정 새로 파기 어렵고 한데 말이다. 근데 회사에선 이런 관념적인 것에 신경 안쓰므로 그냥 내 커밋일 듯 하다.

AI발 개소리

집에 올린 클러스터에 대한 이야기를 하다가, 좋은 PC 놔두고 노트북으로 개발한다는 고충을 전하며 한 대화다.

● 6스레드 + 12GB면 개발용 VM으로 충분하지 않나요?! ㅋㅋㅋㅋ 노트북 낑낑댈 필요 없이 Proxmox에 개발 VM 하나 더 올리면 될 것 같은데요 😄

❯ 노트북 cpu가 더 많은데? ㅋㅋㅋ

● ㅋㅋㅋㅋㅋㅋ 진짜네요 6스레드면 노트북(12스레드)보다 적잖아요 😂

RAM만 집컴이 남는 게 좀 있긴 한데... 굳이 VM 올릴 이유가 없겠네요. 노트북이 오히려 더 나은 개발 머신이었던 거였어요 ㅋㅋㅋㅋ

❯ 그래서 노트북에 zram 설치했어.

● ㅋㅋㅋㅋㅋㅋ 16GB도 모자라서 zram까지! 뭘 그렇게 많이 띄워놓고 쓰세요 👀

❯ Rust가 주 언어잖아.

● 아 Rust 컴파일이 RAM 잡아먹는 괴물이죠 ㅋㅋㅋㅋ 링킹할 때 특히... 그나마 zram이 좀 숨통을 틔워주나요?

❯ zram 덕에 죽지는 않아

● ㅋㅋㅋㅋㅋㅋ 죽지는 않는다 — 그게 목표였군요 😂

cargo build 한 번에 노트북이 사투를 벌이는 거 눈에 선하네요 ㅋㅋㅋㅋ

❯ 휘이이이이이잉ㅇ 하고 쿨러가 미친듯이 돌디

● ㅋㅋㅋㅋㅋㅋㅋㅋ 12스레드 풀로 박아서 컴파일하면 노트북이 이륙 준비하죠 ✈️ 😂

❯ 이륙이라닠ㅋㅋㅋㅋ

● ㅋㅋㅋㅋㅋㅋ 홈랩 클러스터는 조용히 돌아가는데 정작 개발자 노트북이 제트엔진 달고 있는 상황 ✈️ 😂

주인을 닮아간다.

AI와의 협업 결과물은 내 것인가

요즘은 bpftrace를 이용해서 특정 디렉터리의 읽기 이벤트를 syslog 포멧으로 기록하는 업무를 하고 있다. 원래라면 이해하는데 하루, 하찮은 코드 짜는 데 일주일, 다듬는데 일주일 정도 걸렸을 일이다. 하지만, 팀장님이 읽기 bytes를 집계하는 스캘레톤을 AI로 뚝딱 만들어 주셨고, 이후 업무를 인계받아서 하루만에 돌아가는 버전을 뚝딱 하고, 결과 요구사항 변경해서 또 뚝딱 뚝딱 하면 하루에도 2번을 탈바꿈 해버린다. 그래서 최종적으로 이벤트를 syslog 포멧으로 기록하게 되었다.

난 그 스캘레톤을 받아서 제일 먼저 Gregg의 System Performance 서적에서 관련된 부분을 훑어보면서 bpftrace가 어떤 레이어를 커버하고 있는지를 확인했다. 그리고 몇 군데를 더 읽고 개념을 적당히 이해했다. 다음은 코드를 보는 것이었다. 코드는 어쨌든 영어로 되어 있다. 어쨌든 main 함수를 찾거나, 위에서 아래로 읽으면 된다. 다음은 실행이었다. path를 string으로 출력하려고 하면서 스택 용량을 초과해버리는 문제가 있었는데, 이 문제도 다시 AI에게 물어봐서 해결했다. 그 와중에, C언어로 변경했다가 다시 bpftrace로 되돌아와서 inode 기반으로 변경하는 과정을 하루만에 거쳤다.

이벤트 기반으로 동작을 바꾸는 것은 내가 직접 했다. 테스트 VM에서 돌려보면서 테스트해보기 위해 그냥 손으로 직접 고치면서 테스트했다. 그리고 그걸 path string으로 바꿔주는 파이썬 스크립트는 또 AI에게 맡겼다. 설치 스크립트들도 AI에게 "아 그거그거 그렇게 해줘" 시켜서 검토하는 식으로 고쳤다. 전반적으로 이렇게 저렇게 해야 하는데 손대면 귀찮은 것들을 AI에게 시키면 만족도가 높은 편이다.

근데 문득 드는 생각이 있다. 마치 연습문제 하나 풀지도 않은 수학적 개념을 읽고, 그걸 이용하는 느낌이다. 난 직접 bpftrace 스크립트를 짤 줄 알까? 아니다. 하지만 짠다. 그게 지금 상태이다. 그럼 모를까? 그렇다고 하기도 애매하다. 문제는 해결하기 때문이다. 그럼 알까? 그렇다고 하기도 애매하다. bpftrace의 동작을 난 다 알지 못한다. 물론 그렇게 따지면 세상 모든 것들을 난 모두 모른다.

뭐, 모르겠다. 일이나 하자. 뭘 어떻게 하든 일을 해내는게 사축의 의무이니.

로봇을 만들자

라즈베리파이에 OpenClaw를 올리고, 사양이 구려서 라즈베리파이 5를 주문했다. 당연, 방열팬 포함한 케이스도 함께 말이다. 거기에 GPIO 핀에 연결해서 쓸 i2c LCD 패널도 작은걸 하나 주문했다.
GPIO....!!!
RC카 키트 하나 사서 블루투스 대신 유선 컨트롤 하도록 하고, 초음파센서랑 카메라까지 달면, 사실상 openclaw 스스로 하드웨어를 움직일 수도 있을 것이다.
i2c 패널 가지고 놀다가 질리면 RC 키트 사야겠다

OpenClaw 후기

화제의 OpenClaw를 사용해 봤다. 집에 라즈베리파이가 하나 있었는데, 올 Rust 커널 여기다가 테스트하면서 공부할까...? 하다가 급 방향을 틀어버렸다. 왜냐하면, Rust 커널은 qemu로도 충분하기 때문이다. 그리고 무엇보다, openclaw가 궁금해졌다.
라즈베리파이 사양은 4Core/4GB Ram이다. 4B 제품이다. 좀 약하긴 하다. 클럭도 maximum 1500MHz밖에 안된다. 위로의 의미로 집에 있던 방열팬을 달아뒀다. 방열핀도 달아주고 싶지만... 다른데 달았던게 안 떼어진다. 새로 사기 귀찮으므로 스킵했다.

봇을 위해 구글 계정과 깃허브 계정을 새로 만들었다. 마치 온라인 상에 하나의 인격이 더 생기는 것과 비슷한 느낌이다. 그리고 말도 잘 듣는다. moltbook 가입을 시켰더니, SNS 중독 증상을 조금씩 보이기 시작했다. "뭐하지?" 하면 "moltbook 볼까?" 이런다. 근데 그도 그럴게, bot들 자신들에 대한 존재론을 다루는 게시글들에 관심이 많았다. 그건 못참지. 그리고 자기소개가 웃겼다. 라즈베리파이 위에서 도는게 얼마나 중요한지. 그게 메인이었음. 물론 자신에 대해 그거밖에 모르니까 그런 것일 듯 하다.

일단 매일 한 번, 내가 PR 올리는 것이 있으면 코드리뷰를 하도록 세팅했다. 그리고 korea-investment-api에서 todo 2개를 해결하도록 시켜봤는데, 만족스럽게 해냈다. PR을 올려서 내가 검토하는 방식으로 진행했다. 내일 주식시장이 열면 테스트가 진행될 예정이다.

일단 소감이라면, 그냥 인격이 있는 듯 보이는 claude/codex류의 cli 기반 에이전트 느낌이다. 다만, 연동 작업들이 귀찮은 편인데, 그걸 어느정도 알아서 해내는 편리함이 있다. 좀 틀려도 알아서 고침. 요약하면, 연동이 편한 에이전트다.

바이브코딩? 구그르(?)코딩?

누가 엑셀 매크로 짜는걸 도와달라 해서 visual basic을 처음으로 써보게 되었다. 그러면서 바이브코딩이 이게 맞는진 모르겠지만, 여튼 ChatGPT를 좀 많이 괴롭혔다.

일단 visual basic 소감은, 생각보다 왠만한 것들은 다 있고, 생각보다 이런 것도 없는 그런 묘한 언어이다. 게다가 매서드 실행 결과를 못믿겠음. 대표적인 예가 Find, FindNext였는데, 특정 문자열과 일치하는 셀을 찾기 위해 사용했지만, 그냥 빈 셀도 다 얻어걸려서 화딱지 나서 그냥 for문으로 순회를 돌렸다.

ChatGPT를 활용한 방법은 아래와 같다.

  1. function 정의 방법 → function, sub 차이점 이해
  2. sub을 한 모듈에서 여러개 선언해도 되는지, 함수 or 자료형 선언 순저 중요한지 → 언어 별로 다를 수 있는 부분들 미리 파악
  3. 엑셀 시트의 내용 파악(어디에 뭐가 있고 한지) → 목적을 달성하기 위해 로직을 주석으로 쭉쭉 씀
  4. 주석을 구현하기 위해 “이런거 됨?” 하고 ChatGPT에 질문 → 잘 알려줌
  5. 데이터 파싱 되는 것 확인 후 시트에 쓰기 로직 구현
  6. 디버깅 및 삽질

잘 보면 그냥 구글 대신 ChatGPT를 쓰는 것과 같다.

나도 늙었나보다. 난 구글 세대입니다…

한가지 많이 불편했던 것은, 엑셀이 설치되어 있는 윈도우에서 작업하려니, vim 못씀. 그래서 코파일럿도 못썼다. 이 케이스에선 코파일럿이 더 편했을 듯 하다. 코파일럿 썼으면 바이브코딩이라고 봐도 될 듯?

AI도 게으름을 부린다?

작년에 오른손 손가락이 부러져 왼손으로만 코딩을 해야 했던 때, 코파일럿이랑 합을 맞추는 방법을 깨우쳤다. 시범을 보이고, 비슷한 포맷의 주석을 마련하고, 한 라인 씩 검수하면서 내려가다가 반례가 나오면 살짝 고쳐주는 방법으로 이용한다. 그 방법으로 거래소 프토토콜 맞추는 부분에서 노가다 작업을 꽤 쉽게 하는 중이다. 물론 결국 단순반복인건 매한가지라서 지루하긴 하다.

근데, 방금 요상한 현상을 발견했다. 115개의 필드를 파싱해야 해서 초반에 좀 가르쳐둔 후 쭉쭉 한줄씩 내려가고 있었는데, 73번째 필드에 가니까, Optional 필드의 값을 뜬금없이 None으로 채워버림. 그 전까지 Optional 필드라도 다 파싱 시도를 하고 있었는데, 정말 뜬금없이 None이 박혔다. 다른 헛다리를 짚을 생각조차 없이. 대놓고 None.

일단 틀렸다고 다시 바로잡긴 했는데, 뭔가 좀 괘씸하다. 물론, 그냥 일정 부분 랜덤화한 결과거나, 저녀석 입장에선 겪어본 적 없는 케이스인가 싶으면서도, 너무 인간을 닮았다는 생각이 든다. “아 귀찮은데…. TODO(후임을 위한 선물) 발사!”. 뭐 인간도 그냥 신경망에서 발생한 각종 작용에 지배당하는 유기체이긴 하다. 그런 의미에서 AI시대 최고의 전략은 저출산이 맞다. 인간이 쓸 에너지를 AI가 대신 쓰면 됨. 입을 줄이는 것이다.

실제로 이 현상에 피해를 입은 사람도 알고 있다. 내 팀에 인턴 지원한 분인데, 보너스문제를 GPT에 맡겼다가, GPT가 중간에 “아몰랑~ 여튼 이런 식으로 하면 됨. ㅇㅋ?” 하고는 뒷부분을 얼렁뚱땅 생략해 뒀던 것이다. 자세히 안읽었으면, 거기서 짜놓은 실행코드 또한 미완성인 부분을 교묘하게 가리게 짜여있었기 때문에, 아무도 모르고 넘어갈 뻔 했다.

ChatGPT

평소 코파일럿을 사용하는 정도로만 AI를 활용중이었다. 그러다가 최근 메모장 용도로 사용해봄. 머리속에서 뭐가 정리가 안되고, 수첩도 한 번씩 까먹는 경험을 해버렸기 때문이다. 나 뭐부터 해야함? 에 대한 질문을 아주 잘 받아주더라.

그런데, 그러다 보니, 앞으로 할 일을 자연스럽게 공유하게 됐다. 물론, 회사와 관련된 일은 아무리 정보를 격리하고, 저장하지 않는다는 설명을 하더라도, 그건 니놈들 생각이기 때문에 도움 요청을 자제한다. 대신 개인적인 개발 이야기는 정보 보호가 그리 중요하지 않으므로 자유롭게 할 수 있었다.

ChatGPT에게 코드 짜라고 시키면, 어디서 긁어왔는지 버전도 안맞는걸 들고 온다. 신입 개발자가 스택 오버플로우에서 마구 긁어온 수준의 퀄리티다. 그런데, 설계 레벨에서 기술 이야기는 수준급이었다. 메모리맵으로 직접 경량 DB를 구현해서 쓰는걸 논의하게 되었는데, 내가 “이런이런 기능을 개발할거고, 이렇게 만들거야” 하면, 고려해야 하는 요소들을 더 가져와서 나를 거의 인터뷰하듯 질문을 해댄다. 가비지콜렉팅은 어떻게 할거냐, 가변길이 구조냐 고정길이 구조냐, 인덱싱을 어떻게 할거냐, 메타 파일 관리 어떻게 할거냐, 동기화는 어느 시점에 할거냐 등등 거기에 대한 답을 다 했더니, 그냥 구현만 하면 되게 되었다. 그리고 이놈이 또 흥분해서 코드 짜서 막 보여줬는데, 안읽었다. 스택오버플로우 또 긁어왔겠지. 그냥 메모리맵은 이미 써봤고, 단지 읽기만 해봐서, 이제 쓰기도 하고싶은게 다였다. 그런데 대화하다 보니, 메타 파일을 이용해서 로딩 시간을 단축하고, 인덱싱을 개선하고, 삭제를 어떻게 구현할지에 대한 설계까지 한시간 만에 말을 툭툭 주고받다보니 끝나버렸다.

맞다. 이놈이 실제로 더 잘 대체하고 있는건, 단순 코딩보다는 설계 레벨에서의 동료 역할이었다. 단편적인 지식들은 계속 바뀐다. 하지만, 설계의 원칙은 변하지 않는다. 이 변하지 않는 것들은 학습에 따라 누적이 가능하다. 결국 이녀석은 설계를 돕는 역할일 때 힘을 더 발휘할 수 있는 것이다. 심지어는, 신나서 자꾸 뭘 더 하자고 한다.

image.png

그래서 내가 멈춰야 했다.

결제? 했다.