https://caseyyano.com/on-evaluating-godot-b35ea86e8cf4

고도(Godot) 엔진 평가기

작성자: Casey Yano (2023년 10월 17일)

메가 크릿(Mega Crit)에서 고도(Godot) 엔진을 평가하기 위해 진행했던 3주간의 사내 게임잼을 막 마쳤습니다.

왜 엔진을 바꾸려 하는가?

미래에서 온 분들을 위해 설명하자면, 2023년 9월 12일 유니티(Unity)는 런타임 수수료 정책을 발표했고 10일 후 부분적으로 철회했습니다.

그 사이 개발자들은 이것이 이미 출시된 게임에도 적용되는지 알지 못했고, 런타임 수수료의 정의는 모호했으며, 이를 어떻게 감지하는지에 대한 우려가 쏟아졌고, 유니티는 깃허브(GitHub)의 이용약관(TOS) 페이지마저 삭제하면서 대혼란이 벌어졌습니다.

유니티는 나중에 해당 깃허브 페이지의 트래픽이 적어서 약관 투명성 유지 방식을 삭제했다고 밝혔습니다. ???

말할 것도 없이 유니티는 이상한 후속 성명과 부실한 해명으로 상황을 더 악화시켰고, 다른 사람들과 마찬가지로 혼란스러워하던 직원들은 사람들을 진정시키기 위해 최선을 다했습니다. 대재앙이었습니다.

초기 문제와 후속 상황에 대한 자세한 내용은 관련 링크에서 확인할 수 있습니다.

유니티가 한 짓은 멍청한 짓이었습니다. 저는 애초에 그들의 엔진을 그렇게 좋아하지도 않았고, IPO 상장 이후 버그가 많은 컴포넌트들을 고치지도 않으면서 수수료를 덧붙이는 '커뮤니티를 위한' 엔진이라는 말을 들었을 때 전혀 독립적인 인디 개발자라는 느낌을 받지 못했습니다.

그래서 메가 크릿 팀과 저는 약 일주일 동안 고도를 평가한 후, "고도는 절대 이런 걸 못 한다"라거나 아키텍처상의 함정(예를 들어 창작자가 ECS에 너무 광적으로 집착한다거나) 같은 문제점들을 검토하기 위해 2주짜리 게임을 만드는 것이 최선이라고 결정했습니다.

그런데 왜 고도(Godot)인가?

게임 엔진을 선택할 때 제가 고려하는 몇 가지 요구 사항이 있습니다. 주로 생각나는 것들은 다음과 같습니다:

단순한 게임 라이브러리 이상의 기능: SDL이나 LWJGL로 작업해 본 경험상, 조금 더 친절하게 안내해 주는 엔진을 원합니다. 리소스 로딩/언로딩, 폰트 처리, 디스플레이 처리를 위한 사내 API 몇 개 정도는 있었으면 합니다. 그런 것까지 직접 짜고 싶지는 않습니다. 저는 게임을 만들고 싶으니까요!

정적 타입 언어(Statically-Typed Language): 비주얼 스크립팅, 드래그 앤 드롭 전용 에디터는 절대 사양하며, 동적 스크립팅 방식도 원치 않습니다. 저는 C++, C, Objective-C, Java를 다룰 줄 알고 Python과 JavaScript도 알지만 제게는 그저 찝찝할 뿐입니다. 제가 이 언어들로 작성하는 코드가 문제라기보다, 회사 내에서 모든 것을 정적 타입으로 작성하도록 강제할 방법이 없기 때문입니다. 저는 제 토끼가 어디에 똥을 쌀지도 강제하지 못합니다.

커뮤니티:

고도는 열정 면에서 대중적인 대안처럼 느껴집니다.

인기가 많을수록 공통적인 문제들이 더 많이 해결되고 논의됩니다.

저는 똑똑한 사람이 아닙니다.

문제를 빠르게 해결하지 못하면 그냥 대충 임시방편으로 때우고 넘어갑니다.

그래도 프로젝트를 위해 높은 완성도를 가진 해결책을 찾아서 적용하는 것을 선호합니다.

우리는 소규모로 효율적으로 일하기 때문에 굳이 바퀴를 다시 발명하고 싶지 않습니다.

제가 볼류메트릭 클라우드를 직접 구현할 것 같나요? 사양하겠습니다.

