NDC Replay

내가 만든 언어의 개발환경을 Visual Studio Code로 빠르고 쉽게 구축하기
강성훈, 이승재
넥슨코리아
이승재: 스튜디오 공용 게임서버엔진을 개발하고 있습니다. <마비노기 듀얼>, <마비노기 2: 아레나>, <데스크탑 히어로즈>, <카바티나 스토리> 개발에 참여했습니다. <br/>강성훈: 대학원에서 프로그래밍 언어 전공으로 석사 졸업 후 여러 벤처기업에서 백엔드-프론트엔드와 아키텍처를 가리지 않고 개발을 해 왔습니다. 넥슨에서는 <마비노기 듀얼>의 서버 프로그래밍을 담당했다가, 모두가 동적 언어에 지친 틈을 타서 오랫만에 전공을 살려 카일루아라는 언어를 개발하는 중입니다.
도메인 특화 언어를 개발할 때 파서와 인터프리터 만들기는 대략 비용을 예측할 수 있습니다. 학교 과제로, 혹은 취미로 해본 경우도 많습니다. 그러나 디버거와 IDE 통합(자동완성, 정의로 바로가기, 리팩토링 등)은 만들 엄두가 나지 않습니다. 그런 점들 때문에 도메인 특화 언어를 적용하기 좋은 상황을 놓치기 쉽습니다. 이 세션에서는 최근에 나온 IDE인 Visual Studio Code를 사용해서 새로운 언어의 개발환경을 빠르게 만드는 방법을 Lua 디버거와 Kailua의 예를 들어 설명합니다.
[새 창에서 슬라이드 보기]
안녕하세요. 시작하겠습니다.

저는 데브캣 스튜디오의 이승재고요. 2007년부터 게임 개발을 하고 있는 프로그래머입니다. 가장 최근에는 <마비노기 듀얼> 개발에 참여했고요. 지금은 스튜디오에서 사용하는 서버 엔진을 만들고 있습니다.

이 발표의 제목은 “내가 만든 언어의 개발 환경을 Visual Studio Code로 빠르고 쉽게 구축하기”이죠. 내가 만든 언어. 눈치를 채셨겠지만 이거는 직전 시간 발표에 이어지는 내용입니다. 직전 시간 발표를 안 들으신 분 손 좀 들어주시겠어요? 네, 꽤 되시네요. 감사합니다. 직전 발표를 안 들으셨더라도 이해하시는데 문제가 없도록

도메인 언어에 대한 부분을 짧게 짚고 넘어가겠습니다. 이건 제가 좋아하는 실용주의 프로그래머라는 책에 나오는 구절이에요. (웃음) 전혀 웃기려고 의도한 포인트가 아닌데 왜 웃으시죠? 당혹스럽네요. 읽어보겠습니다. “어떤 애플리케이션 프로그램을 제어하거나 환경 설정하기 위한 단순한 언어든, 규칙이나 절차를 명시하기 위한 더 복잡한 언어든, 우리는 여러분의 프로젝트를 문제 도메인에 가까운 곳으로 옮길 방법들을 궁리해봐야 한다고 생각한다. 더 높은 추상화 수준에서 작업함으로써 사소한 구현의 세부사항들을 무시하고 도메인의 문제들을 푸는 일에만 정신을 집중할 수 있다.” 도메인 언어에 대한 설명은, 개념에 대한 설명은 대충 이 정도로.

도메인 언어를 꼭 텍스트로 만들 필요는 없습니다. 언리얼 엔진에도 블루프린트가 들어있죠. 하지만 텍스트로 만드는 데는 나름의 장점이 있습니다. 일단 작동하는 첫 버전을 빠르게 만들 수 있어요. 비주얼 스크립트는 일단 편집할 툴이 있어야 시작을 할 수 있죠? 물론 블루프린트 같은 내부 솔루션을 가져오면 좀 더 빠르게 시작할 수 있겠습니다만은. 그리고 변경을 추적하기가 쉽습니다. 텍스트 포맷은 아무래도 버전 컨트롤 시스템 친화적이죠? 그리고 대규모 리팩토링을 하기가 쉽습니다. 텍스트 에디터가 여기도 대량 작업할 때는 편하죠. 그리고 텍스트니까 검색이 쉽습니다. 과거에 만들어서 썼던 텍스트 기반 도메인 언어의 샘플을 몇 개 보여드릴게요.

이거는 <카바티나 스토리>에 썼던 AI 스크립트입니다. 언어 이름은 FSM이고요. 원래 플레이어 조작기에 사용했었는데 AI도 사용을 했습니다. 대충 어떤 느낌의 언어인지 한 번 쭉 보시고요. 일단 먼저 -> 왼쪽에 있는 게 조건식이고요. 이 조건이 만족이 되면 할 행동을 -> 오른쪽에 적고 그리고 그다음에 트랜지션할 스테이트를 [] 안에 적습니다. 그리고 $로 시작된 색깔이 다른 텍스트는 몬스터 종류마다 달라지는 상수값이고요. 이제 이거의 경우에는 상수값을 참고하는 조건식이 되겠습니다. 몬스터 종류마다 스킬 평타의 종류가 다르고 몬스터 종류마다 다르게 동작하게 하기 위해서 있는 거고요. 이제 이거는 되게 여러 코드를 되게 짧은 형태로 쓸 수 있는데 이거를 우리가 보통 쓰는 C#이나 C++로 표현을 하려고 하면 상당히 길어지겠죠.

그리고 이거는 <마비노기 2>에 사용했던 AI 스크립트입니다. 이름은 HFSM이고요. NDC 13에서 발표를 했었습니다. 이것도, 잘 보이시나요? 글씨가 좀 작은데. 이것도 어떤 느낌인지 한 번 천천히 보시고요. 이 언어에는 변수를 넣었습니다. 그래서 다른 C++스러운 그런 언어에 가까워졌고요. 우리가 보통 보는. 그리고 변수를 초기화하는 걸 좀 편하게 했고 상태 트랜지션 하는 거 역시나 들어가 있고요. 이거는 우리가 보통 보는 언어에 잘 없는 거죠. 그리고 실행 중 일시정지하는 거 넣었고요. 요새는 보기 쉽습니다만은.

