늦은 학생 개발자 시절 회고 (~2017)

사실 개발자 회고로 1개의 글을 작성하고 싶었지만 입사 전 내용을 작성하다보니 너무 길어지고 성격도 다른 것 같아 별개의 제목으로 분리했다. 입사 후의 회고 이후 글에서 다룰 예정이다.

다른 개발자 분들의 글만 보다가, 2년차의 막바지에서 회고를 작성하려다 다른 길로 새서 학생 개발자 시절을 회고하는 글이다. 개인적으로 기록해두고 싶기도 하고 누군가에게는 도움이 되었으면 하는 마음에 적어본다.

학생 때는 요즘 학생들(?) 대부분이 많이 사용하는 JavaScript + Node.js 를 주로 사용했고
(회사에서 지나가다, 요즘 학생들이 이런거만 해보고 백엔드 개발자라고 한다며 하는 얘기도 들어본 적이 있지만...)
프론트엔드에 관심이 많은 (나보다는 뛰어난) 친구와 주로 같이 다녔는데 그 과정에서 나는 자연스럽게 백엔드를 하는... 악어와 악어새 느낌으로 개발해왔다. 매번 드는 생각이지만 이런 관계가 있던 부분이 운이 좋았다고 생각한다.

캡스톤 프로젝트

위 친구를 포함하여 캡스톤 프로젝트를 매우 재밌게 진행했는데, 간략하게 설명하자면 현재 구름(goorm.io)과 비슷한 실시간 코드 편집이 가능하고, 화상 + 채팅을 제공하는 강의 플랫폼이다. 코드 퀄리티도 별로고 심지어 지금은 반납해버린 DB 의 IP 도 공개 되어 있지만 혹시나 참고하려면 여기 에 있다.

아이디어 도출 + 구체화 + 개발까지 8월부터 12월까지 총 5개월을 소요했다. 사실 학기가 시작하기 전인 8월부터 만나서 하는게 옳은 것인지는 모르겠지만, 그 당시에는 (아무 것도 하지 않은) 한 학기를 휴학 후 복학하는 상태여서 무언가를 잘 만들어보고 싶다는 의욕이 있었다.

경과

8월 (아이디어 도출)
- 방학 주 1~2회 모임, brainstorming
  - 드론, 코드 편집기, 기타 등등
- 실시간 코드 편집을 하고 싶다
  - ShareDB 가 간단하다: 에디터 프로토타입 완성
- 구름이라는 서비스가 있는데 그냥 베껴서 만드는게 맞는가?
9월 (개강, 아이디어 구체화)
- 강의 서비스를 개발하는 것이 좋겠다는 의견 (교수님)
  - 강의할 수 있는 플랫폼을 만들자 (변경)
- 기능 도출
  - 큰 단위 기능: 게시판, 코드 편집, 채팅, 터미널 등
  - 세부 기능을 나누어 업무 분담
- 개발 환경 설정
  - FE 기반 설정 (webpack, babel, react, redux, ...)
  - 각 웹 서버 + DB 설치 등
10월, 11월 (개발)
- 개발 진행
- 내부적으로 추가 기능 의견 (화상 채팅)
  - WebRTC 검토 + 적용 (이 과정에서 https 적용)
12월 (완료 및 데모)

사용 (백엔드 기준)

ShareDB (실시간 코드 편집에 사용, Operational Transformation 기반)
MySQL, MongoDB (게시판, 채팅 기록, ShareDB 연동 등)
Docker (강의 별 개발 터미널 제공)
socket.io (터미널 I/O 처리 및 채팅)
JWT (회원 처리)

제대로 알고 사용한 것이 많지 않아서 그냥 사용 정도에 의의를 두고 있다. 다만 여기서 한 가지를 이끌어낸게 있다면 ShareDB 를 선택하게 된 과정이다. (같이 진행한 친구들에게는 이 내용을 몇 번을 우려먹는다며 욕을 먹지만)

실시간 코드 편집을 어떻게 할 수 있는지에 대해 우선 다른 서비스들은 어떤 기술 스택을 사용하는지 먼저 찾아보았다.
계속 언급한 구름이나, Google Docs 같은 서비스에 접속하여 단순 무식하게 개발자 도구를 열어보며 어떤 것들을 사용했는지 알아보았다.