포팅(Porting):

직접 포팅을 하고 싶습니다!

슬레이 더 스파이어(Slay the Spire)에 LibGDX를 선택했던 이유는 PC, Mac, Linux를 지원할 수 있었기 때문입니다.

네, JavaVM에서 돌아가고 온갖 문제가 있지만 '한 번 작성해서 어디서나 실행(Write once, run anywhere)' 아니겠습니까?

아니었습니다.

콘솔에서는 실행되지 않았고 Mac과 Windows 업데이트는 끊임없이 충돌을 일으켰습니다.

어쨌든 포팅은 어려운 일인데, 고도의 경우 W4Games가 포팅 툴을 개발 중인 것으로 보이며 콘솔 포팅을 진행하는 다른 회사들도 있습니다!

매우 멋진 일입니다.

닌텐도 스위치로 나온 브로타토(Brotato)와 카세트 비스트(Cassette Beasts)라니 👀!?

일반적인 엔진 속도, 업데이트 빈도, 인터페이스의 쾌적함, 그리고 소유자/설립자가 '존 리치티엘로(전 유니티 CEO) 증후군' 증세를 보이는지 여부 등 엔진을 선택하는 다른 이유들도 있습니다.

고도는 이러한 요구 사항들을 충족했고 C#도 지원한다고 되어 있었습니다.

좋습니다. 게임을 만들어 봅시다.

댄싱 듀얼리스트(Dancing Duelists)는 어떤 게임인가?

앞서 언급했던 바로 그 게임잼 게임입니다!

프로그래머 한 명이 '대규모 포팅' 작업을 시작해야 했고 코어 프레임워크에 작업자가 너무 몰리는 것을 원치 않았기 때문에 결국 잼에 1주일을 더 쓰게 되었습니다.

저희는 덱빌딩 오토배틀러를 만들기로 했습니다.

익숙하기도 하고, 저희가 만들기 좋아하는 장르의 요소들(콘텐츠가 방대하고 결정론적인 게임)을 많이 담고 있기 때문입니다.

https://youtu.be/ocDoNhz5JkM?si=RGWUGr05QjIFmI-C

Dancing Duelists Gameplay (GameJam) v2

Some gameplay footage for Dancing Duelists, a gamejam game by Mega Crit for Godot exploration :).

youtu.be

(일부 공개)

게임 콘텐츠 파이프라인

다른 회사들과 달리 저희는 기획 중심(design-first) 회사이며, 두 명의 게임 디자이너(저와 앤서니) 모두 기술적으로 능숙하여 여러 툴을 따로 만드는 번거로움을 피할 수 있습니다.

유니티에서 작업할 때도 저희는 프리팹을 콘텐츠로 만들거나 Scriptable Object를 콘텐츠 데이터 저장 수단으로 사용하는 방식을 지양했습니다.

마우스로 이리저리 클릭하고 싶지 않았고, IDE를 사용하는 것이 훨씬 빨랐기 때문입니다.

정의와 매개변수를 오가기 편하고, 강력한 검색 기능을 사용할 수 있으며, 엔진이 코드 줄을 정확히 짚어주면 버그를 해결하기도 훨씬 수월합니다.

이러한 '코드 기반 콘텐츠(Content-as-code)' 아키텍처는 슬레이 더 스파이어를 만들 때 사용했던 방식 그대로이며, 이번 카드 게임잼에서도 고도 엔진에서 완벽하게 작동했습니다.

프로그래밍이라는 단어에 거부감이 있는 비기술직 디자이너라면 다음 코드를 살펴보세요.

저희가 '백플립(Backflip)'이라는 카드를 구현한 방식입니다.

인스펙터나 특수한 데이터 포맷을 사용하는 것보다 이 방식이 훨씬 순수하다고 생각하지만, 개인 취향에 따라 다를 수 있습니다.

C#

public sealed class Backflip : CardModel { 

    public override string Title => "Backflip"; 

    public override string Description => "Deal 2 damage.\nGain 2 HP."; 

    protected override string PortraitPath => "backflip.png"; 

    public override async Task OnPlay(FighterClashState owner, FighterClashState target) { 

        await FighterCmd.Damage(target, 2, owner, this); 

        await FighterCmd.GainHp(owner, 2, owner); 

    } 

}

