나의 얼렁뚱땅 오픈소스 참여기 - part 1

September 27, 2021

세 줄 요약

VS Code에 내가 원하는 단축키가 없길래,
xterm.js에 코드 한 줄 넣으려다가
결국 VS Code에 들어가게 되었다.

긴 이야기

자, 그럼 시작해보자. 이 이야기는 장황해질 수도 있다. 그래도 내용은 별 거 없고 사실 위에 적은 게 다다. 하지만 우리는 뭐하러 블로그에 글을 적고 그걸 또 읽고 앉았는가. 그냥 단지 뭐라도 구구절절 이야기를 쓰고 싶고, 읽고 싶을 뿐이지 않은가.

어느 개발자분이 그런 얘길 했다. 인터넷에 돌아다니는 수많은 정보들은 대부분 초보를 막 벗어난 사람이 초보에게 알려주는 기초적인 내용들이 많다고. 이 글 또한 그러하다. 오픈소스에 대해 잘 모르던 어떤 사람이 어쩌다 보니 코드 한 줄을 오픈소스 프로젝트에 넣게 된 이야기이다. 별 거 아니라면 별 거 아니지만, 그래도 또 누구한테는 티끌만큼이라도 도움이 될지도 모른다. 아니, 뭘 또 도움 씩이나. 그런 거 아니어도 상관 없다. 어쨌든 시시한 이야기거리 하나는 남게 될 테니 말이다.

때는 바야흐로 2021년, 지구상의 가장 대표적인 소스 코드 저장 공간 GitHub이 MS의 후원을 등에 업고 맹위를 떨치고 있고, 컴퓨터 좀 만진다는 사람들은 누구나 거기에 저장소 만들어서 이런저런 SW 프로젝트를 만들고 참여하는 시절이다. 얼굴도 이름도 모르는 사람들끼리 힘을 합쳐 좋은 걸 만들어보겠다고 지혜와 기술을 모으는 오픈소스 프로젝트! 멋지지 않은가.

나도 그런 데 한 자리 끼어서 뭔가 그럴듯한 기여를 하면 좋을 것 같다는 생각은 한참 전부터 해왔다. 폼 나지 않겠나? 그런데 뭘 어디서부터 해야 하나. 세상에 오픈소스 프로젝트는 수천 개, 수만 개는 되니 어디를 기웃거려야 할지도 모르겠고, 유명한 프로그램의 소스를 받아보아도 뭘 어떻게 해야할지 잘 모르겠고…

한편, 나도 여느 개발자들처럼 VS Code 에디터를 메인 작업 도구로 사용하고 있는 중이었다. 어느 새 대세로 자리잡은 이 프로그램에 딱히 불만은 없는데, 단 하나 아쉬운 점이 있었으니 그것은 바로 내장 터미널에서 내가 즐겨 쓰는 단축키 하나가 안 먹는 것이었다.

macOS의 기본 터미널을 보자. 이걸 안 쓰고 iTerm이나 다른 걸 쓰는 사람들도 많은 것 같지만, 나로서는 OS의 기본 앱이 큰 문제 없으면 그걸 주로 쓰는 편이다. macOS 터미널도 아직까지는 불편함을 못 느끼고 잘 쓰고 있다.

터미널을 쓸 때 곧잘 누르게 되는 단축키가 ctrl-C 이다. 아시다시피 뭔가 프로그램을 실행하다가 중단시키고 싶을 때 break 역할로 쓴다. 그런데 macOS에서 이 키를 쓰기는 좀 불편한데, 그건 Mac 키보드에서 control 키를 찾아서 누르기가 영 마땅치 않기 때문이다. 맥북의 키보드에서도 그렇고 요즘 나오는 아이맥에 딸려오는 무선 키보드에서도 control 키는 참 애매한 위치에 있다. 맨 왼쪽 아래 Fn 키 바로 옆에 한 자리 차지하고 있다.

mac-keyboard — 자, 눈으로 안 보고 control 키 눌러보라. 할 수 있겠는가?

난 아직 이걸 안 보고 제대로 눌러본 적이 없다. 그래도 별 불편은 없는 게, macOS에서 중요한 키는 command 키이기 때문에 사실 control 키는 별로 누를 일이 없기 때문이다. 딱 한 경우, 터미널에서 ctrl-C 를 누를 때 빼고는.

