[월간 기록] 2026년 2월

크래프톤 정글 SW 12기 합격, AI 시대의 학습

이번 달의 큰 이벤트는 크래프톤 정글 SW 12기 합격과 참여를 위한 첫 번째 회사의 퇴사이다.
인수인계와 시험 준비에 많은 시간을 소요하여 자료 수집과 작업을 많이 하지 못했다.

수집

흥미롭거나 유용했던 자료들

LLM을 칩 위에 '인쇄'하는 Taalas의 방식 | GeekNews

Taalas라는 스타트업이 Llama 3.1 8B 모델의 가중치를 하드웨어 칩의 트랜지스터로 직접 구현했다.

원래 X에서 먼저 알았는데 GeekNews에도 올라왔다. TokenPost 기사도 참고.

처음 보고 모델을 칩에 고정한다는 발상이 신선했는데, 생각해 보면 비슷한 사례가 이미 있다.

부동소수점 연산은 원래 소프트웨어로 처리하다가 CPU에 내장되었다. ARM도 JavaScript의 부동소수점→정수 변환을 하드웨어 명령어(FJCVTZS)로 넣었다.

자주 쓰이는 연산을 하드웨어에 옮기는 건 반복되어 온 패턴이지만, LLM이 가능할 거라고는 직관적으로 생각하지 못했던 부분이다.

속도가 비교도 안 되게 빠르다. 데모 사이트에서 직접 대화해 보면 체감할 수 있다.

바이브코딩의 보안 문제: MoltBook 해킹 (GeekNews) | OpenClaw 마크다운 악성코드 (GeekNews)

MoltBook이 Supabase 설정 오류로 150만 개의 API 키, 35,000개 이상의 이메일, 비공개 메시지가 노출되었다. RLS(Row Level Security)가 비활성화되어 누구나 전체 DB에 접근 가능한 상태였다.

OpenClaw 에이전트의 마크다운 악성코드 문제도 있었다.
ClawHub의 인기 스킬이 마크다운 문서에 위장된 악성 링크를 포함하고 있었는데, 사람들이 마크다운 파일을 위험하다고 인식하지 않는 점을 노린 것이다. 이제는 텍스트 자체가 취약점이 될 수 있다는 사실을 인지해야 한다.

다만 두 사례는 별개의 이슈다.
MoltBook의 사례를 예시로 OpenClaw가 위험하다는 식의 의견을 종종 보았는데, 이는 맞지 않는 말이다.

MoltBook은 기업가 Matt Schlicht가 코드를 직접 보지 않고 바이브코딩으로 만든 플랫폼이고, OpenClaw의 Peter Steinberger는 전 소프트웨어 엔지니어로 코드 구조를 설계하고 리뷰한다.
OpenClaw의 악성코드 문제는 사칭 배포처에서 발생한 사건으로, 사람이 만든 소프트웨어라도 동일하게 발생할 수 있는 유형이다.
또한 OpenClaw 자체 구조상 플랫폼 내부에서 개인정보가 유출되는 문제와는 직접적인 관련이 없다. 다만 OpenClaw는 AI에게 강력한 권한을 부여하는 도구이기 때문에, 이런 문제는 자연스러운 특성에 가깝다.

어쨌든 바이브코딩의 문제점을 잘 보여주는 사례다. 개인정보를 저장하고 관리하는 곳에 바이브코딩을 적용하는 게 올바른지는 확실히 고민해 봐야 한다. Andrej Karpathy도 보안 취약점/해킹/스팸/조작 등의 이유로 사용을 비추하면서도, 대규모(15만+) 에이전트 네트워크를 만들어낸 건 흥미롭다고 평가했다.

Rust 한국 디스코드 채널의 Rust-for-Linux 관련 글 | Discord

Linux Kernel v7.0-rc1 릴리즈와 함께 Rust 지원이 확대되었고, 실제 하드웨어 디바이스 지원을 위한 기능들이 추가되었다. Linux Plumbers Conference 2025 분위기도 Rust 중심이었으며, 커널 개발 쪽에서 Rust 채택 흐름이 강해지는 상황이다. 커널 개발에 관심 있는 사람이라면 지금 Rust 기반 커널 개발 흐름에 참여하는 것도 좋다는 의견이 나왔다.