이 게임 콘텐츠를 구현하기 전에 화면 간 처리 로직, UI, 애니메이션, VFX, 오디오, 폰트 등을 위한 프레임워크를 먼저 구축해야 했습니다.

대부분의 엔진과 마찬가지로 매니저, 팩토리를 구성하고 경쟁 상태(Race condition)를 방지하면서 게임 콘텐츠를 최대한 쾌적하게 추가하고 트러블슈팅할 수 있는 최적의 방식을 찾아야 했기에, 잼 기간의 대부분을 여기에 쏟았습니다.

화면과 오브젝트

저는 화면을 로딩하고 언로딩하는 작업을 싫어합니다.

불필요하게 느리고, 정리(cleanup) 방식이 난해하며, 온갖 다양한 데이터를 이곳저곳으로 넘기는 기발한 방법을 고안해야 하기 때문입니다.

2D 게임처럼 언로드하고 로드해야 할 대상이 작을 때는 몇 가지 에셋만 내리고 새 에셋을 올릴 수 있습니다.

확신이 있다면 사전에 비동기로 미리 로드할 수도 있습니다.

유니티와 고도 모두 부모/자식 관계로 오브젝트를 시각화하고 씬 리로딩을 피할 수 있어 유연합니다.

현대 게임 엔진의 멋진 점 중 하나입니다.

씬 트리를 시각화해서 보지 않으면 가끔 오브젝트를 미처 정리하지 못하고 남겨두는 경우가 생깁니다.

씬 트리가 나온 김에 이야기하자면, 유니티에는 씬(Scenes)과 프리팹(Prefabs)이 나뉘어 있습니다.

고도에서는 이 둘이 scenes라는 하나의 개념으로 합쳐져 있으며, tscn 포맷으로 저장되어 Git과 완벽히 호환됩니다.

정말 대단합니다.

Perforce가 과연 유용한 툴인지 회의감이 들게 만들었던 유니티의 YAML 방식보다 훨씬 낫습니다(Perforce는 유용하지 않습니다, 반박 환영).

끔찍했던 프리팹 병합의 시대는 끝났습니다.

물론 씬에 변경 사항이 너무 많으면 약간의 문제가 생길 수 있지만, 정말 '약간'에 불과합니다.

이러한 씬 내부의 오브젝트들을 노드(Node)라고 부릅니다.

즉, GameObject가 Node가 된 셈입니다.

컴포넌트를 여러 개 붙일 수는 없지만, 대부분의 요구 사항을 처리할 수 있는 다양한 노드 확장 클래스들이 존재합니다.

없다면 기본 Node 클래스를 상속받아 직접 작성하면 됩니다.

저는 워낙 깐깐한 편이라 이 방식이 오히려 마음에 듭니다.

온갖 컴포넌트로 뒤범벅된 유니티의 프랑켄슈타인 같은 GameObject들은 항상 마음에 들지 않았습니다.

하루 종일 인스펙터를 스크롤하는 것은 고통스럽습니다.

논란의 여지가 있겠지만, 저는 모니터 전체 화면을 활용해 빠르고 매끄럽게 게임을 만들고 싶고 Alt+Tab을 너무 자주 누르고 싶지 않습니다.

때로는 노드의 여러 설정을 만져야 하지만, 각 노드가 가진 제한된 파라미터가 오히려 작업의 선을 지켜준다는 느낌을 받았습니다.

UI 레이아웃

노드 이야기가 나온 김에 덧붙이자면, 노드를 부모-자식 관계로 묶고 다양한 지점에 앵커(Anchor)를 잡는 방식은 게임 UI를 배치하고 다양한 화면 비율 및 해상도 호환성을 높이는 현대적인 방식입니다.

자체 엔진을 만드는 개발자들이 왜 UI 작업을 싫어하는지 궁금하다면, 바로 이런 시스템을 직접 구현하고 싶지 않기 때문입니다.

번거롭고, 또 다른 생소한 화면 비율을 지원하게 되었다고 해서 딱히 무언가를 성취했다는 느낌도 들지 않습니다.

유니티와 고도 모두 리스트나 그리드로 정리할 수 있도록 피벗, 앵커, 다양한 컨테이너를 제공합니다.

때로는 매우 헷갈릴 수 있는데, 특정 변수가 잠길 때는 그 이유가 아주 명확해야 한다고 생각하지만 결코 그렇지 않습니다.