그리고 세 번째로 이거는 <데스크탑 히어로즈>에서 만든 던전을 서술하는 스크립트고요. 이거는 Lua를 그대로 썼는데 Lua 위에다 올린 거고 게임 디자이너가 사용할 수 있는 부품을 많이 제공을 한 사례입니다. 어떤 느낌인지 좀 보세요. 일단 한글이라서 읽을 수가 있죠. 어떤 뭘 하는 건지를. 여기도 시간 지연하는 거 집어넣었었고 한글 쓸 수 있고 복잡한 기능을 가진 부품을 조립해서 사용할 수 있게 했고 이거는 메인 흐름이랑 상관없이 다른 이벤트가 발생했을 때 할 일 같은 걸 여기다 적고 그다음에 스크립트 전체가 끝날 때까지 기다림. 뭐 이런 겁니다.

그럼 방금까지 보여드린 제가 과거에 프로젝트들에서 만들어서 잘 썼던 거를 프로젝트 하나당 하나씩 예제를 보여드렸는데요. 이거를 어떻게 만들면 되는지, 이게 사실 좀 의외로 간단합니다. 구문 분석이랑 실행하는 걸 그냥 만들면 돼요. 이 발표에선 여기에 대해서 자세한 내용까지 다루지는 않고요. 간단하게 이런 방법들이 있다 정도까지만 집고 넘어가도록 하겠습니다.

구문 분석, 즉, 텍스트 구조를 파악하는 방법부터 살펴볼게요. Line by Line으로 분석을 하는 방법도 있고 Recursive Descent Parser라는 방법도 있습니다. 파서 생성기를 사용할 수도 있고요. 가장 일반적인 방법인 것 같은데 저는 별로 안 좋아합니다. 학교 다닐 때 Lex, YACC 이런 안 좋은 기억 때문에 그런 것 같기도 하고요. 간단한 언어일 경우에 라인 중심 형식의 언어를 쓰는 걸 추천을 하고 복잡한 언어일 경우에는 Recursive Descent Parser를 만드는 걸 추천합니다. 앞에서 보여드렸던 예제 3개 중에 Lua는 Lua로 만든 거고 HFSM은 Recursive Descent Parser로 만들고 FSM은 라인 중심 형식 언어로 만들었었습니다.

그리고 실행기를 만드는 방법인데요. 이거는 구문 분석하면서 만들어 낸 트리를 그냥 평가하는 방법이 있고 다른 언어로 트랜스파일하는 방법도 있고요. 그러니까 다른 언어의 코드를 생성하는 거예요. 그리고 바이트코드로 컴파일해서 실행을 할 수도 있습니다. 이거 <마비노기 2>때 했었는데요. 최대 장점은 만들기가 재밌다는 겁니다. 로딩도 빠르고 실행하는 것도 빠르겠죠? 그런데 솔직히 만드는데 되게 오래 걸립니다. JIT는 JIT, JIT 많이들 그러는데 저 되게 무섭고요 이거. 이건 자세히 설명 안 드리고 넘어갈게요. 실행기 설계할 때는 이게 발표 본 내용이랑 별 상관은 없지만 바인딩 그러니까 호스트 언어랑 상호작용하는 거를 어떻게 만들지 미리 고려하는 거 잊으시면 안 되고요. 구문 분석 결과를 트리로 분석해놓고 평가하는 이 방법이 가성비가 좋아서 추천을 드리고 코드를 동적으로 로드를 하고 실행할 수 있는 언어에서는 트랜스파일을 하는 것도 괜찮겠습니다.

구문 분석이랑 실행하는 거 말씀을 드렸는데요. 이거는 학부 때 컴파일러 수업을 들었으면 충분하고요. 안 들었어도 선택지도 되게 많고 참고 자료도 많습니다. 일단 이 구문 분석이랑 실행이면 동작을 하는 초기 구현을 만들 수가 있어요. 그런데 심지어 안 해도 됩니다. 구문 분석이랑 실행기 따로 안 만들어도 되고 앞에서 보셨듯이 Lua 같은 스크립트 언어로 붙여 넣고 그 틀 안에서 만들어도 돼요.

자, 이렇게 동작을 하는 초기 구현을 만들었습니다. 그리고 시간이 흐르면 어떻게 될까요?

도메인 언어는 상상 이상으로 강력합니다. 도메인 언어를 사용해서 만든 프로그램이 설계자가 처음에 상상했던 범위를 훨씬 뛰어넘는 범위로 자라나고요. 시간이 지나면 지날수록, 그리고 기능도 계속 덧붙이게 됩니다.

그러다 보니까 복잡도를 컨트롤해야 되는 문제가 생기기 시작하죠. 개발 환경에 대한 불만이 쌓입니다. 왜냐하면 일반 텍스트 에디터만 가지고 편집을 하는 거기 때문에. 디버깅이 안 되잖아? 자동 완성됐으면 좋겠어. 정의로 바로 가기 안 되나? 리네임은? 앍읅앍앍악 미칠 것 같아요. 너무 힘들어요.

개발 환경을 만드는 비용을 예측하기가 어렵죠. 텍스트 에디터 바닥부터 만들 수는 없잖아요. 물론 안 되는 건 아니지만, 얼마나 걸릴지 알 수가 없어요. 이걸 비용을 예측하기가 어려운 설계 혹은 비용을 예측하기 어려운 계획 이런 걸 채택하기가 되게 어렵습니다. 바로 이런 점 때문에 열악한 레거시 개발 환경에 그냥 적응을 해버리거나 그보다 근본적으로는 도메인 언어의 열악한 개발 환경을 겪어본 사람들이 그 열악한 개발 환경 때문에 다음 프로젝트에서 도메인 언어를 쓰지 말자고 결정해버리고 있는 건 아닌가? 그런 생각이 들어요. 그런데

Microsoft님께서 Visual Studio Code라는 IDE를 만들어주셨습니다. 이거 Visual Studio하고 아무런 상관없고요. 이름만 들어가 있고요. Java랑 JavaScript와의 관계랑 비슷합니다. 딱딱 그 관계고요. Visual Studio에 익숙하면 단축키 같은 게 거의 비슷하기 때문에 빠르게 적응할 수 있고 그다음에 언어별 확장 만들기가 대단히 쉽습니다.

그래서 이 발표에서는 Visual Studio Code에 Lua Debugger랑 카일루아 언어 지원을 붙여본 경험을 말씀을 드리려고 합니다. 그래서 언어별 확장을 만들 때 비용이 대략 어느 정도인지 그다음에 어떤 걸 주의해서 시행착오를 줄이고 좀 더 빠르게 만들 수 있을지 이런 거를 얻어 가실 수 있을 겁니다.