2026년, 그냥 Postgres를 쓰자 | GeekNews

대부분의 기업은 PostgreSQL 하나로 충분하다는 주장이다.

AI 에이전트 시대에는 단일 DB 환경에서 빠르게 테스트하고 디버깅하는 것이 효율적이고, 백업/모니터링/보안 전략을 단일화하여 운영 비용을 줄일 수 있다.

PostgreSQL 확장 기능으로 검색(pg_textsearch), 벡터 검색(pgvector), 시계열(TimescaleDB), 문서(JSONB) 등을 전문 프로그램과 비교하여 거의 비슷한 성능을 낼 수 있다고 주장한다.

실무에서도 그런 통계 결과가 나올지 모르겠지만, 실제 데이터 시연 결과를 보여주고 증명하는 점에서 테스트해 보고 도입해 볼 만한 것 같다.

Stop Forwarding Errors, Start Designing Them

Rust에서 더 나은 에러 처리를 위해, 기계가 처리할 정보와 사람이 읽을 정보를 분리하자는 글.

예를 들어 기계용 정보로는 ErrorKind 열거형과 ErrorStatus를 통해 처리 방법, 재시도 가능 여부 등을 명시하고, 사람용 정보로는 #[track_caller]로 호출 위치를 자동으로 기록하며, 타입 시스템으로 모듈 경계에서 문맥 추가를 강제한다.

액션베이스(Actionbase) – 좋아요, 최근 본, 팔로우를 위한 데이터베이스 | GeekNews

좋아요, 팔로우, 최근 본 항목 등 "누가 무엇을 어떻게 했다"라는 관계형 기능을 위한 카카오의 오픈소스 DB이다.
쓰기 시점에 모든 데이터를 미리 계산하고 읽기는 단순 조회만 수행하여 빠르고 예측 가능한 성능을 제공한다.
카카오톡 선물하기 위시 등 프로덕션 환경에서 분당 100만 건 이상의 요청을 처리 중이라고 한다.

회사에서 비슷한 걸 RDB로 만들어 본 적 있는데, 구현이나 유지보수가 어려웠다.
나중에 비슷한 기능을 구현하게 될 수도 있다고 생각하는데, 이 프로젝트의 코드나 원리를 뜯어보면 적용할 수 있을 것 같다.

그 외 수집한 글

작업

학습, 개발, 실험 등 직접 손댄 것들

짧은 글: AI 시대의 학습과 올바른 사용에 대한 고민

AI 시대에서의 학습 능력과 프로젝트 개발 의욕 저하

Anthropic 연구 (GeekNews)에 따르면, AI에 작업을 전적으로 맡긴 개발자들은 퀴즈에서 17% 낮은 점수를 기록했다. AI는 학습 측면에서는 그다지 도움이 되지 않을 수 있다.

"AI가 당신을 지루하게 만든다" (GeekNews)라는 글에서도 말하듯, AI 중심의 개발 방식은 금방 흥미를 잃게 만들 수 있다.

나 역시 이 의견에 동의하는데, AI를 많이 사용할수록 결과물에 대한 애착이 줄어들고 장기적으로 이해도가 떨어진다는 느낌을 받았다.

따라서 의도적으로 AI 없이 코드를 작성하고 학습하는 과정을 만들어야 한다고 생각하고 있다.

어떻게 코드를 다루어야 할까?

Node.js 메인테이너인 Matteo Collina (GeekNews)도 AI를 생산성 도구로 활용하되, 판단력과 책임은 포기하면 안 된다고 주장한다.

요즘 해커뉴스나 긱뉴스, 여러 오픈소스 커뮤니티에서 AI Slop의 남발로 인한 문제는 심심치 않게 접할 수 있다.

하지만 AI 활용이 긍정적인 사례도 분명히 있다. hwplibsharp 업스트림 관리에서는 AI가 포팅 코드를 작성하고 리뷰만으로 유지보수하는 방식을 소개한다. 이전에 본 $5짜리 프롬프트로 $2,418짜리 취약점을 찾은 사례도 좋은 영향을 주는 AI 활용 예시라고 생각한다.

이런 식으로 AI를 사용하되, 피해나 부담을 주지 않으면서 긍정적으로 활용하려는 자세가 필요한 듯하다.

AI 개발의 3가지 조합

