Sentio, ergo sum

   웹(클라우드) IDE은 웹 환경, 즉 브라우저를 통해 인터페이스를 제공하는 통합 개발 환경입니다. 

로컬 PC에 IDE를 다운로드 받아 실행하지 않고 웹 브라우저를 통해 접속하여 해당 서비스에서 제공하는 환경을 통해 개발할 수 있습니다.

   지원하는 언어, 미들웨어, 데이터베이스 등의 종류와 기능은 각 서비스 별로 상이하지만 파일 브라우징, 버전 관리 연동, 편집기, 콘솔, 터미널 등의 기본적인 기능은 대동소이합니다.

   이 글에서는 상용 서비스와 오픈 소스로 공개된 웹 IDE에 대해 비교해보도록 하겠습니다. 이전에 웹 IDE를 분석했던 자료를 PT로 정리해뒀었는데, 묻어두긴 아까워 PT자료를 토대로 글로 옮겼습니다. 슬라이드 그대로 짜깁기한 부분도 있으니 너그러이 양해를 :D

※ PT 자료는 http://www.slideshare.net/ssusercef361/ide-60399120 에서 보시거나 다운로드 받으실 수 있습니다.

I. 주요 상용 웹 IDE

   이 중 NITROUS는 회원 가입 시 전화번호 인증이 필요한데 한국 번호(+82)로는 인증 문자가 발송되지 않는 건지 인증을 하지 못해서 테스트해보지 못했습니다 ;;

  상용 웹 IDE의 공통 기능

대부분의 서비스가 아래와 같은 기능을 제공합니다.

1. 프로젝트(파일) 관리/브라우징

   - 워크스페이스 제공

   - 언어/프레임워크별 프로젝트 템플릿 제공

   - 파일 업로드/다운로드

   - 프로젝트 내보내기/가져오기 (파일 또는 링크 형태의 공유)

2. 편집기(문법 검사, 코드 하이라이팅, 자동 완성 등)

3. 자동 저장 및 리비전(SCM과는 별도로 파일 자체의 리비전 관리)

4. 개발, 빌드 및 실행을 위한 VM이나 Container 제공

5. 협업 기능

   - 프로젝트 공유/프로젝트 멤버(팀) 관리

   - IDE 내 메신저 채널 제공

   - 동시 협업 코딩(구글 문서와 같은 동시 편집 기능)

6. 웹 기반 SSH 터미널 제공(대부분 sudo 명령어 지원)

7. 형상관리 시스템 연동(Git.Mercurial/SVN 또는 외부 서비스 e.g. Github)

8. UI 사용자화(Custumizing)

   - 창/탭 형태의 UX 제공

   - 창/탭 분할

   - 테마 사용자화

   개발/빌드/실행 환경에 있어서는 VM이나 Container 기반의 워크스페이스(또는 프로젝트)를 제공하며, 서비스에 따라서 실행 및 빌드 시에만 VM(Container)를 생성하는 경우도 있습니다. 또한 자체적으로 웹 애플리케이션 테스트를 할 수 있는 경우 Public URL을 제공하여 해당 URL을 통해 실행된 웹 애플리케이션을 확인할 수 있습니다.

   대부분의 경우 웹 IDE에서는 테스트 환경까지는 제공하지만 배포환경은 제공하지 않습니다. 즉 웹 IDE를 통해서 안정된 서비스를 운영하기는 아직까지 어려워보입니다.

웹 IDE에 따라서는 Cloud 서비스(IaaS/PaaS)와 연동하여 개발된 결과를 해당 서비스에 배포할 수 있도록 하는 기능도 제공합니다.

  Codenvy - https://codenvy.com/

Codenvy의 주요 특징

   - Docker 기반 컨테이너 제공

   - 프로젝트 실행 시에만 컨테이너(Runner) 동작

      - Runner가 동작중일 때 웹 SSH Terminal을 통해 접속가능

   - 웹 UI를 통한 데이터베이스 연동

   - 언어 지원 : C/C++, Javascript, Java, PHP, Python, Ruby

   - 템플릿 프로젝트 제공

   - 언어별 빌드툴에 대한 빌더 인터페이스 제공

   - 형상관리 제공(Git, Subversion)

   Codenvy를 통해 개발 시 소스코드 등의 프로젝트 파일은 서버의 파일 시스템으로만 관리되고, 테스트 시에는 Runner라는 실행환경을 제공합니다. Runner는 Docker를 통해 생성된 Container이며, 빌드 결과를 Runner에 업로드하여 Runner 환경 내에서 실행됩니다.

    Runner는 언어/프레임워크/웹서버/WAS 등에 따라 다양하게 제공되고 있으며 2015년 11월 기준으로 제공되는 Runner는 아래와 같습니다.

   또한 기본적으로 제공되는 Runner이외에도 현재의 Runner를 통해 Custom Runner를 구성하여 생성할 수 있습니다.

Codenvy 아키텍쳐

주요 화면 캡처

(전체 화면 스크린샷이라 잘 보이지 않습니다 ;; 자세한 화면은 슬라이드쉐어에 공유한 PT 자료를 참고해주세요)

기본 편집 화면

새 프로젝트 생성 - 언어별 템플릿 프로젝트 제공

러너 및 러너 속성 

러너 실행 시 콘솔을 통한 로그 확인

러너 접속을 위한 터미널

데이터베이스 연결 - 

데이터베이스(PostgreSQL, MySQL, Oracle, MS SQL, NuoDB) 가 설치된 URL을 직접 입력하거나

Google Cloud SQL, Amazon의 데이터베이스에 연결

  SourceLair