이제 디버거 확장에 대해서 먼저 얘기를 드릴게요.

이거는 사실 공식 문서가 잘 되어 있어요. 여기 발표 내용 중에 상당 부분은 공식 문서에서 얻으실 수 있는 건데 그래도 이제 문서 내용이 많고 영어이기 때문에 일단 큰 그림을 그려 드리면 도움이 될 거라고 생각해서 이해를 돕기 위해서 큰 그림 위주로 간단하게 설명을 좀 드리겠습니다. 먼저 디버그 어댑터를 만들어야 돼요. 이게 뭐냐 하면 디버거랑, 실제 디버깅하는 무엇인가랑 VS Code 자체를 중개하는 그런 프로그램이고요. VS Code가 얘를 실행을 해줍니다. 그리고 이거는 별도 프로세스로 동작을 하기 때문에 아무 언어로 만드실 수 있어요. 그냥 편한 언어로 만들면 되고요. 저는 C#으로 만들었었고 VS Code하고는 표준 입출력으로 통신을 합니다.

그림으로 그려보면 이런 꼴이에요. 오른쪽 아래에 좀 잘 봐주시고요. your-debug랑 your debugger라고 되어 있습니다. 이 두 개를 만들면 됩니다. 왼쪽에 있는 네모난 박스가 디버그 어댑터고 오른쪽에 있는 동그라미가 디버거고요. 이걸 만들면 되는데 여기 VS Code Debug Protocol이라고 돼있죠? VS Code랑 디버그 어댑터랑 통신하는 부분, 여기를 좀 더 자세히 보면

메시지가 열몇 개 돼요. 이것만 구현하면 돼요. 생각보다 많지 않습니다. 이것만 있으면 디버거를 만들 수 있어요. 이거보다 더 있는 걸로 알고 있는데 저는 이거까지만 딱 썼고요. 프로토콜 면에서는 이거까지만 구현하면 됩니다.

근데 디버거를 어떻게 만들어야 되죠? 디버그 어댑터는 대충 이런 거고 어떻게 돌아가는 건지 알 것 같고 명세대로 만들면 될 것 같은데 아 디버거를 어떻게 만들어야 되지? 이거 사실 되게 굉장히 어려운 주제입니다. 다른 프로세스의 실행을 제어를 하고 내부를 들여다볼 수 있어야 되잖아요. 그런데 네, 물론 있죠. Windows 디버깅 API가 있습니다. 이런 게 있는데 그거는 기계어를 위한 거고 머신 랭귀지를 위한 거고 Non-JIT 그러니까 우리가 아까 말씀드렸던 방법 중에 파스 트리를 만들거나 아니면 바이트코드 컴파일해서 돌리거나 이런 걸 디버깅하기에는 거의 써먹을 수가 없어요. 그거보다 한 단계 더 하이 레벨에서 돌아가기 때문에 우리가 만들 거는. 생각을 바꿔봅시다. 프로세스가 자기 자신을 디버깅할 수 있는 인터페이스를 제공을 하면 그러면 디버거 만들기가 훨씬 쉬워요. 그럼 그 인터페이스는 어떻게 생겨야 되느냐? 프로세스 관통식이니까 TCP 소켓이 가장 만만하죠. 그리고 TCP 소켓으로 만들면 디버깅하는 대상이 다른 플랫폼 이어도 되고 iOS에 돌아가는 앱을 원격으로 디버깅하는 것도 가능하죠.

자 이렇게 만들면 됩니다. 디버그 어댑터와 디버거 대상을 같이 만들어야 되는데 디버그 어댑터는 Visual Studio Code랑 디버그 프로토콜로 통신을 하고 디버그 대상하고는 우리가 만든 프로토콜로 TCP 위에서 통신을 합니다. 그리고 디버그 어댑터가 디버그 대상을 실행해주기도 해야 되고요. 디버그 대상은 디버그 어댑터에 의해서 실행되거나 아니면 단독으로 실행이 되어서 디버그 어댑터가 Attach를 해서 TCP를 통해 디버깅 명령을 받고 실행을 하면 됩니다.

그래서 저희가 실제로 만들었습니다. 세상에 마음에 드는 Lua Debugger가 단 하나도 없어서 만들었습니다. 데모 보여드릴게요.

잘 보이시나요? 글씨 너무 작나요? 그런데 제가 잘 안 보이는군요. 실행해볼게요. Lua 코드고요. 제가 테스트 용으로 쓰는 코드인데 일단 여기 nil + nil로 버그가 있는 자리에서 지금 멈췄죠? 다시 한 번 또 실행을 해보겠습니다. 여기도 버그 있는 자리에서 멈췄고요. 이번엔 브레이크포인트 좀 잡아 볼까요? 여기서 좀 멈추고 싶어요. 다시 F5로 실행을 하겠습니다. 그리고 여기 arr이라고 하는 게 뭔지 좀 열어볼게요. 오, 방금 전에 데이터 넣고 이랬던 게 그대로 잘 들어있습니다. Evaluate 해볼까요? 4라고 마지막에 썼었죠? 네, 잘 들어있습니다. 괜찮죠? (박수) 감사합니다. Step over, Step over, Step in to, Step in to, Step out, Step out, Step over, Over, Over. 이런 것도 다 잘 되고요. 뭐 그렇습니다. 데모는 여기까지 할게요.

다시 발표로 돌아와서 공개되어 있고요. VS Code 확장 검색창에 두 개가 딱 뜨는데 그중에 하나가 이겁니다. Lua를 사용하시는 분들이라면 이거를 다운로드하시고 적용을 하시면 삶이 많이 편해지실 걸로 권장을 드리고요.

이걸 구체적으로 어떻게 만들었는지를 조금만 깊게 설명을 드릴게요. Lua의 경우에는 debug 라이브러리라는 게 있어요. 이거 자체로 디버거는 아닌데 디버거를 만드는데 충분한 기본 요소들을 제공을 합니다. 이거 대부분 다 써야 했고요.

