24b0d121e09c28a8699fe8b115ef0468e3aee9bc63




24b0d121e09c28a8699fe8b115ef046c68f22a479d




아마 Zeno를 안 뜯어본 거 같은데

Zeno안에는 다음과 같은 src가 5개 있다.




24b0d121e09c28a8699fe8b115ef046c60f12b479a



24b0d121e09c28a8699fe8b115ef046ec241cefe



24b0d121e09c28a8699fe8b115ef0468e6a9e9ba



여기서 런타임과 컴파일러가 제일 중요하고

나머지 셋은 걍 성격상 분리가 필요했거나 벤치마크용임


근데 3개 안 빼고 5개 전부 다 합쳐서 계산해도


코드 전체 총량이 겨우


5,151줄


이다



참고로 저번에 내가 보여줬던 EMP아키텍쳐로 개발된 내 홈페이지 core 프로젝트는

docs/ 런 거 다 빼고 직접 작성한 코드만 집계해도


1.7만 줄이 나온다.



24b0d121e09c28a8699fe8b115ef046c60f42c469a



참고로 내가 제일 적게 수행한 일이 홈페이지 개발이다.


아래는 에이전트에게 시켜서 집계 명령어 돌린 결과



24b0d121e09c28a8699fe8b115ef0464d184e5ce




그리고 이 밑은 내가 좋아하고 자주 참고하는 울트라리틱스의 코드 수다




24b0d121e09c28a8699fe8b115ef046c64f02b4d9c



보이다시피 5.7만 줄이다.


울트라리틱스나 Langchain 같이 제법 큰 프레임워크도 필요한 부분을 고쳐쓰거나,

기능 부족할 때마다 코드 리뷰하고 직접 고쳐서 쓰는 게 일상다반사다.

레딧이나 이런데 검색하면 그렇게 작업 중인 사람들이 수두룩하게 검색된다.


예를 들어 울트라리틱스는 본래 yolov8의 p0를 지원하지 않는데,

나 포함 중국 쪽 드론계열 연구자들 중에는 항공샷 연구해야돼서

울트라리틱스를 p0로 개조한 사람들이 자주 눈에 띈다.

심지어 울트라리틱스는 트랜스포머를 안쓰는데 라이브러리 고쳐서 Bi 트랜스포머 붙인 연구도 자주 봤다.


즉, 라이브러리를 고치는 건 매우 자주 일어나는 일임.

그러려면 일단 읽어보고 리뷰를 해야 고칠 수 있겠지?


5.7만줄짜리 라이브러리도 그렇게 하는데

고작 Zeno 사이즈를 리뷰 못하면 개발을 어캐 하겠냐?



만약 리뷰 못해서 직접 개발한다고 치자.


일단 보낼사람 받을 사람이 따로 있으니깐 프로토콜을 확정하고 진행해야겠지?

그러려면 너보다 높은 급이거나, 실력이 월등히 떨어지거나, 혹은 성격이 개차반인 개발자를 최소 2명, 많으면 3명까지 테이블로 모아야한다.


모으기 위해서 전화기를 들었다고쳐.


언제 모일 건데? 내일 모일 거야? 사람들이 전주나 울산에 살면 어쩔 건데?

밥은 누가 살 건데? 멀리서 불렀는데 더치페이할 거야? 니가 불렀는데 나이 많은 사람에게 밥 사달라고 할 거야?


뭐 어찌어찌해서 회의실에 앉았다고 치자.

니가 프로토콜 정할 거야? 니가 프로젝트 요구사항을 다 파악하고 있어? 의견들을 다 들어봐야겠지?

근데 의견이 상충되면 어떡하냐? A랑 B가 싸울 수도 있겠지? 니가 그걸 중재할 수 있어?


어찌저찌 건설적으로 토론이 끝났다고 치자. 요구사항 다 파악하면 네가 그 자리에서 바로 프로토콜 확정할 수 있냐?

니가 니 맘대로 확정했다가 나중에 수정사항 생기면 어쩔 거야?

사람들에게 전화돌려서 프로토콜 변경됐다고 통보할 거임?

너보다 급 높고 성격 드럽고 말귀도 못알아먹는 사람들에게 각각?

아니면 니가 찐빠냈으니까 다시 모이자고 할래? 전주에서 다시 올라오라고?


상상만해도 좆같은 게 한 두개가 아니잖아

심지어 이거 다 통과해서 라이브러리 개발하고 나면


이제 프로젝트를 위해서 위의 과정들을 1순 더 거쳐야함.

이 얼마나 끔찍한 일이야?


그러느니 걍 5천 줄짜리 각자 읽고 Zeno쓰자는 거임


사실 다 읽을 필요도 없지

리드미 읽고 튜토리얼 따라서 하면 그만이니깐

실상 제대로 읽을 코드 분량은 1, 2천 줄 내외에 불과함



글고 바이너리 프로젝션 컴파일러 질문은 내가 당시에 못봤었는데 (졸려서)


걍 지금 설명해주겠음


바이너리 <-- 데이터를 이진수로 보겠다

프로젝션 <-- 새 객체 안만들겠다

컴파일러 <-- 코드 생성기다


걍 이렇게 말한 건데 니가 이해를 못한 거는

이 단어가 flatbuffers 과의 차이점을 강조하기 위해 조합한 단어들이라 그럼.


이것도 설명해줄게.


flatbuffers는 바이너리가 아니라 table로 프로젝션을 함.

참고로 프로젝션이란 개념은 flatbuffers얘네가 먼저 사용한 개념임.

카피를 하지 않고(zero copy) 걍 오프셋의 위치를 기반으로 view만 하는 게 flatbuffers의 핵심이라고 했잖아?

이때 오프셋 기반 view를 프로젝션(투영)이라고 한 거임


그리고 얘넨 이걸 위해 .fbs란 자기만의 언어(확장자)를 사용하고 있는데,

Zeno는 이게 없음.


그럼 어떻게 프로젝션을 하느냐? 여기서 컴파일러란 개념이 나오는 거임.

컴파일러가 뭐야? A 코드를 B코드로 번역해주는 프로그램잖아?


Zeno의 컴파일러는 zeno-codegen고

이 컴파일러는 내부의 ts파일을 읽은 뒤 그걸 데이터뷰 클래스로 번역하는 일을 해준다.


즉...


1. table 프로젝션이 아니라 바이너리 프로젝션임.

2. zeno-codegen으로 데이터뷰를 위한 코드들을 생성하기 때문에 컴파일러임.


이래서 'Zeno = 바이너리 프로젝션 컴파일러'란 말이 나온 거임


물론 이 조어 자체가 좀 어색하긴 해.

근데 ㅆㅇㅆ가 원래 말 잘하는 인간이 아니라는 점을 생각하고 곰곰히 유추해보면

쉽게 파악할 수 있음.


이제 너도 이해했지??

이해했으면 잘자콘 달아줘




60