개알못인 당신이 웹개발을 시작한다면 (3)
개발을 알지 못하는 당신에 웹 개발을 시작한다면, 어디서부터 무얼 공부하면 되는지 알려드리겠다는 당찬 포부로 벌써 세 번째 글을 적고 있습니다. 첫 번째 글에서는 프론트엔드와 백엔드에서 공부해야 할 것들을 말씀드렸고, 두 번째 글에서는 데이터베이스와 네트워크에 대해 설명드렸습니다. 이번 글은 개발 과정에 쓰는 몇 가지 도구를 간략히 나마 정리해 볼게요.
1편: 프론트엔드와 백엔드 — https://goo.gl/7GLeQN
2편: 데이터베이스와 네트워크 — https://goo.gl/d16511
텍스트 에디터
개발은 글쓰기와 상당히 유사합니다. 원고지에 글을 쓰든, 타자기로 쓰든, 워드프로세서로 쓰든 결국 텍스트를 적는 행위이고, 그 텍스트를 인쇄해서 책자로 만들어 독자에게 전달하는 것처럼, 개발자도 소스코드라고 부르는 프로그램 텍스트를 작성해서 그것을 프로그램으로 변환해서 배포하고, 그 프로그램을 이용하는 사용자가 쓰게 됩니다. 다소 다른 점이라면, 이용자들은 소스코드를 직접 보지는 않고 프로그램의 겉모습 만을 본다는 점 정도랄까요? 그래도 개발 과정에서는 함께 개발하는 멤버들이 서로의 텍스트를 함께 보고 같이 고쳐가며 개발하므로, 적어도 개발자들끼리는 그 소스코드를 함께 읽고 씁니다.
결국 이 텍스트는 대부분의 프로그래밍 언어가 알파벳, 숫자, 몇몇 특수문자를 활용해서 작성합니다. 대부분의 프로그래밍 언어가 텍스트에 유니코드를 허용하기 때문에 한글로 작성해도 괜찮은 경우가 많습니다만, 대부분의 프로그래머들은 영문자 위주로만 작성하는 것으로 보입니다(한글코딩 참고. 깨알 홍보).
한글코딩.org — https://goo.gl/ekjKMS
이 텍스트는 텍스트 에디터라는 프로그램으로 작성하고 편집할 수 있습니다. 70년대부터 쓰이던 텍스트 에디터인 Emacs와 Vim이라는 두 제품이 가장 강력하다고 정평이 나있고, 저도 이맥스를 쓰기는 합니다만, 몇 년을 써도 익숙하다고 얘기하기 어려운 면이 있습니다. 제 능력 부족이겠지요. 때로 이맥스교와 빔교의 교인들이 서로 종교 전쟁을 벌이는 경우도 볼 수 있고, 혹시나 주변 개발자가 이 종교(?)의 교인이라면 이런 에디터를 공부하라고 얘기하겠지만, 고맙다 얘기하고 무시합시다. 정말 강력한 것은 틀림없지만, 그냥 더 접근하기 쉬운 에디터를 써도 되지 않을까 하는 생각이 듭니다.
아 좀 그만 좀 싸워, 결론도 만날 똑같이 나잖아.
요새 가장 추천할 만한 에디터로는 Atom이 제일 좋지 않을까 합니다. 만약 프론트엔드 개발만 집중해보겠다면 Brackets도 꽤 편리해 보입니다.
예전에야 서버에 직접 접속해서 텍스트를 편집해야 할 일도 잦기 때문에 서버에서도 잘 실행하기 좋은 이맥스나 Vi가 유력했지만, 요새는 서버에 직접 접속해서 편집할 일은 점점 줄어드는 것 같습니다. 그냥 내 작업용 컴퓨터에서 실행해서 다루기 편리한 에디터를 골라 쓰도록 합니다.
- Do: Atom
- Don’t: Emacs, Vim
물론 세계 최강인 이맥스와 빔이 나쁘다는 뜻은 아닙니다. 익히면 정말 강력하고 멋진 기능은 기본에다가, 뭔가 제대로 된 실력자가 된 것 같은 포스도 덤으로 따라옵니다. 저도 “난 이맥스 써” 이렇게 한마디 말할 때에도 괜히 어깨에 힘이 들어가곤 하지요. 안 쓰는 사람들도, “오 그래? (대단한 녀석이다)”라는 내색을 하기도 합니다. 이미 근 반 백 년 발전한 에디터이니 만큼, 앞으로도 오래 쓰이겠지요. 다만, 그렇게 강력하고 우아하게 쓸 수 있게 되기까지 너무 오랜 노력이 필요하다는 점이 좀 아쉽지요. Atom 같은 현대의 편리한 에디터가 더 발달하기를 기대해 보는 편도 좋을 것 같습니다. 이미 대부분의 활용면에서는 충분히 발달해 있습니다.
통합 개발 환경
Atom처럼 개발자를 위한 텍스트 에디터의 경우, 각종 개발자용 플러그인이 많이 나와있어서, 그대로 개발 작업에 써도 충분한 경우가 많습니다만, 때로는 전용의 통합 개발 환경 프로그램을 쓰는 것이 나은 경우도 있습니다. 예를 들어, Java 개발환경의 경우 인텔리J 라는 통합 개발 환경(IDE, Integrated Development Environment)에서 개발하는 것으로 결론이 난 상황으로 보입니다. 다양한 기능이 덧붙은 유료 버전도 있지만, 제가 업무용으로 사용하는 수준에서도 무료 버전으로도 충분합니다.
텍스트 에디터를 내포하고, 그 외에도 실행, 테스트, 디버그, 빌드 등의 다양한 개발 작업을 하나의 통합된 툴에서 개발할 수 있습니다. 내가 쓰는 언어에 잘 만든 통합개발환경이 잘 갖춰져 있다면 그걸 쓰면 되고, 뭔가 부족하거나 유료만 있다면, Atom에 갖가지 플러그인을 깔고, 커맨드 라인 툴을 함께 쓰며 개발하면 됩니다. 경우에 따라서는 둘 다 써도 무방합니다. 자신에게 맞는 환경을 찾아서 쓰면 됩니다.
인텔리J를 만들어서 판매하는 젯브레인에서는 파이썬이나 루비용 개발 툴도 판매하는데, 무료 버전인 커뮤니티 에디션들도 꽤 쓸만하므로, 그걸로 시작했다가 마음에 든다면 더 강력한 유료버전을 사서 써도 됩니다.
그리고, 최근에는 마이크로소프트에서 공개한 비주얼 스튜디오 코드도 아주 좋아 보입니다. 무료인데다 요새 시대에 걸맞은 편리한 기능들이 아주 우아하게 녹아들어 있어서 매력적입니다.
- Do: 비주얼 스튜디오 코드 or JetBrain사의 제품들
버전 관리 시스템
개발하며 소스코드를 작성하는 일은 일부 선입견과는 달리, 지속적인 개선 작업입니다. 시작해서 개발하고 완성하고 끝나는 것이 아니라, 지속적으로 만들고 고치고 개선하고 또 덧붙이고 줄이고 만들고 고치고 확인하고, 끊임없이 키워 내는 과정입니다. 흔히 회사의 개발팀에서 하는 일은 일정상 시작과 끝이 있지만, 사실 끝이 나지 않습니다. 계속 만들어서 업데이트 하지요. 다 만든 소프트웨어 제품이라는 건, 더 이상 쓰지 않는 제품에나 쓰이는 말입니다.
끊임없이 바꾸고, 때로는 예전 버전으로 되돌려서 확인하거나, 아니면 아예 되돌리고 그간의 작업을 버리기도 합니다. 1안으로 해보고 2안으로도 해보고 둘의 결과를 눈으로 확인해 비교하는 일도 합니다. 또 보통은 여럿이서 작업하기에, 어떤 부분을 누가 왜 바꿨는가를 물어가며 작업할 때도 있습니다.
그런 작업들에 큰 도움이 되는 툴이 버전 관리 시스템입니다. 글 쓸 때 육하원칙과 비슷합니다. 버전 관리 시스템은 소스코드를 “누가 언제 무엇을 어떻게 왜” 바꿨는지가 기록으로 남게 됩니다. “어디서” 바꿨는지만 빼고 다 남는 것 같네요. (그마저도 시간대(timezone) 정도는 남지요.) 어떤 개발자가 언제 어떤 파일의 어떤 내용을 어떻게 바꾸었는지는 자동으로 기록이 남고, “왜” 바꾸었는지는 개발자가 직접 기록을 합니다. 커밋이라는 단위로 묶어서 이 변경 내역은 “어떠어떠한 목적이나 이유로 한 작업”이라고 메시지 로그를 남깁니다. 예를 들어, 이 커밋은 “어떠어떠한 버그 수정”을 위한 것이라는 기록을 남겨 놓지요.
예전에는 선택지가 좀 있었는데, 요새는 그냥 Git을 쓰면 됩니다. 고민할 것 없습니다. 그냥 Git입니다. 이 부분은 다른 도구를 언급하는 사람이 없을 것 같은데요, 혹시 있다 하더라도 무시합니다. 이건 고맙다고 말하지도 맙시다. 요새 세상에 개발자가 다른 버전 관리 도구를 쓰고 있다면 조금 고립된 환경에 있는 것이니 다소 측은한 마음으로 위로를 해줍시다. 업무상 오래된 레거시 시스템을 유지하는 환경에서는 어쩔 수 없이 Subversion을 쓰거나, 심지어 CVS를 아직 쓰고 있을 수도 있지요. 아무튼 업무에 그런 도구를 쓴다고 해서 개인 개발 용도로 Git을 쓰지 말아야 하는 것은 아니니까요.
그래 네가 참 고생이 많다.
다만, Git은, 아니 버전 관리 시스템이라는 도구가 처음 접하기에는 다소 복잡해 보이기도 합니다. 기본 기능만을 익혀서 쓰더라도 일부러 쓰도록 해봅시다. 혼자 작업하더라도 꽤 유용합니다. 나 혼자 하더라도, 예전 버전이 필요할 때는 많거든요. 브랜치를 따서 1안과 2안으로 해봐야 그 효과를 가늠하기 좋을 때도 많고요.
도구 선택과 사용
나름 선택 안을 좁히려 분야마다 적은 선택 안을 정하려 해도 벌써 여러 도구와 언어들을 언급해버렸네요. 아마 개발이 공부하기 어려운 이유 중 하나는 그 자체가 어려워서라기보다, 너무 많은 선택 안과 다양한 길이 있어서 그 안에서 길을 잃어버리는 상황이 너무 잦기 때문이 아닐까 합니다.
개발 도구의 선택에 있어서도, 어떤 사람은 “도구는 도구일 뿐이다. 훌륭한 목수는 연장 탓을 하지 않는다”라고 말하기도 하고, 또 어떤 사람들은 “장비만 프로”의 길을 가기도 합니다. 어떤 취미든 장비는 준 프로급인데 실력은 여전히 초급자인 사람들이 더러 있잖아요? 아마도 옳은 방향은 그 중간 어디쯤이 아닐까 합니다.
깃발이 흔들리는 것도, 바람이 흔들리는 것도 아닙니다. 단지 그대들의 마음이 흔들리는 것 뿐입니다.
그리고 “훌륭한 목수는 연장 탓을 하지 않는다”라는 말도, 단지 연장 상관없이 목수 일을 잘해야 한다는 뜻일 수도 있지만, 한편으로는, 늘 평소에 연장 관리를 잘 해서 중요한 순간에 연장 핑계를 대는 일이 없어야 한다는 뜻일 수도 있습니다. 개발을 할 때도, 평소에 자신에게 잘 맞는 도구들을 틈틈이 익혀서 생산적인 개발에 전념하면서 도구 탓을 하지 말아야 하겠지요. 그렇다고 너무 도구에만 매달려도 정작 생산을 하지 못하는 상황이 될 수도 있겠고요.
이상, 3편을 마칩니다. 내용이 마음에 드셨다면 주변에 공유해주시고, 틀린 내용이 있다면 편히 지적해 주시고, 너무 마음에 안들어서 화가 난다면, 마음에 드는 글을 찾거나 직접 작성해서 공유해주세요. 그럼, 다음 편에 만나요.
1편: 프론트엔드와 백엔드 — https://goo.gl/7GLeQN
2편: 데이터베이스와 네트워크 — https://goo.gl/d16511
3편: 기본 개발 도구 — https://goo.gl/wWgqyw
4편: 기초 자료 구조 — https://goo.gl/ch4paX
5편(끝): 리눅스, 도커, AWS — https://goo.gl/KTd8WP