그리고 이걸 어떻게 붙이면 되냐? luasocket만 들어있으면 우리가 쓰려고 하는 환경에 luasocket이 들어 있으면 디버깅 요청을 TCP를 통해서 받고 처리해주는 라이브러리를 Lua만 가지고도 짤 수 있어요. 무슨 소리냐면 C로 확장을 안 짜도 된단 얘기에요. 이 컨셉은 제가 생각해낸 건 아니고 Zerobrane이라고 하는 Lua IDE 내지는 에디터가 있어요. 그게 먼저 구현을 했고요. 이 컨셉은 luasocket만 있으면 어떤 환경에도 붙일 수 있기 때문에 이걸 따라서 구현을 해봤습니다.

그래서 사용을 하려면 vscode-debuggee.lua라고 하는 앞에서 설명드린 Zerobrane에서는 mobdebug라고 하는데 이거를 프로그램에서 require를 하고 start()를 불러주면 디버그 어댑터에 연결이 됩니다. 아까 설명드렸듯이 VS Code랑 디버그 어댑터의 관계는 VS Code가 디버그 어댑터를 실행하고 그 서로 사이에는 CDP로 통신을 하고요. DebugAdapter.exe가 Lua 프로그램을 실행하고 그다음에 디버거가 Lua 프로그램 안에 포함이 되어서 돌아가는데 그거랑 디버그 어댑터는 자체 프로토콜로 통신을 한다. 이런 그림이죠. 그리고 여기 vscode-debuggee.lua에는

함수가 두 개 더 들어있는데 이렇습니다. enterDebugLoop()랑 poll()이라는 함수 각각이고요. enterDebugLoop()는 continue 명령이 오기 전까지는 계속 디버그 명령을 처리하게 만들었고 에러를 만났을 때 이거를 부르게 하면 됩니다. 아까 혹시 보셨을지 모르겠지만 VS Code 같은 걸로 Lua 코드를 실행하다가 중간에 에러가 나오면 여기서 enterDebugLoop() 하는 걸 확인할 수가 있고요. 그다음에 poll()은 뭐냐 하면 쌓인 디버그 명령어가 있으면 처리하고 없으면 즉시 리턴하는 함수입니다. 로직 코드에서 이걸 때때로 불러줘야 되고요. 이게 왜 필요하냐면 실행 중에 브레이크포인트 설정하는데 필요합니다. 이게 디버그 명령이 게임 실행이랑 별도로 돌아가는 게 아니라 게임의 일부로 돌아가기 때문에 이걸 가끔씩 불러줘야만 쌓인 디버그 명령어가 처리가 되어서 브레이크포인트가 찍히고 그러는 거고요. 그런데 이렇게만 만들면 무한 루프에 들어가면 Pause하거나 BP를, 브레이크포인트를 찍을 수 없다는 단점이 있기는 합니다. 뭐 만드는 게 불가능한 건 아닌데 꼭 필요하지는 않은 것 같고 버그 없이 구현할 자신도 없어서 구현을 안 했고요.

자, 이제 중요한 내용. 그런데 얼마나 걸렸는지. 디버거 만드는데 얼마나 걸렸는지인데 생각보다 되게 얼마 안 걸렸어요. 일단 루아 VM 자체를 패치를 해서 속도 저하가 없는 브레이크포인트 만드는데 약 1주 걸렸습니다. 이거 되게 좋은 거예요. 소스 공개되어 있고요. Lua 5.1 쓰시면 이거 그냥 갖다가 VM 코드 덮어 씌우시면 되고요. 데브캣 스튜디오라는 Github 조직 안에 Repository 하나 만들어 놨으니 그거 참고하시면 되고 핵심 부분, Visual Studio Code로 이게 디버깅이 되게 하는 데 약 3주 정도 걸렸습니다. 생각보다 얼마 안 걸리죠? Microsoft님 너무 감사합니다. 그리고 Gideros Player 원격 제어하는데 약 1주일이 걸렸어요. 저희 본부에서 쓰는 엔진이고요. 저희는 이거를 사용하는 게 되게 중요해서 이거를 좀 편안하게 할 수 있도록 지원을 했습니다.

이제 Visual Studio Code로 디버거 확장을 만들 때 도움이 될 만한 점을 몇 개 알려드릴게요. 첫 번째 팁은 VS Code 사이트에 있는 문서에는 큰 그림만 있고요. 개별 메시지 된 설명이 없어요. 사실 프로토콜 문서가 존재하긴 하거든요? 근데 공식 문서의 프로토콜 문서에 대한 링크가 걸려있는데 제가 그걸 영어라서 대충 읽는 바람에 존재하는 줄을 모르고 시간을 되게 많이 낭비를 했습니다. 그래서 이 문서를 사실은 TypeScript 소스 파일인데요. 개별 메시지 된 설명이 필요하면 이거를 참고하시면 되겠습니다.

두 번째 팁은 이걸 바닥부터 시작하지 마시고요. 절대. 절대 바닥부터 시작하지 마시고 잘 돌아가는 기존 디버거 확장을 찾아서 그걸 클론에서 시작하시길 권합니다. 사실은 그냥 찾지 마시고 Lua Debugger Extension 코드도 공개되어 있으니 그거를 클론 해서 고쳐나가시면 되고요. 이것 자체도 Microsoft님께서 만들어주신 vscode-mono-debug에서 클론 해서 만든 겁니다. 프로토콜 파악하고 구현하는 시간 크게 아낄 수 있으니까 꼭 그렇게 하시고요.

세 번째 이거부터는 좀 더 디버거를 설계하는 것에 관련된 얘긴데요. 실행기에 디버깅 기능을 포함을 시켜도 됩니다. 실행기 즉, 가상 머신 그런 거예요. 이게 왜 그러냐. Lua는, Lua Debugger를 만들 때 그렇게 안 하지 않았느냐? 라는 생각이 드시겠지만 Lua는 설계 철학이 되게 범용적이고 최소 주의적이에요. 그래서 디버거도 존재하지 않고 디버그 API만 있죠? 이거는 어떤 디버거라도 붙일 수 있게 하기 위해서 이렇게 만들어 놓은 거죠. 설계의 의도는 그랬지만 결과는 세상에 마음에 드는 디버거가 하나도 없는 거였지만. 그리고 소켓조차도 Lua 런타임 기본으로 포함이 되어 있지 않고 확장입니다. 그래서 우리가 작업을 할 때에는 한정된 용도의 도메인 언어를 만들고 있는데 Lua처럼 그렇게 범용적으로 최소 주의적으로 그렇게 Lua의 설계를 따라가서 만들 필요는 없다. 그렇게 생각이 됩니다.

