h_channni.log

Paper Review : Safeguarding Mobile GUI Agent via Logic-based Action Verification (VeriSafe Agent)

Fri, 18 Jul 2025 15:22:09 GMT

Introduction

대규모 파운데이션 모델들 (LFMs, ChatGPT나 Gemini 등을 생각하면 되겠다) 이 눈부신 발전을 함에 따라, 이를 모바일 GUI와 상호작용하는 데 활용해서 모바일 작업들을 자동화하려는 ‘Mobile GUI Agents’와 관련한 연구들이 등장하고 있다.

최근 Mobile GUI Agents 관련 연구들은 LFM을 활용해 자연어로 들어오는 user request를 해석하고, 이를 모바일 상에서의 UI interaction으로 ‘번역’하는 식으로 LFM의 자연어 처리 능력과 추론 능력을 활용하고 있다.

다만, 아무리 LFM이 발전했다 하더라도, 이를 기반으로 하는 Mobile GUI Agents에게는 근본적인 한계점이 있다: 바로 LFM의 근본적인 확률적인 특성으로 인해, 모바일 작업 자동화를 실제 애플리케이션에 적용하기에는 안전성, 신뢰성 이슈가 대두될 수밖에 없는 현실이다. 특히, 모바일 앱 상호작용이라는 것은 매우 모호하고, 맥락에 의존적이어서 많은 성능 향상이 이루어진 최근의 SOTA LFM들에게도 여전히 어려운 작업이다.

또 하나 중요한 문제는 mobile task들의 특성이다. 특히 비가역적이면서도 LFM이 만들어내는 에러가 정말 심각한 결과를 초래하는 경우가 많다는 것이다. 금융 거래나 메신저 등의 예시를 생각할 수 있는데, 이런 task들은 한 번 잘못 실행이 되어버리면 되돌릴 수 없다는 특성이 있다. 이런 작업들에서까지 Mobile GUI Agents를 활용하려면 그 전에 견고한 safeguard와 검증 메커니즘을 확보하는 것이 필수적이다.

Prior works

그렇다면, 기존의 연구들에서는 Mobile GUI Agents의 행동을 어떻게 ‘검증’을 시도했을까?

Reflection 기법이 대표적이다.

이는 primary GUI agent가 생성한 행동을 리뷰하기 위해 또 다른 LFM을 활용한 reflection agents를 두는 multi-agent 방식의 접근법이다.

Reflection 기반 기법은 크게 두 가지로 분류할 수 있는데, pre-action 검증과 post-action 검증이 있다:

pre-action 검증은 특정 행동이 모바일 앱에서 실행되기 ‘전에’ 검증하는 기법이다. 앞서 말했던 금융 거래와 같은 비가역적인 행동을 검증하기 위해서는 pre-action 검증이 실행되어야 하겠다. 하지만, 이 방법은 행동의 결과를 ‘예측’해야 한다는 어려움이 있고, 따라서 검증 정확도가 떨어진다는 문제가 있다.
post-action 검증은 특정 행동이 실행된 ‘이후’ 그 결과인 애플리케이션 상태를 보고 올바른 행동인지 검증하는 기법이다. 이를 통해 검증 정확도를 크게 향상시킬 수 있었다. 다만, 앞서 말했던 비가역적인 action을 사전에 막을 수 없다는 치명적인 한계가 존재한다.

또한, Reflection은 본질적으로 LFM을 사용해서 검증이 이루어지는 것이기 때문에, 정확도를 높일 수는 있더라도 결국 이 방식으로는 AI의 확률적인 특성에서 벗어날 수 없다는 것도 이 기법의 한계점이다.

VeriSafe Agent (VSA)

앞서 말했던 기존 연구인 Reflection 기법의 한계를 보완하기 위해 이 논문에서는 VeriSafe Agent(VSA)를 제안한다.

이 Agent는 확률적인 추론 대신, 논리 기반의 신뢰성 있는 pre-action 검증을 제공한다.

위 Figure의 우측을 보면, GUI agent의 UI action을 pre-action 단계에서 intercept하여, User Instruction과 Application State를 논리적인 formula로 형식화하여 올바른 action인지 검증을 수행한다.

즉, VSA는 사람이 natural language로 내리는 지시사항을 formal specification으로 자동 번역하는 Autoformalization이라는 concept을 활용한다.

또한, Figure를 보면 알 수 있듯이 VSA는 직접 행동을 수행하는 Mobile GUI Agent의 새로운 종류가 아니라, 기존 agent를 ‘검증’해 주는 시스템이다.

System Workflow

VSA의 system workflow는 아래 4가지 단계이다 :

App Development Phase
Intent Encoding
Verification
Feedback Generation

먼저, App Development Phase에서는 VSA를 위해 사전에 진행되어야 하는 단계로, 개발자가 직접 모바일 애플리케이션을 개발할 때 Predicates과 State transitions를 정의해 줘야 한다.

Intent Encoding 단계에서는 위 그림처럼 유저가 자연어로 내리는 지시사항을 구조화된 logical rules로 변환해 주는 작업이 실행된다.

Verification 단계에서는 기존 GUI Agent가 유저의 지시사항을 받고 실행한 UI Action에 대한 검증이 이루어지게 된다.

사전에 개발자가 개발해 둔 VSA developer library를 기반으로 해당 action을 수행했을 때 예상되는 state transition이 도출된다. Intent Verifier는 이 결과를 기반으로 logical rules에 따라 적절한 action인지를 검증하는 단계를 거친다.

마지막으로 Feedback Generation 단계에서는 앞선 검증 단계에서의 검증이 성공했는지, 실패했는지에 따라 VSA가 GUI Agent에게 적절한 피드백을 제공하게 되는 단계이다.

Challenges

논문에서는 VSA가 다루는 3가지 key challenges를 제시한다 :

C1. How to formally express the user’s intent and the app’s execution flow in logically tractable representation?
C2. How to accurately translate natural language user instructions into a formal representation and perform runtime verification against it?
C3. How to effectively communicate verification results back to the GUI agent in an actionable, explainable manner?

이 각각의 challenges에 대해서 VSA는 각각의 solutions들을 매핑해서 보여주는데,

C1에 대해서는 domain-specific language(DSL) 과 함께 관련된 developer library를 제시한다. (S1)
C2에 대해서는 self-corrective encoding approach(in Intent Encoder)와 two-tiered verification strategy(in Intent Verifier)를 제시한다. (S2)
C3에 대해서는 구조화된 feedback generation mechanism을 제시한다. (S3)

이 각각의 solution들을 하나하나 자세히 알아보도록 하자.

Domain-Specific Language (DSL) - for Solution 1

DSL은 특정 도메인에 특화된 computer language이다. 아래 위키백과 링크에서 더 자세한 내용을 확인할 수 있다.

https://en.wikipedia.org/wiki/Domain-specific_language

이 논문에서는 유저가 natural language로 내리는 instruction에 포함되어 있는 모바일 애플리케이션에서의 제약조건 / 실행 흐름 / 조건부 분기 등을 유연하게 표현하기 위해 DSL을 새롭게 설계한다.

Design of Domain-Specific Language

위 장표는 DSL의 구조를 시각화해 본 그래프이다.

유저의 지시사항 하나를 Specification이라 한다. 이것은 여러 가지의 Rule들로 구성되어 있다.

Rule*은 *Predicate(전제조건)들과 Objective(결론)으로, 다시 Predicate은 또 State Predicate들로 .. 이런 식으로 각각을 구성하는 요소들로 쪼개 나간다는 것을 알 수 있다.

Figure 2와 Figure 3에서 DSL의 syntax와 이를 활용한 instruction의 Specification을 확인할 수 있다.

각 Rule*은 하나의 Horn Cluase로 표현되고, 하나의 user instruction(i.e. *Specification)을 여러 개의 Rule들로 쪼개서 표현하는 역할을 한다.

이 Rule은 또 전제조건에 해당하는 State Predicates들과 결론에 해당하는 Objective로 구성된다.

Figure 3의 예시를 보면 직관적으로 이해가 가능할 것이다. “R이라는 이름의 레스토랑에 19시 전으로 예약을 하고, 해당 시간대에 레스토랑이 이용 불가능하다면, 아무것도 하지 말아라” 라는 유저의 지시사항을 3개의 Rule로 표현하였다:

R1 : 레스토랑의 정보 (이름이 ‘R’인지) 와 예약 정보 (날짜가 오늘인지, 시간이 19시 이전인지, 예약이 가능한지) 가 true이면 → Reserve를 진행한다. R2 : Reserve가 수행되고, 예약 결과가 성공이면 → Done(즉, action 마침) R3 : 만약 해당 시간에 예약이 불가능하면 (예약 정보에서 available 속성이 false) → Done (즉, 예약하지 않고 action을 마침)

R1의 결론이 R2의 전제조건으로 쓰이는 것과 같은 예시로 DSL이 action의 선행관계를 표현해 낸다는 것을 알 수 있다.

이와 같은 DSL을 구조화하여, VSA는 자연어로 된 유저의 지시사항을 형식적인 표현으로 ‘번역’을 성공적으로 수행할 수 있다.

Developer Library

이렇게 개념적으로 구현한 DSL을 실제 모바일 어플리케이션과 Mobile GUI Agents의 행동을 검증하고 평가하는 데 활용하기 위해서는 개발자가 앱의 상태(state predicates), 그리고 그와 관련된 state transitions를 ‘직접’ 정의해 줘야 한다.

개발자가 앱의 모든 상태와 상태 전이를 추가적으로 정의해줘야 한다는 것은 개발자에게 부담이 될 수도 있겠지만, 이미 React Native, iOS’s SwiftUI 등의 프레임워크에서 앱의 state와 transition 관리라는 개념이 존재하는 만큼 이것과 align함으로써 개발자의 부담이 그렇게 크지 않다고 말한다.

위 그림들과 같이 앱의 상태 정보와 상태 업데이트 정보를 몇 줄의 추가적인 코드 작성으로 쉽게 추가할 수 있는 개발자 라이브러리를 제공한다.

Verification Engine - for Solution 2

유저의 지시사항을 앞서 정의한 논리적 표현으로 인코딩하고, 이를 런타임에 정확하게 검증하기 위해서 VSA는 Intent Encoder와 Intent Verifier를 내부 엔진으로 구축한다.

더 자세한 방법론에 대해 알아보자.

Intent Encoder (self-corrective encoding)

Intent Encoder를 구현할 때 LFM에만 의존하게 되면, 할루시네이션의 발생 가능성을 생각하지 않을 수 없다.

이 리스크를 완화하기 위해서, 논문에서는 self-corrective encoding이라는 기법을 적용한다. 이는 아래의 두 가지 단계로 구성된다.

Rule-based Syntax Checking : 이 단계에서는 Encoder LLM이 natural language 유저 지시사항을 보고 생성한 Specifications를 검사한다. 앞서 정의한 DSL의 문법을 철저히 지키는지를 검사하게 된다.
Decoding-based Semantics Checking : 이 단계에서는 Decoder LLM과 Checker LLM을 활용해 생성한 Specifications을 다시 natural language로 디코딩하고, 이를 기존 유저 지시사항과 비교하면서 Semantic 정보를 확인한다.

이렇게 syntax와 semantic을 확인하는 두 단계의 과정을 거치면서, Intent Encoder는 user instruction이 DSL Specification으로 정확하게 인코딩한다.

Intent Verifier (two levels of verification)

인코딩을 마치게 되면, 아래의 메커니즘에 의해 Verification 단계가 수행된다 :

Mobile GUI Agent가 UI action을 생성한다.

→ 사전에 정의된 develoepr library를 통해 예상되는 state update가 반환된다.

→ 이 값을 기반으로 state predicate들의 true/false 여부를 재평가한다.

