관점 E. 캠프에서 코딩 멘토링 받은 이의 관점

<이글은 24시간 영어-코딩 상호멘토링 캠프 후기...의 시리즈 입니다>

캠프를 한지 벌써 2주가 지났다. 기억이 가물가물 해지고 있다. 캠프는 끝났지만 흔적은 남았다. 캠프를 하기 이전과 이후의 나는 분명 다르다. 레일즈로 엄청난 것을 해내는 건 아니지만, "댓글에서 건지다"라는 서비스에 글을 올리기도 하고, 사용하다가 작은 변화를 주기도 한다. 이를 테면 최근 글이 위로 올라가게 하는 것.

캠프를 하기 전에 그런 게 프로그래밍을 사용하면 쉽게 할 수 있으리란 것을 알고는 있었다. 하지만 그걸 실제로 구현해서 돌아가게 하는 것은 내가 할 수 없었다. 어려운 이유가 뭔가? 누군가 묻는다면 한마디로 답할 수 없지만 명확하게 아는 건 내가 하지 못했다는 것이다. 시간이 없어서, 개발 환경을 설치하는 게 익숙하지 않아서, 레일즈의 기본적인 부분은 익혔는데 뭔가 중간에 에러가 나서 막히면 한 발짝도 나아갈 수 없어서. 이유는 많을 것이다. 지금으로선 비트버킷에 들어가서 내가 생각한 작은 변화를 혼자서 적용시킬 수 있다는 게 감동스러울 뿐이다. 이제 내가 할 수 있는 것을 조금씩 늘려가면 된다. 막히면 물어볼 사람도 있다.

캠프 때를 떠올렸다. 캠프는 24시간이었지만 나의 루비온레일즈 코딩 멘토인 범재님과 대화를 나누면서 24시간은 짧다는 데 서로 동의했다. 24시간을 잘 보낼 수 있도록 미리 준비하자고 했다. 범재님은 영어로 무엇에 대해서 쓸지, 구체적으로 어떤 내용을 쓸지, 그날 돌입해서 바로 쓸 수 있을 것 같은지 시험삼아 소주제를 잡고 써보기도 했다. 내 경우에는 1. 무엇을 만들지 정하고, 2. 루비라는 언어와 3. 루비온레일즈에 대해서 조금 익혀 두기로 했다.

1. 무엇을 만들지 정하기

원래 만들려고 했던 것은 개영Q였다. 개발자가 특정 상황뱔로 던질만한 질문(예를 들면 외국 고객과 일에 대해서 얘기할 때, 외국에 취업했을 때 주변 동료에게 던질만한 질문)을 차곡차곡 써둘 수 있는 곳. 나는 이것을 모아서 영문으로 만들어서 컨텐츠로 만들면 좋을 것 같았다. 개발자의 상황별 질문으로 컨텐츠로 만드는 것은 요전에 만났던 고승원님이 주신 아이디어였고, 나는 좋은 생각이라고 생각했었다.

그런데 중간에 범재님이 이런 얘기를 했다. 작은 서비스를 만들 때, 실제 내가 계속 사용할 만한 서비스를 만들 면 좋을 것 같다고. 생각했다. 내가 개영Q에 글을 계속 올릴 수 있을까? 아니었다. 나는 개발자가 아니니까 개발자가 진짜로 던질만한 질문을 올릴 수가 없었다. 그래서 생각했다. 내가 계속 사용할 만한 서비스가 뭘까? 다른 사람들이 이용하게 만들려면 뭔가 굉장히 매력적인 것을 만들어야 하는데 지금 그런 걸 기획하고 만드는 건 무리다. 나라도 혼자서 쓸만한 무언가를 만들어야 하는데 그럴 만한 게 뭐가 있을까.

개발자영어 페이스북 그룹에서 항상 느끼는 것은, 글과 글에 달린 댓글들, 이 대화들이 흘러가서 과거에 묻히는 게 아쉽다는 것이다. 이런 저런 팁들도 나오고 기대하지 못했던 설명들도 나온다. 그런 대화들이 오갈 땐 참여하는 사람들이 최선을 다한다. 그런 것들이 모두 시간이 지났다는 이유로 흘러가서 사라져 버린다. 나는 그게 아쉬웠다. 그게 아쉬워서 나는 글을 캡쳐하고 개발자 영어 홈페이지에 개영페북 Digest라는 코너를 만들어서 거기에 시리즈로 분류하여 올리려고 해보았지만 지속적으로 옮겨두지 못하는 바람에, 그 대화들은 결국 과거에 묻히고 말았다.