네 번째 팁은 디버그 프로토콜, VS Code와 통신하는 디버그 프로토콜을 디버그 어댑터만 이해를 하는 게 아니라 그보다 한 칸 더 위에 있었던 디버그 대상을 직접 이해하게 만들어도 괜찮아요. 디버그 어댑터가 메시지를 번역할 필요가 없고요. 그렇게 만들면. 그리고 실제로 저희는 Lua Debugger를 만들 때 초기화랑 실행 관련 메시지만 어댑터가 인식을 하고 나머지는 전부 그냥 바로 전달을 해서 디버깅해서 처리를 하도록 했습니다. 그리고 네, 그렇게 하면 Lua, VS Code 이외의 디버거에선 쓸 수 없게 되겠지만 빨리 만들 수 있죠. 빨리 만드는 게 제일 중요하죠.

지금까지 Visual Studio Code의 Lua Debugger를 붙일 때 시간이 얼마 걸렸는지 말씀을 드렸고, 3주 걸렸어요. 그리고 디버거 확장을 만들 때 참고할만한 점은 무엇인지도 말씀을 드렸습니다. 이다음 부분은 강성훈 님께서 이어서 발표해주시겠습니다.

제가 다른 장비를 들고 왔기 때문에 잠깐만 이해를 해주시면 감사하겠습니다.

네, 발표 시작하겠습니다. 이어서 발표할 강성훈이라고 합니다.

저는 이런 사람이고요. 인터넷에서 이런저런 일들을 많이 해서 그쪽으로 알고 계신 분들도 많으실 텐데 데브캣 스튜디오에서는 <마비노기 듀얼>이라는 게임을 개발하다가 지금은 다른 일을 하고 있습니다. 그 다른 일에 대해서 말씀드릴 거고요.

제가 작년에 발표를, NDC에서 발표를 했었는데 이어지는 내용이 있어서 잠깐 재탕을 해보도록 하겠습니다.

<마비노기 듀얼>은 빡빡한 일정으로 진행된 프로젝트였고요. 서버도 처음에 급하게 붙이느라 기존의 라이브러리나 바인딩이나 그런 게 다 마련돼 있는 Lua를 가져다 쓰던 것이 지금까지 내려오게 된 거고요. 그 결과 대책이 없는 기술 부채가 쌓이게 되었습니다. 

특히 Lua라서 문제가 커진 것도 좀 있어요. Lua는 동적으로 타이핑되는 언어, 하하 이거 좋아하시는 분들 많으셔서 추가했는데, 줄여서 동적 언어라고 불리는 그런 언어인데 빠르게 붙여서 빠르게 테스트할 수 있는 대신에 특히 코드 규모가 커질수록 <마비노기 듀얼> 같은 경우에는 Lua 코드가 30만 줄 정도 되는데요. 아무튼 이상한 데서, 잘못 쓰면 이상한 데서 터지고 그렇게 된 거를 먼저 바로바로 알 수 없다. 그런 문제를 겪게 됩니다.

그래서 이것 때문에 온갖 삽질을 하다가 제가 대학원에서 전공을 프로그래밍 언어를 했어요. 그래서 아예 언어 개발을 해보면 어떨까? 하는 제안이 나와서 만들게 된

그런 것이 카일루아입니다. 카일루아는 하와이에 있는 해변 이름이고요. 제가 예쁘다는 얘기를 많이 듣긴 했는데 제가 하와이나 미국에 가본 적이 없기 때문에 이런 이름이 붙었겠죠? 그래서 카일루아는 Lua와 같은 문법을 사용하지만 타입이 잘 붙어있어서 실행을 하기 전에 체크를 할 수 있고요. 대신에 그렇다고 Lua로 실행하는데 문제는 없어야 되기 때문에 모든 추가된 문법은

이런 식으로 다 주석으로 되어 있습니다. Lua를 모르시는 분들을 위해서 말씀드리자면 Lua에서는 하이픈이 주석 두 개에요. 그런데 모든 추가된 색깔로 칠해진 것들이 다 하이픈 두 개로 시작하는 걸 보실 수 있죠. 이런 식으로 타입을 많은 곳에 지정할 수 있을 뿐만 아니라 모든 곳에 타입이 붙어있지는 않잖아요. 모든 곳에서 타입을 추론을 해주고요. 그럼에도 불구하고 Lua가 완벽하게 타입을 붙일 수 있는 언어는 아니다 보니까 여기 assume이니 whatever니 하는 그런 비상구를 여럿 가지고 있습니다. 그래서 점진적으로 있는 코드 베이스에 타입을 붙일 수 있도록 설계되어 있습니다.

그래서 이게 작년 NDC에서 발표했던 내용인데 1년이 지났죠. 도대체 무슨 일이 일어났는가?

일단 베이퍼웨어가 아닙니다. 카일루아는, (박수) 어우, 감사합니다. 여기저기 저희 조직 분들께서 계셔서 하하하하. 카일루아는 데브캣 곳곳에서 도입이 진행 중이고 특히 새로 작성되는 모든 Lua 코드는 카일루아가 붙어서 나온다고 생각하시면 되고요. 근데 작년 NDC를 할 시점에서도 도입이 진행 중이라는 얘기를 했었어요. 근데 이게 왜 1년이 걸렸냐 하면 Lua에는 C나 C++를 써보신 분들께는 null pointer 같은 그런 존재가 있는데 이게 버그의 온상이란 말이에요. 그래서 nil을 빡세게 체크하는 그런 타입 시스템을 만들었는데 써보니까 생각한 것 이상으로 많이 쓰기 어렵더라고요. 예를 들어서 Lua에서는 단순한 배열 접근만 해도 nil이 튀어나올 수 있어요. 그렇기 때문에 사용성이 너무 안 좋다. 그래서 이거는 개선이 필요하다. 타협을 해야겠다. 근데 타협을 하려면 시간이 필요해요. 그러면 그렇게 늘어난 시간을 정당화를 하려면 IDE 지원도 같이 추가해야 되지 않겠느냐? 라는 얘기가 나와서 시작한 결과가 오늘의 발표가 되겠습니다.

