취미 부자의 개발 노트

https://huggingface.co/blog/gaussian-splatting Introduction to 3D Gaussian SplattingWe’re on a journey to advance and democratize artificial intelligence through open source and open science.huggingface.co 이 글의 결론 (3문장)3DGS는 신경망이 아니라 미분 가능한 래스터라이저다. SGD로 최적화하지만 레이어가 없고, 학습되는 것은 가우시안 파라미터 그 자체다.병목은 연산량이 아니라 수백만 개를 매 프레임 깊이순으로 정렬하는 것이다. 그래서 프로덕션 렌더링 파이프라인 이식이 막혀 있다.입문 글이 "색은 RGB 3개"라고 쓴 부분을 그대로 받으..

지금까지 AI 하네스를 RTL 업무에 어떻게 붙일 수 있는지 여러 관점에서 정리했다.RTL을 읽히기 전에 무엇을 준비해야 하는지, AI가 RTL을 어떻게 오해할 수 있는지, 검증 포인트를 어떻게 뽑을지, 버그 리포트와 수정안을 어떻게 다룰지, 그리고 작업 로그를 어떻게 남길지까지 이야기했다.마지막으로 정리하고 싶은 말은 이것이다.AI를 잘 쓰려면 프롬프트 하나를 잘 쓰는 것보다, 반복해서 쓸 수 있는 하네스를 남기는 것이 더 중요하다.프롬프트는 그 순간의 질문이다.하네스는 반복 가능한 작업 구조다.RTL 업무에서 AI가 진짜 도움이 되려면, 매번 감으로 묻는 방식에서 벗어나야 한다.무엇을 입력하고, 어떤 형식으로 받고, 무엇을 사람이 검증할지 정해져 있어야 한다.1. 좋은 프롬프트보다 좋은 구조가 오래 ..

AI를 RTL 업무에 붙여보면 꽤 놀랄 때가 있다.코드를 요약하고, 테스트 실패 로그를 정리하고, 리뷰 질문을 만들고, 수정 후보까지 제안한다.예전에는 사람이 한참 붙잡고 있던 정리 작업을 훨씬 빠르게 처리해준다.그러다 보면 자연스럽게 이런 질문이 나온다.“이러면 RTL 엔지니어의 역할이 줄어드는 거 아닌가?”내 생각은 조금 다르다.AI가 좋아질수록 RTL 엔지니어의 역할은 사라지는 것이 아니라, 더 중요한 쪽으로 이동한다.단순히 코드를 많이 읽고 많이 정리하는 능력보다, 무엇이 맞는지 판단하고 검증 기준을 세우는 능력이 더 중요해진다.1. AI는 빠르지만 책임을 지지는 않는다AI는 빠르다.긴 RTL을 요약하고, 반복되는 로그를 묶고, 테스트 후보를 만들고, 문서를 정리하는 속도는 사람이 따라가기 어렵다..

칩 개발 일정은 늘 여유롭지 않다.RTL을 작성하고, 테스트를 만들고, 실패를 보고, 수정하고, 다시 regression을 돌린다.중간중간 설계 리뷰도 해야 하고, 문서도 정리해야 하고, 다른 팀과 인터페이스 조건도 맞춰야 한다.이 흐름 안에서 AI를 쓰면 이런 기대가 생긴다.“AI를 붙이면 일정이 확 줄지 않을까?”어느 정도는 맞다.하지만 정확히 말하면 AI가 모든 일정을 줄여주는 것은 아니다.AI가 잘 줄여주는 시간은 따로 있다.바로 반복해서 읽고, 정리하고, 비교하고, 확인하는 시간이다.1. AI는 일정을 마법처럼 줄여주지 않는다AI를 도입할 때 가장 위험한 기대는 “이제 AI가 대신 해주겠지”라는 생각이다.RTL을 대신 다 짜주고, 검증 포인트를 알아서 뽑고, 버그 원인을 찾아서 고치고, 리뷰 자..

AI를 RTL 업무에 붙이면 생각보다 많은 일을 빠르게 할 수 있다.RTL 코드를 요약하게 할 수 있고, 테스트 실패 로그를 정리하게 할 수 있고, 리뷰 질문을 만들게 할 수 있다.때로는 수정 후보를 제안하게 할 수도 있다.그런데 여기서 놓치기 쉬운 문제가 하나 있다.AI와 어떤 대화를 했는지, 어떤 입력을 줬는지, 어떤 답을 받았는지, 그중 무엇을 채택했고 무엇을 버렸는지가 남아 있지 않으면 나중에 다시 파야 한다는 점이다.처음에는 빠르게 일한 것처럼 보인다.하지만 며칠 뒤 같은 이슈를 다시 보면 이런 생각이 든다.“이 판단을 왜 했지?”“AI가 말한 걸 믿은 건가, 내가 확인한 건가?”“이 테스트는 실제로 돌린 건가, 돌려야 한다고만 한 건가?”그래서 RTL 업무에서 AI를 쓸수록 작업 로그 하네스가..