이 과정에서 OT 라는 일종의 알고리즘(?) 을 찾았고 Firebase 에 올라가 있는 이름이 기억이 나지 않는 어떤 라이브러리도 찾아서 프로토타입까진 만들어보았다. 하지만 이 당시에 이 라이브러리를 사용하고 기능을 붙이는 작업을 진행하면서 DB 저장이나 기타 하고자 하는 것을 구현하기 매우 어려웠다. 그래서 다른 구현체를 찾아보다가 발견한 것이 ShareDB 였다. 실시간 에디팅부터 MongoDB 에 저장까지 매우 잘 사용할 수 있도록 구현이 되어 있었기 때문에 정의했다.

다만 "코드 편집" 이라는 기능을 하려면 대부분 IDE 에서 제공하는 Syntax Highlighting 이 되어야 하는데 여기서 유명한 것이 CodeMirror 나 ACE 등이 있었다. 코드미러의 룩이 더 좋아보여서 선택했고, ShareDB 와 연결하기 위해서 sharedb-codemirror 라는 라이브러리를 찾아서 적용하다가 문제가 발생했는데...

경험

코드 리뷰 (해커톤에서 경험하여 적용)
서드 파티 (?) 오픈 소스 수정 (메이저 오픈 소스의 버전업으로 미동작하여 수정, sharedb-codemirror)
shell script 개발 (반복되는 서버 접속, 재시작 등의 간소화)
DNS 등록

ShareDB 만 있으면 잘 동작하는 실시간 편집이, sharedb-codemirror 를 적용하면 작동하지 않았다. 남들은 잘 동작하는 것 같은데 도대체 왜 내 컴에는 안 되는지 답답하여 이 때 처음으로 라이브러리 내부 코드를 들여다보기 시작했다. ShareDBCodeMirror.prototype._init 와 같은 것을 보며 내가 JavaScript 를 잘 알고 쓰는 것도 아니어서 무슨 코드인지 모르겠다는 문제가 있었다. 어찌저찌 개념을 찾아보고 ShareDB 와 어떻게 연결되어 있는 지에 대해 보다보니, 내가 사용하는 ShareDB 의 버전에서 주는 값과 sharedb-codemirror 에서 사용하는 값이 맞지 않는 것을 발견했다.

하지만 ShareDB 의 버전을 내릴 수 없었던 것이, 이 버전에서만 제공하고 하위 버전에는 없는 기능을 이미 사용하고 있었다. 그래서 sharedb-codemirror 를 fork 하여 수정 후 PR 을 시도해보았다. 나도 오픈소스에 코드 커밋이라는 것을 해보는 건가에 대한 기대에 엄청 들떠있었는데, 관리를 하지 않는지 받아주질 않아 내가 닫아버렸고 내 repo 에만 남아있다. (영어를 못해서였을지도)

shell script 에 관해서는, 당시 캡스톤 프로젝트 외에도 자기주도연구라는 다른 과목에서 오픈스택을 주제로 진행하던 내용이 있었다. 오픈스택은 최소 3대의 서버로 구성이 필요한데 캡스톤에서는 프론트, 백엔드 각 1대의 서버가 있으므로 ip 기반으로 총 5대의 서버에 접속이 필요했다. ssh 접속에는 윈도우에서 리눅스 터미널을 사용할 수 있는 WSL 을 이용했다.

초기에는 윈도우 sticky memo 에 ip 를 다 적어놓고 ssh user@ip 를 수동으로 입력하며 접속했는데, 이게 너무 귀찮아서 다른 단축 명령어로 만들 수 있을지 않을까를 생각하던 중 스크립트를 발견했다. 결론부터 말하면 gist 에 올린 그대로이고 이전에 관련 글도 작성했었다. 이 경험으로 node 서버 관련 재시작, 시작, 중단, 포트 체크도 스크립트로 만들어서 사용했다.

기타

사실 지금 생각해보면 절대 서비스로는 나갈 수 없는 구조였다. apache, nginx 와 같은 웹서버도 따로 두지 않아 access log 추적은 당연히 되지 않았으며, 백엔드 서버는 1대의 2GB 듀얼 코어, 2GB 램에 Node.js + express, MySQL, MongoDB, Docker 가 돌아가는 엄청난 구성이었기 때문이다. (어느 정도 개발이 진행된 이후에는 ssh 터미널 접속의 딜레이가 있던 것으로 기억한다.)

위의 과정을 겪으면서 처음 들어보는 모든 것들을 끌어다 쓴 경험으로 현재 회사의 해커톤 참가 자격을 얻고, 이후 인턴에 참여하게 됐다.

인턴