SourceLair의 주요 특징

   - 형상관리 시스템에 밀접하게 연동

      - 프로젝트 생성 시 형상관리 시스템을 먼저 선택하도록 되어있음

   - UI 상에서 Package Management 제공

      - npm, pip, bower 등

   - 개발용 데이터베이스 인스턴스 제공

   - Heroku 개발 특화

      - Heroku 앱 템플릿 제공(Heroku 용 Node, Django)

   - Linux 터미널 제공

   - 웹 서비스의 Public URL 제공

   - Sublime Text의 Command Palette와 유사한 기능 제공

   - HTML 라이브 프리뷰

   편집 기능에 있어서 강력한 기능을 많이 제공합니다. HTML 의 라이브 프리뷰도 그렇고, 자동 완성, 코드 폴딩 등의 기능을 제공합니다. 웹에서 웬만한 IDE의 편집기에 버금가는 기능을 갖췄다니 대단하네요.

   특이한 부분은 웹 UI 내에서 npm, pip와 같은 패키지 관리를 할 수 있단 부분인데요. 물론 다른 웹 IDE 들도 터미널을 통해 할 수 있지만 UI를 통해서 할 수 있는 건 SourceLair 밖에 없어 보입니다.

편집 화면 캡처

편집 화면 - 상단 메뉴 대신 왼쪽에 바 형태로 아이콘을 제공합니다. 편집기에서는 탭으로 파일을 구분하여 작업할 수 있습니다.

  Koding - http://www.koding.io

Koding 의 주요 특징

   - VM 기반 워크스페이스 제공 : VM에 대한 Public IP 제공

   - 편집기 위주의 화면 구성

   - 빌드, 테스트 등은 터미널을 통해 명령어/스크립트로 수행

   - 그림판(Drawing Board) 편집기 제공

   - 메신저(개인 Direct Message / 채널)

      - 채널의 경우 공개되어 있으며, 다른 사용자들과 의견 공유 가능

   - VM 관리

      - VM Spec, Disk Usage, Domain, VM Share, Snapshot 등 IaaS 주요 VM 관리 기능 제공

      - 외부 서비스의 VM 사용 가능 - 해당 VM에서 셋업 스크립트 실행을 통해 초기화

Koding의 경우 다른 서비스들과 달리 Koding을 위한 개발환경이 세팅된 VM을 통째로 제공해 줍니다. VM안의 파일 시스템을 사용하고 언어, 프레임워크, 데이터베이스 등을 설치하여 사용할 수 있습니다. 가장 자유도가 높은 웹 IDE 입니다.

또한 사용하는 IaaS가 있다면 그곳의 VM에 셋업 스크립트를 실행해서 Koding 에서 사용할 수 있도록 설정할 수 있습니다.

주요화면 스크린샷

편집 화면 - Drawing Board에 Hello World 써보기 (악필...)

VM 설정 화면

채널을 통한 커뮤니케이션

Direct Message

외부 VM을 추가하기

  codeanywhere - http://www..io

codeanywhere 의 주요 특징

   - 컨테이너, FTP/SFTP/SSH, Git, 스토리지 서비스로부터 프로젝트를 생성/파일 관리

      - 자체 제공 컨테이너 : 언어 및 프레임워크별 이미지 제공

      - Github/Bitbucket 연동 또는 Git URL 직접 입력

      - 3rd 파티 스토리지 서비스 : 아마존 S3, Dropbox. Google Drive

   - 프로젝트 템플릿은 제공하지 않음

   - 컨테이너의 언어(프레임워크) 스택에 따라 웹 서버 실행

   - 스택에 필요한 패키지 설치 후 커스텀 스택으로 저장 할 수 있음

   - 다른 사용자에게 프로젝트 공유 기능 지원

   - 프로젝트/컨테이너 등의 설정은 JSON 형식의 설정 파일을 직접 수정

   Codeanywhere은 프로젝트 생성 시 '연결'한다는 개념으로 접근합니다. 컨테이너에 연결, GitHub에 연결, SSH 서버에 연결.. 등 파일 시스템을 사용할 수 있는 시스템을 기반으로 하여 개발을 할 수 있도록 해두었습니다. 다만 컨테이너 이 외에는 통합 개발 환경을 제공하기 보다는 웹을 통한 파일 관리의 느낌이 더 드는..?

   컨테이너의 경우에는 '스택'이라는 개념으로 언어나 프레임워크 등을 관리할 수 있도록 되어있고, 개발자가 원하는 패키지를 설치한 후 커스텀 스택으로 저장하여 사용할 수 있습니다.

주요 화면 캡처

프로젝트 생성 (Connection Wizard)

컨테이너 연결 - OS 선택(Ubuntu / CentOS)

편집 화면 - 기본적인 IDE와 비슷한 구성(터미널 제공)

  Cloud9 - https://c9.io

Cloud9 의 주요 특징

   - 컨테이너 기반 개발 환경 제공

   - REPL(Javascript) 제공

   - WAS의 로그 콘솔 제공

   - 로컬 IDE와 유사한 수준의 디버깅 기능 제공

   - 컨테이너 리소스 모니터링 및 프로세스 관리 가능

   - HTML 페이지, 마크다운, 이미지 파일 등의 프리뷰 지원

Cloud9은 개인적으로 이름이 마음에 드는 서비스입니다. 이름이 갖는 의미 만큼의 개발 환경을 제공해 줄 수 있을지는 더 지켜봐야겠지만요..? (오래오래...?)

SourceLair의 경우에는 웹 UI 상에서 패키지 관리를 제공했다면, Cloud9은 컨테이너의 메모리, 디스크와 같은 리소스와 컨테이너에서 실행 중인 프로세스를 관리할 수 있는 기능을 제공합니다.

또 특이하게 REPL(Read Eval Print Loop, 인터프리터 언어의 대화형 쉘)을 제공하는데, 웹 브라우저의 개발자 도구를 활용해도 되긴 하지만 바로 사용할 수 있다는 점에서 편리하긴 하네요. 또한 높은 수준의 디버깅 기능을 제공합니다.

주요 화면 캡처

로그인 후 프로젝트 메인 화면, 사용률 및 README 파일 확인 가능

편집 화면 - 설정 파일 편집(JSON 형식), 오른쪽에는 디버거

프리뷰(Preview) 를 통한 확인

Rails의 출력 로그 확인(터미널과 별도로 제공)

  구름IDE - https://www.goorm.io