그런데 마침맞게도 macOS 터미널에서는 더 나은 방법이 있었으니, 그것은 바로 cmd-. (커맨드 쩜) 을 누르는 것이었다. 이게 있는 걸 알고 아주 좋았다. 이제 더 이상 control 키 찾느라 두리번거리지 않아도 된다! 그리하여 불편 없는 터미널 생활을 하고 있던 차에, VS Code에 내장된 터미널을 써보니 아뿔싸, 여기에서는 그 키가 안 먹는 것이었다.

여기서 잠깐, 왜 굳이 VS Code 내장 터미널을 쓰느냐고? macOS 기본 터미널이 좋다면서 그냥 그걸 쓰면 되지 않느냐고?

좋은 질문이다. 나도 처음에는 그렇게 쓰곤 했는데, 다른 프로젝트 소스를 몇 개 열고 왔다갔다하면서 뭘 하다 보면 개발툴 안에 내장된 터미널을 쓰는 게 낫다는 생각이 든다. A 프로젝트 소스를 VS Code 창 하나에 띄워놓고, yarn dev, git switch 등의 명령어 실행을 위해서 별도의 터미널 창 하나를 띄우고 하다가, B 프로젝트 작업을 할 일이 생겨서 또 VS Code 창 하나를 띄우고 그것의 실행을 위해서 터미널 창 또는 탭을 하나 더 띄워서 하다 보면, 이 창 저 창, 이 앱 저 앱 왔다갔다하는 게 여간 귀찮은 게 아니다. 그러니 프로젝트별로는 VS Code 창 하나씩만 띄우고 터미널은 그 안에서 내장 터미널을 열고 작업을 하는 게 훨씬 낫다. 최소한 내게는 그렇다.

결국 그렇게 문제가 불거진 것이다. VS Code, 다른 건 다 좋은데 내장 터미널에서 ‘커맨드 쩜’ 단축키가 안 먹는다는 것. 다른 사람들에게 물어보기도 했다. ‘그런 단축키가 있었어요?’ 하는 반응이 돌아왔다. 음, 아주 인기있는 키는 아닌가보군. ‘구글신에게 한번 물어보세요’

하지만 신은 내게 쉽사리 응답해주지 않았고, 나는 아쉬움을 참고 그냥저냥 불편하게 지내고 있었다. 가끔 두리번거리며 control, c, 를 눌러가면서.

그러던 어느 날.

주말이 시작되는 금요일 저녁이었나보다. 아니, 토요일이었던가? 잘 모르겠다. 어쨌든 그날 나는 무료함을 느끼고 있었고, 마침 별로 할 일이 없었다. 사실 정말 할 일이 없던 건 아니었다. ‘성질 나는데 그 문제나 한번 풀어볼까?’ 하는 생각이 들었다. 물론 진짜 성질이 난 건 아니었다.

VS Code의 github 페이지를 찾아갔다. git clone을 하고, 빌드를 해봤다. 음, 시키는 대로 하니까 실행이 되는군. 정식 배포되는 버전이랑 헷갈리지 않도록 다른 아이콘으로 표시되면서 Code-OSS 라는 이름으로 실행이 되었다. 좋아, 어디를 고치면 되는지 찾아보자. 흠, Electron 기반이고 TypeScript가 주로 쓰이고 있군. 문제가 될 만한 부분은… 잘 모르겠군.

얼마간의 삽질 끝에 얻은 소득은, VS Code에 내장된 터미널은 xterm.js 라는 라이브러리를 가져다 썼다는 걸 알아낸 것이었다. Blazing banana (feat. 치코 봉봉) 하나 먹으면서 곰곰 생각해보니, xterm에서 커맨드 쩜 단축키를 지원한다면 VS Code에서는 자연스럽게 지원될 수 있을 것이었다. 그래, 그게 낫겠어.

xterm.js의 github 페이지를 찾아갔다. git clone을 하고 빌드를 해봤다. 음, 시키는 대로 하니까 실행이 되는군. 뭐야, 여기도 TypeScript가 쓰이고 있군. 요즘은 다 이걸로 하나? 뭐 어쨌든 좋아. package.json 파일을 살펴보니 start 스크립트가 있군. 실행을 해보자. localhost 3000 포트로 뭔가가 실행되는군. 브라우저로 접속을 해보니, 오호, 디버그용 데모 페이지가 잘 만들어져 있다. 고친 다음 여기서 확인해보면 되겠네. 좋아, 어디를 고치면 되는지 찾아보자.

