작성일자

맥 OSX과 터미널

<편집자주> 민트기술에서는 외부 집필자의 도움으로 애플/맥에 관한 좋을 글들을 받아서, 홈페이지를 통해서 제공하려고 합니다. 이번에는 김정님께서 OS X 과 터미널에 대한 글을 기고해 주셨습니다.


터미널(Terminal)이란 단어는 일상 생활 속에서도 익숙한 단어다. 하지만 OS X에서는 누구에게나 편하기만 하지않은 미지(?)의 영역이라고 할 수 있다. 복잡해 보이는 터미널 환경에 대해 이야기해보자.
 
우리가 알고 있듯이 터미널이란 단어의 뜻은 주로 “끝에 있는”, “마지막에 있는” 무언가를 의미한다. 그래서 버스 터미널은 버스 종착역을 의미한다. 그렇다면 OS X의 터미널 앱은 어떤 의미가 있는걸까? 그것은 컴퓨터 역사에서 터미널의 역할을 되짚어 보면 알 수 있다.

초창기 대형 컴퓨터들은 엄청난 크기의 몸집을 갖고 있었다. 그리고 커다란 본체 입력을 하기 위해서, 초창기에는 천공카드 입력기를 사용했지만, 점차 타자기처럼 생긴 작은 기계를 연결해서 사용했었다. 실제로 초창기 터미널들은 그림과 같이 타자기와 같은 모습이었다. (그래서 현재 UNIX/Linux에서 터미널을 의미하는 TTY라는 단어도 TeleTYpewriters 에서 나온 것이다)
 

대형 컴퓨터를 만드는 업체들이 차츰 UNIX 기반 운영체제를 사용하도록 진화해 가면서, 시분할 접속 방식으로 여러 사람이 동시에 접속해서 사용할 수 있게 됐다. 지금도 남아있는 RS-232 같은 시리얼 방식도 터미널에 연결 방식으로 도입되었고, DEC에서는 최초로 ANSI 규격을 준수하는 그림과 같은 VT100 현대적인(?) 터미널이 만들었다. 워낙 컴퓨터 제조사의 터미널 마다 화면에 글씨를 표시하는 방식이 다르기 때문에 ANSI 표준을 정했었다. 그리고 이 당시 대부분의 터미널의 글자색이 녹색이었고 ASCII 문자만 표시할 수 있었기 때문에, 지금까지도 터미널 앱에서 검은색 배경에 녹색 글씨로 쓰는 사람이 많다.

90년대 모뎀으로 접속하는 PC통신을 해본 사람들이라면 이미 터미널 화면에 익숙하다고 할 수 있다. 왜냐하면 당시의 국내 PC 통신 서비스들이 모두 터미널 기반의 접속 서비스였기 때문이다. 하늘소 팀에서 만든 “이야기”가 가장 인기 있던 터미널 에뮬레이션 앱이었다.
시간이 흘러서 개인용 컴퓨터가 발전하면서 대형 컴퓨터에 접속하기 위한 전용 터미널들은 의미가 없어졌다. 대신 PC에서 터미널을 에뮬레이션해서 다른 컴퓨터에 접속하도록 화면과 통신 프로토콜만 맞춰주면 되는 시대가 됐다. 맥 OS9까지는 zterm같은 에뮬레이터 앱은 있었지만 공식적인 터미널 앱은 없었다. 그렇지만 OS X부터 유틸리티 디렉터리에 터미널 앱과 함께 콘솔 앱까지 제공한다. 참고로 콘솔은 터미널과 비슷한 듯하지만 쓰임새는 사뭇 다르다. 터미널은 일반 사용자가 대형 컴퓨터에 입-출력을 하기 위한 것이라면, 콘솔은 대형 컴퓨터를 운영하는 운용자가 시스템을 관리하기 위해 로그을 확인하는 용도인 것이다. (물론 운용 명령어를 알고 있다면 터미널로 접근해서 마치 콘솔처럼 활용할 수 있다)