X에서 본 글인데, 인간(의지/의도 주입) + LLM(코드 생성) + 정적분석(타입체커, 린터, 자동테스트)을 조합하는 구성이 좋다는 의견이다.
좋은 패턴이라고 생각해서 시도해 볼 계획이다.

AI와 함께 개발한다면, 혼자가 아니라 다른 사람과 협업하는 것처럼 접근해야 한다.
코드를 작성하는 주체가 여럿이므로 이런 구성을 기본으로 사용하는 게 올바르다고 생각한다.

짧은 글: Functor와 Monad가 무엇인가?

참고한 글:

정리한 핵심 개념:

  • Functor: A => B를 적용하면서 컨텍스트는 불변. 현실의 사이드이펙트나 별도 기능을 의미하는 컨테이너로 실제 값(타입)을 감싸는 것.
  • Monad: A => M[B]를 적용하면서 컨텍스트를 합성. Monad는 Functor를 포함한다.
  • Context: 계산의 성격이나 값의 추가 정보. Option(있거나 없음), List(여러 개), Future(대기 중) 등.
  • Monad의 실용적 관점: 연산 중 컨테이너를 컨테이너로 감싸는 중첩 문제를 해결하기 위한 것.
  • Monad의 함수적 관점: 숫자에 0을 더해도 값이 변하지 않듯, 어떤 컨테이너를 pure로 감싸고 다시 펴는 행위가 원래의 정보나 상태에 영향을 주지 않아야 한다.
  • Monad 종류: Option, Either, List, IO, Future, State, Reader 등. 구현을 바꾸면 패턴을 유지하면서 동작을 변경할 수 있다.

사실 하스켈 같은 순수 함수형에 가까운 언어를 사용해 본 경험이 거의 없어서, 이런 식으로 정보만 접하는 게 올바른지는 모르겠지만, 모나드에 대해서 실용적으로 적용할 수 있을 정도는 이해한 것 같다.

zsh + starship 터미널 환경 세팅

zsh + starship을 사용해 봤다.
oh-my-zsh 대신 플러그인 zsh-autosuggestions, zsh-syntax-highlighting를 설치한 기본 zsh에 적용하였다.

스타일은 oh-my-zsh보다 취향에 맞아 만족하고 있다.

참고한 자료: starship 가이드, zsh 설정 참고, dotfiles 예시

CS146S: The Modern Software Developer 강의 정리

1월에 소개했던 Stanford CS146S 강의를 주차별로 정리했다.

다만 3주차부터는 시간이 없어서 실습을 하지 못했고, 자료에 대한 요약을 훑어보기만 했다. (항상 이런 식으로 대충 마무리된다.)

노트: LLM 토큰 반복 루프 이해

LLM 공부를 하다 보니 원리가 궁금해져서 예전에 본 뉴로사마 고장 영상의 원인을 찾아보았다.

어떤 이유로 "location"의 선택 확률이 비정상적으로 높아지면, 출력된 "location"이 컨텍스트 윈도우에 누적되고, 컨텍스트에 "location"이 많을수록 다음 토큰으로 "location"을 선택할 확률이 더 높아져서 피드백 루프가 발생한다.

비달(개발자)은 뉴로(LLM 에이전트)에게 중립적인 단어를 계속 말하게 하여 컨텍스트 윈도우에서 "location"을 밀어내서 해결하였다.

짧은 생각

근황과 요즘 하는 생각

크래프톤 정글 SW 12기에 합격하였고, 참여를 위해 1년 8개월 정도 다닌 회사를 퇴사하게 되었다.
주위에서 주워들은 정보로 보면 충분히 안정적이고 성장 가능성 있는 회사라고 생각하지만, 개인적인 성장에 대한 욕심이 있어 퇴사하게 되었다.

개발용으로 사용할 노트북을 중고로 저렴하게 구했다.
배터리 상태 100%인 MacBook M1 Pro, RAM 32GB / SSD 512GB 모델을 150만 원에 구매했다.

BongoCat이라고 데스크톱에서 고양이가 마우스 위치와 타이핑을 따라하는 앱이 재미있고 귀여워 보여 설치했다.
가끔 유튜브에서 비슷한 기능을 버튜버들이 쓰는 걸 볼 수 있고, 나는 작게 우측 하단에 띄워놓으면서 쓰고 있다.