그래서 원래 <듀얼>은 Visual Studio랑 아까 전에 말씀하셨던 Gideros Studio 두 개를 함께 썼었어요. 근데 Gideros는, 아니 Gideros Studio는 확장이고 뭐고 할 수 있는 구조가 아니에요. 그래서 Visual Studio 확장을 만들려고 했는데 이게 참 거대한 레거시 덩어린 거예요. Visual Studio 자체가 정말 오래된 프로젝트기 때문에 API가 두 종류로 나뉘어 있어요. 하나는 전통적인 COM 기반의 인터페이스가 있고 다른 하나는 MEF, Managed Extensibility Framework라고 하는 그런 두 종류의 API가 있는데 하나에만 있는 경우도 있고 둘 다 있는 경우도 있는데 둘 다 찾아보려니까 둘이 서로 동기화가 안 되어 있는 경우도 있어요. 그래서 디버깅하기가 참 까다롭고 게다가 MSDN의 문서가 있는데도 불구하고 그것만으로는 피할 수 없는 버그들이 몇 개 있어요. 그래서 여러 가지 문제를 겪고 있는 와중에

최근에 Microsoft가, Microsoft느님께서 어떤 바람이 드셨는지 Visual Studio Code라는 걸 내놓았어요. 아까 전에 말씀드렸지만 오픈소스고 크로스 플랫폼 개발 환경이고요. 그리고 웹 기술을 사용하는 그런 IDE입니다. 그런데 이제 확장 만들기 쉬울 뿐만 아니라 사실은 이게 JavaScript 기반의 TypeScript라는 언어로 작성되어 있는데요. TypeScript를 안 써도 대부분의 기능들을 구현할 수 있어요. 물론 정확하게 말하면 오늘 설명드릴 언어 확장에 관련된 부분인데요. 아무튼 그래서 처음에는 제가 Visual Studio 작업을 하면서 승재님께서 디버거 작업을 하셨는데 디버거를 카일루아랑 같이 쓰게 하려면 Visual Studio로 포팅을 해야겠다. 그래서 저는 편집기 확장도 만들었고 디버거 확장도 만들었었는데요. 제가 삽질을 하는 동안 승재 님께서 만드셨던 디버거 확장이 너무 흥해서 그래서 전사적으로 다 VS Code로 갈아타는 덕분에 제가 좀 편해졌습니다.

그래서 이런 무시무시한 일정이 탄생하고 말았는데요. 뭐 이럴 수도 있죠. 여기 보시면 VS 확장 개발에 5개월 걸린 걸로 나오는데 실제로는 5개월 중간중간에 스펙 변경하거나 하는 과정도 있어서 좀 오차가 있을 수도 있지만 이 5개월 동안 한 거를 나중에 이제 번아웃 된 다음에 코드로 넘어가기로 결정했고 그래서 코드로 재구현하고 쓸만한 상태로 만들 때까지 한 달 반 정도가 걸렸어요. 그래서 참 다행이라고 생각하고요. 그래서 이렇게 만들어진 Visual Studio Code 확장을 제가

시연을 해보도록 하겠습니다. 마침 제 노트북에 켜져 있는데 잠깐 화면 전환이 필요할 것 같네요.

이런 화면이고요. 보시다시피 색깔이 잘 붙어있는 걸 보실 수 있고요. 이 코드는 승재 님께서 만드셨던 NDC replay 관련된 코드 중 일분데 제가 테스트하는 동안 많이 썼기 때문에 이걸 사용하겠습니다. 이런 식으로 타입 정보도 잘 나오고 있고요. 물론 이제 여기서 자동 완성 같은 것도 다 작동하는 걸 보실 수 있죠. 그리고 당연하지만 여기에 타입을 지정했을 때, 예를 들어서 문자열을 이용하려고 했는데 Integer가 나오면 오류가 이런 식으로 나오고요. (박수) 물론 하하하하 좋아하시는 분들이 많으시네요. 그래서 필요한 만큼 구현을 했는데 이런 식으로 파일이라고 바꾸면 다른 데서는 변경되지 않고요. 네. 이런 종류의 확정을 만들었었습니다. 그래서 다시 돌아오면 오, 잠깐만요. 제가 화면을 전환을 해야 되는데

네, 다시 돌아가면요. 그래서 지금까지 한 얘기는 카일루아 얘기였는데요. 작년 발표를 못 들으신 분들을 위해서 다시 소개를 해드렸는데 그럼 도대체 내가 만든 언어는 어떻게 할 것이냐? 그래서 제가 카일루아를 VS Code의 IDE 연동을 한 경험을 여러분께 공유드리려고 합니다. 

그런데 이제 시간도 그렇고 세부적인 내용을 이런 식으로 슬라이드로 말씀드리는 데는 한계가 있어서 여기에서는 코드나 문서 같은 것으로 알 수 없지만 제가 삽질을 하면서 겪었던 도움이 되는 내용을 중심으로 말씀드리려고 합니다.

그래서 다양한 IDE 연동 기능을 지원하는데 각각 난이도가 달라요. 정확하게 말하면 IDE 연동하는 게 어렵다기보다는 IDE 연동을 위해서 내가 만든 언어 구현을 뜯어고치는 게 비용이 서로 다릅니다. 그래서 가장 쉬운 것부터 가장 어려운 것까지 순서를 한 번 보도록 하겠습니다.

그래서 가장 쉬운 걸로 문법 강조가 있습니다. 아까 전에 좋아하시는 분들 많으셨는데 코드가 알록달록하게 나오는 거 모두 다 좋아하시잖아요. 그런데 저는 Visual Studio에서 문법 강조를 짜기 위해서 꽤 코드를 많이 짰어야 됐는데 다행히도 Visual Studio Code 같은 경우에는 코드를 별로 짤 필요가 없습니다. 게다가 옛날에는 좀 디버깅하기에는 좀 까다로웠어요. 그런데 전용 디버깅 명령이 추가되었기 때문에 요즘은 상당히 할만합니다. 그런데 제가 코드를 짤 필요가 없다고 하긴 했지만

사실 아무리 몰라도 정규 표현식을 알아야 된다는 단점이 있는데요. 그래도 정규 표현식은 인터넷상에 많은 문서가 있기 때문에 모르시는 분들께서는 그걸 찾아보시면 도움이 되실 겁니다. 저 같은 경우에는 정규식 같은 거에는 큰 문제가 없었기 때문에 제가 앞으로 설명드릴 대부분의 다른 기능들은 다 주 단위로 걸렸는데요. 그러니까 1개월 반에서 주 단위로 걸렸는데 이거는 하루 이틀 정도 만에 구현을 할 수 있었습니다.