구름IDE의 주요 특징

   - 국내에서 개발된 웹 IDE

   - 컨테이너(Amazon EC2 Container) 기반 워크스페이스 제공

      - *.goorm.io / *.compute.amazonaws.com Public URL 제공

   - Java 교육용 컨텐츠(예제 및 템플릿) 제공

   - 로컬 IDE와 유사한 수준의 디버깅 기능 제공

   - Git/Subversion 연동 (다소 불안정)

   - 문서 뷰어 제공(Slideshare.net, PDF 파일)

   - 작업 내역(리비전) 기록 및 해당 리비전에 대한 작업 내역 재생 가능

   구름 IDE 는 국내에서 개발된 웹 IDE입니다. 해외의 주요 웹 IDE에 비해서는 아직 안정성이나 기능적인 면에서 조금 부족한 모습이 보입니다. Git이나 Subversion과 같은 버전 관리 시스템과의 연동은 불안정한 부분이 있구요.(연결이 되기도 했다가 안되었다가..)

   전반적인 기능으로 봤을 때는 실제 개발을 위한 IDE라기 보다는 교육용에 가까운 모습입니다. 프로젝트 생성 시 자바의 문법이나 특정 API와 관련된 샘플 템플릿을 제공한다거나, IDE 편집 화면 내에서 Slideshare.net의 링크나 컨테이너에 업로드한 PDF 파일을 볼 수 있는 뷰어를 제공합니다.

   구름 IDE 역시 Cloud 9과 비슷하게 로컬 IDE와 유사한 수준의 디버깅 기능을 제공합니다.

구름 IDE 아키텍처

주요 화면 캡처

로그인 후에 가상 머신(컨테이너)의 상태를 확인할 수 있습니다.

- 컨테이너를 실행 시켜야 편집 모드를 사용할 수 있습니다.

새 프로젝트 생성 - Java 프로젝트, 예제 프로젝트의 모습이 보입니다.

편집 화면 구성 - 브라우징, 편집기, 채팅, 쉘 등의 기능을 제공

문서 뷰어 - Slideshare.net의 링크를 입력하거나, PDF 파일을 열어서 내용을 볼 수 있음

문서 뷰어 - PDF 파일을 연 모습

II. 오픈소스 웹 IDE

  주요 오픈소스 웹 IDE

- Eclipse Che

- Eclipse Orion

- Eclipse Dirigible

- Eclipse Flux

- Codebox

- Codiad

위 목록에서 보다시피 Eclipse가 붙은 프로젝트가 네 가지가 있습니다. 이름대로 이클립스 재단에서 클라우드 환경에 맞는 IDE 개발을 위해 진행중인 ECD(Eclipse Cloud Development)에  포함된 네 개의 프로젝트입니다. 

http://www.eclipse.org/ecd 에 접속해 보시면 위 네 개의 프로젝트에 대한 소개와 링크를 제공합니다.

  Eclipse Che - http://www.eclipse/che

Eclipse Che 프로젝트는 상용 서비스인 Codenvy에서 이클립스 재단에 기여한 프로젝트입니다.

Codenvy의 UI를 포함하여 대부분의 기능을 제공하고 있습니다.

그러므로 Eclipse Che에 대한 설명은 생략하겠습니다. (...?)

  Eclipse Orion - https://orionhub.org/

오리온의 주요 특징은 아래와 같습니다. 

   - CloudFoundry와 연동 제공

   - 기본적인 수준의 편집 기능 제공

   - 외부 Git 서비스 연동

   - Shell 제공 (지정된 명령어만 사용 가능, 일반적인 터미널과 다름)

   - Public URL 제공

   - manifest.yml 편집 및 유효성 검사 기능 제공

manifest.yml 파일은 CloudFoundry에서 사용하는 애플리케이션의 설정 파일이며, 애플리케이션의 자원(메모리, 디스크), 서비스, 애플리케이션 속성 등을 관리하는 파일입니다.

Eclipse Orion 에서는 manifest.yml 파일을 직접 이용하여 애플리케이션에 대한 설정을 할 수 있도록 되어있으며, 편집기 자체에서 매니페스트 파일의 유효성을 검사합니다. 즉 CloudFoundry에 최적화된 모습을 보입니다. 컬러 테마 역시 CF와 같아 보이는군요. Pivotal 쪽과 관계가 있지 않을까 추측해 봅니다.

주요 화면 캡처

(작아서 잘 안보이지만..) manifest.yml 파일 편집

Git Repository 연동

Git Repository 연동 후 - 커밋 내역이나 파일을 탐색할 수 있습니다.

쉘 - help 명령어를 쳐서 나오는 명령어만 사용가능합니다.

라우팅 설정

라우팅 목록

Cloud Foundry 연동 - API/Manage URL을 입력하여 연동할 수 있습니다.

플러그인 목록 - CF이 외에도 이미지 뷰어 자바스크립트 툴 등의 다양한 플러그인을 제공합니다.

  Eclipse Dirigible - http://www.dirigible.io

Eclipse Dirigible의 주요 특징은 아래와 같습니다.

   - SAP에서 이클립스 재단에 기여

   - Perspective를 통한 화면 구성

      - Database, Debug, Generic, Registry, Repository, Workspace, Help

   - Sandbox를 통한 호스팅 제공

   - 데이터베이스 스키마 편집 모드(Perspective) 제공

   - Plugin Lazy Load

   - UI 구성이 일반적인 IDE와 차이가 있어서 러닝 커브가 있음

IDE로써의 다양한 기능을 제공합니다. 특히 데이터베이스 스키마 편집을 위한 Database 퍼스펙티브와 사용자들이 개발한 프로젝트를 등록하여 공유할 수 있는 Registry를 제공합니다. 이 두 가지 관점에서는 다른 IDE보다 우수하네요.

다만 Plugin Lazy Load 때문에 체감 속도는 더 느리게 느껴집니다. (매번 로딩...) 또한 전반적으로 UI 반응성이 떨어져서 사용성이 떨어지는 느낌입니다. 

