LLM이 Rust·Zig와 저수준 기술 진입 장벽을 낮추지만, HN은 검토와 암호 전문성은 남는다고 봄

에이전트 코딩이 프레임워크, 데이터베이스, 운영체제, 게임 엔진처럼 예전엔 규모나 난도로 엄두 못 내던 걸 시도하게 만드는 건 맞다고 봄.

내 경우 에이전트에게 통째로 맡기기보다는 채팅 추론을 쓰는 편이 훨씬 유용했음. 2년 넘게 만든 큰 앱을 몇 달 만에 전면 재작성했는데 ChatGPT Plus 월 $20가 대부분을 도왔고, 막판엔 Pro 월 $100도 썼음. 그래도 매 단계 내가 밀착 검토하고 관리해야 했지.

날씨 앱을 한 페이지에 스크롤 없이 보여 달라고 Anti-gravity에 시켰더니 30분 만에 만들었음. 그런데 Codex로 검토하니 절반은 작동하지 않았고 풍속 돌풍 데이터를 지어내고 시간별 데이터와 캐시도 망가뜨렸더라. 고쳤다고는 하는데 정말 고쳤는지는 모르겠음.

그게 학습 데이터를 다시 표현하는 것뿐이라면 정말 내가 만든 건지, 라이선스 세탁인지 모르겠음.

게임 엔진이나 커널, 데이터베이스를 직접 만드는 일은 AI 이전에도 책을 따라 배우는 강좌와 오픈소스 구현이 많았음. AI가 이 흐름을 부추겼을 수는 있어도 전부 AI 탓은 아님.

LLM이 코드를 잘 쪼개 내도 오래 변화할 시스템이라면 개발자가 언어와 도메인을 알아야 함. Effect.ts를 몇 주 공부하며 조합성, 문법, 깨지는 지점을 직접 겪고 나서야 LLM 결과를 제대로 쓸 수 있었음. 안 그랬으면 시간이 지나 피드백을 받는 시스템은 취약해졌을 것 같음.

암호를 잘 모르는 나도 '커스텀 암호'라는 말은 무서움.

프런티어 모델이 암호 기능을 만들면 중앙값 인간 개발자보다 나은 기록을 낼 가능성은 인정함. 암호 구현 실패는 대개 지식 부족에서 나오고, 모델은 세부 지식을 많이 알고 있으니까. 그래도 구현 1달러당 검증에 10달러를 쓰는 식의 스트레스 테스트가 가장 중요함.

고위험 암호 코드를 다뤄 봤는데, 안전하게 만들거나 기존 코드의 안전성을 판정하려면 코드 양과 다른 수준의 지식, 신중함, 보수성이 필요함. 학생들을 가르친 건 게이트키핑이 아니었고, 실제로 이를 해낼 사람은 극히 적었음. 검증 비용을 낮추는 AI는 쓰되 프로덕션 암호 작업을 AI 코딩에 맡기면 안 됨.

'언어를 익힐 필요가 없다'는 전제에는 동의 못 함. 에이전트 결과를 검토하고 커밋 여부를 판단하려면 최소한 언어를 따라갈 정도는 알아야 함. 나는 이제 숙련을 목표로 한두 언어만 파기보다 Haskell의 함수형, Elixir의 동시성처럼 각 언어의 패러다임을 빠르게 읽어 익히는 식으로 바뀌었음.

LLM 성능은 해당 주제의 공개 데이터 양으로 꽤 예측 가능하다고 봄. 수학, 알고리즘, C 바인딩은 선행 사례가 많아 잘하지만 최신 언어 기능은 자료가 적어서 못함. UI 설계를 못하는 이유는 나도 모르겠음.