OS X는 FreeBSD가 기본적으로 포함되어 있고, 오픈그룹의 인증까지 받은 UNIX 머신이다. UNIX 명령을 사용하기 위해서는 당연히 가상의 터미널이 필요하게 되었고, 터미널에서 사용하는 수많은 UNIX 명령어들도 기본적으로 제공하고 있다. 사실 OS X의 수많은 기능들은 UNIX 명령으로 만들어져 있고, 명령의 결과를 GUI로 보여주기 위해 Aqua 윈도우 시스템을 활용하고 있다. 예를 들어 환경 설정 – Preferences 앱을 실행하면 시스템 혹은 홈폴더 아래 있는 /Library/Preferences/ 디렉터리에서 plist 파일들을 열어 화면으로 보여주고, 설정을 변경하면 이 파일들을 수정해서 저장한다. 그리고 이 파일들에는 환경 설정에서 보여주지 않는 숨겨진 기능까지 저장되어 있다.
OSX을 포함해서 모든 운영체제는 시스템 내부를 관리하고 프로그램을 실행하는 커널과 그 커널을 보호하기 위해 둘러싸고 커널의 기능 중에서 한정된 기능만을 사용하도록 하는 쉘이 있다. 여러 가지 쉘 중에서도 UNIX기반 쉘은 터미널에서 쓸 수 있도록 텍스트 기반의 쉘로 발전했고, GUI 기반의 매킨토시와 윈도 시스템은 탐색기나 파인더가 부분적으로 쉘 역할을 한다. OS X은 NeXTSTEP과 Mac OS의 화려한 GUI와 UNIX의 강력한 터미널 기능이 멋지게 결합된 형태라고 할 수 있다. 따라서 터미널 앱을 실행하고 OS X에 접근하기 위해서는 UNIX 쉘과 명령어들에 익숙해져야 한다. 결국 OSX의 터미널 앱은 UNIX 쉘을 사용하기 위한 접속 도구일 뿐인 것이다.
다음에는 OS X의 터미널에서 사용하는 여러 가지 쉘 환경과 유용한 명령어들을 살펴보도록 하겠다.

<편집자주> 본 컬럼의 내용은 민트기술의 의견은 아닙니다. 민트기술에 컬럼을 기고하실 분께서는 메일(wangsy@wangsy.com)로 문의 바랍니다.

작성일자

redmine tool – 1st Iteration

드디어, 내부 프로젝트의 첫삽을 떴습니다.
지난번 모임에서 몇가지를 확인하였습니다.

  • 내부 프로젝트의 가이드 라인
    • Mac OS X 용 응용 프로그램일 것.
    • Mac OS X 용 응용 프로그램 이상의 개발이 필요하지 않을 것.
    • 우리 스스로가 가장 많이 사용할 것.
  • 개발할 아이템
    • redmine 관련 도구!

이번 모임에서는 5시간에 걸쳐서, 기획/개발를 동시에 진행해 보았습니다. 그리고, redmine 도구, 과연 어떤게 필요할까 하는 의견부터 모아보았습니다.

  • Gantt 차트 도구 : 현재 redmine 에서는 Gantt 차트로 이슈를 보여주는 기능이 있는데, 이 그래프가 단지 시각적으로 보이기만 하고, 실제 마우스로 이동한다던지, 시작일과 종료일을 바로 바꾼다던지 하는 다이나믹한 사용은 불가하다. 이것을 Native App 을 통해서 해결하고 싶다.
    • 일단, Gantt 차트에 추가 기능을 제공하기 이전에, 기본적인 Gantt 차트 그리기 기능부터 만들어야 하나, 이에 대한 노력이 많은 큼. 추가적인 기능 제공을 하기 위해서, 웹에서 이미 제공하는 기능을 다시 만들어야 한다는 부담도 경제성을 생각해 봐야 할듯 함.
  • Time Tracking 기능 : 현재 이슈에 대한 소요 시간을 웹 페이지에서 스스로 기록하도록 되어 있으나, 이를 Mac OS X 응용 프로그램 차원에서 쉽게 해 줄 수 있을까?
    • 일단 기본적인 기능을 먼저 구현한다면, 그 다음에 쉽게 추가할 수 있을 듯하다.
  • Redmine 이슈 목록 보기 : 자동 로그인 하여, 프로젝트 목록과 이슈 목록을 볼 수 있게 하자.
    • 오늘의 주제로 선정