주요 화면 캡처

메인 화면 - 기능별로 구분되어 있습니다만 써보기 전엔 이게 뭔지 잘 모를..

IDE 퍼스펙티브 - 로컬 IDE와 유사하게 잘 구성되어 있습니다. 구문 강조 등의 기본적인 편집기 기능을 제공합니다.

데이터베이스 퍼스펙티브 - MySQL 워크벤치처럼 스키마/테이블을 편집할 수 있습니다.

Registry - 사용자들이 등록한 프로젝트를 볼 수 있습니다. 공유된 걸 가져와서 테스트 해보려고 했으나 런타임 익셉션이..

List와 Generic - 정확하게 어떤 기능인지는 모르겠지만 프로퍼티 관리 기능으로 보입니다.

도움말

  Codebox - http://www.codebox.io

Codebox는 분석 전에 스크린샷이나 소개 글로 봤을 땐 개인적으로 괜찮아 보였는데... 테스트 서버에 회원가입 제한이 되어있더군요. (분석할 때는 작년 말이었는데, 지금도 보니 회원가입은 비활성화 되어있네요)

간략하게 특징을 살펴보면

   - Node.js 기반의 Apache 라이선스로 개발

   - Java, Python, Ruby, Go 등의 언어 지원

마지막 커밋이 글을 쓰는 현재(`16. 3. 31) 11개월 전인 것으로 보아 개발이 중지된 것으로 보입니다. (왠지 슬픔 ㅠㅠ)

편집 화면 캡처

사실 이 캡처의 모습이 서브라임과 유사해서 좋았었는데, 조금 아쉽네요.

  결론

   웹 IDE를 통해서 개발 시 소스코드나 리소스 등의 파일은 서버에 위치해 있고, 필요 시 로컬로부터 업로드하여 사용합니다. 물론 컴파일(빌드), 테스트, 배포 등의 작업 역시 서버 내에서 이루어집니다.

   화면으로 제공되는 것 이외에는 모든 작업이 서버에서 이루어지지만, 서버나 VM/Container에서 사용할 수 있는 기능이 모두 UI로 제공되지는 않습니다. 그걸 다 제공한다면 UI는 너무 복잡해 지겠지요.

이런 제한점을 해소할 수 있는 것은 웹 기반 SSH 터미널을 통해 필요한 것을 설치하거나 사용할 수 있습니다. 물론 SSH를 제공하지 않으면 UI로 제공하는 기능이 기능이자 제약이 되기도 합니다.

   속도 면에서는 서비스가 지원하는 성능 또는 과금 모델에 따라 속도 차이가 날 수 있으며, 인터페이스 및 편집기 기능을 제공하는 웹 브라우저에서는 일반적인 로컬 IDE보다는  속도가 느립니다.

네이티브 앱과 하이브리드 앱(또는 웹 앱)에서의 속도차이와 같은 개념으로 볼 수 있겠네요. 현재는 웹 IDE를 기반으로 실제 운영을 위한 서비스를 개발하라고 하면 당연히 무리가 있겠지만 속도, 기술, 기능 등의 면은 시간이 흐를 수록 발전되고 더 나은 사용자 경험을 제공할 수 있다고 봅니다.

   또한 웹 IDE는 클라우드 개발환경이 IaaS에서 PaaS로 점차 넘어가는 환경에서 이에 걸맞은 개발환경이 될 수 있다고 생각하기 때문에 PaaS와 웹 IDE는 유사한 수준으로 함께 발전할 것이라고 생각됩니다.

   개발 환경을 완전히 웹 IDE를 통해 구축할 수 있다면, 그야말로 언제든, 어디서든 개발할 수 있는 환경이 마련되겠네요 :)

※ http://www.slideshare.net/ssusercef361/ide-60399120 업로드 자료

글을 정리하기는 작년 10월 15일. 퇴사 한 달도 더 전에 써놓고서는 이제야 마무리를 지어본다.

회사에 들어가기는 2014년 6월 중순. 모멘티 파일럿 개발을 하고 있을 때 소프트웨어 마에스트로 과정에서 멘토셨던 대표님으로부터 연락이 왔고, 클라우드 R&D라는 관심이 가는 주제였기에 모멘티 파일럿이 끝나고 입사하게 되었다.

1년 5개월, 경력으로 보았을 때는 그리 길지 않은 시간이지만 많은 분들을 만나고, 많은 것들을 보고 배울 수 있는 시간이었다. 프로젝트를 함께 했던 분들이 다들 좋은 분들이셨던지라, 저 짧은 경력이 더 짧아지지 않고 그래도 작년 말까지는 있을 수 있었던 것 같다.

퇴사 시기를 11월로 잡은 것은 2차년도 프로젝트 과제를 어느 정도는 마무리하기 위함도 있고, 오픈 프론티어 랩(지금은 이름이 KOSS Lab으로 변경의 지원 시기가 그 쯤이기도 했기 때문이었다. 프로젝트를 진행하는 동안 개발 업무가 거의 없었고 개발 실력이 정체되어 있음을 느꼈다. 공부는 혼자서 하는 게 맞긴 하지만 회사 업무와 병행해서 관련있는 공부를 경험과 함께 하는 것과 그냥 개인적으로 공부만 하는 것에는 차이가 있을 수 밖에 없다고 본다. 그래서 오픈소스 활동을 하면서 그간 하지못한 개발 공부를 하고 싶었기 때문에 오픈 프론티어 랩에 지원했으나 서류 광탈.. 퇴사일 보다 앞서 결과 발표가 났지만, 당락 여부와 관계 없이 퇴사를 결심했던터라 예정대로 12월 1일에 퇴사했다.

어쩌면 불평 불만이 가득할지도 모르겠지만, 주어진 일들은 열심히, 잘 소화해왔고, 퇴사할 때까지도 나름 마무리를 잘 짓고 나왔다고 생각한다. 퇴사 후에 거의 한 달 동안은 반은 책임으로 반은 팀원에 대한 미안함으로 관리자 대시보드 프론트 개발을 하고 넘겨주었다. 지금 생각하면 미련하게 왜 그랬나 싶기도 하지만.. :)

어쨌든 이런 저런 것들이 쌓여 퇴사 사유가 되었던 것들을 정리해보았다. 대부분의 것들은 대표님과 지속적으로 얘기를 해왔고, 대표님도 해결을 위해 많은 노력을 해주셨지만 어쩔 수 없는 부분들이 있었다. 서로가 서로를 이해하지만 어찌할 수는 없는 상황이란 건 참으로 슬픈 듯 하다.

1. 본사 업무와의 병행

프로젝트 특성 상 참여하는 업체들과 함께 진행하다보니 본사에서 파견을 나와서 따로 마련된 사무실에서 근무했다. 사실 어디든 하나의 업무에 집중해서 할 수 있는 환경은 이상적이랄 수 있겠지만, 프로젝트가 아닌 다른 서비스의 유지보수와 VoC에 대한 대응을 했고, 기한이 정해진 업무가 있는 상태에서 서비스에 장애가 발생하거나 고객 대응을 할 일이 있을 때는 경영/기획팀에서 어느정도 커버하긴 했지만 기술적인 대응은 내가 맡고 있어서 어쩔 수 없이 처리해야했다. 기존 서비스 코드가 유지보수가 잘 되어있고 장애에 잘 대응할 수 있는 구조였더라면 좋았겠지만 처음에는 로그도 제대로 쌓이지 않아서 하나하나 찾아가야 했다. 나중에 크게 유지보수를 해서 대응을 하기 좋아지긴 했지만 우리쪽 장애 뿐만이 아니라 연동된 다른 서비스에서 발생하는 장애도 있어서 완전히 없앨 수는 없었다.

차라리 추가 개발이 있었더라면 그래도 개발이라도 할 수 있으니 괜찮았을테지만 사용자 수는 줄어가고, 본사는 다른 서비스에 집중하다보니 뒷전인 서비스가 되었고, 적은 수지만 사용자가 있었기 때문에 서비스를 유지하고 있었다. 퇴사 전 나와 다른 분들이 서비스를 정리해야한다는 의견을 냈고, 올해 말에 서비스를 종료하기로 했다.

대표님 역시 이 서비스가 회사의 아이덴테티를 가지고 있기 때문에 쉽지 않은 결정이었지만 회사의 방향성을 위해서 어렵지만 좋은 결정을 해주셨다.

거기에 더해 나뿐만 아니라 중국어를 하시는 팀원분은 중국어 번역 업무까지 맡다보니 팀원들의 불만 역시 많아졌고, 다른 이유도 있었지만 결국 그 분도 퇴사를 선택하시게 되었다.

2. 인력

2014년 6월에 이 프로젝트로 투입이 되었고, 수석급으로 계시던 분은 원래 임시로 있었기로 했기 때문에 그 분이 나가시고 연말까지 나와 다른 팀원분 이렇게 오픈 소스를 분석하고 문서화 그리고 테스트 등의 업무를 둘이서 하게 되었다. 클라우드 경험은 IaaS를 사용해본 것이 다였기 때문에 모든 것을 처음으로 했고, 같은 해 11월에 들어온 팀원 역시 신입이었다. 그리고 연말에는 이 전에 같이 일하셨던 분은 군 복무로 인해 퇴사하셨다.

그리고 다음 해 2년차 정도의 팀원이 새로 입사하셔서 팀에 합류했지만 서버 애플리케이션 개발 경험은 있지만 클라우드 경험은 없었기 때문에 다시 시작해야 하는 상황. 그 쯤해서 프로젝트의 팀장이 되어 PL업무를 수행했다. 1차년도까지는 대표님이 오셔서 PL을 하셨지만 다른 신규 서비스에 집중을 하셔야 했기 때문에 점점 이 프로젝트에 대한 팔로업이 되지 않았고, 중요한 결정사항 이외에는 내가 대부분 처리했다. 프로젝트에 참여하는 5개 업체 중 우리 회사를 제외한 4개 업체의 PL은 수석급이거나 이사, 그리고 부장이었기 때문에 사실상 심적으로 부담이 되는 부분이 많았다. 팀장으로써 PL로써 모르는 것도 많았고, 부담스러운면이 있었다. 어떻게든 책을 보고, 다른 분들의 도움을 받아 업무를 진행하긴 했지만 역량이 부족한 탓에 일정이 연기되는 일이 잦았고, 다시 부담으로 돌아오는 악순환이 이어졌다.

상급자(수석급 혹은 PL역량을 지닌)의 부재 문제로 대표님과 많이 얘기하고 사람을 구하려고 노력했지만 여러 번의 시도 끝에 결국 업무에 적합한 분을 찾지 못해 퇴사할 때까지 기존 업무를 수행해왔고 익숙하기 때문에 그대로 팀장을 하기로 합의를 하고, 3차년도부터는 파견이 아닌 본사에서 개발업무를 하기로 프로젝트 PM님과 협의를 했고, 올해 초부터는 남은 팀원들은 본사로 돌아와서 업무를 수행하게 되었다.

또한 다른 업체의 팀이 5명내지는 7~8명 정도 되는 반면에 우리는 3명이었기 때문에 사람이 부족한만큼 개인당 업무량이 자연스레 많아질 수 밖에 없었다. 물론 다른 업체들에 비해전체 업무량은 참여 인원에 비례하긴 했지만 역량이 그만큼 따라오지 못했던 부분도 있긴 했다. 하지만 R&D 프로젝트에 파견나와있는 팀원 3명을 제외한 회사 대부분의 인원들도 참여 인력으로 등록되어 있었기 때문에 인건비를 캐리하는(?) 입장에서 대우는 그만큼 받지 못한다고 느껴지기도 했다.

3. 관리업무

PL업무를 수행하면서 프로젝트의 일정, 업무 분배 등의 업무를 하고, 팀장으로서 처리하는 업무들이 많은 편이었고, R&D 자체도 개발이 많지 않았지만 관리 업무로 인해 그마저도 줄어들었다. 물론 관리 업무도 좋은 경험이었고, 내게 도움이 된다곤 생각하지만 관리 업무와 프로젝트 실무가 병행되었기 때문에 집중할 수 있는 환경이 되지 않기도 했고, 아직은 효율적인 관리를 하기에는 부족한 면이 있었기 때문에 그보다는 이를 효율적으로 할 수 있는 사람이 필요하다고 생각했다. 

어떻게 하면 일정을 업무 처리 속도에 맞게 할 수 있을지, 인터럽트가 발생하면 어떻게 처리해야할지, 개인 역량에 맞게 어떻게 업무를 분배하면 좋을지 등등의 질문을 내게 했지만  끝날 때까지도 마땅한 답을 찾지 못했던 것 같다. 지금이라면 그 떄의 업무를 다시 맡게 되었을 때는 조금은 더 나은 모습이지 않을까 생각해본다.

4. 소음

근무지가 시청과 국가인권위원회(지금은 위치를 옮김)가 인접해 있어 시위가 잦았고, 서울 광장에서는 행사가 많았다. 시위의 경우엔 처음에는 시끄럽긴 했어도 그로 인해 스트레스를 받거나 소음이라고 생각지는 않았고, 시위의 목적도 어느정도 이해가 가고 동의할 수 있는 부분이 있었다. 시위로 인해 가장 고통스러웠던 건 서울 광장에서 동성애 관련 행사가 있었는데, 해당 행사를 반대하는 기독교 단체에서 한 시위였다. 이해 관계가 얽힌 상태에서는 서로가 어느정도 합당한 주장을 하지만 이 때는 당최 논리도 근거도 없고, 앰프는 볼륨을 높이고, 하루종일 같은 소릴하고, 찬송가를 불러댄다. 그런 시위가 아침부터 저녁까지 이어진다. 다른 시위는 '소리'로 느껴졌지만 이 경우는 내게 그저 '소음'일 뿐이었다. 그게 반년을 넘게 이어졌다.

행사의 경우 대부분 저녁시간에 하긴 하지만 공연을 할 때에는 낮시간에 리허설을 한다. 저음에서 울리는 앰프는 거리가 꽤 있었음에도 불구하고 창문이 우우웅-하고 울릴 정도의 크기의 소리였다. 데시벨 기준이 어떻게 되나 찾아봤지만 주거지역이 아니었기 때문에 해당사항이 없었기 때문에 마땅히 할 수 있는 일은 없었다. 심할 때는 나 뿐만이 아니라 사무실의 모든 분들이 소리와 진동에 어이가 없어 업무를 놓고 있을 때도 빈번했다.

5. 일의 만족도와 주역할

1차년도에는 그나마 OpenShift 전체 소스코드를 분석하고 역공학을 통해 문서화를 했기 때문에 배울 수 있는 부분이 많았지만, 2차년도에는 CloudFoundry 이클립스 플러그인의 한글화 + 문서화, 그리고 관리자 대시보드 프론트엔드 재개발과 문서화 작업이었다. 관리자 대시보드는 기존 CloudFoundry의 인큐베이터 프로젝트였던  admin-ui를 분석하고, 프론트엔드를 한국 정서에 맞게(?) 재개발했다. 그나마 새로이 개발을 해서 조금은 괜찮았지만 나머지는 분석, 테스트, 문서 작업이었다. 물론 모두 필요한 요소들이지만 개발역량을 키우고 계속 해나가고자 하는 입장에서는 첫 직장에서 개발 경력이 단절된 것이나 다름없으니 나로서는 업무 자체에 만족을 하기 어려웠다. 그리고 관리업무와 환경, 그리고 잦은 회의(프로젝트 + 본사)로 인해 집중하기엔 다소 무리가 있었다.

문서작업. 좋아한다. 하지만 너무 모든 것이 페이퍼 워크다. 그래도 TTA 표준 제안서를 작성할 때는 PaaS를 활용하는 애플리케이션의 아키텍처에 대해 표준을 작성하다보니 개인적으로도 공부가 된 부분도 많았고 내가 선정한 주제다보니 그나마 오너십을 좀 더 갖고 할 수 있었던 것 같다.

6. 본사 업무 프로세스와의 괴리

프로젝트는 특성상 폭포수로 진행되었고, 본사에서는 스크럼을 활용했다. 주간보고는 프로젝트에도 해야하고 본사쪽으로도 또 해야한다. 거기에 더해 작년 초에는 본사에서 관리를 강화하겠다고 주간보고에 개인 주간보고와 팀 주간보고를 함께 하도록 했다. 일단 프로젝트와 본사의 프로세스가 달랐고, 주간보고가 중복으로 이루어졌기 때문에 불필요한 업무가 추가되었다. 더군다나 개인과 팀 주간보고를 하고(디테일하게 일별로 할일을 보고토록 했다) 프로젝트에 대한 주간보고도 따로 하는 것은 낭비라는 생각이 들었다.

주간보고를 그렇게 함에도 불구하고 팔로업이 되지 않았기 때문에 더더욱이나 무의미하게 느껴졌다.

누군가가 보면 불평 불만만 가득하다고 생각할 수는 있겠지만 하고 있는 일을 하지 않았던 것도 아니고 내 선에서는 나름 잘해내었다고 생각한다. 처음에 언급했듯 대표님과 많은 얘기를 하고 최대한 개선하려고 대표님도 노력하셨지만 해결되지 못하는 것들이 많았고, 그 부분은 충분히 이해가 간다. 하지만 보다 나은 환경에서 하고 싶은 일을 할 수 있는 곳을 원했기 때문에 퇴사를 결정하고 이직을 하게 되었다. 이런 저런 불만이 많았음에도 회사에 있었던 시간을 돌아보면 '나는 좋은 구성원이었나?', '나는 좋은 팀장이었나?' 에 대한 질문에 '부족했지만 최선을 다했고, 그렇다'라고 대답할 수 있을 것 같다.

이 결정을 언젠가는 후회하게 될지도 모른다. 나는 본사에서 하고 있는 서비스를 응원하고 충분히 잘될 수 있다고 감히 생각하기 때문에 스톡옵션을 아쉬워 할지도 모른다. 하지만 회사는 회사대로, 나는 나대로의 길을 서로 응원하며 가기를 바란다.

회사에서 운영하고 있는(거의 방치된...) 서비스에서 외부 서비스의 REST API를 호출하는 부분에서 오류가 잦아, 원래의 주업무는 뒤로 미뤄진채로 오류를 고치는 작업을 하고 있습니다.

먼저 외부 서비스의 클라이언트를 작성하는 작업을 했고, 기존 코드의 외부 서비스 API 호출 부분을 교체하려고 했습니다. 작성한 클라이언트를 테스트한 후 하나씩 교체해나가고 있는데 끝이 없네요.

일단 테스트 코드가 없어 클라이언트 부분 교체 후에 어디까지 영향을 받는지 명확하게 파악하기가 너무 어려웠고, 그나마도 로그를 보려고 했더니 로그 설정도 엉망인 탓에 로그 설정부터 다시 잡아야 했습니다.

문제가 너무 많지만(...) 조금 짚어보자면

- 외부 서비스 API 연동 부분과 비즈니스 로직 부분의 커플링이 심하다.

- 중복된 코드가 많아 같은 기능에 대한 수정을 여러 번 해야한다.

- 모든 것을 서비스 레이어에서 처리한다.

- 불필요한 상속으로 인해 섣불리 베이스 클래스의 코드를 건드리기 어렵다.

- 클래스들의 역할이 불분명하다.

- InMemory DB/RDB/WAS VM은 각각 2개로 구성되어 있으나 하나만 돈다(!?)

- 세션 저장을 위한 Redis 서버는 테스트 서버의 Redis로 설정되어있었다.(......)

- 메이븐 모듈 구성이 불분명하다(쓰이지 않는 모듈이 있긴 한데. 빼려니 무섭다..)

- 배포 환경에 대한 설정 파일의 구분이 없다.(브랜치로 구분한다....잘못 수정하고 merge하면 악몽)

- 브랜치는 VM당 1개로 되어 있닼ㅋㅋ

- 외부 API와 연동 시 응답받은 JSON과 매핑되는 클래스의 필드 타입이 정확하지 않다.

(이건 외부 API 제공 업체의 문서화가 정확하지 않은 탓도 있다. API 문서에 타입이 기재되어 있지 않고, 그냥 샘플 값만 있어서 ID경우 샘플은 숫자로만 12345가 적혀있는데 사실은 정수 타입이 아닌 UUID형식의 String도 섞여 있다)

- 외부 API 호출 시의 요청 URL을 URL인코딩하지 않아 일부 케이스에서 오류가 발생했다. (서명을 생성하면서 특정한 경우에는 인코딩하지 않아도 되지만, 또 어떤 경우에는 인코딩을 해주어야 하는 문자가 포함됨)

- ... (한숨)

울고싶네요.. 하...

어쨌든 사용자의 관점에서 가장 불편을 겪고 있는 것은 외부 서비스 API의 연동으로 인한 오류인데, 회원 정보 이외의 거의 대부분의 기능은 모두 외부 서비스 API를 호출하고 있으니.. 사실 상 프로젝트의 대부분의 코드를 변경해야 하는 셈입니다.

차라리 이 서비스가 전망이 훤하고, 그저 이 전에 개발했던 분들이 시간이 없어서 그랬고, 고치기만 하면 흥할 것이라 예상이 되고, 제가 이 서비스에 애착이 있고 오너십이 있다면 좋겠지만... 모두 아니라 답답할 따름입니다.

얼른 수술 마무리하고 주업무로 넘어가야겠네요

QueryDSL 설정 시 Maven APT Plugin을 이클립스에서 사용 시 이슈가 있어서 아래와 같은 오류 메시지를 확인할 수 있다.

첫 번째 해결 방법으로는 커맨드 라인에서 직접 메이븐 빌드를 수행하는 것

두 번째 해결 방법으로는 이클립스 설정 파일에 vm을 직접 설정해주는 것

이클립스가 위치한 폴더의 eclipse.ini (Spring Tool Suite의 경우 sts.ini)에서 아래와 같이 -vmargs 옵션의 위 쪽에 -vm 옵션을 추가해준다.

※ 참고 : http://stackoverflow.com/questions/24482259/eclipse-issue-with-maven-build-and-jdk-when-generating-qclasses-in-querydsl

군것질도 좋아하고, 먹는 것도 가리지 않고 잘 먹고, 사무실에선 앉아있고, 운동은 안하고 있고..

대사량에 비해서 섭취하는 칼로리가 더 많다보니, 학교 다닐 때까지만 해도 68kg을 유지하던 몸무게가 꾸준히 늘어 70을 넘어 73, 74.. 이대론 안되겠다 싶었다.

건강하게 먹고 꾸준히 운동을 하면 제일 좋은 방법이겠지만, 시간 또는 의지 때문에(사실 의지가 있으면 시간따윈 상관없겠지..!) 운동이 아닌 '건강하게 먹기'에 초점을 맞추어 5월 18일부터 점심으로 샐러드를 먹기 시작했다.

그 전부터 샐러드를 먹고 싶긴 했지만, 팀이 두 명인 상태에서 나혼자 샐러드를 먹겠다는 건 팀원 혼자 밥먹게 두는 것이니, 나야 혼자 먹어도 상관없지만 혼자 먹지 못하는 울 팀원을 위해.. (주륵) 팀원 한 명이 더 들어와 세 명이 되고, 어느정도 친해졌다 싶어졌을 때부터 계획을 실행했다. 저녁이 아닌 점심이었던 까닭은 왠만해서는 점심 약속이 잡힐 일이 없고, 내 선에서 대부분 컨트롤 할 수 있기 때문이었다.

그렇게 두 달하고 열흘 정도가 지난 어제, 여느때와 마찬가지로 습관적으로 체중계에 올랐는데, 앞자리가 6인게 아닌가! 같이 체중계의 LED를 보고 있던 여자친구와 나는 탄성을 터뜨렸다. '오오오오!!'

아아 사무실에서 그토록 좋아하던 간식도 안먹고 꾸욱 참고, 카페에 가도 아메리카노만 마시고, 샐러드를 꼬박꼬박 챙겨먹은 보람이 있구나!

일단 목표로 하는 몸무게는 65kg, 통뼈인지라(라는 핑계) 이제부턴 운동을 겸해서 해야 만들 수 있겠지만, 다시 찾은 6! 2년만에 다시 돌아온 6! 잘 유지해야겠다

Jenkins에서 SSH 서버 추가 시 다음과 같은 오류가 발생하면서 [Test configuration]을 수행할 수 없을 때

위 문제는 SSH를 non-interactive로 세션을 접속했을 때 쉘 초기화 파일에서 표준 출력이 있는 경우에 발생한다.

접속하는 계정의 ~/.profile, ~/.bashrc, ~/.bash_profile과 같은 쉘 세션 초기화 시에 실행되는 스크립트에서 echo 명령어나 다른 명령어로 인해 출력이 있을 때 발생할 수 있다. 이 출력 값으로 인해 SSH 클라이언트나 scp, sftp에서 정상적으로 출력되지 않는 경우가 있으므로, 위 초기화 파일로 인해 출력되는 내용이 없도록 수정하면 된다.

확인 방법은 대상 SSH 서버를 원격 호스트로 하여 아래와 같은 명령을 수행해서 아무런 출력이 없음을 확인하면 된다. (/usr/bin/true 파일의 존재는 상관없다, 파일이 없을 때는 bash: /usr/bin/true: No such file or directory라고만 출력된다.)

내 경우는 쉘 접속 시 초기화 스크립트의 수행 순서를 확인하려고 .bashrc 파일에 echo "=== START ~/.bashrc ==="를 넣어두었는데, 이것 때문에 젠킨스에서 SSH 서버 설정을 테스트할 수 없었다. 위 구문만 지워주니 깔끔하게 success로 확인이 되었다.

참조 : OpenSSH FAQ - 2.9 sftp/scp is fails at connection, but ssh is OK

저번 주까지만 해도 괜찮던 랩탑이 작업을 못할 정도로 너무 느려졌다.

그저 주말에 꺼두었다가 어제 출근해서 켰더니 느렸다. 달리 설치한 거라고는 Groovy와 JRuby를 설치했다 정도..?

작업 할 때 기본적으로 크롬과 슬랙을 켜놓았는데, 슬랙에서는 타이핑을 따라오지 못할 정도로 랙이 걸리고, 크롬은 새 탭을 띄워서 페이지 로딩을 시작하는 데까지 길게는 1분이 넘게 걸리고(아직 페이지 로딩을 한 상태가 아니라 탭만 만들어지고 그대로 프리징..), 페이지를 로딩 하는데도 한참 걸린다.

무슨 이유인지 짐작할 수가 없어서 시스템 리소스를 확인해봤더니 CPU도 20~30%대이고, 메모리도 50% 미만으로 사용하고 있었는데, 혹시나 싶어 쓸 데 없는(특히 Active X류.. IE 플러그인들.. 부들부들) 프로그램들을 삭제하고,

서비스들도 정리하고, 시작 프로그램도 정리하고, 조각 모음도 해보고 재부팅도 해보고, 리눅스 파티션도 날리고 다 해보았지만 소용이 없었다.

그러던 와중에 검색 결과 중에서 크롬에서 "가능한 경우 하드웨어 가속 사용" 옵션을 끄면 하드웨어 가속 기능으로 인한 충돌을 없애서 속도를 향상할 수 있다는 걸 찾았다.

(이 글을 읽으시는 분 중에 비슷한 증상인 경우 크롬을 모두 종료하고, 파이어폭스, 오페라, 인터넷 익스플로러와 같은 타 브라우저를 실행해서 다른 브라우저는 정상적으로 동작한다면 같은 문제일 수 있습니다.)

먼저 크롬 실행 후 주소 입력 창에 chrome://settings 를 입력하거나 오른쪽 위의 메뉴에서 설정(S) 메뉴로 이동한 후,

스크롤을 내려 하단의 고급 설정 보기를 클릭하고, 펼쳐진 고급 설정에서 다시 하단의 시스템 섹션에서 "가능한 경우 하드웨어 가속 사용"의 체크를 해제하고 크롬을 재시작한다.

다행히 내 케이스는 하드웨어 가속이 문제였는지 느려졌던 증상이 나아졌다.

헌데 잘되다가 갑자기 느려진 이유를 도무지 알 도리가 없다. 그래픽 카드가 나갔나..?

참고 : 씨넷 코리아 기사 "이유없이 느린 구글 크롬 속도 개선하는 법"

여담으로 PC 리소스 모니터링을 하다가 nProtect에서 스레드를 152개를 사용하고 있었다. 윈도우즈 시스템에서 사용하는게 144개였는데.. -_- 리소스를 많이 먹고 있지는 않았지만 저 스레드를 다 어디에 쓰고 있는지 궁금하다. 결제할 때라던가 관공서 사이트를 이용할 때 설치했을텐데, 대체 왜 백그라운드에서 돌고 있는지 어이가 없다.

  확인 사항

1. Project Properties > Project Facets > Dynamic Web Module > Version 3.0

2. 프로젝트 폴더의 .settings 폴더의 org.eclipse.wst.common.project.facet.core.xml 파일 확인

3. web.xml 파일 스키마 버전 확인

4. 프로젝트 탐색기에서 프로젝트 선택 후 오른쪽 버튼 클릭하여 컨텍스트 메뉴 호출 후 [Maven] > [Update Projects...] 클릭 또는 Alt+F5키를 눌러 프로젝트 업데이트