그런데 문법 강조가 쉽다고는 하지만 내가 완벽하게 원하는 식으로 색깔을 칠하는 거가 쉽지는 않아요. 그래서 카일루아는 Lua 기반이기 때문에 제가 언어에서 고치고 할 수 있는 게 많이 없었는데 사실 내가 직접 언어를 만들고 있다 하면 사실 문법 강조가 쉬운 형태로 자기 문법을 뜯어고치는 게 아마 앞으로 개발하는데 쉬울 겁니다. 왜냐하면 파서, 나중에 구문 분석을 한다거나 다른 IDE 연동을 한다거나 할 때 큰 도움이 될 거예요. 그리고 제가 코드가 필요하지 않다고는 했지만 필요한 경우가 좀 있는데 아까 전에 보신 것들은 예를 들어서 어떤 게 이름이다. 어떤 게 숫자다. 그런 식으로 테마에서 지정한 색깔을 사용하는 거로 되어 있어요. 근데 테마를 따르고 싶지 않고 내가 원하는 색깔을 무조건 쓰게 하고 싶다. 그러면 코드를 작성해야 됩니다. 또는 문법은 같은데 지역 변수라거나 전역 변수처럼 의미가 다를 수 있는 그런 거를 하이라이팅 해주고 싶으시면 그러면 코드를 작성해야 될 겁니다. 그런데 카일루아 같은 경우에는 이런 작업은 하지 않습니다.

그다음으로 할만한 것이 실시간 체크를 내고 오류를 표시하는 건데요. 여기서 언어 서버라는 얘기가 나오죠.

사실 기본적인 컨셉은 아까 전에 디버그 프로토콜에서 사용했던 거랑 비슷합니다. 그래서 VS Code는 원래 확장을 TypeScript로 작성하는데 항상 언어 구현을 TypeScript로 작성하는 건 아니죠. 저 같은 경우엔 Rust를 사용해서 만들었었는데요. 그래서 언어 서버라고 하는 별도의 프로세스를 두고 그 서버랑 꼬마 확장이랑 통신을 합니다. 여기서 꼬마 확장이라고 한 거는 물론 TypeScript인데요. 이거는 외부 라이브러리를 바로 가져다가 한 몇십 줄 만에 구현을 할 수 있기 때문에 언어 서버를 잘 작성하면 TypeScript에 작성하지 않고도 원하는 결과를 얻어낼 수 있습니다.

그래서 카일루아는 원어 서버에 사용하는데요. 언어 서버는 편집기랑 독립이에요. 그래서 무슨 파일이 열려있는가? 그런 정보들을 서로 동기화를 해야 되는데 이 과정에서 버그가 발생하기 쉬워요. 그런데 이제 이 작업을 맨 먼저 하는 이유는 동기화가 제대로 안 되어 있으면 오류가 바로바로 튀어나오는 걸 눈으로 볼 수 있어요. 그래서 빠르게 확인할 수 있다는 장점 때문에 이걸 먼저 하시는 걸 추천드리고요. 그리고 사실 오류 체크는 10초 그렇게 걸리지만 않으면 한 1초 정도 걸린다고 사람들이 그렇게 신경 쓰지 않아요. 제대로 오류가 나기만 하면. 그래서 좀 늦어도 괜찮으니까 대신에 이거를 특히 동시성 관련해서 좀 문제가 있을 수 있는데 편집할 때마다 체크를 하다가 체크가 동시에 몇 개가 뜨고 있어서 CPU가 다 가득 찬다거나 그런 상황만 방지하시면 큰 문제없이 구현하실 수 있을 겁니다.

그런데 이제 이게 시작하기 쉽다는 거고요. 이거를 완벽하게 만드는 예를 들어서 카일루아 같은 경우에는 다른 분들이 사용해야 되니까 완벽하게 만들 필요가 있었는데 할 일이 꽤 많아요. 일단 오류 메시지를 잘 만드는 게 쉽지는 않고요. 특히 저는 IDE 붙이기 전부터 오류 처리하는 프레임워크를 다 만들어서 썼었는데 연동하면서 제가 생각했던 것이 다 튀어서 다 갈아엎어야 했습니다. 그리고 연관된 오류 메시지 이런 식으로 여러 개가 서로 연관되어 있는 그런 메시지들이 VS Code에서는 위치에 따라 정렬돼요. 그래서 서로 떨어져서 나오기 때문에 좀 이해하기가 어렵기 때문에 저 같은 경우에 이런 식으로 합쳐놨는데 이런 것들을 다 한 번 보면서 확인해봐야 되는 문제가 있습니다. 아니면 타입 정보가 이런 식으로 나오는데 타입이 길어지면 그런 경우에는 IDE 상에서 많이 보기가 힘들죠. 그런 것들도 감안해서 타입을 줄여줘야 되고 또는 보시면 아시겠지만 이 오류가 난 위치가 정확하게 표시되고 있어요. Line by Line으로 나오는 게 아니라 이 컬럼 단위에서 정확하게 나오고 있는데 이런 것들도 위치 정보를 기록해야 되고요. 그래서 이게 참 완벽하게 하려면 할 일이 참 많은데 시작하기는 쉽기 때문에 일단 먼저 쉽게 빠르게 시작하시되 점진적으로 보완하고 시험을 하면서 개선하시는 걸 추천합니다.

그다음으로 어려운 건 정의로 가는 건데요. 이게 편리한 기능이죠? 근데 어려운 이유가 있어요. 일단 문법 요소가, 지금 커서에 있는 문법 요소가 함수 이름인지 변수 이름인지 아니면 바로 갈 수 없는 그런 물건인지를 다 알고 저장을 해 놔야 돼요. 그리고 거기에 대응하는 정의가 무엇인지도 기록해놔야지 나중에 정의로 갈 때 유용할 수 있겠죠? 그래서 처음부터 이거 신경 써서 개발하면 좀 나은데 보통은 사실 카일루아 같은 경우에는 VS 확장 만들 때 이 작업을 다 해놨기 때문에 그대로 썼지만 개인적으론 그냥 야매로 구현해도 굉장히 쓸만한 결과가 나오기 때문에 그쪽을 추천드립니다. 그래도 이제 정의로 가는 게 되면

