[월간 기록] 2026년 5월

Pintos와 신경망 공부, AI와 책임감

Pintos 주차를 마무리하고

수집

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

Nobody's job, everybody's problem: F/OSS in the age of AI

Fedify 메인테이너로 유명한 홍민희님이 KAIST에서 발표한 자료. X를 통해 알게 되었다.

내용이 좋아서 주기적으로 참고해볼 듯 하다. 다음과 같이 요약할 수 있다.

"오픈소스는 공공 인프라지만 책임과 비용은 소수에게 몰려 있다. AI 시대에는 이 문제가 더 커지므로, 오픈소스 참여자는 이해/신뢰/책임/지속 가능성을 중심에 둬야 한다.".

짦은 글: AI 의존에 대한 문제

특히 AI 의존에 대한 고민을 정리하는 데 도움이 되었는데, 오픈소스 뿐만 아니라 팀 프로젝트에서도 적용된다고 생각한다.

발표에서는 이론 형성으로서의 프로그래밍을 이야기하는데, 여기서 코드 작성은 프로젝트에 대한 이론을 만들고 공유하는 활동이다.

이 이론에 대한 이해는 문서에 완전히 담길 수 없고, 사람들 사이에 축적된다. 이 사람들이 없다면 결국 동일한 요구사항을 만들더라도 다른 결과물(이론, 코드)이 나올 수 있다.

오픈소스는 이러한 이론을 특정 조직 내부에 가두지 않고, 널리 퍼트려 장기적으로 유지하는것에 가치가 있다.

따라서 오픈소스에 기여한다는 것은 코드의 의도와 동작을 이해하고, 그 영향까지 설명할 수 있어야 한다.

하지만 AI에 의존한 작업물은 사람들 간의 관계 혹은 이해가 발생하지 않기 때문에, 이론 형성에 도움이 되지 않고, 잘못된 코드가 들어옮으로써 더 큰 문제를 만들어낸다.

이때 검토와 책임의 비용은 코드를 제출한 사람이 아니라, 그 코드를 받아들이고 유지해야할 기존 참여자에게 전가된다. 이는 생산성 저하와 의욕 하락 등의 문제로 퍼질 수 있다.

즉, AI로 적절한 이해 없이 코드를 제출하는 것은 책임감에 대한 문제이다. 또한 이러한 것을 적절하게 예방하지 않는 조직의 문제로도 볼 수 있다.

Shopify, 재고 예약 시스템을 Redis에서 MySQL로 교체 | GeekNews

백엔드 질문 등에서 흔하게 보이는 재고 관리/티켓 동시성 문제를 SKIP LOCKED을 사용해 풀어낸 경험 소개.

일반적으로 DB Lock은 느려서 Redis를 사용한다고 알고 있는데, Redis 없이도 고성능 처리를 달성했다는 점에서 인상깊었다.

개인적으로 기존 기술로 대체 가능하다면 신규 기술을 도입하는 것을 좋아하지 않는 편이라, 필요하다면 해당 방법을 써볼지도 모르겠다.

다만 안전성은 더 좋지만 복잡도 자체는 Redis보다 더 높을 수 있어보인다.

수백만 줄의 Haskell: Mercury의 프로덕션 엔지니어링 | GeekNews

Haskell은 매우 엄격한 함수형 언어로 알고 있는데, 이러한 제약이 있는 언어를 큰 프로덕션에서 사용한다는게 신기했다.

특히 서버 위주의 코드인 듯 한데, 코드베이스를 안정적으로 잘 운영하기 위한 철학이 인상깊었다.

결국 나쁜 코드를 작성하지 않게 강제하는 것들인데, 범용적으로 채택 가능한 원칙들이 많았다.

  1. 도메인 에러와 전송 계층(HTTP/worker) 에러를 분리
  2. 중요한 상태는 상태 전이 타입화를 사용
    • 특정 순서로 함수 호출이 되어야 하는 경우, 입력 값과 결과를 타입으로 만들어 처리를 강제
    • 단, 변경에 취약해지므로, 중요한 부분만
    • User -> ValidatedUser -> LoggedInUser -> AccessControlledUser
    • RawInput -> ParsedInput -> VerifiedInput
  3. 외부 시스템과 닿는 클라이언트는 tracing/logging/injection이 가능하도록 인터페이스나 미들웨어 형태로 설계하기
  4. 위험한 내부 동작은 좁은 인터페이스 뒤에 숨기기

AI 활용법

기술 문서 작성

그 외 수집한 글

작업

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

짦은 글: AI 피로감에 대한 고민

요즘 기술 커뮤니티를 보면 AI로 인해서 특정 기술에 대한 이해/전문성 없이도 참여가 가능해저 버렸고, 이로 인해서 Slop, AI의 말을 그대로 사용하는 등 피로감을 많이 겪는 문제가 보인다.

팀 프로젝트를 앞선 지금 많은 고민이 된다.

크래프톤 정글에선 수요코딩회라는 하루동안 AI를 사용해 특정 주제의 프로젝트를 만드는 활동이 있었는데, 관련 글의 상황처럼 피로감을 유발하는 상황이 많았다.

지금 프로젝트처럼 제어 가능한 규모일 때는 그렇다 쳐도, 만약 회사 전체가 이런 분위기라면 어떻게 대응해야 할까.

짧은 글: 여전히 코드는 중요하다

나는 여전히 코드가 중요하다고 생각한다. SDD(Spec Driven Development)나 바이브 코딩처럼 코드를 보지 않는 방식은 유지 불가능하다고 생각하다.

AI는 결국 인간의 텍스트에서 학습하고, 인간처럼 문맥을 파악한다. (물론 동일하진 않을 것이다.)

그리고 실제 실행의 근원은 코드다. AI가 문서를 읽고 맥락을 이해하더라도, 최종적으로는 코드를 읽고 수정해야 한다.
모든 코드와 이전 맥락을 완전히 알 수는 없기 때문에 의도와 다른 코드가 생길 수밖에 없다. 그리고 우리는 이걸 버그라고 부른다.

그래서 인간과 AI 모두에게 좋은 코드를 작성하는 일이 중요하다.

문서화, 코드 분리, 추상화, 테스트 코드, 자동화 같은 것들이 더 필요해진다.
오히려 AI는 이런 어렵고 반복적인 품질 개선 작업에 잘 활용될 수 있다고 생각한다.

다만 인터넷의 자료들을 보면, 실제 품질 개선보다는 저품질의 Slop을 빠르게 만드는 방법만 늘어나는 것 같아 걱정된다.

물론 내가 지금 부트캠프를 다니며 실무와 조금 멀어진 상태라 그렇게 느끼는 것일 수도 있다. 나에게도 자주 보이는 자료라면, 이는 실제 제품 개발보다는 개발자가 아닌 사람들을 위한 동작만 하면 되는 편리한 무언가를 만드는 용도에 더 가까울지도 모른다.

그렇게 보면 내가 너무 걱정하는 것일 수도 있다.

Jungle Bell 유지보수

Jungle Bell은 정글 출석체크 알림용 트레이 앱이다.

몇 주간의 신규 개발을 마무리하고, 유지보수 단계로 전환했다.

Jungle SW-AI Lab 활동

10주차

11~12주차

13~14주차

xv6를 사용한 프로젝트 학습

  • 프로젝트: xv6-riscv-study
    • Pintos 이후 운영체제 공부를 이어가기 위해 xv6 강의와 코드를 정리하는 저장소를 만들었다.