목록으로
업무 생산성 개선을 위한 AI 활용
Ust
범국가적 지능·정보 네트워크
🤖 활용 AI 도구
Claude Code
# Ust
"Rust" 프로그래밍 언어는, 미리 정의되지 않은 동작을 원천 차단할 수 있다는 특징이 있다. 그 아이디어를 OS의 층위에도 적용한다면, 하드웨어가 절대적으로 보장하는 권한 규칙만 남김으로써, 대다수의 보안, 성능 문제 상황을 제거할 수 있다.
Rust만 해도, 이미 안전하고 범용적이고 성능 좋은 언어다. 데스크톱, 대형 서버, 웹, 게임 등 모든 디지털 세상의 프로그램들이 Rust로 빠르게 교체되고 있다. 하지만, 컴퓨터에서 한 언어만 허용한다는 것은, "교체"와 전혀 다른 의미이다.
일단은, "Ust"라고 부르겠다. Ust 시스템은, 기존 모든 앱과 파일들의 완전한 대체, OS 개념의 대격변을 필요로 한다. 결국 그렇게, OS, 에디터, LLM 하네스, 뭐든지 Ust 언어만으로 다루게 될 수 있게 된다. 그런 OS라면, OS 자체를 Ust라 할 수 있다.
Ust 시스템이 범용 OS로 작동하려면, 조건이 더 필요하다. 쉽게 말하면, Ust 언어와 Ust OS가 필요하다. 전용 하드웨어를 따로 만들거나, 부품을 바꿀 필요는 없다. 어렵게 말하면, 요청에 해당하는 privilege level(U/S 비트가 0이냐 1이냐)에 대해, CPU가 지금처럼 정상적으로 처리한다는 전제로, Rust에서 대다수의 unsafe와 라이브러리를 금지하고, 추상화를 단순화한 Ust 언어를 만들고, 모든 파일에 type, 바이너리에 signature 개념을 적용해서 IPC를 원본을 넘기거나 빌려주는 것으로 대체하고, 그런 기능을 최적화하는 컴파일러와 그것의 무결성이 필요하다.
Ust 시스템은, CPU가 강제하는 메모리 주소 공간 분리를 이용한다. 모든 컴퓨터의 프로그램은, RAM의 양분된 주소 공간 중 하나에 나눠져 올라가고, 한 쪽에 올라간 프로그램이 일방적으로 다른 쪽에 올라간 프로그램을 바꿀 수 있다. Ust 시스템은 이 두 공간 중 바꿀 수 있는 쪽에 OS 프로그램 및 사용자(User) 관련 정보를 올려두고, 바꿀 수 없는 쪽에 모든 앱 프로그램을 가두고, 각각을 "사용자 공간", "앱 공간"으로 부른다.
Ust 시스템에서 모든 형태의 정보는, 폴더와 파일 2분법이다. 사용자가 네트워크로 주고받고 있는 것도 폴더 또는 파일이고, 그것은 RAM이나 디스크에 폴더 또는 파일이 되며, 사용자가 체감하는 "권한"은, 단순히 이런 폴더와 파일의 중첩(경로)이다.
Ust 파일은 읽거나 쓰기를 위해 존재한다. 사용자가 "직접" "쓴" 파일은, 당연히 사용자의 "사용자 공간"에 올려지겠지만, "앱 공간"에 올려져 있는 "파일"은, 예를 들어, 다른 사용자의 소유일 수도 있다. 파일의 저작자는 읽기만 허용할 수도 있고, 그 파일의 수명을 설정할 수도 있고, 네트워크에 연결됐을 때만 읽을 수 있게 하여, 최신 버전만 보게 할 수 있다.
하지만, 위에서 설명했듯, 이런 Ust의 시스템이 작동하는데 필요한 것은 Ust 언어와 Ust OS뿐이다. 따라서, 이 기능은 Ust 브라우저, Ust 텍스트 뷰어 등 "특정" Ust 앱에 의한 것이 아니다.
하지만, 방금 설명했듯, 모든 정보는 파일과 폴더일 뿐이다. 따라서, 권한이 있는 모든 파일을 담을 수 있는 임의의 "프로그램"이 "Ust 폴더"이고, "Ust OS"가 바로, 모든 다른 파일이나 폴더를 담는 하나의 Ust 폴더이자, 파일에 대한 접근을 관리하는 운영체제이다.
하지만, 그 전에 설명했듯, OS는 "사용자" 공간에 있다. 사용자가 컴퓨터를 점유하고, OS를 실행시킬 권한이 있다는 의미라면, 뭔가 말이 되는 것 같기도 하지만, 그러고 나서 어떠한 파일에 대해서도 읽거나 쓰는 작업을 하지 않는 사람도 많다. 모든 사람들이 "폴더" 개발자도 아니고, 컴퓨터에 "파일"을 넣어두고 읽는 것을 싫어하는 사람도 많다. Ust OS를 쓰더라도, 누군가의 글과 앱만을 사용하며, 그렇게 자기 소유 파일 하나 없이, "사용자 공간"을 "사용" 하지 못할 수 있는 것이다.
여기서, 아직 말을 안 한 것은, Ust OS뿐만 아니라 Ust 언어 자체도 모든 사람들이 쓸 만큼 쉬울 수 있다는 것이다. 직전까지 설명한, 파일에 "수정 가능", "네트워크가 연결됐을 때 읽기만" 등의 성질을 미리 결정해두었다면, 나중에 "지금은 수정할 수 없음" "지금은 읽어도 됨" 등의 실시간 행동 규칙으로 적용되는 것은, Rust 언어로 쓰인 프로그램이 정의되지 않은 동작을 원천 차단하는 방식 그 자체이다.
## 언어
Rust 언어의 "동작을 미리 결정해야 한다"는 규칙은, Rust 언어의 단점이나 제약이 되지 않는다. 오히려 다른 모든 언어를 사용하는 프로그래머도 직간접적으로 이미 지키고 있는 것이고, 못 지켰을 때는 "예상하지 못한 버그"가 발생하게 된다. Rust의 규칙은 다른 언어에서는 "절대 규칙"이 아니고, 명시적이지도 않다. 다른 언어는, 코드가 길어질수록, 그만큼 복잡해지는 동작 결정 "관습"을 생각하기 힘들어지고, 이런 "관습"만을 생각하면서 코드를 짤 수도 없다. Rust는, 이런 종류의 "예상하지 못한 버그"가 발생하는 모든 경우는, 알고 보니 컴퓨터 언어의 문법을 바꾸면 제거할 수 있었다는 것을 깨달았던 것이다.
말 그대로다. Rust 언어의 문법과 규칙은, 프로그램의 동작을 미리 결정되게 한다. 예를 들어, 어떤 정보를 "수정할 수 있다"는 코드와, "수정했다"는 코드 사이에는, 그 정보를 "읽는다"는 코드를 쓸 수 없다. 정보가 수정될 수 있는 순간에는, 그 정보가 불완전한 상태일 수 있기 때문이다. 규칙을 모두 지켜낸 경우에만, 코드 파일은 실행 파일로 바뀐다. 그것은 누군가의 컴퓨터에 저장되어, 원할 때마다 실행할 수 있는 형태다. 여기서 "실행"은, 항상, RAM(기억 장치)과 CPU(계산 장치)의 합작이다.
이 때, 코드 파일을 작성하는 개발자의 관점은 이거다: 실행 파일이 나중에 누군가의 컴퓨터에서 실행될 때를 대비하여, RAM 어딘가에 들어갈 수도 있는 모든 "정보"에 대해, 코드 파일에서만큼은, 자신이 구분하기 쉬운 "이름"을 붙여두고, 이름에 묶이는 정보가 CPU에 의해 어떻게 다뤄져야만 하는지를, "이름"과 이름 또는 정보의 "성질"로 미리 결정하는 것이다.
예를 들어, `let mut 한글: String = "가나다"`라는 Rust 코드에서 "한글"이 이름, (가나다)는 나중에 정보가 될 수도 있는 무언가, 이름 왼쪽의 `mut`과 오른쪽의 `String`이 "한글"이라는 이름에 고정되는 성질이다. 해석해보면 대충 이런 뜻이다: 나중에 수정당할 수 있는 "한글"은 문자열(String) 성질이고, 적어도 바로 다음 줄에서는, "한글" 안에 (가나다)라는 정보가 묶여 있다고 가정한다.
코드 파일이 실행 파일로 바뀔 때, 개발자가 붙여둔 "이름"과 "성질"은 전부 없어지고, 결국 실행 파일 안에는 정보가 될지도 모르는 것(가나다)만 남게 된다. 하지만, 적어도 Ust에서는, 이것이 "개발자에게도 정보가 중요하다"는 뜻이 되지는 않는다. 왜냐하면, 개발자의 목적은 항상 "이름"으로 표현되고, 정보가 될지도 모르는 것에도, 항상 이름을 붙여서 다룰 수밖에 없으며, 이름에 고정되는 성질의 규칙을 모든 코드에서 지켜야만, 동작을 미리 결정할 수 있기 때문이다. 따라서, 개발자가 집중해야 하는 것은, 언젠가 누군가의 RAM 위의 "정보"가 아니라, 코드 파일에 자기가 쓴 "이름"이다.
Rust가 이룬 것은, 이름이나 정보에 대한 규칙을 각각 정하고, 그것들의 성질을 특정 특수 문자나 단어로 정해두고, 이름 왼쪽이나 오른쪽을 각각 "이름의 성질 자리", "정보의 성질 자리"로 만들고, 동작이 끝나 쓸모없어질 정보의 정리를 자동화하고, 설령 개발자가 실수해도 실행 파일이 절대 만들어지지 못하게 하고, 결국 완성된 실행 파일은 더할 나위 없는 성능을 낼 수 있도록 설계했다는 것이다.
위업이라 칭할 만하지만, Rust에서는, 용어들을 더 일반화해내지는 못했다. Rust의 공식 교과서나, 코드 파일의 문법은, "동작을 미리 결정한다"를 좀 길게, 잘게 나눠서 설명한다. "정보는 이름과 떨어질 수 없다"와 "이름의 성질은 바뀌지 않는다"까지 정해놨으면서, 왜 성질 자리를 나눠놓았는가? 코드 안에 있을 수 없는 정보를 왜 생각하게 하는가? 그렇게 나눠버리면, 인간의 집중력으로는, "이름"과 "정보"를 둘 다 놓치게 된다.
...아마 "정보"를 생각할 수밖에 없는 기존 언어의 문법과 용어사용을 그대로 참고하면서 Rust를 만들다 보니 이렇게 된 것 같다. Ust 언어는, 바꾸는 김에 싹 다 바꾼다. Rust의 핵심 아이디어를 보전하면서, 용어 사용 방식을 "이름" 중심으로 하고(지금까지처럼), 특수문자 사용법도 바꾼다.
"Rust" 프로그래밍 언어는, 미리 정의되지 않은 동작을 원천 차단할 수 있다는 특징이 있다. 그 아이디어를 OS의 층위에도 적용한다면, 하드웨어가 절대적으로 보장하는 권한 규칙만 남김으로써, 대다수의 보안, 성능 문제 상황을 제거할 수 있다.
Rust만 해도, 이미 안전하고 범용적이고 성능 좋은 언어다. 데스크톱, 대형 서버, 웹, 게임 등 모든 디지털 세상의 프로그램들이 Rust로 빠르게 교체되고 있다. 하지만, 컴퓨터에서 한 언어만 허용한다는 것은, "교체"와 전혀 다른 의미이다.
일단은, "Ust"라고 부르겠다. Ust 시스템은, 기존 모든 앱과 파일들의 완전한 대체, OS 개념의 대격변을 필요로 한다. 결국 그렇게, OS, 에디터, LLM 하네스, 뭐든지 Ust 언어만으로 다루게 될 수 있게 된다. 그런 OS라면, OS 자체를 Ust라 할 수 있다.
Ust 시스템이 범용 OS로 작동하려면, 조건이 더 필요하다. 쉽게 말하면, Ust 언어와 Ust OS가 필요하다. 전용 하드웨어를 따로 만들거나, 부품을 바꿀 필요는 없다. 어렵게 말하면, 요청에 해당하는 privilege level(U/S 비트가 0이냐 1이냐)에 대해, CPU가 지금처럼 정상적으로 처리한다는 전제로, Rust에서 대다수의 unsafe와 라이브러리를 금지하고, 추상화를 단순화한 Ust 언어를 만들고, 모든 파일에 type, 바이너리에 signature 개념을 적용해서 IPC를 원본을 넘기거나 빌려주는 것으로 대체하고, 그런 기능을 최적화하는 컴파일러와 그것의 무결성이 필요하다.
Ust 시스템은, CPU가 강제하는 메모리 주소 공간 분리를 이용한다. 모든 컴퓨터의 프로그램은, RAM의 양분된 주소 공간 중 하나에 나눠져 올라가고, 한 쪽에 올라간 프로그램이 일방적으로 다른 쪽에 올라간 프로그램을 바꿀 수 있다. Ust 시스템은 이 두 공간 중 바꿀 수 있는 쪽에 OS 프로그램 및 사용자(User) 관련 정보를 올려두고, 바꿀 수 없는 쪽에 모든 앱 프로그램을 가두고, 각각을 "사용자 공간", "앱 공간"으로 부른다.
Ust 시스템에서 모든 형태의 정보는, 폴더와 파일 2분법이다. 사용자가 네트워크로 주고받고 있는 것도 폴더 또는 파일이고, 그것은 RAM이나 디스크에 폴더 또는 파일이 되며, 사용자가 체감하는 "권한"은, 단순히 이런 폴더와 파일의 중첩(경로)이다.
Ust 파일은 읽거나 쓰기를 위해 존재한다. 사용자가 "직접" "쓴" 파일은, 당연히 사용자의 "사용자 공간"에 올려지겠지만, "앱 공간"에 올려져 있는 "파일"은, 예를 들어, 다른 사용자의 소유일 수도 있다. 파일의 저작자는 읽기만 허용할 수도 있고, 그 파일의 수명을 설정할 수도 있고, 네트워크에 연결됐을 때만 읽을 수 있게 하여, 최신 버전만 보게 할 수 있다.
하지만, 위에서 설명했듯, 이런 Ust의 시스템이 작동하는데 필요한 것은 Ust 언어와 Ust OS뿐이다. 따라서, 이 기능은 Ust 브라우저, Ust 텍스트 뷰어 등 "특정" Ust 앱에 의한 것이 아니다.
하지만, 방금 설명했듯, 모든 정보는 파일과 폴더일 뿐이다. 따라서, 권한이 있는 모든 파일을 담을 수 있는 임의의 "프로그램"이 "Ust 폴더"이고, "Ust OS"가 바로, 모든 다른 파일이나 폴더를 담는 하나의 Ust 폴더이자, 파일에 대한 접근을 관리하는 운영체제이다.
하지만, 그 전에 설명했듯, OS는 "사용자" 공간에 있다. 사용자가 컴퓨터를 점유하고, OS를 실행시킬 권한이 있다는 의미라면, 뭔가 말이 되는 것 같기도 하지만, 그러고 나서 어떠한 파일에 대해서도 읽거나 쓰는 작업을 하지 않는 사람도 많다. 모든 사람들이 "폴더" 개발자도 아니고, 컴퓨터에 "파일"을 넣어두고 읽는 것을 싫어하는 사람도 많다. Ust OS를 쓰더라도, 누군가의 글과 앱만을 사용하며, 그렇게 자기 소유 파일 하나 없이, "사용자 공간"을 "사용" 하지 못할 수 있는 것이다.
여기서, 아직 말을 안 한 것은, Ust OS뿐만 아니라 Ust 언어 자체도 모든 사람들이 쓸 만큼 쉬울 수 있다는 것이다. 직전까지 설명한, 파일에 "수정 가능", "네트워크가 연결됐을 때 읽기만" 등의 성질을 미리 결정해두었다면, 나중에 "지금은 수정할 수 없음" "지금은 읽어도 됨" 등의 실시간 행동 규칙으로 적용되는 것은, Rust 언어로 쓰인 프로그램이 정의되지 않은 동작을 원천 차단하는 방식 그 자체이다.
## 언어
Rust 언어의 "동작을 미리 결정해야 한다"는 규칙은, Rust 언어의 단점이나 제약이 되지 않는다. 오히려 다른 모든 언어를 사용하는 프로그래머도 직간접적으로 이미 지키고 있는 것이고, 못 지켰을 때는 "예상하지 못한 버그"가 발생하게 된다. Rust의 규칙은 다른 언어에서는 "절대 규칙"이 아니고, 명시적이지도 않다. 다른 언어는, 코드가 길어질수록, 그만큼 복잡해지는 동작 결정 "관습"을 생각하기 힘들어지고, 이런 "관습"만을 생각하면서 코드를 짤 수도 없다. Rust는, 이런 종류의 "예상하지 못한 버그"가 발생하는 모든 경우는, 알고 보니 컴퓨터 언어의 문법을 바꾸면 제거할 수 있었다는 것을 깨달았던 것이다.
말 그대로다. Rust 언어의 문법과 규칙은, 프로그램의 동작을 미리 결정되게 한다. 예를 들어, 어떤 정보를 "수정할 수 있다"는 코드와, "수정했다"는 코드 사이에는, 그 정보를 "읽는다"는 코드를 쓸 수 없다. 정보가 수정될 수 있는 순간에는, 그 정보가 불완전한 상태일 수 있기 때문이다. 규칙을 모두 지켜낸 경우에만, 코드 파일은 실행 파일로 바뀐다. 그것은 누군가의 컴퓨터에 저장되어, 원할 때마다 실행할 수 있는 형태다. 여기서 "실행"은, 항상, RAM(기억 장치)과 CPU(계산 장치)의 합작이다.
이 때, 코드 파일을 작성하는 개발자의 관점은 이거다: 실행 파일이 나중에 누군가의 컴퓨터에서 실행될 때를 대비하여, RAM 어딘가에 들어갈 수도 있는 모든 "정보"에 대해, 코드 파일에서만큼은, 자신이 구분하기 쉬운 "이름"을 붙여두고, 이름에 묶이는 정보가 CPU에 의해 어떻게 다뤄져야만 하는지를, "이름"과 이름 또는 정보의 "성질"로 미리 결정하는 것이다.
예를 들어, `let mut 한글: String = "가나다"`라는 Rust 코드에서 "한글"이 이름, (가나다)는 나중에 정보가 될 수도 있는 무언가, 이름 왼쪽의 `mut`과 오른쪽의 `String`이 "한글"이라는 이름에 고정되는 성질이다. 해석해보면 대충 이런 뜻이다: 나중에 수정당할 수 있는 "한글"은 문자열(String) 성질이고, 적어도 바로 다음 줄에서는, "한글" 안에 (가나다)라는 정보가 묶여 있다고 가정한다.
코드 파일이 실행 파일로 바뀔 때, 개발자가 붙여둔 "이름"과 "성질"은 전부 없어지고, 결국 실행 파일 안에는 정보가 될지도 모르는 것(가나다)만 남게 된다. 하지만, 적어도 Ust에서는, 이것이 "개발자에게도 정보가 중요하다"는 뜻이 되지는 않는다. 왜냐하면, 개발자의 목적은 항상 "이름"으로 표현되고, 정보가 될지도 모르는 것에도, 항상 이름을 붙여서 다룰 수밖에 없으며, 이름에 고정되는 성질의 규칙을 모든 코드에서 지켜야만, 동작을 미리 결정할 수 있기 때문이다. 따라서, 개발자가 집중해야 하는 것은, 언젠가 누군가의 RAM 위의 "정보"가 아니라, 코드 파일에 자기가 쓴 "이름"이다.
Rust가 이룬 것은, 이름이나 정보에 대한 규칙을 각각 정하고, 그것들의 성질을 특정 특수 문자나 단어로 정해두고, 이름 왼쪽이나 오른쪽을 각각 "이름의 성질 자리", "정보의 성질 자리"로 만들고, 동작이 끝나 쓸모없어질 정보의 정리를 자동화하고, 설령 개발자가 실수해도 실행 파일이 절대 만들어지지 못하게 하고, 결국 완성된 실행 파일은 더할 나위 없는 성능을 낼 수 있도록 설계했다는 것이다.
위업이라 칭할 만하지만, Rust에서는, 용어들을 더 일반화해내지는 못했다. Rust의 공식 교과서나, 코드 파일의 문법은, "동작을 미리 결정한다"를 좀 길게, 잘게 나눠서 설명한다. "정보는 이름과 떨어질 수 없다"와 "이름의 성질은 바뀌지 않는다"까지 정해놨으면서, 왜 성질 자리를 나눠놓았는가? 코드 안에 있을 수 없는 정보를 왜 생각하게 하는가? 그렇게 나눠버리면, 인간의 집중력으로는, "이름"과 "정보"를 둘 다 놓치게 된다.
...아마 "정보"를 생각할 수밖에 없는 기존 언어의 문법과 용어사용을 그대로 참고하면서 Rust를 만들다 보니 이렇게 된 것 같다. Ust 언어는, 바꾸는 김에 싹 다 바꾼다. Rust의 핵심 아이디어를 보전하면서, 용어 사용 방식을 "이름" 중심으로 하고(지금까지처럼), 특수문자 사용법도 바꾼다.
📎 첨부파일 (1)
📄 Ust.pdf