최악의 경우에는 "부모가 화가 났기 때문에 이 작업을 수행할 수 없습니다"라는 식의 팝업이 뜹니다.

그래서 학습 곡선이 존재하며, 유니티는 UI Toolkit을 통해 이 모든 것을 갈아엎기로 결정했습니다.

기본적으로 비디오 게임에서 UI를 만드는 과정은 영원히 재앙으로 남게 될 것입니다.

UI 작업을 즐기는 사람은 고작 6명 정도에 불과하고, 유니티 책임자는 프론트엔드 웹 개발자 출신일 것이며, 이제 모든 인디 개발자는 그 방식을 강제로 배워야 하기 때문입니다.

조의를 표합니다.

어쨌든 고도와 유니티 모두 UI용 특수 노드들은 형편없습니다.

맞습니다.

과거에도 형편없었고 앞으로도 형편없을 것입니다.

게임에는 복잡한 UI 예외 케이스가 많아서 일반적인 템플릿을 빌려 쓰면 게임의 질이 떨어집니다.

UI는 User Interface의 약자이며, 유저(플레이어)가 인터페이스(게임)와 상호작용하는 통로입니다.

초보 개발자들은 모두 기본값을 사용합니다.

버튼 색상이 미세하게 바뀔 때: "아, UI 개발자가 게으른 유니티 게임이군."

글자 위에 마우스를 올렸는데 마우스 커서가 텍스트의 벡터 외곽선에 정확히 닿아야만 반응할 때: "아, 플래시 게임이군. 어떻게 2023년에 아직도 플래시 게임을 하고 있지?"

유니티의 못생긴 기본 'Font' 컴포넌트 버튼과 UI 컨트롤에 대해서는 말도 꺼내지 마세요.

그렇지만 TextMeshPro는 정말 훌륭했습니다.

그립네요. 제발 글꼴 자동 크기 조절의 최소/최대치를 깔끔한 직사각형 안에 수직 중앙 정렬만 할 수 있게 해줬으면 좋겠습니다.

텍스트를 보기 좋게 만들기 위해 자체 코드를 작성해야 했습니다.

저는 폰트와 텍스트에 매우 신경을 많이 씁니다.

(저희 디스코드 서버에는 제가 폰트 이야기를 너무 많이 하면 경고를 주는 봇이 있을 정도입니다.)

그래도 고도에서 MSDF(Multi-channel Signed Distance Field)를 지원하는 것을 보고 기뻤습니다.

멋진 기술입니다!

모서리가 아주 날카롭고 스케일링도 훌륭합니다.

완전히 작동하지 않을 때만 빼고요. 😢

(네, 예제 프로젝트와 함께 이슈를 제보할 예정입니다. 방금 잼을 끝냈으니 시간을 조금만 주세요.)

C#을 실제로 제대로 지원하는가?

C#에서는 특정 API에 접근할 수 없지 않을까?

씬에서 오브젝트를 찾는 것이 번거롭지 않을까?

컴파일할 때 항상 업데이트 중이거나 불안정하지 않을까?

IDE에서 고도 에디터로 Alt+Tab을 누를 때마다 매번 10초씩 스크립트를 컴파일하느라 워크플로우가 엉망이지 않을까?

이런 생각들은 C# 관련 이야기 중에 GDScript 전도사들이 등장했을 때 제가 가졌던 비이성적인 두려움들이었습니다.

위에서도 언급했고 다시 말씀드리지만, 저는 정적 타입 언어를 선호합니다.

느슨하고 모호한 동적 타입의 var 같은 것은 전혀 원치 않으며, 아무도 제 성향을 바꿀 수 없습니다.

저는 명확하고 장황한 것을 좋아합니다.

비슷한 맥락에서 저희는 CSV 대신 JSON을 사용합니다.

같은 원리입니다.

본론으로 돌아가서, C# 통합 수준에 매우 놀랐습니다.

제가 주로 사용하는 IDE(JetBrains Rider) 설정도 쉬웠습니다.

자동 완성이 훌륭하게 작동했고 기본적으로 IDE에서 게임을 바로 실행할 수 있었습니다.

또한 고도로 전환하여 게임을 실행하는 속도가 빨랐습니다.

정말, 아주 빨랐습니다.