검증은 Predicate-level과 Rule-level의 두 가지 단계에서 이루어진다.

다시 DSL 구조 시각화 자료를 보면 이해가 쉬울 것이다.

Predicate-level Verification : 이 단계의 검증은 ‘모든 상태 업데이트’마다 수행된다.

만약, 여기서 predicate가 false로 평가되어도, 이는 에러를 의미하는 것이 아니다. 그 이유는, 유저 지시사항을 중간 단계에서 업데이트가 진행되고 있는 중일 수도 있기 때문이다. (예시로, 사과 3개를 장바구니에 담는 경우 ‘+’ 버튼을 세 번 누르면서 사과의 개수가 1개, 2개로 업데이트되는 중간 상태를 떠올려 볼 수 있다.)

이때 VSA는 soft feedback을 agent에게 전달하게 된다.
Rule-level Verification : 이 단계의 검증은 ‘되돌릴 수 없거나 critical한 checkpoint’에서 수행된다.

이러한 체크포인트는 되돌릴 수 없는 critical한 action과 관련된 rule이 만족되지 않으면, 해당 action은 무효화되고 차단된다.

VSA는 hard feedback을 agent에게 제공한다.

Structured Feedback Generator - for Solution 3

VSA와 같은 검증 시스템은 Mobile GUI Agent의 action을 검증해 준다는 장점도 있지만, agent에게 피드백을 제공해줄 수 있다는 것 또한 굉장한 장점이다.

VSA는 앞선 검증 결과를 기반으로, 세 가지 종류의 구조화된 피드백을 제공하여 mobile task 자동화의 신뢰성과 안전성을 높인다.

Roadmap Feedback : logical Specification을 기반으로, 전반적인 경로에 대한 가이드라인을 제공한다 (검증 결과와는 관계x)
Predicate-level Soft Feedback : Predicate-level verification이 실패한 경우, agent에게 일종의 경고로써 soft feedback을 제공한다. 이는 행동을 엄격하게 차단하는 것이 아니므로, agent는 피드백을 참고하되 동일한 action을 다시 수행할 수 있다.
Rule-level Hard Feedback : Rule-level verification이 실패한 경우, 이 경우는 critical actions에 대해서 rule-level에서 엄격한 금지와 피드백이 제공된다. 이때는 agent는 해당 rule을 구성하는 모든 state predicate들이 만족되기 전까지 동일한 행동을 수행하지 못한다.

Implementation & Evaluation

Implementation

Python으로 구현되었고, Intent Encoder를 구현하기 위해 GPT-4o를 활용한다.
Developer Library 구현에 대한 문서와 가이드라인을 제공하여 개발자가 효과적으로 State Predicates를 정의하고 활용할 수 있도록 한다.
OpenAI의 text-embedding-3-small model을 사용하여 user instruction의 ‘구조적 일치(structural equivalence)’ 대신 ‘의미적 일치(semantic equivalence)’를 판단한다.

Dataset

300개의 user instruction에 대한 dataset을 활용해서 Evaluation을 진행한다. (150 correct + 150 wrong)
이들 중 125개의 correct와 125개의 wrong dataset은 널리 사용되고 있는 데이터셋인 LlamaTouch의 일부를 활용했다.
다만, LlamaTouch는 상대적으로 단순한 instruction들로 구성되어 있으므로 (avg. 5.67 steps), 연구진은 더 복잡한 (avg. 19.16 steps, max. 40 steps) 25개의 correct, 25개의 wrong instruction들로 이루어진 Challenge Dataset을 직접 구성하여 추가로 확보했다.

Evaluation

실험을 진행한 결과, VSA를 적용한 경우에 LlamaTouch Dataset과 Challenge Dataset에서 모두 Reflection 방법에 비해 더 높은 검증 정확도를 보이는 것을 확인할 수 있다.

특히 Challenge Dataset에 대해서 여러 번 반복시켰을 때 VSA의 검증 정확도가 크게 상승한다는 것을 확인할 수 있다. 이는 검증이 logical formula에 기반해서 이루어지기 때문이다.

피드백의 영향 또한 확인할 수 있다.

Challenge Dataset에서, 두 가지 Reflection의 경우 피드백을 거쳤더라도 실패했던 case를 다시 성공시키지 못했던 반면, VSA가 피드백을 적용한 이후 Agent는 기존에 실패했던 많은 instruction들을 성공시키는 효과를 보여주었다. 이는 구조화된 피드백의 강력한 영향력을 보여준다.

Nomad Coders ‘플러터 10주 챌린지’ 4기 3주차 주간회고

Fri, 24 Jan 2025 07:16:29 GMT

3주차 주간회고

눈 감았다 떳는데 벌써 이번주 주간회고를 제출해야 하는 시간이 되었다.

내가 이번주에 뭘 했지 ….. ?

그러고 보니 벌써 1월도 다 끝나가네 ..? 시간에 버그난 것 같다(그렇다고 믿고 싶다)

좋은 소식이 있다면 .. 상하이로 해외여행(2.10~13)만 다녀와서 자대 랩실에 학부연구생으로 합류할 것 같다!

기대 반 걱정 반 … 그래도 교수님께서 참 인자하셔서 다행이다.

이번주에 연구실 컨택 준비한다고 시간을 너무 많이 뺏기긴 했지만 (벌써부터 밀리기 시작한다 ..~) 그래도 결과가 좋아서 다행이다.

이렇게 또 한 단계 스텝업 하는거겠지!

대신, 그만큼 바빠질 것 같다. 지금보다 더 바빠진다는게 아주 두렵긴 하지만 ..

심신에 부작용이 생기지 않게 관리를 잘 해야 할 필요성이 느껴진다. 방법은 잘 모르겠지만, 안 그러면 어느 쪽으로든 문제가 생길 것 같다.

핵심 3줄 요약

와 바쁘다 ! 연구실 컨택에 동아리 운영진에 다른 프로젝트에 스터디까지 ..
틱톡 클론코딩 강의 시작! 이 강의를 완전 처음 듣는 거라 그만큼 시간이 더 오래 걸리는 것 같다.
몸과 마음을 더 잘 챙길 수 있도록 해야 할 듯.

잘한 점

틱톡 클론코딩 챌린지, 그래도 꾸역꾸역 진도는 맞췄다! (강의 수강 & 챌린지 과제 제출)
운동을 다시 시작했다. 더 자주 가자!

개선할 점

코드 리팩토링이나 다른 분들 코드리뷰를 제대로 못 했다. 챌린지 두 번째 과제가 첫 번째와 이어지는 만큼 이거부터 해보자.
번아웃 위기 ..? 일이 쌓여있는데 너무 손에 안 잡혀서 반 놓아버렸다가 다시 정신 차림 ..
시간이 후달리기 시작하니까 플러터 학습의 깊이가 얕아지는 것 같다. 단순히 강의 내용 습득이 아니라 더 고차원적으로 접근하려는 시도를 해야 할 듯

일일 스프린트

25/01/20 (월) [⏩] 틱톡 클론코딩: #2.0~#4.4 수강 [✅] 지난주 과제 README 파일 작성 & 수정 [⏩] 코드리뷰 보고 댓글달기 ! [✅] 교수님 컨택 메일 발송 [⏩] 운동 일일회고: 볼링동아리 정기전 스근하게 다녀와서 뻗어버림 .. 전날 밤샌 여파가 ..ㅜ
25/01/22 (수) [✅] 운동가기 [✅] 오상은 교수님 연구실 방문 11:00 [✅] 케이웹 운영진 회의 13:00 [✅] 스터디 주간회의 참석 20:00 [✅] 틱톡 클론코딩 ~#4.10 수강 [✅] 틱톡챌린지 과제 제출 일일회고: 밤새 챌린지 과제 겨우 끝내고 얼레벌레 낸 것 같다. 쉽지 않구만 ..
2025/01/23 (목) [⏩] 운동하기 [⏩] 틱톡 클론 강의 #5.0 ~#5.4 [⏩] 지난 챌린지 리팩토링 [⏩] 다른분들 코드리뷰 보고 공부 + 댓글 일일회고: 어제의 여파로 늦잠이슈 + 나태지옥에 빠져버림 .. 벌써부터 이런 징조가 보이면 안 되는데 …?
2025/01/24 (금) [] 틱톡 클론 강의 #5.0~#5.4 [] 주간회고 작성 [] 백준 PS 1문제 풀기

이번주 배운 내용

(틱톡 클론코딩 Ch4까지 내용 기준.. Ch5부터는 아직 못 들었다 ㅜ)

이번주는 UI 관련해서 집중적으로 배운 한 주였다.

다른 위젯들도 모두 새로 배운 것들이지만, TextField 위젯이 특히 기억에 남는 것 같다.

→ 이런 디자인에, Error 스타일이나 Label 스타일까지 ..

이전에 React로 웹 프론트엔드를 공부할 때, 비슷한 디자인을 만들어보려고 정말 개고생했던 (…) 기억이 떠올랐는데, 이게 기본적으로 적용되어서 갖다 쓰기만 하면 된다는 게 참 신세계였다.

그 밖에도, 니꼬쌤의 의도대로 인터페이스를 구성할 수 있는 다양한 위젯들을 직접 사용해보면서 공부할 수 있어서 좋았다. 역시 이런 강의 스타일이 내가 니꼬쌤 강의를 좋아하는 이유이자 주변 친구들에게도 강력하게 추천하는 이유인 듯하다.

마무리

다음주는 설 명절이라 챌린지가 없다 !

개인적으로는 다음주가 판 뒤집을 기회라고 생각중이다 … ㅋㅋㅋ 다음주에 복습과 예습을 잔뜩 해놔서 다시 한 번 스터디 따라갈 동력을 확보하는 게 목표이다.
!

긴 회고 읽어 주셔서 감사합니다!

모두들 명절 잘 보내시고 함께 화이팅해봐요 ~~ :)

Nomad Coders ‘플러터 10주 챌린지’ 4기 2주차 주간회고

Sun, 19 Jan 2025 20:27:16 GMT

2주차

Nomad Coders ‘플러터 10주 챌린지’ 4기 2주차 주간회고록입니다.

chill guy 밈에 빠져버렸습니다. (디코 프사까지 전격 교체 .. 누오야미안해)

https://www.youtube.com/watch?v=hMuoeP-lbS4&t=2311s chill guy 브금과 함께 코딩하는 삶 (노동요 추천에도 올려야지)

코드에서 버그가 터져도 고chill 수 있는 chill guy인 나:

이것저것 바쁜 우리네 인생이지만 chill하게 살자구요 ~

✅ 핵심 3줄 요약

벌써 밀리기 시작한다 .. 정신 바짝 차려야 할 듯
강의를 들을 때 시간 분배를 훨씬 넉넉하게 해야 할 것 같다.
코드리뷰 열심히 동참하기!!

✅ 이번 주 목표

[x] '플러터로 웹툰 앱 만들기' 강의 필기 하면서 완강 [x] 챌린지 과제 밀리지 않고 제출 [ ] 일일 스프린트 매일 올리기

✅ 잘한 점

강의 완강 & 챌린지 모든 과제 제출 성공!
시간이 오래 걸렸지만, 강의 내용 필기를 착실히 하면서 들었다.

✅ 개선할 점

일일 스프린트를 빼먹은 날이 많았다. 다음주는 매일매일 올리기!
코드 챌린지를 수행할 때 딱 필수 사항만 충족해서 제출했다.
디스코드 활동이 부족했다.

✅ 이번 주 배운 내용

(강의 필기 내용정리 일부분 캡처. 각 행마다 페이지를 만들어서 필기하고 → 중요한 부분은 따로 메모하면서 공부중입니다!)