일단, 위와 같이 하여, 이슈 목록을 메뉴바 애플리케이션으로 저장하여, 현재 이슈의 목록과 프로젝트의 목록을 보여주도록 하는 아주 간단한 기본적인 기능을 만들어 보기로 하였습니다. 일단은 시작하는 차원에서 redmine 과의 연동을 테스트 해 보는 차원도 있기 때문에, 많은 욕심을 내지 않았습니다.
화이트 보드에서 전체적인 그림을 그려 보았습니다.

  • 최초 시작시, API 키 값과, redmine URL 입력창 보여주기. Login 버튼을 누르면, 해당 값이 유효한지 확인하고, 확인이 되면, 넘어가고, 확인이 안되면 실패를 알려준다.
  • 로그인 후에는 화면 상단의 메뉴바의 메뉴를 클릭하면, 현재 이슈의 목록을 메뉴 항목으로 보여준다. 그리고, 해당 메뉴를 선택하면, 웹 페이지를 통해서 해당 이슈 페이지로 이동한다.
  • 이슈 목록 하단에는 Projects 라는 메뉴를 두고, 그 서브메뉴에는 프로젝트 목록을 표시해 준다. 그리고, 그 목록에서 하나의 프로젝트를 선택해 주면, 다시 본 메뉴의 이슈 목록은 해당 프로젝트내의 이슈 목록으로 그 리스트를 제한한다.

썩 좋은 UI 구성도, work flow 도 아니지만, 일단 가장 간단하게 만들어 볼 수 있다는 차원에서 이 정도로 안을 만들었습니다.. 그리고, 만들어야 할 구성 요소와 각자의 역할을 찾아 보았습니다.

  • 프로토콜 분석 : JSON 프로토콜이 제공하는 범위 파악. 각 기능 구현을 위해서 어떤 프로토콜을 사용해야 하는지 파악. 이 역할을 한 사람이 담당하니 매우 시간이 절약 되었습니다.
  • 서버 통신 및 JSON Parse 기능 구현 : HTTP 통신 및 JSON 분석은 워낙 많이 사용되는 기법이라 시간이 많이 걸리지 않았습니다. 재사용 하여 한두시간 내에 구현이 되었습니다.
  • Menu 항목에 대한 다이나믹한 구성 : 서버에서 받아온 이슈 목록과 프로젝트 목록을 메뉴 아이템으로 만드는 모듈. 생각치 못한 버그로 인해서 의외의 모듈에서 시간이 꽤 걸렸습니다.
  • Login 창 및 로직 : 로그인 데이타를 받고, 처리하고, 넘어가는 부분. 어렵지 않게 진행 가능했습니다.
총 5시간의 작업결과 해당 기능을 만들어 낼 수 있었습니다.
Login 창의 동작 모습

메뉴바를 통해서 이슈 목록과 프로젝트 목록을 보여줌

소감

  • 아직은 너무 간단한 기능을 제공하기 때문에, 유용함을 갖췄다고 하기엔 부족함이 많다는 것을 잘 알고 있습니다.
  • 하지만, 5시간을 투자하여, 우리가 생각했던 것을 실제로 동작하는 소프트웨어로 만들어 냈다는 점은 아주 큰 기쁨을 주었습니다.