그래서 생각했다. "댓글에서 던지다"라는 서비스를 만들자. 개발자 영어 페이스북 댓글에서 건진 내용들, 다시 보고 싶은 내용들을 모아두는 서비스를 만들자. 모아두면 메타 정보를 붙여서 검색도 하고, 활용할 수 있는 방법을 고민하면 된다.

이런 서비스가 없는 건 아니다. 사실 딜리셔스 같은 북마크 서비스를 사용하면 될 일이기는 하다. 하지만 지금 내가 하고 싶은 것은 뭔가 기발한 것을 만들어내는 게 아니라, 실제로 내가 사용할 수 있는 프로그램이면서, 루비온레일즈 사용의 기본기를 다지는 기회를 줄 수 있을 만한 프로그램이었다. 적당해 보였다. 이렇게 해서 기획한 게 "댓글에서 건지다"라는 프로그램이다. 이 프로그램은 감격스럽게도 헤로쿠에서 쌩쌩 돌아가고 있다.

2. 루비라는 언어 익히기
범재님은 캠프 전에 미리 준비하기 위해 두 가지를 권했다. 하나는 루비라는 언어의 기본 문법을 익히는 것이었고 다른 하나는 루비온 레일즈에 대한 튜토리얼을 읽고 따라해 보는 것이었다. 루비라는 언어의 기본 문법을 익히는 방법으로 루비 시도하기(http://tryruby.org)라는 사이트를 추천해주셨다. 큰 어려움은 없었다. 설명을 읽고 따라 쳐보고 다음으로 넘어가니 어느새 끝에 이르러 있었다. 뒷부분에 나오는 부분은 개념이 좀 와닿지 않는 것들이 있었지만 그러려니 했다. 모든 것을 지금 이해하고 넘어갈 수는 없었다. 그래도 참 다행인 것은, 이렇게 인터랙티브한 방식으로 루비 문법을 익힐 수 있다는 사이트가 있다는 것이었다. 책으로 보고 따라하려면 뭐 설치하고, 안되면 해결해야 하고.. 이런 것들이 이미 다 해결되어 있었다. 문득 이런 일들이 필요하다고 생각하고 이미 해결해둔 사람들이 대단하다고 느껴졌다.

3. 루비온레일즈에 대해 익히기
루비온레일즈를 익히는 방법으로 범재님은 railstutorial.org라는 곳을 추천했다. 나는 예전에 RoR 튜토리얼을 읽었을 때를 떠올렸다. 범재님에게도 얘기했다. 튜토리얼을 따라하면요, 뭔가 응용을 못하겠더라고요. 따라하면 뭔가 만들어지긴 하는데 조금만 바꿔보고 싶어도 할 수가 없어요. 이 튜토리얼을 읽어도 마찬가지 아닐까요? 그럼 범재님은 지긋이 미소지으며 "그럼 레일즈 튜토리얼"을 읽으시면 돼요. 나는 갸우뚱했다. 내가 전에 읽었던 튜토리얼들과는 다르다는 얘길까?

평일에는 시간이 없었고 주말에 몇 시간을 확보해서 튜토리얼을 읽기 시작했다. 컴퓨터를 켜서 따라해보기도 했다. 튜토리얼은 한 12챕터 정도 되는데 캠프 전까지 4장까지 겨우 읽었다. 읽고 따라하다 보니 나는 범재님이 지긋이 짓던 미소의 의미를 이해할 것 같았다. 이 튜토리얼은 내가 전에 봤던 튜토리얼과는 분명 달랐다.

웹프레임워크는 생산성을 높이기 위해서, 웹개발을 할 때 반복적으로 사용하는 부분들을 대신 처리해주는 것들을 준비해두고 있다. 예를 들어 RoR에서는 scaffold라는 것을 사용하면, 모델, 컨트롤러, 뷰 심지어 테스트까지 만들어준다. db:migration을 하면, db의 테이블도 알아서 만들어준다. 어떤 객체를 만들고 object.save라고 하면 db table에 알아서 넣어준다. 결국 소위 웹개발에서 기본적인 요소라고 할 수 있는 CRUD(create, read, update, delete)기능을 매우 빨리 구현할 수 있다.

scaffold라는 기능을 사용하면, 필수적인 것들이 주르륵 만들어지는데, 문제는 이것들이 뭔지 나같은 초보에게는 머리에 입력이 안된다는 것이다. 예전을 떠올렸을 때 가장 어려웠던 것은 폴더의 구조였다. 이 파일이 대체 어디 있는지 복잡하고 찾기가 어려웠다. 물론 이런 문제는 에디터의 파일 찾기 기능으로 해결할 수도 있는 것이었을 수는 있다. 하지만 자기가 만든 프로그램의 폴더 구조와 중요한 파일의 위치를 모른다는 것이 나는 이상하게 여겨졌다.

레일즈튜토리얼에서는 놀랍게도 이런 지점을 해소시켜주겠다는 약속을 했다. 우선은 스캐폴드로 CRUD를 순식간에 만들거야. 하지만 이렇게 하면 너는 레일즈의 작동방식을 이해하기 어렵겠지. 그러니 3장부터는 스캐폴드를 사용하지 않고 직접 하나하나 만들어볼거야. 나는 이부분을 읽고선 너무나 기뻤다. 이번엔 다르겠구나... 생각했다. 그리고 생각했다. 좋은 튜토리얼을 추천받는 것도 중요하구나. 그냥 내가 검색해서 아무거나 봤더라면 나는 이번에도 포기했겠지.

그리고 레일즈튜토리얼의 또 다른 놀라운점은 테스트와 버전관리, 배포에 대해서 초반부터 다룬다는 점이었다. 그것들을 미리 다뤄야 하는 필요성에 대해서도 조근조근 설명해 주었다. 초반부터 다루니 특히 테스트의 경우, 테스트의 내용이 복잡하지 않아서 이해하는 데도 큰 무리가 없었다.

사실 예전에 이호성님과 영어코딩 1:1교환을 했을 때, TDD를 하면서 만들자고 하셔서 나는 좋다고 했고, 호성님은 그게 뭔지 설명을 해주셨다. 방법도 보여주시고. 나는 그때 갸우뚱했었다. 왜 테스트를 굳이 먼저 만들어서 fail을 시키고, 구현한 다음에 테스트가 통과하게 하는 걸까? 그냥 구현하고, 테스트케이스를 만들어서 테스트를 하는 편이 더 자연스러운 흐름이 아닐까? 이번에 레일즈 튜토리얼에서 설명을 읽으면서 그 갸우뚱함이 사라진 건 아니었다. 다만 그래도 전에 들은 적은 있어서 그런지 친근하게 여겨졌고, 특히 어떤 기능을 추가했을 때 생길 수 있는 에러에 대해서 (테스트만 잘 만들어두면) 자동으로 확인할 수 있다는 게 매력적으로 여겨졌다.

원래는 캠프때도 테스트를 작성해서 뭔가 기능 구현했을 때 rails test를 딱 때려서 0 errors가 나오는 걸 보는 것을 목표로 했지만, 캠프 시작하기 전에 테스트를 작성하는 법을 잘 익히지 못했다. 그래서 아쉬운대로 테스트는 스킵했다.

버전관리의 경우, 사실 프로그래밍도 수십번을 포기했지만 git 사용도 시도하다 포기하다를 반복한 기억이 많다. 그나마 2015년에 Git+Guthub입문이라는 책을 보고 이젠 할 수 있을 것도 같다는 생각이 들어 신이나소 gitlab으로 개인 데이터를 관리했던 기억이 난다. 하지만 안 쓰다보니 다시 잊어버렸다. 레일즈 튜토리얼에서는 어떤 작업을 마무리했을 때 항상 commit을 하게 시켰다. 작은 작업단위마다 commit을 하는 것은 캠프때도 실천했다. 이제 다음의 명령어는 조금 익숙해졌다.

git status
git branch
git add .
git commit -m "커밋 메세지"
git push origin master
git checkout -b "만들 브랜치 이름"
git checkout master

뭔가 보지 않고 이렇게 쓸 수 있다니 감동이다. 그나저나 나는 깃 관련 명령어가 아리송하다고 느낄 때가 많았다. 특히 git add .는 현재 바뀐 것들을 staging area에 추가시키는 거고, git push는 현재 내가 있는 폴더의 staging area에 있는 것을 명령어 뒤에 나오는 destination에 보내는 것이다. 뭐랄까, 나에게 가장 혼란을 주었던 것은, git 명령어 뒤에 "내가 지금 있는 곳" 정보를 써주지 않았다는 것 같다. 당연한 거니까 생략했겠지. 지금 생각해보니 이런 생각이 든다. 비현실적인 생각이긴 하지만 git명령어에 조사표현이 있었으면 좋았을텐데.. 이게 목적어인지, 방향인지 알았다면 좀 더 수월했을텐데..

마지막으로 배포..

예전에 웹프로그래밍을 조금 배웠을 때를 기억한다. 항상 테스트페이지를 확인하는 것은 127.0.0.1을 주소창에 입력해서 로컬에서 돌아가는 서버에서 돌아가는(?) 페이지를 확인하는 것이다. 사실 그것도 감동이기는 했다. 뭔가 에디터에서 입력하면 로컬 웹브라우저에서 결과를 확인할 수 있었으니. 그리고 포기했다가 다시 배웠을 때는 웹서버를 따로 설치할 필요가 없고 php, mysql, apach를 한큐에 깔아주는 설치본도 나왔더랬다. 그런데 항상 아쉬움은 외부에서도 접속할 수 있도록 배포하는게 나에게는 너무 어려웠다는 것이다. 꼭 남에게 보여주는 게 아니더라도, 내가 밖에서 모바일로 접속할 수 있으려면 실제 서버에서 돌아가는 게 필요했다. 이번에 레일즈 튜토리얼에서는 초반부터 헤로쿠에 배포하는 것을 확실히 알려주었다. 지금 이시간에도 "댓글에서 건지다" 서비스는 헤로쿠에서 돌아가고 있다.

캠프 시작하기 전에 나는 튜토리얼을 읽으며 뭔가 이번에는 다른 것 같아...라고 연신 되뇌이며, 이 레일즈 튜토리얼을 쭉 따라 하면 그냥 웹개발을 할 수 있게 되는 것 아닐까 하는 생각도 감히 했다. 하지만 역시... 에러의 계절은 돌아왔고, 뭔가 조금 바꾸어봤을 때 에러가 났고 나는 도저히 해결할 수 없었다. 나는 범재님에게 SOS을 쳤다. 범재님은 시간을 내주셨고 이렇게 말했다. "분명 멘붕이 한번 올텐데 왜 얘기가 없지? 생각하고 있었어요." 범재님의 뚜닥뚜닥을 거치니 문제는 해결되었고, 나는 내가 했을 때는 왜 문제였던 걸까 스스로가 답답하게 여겨지기도 했다. 에러 화면에 사라지니 일단 살 것 같았다. 영어와 프로그래밍의 차이 중 하나를 느꼈다. 프로그래밍의 인터프리터나 컴파일러에 해당하는 건 언어에서 뭘까? 인간의 머리 안에 언어 해독기 같은 것이겠지. 사람을 앞에 두고 뭐라고 얘기하면, 뭔가 에러가 있다고 해서 아예 먹통이 되어 버리지는 않는다. 여러 가지 다른 힌트들이 있으니까. 표정도 있고 목소리도 있다. 어떻게든 뭔가 원래의 메세지에 다가갈 여지가 있다. 설사 정확히 전달되지 않더라도 "더 이상의 노력을 거부함"이라는 빨간 화면을 보인채 표정을 굳히지는 않을 것이다. 하지만 프로그래밍은 뭔가 에러가 생기면 빨간 화면을 보이며 알 수 없는 에러메세지만을 보인다. 꿈쩍도 하지 않는다. 나는 그것을 보는 게 답답하고 초초했다. 물론 프로그래밍의 장점도 있는 것 같다. 언어는 뭐라고 말을 하면 상대가 대답을 하기는 하지만, 내가 제대로 말했는지, 제대로 말을 안했으면 뭘 제대로 안했는제 정확하게 피드백을 해주지는 않는다. 스스로 설계해서 알아낼 수밖에 없다 (얘가 내 말을 이렇게 이해했다면 내가 이렇게 말하면 이런 얘기를 하겠지?) 그런데 프로그래밍에서는 어쨌든 문제에 대해서 "에러메세지"를 보여준다. 어느 쪽의 친절함이 더 나은지 재지는 말자. 다만 나는 이제까지 살아오며 전자의 방식에 익숙해져 있고, 후자는 생경하기 그지없어서 그 화면에 당황하는 것이겠지, 익숙해지겠지 할 뿐이다.

(이놈의 주저리 주저리 때메 캠프 시작 언저리에도 못갔 갔다. 캠프 때 얘기는 다음 글에서 쓰기로...)