이거는 좀 알 것 같았다. Keyboard.ts 라는 소스 파일이 있는데 여기 보니 여러 가지 키들에 대한 동작 정의가 되어 있는 것 같았다. 내가 추가하려는 커맨드 쩜 단축키는 macOS 전용이니, isMac 조건값에 따라 동작하도록 하면 될 것이었고, 마침 비슷한 코드가 이미 들어 있었다. command-a 를 누르면 다른 OS의 ctrl-a 처럼 ‘전체 선택’이 되게 하는 코드가 보였다.

이 조건문 안에 비슷하게 넣으면 될 것 같군. 가만있어보자, 쩜 키를 누를 때의 키 코드가 뭐였더라? 콘솔에 로그를 찍어보는 게 확실하겠군. 그런데, 코드 수정하고 실행했는데 왜 콘솔에 아무 것도 안 찍히는 거지? 아, 이거는 .ts 소스잖아, .js로 트랜스파일되었는지 확인해야지. 역시 안 되었군. yarn build를 하고 다시 돌려보자. 오케이, 나온다. 쩜을 누를 때의 키 코드는 190이군. 그럼 이제 그걸 콘트롤-씨로 매핑해야 하는데… 남들 해놓은 것을 보니 대충 result.key 값을 바꿔주는 것 같군. C0 라는 namespace에 값들이 선언되어 있는 것 같은데, 오 여기 있다. 콘트롤-씨에는 ETX라는 이름이 붙어있구나. 그걸로 키 값을 바꿔주고, 어디 한번. 오, 된다. 디버그용 데모 페이지에서 커맨드 쩜이 인식된다!

xterm-demo-page — xterm.js의 디버그용 데모 페이지 화면

아, 일단 한 고비 넘은 것 같다. 잘 했으니 술 한 잔 하고 오자. (우유 마심)
그럼 이제 어떡하지? 요거 고친 거를 바로 올리면 되나? 음, 아냐. 이거를 고쳤을 때 진짜로 VS Code에서도 키가 먹는지를 확인해야겠어.

그런데, 내가 고친 xterm을 VS Code에서 쓰게 하려면 어떻게 하면 되지? 찾아보자, 찾아보자… 아, 이런 방법이 있군. xterm쪽에서 npm pack을 하고, .tar 파일을 옮겨다 적당한 데다 풀어서 package라는 폴더를 만들고, VS Code 쪽에서는 yarn add로 그 폴더를 설치. 오, package.json에서 xterm 항목이 내가 수제 가공한 버전으로 경로가 바뀌었네. 이렇게도 dependency가 연결될 수 있구나.

vscode-package-json — VS Code의 package.json에 local xterm 경로가 지정되었다.

어디 그럼, 이제 요걸로 VS Code를 실행해보자. 빌드를 한 번 해주고, Code-OSS 실행하니… 오오, 된다! (감동의 물결~)
좋아, 그럼 이제 Pull Request 올려보자.

회사 프로젝트 작업할 때 GitLab의 Merge Request 만드는 거랑 같겠지만, 그래도 혹시 몰라 xterm의 안내 페이지를 여러 번 참고해보았다. 내 딴에는 잘 한다고 수정해서 올려도, 그쪽 규칙에 안 맞는다거나 하면 안 되니까. Contributing 페이지에 뭐라고 써있나. 일단 이슈를 하나 등록하고(JIRA 이슈 같은 거겠지), 그것을 내가 고치겠다고 명시하고, 그 다음에 PR을 올리면 되는 것 같았다. 맞다, 설마 이 커맨드 쩜 단축키에 관한 이슈가 이미 올라와있거나 하진 않겠지? 기존 이슈들을 쭉 둘러본 결과 그렇지는 않았다. 좋다. 그럼 이슈를 등록하자. 커맨드 쩜 단축키가 왜 필요한지 나름대로 간단명료하게 쓰려고 노력했다.

다음, xterm.js 소스를 내 계정 밑으로 fork 했다 (처음엔 이 개념이 굉장히 낯설었다). 이제 그걸 origin 삼아서 로컬에 clone하고, 코드를 수정하고 (두 줄짜리 if 문 추가), 로컬에 커밋하고, git push 실행. 그 다음 github 웹으로 가서 PR을 작성했다. 두근두근, 설렌다. 외부 세계에 내 목소리를 내는 것이다. “저기요, 제가 이런 거 한번 고쳐봤거든요. 어떻게 좀 한번 봐주시겠어요…?”

자, 이제 루비콘 강을 건넜고, 주사위는 던져졌다. 과연 이 PR은 어떤 처분을 받게 될 것인가.

(이어지는 글: 나의 얼렁뚱땅 오픈소스 참여기 - part 2)

세 줄 요약

긴 이야기

Links