현재 회사의 4주 인턴 과정에 참여했고 하나의 공통 프로젝트를 3명이서 컴포넌트를 나누어서 개발하는 과제였다. 프론트, 백엔드, 통계 컴포넌트였는데 어느 것도 자신이 없어서.. 제일 마지막에 남은 통계 컴포넌트를 진행했다 (사실 제일 어려워보여서 피하기 싶었지만). 통계 컴포넌트의 요구 사항으로는 프론트와 백엔드에서 이루어진 활동에 대한 내용을 나이별, 시간대별 등의 기준으로 집계하여 차트 UI 까지 구현하는 것이었다.

제약 및 기타 규칙

JAVA + Spring (버전 제약은 없었으나 개념이 없었음)
배치 처리
billboard.js (차트 UI)
매일 오전 스크럼

자바는 사실 학교다닐 때 거의 버려놓은 수준이었고 물론 Spring 도 하나도 몰랐지만, 객체 지향 외에 분산시스템설계라는 과목을 수강하여 Spring boot 를 사용하는 좋은 레퍼런스 코드를 하나 얻어두었기에 도움이 되었다. 문제는 배치에 대한 개념이 전무했던 상황이어서 이 개념을 대략적으로 잡는데만 Spring batch 를 포함하여 1주는 허비했다.

구현

과제는 3명이서 기능 분석과 테이블 설계부터 시작하여 실제적인 기능 구현까지 서로 도와가면서 진행했다. 예시로 나는 위에 캡스톤 프로젝트를 진행하면서 경험한 스크립트 부분을 이용하여 공통 배포 스크립트를 만들어서 공유했고, 다른 팀원으로부터 트위터에서 만든 DB 조회 기반 자동완성 모듈에 대한 내용이나 기타 Spring 기반 설정 등에 대해 전달 받았다. 대부분의 내용은 상호 코드 리뷰를 통해 주고 받은 내용이다.

멘토 분들께 받은 코드리뷰 중 기억이 나는 부분은 js for loop 사용 시 주의해야할 부분, Calendar 사용하는 중복 코드를 Util 로 분리 등이 있었다.

배치는 구글링을 통하여 여러 글들을 읽은 결과로, ItemReader 에서 원본 데이터를 얻고 ItemProcessor 에서 간단한 정제, ItemWriter 에서 새로운 테이블에 저장하는 방식이었다. 이 때 서버를 재시작하고 첫 구동 시 ItemReader 에서 계속 처음부터 읽어들이는 문제가 있었다. 서버가 죽기 전 마지막에 읽었던 부분부터 시작해야 했다. 이 방식이 맞는 지에 대해 고민을 했지만 로깅용 테이블을 하나 만들어서 마지막에 읽어들인 id를 저장했고, 새로 애플리케이션이 뜰 때 해당 테이블의 값을 들고오는 것으로 해결했다.

배치 cron 주기가 초기 매우 길었던 것으로 기억하는데 실 서비스가 아니기 때문에 데이터가 너무 적었다. 그래서 프론트와 백엔드에서 진행된 데이터가 통계로 나타나지 않았던 문제로 5분 주기로 돌도록 수정했다.

통계 화면은 jQuery 3 로 작성했고 나름 거의 SPA 와 유사하게(?) 진행했다. 서버에서 그려주는 내용은 거의 없고 페이지 1개에서 정렬 조건 버튼 4개와 데이터 버튼 4개를 각 1개씩 선택하면, 만들어둔 REST API 를 호출하여 데이터를 받아오고 billboard.js 에 넘겨서 그려주는 것이 대부분이었다. 상품 개념이 있었는데, 어떤 상품이 있는지 검색하기 위해 위에서 언급한 자동완성 모듈을 붙여주는 것이 추가 기능이었다.

사실 5개월 진행한 캡스톤과 비교하면 한 달도 채워지지 않은 4주여서 적을 내용이 적지만, 실제 4주를 진행하면서 이 짧은 기간동안 주어진 과제를 할 수 있는지에 대해 걱정하면서 이리저리 찾아보느라 정신이 없었기 때문에 기억이 잘 나지 않기도 하다.

얻은 것

배치 처리 (cron 개념, Reader, Processor, Writer 이용 등)
JAVA 개발 시 유용한 개념 (Logger, Util 등)
경험이 많은 멘토들에 의한 코드 리뷰

 

마무리

앞서 언급했던 대로 시작은 개발자 회고였지만 너무 추억 팔이성 내용이 길어져서 별도로 분리했다.
이런 경험들을 계속 쌓고 기록하면서 나중에 들춰볼 수 있게 만들어야겠다.