애자일 개발 방법론에 대해서

  • 우리는 나름 애자일 개발방법으로 해 보았다고 했으나, 이것이 애자일인지 아닌지는 모르겠습니다. 하지만, 우리가 지금껏 해 오던 방식과는 분명 달랐습니다.
  • 기획안을 먼저 골똘히 준비하고, 그에 맞춘 개발을 진행하는 것이 아니라, 개발자끼리(혹 기획자가 있다면 함께 해도 좋지만, 기획자가 없는 관계로)모여서 우리 스스로가 옳다는 기획안을 만들어서, 금방 구현을 해서, 그 유용함을 확인해 보았는 것은 의미있는 과정이었습니다.
  • 또한 개발자 5명과 테스터 1명이 서로 같은 자리에서 얼굴을 맞대고 작업하는 것은 또다른 새로움이었습니다. 지속적으로 대화를 하면서 개발을 진행하였고, 그래서 어쩌면 지속적인 긴잠감을 주는 것 같기도 하였습니다. 대부분의 의견이 5시간동안 집중을 하게끔 한다고 하였습니다. 육체적 피로감은 높았지만, 그 집중력에 대한 성취감도 높았습니다.
  • 생산성은 아주 높았습니다. 모두가 따로 떨어져 했을 때보다, 두세배 더 빠르게 작업하지 않았나 하는 생각입니다.
  • 짧은 시간에 모두가 각자의 역할을 찾는 것이 생각보다는 어렵지 않았습니다. 그래서 혼란스럽지 않게 잘 진행이 되었습니다.
이번주에는 여러가지 일정의 문제로 반나절까지만 해 보기로 하였습니다. 하지만, 일주일에 반나절의 일정으로는 이 프로젝트에 대한 진도가 생각보다 더딜 것 같아서, 일주일에 두번으로 늘여볼까 합니다. 일주일에 두번씩 매번 이정도의 진도로 진행해 나간다면, 앞으로 한달, 석달이 지난 다음에는 꽤 쓸만한 소프트웨어가 되어 있지 않을까 하는 기대감이 듭니다.

 
 

작성일자

민트기술 2012년 새로운 자체 프로젝트

민트기술을 외주 프로젝트를 통해서 주매출을 얻습니다. 작년 한해 5개 정도의 자체 프로젝트를 했었지만, 그것이 매출로 이어진 것은 없습니다. 매출로 이어지지는 않지만, 그래도 꾸준히 내부 프로젝트를 해야 하는 이유가 있습니다. 우리는 우리의 개발 기술력이 타인의 아이디어, 제품을 빛내주는데에도 잘 사용되기를 바라지만, 우리 스스로의 아이디어와 생각에도 사용되기를 바라기 때문입니다.
우리는 작년 한해동안 해온 내부 프로젝트가 성공적이었다고 단언할 수는 없습니다. 대신 많은 반성을 하였습니다.  2012 신년 계획 에서 그에 관한 생각을 정리한 적이 있습니다. 이에 대한 반성을 바탕으로, 새로운 방향을 잡아 보기도 하였습니다.
그래서, 내부 프로젝트에 대한 몇가지 가이드라인을 잡아 보았습니다.

  1. 첫째, 맥 애플리케이션 입니다. iOS 용 앱도 아닌, 안드로이드용 앱도 아닌, 오로직 맥 애플리케이션을 최종 결과물로 하기로 하였습니다.
  2. 둘째, 단독 소프트웨어 입니다. 맥 애플리케이션 하나로 완전해야 합니다. 다시 말해, 우리가 개발할 영역으로는 맥 애플리케이션으로 한정하였습니다. 서버사이드 개발이 필요하거나, 웹 개발이 필요하거나 하지 않고, 맥 애플리케이션 개발만 하기로 하였습니다.
  3. i use it. 내가 사용하는 소프트웨어를 만들기로 하였습니다. 민트기술 개발 팀원이 스스로 쓸 수 있는, 아니 스스로 쓰고 싶은,스스로에게 꼭 필요한 소프트웨어를 만들기로 했습니다. 그 누구 타인이 필요한 소프트웨어 보다는, 우리가 필요한 소프트웨어를 만드는 것이 더 가치 있을 수 있고, 더 정확할 가능성이 높기 때문입니다.