플러터의 핵심이 되는 Widget 에 대해 많은 내용을 배웠다.
‘이런 게 기본으로 제공된다고?’ 하는 것들이 많아서 놀랐다. (특히 ListView 나 Navigator 같은 UI 관련 기능들) 플러터 배우길 참 잘했다는 생각을 하면서 ..~
API Fetching 관련 구조 (model, service, etc.), HTTP Method 호출, async-await 문법 등은 기존 백엔드 개발에서의 그것과 유사하다.
Code Actions는 플러터 개발자의 삶의 질을 지켜준다. 참 좋은 기능이지만, 이 기능이 없었다면 많은 앱 개발자들이 플러터를 애초에 선택하지 않았을 것 같기도 하다. 개발자들을 유인하기 위해선 필수불가결한 기능이 아니었을까?

✅ 주간회의 (온라인 단체 커피챗)

또 한 번 스터디원 분들의 넓은 스펙트럼에 놀랐다. 진짜 대단하신 분들이 많은 것 같다.
아직 대학생인 나보단 대부분의 분들이 경험이나 커리어가 비교도 안 될 만큼 깊고 풍부하신 것 같다는 느낌을 받았다. 뭔가 다들 말을 잘 하시는 느낌 ..? 이 들어서 내 답변이 조금 부끄럽기도 했던 것 같다.
앞으로 진행될 조별 활동도 기대된다!

감사합니다 😊

Rust - 제네릭(Generic) & 트레이트(Trait)

Tue, 03 Dec 2024 07:52:38 GMT

Rust에 존재하는 제네릭 (Generic), 트레이트 (Trait), 라이프타임 (Lifetime) 개념에 대해 공부하고, 정리해 보겠습니다.

제네릭: 중복되는 타입 효율적으로 처리하기 위한 도구

🦀 제네릭 (generic)
모든 프로그래밍 언어는 중복되는 개념을 효율적으로 처리하기 위한 도구를 가지고 있습니다. 러스트에서는 제네릭 (generic) 이 그 역할을 맡습니다.
제네릭은 구체(concrete) 타입 혹은 기타 속성에 대한 추상화된 대역입니다. 컴파일과 실행 시점에 제네릭들이 실제로 무슨 타입으로 채워지는지 알 필요 없이 제네릭의 동작이나 다른 제네릭과의 관계를 표현할 수 있습니다.

교재에 나와 있는 제네릭에 대한 설명입니다. 다시 요약하자면, 러스트에서는 타입을 추상화하는 도구로 제네릭을 사용합니다.

반복되는 코드 블록을 여러 번 반복해서 작성하는 대신 ‘함수’로 만들어서 재사용하는 개념을 떠올려보면 제네릭을 이해하는 데 도움이 될 것 같습니다.

제네릭을 사용하면 타입과 기능을 일반화하여 코드 중복을 줄이고 유지보수성을 향상시킬 수 있습니다.

제네릭은 타입 매개변수를 사용하여 구현되며, 이는 코드가 사용될 때 구체적인 타입으로 지정될 placeholder 역할을 합니다.

함수의 매개변수나 반환 타입, 구조체, 열거형, 메서드 등에서 경우에 따라 여러 타입을 사용해야 할 수도 있습니다. 이때, 제네릭이 빛을 발하게 됩니다.

제네릭 사용 예시 코드

// 제네릭 함수 정의
fn largest(list: &[T]) -> &T {
    let mut largest = &list[0];

    for item in list {
        if item > largest {
            largest = item;
        }
    }

    largest
}

// 제네릭 구조체 정의
struct Point {
    x: T,
    y: T,
}

fn main() {
    let integer = Point { x: 5, y: 10 };
    let float = Point { x: 1.0, y: 4.0 };
}

// 제네릭 열거형 정의 - Option, Result
enum Option {
    Some(T),
    None,
}

enum Result {
    Ok(T),
    Err(E),
}

// 제네릭 메서드 정의
struct Point {
    x: X1,
    y: Y1,
}

impl Point {
    fn mixup(self, other: Point) -> Point {
        Point {
            x: self.x,
            y: other.y,
        }
    }
}

제네릭을 사용할 때는 <> 꺾쇠괄호 안에 타입 매개변수의 이름을 작성해 줘야 합니다. (관행적으로 Type의 첫 글자를 딴 T를 사용합니다.)

함수나 구조체, 열거형, impl 키워드 바로 뒤에 를 붙여 타입 매개변수 이름을 선언하고 각각의 정의 내에서 구체적인 타입 대신 타입 매개변수 이름을 활용하면 됩니다!

트레이트: 공통된 동작을 정의하기

🦀 트레이트 (trait)
트레이트 (trait) 는 특정한 타입이 가지고 있으면서 다른 타입과 공유할 수 있는 기능을 정의합니다. 트레이트를 사용하면 공통된 기능을 추상적으로 정의할 수 있습니다.
트레이트 바운드 (trait bound) 를 이용하면 어떤 제네릭 타입 자리에 특정한 동작을 갖춘 타입이 올 수 있음을 명시할 수 있습니다.

(Note: 약간의 차이는 있으나, 트레이트는 다른 언어에서 흔히 인터페이스 (interface) 라고 부르는 기능과 유사합니다.)

여러 타입(type)의 공통된 행위/특성을 표시한 것을 Trait 라고 합니다.

// Summary 트레이트 정의
pub trait Summary {
    fn summarize(&self) -> String;
}

우리는 러스트에서 트레이트를 활용해서, 다양한 타입들이 공통적으로 갖는 동작에 대해 추상화할 수 있습니다. 마치 객체지향 프로그래밍의 인터페이스처럼 말이죠! 트레이트를 통해 우리는 코드의 재사용성, 유연성, 안전성을 높일 수 있습니다.

위의 트레이트 정의 예시에서, 메서드 시그니처 뒤에는 중괄호로 시작하여 메서드를 구현하는 대신 세미콜론을 집어넣었습니다. 이 트레이트를 구현하는 각 타입이 메서드에 맞는 동작을 직접 제공해야 합니다. 컴파일러는 Summary 트레이트가 있는 모든 타입에 정확히 이와 같은 시그니처의 summarize 메서드를 가지고 있도록 강제할 것입니다.

특정 타입에 트레이트 구현하기

pub struct NewsArticle {
    pub headline: String,
    pub location: String,
    pub author: String,
    pub content: String,
}

impl Summary for NewsArticle {
    fn summarize(&self) -> String {
        format!("{}, by {} ({})", self.headline, self.author, self.location)
    }
}

pub struct Tweet {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub retweet: bool,
}