이름 찾아 바꾸는 거 같은 건 쉬워요. 예를 들어서 이름 찾아 바꾸는 거는 파일 안에 모든 문법 요소를 돌아다니면서 이게 변수이고 해당하는 이름인지 찾아서 그걸 다 바꾸면 돼요. 물론 예를 들어서 변수가 두 개의 함수에 똑같은 이름의 변수가 있는데 그중에서 하나만 바꿔야 되는 경우 일단 로컬 변수면 한 쪽만 바꿔야 되죠? 그런 변수가 있을 수 있는데 아까 전에 정의로 가는 거를 구현했었잖아요. 그러면 정의가 다르게 가면 그러면 다른 변수다. 즉, 고치면 안 된다. 이런 거를 바로 구현을 할 수 있습니다.

마찬가지로 커서를 올려서 타입 정보를 보는 것도 근본적으론 같습니다. 그냥 타입 체크하는 시점까지 위치 정보를 들고 가면 돼요. 이쯤에서 계속 나오는 얘기가 있는데

기반 작업이란 얘기가 좀 나오고 있죠? 제가 카일루아를 처음 만들 때는 일단 구문 분석을 하고 타입 체크를 한 다음에 둘에서 나온 결과를 가지고 IDE 지원을 넣으면 되겠다라고 막연하게 생각을 했었어요. 다행히도 제가 생각한 정도의 시간 안에 나오기는 했었는데 근데 IDE 지원을 하다 보니까 결국에는

구문 분석이나 타입 체크 과정에서 만들었던 것들 다 많이 고쳐야 되더라고요. 그래서 제가 다음에 카일루아 같은 거를 또 만든다면 아무래도 구문 분석이나 타입 체크를 하는 동안에 IDE 지원을 틈틈이 작업을 하면서 설계를 보완을 해야 되지 않을까? 라고 생각합니다. 그래서 다시 돌아가면

끝판왕이 있어요. 끝판왕이 있는데 자동 완성이죠. 제가 IDE 지원 얘기를 처음 들었을 때 다른 거는 안 돼도 자동 완성은 됐었으면 좋겠다. 라는 말씀을 드렸어요. 그런데 안타깝게도 이게 참 많이 어렵습니다. 아까 전에 정의로 가기 기능을 구현하는 거에 덧붙여서 자동 완성은 사실 자기가 아직 완성되지 않은 코드에 대해서도 동작해야 돼요. 그래서 상당히 까다로운 데다가 연구 같은 게 진행 중이긴 하지만 이거를 일반적으로 사용할 수 있는 형태로 나온 게 아니기 때문에 보통 노가다를 해야 되고요. 그리고 이제 여기서 작성된 코드는 보통 재활용이 안 돼요. 다른 언어 작업을 하다 보면 여기저기서 쓸 수 있는 코드들이 나오는데 보통 여기에서 짠 코드는 다른 데서 쓸 수 없어요. 그냥 자동 완성용으로만 만들어야 돼요. 그래서 작업량이 많은 대신에 제대로 구현하면 꽤 만족도가 높습니다.

그래서 크게는 두 가지 전략을 들 수 있는데요. 하나는 전체를 다 보지 않고 커서를, 현재 커서를 기준으로 앞뒤로 조금씩 조금씩 파싱 해 나가면서 부분 파싱을 하면서 현재 위치를 알아내가는 방법이 있어요. 그리고 다른 하나는 파싱을 하면서 오류 복구를 하는 거예요. 즉, 여기서 괄호가 안 닫혔으면 어느 시점에서 닫혀야 될 거라고 적절히 경험적으로 찍어서 닫아준 다음에 오류로 내보내고요. 그다음에 그 과정에서 얻어낸 위치 정보를 사용해서 자동 완성을 한 방법이 있습니다. 카일루아 같은 경우에는 이미 파서를 작성한 상태였기 때문에 후자로 하는 게 빨라서 그렇게 구현을 했었는데 사실 제가 장단이 있다고 했지만 계속하다 보면 둘 다 써야 되는 경우가 있긴 해요. 예를 들어서 이 코드를 보시면 x에 있는 필드 목록을 자동 완성하고 있는데요. x가 무슨 필드를 가지고 있는지 알려면 일단 타입이 뭔지를 알아야 돼요. 근데 그거랑 별개로 이게 필드에 대한 자동 완성이란 걸 알려면 부분 파싱을 해봐야 돼요. 그래서 둘 다 사용할 수밖에 없는 경우가 있고 이런 문제들 때문에 구현해야 되는 양이 꽤 많습니다. 그래서 전 개인적으로는 자동 완성보다는 아까 말씀드렸던 문법 강조라거나 그런 좀 더 쉬운 거를, 가성비가 좋은 것들을 먼저 하시고 그다음에 시간이 남으시면 도전을 해보시는 걸 추천드립니다.

그래서 제가 Visual Studio에 이렇게 고통받고 있었는데요. 그런데 다행히도 Visual Studio Code 덕분에

살아났습니다. 그래서 이게 참 저희만 쓰기에는 아깝단 말이죠. 아까 전에 조직에서도 큰 박수를 받았고 그래서 아무래도 링크도 있지만 이미 알고 계신 분들도 계실 텐데요. 카일루아는 지금 VS Code Market Place에 올라와 있습니다. 그래서 바로 사용해보실 수 있고요. 지금은 배포 문제가 좀 있어요. 그래서 Windows만 되는데 앞으로는 개선할 예정이고요. 저희가 쓰기에는 충분한 완성도를 가지고 있다고 생각하지만 아무래도 많은 사람들이 써보면 버그 같은 것들이 분명 나올 것이기 때문에 그래서 피드백을 주시면 감사하겠습니다.

아, 왜 여기에 빈 슬라이드가 있을까요? 제가 작년에 NDC 발표를 할 때 질문을 여러 가지 받았었는데 공개 안 하시냐고 여쭤보신 분들이 계셨어요. 그중에는 공개를 어떻게 하느냐에 대한 구체적인 얘기를 하신 분들도 계시는데 이미 카일루아가 Market Place에 올라와 있긴 하지만 카일루아가 저 혼자 개발하다 보니까 좀 한계가 있긴 하고 더 많이 쓰이고 더 좋아지려면 아무래도

이래야 할 거라고 생각합니다. 카일루아는 오늘부터 오픈소스화돼서 공개돼 있고 지금 Github에 올라와 있고 여기 가시면 보실 수 있습니다. (박수) 감사합니다. 그래서 제가 코드를 혼자 1년 반 정도 작성하느라, 좀 그렇긴 하지만 많은 참여가 있으면 하는 바람입니다.

이것으로 모든 발표를 마치겠습니다. 감사합니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