그래서, 이 가이드라인에 따라서, 몇가지 안을 세워 보았습니다.
  • WYSIWYG 위키 편집 툴. 민트기술 개발팀은 위키를 이용하여, 개발 문서화를 하고 있습니다. 문서화를 잘 하기 위해서는 textile 같은 문법을 익혀야 합니다. 익힌다 하더라도, 복잡한 표가 들어간 문서는 편집하는 것이 보통일이 아닙니다. 좋은 도구가 있었으면 하는 생각을 했습니다.
  • redmine 도구. 민트기술 개발팀은 이슈 관리 도구로, redmine 도구를 사용합니다. 개발 과정 중간에 항상 참조하고, 기록하기 위해서 웹 페이지를 띄워놓아야 합니다. 그리고, 업무 흐름을 파악하는 것도 쉽지 않습니다. 하나의 이슈를 포커스 하는 것도 쉽지 않습니다. 딱히 떠오르는 아이디어는 없지만, redmine 을 쉽게 쓸 수 있도록 도와주는 맥 애플리케이션이 있었으면 좋겠다는 생각이 듭니다.
  • google addressbook sync. 아이클라우드 주소록과 구글 주소록을 서로 비교하여, 싱크를 잘 할 수 있었으면 좋겠습니다. 현재 나와있는 도구는 우리를 만족시켜줄 수 없습니다.
  • flickr_fs. fuse 를 이용하여, flickr 사이트를 파일 시스템으로 마운트하여, 파일을 업로드 다운로드 할 수 있었으면 좋겠습니다. 현재 나와 있는 버젼을 좀더 개선하고 싶습니다.
  • git flow tool. 민트기술에서는 git flow 를 사용하고 있습니다. 이와 관련한 branch visualization 이 있었으면 좋겠다는 생각을 하였습니다.

위 안을 다수결로 하여, redmine 도구 관련한 애플리케이션을 개발하는 것으로 결의하였습니다.
개발 방법론으로 Agile 개발 방법론을 시도해 보기로 하였습니다. 아직 어떻게 하는 것인지 정확한 아이디어는 없지만, 일단 우리 방식으로 적용을 해 볼까 합니다.

  • 일주일에 반나절 정도의 시간을 할애한다.
  • 해당 시간에 개발팀이 전원 모여서 작업을 한다.
  • 모인 자리에서 개발 기획과 개발 진행, 검증을 진행한다.
  • 각자의 정해진 역할을 미리 정하지 않고, 모인 자리에서 그때 그때 결정하여 진행한다.
  • 지속적인 대화를 통해서 의견 교환을 하고, 그와 동시에 구현을 하고, 그 구현 결과를 통해 의견을 나누면 개선해 나간다.

위와 같은 방법론이 과연 잘 진행된지에 대한 의문은 있지만, 일단 진행해 보기로 하였습니다. 잘 안되면, 계속적으로 문제점을 파악하고 개선해 나가야 겠죠?
이쯤되면, 다시 한번 의문이 들 수 있읍니다. 과연 redmine 도구를 왜 만들어야 하는 것일까? 이것이 새로운 수익을 창출할 수 있을까? 일단은 단기적으로 그것보다 목표는 소박합니다. 우리의 목표는 먼저 “아주 작은 그룹의 사용자”에게 “아주 특수한 목적으로 사용되는” 애플리케이션을 통해서 “가치”를 제공하는 것을 만들고 싶기 때문입니다. 만일 이 작은 그룹/목적 내에서 “가치”를 만들어 내기만 한다면, 그 다음에는 더 많은 사람, 더 많은 목적을 위해서도 만들 수 있다고 생각합니다. 그리고, 사람들에게 “가치”를 제공해 줄 수 있다면, 수익, 매출 이런 것은 걱정할 것이 아닌것 같습니다.
아주 처음은 작고 소박한 목표를 향해 출발합니다. 잘 진행되는 과정을 반복한다면 머지 않아 큰 결실을 이룰 수 있을 것으로 기대합니다.