impl Summary for Tweet {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

이 예시에서는 NewsArticle 과 Tweet 타입에 각각 Summary 트레이트를 구현하였습니다.

특정 타입에 트레이트를 구현하는 문법은 위 예시에서 확인할 수 있듯이,

impl Trait for Type { }

형태로 명시한 다음, 트레이트 정의에 정의된 메서드 시그니처에 대한 메서드 본문을 작성해주면 됩니다.

트레이트 바운드 (trait bound): 제네릭과 트레이트를 활용한 Rust의 유연하면서도 강력한 기능

앞서 소개한 제네릭과 트레이트를 함께 사용하는 방법으로 트레이트 바운드가 있습니다.

트레이트 바운드는 제네릭에 제약을 걸어, 특정 동작을 보장하는 방법입니다. 즉, 제네릭 타입이 특정 트레이트를 구현한 타입이어야 한다는 조건을 명시해둔 것입니다.

이를 통해, 다양한 이점을 얻을 수 있는데, 아래와 같습니다:

컴파일러에게 제네릭 타입이 어떤 기능을 가져야 하는지 알려주고, 컴파일 시점에 타입 검사를 실행하여 런타임 오류를 방지할 수 있습니다.
함수나 구조체가 구현해야 하는 기능을 명확히 표현해둘 수 있습니다.
트레이트 바운드를 통해 Rust는 강력한 타입 시스템을 유지하면서도 유연한 제네릭 프로그래밍을 가능하게 합니다.

pub fn notify(item: &T) {
    println!("Breaking news! {}", item.summarize());
}

트레이트는, 꺾쇠괄호 안의 제네릭 타입 매개변수 선언 뒤에 콜론(:)과 함께 위치하게 됩니다.

이제, notify 함수의 item 매개변수로 올 수 있는 타입은 Summary 트레이트를 구현한 타입으로 제한됩니다.

pub fn notify(item: &T) {

위와 같이 + 구문으로 여러 개의 트레이트를 모두 구현하도록 바운드를 설정할 수도 있습니다.

fn some_function(t: &T, u: &U) -> i32
where
    T: Display + Clone,
    U: Clone + Debug,
{

위 예시는 where 조항입니다.

트레이트 바운드가 복잡해지면 자칫 코드의 가독성을 해칠 수 있습니다. 이때, 트레이트 바운드의 내용은 where 조항으로 따로 빼 버리면 함수 시그니처를 읽기가 더욱 쉬워질 것입니다.

읽어주셔서 감사합니다 🙇‍♂️

References

https://doc.rust-kr.org/ch10-01-syntax.html

https://doc.rust-kr.org/ch10-02-traits.html

https://www.linkedin.com/pulse/generics-rust-amit-nadiger

Rust - 에러 처리 (Error handling)

Mon, 11 Nov 2024 05:54:46 GMT

“소프트웨어에서 에러는 삶의 일부이므로, 러스트는 뭔가 잘못되는 상황을 처리하기 위한 기능을 몇 가지 갖추고 있습니다.” 라는 Rust 교재의 말처럼, 개발을 하는 과정에서 발생하는 수많은 에러를 우리는 해결해야 합니다. Rust의 에러 처리에 대해 공부하고, 정리해 보겠습니다.

대부분의 경우 러스트에서는 코드가 컴파일 되기 전에 에러의 가능성을 인지하고 조치를 취해야 합니다. 이러한 요구사항은 여러분의 코드를 프로덕션 환경에 배포하기 전에 에러를 발견하고 적절히 조치할 것을 보장하여 여러분의 프로그램을 더 견고하게 해 줍니다!

러스트는 에러를 복구 가능한 (recoverable) 에러와 복구 불가능한 (unrecoverable) 에러 두 가지 범주로 묶습니다.

복구 가능한 에러: Result 타입
복구 불가능한 에러: panic! 매크로 (에러가 발생했을 때 프로그램을 종료함)
## panic!으로 복구 불가능한 에러 처리하기

가끔은 코드에서 나쁜 일이 일어나고, 이에 대해 여러분이 할 수 있는 것이 없을 수도 있습니다. 이런 경우를 위해 러스트에는 panic! 매크로가 있습니다.

실제로 패닉을 일으키는 두 가지 방법이 있습니다.

코드가 패닉을 일으킬 동작을 하는 것
panic! 매크로를 명시적으로 호출하는 것

패닉이 일어나면 ..

실패 메시지를 출력하고
되감고 (unwind)
스택을 청소하고 (+ backtrace information을 만들 수도 있다.)
종료합니다.

```rust fn main() { let v = vec![1, 2, 3];
v[99]; }

벡터의 유효한 범위를 넘어선 인덱스로 접근을 시도하는 예시 코드를 통해 에러를 발생시켜 보겠습니다.

$ cargo run
   Compiling panic v0.1.0 (file:///projects/panic)
    Finished dev [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/panic`
thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 99', src/main.rs:4:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

첫번째 줄은 99 인덱스로 접근을 시도한 main.rs 4번째 줄을 가리키고 있습니다.
그다음 줄은 RUST_BACKTRACE 환경 변수를 설정하여 에러의 원인이 무엇인지 정확하게 백트레이스할 수 있다고 말해주고 있습니다.

한번 RUST_BACKTRACE 환경변수를 0이 아닌 값으로 설정하여 백트레이스를 얻어봅시다. 아래의 코드 블록은 여러분이 보게 될 것과 유사한 출력을 나타냅니다.

$ RUST_BACKTRACE=1 cargo run
thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 99', src/main.rs:4:5
stack backtrace:
   0: rust_begin_unwind
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/panicking.rs:142:14
   2: core::panicking::panic_bounds_check
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/panicking.rs:84:5
   3: >::index
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/slice/index.rs:242:10
   4: core::slice::index:: for [T]>::index
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/slice/index.rs:18:9
   5:  as core::ops::index::Index>::index
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/alloc/src/vec/mod.rs:2591:9
   6: panic::main
             at ./src/main.rs:4:5
   7: core::ops::function::FnOnce::call_once
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

백트레이스 (backtrace) 란 어떤 지점에 도달하기까지 호출한 모든 함수의 목록을 말합니다.

백트레이스를 읽는 요령은 위에서부터 시작하여 여러분이 작성한 파일이 보일 때까지 읽는 것입니다. 그곳이 바로 문제를 일으킨 지점입니다.

여러분의 파일이 나타난 줄보다 위에 있는 줄은 여러분의 코드가 호출한 코드이고, 아래의 코드는 여러분의 코드를 호출한 코드입니다. → panic이 발생한 지점을 전후로 더 정확한 실행 기록을 추적해볼 수 있습니다.

이 전후의 줄에는 핵심 러스트 코드, 표준 라이브러리, 여러분이 이용하고 있는 크레이트가 포함될 수 있습니다.
## Result로 복구 가능한 에러 처리하기

대부분 에러는 프로그램을 전부 중단해야 할 정도로 심각하진 않습니다.

때때로 어떤 함수가 실패할 경우는 쉽게 해석하고 대응할 수 있는 원인 때문입니다. 예를 들어 어떤 파일을 열려고 했는데 해당 파일이 존재하지 않아서 실패했다면, 프로세스를 종료해 버리는 대신 파일을 생성하는 것을 원할지도 모르죠.

enum Result { Ok(T), Err(E), }

Result 열거형은 Ok와 Err라는 두 개의 배리언트를 갖고 있습니다.

T와 E는 제네릭 타입 매개변수입니다. (교재의 10장에서 자세히 다루게 되는 내용) → T는 성공한 경우 Ok 배리언트 안에 반환될 값의 타입을 나타냅니다. → E는 실패한 경우 Err 배리언트 안에 반환될 에러의 타입을 나타냅니다.

use std::fs::File; fn main() { let greeting_file_result = File::open("hello.txt"); let greeting_file = match greeting_file_result { Ok(file) => file, Err(error) => panic!("Problem opening the file: {:?}", error), }; }

→ 예제: File::open 반환 값에 따라 다르게 작동하는 코드

File::open의 반환 타입은 Result입니다.

File::open이 성공한 경우에는 greeting_file_result 변수의 값이 파일 핸들을 가지고 있는 Ok 인스턴스가 될 것입니다.

실패한 경우 greeting_file_result는 발생한 에러의 종류에 관한 더 자세한 정보가 담긴 Err 인스턴스가 될 것입니다.

Option 열거형과 같이 Result 열거형과 배리언트들은 프렐루드로부터 가져와진다는 점을 주의하세요. 따라서 match 갈래의 Ok와 Err 앞에 Result::라고 지정하지 않아도 됩니다.

### 에러 발생 시 패닉을 위한 숏컷: `unwrap`과 `expect`

unwrap 메서드는 예제 9-4에서 작성한 match 구문과 비슷한 구현을 한 숏컷 메서드입니다.

만일 Result 값이 Ok 배리언트라면, unwrap은 Ok 내의 값을 반환할 것입니다.

만일 Result가 Err 배리언트라면 unwrap은 panic! 매크로를 호출해줄 것입니다.

아래에 unwrap이 동작하는 예가 있습니다:

use std::fs::File; fn main() { let greeting_file = File::open("hello.txt").unwrap(); }

이와 비슷한 expect는 panic! 에러 메시지도 선택할 수 있도록 해 줍니다.

unwrap 대신 expect를 이용하고 좋은 에러 메시지를 제공하면 여러분의 의도를 전달하면서 패닉의 근원을 추적하는 걸 쉽게 해줍니다.

expect의 문법은 아래와 같이 생겼습니다:

use std::fs::File; fn main() { let greeting_file = File::open("hello.txt") .expect("hello.txt should be included in this project"); }

프로덕션급 품질의 코드에서 대부분의 러스타시안은 unwrap보다 expect를 선택하여 해당 연산이 항시 성공한다고 기대하는 이유에 대한 더 많은 맥락을 제공합니다. 이렇게 하면 가정이 틀렸다는 것이 입증될 경우 디버깅에 사용할 더 많은 정보를 확보할 수 있습니다. (추후 러스트로 개발할 때 이 내용을 참고하면 좋을 것 같습니다!)

### 에러 전파하기 (propagating)

함수의 구현체에서 실패할 수도 있는 무언가를 호출할 때, 이 함수에서 에러를 처리하는 대신 이 함수를 호출하는 코드 쪽으로 에러를 반환하여 그쪽에서 수행할 작업을 결정하도록 할 수 있습니다.

이를 에러 전파하기 (propagating) 라고 하며 호출하는 코드 쪽에 더 많은 제어권을 주는 것인데, 호출하는 코드 쪽에는 에러를 어떻게 처리해야 하는지 결정하는 정보와 로직이 여러분의 코드 컨텍스트 내에서 활용할 수 있는 것보다 더 많이 있을 수도 있기 때문입니다.

use std::fs::File; use std::io::{self, Read}; fn read_username_from_file() -> Result { let username_file_result = File::open("hello.txt"); let mut username_file = match username_file_result { Ok(file) => file, Err(e) => return Err(e), }; let mut username = String::new(); match username_file.read_to_string(&mut username) { Ok(_) => Ok(username), Err(e) => Err(e), // 이 함수의 마지막 표현식이기 때문에 명시적으로 return이라고 적을 필요는 없습니다. } }

→ 파일로부터 사용자 이름을 읽는 함수를 작성한 것입니다. 만일 파일이 존재하지 않거나 읽을 수 없다면, 이 함수는 호출하는 코드 쪽으로 해당 에러를 반환할 것입니다.

반환 타입: Result → 제네릭 매개변수인 가 모두 concrete type으로 채워져 있습니다.

만일 이 함수가 문제없이 성공하면, 함수를 호출한 코드는 String(이 함수가 파일로부터 읽어 들인 사용자 이름이겠지요)을 담은 Ok 값을 받을 것입니다.

만일 어떤 문제가 발생한다면, 이 함수를 호출한 코드는 문제가 뭐였는지에 대한 더 많은 정보를 담고 있는 io::Error의 인스턴스를 담은 Err 값을 받을 것입니다.

이 코드를 호출하는 코드는 사용자 이름이 있는 Ok 값 혹은 io::Error를 담은 Err 값을 처리하게 될 것입니다. 이 값을 가지고 어떤 일을 할지에 대한 결정은 호출하는 코드 쪽에 달려 있습니다. (만일 그쪽에서 Err 값을 얻었다면, 이를테면 panic!을 호출하여 프로그램을 종료시키는 선택을 할 수도 있고, 기본 사용자 이름을 사용할 수도 있으며, 혹은 파일이 아닌 다른 어딘가에서 사용자 이름을 찾을 수도 있습니다.)
### 에러를 전파하기 위한 숏컷: ?

use std::fs::File; use std::io::{self, Read}; fn read_username_from_file() -> Result { let mut username_file = File::open("hello.txt")?; let mut username = String::new(); username_file.read_to_string(&mut username)?; Ok(username) }

→ 위 예제 코드와 같은 기능을 수행하지만, 숏컷인 ?를 사용합니다.

만일 Result의 값이 Ok라면, Ok 안의 값이 얻어지고 프로그램이 계속됩니다.

만일 값이 Err라면, return 키워드로 에러 값을 호출하는 코드에게 전파하는 것처럼 Err의 값이 반환될 것입니다.

?는 ?이 사용된 값과 호환 가능한 반환 타입을 가진 함수에서만 사용될 수 있습니다. → 함수의 반환 타입이 Result여야 이 return과 호환 가능합니다.

읽어주셔서 감사합니다 🙇‍♂️

References

https://doc.rust-kr.org/ch09-01-unrecoverable-errors-with-panic.html

https://doc.rust-kr.org/ch09-02-recoverable-errors-with-result.html

Rust - 크레이트(Crate), 패키지(Package), 모듈(Module)

Sun, 10 Nov 2024 10:33:28 GMT

프로젝트가 커지면 커질수록 방대해지는 코드를 효율적으로 관리하는 것은 아주 중요합니다. Rust에서 이러한 코드 조직화를 다루기 위해 제공하는 크레이트 / 패키지 / 모듈 개념에 대한 내용을 정리해 보겠습니다.

크레이트 (Crate)

Rust가 컴파일 한 차례에 고려하는 가장 작은 코드 단위

바이너리 크레이트와 라이브러리 크레이트 2종류가 있다.

크레이트는 여러 모듈을 담을 수 있다. (모듈은 이 크레이트와 함께 컴파일되는 다른 파일들에 정의되어 있을 수도 있습니다.)

바이너리 크레이트(Binary crate):

실행 가능한 실행파일로 컴파일할 수 있는 프로그램

main 함수를 포함하고 있어야 한다. → 여태껏 만들어 본 모든 크레이트는 바이너리 크레이트였음.

라이브러리 크레이트(Library crate):

main 함수를 가지고 있지 않고, 실행파일의 형태로 컴파일되지 않는다.

대신, 여러 프로젝트에서 공용될 의도로 만들어진 기능들이 정의되어 있다.

러스타시안들이 ‘크레이트’라 말하는 것은 대부분 라이브러리 크레이트를 의미하는 것이고, 이는 일반적인 프로그래밍 개념에서의 ‘라이브러리’와 혼용된다.

크레이트 루트(crate root):

러스트 컴파일러가 컴파일을 시작하는 소스 파일이다.

크레이트의 루트 모듈을 구성한다.

Library crate → src/lib.rs 가 크레이트 루트 & Binary crate → src/main.rs 가 크레이트 루트.

패키지 (Package)

일련의 기능을 제공하는 하나 이상의 crate들의 번들이다.

Cargo.toml 파일 포함

적어도 하나의 crate를 포함해야 한다. (Binary든 Library든)

Binary 크레이트는 원하는 만큼 포함할 수 있지만, Library 크레이트는 단 하나만 넣을 수 있다.

cargo new 명령어 → 패키지를 만든다.

$ cargo new my-project Created binary (application) `my-project` package $ ls my-project Cargo.toml src $ ls my-project/src main.rs

현재 패키지는 src/main.rs 만 포함하고 있으므로 이 패키지는 my-project라는 이름의 바이너리 크레이트만으로 구성되어 있습니다.

만약 어떤 패키지가 src/main.rs와 src/lib.rs를 가지고 있다면 해당 패키지는 패키지와 같은 이름의 바이너리, 라이브러리 크레이트를 포함하게 됩니다. (즉, 한 패키지에 크레이트 2개!)

src/bin 디렉터리 내에 파일을 배치하면 각각의 파일이 바이너리 크레이트가 되어, 여러 바이너리 크레이트를 패키지에 포함할 수 있습니다.

모듈 (Module)

모듈 치트 시트

https://doc.rust-kr.org/ch07-02-defining-modules-to-control-scope-and-privacy.html#모듈-치트-시트

크레이트 루트부터 시작: 크레이트를 컴파일할 때 컴파일러는 먼저 크레이트 루트 파일을 본다.

모듈 선언: 크레이트 루트 파일에는 새로운 모듈을 선언할 수 있다; mod garden;이라는 코드로 ‘garden’ 모듈을 선언할 수 있습니다.

컴파일러는 아래의 장소에서 이 모듈의 코드가 있는지 찾는다.

mod garden 뒤에 세미콜론 대신 중괄호를 써서 안쪽에 코드를 적은 인라인

src/garden.rs 파일 안

src/garden/mod.rs 파일 안 (예전 스타일)

서브모듈 선언: crate root가 아닌 다른 파일에서는 서브모듈을 선언할 수 있다. (ex. src/garden.rs 안에 mod vegetables; 를 선언할 수 있다.) → 아래의 장소에서 찾는다.

mod vegetables 뒤에 세미콜론 대신 중괄호를 써서 안쪽에 코드를 적은 인라인

src/garden/vegetables.rs 파일 안

src/garden/vegetables/mod.rs 파일 안 (예전 스타일)

모듈 내 코드로의 경로: 일단 모듈이 크레이트의 일부로서 구성되면, 공개 규칙이 허용하는 한도 내에서라면 해당 코드의 경로를 사용하여 동일한 크레이트의 어디에서든 이 모듈의 코드를 참조할 수 있게 됩니다. 예를 들면, garden vegetables 모듈 안에 있는 Asparagus 타입은 crate::garden::vegetables::Asparagus로 찾아 쓸 수 있습니다.

비공개 vs 공개: 모듈 내의 코드는 기본적으로 부모 모듈에게 비공개 (private) 입니다. 모듈을 공개 (public) 로 만들려면, mod 대신 pub mod를 써서 선언하세요. 공개 모듈의 아이템들을 공개하려면 마찬가지로 그 선언 앞에 pub을 붙이세요.

use 키워드: 어떤 스코프 내에서 use 키워드는 긴 경로의 반복을 줄이기 위한 어떤 아이템으로의 단축경로를 만들어 줍니다. crate::garden::vegetables::Asparagus를 참조할 수 있는 모든 스코프에서 use crate::garden::vegetables::Asparagus;로 단축경로를 만들 수 있으며, 그 이후부터는 스코프에서 이 타입을 사용하려면 Asparagus만 작성해주면 됩니다.

위의 규칙들을 보여주는 backyard라는 이름의 바이너리 크레이트를 만들어 보았습니다. 디렉터리명 또한 backyard로서, 아래의 파일들과 디렉터리들로 구성되어 있습니다.

backyard ├── Cargo.lock ├── Cargo.toml └── src ├── garden │ └── vegetables.rs ├── garden.rs └── main.rs
지금의 경우 크레이트 루트 파일은 src/main.rs이고, 내용은 아래와 같습니다:

파일명: src/main.rs

use crate::garden::vegetables::Asparagus; pub mod garden; fn main() { let plant = Asparagus {}; println!("I'm growing {:?}!", plant); }

pub mod garden; 라인이 컴파일러에게 src/garden.rs에 있는 코드를 포함할 것을 알려주고, src/garden.rs는 아래와 같습니다:

파일명: src/garden.rs

pub mod vegetables;

여기 pub mod vegetables;은 src/garden/vegetables.rs의 코드 또한 포함되어야 함을 의미합니다. 해당 파일의 코드는 아래와 같습니다:

#[derive(Debug)] pub struct Asparagus {}

이제 위 규칙들의 세부 사항으로 넘어가서 실제로 해보면서 확인합시다!

모듈 트리 예시

mod front_of_house { mod hosting { fn add_to_waitlist() {} fn seat_at_table() {} } mod serving { fn take_order() {} fn serve_order() {} fn take_payment() {} } }

→ 모듈 예시!

mod 키워드와 모듈 이름(위의 경우 front_of_house)을 지정하여 모듈을 정의합니다.

모듈의 본문은 중괄호로 감싸져 있습니다.

hosting, serving 모듈처럼, 모듈 내에는 다른 모듈을 넣을 수 있습니다.

모듈에는 구조체, 열거형, 상수, 트레이트, 함수(예제 7-1처럼) 등의 아이템 정의 또한 가질 수 있습니다.

위 예시를 트리 구조로 표현하면,

crate └── front_of_house ├── hosting │ ├── add_to_waitlist │ └── seat_at_table └── serving ├── take_order ├── serve_order └── take_payment

마치, 파일 디렉터리 구조가 연상된다!

전체 모듈 트리 최상위에 crate라는 모듈이 암묵적으로 위치한다는 점을 기억해 두세요.

앞서 src/main.rs와 *src/lib.rs는 크레이트 루트라고 부른다고 언급했습니다. 이 두 파일이 그런 이름을 갖게 된 이유는 *모듈 트리 (module tree) 라고 불리는 크레이트 모듈 구조에서 최상위에 crate라는 이름을 갖는 일종의 모듈로 형성되기 때문입니다.
### 경로를 사용하여 모듈 트리의 아이템 참조하기

경로는 두 가지 형태가 존재합니다.

절대 경로 (absolute path) 는 크레이트 루트로부터 시작되는 전체 경로이다. 외부 크레이트로부터의 코드에 대해서는 해당 크레이트 이름으로 절대 경로가 시작되고 현재의 크레이트로부터의 코드에 대해서는 crate 리터럴로부터 시작됩니다.

상대 경로 (relative path) 는 현재의 모듈을 시작점으로 하여 self, super 혹은 현재 모듈 내의 식별자를 사용합니다.

절대 경로, 상대 경로 뒤에는 ::으로 구분된 식별자가 하나 이상 따라옵니다.

mod front_of_house { mod hosting { fn add_to_waitlist() {} } } pub fn eat_at_restaurant() { // 절대 경로 crate::front_of_house::hosting::add_to_waitlist(); // 상대 경로 front_of_house::hosting::add_to_waitlist(); }

→ 이 코드는 에러가 발생합니다! 에러 메시지는 hosting 모듈이 비공개 (private) 라는 내용입니다. hosting 모듈과 add_to_waitlist 함수의 경로를 정확히 명시했지만, 해당 영역은 비공개 영역이기 때문에 러스트가 접근을 허용하지 않습니다.

러스트에서는 (함수, 메서드, 구조체, 열거형, 모듈, 그리고 상수 등) 모든 아이템이 기본적으로 부모 모듈에 대해 비공개입니다. → 함수나 구조체 같은 아이템을 비공개로 하고 싶다면 모듈에 넣으면 됩니다.

부모 모듈 내 아이템은 자식 모듈 내 비공개 아이템을 사용할 수 없지만, 자식 모듈 내 아이템은 부모 모듈 내 아이템을 사용할 수 있습니다. 이유는, 자식 모듈의 세부 구현은 감싸져서 숨겨져 있지만, 자식 모듈 내에서는 자신이 정의된 컨텍스트를 볼 수 있기 때문입니다.

러스트 모듈 시스템은 내부의 세부 구현을 기본적으로 숨기도록 되어 있습니다. 이로써, 여러분은 외부 코드의 동작을 망가뜨릴 걱정 없이 수정할 수 있는 코드가 어느 부분인지 알 수 있죠. (당연히 공개되어 있지 않은 부분이겠지?) 그렇지만 러스트에서는 pub 키워드를 사용하여 자식 모듈의 내부 구성 요소를 공개 (public) 함으로써 외부의 상위 모듈로 노출할 방법을 제공합니다.

### pub 키워드로 경로 노출하기 (공개하기?)

mod front_of_house { pub mod hosting { fn add_to_waitlist() {} } } pub fn eat_at_restaurant() { // 절대 경로 crate::front_of_house::hosting::add_to_waitlist(); // 상대 경로 front_of_house::hosting::add_to_waitlist(); }

→ 앞의 코드와 비교했을 때, hosting 모듈에 pub 키워드를 추가했습니다. 하지만 이 코드 또한 에러가 발생합니다. 왜 그런 걸까요?

hosting 모듈에 pub을 붙여서 모듈이 공개되었으므로, 이제 front_of_house 에 접근할 수 있다면 hosting 에도 접근할 수 있게 되었지만, hosting 모듈의 내용은 여전히 비공개입니다. 모듈을 공개했다고 해서 모듈의 내용까지 공개되지는 않습니다.

mod front_of_house { pub mod hosting { pub fn add_to_waitlist() {} } } pub fn eat_at_restaurant() { // 절대 경로 crate::front_of_house::hosting::add_to_waitlist(); // 상대 경로 front_of_house::hosting::add_to_waitlist(); }

→ 이렇게 add_to_waitlist 함수도 정의에 pub 키워드를 추가해서 공개해야 합니다. 이제서야 우리는 코드를 컴파일할 수 있게 되었습니다!

추가적으로,

서로 형제 관계에 있을 때는(즉, 같은 모듈 상에 있을 때는) pub 키워드로 공개해주지 않아도 접근할 수 있습니다.

pub 키워드로 외부에 공개되었다면, “해당 대상의 부모에게 접근할 수 있을 때, 해당 대상에게도 접근할 수 있다” 라고 핵심을 정리할 수 있겠습니다.

### super로 시작하는 상대 경로

상대 경로에서, super 로 시작하면 현재 모듈 혹은 크레이트 루트 대신 자기 부모 모듈부터 시작되는 경로를 만들 수 있습니다.

### 구조체, 열거형을 공개하기

구조체 정의에 pub를 쓰면 구조체는 공개되지만, 구조체의 필드는 비공개로 유지됩니다.

반대로, 열거형은 공개로 지정할 경우 모든 배리언트가 공개됩니다. (열거형은 그 배리언트가 공개되지 않는다면 큰 쓸모가 없습니다.)

### use 키워드로 경로를 스코프 안으로 가져오기

use 키워드를 한번 사용하여 어떤 경로의 단축경로 (shortcut) 를 만들 수 있고, 그러면 스코프 안쪽 어디서라도 짧은 이름을 사용할 수 있습니다.

스코프에 use 키워드와 경로를 작성하는 건 파일 시스템에서 심볼릭 링크 (symbolic link) 를 생성하는 것과 유사합니다.

use 키워드로 가져온 경우도 다른 경로와 마찬가지로 비공개 규칙이 적용됩니다.

mod front_of_house { pub mod hosting { pub fn add_to_waitlist() {} } } use crate::front_of_house::hosting; pub fn eat_at_restaurant() { hosting::add_to_waitlist(); }

→ eat_at_restaurant 함수 내에서 add_to_waitlist 함수를 hosting::add_to_waitlist 경로만으로 호출하는 예제입니다.

use가 사용된 특정한 스코프에서만 단축경로가 만들어진다는 점을 주의하세요. → 다른 스코프에서는 use 구문으로 만들어진 단축 경로가 적용되지 않습니다.

읽어주셔서 감사합니다 🙇‍♂️
References

https://doc.rust-kr.org/ch07-00-managing-growing-projects-with-packages-crates-and-modules.html

Rust - 구조체(struct) 와 메서드(method)

Tue, 15 Oct 2024 13:05:17 GMT

구조체에 대한 자세한 사항이 공식문서와 교재에 워낙 잘 설명이 되어 있기 때문에, 해당 내용들을 참고하면서, 제 기준에서 기록과 함께 제대로 체화시켜야 되겠다 싶은 부분들 위주로 정리해볼까 합니다.

구조체 기본 개념

A struct (or structure) is a custom data type that lets you package together and name multiple related values that make up a meaningful group → 고려대학교 ‘시스템 프로그래밍’ 강의자료 중 발췌

구조체 정의 및 인스턴스 생성

struct User { active: bool, username: String, email: String, sign_in_count: u64, }

User 라는 예시 구조체 정의

fn main() { let user1 = User { active: true, username: String::from("someusername123"), email: String::from("someone@example.com"), sign_in_count: 1, }; }

User 구조체의 인스턴스 생성

필드 초기화 문법

fn build_user(email: String, username: String) -> User { User { active: true, username, email, sign_in_count: 1, } }

위 코드처럼 변수명과 구조체 필드명이 같으면, username: username, 의 형태처럼 두 번 작성할 필요 없이 한 번만 쓰면 OK!

구조체 업데이트 문법: 기존 인스턴스를 이용해 새 인스턴스를 만들 때

fn main() { // --생략-- let user2 = User { email: String::from("another@example.com"), ..user1 }; }

.. 문법은 따로 명시된 필드를 제외한 나머지 필드를 주어진 인스턴스의 필드 값으로 설정합니다.

구조체 업데이트 문법이 대입처럼 = 를 이용한다는 점을 주목해야 합니다. 이로 인해 username처럼 String 데이터로 구조체를 업데이트하는 경우 소유권 이동이 일어날 수 있다는 점을 명심해야 합니다.

다만, Copy 트레이트를 구현한, 스택에만 저장되는 데이터 타입들은 마찬가지로 복사가 일어나므로 소유권에 대한 부분은 크게 신경쓰지 않아도 됩니다.
## 매서드 문법

메서드 (method) 는 함수와 유사합니다. fn 키워드와 함수명으로 선언하고, 매개변수와 반환 값을 가지며, 다른 어딘가로부터 호출될 때 실행됩니다. 하지만 메서드는 함수와 달리 구조체 컨텍스트에 정의되고 (열거형이나 트레이트 객체 안에 정의되기도 하며, 이는 각각 6장, 17장에서 알아보겠습니다), 첫 번째 매개변수가 항상 self 라는 차이점이 있습니다. self 매개변수는 메서드를 호출하고 있는 구조체 인스턴스를 나타냅니다.

#[derive(Debug)] struct Rectangle { width: u32, height: u32, } impl Rectangle { fn area(&self) -> u32 { self.width * self.height } } fn main() { let rect1 = Rectangle { width: 30, height: 50, }; println!("The area of rect1 is {} square pixels", rect1.area()); } fn area(rectangle: &Rectangle) -> u32 { rectangle.height * rectangle.width }

기존에 따로 함수로 만들었던 area 함수를 Rectangle 구조체의 메서드로 추가해준 코드입니다. 변경사항을 자세히 뜯어보자면..

impl 블록을 만들어 주었습니다. → area 함수를 블록 내부로 옮기고 함수 시그니처의 첫 번째 매개변수를 self로 고쳐 주었습니다.

함수 호출 시에는 메서드 문법 (method syntax) 을 사용해 Rectangle 인스턴스의 area 메서드를 호출할 수 있습니다. 메서드 문법은 차례대로 인스턴스, 점, 메서드명, 괄호 및 인수로 구성됩니다.

area 시그니처를 보면, rectangle: &Rectangle 대신 &self를 사용했습니다. &self는 실제로는 self: &Self를 줄인 것입니다. impl 블록 내에서 Self는 impl 블록의 대상이 되는 타입의 별칭입니다. → 즉, self가 파라미터 이름이고, Self가 파라미터 타입이다 !!

rectangle: &Rectangle에서 그랬던 것처럼, 이 메서드가 Self의 인스턴스를 빌려온다는 것을 나타내기 위해서는 self 축약형 앞에 &를 계속 붙여둘 필요가 있음을 주목하세요. 메서드는 다른 매개변수가 그런 것처럼 self의 소유권을 가져올 수도, 지금처럼 self를 불변으로 빌려올 수도, 가변으로 빌려올 수도 있습니다.
### 함수 대신 메서드 문법을 사용하는 이유?

제가 궁금했던 점은 바로 이 부분이었습니다. 이렇게 구조체의 메서드로 만들어버리면 그냥 따로 함수로 쓰는 것보다 뭔가 더 좋을 것 같긴 한데 … 그게 정확히 무엇일까? 라는 의문이 들었습니다.

교재에서 설명하는 내용은 아래와 같습니다:

함수 대신 메서드를 사용하는 주된 이유는 메서드 구문을 제공하고 모든 메서드 시그니처 내에서 self 타입을 반복할 필요가 없다는 것 외에도 코드를 더 조직적으로 만들기 위해서입니다. 향후 우리가 제공한 라이브러리를 사용할 사람들이 Rectangle의 기능과 관련된 코드를 라이브러리 곳곳에서 찾아내야 하는 것보다는, 하나의 impl 블록 내에 이 타입의 인스턴스로 할 수 있는 모든 것들을 모아두는 것이죠.

확실히, 결국 라이브러리의 형태로 코드를 제공해야 한다고 생각했을 때는, 별도의 함수로 뒀을 때보다 메서드로 만들어서 제공하는 것이 이해의 측면에서든, 활용의 측면에서든 훨씬 나을 것이라 짐작됩니다.

연관 함수

impl 블록 내에 구현된 모든 함수를 연관 함수 (associated function) 라고 부르는데, 이는 impl 뒤에 나오는 타입과 모두 연관된 함수이기 때문입니다. 동작하는 데 해당 타입의 인스턴스가 필요하지 않다면 self를 첫 매개변수로 갖지 않는 (따라서 메서드가 아닌) 연관 함수를 정의할 수도 있습니다. 우리는 이미 String 타입에 정의되어 있는 String::from 함수처럼 이런 종류의 함수를 사용해 봤습니다.

→ 교재에서 ‘연관 함수’라고 소개하는 챕터는 정확히는 ‘(메서드가 아닌) 연관 함수’ 라고 봐야 할 듯 합니다.. 예시를 살펴보겠습니다.

impl Rectangle { fn square(size: u32) -> Self { Self { width: size, height: size, } } }

메서드가 아닌 연관 함수는 구조체의 새 인스턴스를 반환하는 생성자로 자주 활용됩니다.

이 함수들은 보통 new라고 명명되는데, new는 이 언어에서 특별한 이름 혹은 키워드가 아닙니다. → 다르게 생각하면, Rust에서도 특정 구조체의 생성자 함수를 정의하고 이름을 new로 지어주면, 다른 언어들과 비슷한 메커니즘으로 활용할 수 있을 것 같습니다!

위 코드는 생성자의 예시로, Rectangle로 정사각형을 만들 때 너비, 높이에 같은 값을 두 번 지정하지 않고 치수 하나를 매개변수로 받아서 해당 치수로 너비와 높이를 설정하는 연관 함수 square를 구현한 것입니다.

반환 타입 및 함수 본문의 Self 키워드는 impl 키워드 뒤에 적혀있는 타입의 별칭으로서, 여기서는 Rectangle이 되겠습니다.

연관 함수를 호출할 땐 let sq = Rectangle::square(3);처럼 구조체 명에 :: 구문을 붙여서 호출합니다. 연관 함수는 구조체의 네임스페이스 안에 있기 때문이죠. :: 구문은 7장에서 알아볼 모듈에 의해 생성되는 네임스페이스에도 사용됩니다.

읽어주셔서 감사합니다 🙇‍♂️

References

https://doc.rust-kr.org/ch05-01-defining-structs.html

https://doc.rust-kr.org/ch05-02-example-structs.html

https://doc.rust-kr.org/ch05-03-method-syntax.html

Rust 교재의 한국어 버전을 기반으로 작성한 글임을 다시 한 번 알려드립니다. 🙏

Rust - 댕글링 참조 (Dangling Reference)

Mon, 14 Oct 2024 06:43:37 GMT

댕글링 포인터 (dangling pointer) 란, 어떤 메모리를 가리키는 포인터가 남아있는 상황에서 일부 메모리를 해제해 버림으로써, 다른 개체가 할당받았을지도 모르는 메모리를 참조하게 된 포인터를 말합니다.
이전 글에서, 작성 도중 떠오른 하나의 질문을 던지고 글을 마무리하였습니다.

Q. 참조자로 참조를 했는데, 원본 값이 갑자기 사라지면 어떡해 …? → A.

결론부터 말하자면, Rust 프로그램에서는 컴파일러가 이러한 상황을 사전에 방지합니다.

댕글링 포인터

Dangling pointers and wild pointers in computer programming are pointers that do not point to a valid object of the appropriate type. These are special cases of memory safety violations. More generally, dangling references and wild references are references that do not resolve to a valid destination. → 위키백과 ‘Dangling pointer’ 발췌

댕글링 포인터는 어떤 포인터가 가리키고 있는 메모리가 할당 해제되었으나 여전히 포인터는 그 주소를 가리키고 있는 상황을 말하고, 이 상황은 예측할 수 없는 행동을 발생시키므로 위험합니다. 참고로 이 경우 Linux 혹은 Unix에서는 segmentation fault가, Windows에서는 general protection fault가 발생할 수 있습니다.

포인터가 존재하는 언어에서는 자칫 잘못했다가는 이러한 댕글링 포인터를 만들기 쉽습니다. 다들 그렇듯이 저도 과거에 segmentation fault가 발생해서 잘못된 부분을 찾느라 고생했던 기억이 여럿 있기 때문에, 이를 사전에 방지해준다는 Rust가 더욱 매력적으로 다가오기도 했습니다..ㅋㅋㅋ

Rust에서의 댕글링 참조

러스트에서는 어떤 데이터의 참조자를 만들면, 해당 참조자가 스코프를 벗어나기 전에 데이터가 먼저 스코프를 벗어나는지 컴파일러에서 확인하여 댕글링 참조가 생성되지 않도록 보장합니다.

교재의 예시를 통해 알아보도록 하겠습니다.

fn main() { let reference_to_nothing = dangle(); } fn dangle() -> &String { let s = String::from("hello"); &s }

위 코드는 에러가 발생합니다:

$ cargo run Compiling ownership v0.1.0 (file:///projects/ownership) error[E0106]: missing lifetime specifier --> src/main.rs:5:16 | 5 | fn dangle() -> &String { | ^ expected named lifetime parameter | = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from help: consider using the `'static` lifetime | 5 | fn dangle() -> &'static String { | +++++++ For more information about this error, try `rustc --explain E0106`. error: could not compile `ownership` due to previous error

아직 다루지 않은 라이프타임이라는 내용이 에러 메시지에 등장하는데, 라이프타임은 10장에서 다룰 예정이니 일단 무시하도록 하겠습니다. 이 코드가 문제가 되는 이유를 알려주는 핵심 내용은 다음과 같습니다:

this function's return type contains a borrowed value, but there is no value for it to be borrowed from. (해석: 이 함수는 빌린 값을 반환하고 있으나, 빌린 실제 값이 존재하지 않습니다.)

dangle 함수에서 어떤 일이 일어나는지 주석을 통해 알아보도록 하겠습니다:

fn dangle() -> &String { // dangle은 String의 참조자를 반환합니다 let s = String::from("hello"); // s는 새로운 String입니다 &s // String s의 참조자를 반환합니다 } // 여기서 s는 스코프 밖으로 벗어나고 버려집니다. 해당 메모리는 해제됩니다. // 위험합니다!

s는 dangle 함수 내에서 생성됐기 때문에, 함수가 끝날 때 할당 해제됩니다. 하지만 코드에서는 &s를 반환하려 했고, 이는 유효하지 않은 String을 가리키는 참조자를 반환하는 행위이기 때문에 에러가 발생합니다.

따라서, 이런 경우엔 String을 직접 반환해야 합니다:

fn no_dangle() -> String { let s = String::from("hello"); s }

굳이 참조자를 반환하지 않고, String을 직접 반환해서 소유권을 이동시키는 방식으로 문제를 해결할 수 있습니다.

댕글링 참조가 발생하지 않도록 사전에 방지해주기도 하고, 간단한 해결책 또한 존재하기 때문에 코드를 작성하는 입장에서는 이는 엄청난 이점이라 생각됩니다!

읽어주셔서 감사합니다 🙇‍♂️

References

https://en.wikipedia.org/wiki/Dangling_pointer

https://doc.rust-kr.org/ch04-02-references-and-borrowing.html

Rust - 참조(reference) 와 대여(borrowing)

Sun, 13 Oct 2024 13:35:24 GMT

앞서 Rust의 소유권 개념에 대해 정리하기도 했고, Rust로 과제를 할 때 쓰면서도 확실하게 이해하고 쓰지 못하고 있다는 느낌이 들었던 참조(reference)와 대여(borrowing)에 대한 내용을 정리하면서 확실하게 파악해보려 합니다.

함수에 파라미터를 전달하고, 값을 반환할 때는 대입과 똑같이 소유권의 이동 혹은 복사가 일어난다고 생각하면 이를 이해하는 것 자체에는 큰 문제가 없을 것입니다. 다만, 모든 함수가 매번 소유권을 가졌다가 반납하는 것은 조금 번거롭습니다.

함수에 넘겨줄 값을 함수 호출 이후에도 쓰고 싶은데, 그렇다고 해서 함수로부터 얻고자 하는 결과에 더해서 이후 다시 쓰고 싶은 변수까지 같이 반환받아야 한다면 본말전도나 다름없죠.

교재에서 설명하는 위와 같은 경우를 생각해보면 매번 이를 신경쓰는 것은 매우 귀찮은 작업이 될 것 같습니다.

그럼, 함수가 값을 사용할 수 있도록 하되 소유권은 가져가지 않도록 하고 싶다면 어떻게 해야 할까요?

Rust에서는 예제 4-5에서처럼 튜플을 사용하여 여러 값을 반환하는 것이 가능합니다:

fn main() { let s1 = String::from("hello"); let (s2, len) = calculate_length(s1); println!("The length of '{}' is {}.", s2, len); } fn calculate_length(s: String) -> (String, usize) { let length = s.len(); // len()은 String의 길이를 반환합니다 (s, length) }

예제 4.5: 매개변수의 소유권을 되돌려주는 방법

다만, 이런 방식도 거추장스럽고, 많은 작업량이 수반되는 것은 마찬가지입니다.

다행히도, Rust에는 소유권 이동 없이 값을 사용할 수 있는 참조자 (reference) 라는 기능을 가지고 있습니다.

참조와 대여

다음은 참조자를 매개변수로 받도록 구현한 calculate_length 함수의 정의 및 용례입니다.

fn main() { let s1 = String::from("hello"); let len = calculate_length(&s1); println!("The length of '{}' is {}.", s1, len); } fn calculate_length(s: &String) -> usize { s.len() }

calculate_length 함수에 s1 대신 &s1을 전달하고, 함수 정의에 String 대신 &String을 사용했네요. 이 앰퍼센드(&) 기호가 참조자를 나타내고, 어떤 값의 소유권을 가져오지 않고 해당 값을 참조할 수 있도록 해 줍니다.

let s1 = String::from("hello"); let len = calculate_length(&s1);

함수 호출부를 보면, s1에 &를 붙인 &s1 구문은 s1 값을 참조하지만 해당 값을 소유하지 않는 참조자를 생성합니다. 값을 소유하지 않으므로 이 참조자가 가리킨 값은 참조자가 사용되지 않을 때까지 버려지지 않습니다.

마찬가지로 함수 시그니처에도 &를 사용하여 매개변수 s가 참조자 타입임을 나타내줍니다.

fn calculate_length(s: &String) -> usize { // s는 String의 참조자입니다 s.len() } // 여기서 s가 스코프 밖으로 벗어납니다. 하지만 참조하는 것을 소유하고 있진 않으므로, // 버려지지는 않습니다.

변수 s가 유효한 스코프는 여타 함수의 매개변수에 적용되는 스코프와 동일합니다. 하지만 s에는 소유권이 없으므로 s가 더 이상 사용되지 않을 때도 이 참조자가 가리킨 값이 버려지지 않습니다.

함수가 실제 값 대신 참조자를 매개변수로 쓴다면 애초에 소유권이 없으니까 이 소유권을 돌려주기 위한 값 반환도 필요 없어집니다. 거추장스러운 작업이 하나 사라지는 셈이 됩니다.

이처럼 참조자를 만드는 행위를 Rust에서는 대여(borrow) 라고 합니다.

가변 참조자

fn main() { let s = String::from("hello"); change(&s); } fn change(some_string: &String) { some_string.push_str(", world"); }

이 코드는 컴파일 에러를 발생시킵니다. 변수가 기본적으로 불변성을 지니는 것과 마찬가지로, 참조자 또한 기본적으로 참조하는 값을 수정할 수 없습니다.

$ cargo run Compiling ownership v0.1.0 (file:///projects/ownership) error[E0596]: cannot borrow `*some_string` as mutable, as it is behind a `&` reference --> src/main.rs:8:5 | 7 | fn change(some_string: &String) { | ------- help: consider changing this to be a mutable reference: `&mut String` 8 | some_string.push_str(", world"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `some_string` is a `&` reference, so the data it refers to cannot be borrowed as mutable For more information about this error, try `rustc --explain E0596`. error: could not compile `ownership` due to previous error

가변 참조자 (mutable reference) 를 사용하는 식으로 코드를 살짝만 수정해 주면 에러를 없앨 수 있습니다.

fn main() { let mut s = String::from("hello"); change(&mut s); } fn change(some_string: &mut String) { some_string.push_str(", world"); }

에러 메시지 내용에서도 자세히 알려주듯이, mut 키워드를 붙여주면 해결됩니다.

(Rust의 가장 강력한 장점은 컴파일러가 에러 메시지를 매우 친절하게 써 주는 것이라 생각합니다. 그대로 따라하면 손쉽게 문제를 해결할 수 있을 정도로 굉장히 직관적이고, 에러 메시지를 보면서 스스로 잘못한 점을 피드백하고 공부까지 할 수 있을 정도입니다.. Rust의 에러 메시지는 볼 때마다 마치 선생님 같다는 생각이 듭니다. 급 주저리 주저리 ..)

가변 참조자 관련 제약사항

가변 참조자는 한 가지 큰 제약사항이 있습니다: 어떤 값에 대한 가변 참조자가 있다면, 그 값에 대한 참조자는 더 이상 만들 수 없습니다. 아래의 코드는 s에 대한 두 개의 가변 참조자 생성을 시도하는 코드로, 작동하지 않습니다:

let mut s = String::from("hello"); let r1 = &mut s; let r2 = &mut s; println!("{}, {}", r1, r2);

에러는 다음과 같습니다:

$ cargo run Compiling ownership v0.1.0 (file:///projects/ownership) error[E0499]: cannot borrow `s` as mutable more than once at a time --> src/main.rs:5:14 | 4 | let r1 = &mut s; | ------ first mutable borrow occurs here 5 | let r2 = &mut s; | ^^^^^^ second mutable borrow occurs here 6 | 7 | println!("{}, {}", r1, r2); | -- first borrow later used here For more information about this error, try `rustc --explain E0499`. error: could not compile `ownership` due to previous error

대부분의 언어들이 언제든 값 변경을 허용하고 있기 때문에, Rust를 처음 사용할 경우에는 이러한 제약이 장애물처럼 다가올 수 있습니다. 하지만, 이 제약 덕분에 러스트에서는 컴파일 타임에 데이터 경합 (data race) 을 방지할 수 있습니다.

데이터 경합이란 다음 세 가지 상황이 겹칠 때 일어나는 특정한 경합 조건 (race condition) 입니다:

둘 이상의 포인터가 동시에 같은 데이터에 접근

포인터 중 하나 이상이 데이터에 쓰기 작업을 시행

데이터 접근 동기화 메커니즘이 없음

가변 참조자와 불변 참조자를 혼용할 때도 유사한 규칙이 적용됩니다. 다음 코드는 컴파일 에러가 발생합니다:

let mut s = String::from("hello"); let r1 = &s; // 문제없음 let r2 = &s; // 문제없음 let r3 = &mut s; // 큰 문제 println!("{}, {}, and {}", r1, r2, r3);

에러는 다음과 같습니다:

$ cargo run Compiling ownership v0.1.0 (file:///projects/ownership) error[E0502]: cannot borrow `s` as mutable because it is also borrowed as immutable --> src/main.rs:6:14 | 4 | let r1 = &s; // no problem | -- immutable borrow occurs here 5 | let r2 = &s; // no problem 6 | let r3 = &mut s; // BIG PROBLEM | ^^^^^^ mutable borrow occurs here 7 | 8 | println!("{}, {}, and {}", r1, r2, r3); | -- immutable borrow later used here For more information about this error, try `rustc --explain E0502`. error: could not compile `ownership` due to previous error

어떤 값에 대한 불변 참조자가 있는 동안 같은 값의 가변 참조자를 만드는 것 또한 불가능합니다.

반면 데이터를 읽기만 하는 기능으로는 다른 쪽에서 값을 읽는 기능에 영향을 주지 않으므로, 여러 개의 불변 참조자를 만드는 것은 가능합니다.

요악하자면, 아래와 같습니다:

어떤 값에 가변 참조자 존재

해당 값에 가변 참조자 생성 불가능

해당 값에 불변 참조자 또한 생성 불가능

어떤 값에 불변 참조자 존재

해당 값에 가변 참조자 생성 불가능

해당 값에 불변 참조자 생성 가능 (여러개 또한 가능)

참조자의 스코프

참조자는 정의된 지점부터 시작하여 해당 참조자가 마지막으로 사용된 부분까지 유효합니다. 즉, 다음 코드는 불변 참조자가 마지막으로 사용되는 println! 이후에 가변 참조자의 정의가 있으므로 컴파일 에러가 발생하지 않습니다.

let mut s = String::from("hello"); let r1 = &s; // 문제없음 let r2 = &s; // 문제없음 println!("{} and {}", r1, r2); // 이 지점 이후로 변수 r1과 r2는 사용되지 않습니다 let r3 = &mut s; // 문제없음 println!("{}", r3);

불변 참조자 r1, r2의 스코프는 자신들이 마지막으로 사용된 println! 이후로 종료되고, 해당 println!은 가변 참조자 r3가 생성되기 전이니 서로 스코프가 겹치지 않아서 이 코드는 문제가 없는 것이죠: 컴파일러는 이 참조자가 어떤 지점 이후로 스코프 끝까지 사용되지 않음을 알 수 있습니다. 강의자료에서 손글씨로 필기한 내용 중, scope를 표시한 부분을 한번 유심히 확인해보면 좋을 것 같습니다! (예시코드는 똑같은 코드입니다~)

스코프가 겹치지 않도록 하는 또 하나의 방법으로, 중괄호로 새로운 스코프를 만들어 가변 참조자를 여러 개 만들면서 동시에 존재하는 상황을 회피하는 방법이 있습니다:

let mut s = String::from("hello"); { let r1 = &mut s; } // 여기서 r1이 스코프 밖으로 벗어나며, 따라서 아무 문제없이 새 참조자를 만들 수 있습니다. let r2 = &mut s;

참조자 여러개를 만들 수 있는지에 대한 규칙 요약:

어떤 값에 대한 가변 참조자가 있다면, 그 값에 대한 참조자는 더 이상 만들 수 없다.

어떤 값에 대한 불변 참조자가 있는 동안, 같은 값의 가변 참조자를 만드는 것 또한 불가능하다.

여러 개의 불변 참조자를 만드는 것은 가능하다.

단, 참조자들의 스코프가 겹치지 않는다면 컴파일 에러가 발생하지 않는다. → 참조자의 스코프는 정의된 지점부터 마지막으로 사용된 부분까지!!

떠오른 질문

참조와 대여에 대한 내용을 정리하면서, 이런 질문이 떠올랐습니다.

Q. 참조자로 참조를 했는데, 원본 값이 갑자기 사라지면 어떡해 …? → A.

이 질문에 대한 답은 ‘댕글링 참조’라는 내용으로 친절하게 설명이 되어 있는데, 내용이 너무 길어지니 다음 글로 나누도록 하겠습니다 .!!

읽어주셔서 감사합니다 🙇‍♂️

References

https://doc.rust-kr.org/ch04-02-references-and-borrowing.html

Rust - Ownership (소유권) 정리

Sun, 13 Oct 2024 11:36:58 GMT

Rust만의 메모리 관리 규칙인 Ownership(소유권) 개념에 대해 정리해 보려 합니다.

소유권이란 무엇인가

소유권은 러스트 프로그램의 메모리 관리법을 지배하는 규칙 모음입니다.

모든 프로그램은 작동하는 동안 컴퓨터의 메모리 사용 방법을 관리해야 합니다. 몇몇 언어는 가비지 컬렉션으로 프로그램에서 더 이상 사용하지 않는 메모리를 정기적으로 찾는 방식을 채택했고, 다른 언어는 프로그래머가 직접 명시적으로 메모리를 할당하고 해제하는 방식을 택했습니다. 이때 러스트는 제3의 방식을 택했습니다: 소유권 (ownership) 이라는 시스템을 만들고, 컴파일러가 컴파일 중에 검사할 여러 규칙을 정해 메모리를 관리하는 방식이지요.

→ The Rust Programming Language 교재 번역본에 나와 있는 소유권에 대한 설명입니다.

→ 현재 수강중인 ‘시스템 프로그래밍’ 과목의 Lec03 - Memory Ownership 강의자료 발췌
즉, 앞으로 알아볼 ‘소유권’이라는 개념은 Rust 프로그램이 메모리를 관리하는 rule들의 모음이며, runtime cost에 영향을 미치지 않는 zero-cost abstraction에 해당합니다.

소유권 규칙

소유권 규칙부터 알아보겠습니다. 앞으로 나올 내용을 보는 동안 다음 규칙을 명심하세요:

러스트에서, 각각의 값은 소유자 (owner) 가 정해져 있습니다.

한 값의 소유자는 동시에 여럿 존재할 수 없습니다.

소유자가 스코프 밖으로 벗어날 때, 값은 버려집니다 (dropped).

String 타입

소유권에 대해 더 자세히 이해하기 위해, 교재에서는 힙에 데이터를 저장하는 String 타입을 활용하고 있습니다.

문자열 리터럴은 쓰기 편하지만, 불변성을 지니고 있고(immutable), 사용자 입력을 받는 등 컴파일 타임에 값을 알 수 없는 경우에는 사용할 수 없습니다. 반면, String 타입은 힙에 할당된 데이터를 다루기 때문에, 컴파일 타임에 크기를 알 수 없는 텍스트도 저장할 수 있습니다.

String 타입은 다음과 같이 from 함수와 문자열 리터럴을 이용해 생성 가능합니다.

let s = String::from("hello");

메모리와 할당

String 타입은 힙에 메모리를 할당하는 방식을 사용하기 때문에 텍스트 내용 및 크기를 변경할 수 있습니다. 하지만 이는 다음을 의미하기도 합니다:

실행 중 메모리 할당자로부터 메모리를 요청해야 합니다.

String 사용을 마쳤을 때 메모리를 해제할 (즉, 할당자에게 메모리를 반납할) 방법이 필요합니다.

첫번째는 앞에서 본 String::from을 호출하면서 해결했습니다. 그렇다면 두 번째는 어떨까요?

먼저 기존의 언어들에서 메모리를 해제하던 방식에 대해 알아보겠습니다.

가비지 컬렉터 (garbage collector, GC) 를 갖는 언어에서는 GC가 사용하지 않는 메모리를 찾아 없애주므로 프로그래머가 신경 쓸 필요 없습니다.

GC가 없는 대부분의 언어에서는 할당받은 메모리가 필요 없어지는 지점을 프로그래머가 직접 찾아 메모리 해제 코드를 작성해야 합니다. → 이 작업은 역사적으로 어려운 프로그래밍 문제였습니다.

프로그래머가 놓친 부분이 있다면 메모리 낭비가 발생하고, 메모리 해제 시점을 너무 일찍 잡으면 유효하지 않은 변수가 생깁니다.

두 번 해제할 경우도 마찬가지로 버그가 발생합니다. 따라서 allocate (할당) 과 free (해제) 가 하나씩 짝짓도록 만들어야 합니다.

Rust에서는 이 문제를 변수가 자신이 소속된 스코프를 벗어나는 순간 자동으로 메모리를 해제하는 방식으로 해결했습니다.

{ let s = String::from("hello"); // s는 이 지점부터 유효합니다 // s를 가지고 무언가 합니다 } // 이 스코프가 종료되었고, s는 더 이상 // 유효하지 않습니다.

위 코드에는 String에서 사용한 메모리를 자연스럽게 해제하는 지점이 있습니다.

변수와 데이터 간 상호작용 방식: 이동

Rust에서는 동일한 데이터에 여러 변수가 서로 다른 방식으로 상호작용할 수 있습니다. 먼저, 첫 번째 케이스입니다.

let x = 5; let y = x;

‘5를 x에 바인딩하고, x 값의 복사본을 만들어 y에 바인딩하시오’ 그럼 x, y 두 변수가 생길 겁니다. 각각의 값은 5가 되겠죠. 실제로도 이와 같은데, 정수형 값은 크기가 정해진 단순한 값이기 때문입니다. 이는 다시 말해, 두 5 값은 스택에 푸시된다는 뜻입니다.

앞선 예제를 String으로 바꾼 두 번째 케이스입니다.

let s1 = String::from("hello"); let s2 = s1;

이 코드는 전혀 다른 방식으로 동작합니다.

마찬가지로 ‘시스템 프로그래밍’ 강의 자료 중 위 코드의 설명에 대한 그림을 캡처한 사진입니다.

s2에 s1을 대입하면, String 데이터가 복사됩니다. 여기서 말하는 데이터는 스택에 있는 포인터, 길이, 용량 값을 말하며, 포인터가 가리키는 힙 영역의 데이터는 복사되지 않습니다.

다만, 이 경우 s1과 s2가 스코프 밖으로 벗어날 때 각각 메모리를 해제하게 되면 중복 해제 (double free) 에러가 발생할 겁니다. 또한, Rust 프로그램 상에서는 앞서 말했던 소유권 규칙 2번('한 값의 소유자는 동시에 여럿 존재할 수 없습니다.')에 위배되는 것이기도 합니다.

메모리 안정성을 보장하기 위해서, Rust는 let s2 = s1; 라인 뒤로는 s1이 더 이상 유효하지 않다고 판단합니다. 이로써 Rust는 s1이 스코프를 벗어나더라도 아무것도 해제할 필요가 없어집니다. s2가 만들어진 이후에 s1을 사용하는 경우 어떤 일이 생기는지 확인해 보면, 작동하지 않음을 알 수 있습니다.

이 개념은 다른 프로그래밍 언어에서 말하는 얕은 복사(shallow copy)와 유사하지만, Rust에서는 기존의 변수를 무효화하기 때문에 이를 이동(move)이라 합니다.

변수와 데이터 간 상호작용 방식: 클론

String의 힙 데이터까지 깊이 복사하고 싶을 땐 clone이라는 공용 메서드를 사용할 수 있습니다. (메서드 문법은 5장에서 다룰 예정이지만, 메서드라는 개념은 대부분의 프로그래밍 언어가 갖는 특성이기 때문에 이미 다뤄보셨을 겁니다.)

let s1 = String::from("hello"); let s2 = s1.clone(); println!("s1 = {}, s2 = {}", s1, s2);

스택에만 저장되는 데이터: 복사

let x = 5; let y = x; println!("x = {}, y = {}", x, y);

위 코드는 정상적으로 동작합니다.

이유는 정수형 등 컴파일 타임에 크기가 고정되는 타입은 모두 스택에 저장되기 때문입니다. 스택에 저장되니, 복사본을 빠르게 만들 수 있고, 따라서 굳이 y를 생성하고 나면 x를 무효화할 필요가 없습니다. 다시 말해 이런 경우엔 깊은 복사와 얕은 복사 간에 차이가 없습니다. 여기선 clone을 호출해도 얕은 복사와 차이가 없으니 생략해도 상관없죠.

소유권과 함수

함수에 파라미터를 전달하는 것은 변수에 값을 대입할 때와 유사합니다. 함수에 변수를 전달하면 대입 연산과 마찬가지로 이동 혹은 복사가 일어나게 됩니다.

fn main() { let s = String::from("hello"); // s가 스코프 안으로 들어옵니다 takes_ownership(s); // s의 값이 함수로 이동됩니다... // ... 따라서 여기서는 더 이상 유효하지 않습니다 let x = 5; // x가 스코프 안으로 들어옵니다 makes_copy(x); // x가 함수로 이동될 것입니다만, // i32는 Copy이므로 앞으로 계속 x를 // 사용해도 좋습니다 } // 여기서 x가 스코프 밖으로 벗어나고 s도 그렇게 됩니다. 그러나 s의 값이 이동되었으므로 // 별다른 일이 발생하지 않습니다. fn takes_ownership(some_string: String) { // some_string이 스코프 안으로 들어옵니다 println!("{}", some_string); } // 여기서 some_string이 스코프 밖으로 벗어나고 `drop`이 호출됩니다. // 메모리가 해제됩니다. fn makes_copy(some_integer: i32) { // some_integer가 스코프 안으로 들어옵니다 println!("{}", some_integer); } // 여기서 some_integer가 스코프 밖으로 벗어납니다. 별다른 일이 발생하지 않습니다.

위 코드에서 주석으로 표시된 설명을 참고해 보면 도움이 될 것 같습니다. takes_ownership 함수를 호출한 이후 s를 사용하려 하면, 이미 값의 이동이 일어났으므로 컴파일 에러가 발생합니다.

fn main() { let s1 = gives_ownership(); // gives_ownership이 자신의 반환 값을 s1로 // 이동시킵니다 let s2 = String::from("hello"); // s2가 스코프 안으로 들어옵니다 let s3 = takes_and_gives_back(s2); // s2는 takes_and_gives_back로 이동되는데, // 이 함수 또한 자신의 반환 값을 s3로 // 이동시킵니다 } // 여기서 s3가 스코프 밖으로 벗어나면서 버려집니다. s2는 이동되어서 아무 일도 // 일어나지 않습니다. s1은 스코프 밖으로 벗어나고 버려집니다. fn gives_ownership() -> String { // gives_ownership은 자신의 반환 값을 // 자신의 호출자 함수로 이동시킬 // 것입니다 let some_string = String::from("yours"); // some_string이 스코프 안으로 들어옵니다 some_string // some_string이 반환되고 // 호출자 함수 쪽으로 // 이동합니다 } // 이 함수는 String을 취하고 같은 것을 반환합니다 fn takes_and_gives_back(a_string: String) -> String { // a_string이 스코프 안으로 // 들어옵니다 a_string // a_string이 반환되고 호출자 함수 쪽으로 이동합니다 }

위 코드에서는 주석으로 함수에서 값이 반환될 때 값의 이동에 대해 설명하고 있습니다. 상황은 다양할지라도, 변수의 소유권 규칙은 언제나 동일합니다.

어떤 값을 다른 변수에 대입하면 값이 이동하고, 힙에 데이터를 갖는 변수가 스코프를 벗어나면, 사전에 해당 데이터가 이동하여 소유권이 다른 변수에 이동되지 않은 이상 drop 에 의해 데이터가 제거됩니다. 이 본질을 기억하면, 아무리 상황이 복잡하더라도 소유권 변화에 대한 흐름을 금방 파악할 수 있을 것입니다.

References

https://doc.rust-kr.org/ch04-01-what-is-ownership.html