유니티에서 5~10초 동안 뜨던 "Compiling Scripts..." 팝업은 늘 제 악몽에 나타나곤 했습니다.

빠른가? 그렇다

스크립트 컴파일 지연이 사라졌고 고도는 유니티보다 훨씬 가볍습니다.

하이엔드 그래픽이나 화려한 조명 기술을 원하신다면 드릴 말씀이 없지만, 셰이더, 파티클 시스템, 머티리얼 등 기본적인 요소들은 충분히 다룰 수 있습니다.

최첨단은 아닐지 몰라도 저는 잘 모릅니다.

제 관심사는 가장 화려한 장난감이 아니며, 어쨌든 저는 인디 개발자니까요.

고도는 가볍기 때문에 매번 디버그 툴을 만들거나 사용하는 대신, 게임을 실행하고 수치를 변경한 뒤 다시 실행하는 과정이 매우 쾌적합니다.

또한 런타임 중에 노드를 변경하면 실행 중인 게임에 즉시 반영됩니다!

유니티를 배울 때 "오, 이건 정말 현대적이네"라고 느꼈던 순간이었는데, 고도에서도 잘 작동해서 기뻤습니다.

유니티에 비해 몇 가지 제한 사항이 있지만 전반적으로 정말 훌륭합니다.

속도 이야기로 돌아가자면, 프로젝트를 여는 속도가 더 빠르고 불필요한 인증 절차도 필요 없습니다.

프로젝트 실행도 빠르고, 스크립팅 워크플로우도 빠르며, 빌드 익스포트도 빠릅니다.

그냥 빠릅니다!

참고: 인터넷에 raycast2d 성능에 대한 불만이 일부 있었습니다.

레이캐스트를 많이 사용할 계획이라면 관련 내용을 조금 찾아보시는 것을 추천합니다.

TexturePacking / TextureAtlas / SpriteAtlas

조금 별로입니다. 그게 전부입니다.

그래도 TexturePacker(서드파티 텍스처 패킹 툴)로 만든 파일을 읽을 수는 있습니다.

약간 번거로울 뿐입니다.

하지만 생각해보면 유니티도 게임을 실행할 때마다 패킹을 다시 하곤 했습니다.

그것도 멍청했죠.

어쩌면 이 워크플로우는 어디서든 좋았던 적이 없었는지도 모릅니다.

TextureAtlas를 사용할 때 NinePatch 텍스처를 설정하는 것이 번거롭습니다.

그리 복잡한 문제는 아닌 것 같아 기능 요청을 제출해 볼까 합니다.

댄싱 듀얼리스트의 기획상 아쉬운 점

자, 다시 댄싱 듀얼리스트(Dancing Duelists) 이야기로 돌아가겠습니다.

프로젝트 규모를 줄이기 위해 도입했던 제한 사항들과 시간 제약으로 인해 충분히 탐색하지 못했던 기획 영역들을 짚어보려 합니다.

덱이 너무 무작위적임:

초기 기획에서는 플레이어가 원하는 순서대로 덱을 구성할 수 있었습니다.

덱은 위에서 아래로 자동 실행되는 방식이었습니다.

하지만 이를 직관적으로 만들려면 상당한 UX 작업이 필요하고 밸런스를 맞춰야 하는 복잡성이 커집니다.

게임을 빠르게 플레이테스트 가능한 상태로 만들 수 있을 거라 예상하지 못했기 때문에 문제가 있는 콘텐츠를 다듬기 위한 여러 차례의 테스트 세션을 진행할 여유가 없었습니다.

이 무작위성 덕분에 잼 규모에 맞게 단순함을 유지할 수 있었습니다.

턴 순서 문제:

누가 먼저 공격할 것인가?

무승부는 어떻게 처리할 것인가?

멀티플레이어라면 누가 선공을 잡을 것인가?

스피드 스탯?

동전 던지기?

내가 먼저 하고 그 다음 상대가 공격?

공정성을 해결해야 하는 오토배틀러 장르에서 이는 꽤 복잡한 문제였기에, 결국 플레이어가 항상 선공을 잡는 PvE 방식을 선택했습니다.

위와 마찬가지로 단순화되기는 했지만 이로 인해 게임의 깊이는 얕아졌습니다.

천편일률적인 빌드:

이상적으로는 각 파이터마다 고유한 카드 풀을 만들어 2~4개의 공통 아키타입으로 빌드할 수 있게 하고 멀티 풀, 공유 풀, 그리고 장신구(trinket) 시스템에도 유사한 방식을 적용했을 것입니다.

이 정도 양의 콘텐츠를 만들고 밸런스를 맞추며 아키타입을 탐색하는 것은 엄청난 작업입니다.

아쉽게도 이번 잼 버전의 카드 풀은 '스핀(Spin)' 카드로 도배되었습니다.

더 많은 한계가 있었지만, 이러한 가지치기 덕분에 짧은 시간 안에 게임을 완성할 수 있었다고 생각합니다.

게임의 잠재력을 온전히 실현하지 못한 것은 아쉽지만, 실용적인 태도를 취하고 엔진 탐색을 위한 게임잼에 너무 집착하지 않는 것이 좋습니다.

멀티플레이어?! 아쉽게도...

오토배틀러 장르의 특성에 맞춰 이번 잼 게임을 멀티플레이어로 만들지에 대해 고민이 많았습니다.

하지만 몇 가지 기획적 문제를 해결하지 못해 결국 구현하지 못했습니다.

이는 곧 저희가 직접 게임을 플레이하고, 덱을 저장한 다음, 그 덱들과 대전해야 함을 의미했습니다.

플레이테스트를 통해 이 데이터를 수집하는 과정이 예상만큼 원활하지 않아 자동화 스크립트를 돌렸습니다.

"머신러닝?", "AI?", "신경망 뭐시기?"를 썼냐고 물으실 텐데, 전혀 아닙니다.

무차별 대입(Brute force) 방식이었습니다.

"턴 순서 문제"로 인해 게임이 비대칭적이었고, 매 전투 시작 시 덱이 무작위로 섞이면서 큰 변수가 생겼기 때문에 저에게는 이 방식으로 충분했습니다.

앞서 고도가 작업하기에 빠르다고 말씀드렸지만, 실행 리소스도 매우 적게 소모합니다.

(고도의 성능은 꽤 훌륭해서 오디오/애니메이션을 모두 켠 상태로 한 번에 약 15개의 인스턴스를 동시에 실행할 수 있었습니다.)

그래서 카드 선택을 무차별 대입으로 돌려 플레이어가 만든 작은 덱들과 싸우게 한 뒤, 승리하면 그 덱을 저장하여 게임에 다시 통합했습니다.

파이터당 라운드별로 약 20개의 고유 덱을 원했고, 플레이어가 만든 덱을 이길 수 있는 최소한의 전투력을 갖춘 약 1,200개의 고유 상대를 만들어냈습니다.

데이터 양이 많아 보이지만 고작 2MB에 불과합니다. 이 덱들은 JSON 파일로 저장됩니다.

(예시 JSON 데이터 생략)

결과적으로 현재 파이터로 연승할수록 난이도를 높이기 위해 마련했던 strength 변수는 사용하지 않았습니다.

마무리하며

해냈습니다!

단 3주 만에 지금 바로 다운로드해서 플레이할 수 있는 진짜 비디오 게임을 만들어냈습니다:

Dancing Duelists 플레이 링크

입력 처리, SDK 연동, 화면비 대응, 현지화, 하드웨어 호환성, 서드파티 플러그인(저희는 Spine2D와 FMOD 사용), 모드 지원 등 다뤄야 할 주제가 더 많지만, 좋은 비디오 게임을 만드는 것은 단거리 경주가 아니라 마라톤입니다.

이번 후기는 여기까지 작성하겠습니다.

제가 결코 고도 전문가는 아니지만, 진짜 2D 비디오 게임을 만들기 위한 도구들은 충분히 갖추어져 있는 것 같습니다.

🔥 실시간 네티즌 베스트 반응

• NORU고도 너무 강하다앗!!
• Indie1오 여기 고도+시샵으로 만들었구나 gd스크립트 새로배우기 부담스러운데 시샵은 제대로 지원하나 궁금했는데 완성까지 간거보면 시샵으로 해도 되겠군
• 비월슬더스2도 C# 썼을라나?
• ㅇㅇ유니티 안건들고 UI 동적으로 생성하는거 AI로나 하는짓인줄 알았는데 실제로도 하는거였구나
• ㅇㅇ잘 읽었습니다