이전 글에서는 RTL 버그를 AI에게 바로 맡기기보다, 먼저 AI가 읽을 수 있는 구조로 정리해야 한다고 이야기했다.그다음에 자연스럽게 따라오는 질문이 있다.“그럼 AI가 수정안까지 만들어주면, 그걸 그대로 반영해도 될까?”결론부터 말하면, 그대로 믿으면 위험하다.하지만 잘 다루면 꽤 쓸모 있다.AI가 만든 RTL 수정안은 정답이라기보다 검토할 후보에 가깝다.하네스의 역할은 그 후보를 바로 코드에 넣는 것이 아니라, 검증 가능한 변경 단위로 바꾸는 것이다.1. AI 수정안은 정답이 아니라 후보에 가깝다AI가 RTL 코드를 보고 수정안을 제안하면 꽤 그럴듯해 보일 때가 많다.조건문을 하나 추가하거나, enable 조건을 보강하거나, reset 값을 정리하거나, 특정 상태 전이 조건을 바꾸는 식이다.diff..

RTL 업무에서 AI를 쓰다 보면 한 번쯤 이런 생각을 하게 된다.“이 버그 로그를 AI에게 주면 원인을 바로 찾아주지 않을까?”가능할 때도 있다.하지만 실무에서는 이 기대를 그대로 가져가면 꽤 위험하다.RTL 버그는 에러 메시지 하나로 설명되지 않는 경우가 많다.어떤 테스트 조건이었는지, reset 이후 어느 구간이었는지, 기대한 동작과 실제 파형이 어디서 갈라졌는지까지 함께 봐야 한다.즉, AI에게 버그를 맡기기 전에 먼저 해야 할 일이 있다.버그를 AI가 읽을 수 있는 구조로 바꾸는 것이다. 1. RTL 버그는 찾는 것보다 전달하는 게 어렵다버그를 발견한 사람은 이미 많은 맥락을 알고 있다.어떤 테스트를 돌렸는지, 어느 로그가 중요해 보였는지, 어느 cycle 근처가 이상했는지, 정상 동작이라면 무..

1. 설계 리뷰는 설명회가 아니다RTL 설계 리뷰를 준비하다 보면 자연스럽게 “어떻게 잘 설명할까”에 집중하게 된다.이 블록이 어떤 역할을 하는지,어떤 신호가 들어오고 나가는지,어떤 조건에서 동작하는지,변경된 부분이 무엇인지 정리한다.물론 설명은 중요하다.하지만 설계 리뷰의 목적은 단순히 설명을 잘하는 것이 아니다.더 중요한 것은 리뷰 전에 중요한 질문을 놓치지 않는 것이다.무엇이 바뀌었는가.어디까지 영향이 있는가.어떤 조건에서 깨질 수 있는가.검증은 어디까지 되어 있는가.결정이 필요한 부분은 무엇인가.AI는 이 준비 과정을 줄이는 데 꽤 유용하다.2. AI에게 “리뷰 자료 만들어줘”라고만 하면 부족하다AI에게 이렇게 요청할 수 있다.이 RTL 코드 보고 리뷰 자료 만들어줘.그러면 AI는 아마 구조 요약..

1. 검증 포인트는 그냥 많이 뽑는다고 좋은 게 아니다RTL 검증을 하다 보면 검증 포인트를 많이 뽑는 것 자체가 목표처럼 보일 때가 있다.normal case.corner case.reset case.stall case.overflow case.invalid input case.이렇게 항목을 많이 나열하면 뭔가 촘촘해 보인다.하지만 좋은 검증 포인트는 단순히 항목 수가 많은 것이 아니다.정말 중요한 것은 어떤 조건이 틀리면 어떤 방식으로 관찰할 수 있는가까지 연결하는 것이다.AI는 검증 포인트 후보를 빠르게 많이 뽑는 데 강하다.하지만 그 후보가 실제 RTL과 spec에 맞는지는 엔지니어가 판단해야 한다.그래서 AI를 검증 포인트 생성기로만 쓰기보다, 조건을 분류하고 질문으로 바꾸는 보조자로 쓰는 편이..

1. AI의 RTL 분석은 꽤 그럴듯하다AI에게 RTL 코드를 보여주면 생각보다 잘 읽는다.module 구조를 요약하고,signal 이름을 보고 역할을 추정하고,FSM이나 counter를 찾아내고,검증해야 할 항목도 어느 정도 뽑아준다.그래서 처음에는 꽤 놀랍다.하지만 RTL 업무에서는 여기서 조심해야 한다.AI가 그럴듯하게 말하는 것과 실제 동작이 맞는 것은 다르다.특히 RTL은 작은 조건 하나로 동작이 바뀐다.reset 우선순위, stall 시 register 유지 여부, valid-ready handshake, counter update 조건, boundary case 같은 것들은 문장으로 대충 설명하면 위험하다.AI의 RTL 분석을 그대로 믿기보다, 어떤 지점에서 오해가 생기는지 알고 있어야 한다..