Browse Category

인턴기

가자고 팀에서의 웹개발자 경험기 by EastskyKang

레저큐 인턴기 7편 – 여자 개발자, 남자 디자이너를 위하여

Culture does not make people. People make culture. If it is true that the full humanity of women is not our culture, then we can and must make it our culture.
문화가 사람을 만드는 것이 아닙니다. 사람이 문화를 만듭니다.

Chimamanda Ngozi Adichie, We Should All Be Feminists

내가 다닌 학부는 남학생 140명, 여학생이 10명의 무려 14:1라는 경이로운 성비를 자랑한다. 머릿 속에 작은 방을 그려놓고 거기에 사람 15명을 들여 보낸다면 그 중 단 한명이 여자라는 것이다.

설상가상으로 우리 학부가 위치했던 신공학관은 학교 전체에서 제일 남녀 성비가 낮다는 기계공학과, 전기공학과, 컴퓨터공학과가 모여있는 건물이었다. 산 꼭대기에 위치하고 있어서 다른과 학생들이 드나들 일도 없을 뿐더러 모든 학과 수업이 이 건물에서만 열리니, 수업이 끝나고 사방에서 체크무늬 셔츠에 두꺼운 안경을 낀 공돌이들이 쏟아져 나오는 광경은 가히 진풍경이라고 할만하다.

japan_eng_student_are_on_check_shirts
단정하게 교복을 입은 공대생들. 체크무늬 셔츠와 두꺼운 안경은 공대생들의 교복이다.

누군가 그랬다. 세상의 절반은 남자고 다른 절반은 여자라고. 그런데 도대체 무엇이 잘못된걸까? 고등학교-대학교-병역특례에 이르는 지난 10년 기간 동안 단 한번도 여자가 많은 조직을 경험해 본 적이 없다. 혹시 내가 뭔가를 잘못하고 있는 것은 아닐까? 세상에 남자와 여자의 수가 같은 집단이라는 게 존재하기는 하는걸까?

성비 균형의 꿈

it_did_happpen

놀랍게도 레저큐에 입사 하면서 나는 그런 조직을 실제로 볼 수 있게 되었다. 여성 직원과 남성 직원의 수가 거의 1대 1인 조직이 실존하고 있었던 것이다.

사실 이런 성비가 가능한 것은 레저큐의 직원들이 맡고 있는 역할과 업무가 정말 폭넓기 때문이다. 개발에서부터 디자인, 상품 운영, CS, 마케팅.. 업무의 폭이 넓으니 직원들의 연령, 성별도 다양할 수 밖에 없다. 그런데 이렇게 1대 1로 균형 잡힌 구성원들의 성비는 남성, 여성 모두에게 어필 할 수 있는 상품들을 판매하는 이커머스 서비스에는 매우 중요한 요소이기도 하다.

남성과 여성은 세상을 인지하고 바라보는 관점, 관심사, 구매 성향이 다르다. 남성 소비자가 서비스에 요구하는 것과 여성 소비자가 서비스에 요구하는 것은 크게 다를 수 있다. 서비스를 운영하는 사람들은 남성 소비자와 여성 소비자 모두를 잡기 위해서 두 관점, 모두에서 서비스를 바라볼 수 있어야 한다. 이를 달성하기 위한 가장 좋은 방법은 당연 구성원에 비슷한 수의 남성과 여성을 두는 것이다.

여성과 남성의 관점 차이에서 생기는 토론과 합의는 더 훌륭한 아이디어를 만들어 낼 수 있는 힘의 원천이 되기도 한다. 서로 다른 관점에서 나온 의견이 때로는 충돌하기도 하고, 때로는 보완되기도 하면서 더욱더 멋진 아이디어가 탄생한다.

실리콘 밸리의 기업들이 성별, 인종, 문화, 전문분야 등에서 다양성을 지향하는 이유도 여기에 있다. 국제적인 서비스, 전 세계 사람들이 이용하는 제품을 만들고 운영하기 위해서는 먼저 서비스를 이용하는 사람들에 대해서 잘 이해하고 있어야 한다. 더불어, 빠르게 변하는 시장에서 끊임 없이 새롭고 멋진 아이디어를 내며 진화할 수 있어야한다. 이를 달성할 수 있는 가장 효과적인 방법은? 바로 기업을 구성하는 구성원의 다양성을 추구하는 것이다.

apple_diversity
애플은 다양성을 모토로 내걸고 있는 회사 중 하나이다. 다양한 인종, 성별, 전공, 문화를 가진 사람들이 애플에서 일하고 있다.

다양성이 비효율을 수반하는가?

어떤 사람들은 이렇게 주장한다. “다양성은 응당 비용을 수반한다. 남성 사원들로 조직된 조직을 상상해보자 이들이 여성을 채용하기 위해서는 기업의 환경, 인프라, 문화를 바꿔야 한다. 이런 비용을 지불하느니 기존에 해왔듯이 남성들로만 기업을 운영하는 것이 더 나을 수도 있다. 그 반대의 경우도 마찬가지이다.”

이들의 말이 맞을 수도 있다. 하지만 레저큐에서 인턴을 하면서 배우게 된 중요한 사실 중 하나는 기업이 성적, 문화적 다양성을 추구하는데 드는 비용보다 그 것을 달성 했을 때 얻을 수 있는 이득이 훨씬 크다는 것이었다.

뿐만 아니다. 다양성의 추구는 기업의 사회적 역할과도 무관하지 않다. 다양한 인종, 그리고 성별, 특히 소수거나 사회적 약자의 위치에 있는 이들에게 기업이 일자리를 제공하고 소득을 분배할 수 있다면 그 어떤 국가적 차원의 지원과 캠페인들이 만들어 내는 것보다 더 큰 효과를 낼 수 있다.

the_more_women_work_the_more_babied_are_born
다양성과 양성평등은 한 커뮤니티, 나아가서 한 사회가 안고있는 골치아픈 문제들을 해결하는 열쇠가 될 수도 있다. (이미지 출처: TechInsider – Norway solved the gender problem that’s creating a crisis in Japan and Korea)

스웨덴의 저명한 통계학자인 한스 로슬링 카롤린스카는 한국을 괴롭히고 있는 저출산과 고령화의 해결책이 페미니즘이 될 수 있다고 주장한다. 실제로 스웨덴은 저출산 문제를 양성평등 확대를 통해서 해결하려는 노력을 펼쳐왔고 이런 문화를 안정적으로 정착시켜 저출산이라는 난제를 멋지게 해결하고 있다.

우리 사회 구성원들의 머리를 아프게 하는 심각한 사회적 문제들을 극적으로 해결할 수 있는 방법이 있다면, 그리고 그 것을 해결하는 것이 아주 사소한 변화에서부터 출발하는 것이라면 이런 문화를 만드는데 투자해야하는 비용은 기꺼이 지불할 만한 것일테다.

옥의 티 찾아내기

우울했던 14대 1 성비의 내 학부시절과 비교했을 때, 레저큐에서의 생활은 분명 훨씬 더 ‘다양’하고 ‘생동감’ 있었다. 이런 점에서 분명 레저큐는 꽤나 모범적인 조직이라고 할 수 있을 것이다. 하지만 여전히 아쉬운 점이 있다. 팀이나 부서별로 떼어놓고 보면 팀을 구성하는 여성, 혹은 남성의 비율이 다소 편중되어 있다는 것이다. 이를테면 레저큐의 개발팀의 개발자 전원은 남성이며, 레저큐의 디자이너들은 한명을 제외하고는 모두 여성이다.

사실 이런 모습은 우리가 소속되어 있는 한국 사회와 정서의 문제와 무관하지 않다. 왜 이공계에는 남성이 압도적으로 많은 것일까. 왜 디자인 학부에는 여학생이 남학생보다 훨씬 더 많은것일까? 정말 남성이 이성적이고 논리적인 사고에 강하고 여성이 섬세하고 감성적인 사고에 강하기 때문일까?

marie_curie
남성은 여성보다 이성적인 사고에 강하며 여성은 남성보다 감성적인 사고에 강하다?

남성과 여성의 능력의 차이에 대해서 생각해보기 이전에 우리 사회가 성역할의 관념에 매몰되어 그런 차이를 만들어내고 있지는 않은지, 혹시 그러한 문제로 인해서 우수한 인재들을 놓치고 더 멋진 기회들을 놓치고 있지는 않은지 되돌아 볼 필요가 있다. 결국 관념과 편견, 문화 그리고 사회적 시스템은 전부 ‘사람’들이 만들기 나름인 것이니까.

여자 개발자, 남자 디자이너를 위하여

레저큐에서 인턴을 하는 동안, 서로 다른 업무를 맡고 있는, 다양한 배경과 성별을 가진 직원들과 소통하며 이 것이 소비자 시장을 대상으로 하는 기업에 강력한 무기가 될 수 있다는 것을 실감했다. 특히 스타트업은 개개인의 개성, 성별, 배경, 그리고 나아가서 문화와 인종의 다양성을 추구할 수 있어야한다.

아쉽게도 다양성의 측면에 있어서 우리는 아직 갈 길이 멀다. 하지만 긍정적인 변화들이 곳곳에서 일어나고 있다. 때로는 이를 추구하고 수많은 담론들을 테이블에 올려놓는 과정에서 수많은 파열음들이 들리기도 한다. 그럼에도 불구하고, 건설적인 담론들이 테이블 위로 올라오고 있다는 것, 사회 구성원들의 생각도 점점 변화하고 있다는 것은 분명 긍정적인 신호일 것이다.

가까운 미래에 여성개발자들과 남성개발자들의 수가 비슷한 개발팀, 그리고 남성디자이너들과 여성디자이너의 수가 비슷한 디자인 팀을 레저큐에서 볼 수 있기를 희망해본다. 어쩌면 기대보다 좀 더 많은 시간이 걸릴 수도 있겠지만 좀 더 다양한 사람들이 일하는 회사, 레저큐는 분명 더 멋지고 생동감 있는 기업이 되어 있을 것이다. 🙂

By EastskyKang

레저큐 인턴기 6편 – 백엔드 개발 도전! (2)

웹API 컨트롤러의 레이어드 아키텍쳐

전편에서 이어집니다…

가자고 웹API의 컨트롤러는

  • Controller 레이어: 가장 상위에서 유저의 리퀘스트(request)를 받고 리스폰스(response)를 돌려줌.
  • Service 레이어: Controller 밑에서 실질적인 비지니스 로직의 구현을 담고 있음.
  • Repository 레이어: DB와의 인터페이스를 담당.

이상의 세개 레이어(layer)로 구성되어 있다. 이렇게 하나의 시스템을 여러개의 레이어(층)로 분리하고 차곡 차곡 쌓아 올라가는 식으로 개발하는 방식을 ‘레이어드 디자인 패턴(Layered Design Pattern)’이라고 부르는데, 소프트웨어 엔지니어링에서 가장 보편적인 디자인 패턴 중 하나이다.

여러가지 이유가 있겠지만 이렇게 레이어를 나누는 가장 중요한 이유는

  1. 규모가 큰 시스템을 여러개로 모듈화하여 한 모듈의 문제가 시스템 전체로 번져나가는 것을 막음과 동시에 각 모듈을 쉽게 교체하기 위함이자, (종속성의 최소화, 재사용성)
  2. 오로지 하나의 이슈를 해결하도록 분리된 각 층을 추상화함으로써 컴포넌트 간에 인터페이스를 쉽게 하고 개발을 용이하게 하기 위함이다. (표준의 지원)

Screenshot 2016-09-06 14.59.49.png
가자고 웹API의 컨트롤러는 Controller, Service, Repository 등의 레이어로 구성된 레이어드 아키텍쳐(Layered Architecture)를 따른다.

레이어드 아키텍쳐 관점에서 개발 미션 바라보기

이쯤에서 나의 개발 미션이 무엇이었는지 다시 떠올려보자.

입력한 조건에 따라 DB에서 서비스 운영에 필요한 통계자료를 추출하는 웹 API를 새로 만들기

개발 미션을 가자고 웹API 컨트롤러의 레이어드 스트럭쳐 관점에서 바라보면 구현 단계를 가장 밑에서부터 네단계로 쌓아 올라가는 것으로 압축할 수 있다.

  1. Model 클래스 구현: 쿼리로 조회한 데이터를 담을 모델 클래스 만들기.
  2. Repository 구현: 데이터 추출 SQL 쿼리를 자바로 구현하기.
  3. Service 구현: 비지니스 로직을 코드로 구현하기. 즉, Repository에서 쿼리로 가져온 데이터들을 어떻게 가공하고 Controller에 다시 돌려줄 것인지 고민하기.
  4. Controller 구현: API에 URL 자원을 RESTFul하게 할당하고 유저의 리퀘스트 처리. 리스폰스 리턴.

사실 Repository 레이어에서 DB로부터 데이터를 가져오는 것을 빼고는 복잡할 것이 없는 작업이다.

  • Model 클래스에서는 내가 필요한 정보(DB의 필드에 해당한다)가 무엇인지 고민하고 이 값들을 담을 수 있는 변수들을 멤버로 가지고 있는 클래스들을 새로 만들어주면 된다. (클래스 만들기는 자바의 기본!)
  • Service에서는 Repository에서 돌려준 데이터들의 묶음(Collector: List, Map 등…)을 엑셀 템플릿과 엑셀 라이브러리를 이용해서 엑셀 파일로 출력해주면 된다. (엑셀 라이브러리만 가져다 쓰면 된다!)
  • Controller는 사실상 스프링 프레임워크에서 제공되는 라이브러리들을 이용하면 자바 어노테이션과 몇 줄 안되는 코드로 구현이 가능하다. (스프링이 알아서 다 해준다…)

자 그렇다면 이번 개발 미션의 핵심이 무엇인지 드러난다. Repository에 SQL SELECT 쿼리를 자바로 구현하는 것이 이번 개발 미션에서 가장 중요한 부분이다.

JOOQ로 SQL SELECT 쿼리를 자바로 구현하기

가자고 어플리케이션은 DB 인터페이스에 JPA(Java Persistence API: 자바 영속성 API)와 JOOQ(Java Object Oriented Querying)를 이용한다.

JPA는 자바 진영의 표준 ORM(Object-relational mapping) 기술로, 관계형 DB를 객체지향패러다임 언어인 자바에서 쓰기 위한 맵핑을 담당하는 기술이다. 표준 영속성(여기서 영속성이란 프로그램이 종료되어도 사라지지 않는 속성, 즉 DB 데이터의 속성을 의미한다) API인 만큼 자바를 이용해서 백엔드 개발을 하는 개발자들이 익히 잘 알고 있는 기술이다.

반면에 JOOQ는 다소 생소한 이름일 수 있다. 스위스 취리히 소재의 스타트업 Data Geekery이 운영하고, 개발하고 있는 JOOQ는, SQL 쿼리를 자바로 구현해야 하는 상황에 이용하는 라이브러리이다. 즉, 미리 작성해 놓은 SQL 쿼리를 그대로 자바로 옮기고 싶다거나, 아니면 JPA로는 구현이 힘든 매우 복잡한 SQL 쿼리를 짜야하는 경우에 멋진 대안이 된다. (참고로 이런 목적으로 사용하는 또 다른 라이브러리 중에 유명한 것이 iBatis 란 기술이다. 가자고 시스템에도 iBatis를 사용한 적이 있었지만 지금은 대부분 JOOQ로 대체하고 있다.)

좀 더 와닿는 코드 예제로 살펴보자. 백엔드 어플리케이션에서 아래와 같은 SQL 쿼리를 사용할 일이 있다고 가정하자. (코드 출처는 wikipedia.org – Java Object Oriented Querying)

위의 SQL 쿼리는 STATUS가 ‘SOLD OUT’인 BOOK 들의 AUTHOR 정보를 가져오는 테이블이다. JOOQ를 이용해서 자바로 변환하면, 이렇게 짤 수 있다.

JOOQ를 이용하면, SQL 문법과 상당히 유사한 자바 코드로 SQL 쿼리를 작성 할 수 있다. 자 그렇다면 이제 JOOQ를 이용해서 내가 작성해두었던 SQL SELECT 쿼리들을 자바로 옮길 차례다.

keep-calm-and-code-on
나우 잇츠 타임 포 코딩!

하나만 간단히 살펴보자. 가자고 서비스 운영에 필요한 정보 중에 특정 아이템을 구매한 고객들의 이름, 이메일, 전화번호를 알아야 하는 경우가 있었다. 이 리스트를 추출하기 위해서 아래와 같은 SQL SELECT 쿼리를 작성했었다.

이 것을 새로 생성한 Repository 클래스의 public List<FrontUser> getItemUserStat(List<String> itemCode) 메서드에 구현했다.

잠시 코드를 살펴보자. 먼저 해당하는 SQL SELECT 쿼리를 JOOQ를 이용해서 만들고 나서, fecthInto(FrontUser.class) 메서드를 호출했다. 이 메서드는 FrontUser 라는 모델 클래스의 리스트(List<FrontUser>)를 리턴하는 것을 확인 할 수 있다. 따라서 이 메서드에, 조회하고 싶은 아이템들의 itemCode를 List<String> 로 전달하면 해당하는 사용자의 정보를 FrontUser 모델 클래스의 리스트로 얻을 수 있다.

이렇게 JOOQ로 쿼리를 짜면 쉽고 간단하게 쿼리를 만들 수 있다. IDE의 자동완성 기능의 도움을 받는다면 일일이 JOOQ의 문서나 매뉴얼을 뒤져보지 않아도 그 자리에서 바로 SQL 쿼리를 자바로 옮길 수 있다.

이렇게 완성된 Repository 메서드를 이제는 거꾸로 Service에서 이용하고, 마지막으로 Controller에서 Service 메서드를 호출하면 SQL로 DB에 쿼리를 날렸을 때와 동일한 데이터를 자바 객체 묶음(Collector: List, Map 등등)으로 얻을 수 있었다. Controller의 각 메서드에 이제 RESTFul 한 URL을 할당해주기만 하면 웹 API가 완성된다!

새로운 세계

그렇게 작성한 나의 첫 백엔드 코드를 커밋(Git Commit)하고, 마침내 나의 풀리퀘스트(Pull Request)가 master 브랜치에 머지(merge) 되는 순간, 새로운 세계가 열렸다! 얕게는 매일 SQL 쿼리를 짜고 DB에서 데이터를 긁어오는 반복 노동으로부터의 해방된 것이고, 깊게는 백엔드 개발의 프로세스에 대한 경험을 해보게 된 것이다. 무엇보다 기뻤던 것은 드디어 가자고 프로젝트에 유의미한 기여를 할 수 있게 되었다는 사실이었다.

물론 이 것은 시작일 뿐이었다. 작동하는 웹 API를 만들어보기는 했지만, 웹 어플리케이션이라는 것이 무엇인지, 어떻게 동작하는지 제대로 이해하게 된 것도 아니고, Spring, JOOQ, JPA와 같은 기술들의 문서를 숙지하고 개발한 것도 아니고, 더군다나 효율적인 개발 프로세스대로 개발을 해본 것도 아니다. 그렇지만 내가 만든 API가 제대로 가자고 웹 어플리케이션 위에서 동작한 것을 확인했을 때의 즐거움이란 어마어마한 것이었다. 하하! 드디어 나도 이제 웹개발자구나! 🙂

여튼 이렇게 웹 개발의 ‘ㅇ’도 모르고 있었던 내가 DB를 다루고 관리하는 일부터 시작해서 백엔드 어플리케이션을 개발하는 백엔드 개발자의 업무를 경험해보기 까지 1달이 좀 못되는 시간이 걸렸다. 물론 그때는 몰랐다. 백엔드 개발에 더 익숙해지는데까지는 훨씬 더 많은 시간이 걸릴 것이라는 것을…

백엔드 개발 도전! 편 끝. 레저큐 인턴기는 계속 이어집니다…
By EastskyKang

레저큐 인턴기 5편 – 백엔드 개발 도전기 (1)

신이라면 믿겠지만 아니라면 데이터를 가져와야 합니다.

인터넷에서는 사용자의 결정과 행동을 추적하여 누적해두고 의미 있는 정보로 ‘데이터화’하는 것이 가능하다. 그리고 이런 데이터는 웹 쇼핑몰이라는 가상의 매장을 만들어놓고 상품을 판매하는 이커머스 서비스에게는 매우 강력한 무기가 된다. 웹사이트에서 어떤 사용자 경험성(UX, User Experience)을 제공할지, 어떤 상품을 노출할지, 어떤 가격으로 판매할지 등을 결정할 때 사용자의 구매 패턴과 행동 데이터들을 이용할 수 있고, 이를 통해 서비스의 매출을 극대화 시킬 수 있기 때문이다.

데이터를 기반으로 이커머스 서비스는 어떤 유저에게, 어떤 상품을, 어떤 가격으로(논쟁거리가 되기도 한다!) 노출할지 개인화할 수 있어서, 경제학에서 말하는 이상적인 판매 전략을 실현하여 큰 이익을 낼 수 있다. 따라서 데이터화와 분석은 이커머스가 기존의 상거래 시스템과 차별화되는 가장 주목할만한 요소 중 하나이며 기업의 성장과 직결되는 문제이다.

bigdata
빅데이터! 빅데이터! 빅데이터! 인터넷 세계에서 유저들이 만들어 내는 수많은 데이터들을 수집하고 잘 분석하는 것은 이제 이커머스 서비스에 필수적인 역량이 되었다. (이미지 출처 : LinkedIn post by Amarnath K Mattad)

이커머스 서비스는 사용자의 구매 패턴과 행동을 통계내고 분석하는 툴 혹은 시스템을 잘 구축해야 한다. 물론 사용자와의 인터랙션을 추적하는데 이용하는 Google Analytics과 같은 툴들도 훌륭하긴 하지만 아무래도 DB에서 가져오는 통계보다는 훨씬 부정확하고, 이커머스 운영의 의사결정에 활용하기 위한 정보들을 얻기에는 기능이 부족하다.

가자고 개발팀은 얼마 전부터 엘라스틱서치라는 검색엔진/데이터 저장소를 이용해서 매출과 실시간 판매 데이터등을 통계내고 비주얼라이제이션 하는 시스템을 구축하고 있다. 하지만 서비스 초창기에는 실시간으로 서비스 데이터를 수집하고 분석하는 시스템을 구축할 시간이 없었다. 대신 필요한 데이터가 있을 때 마다 SQL(Structured Query Language)코드로 직접 데이터베이스(DB)에서 판매 데이터나 매출 정보들을 긁어오는 ‘노동집약적인 방식'(^^;)으로 데이터를 수집하고 분석했다.

SQL
SQL은 관계형 데이터베이스 시스템을 관리하고, 조건에 맞는 데이터를 질의(Query) 하는데 이용되는 표준 언어이다.

나의 첫 백엔드 개발

나같은 새내기 개발자에게는 이런 작업이 좋은 기회가 될 수도 있다. DB에서 원하는 데이터를 가져오는 작업을 통해 시스템과 DB의 구조에 대해서 파악할 수 있었기 때문이다. 이커머스 서비스는 DB의 구조와 관계가 매우 복잡한데, 원하는 데이터를 얻기 위해서 어떻게 SQL 쿼리를 짤지 고민하는 것이 이 구조를 이해하는데 좋은 연습이 된다.

하지만 며칠이 지나자 통계를 얻기 위해서 SQL을 짜고, DB에 쿼리를 날리고, 얻어낸 데이터를 다시 스프레드시트에 정리하는 반복적인 작업들이 귀찮아지기 시작했다. 조금씩 조건이 바뀔 뿐, 매일 같이 반복적인 작업을 하는 것일 뿐인데, 수작업으로 SQL을 작성하고, 쿼리를 날리고, 데이터를 스프레드시트 포맷에 정리하는 일련의 일들이 생각보다 훨씬 번거롭고 지루했던 것이다.

이걸 자동화 할 수 있는 방법은 없을까? 당연히 있다. 가자고 백엔드 어플리케이션에 아예 이 통계를 내주는 기능을 추가하고 API를 만들어서 관리자 사이트에서 필요한 데이터의 종류와 검색 조건을 입력하면 해당하는 데이터를 엑셀로 정리해서 다운받을 수 있게 하면 된다.

자, 그렇다면 이제 드디어 첫 백엔드 개발을 시작할 때가 되었다. 일찍이 난무하는 자바 어노테이션(Java Annotation)들과 복잡한 구조에 기죽어서 포기했었던 백엔드 개발에 다시 도전하게 된 것이다.

그 첫번째 미션은 바로 입력한 조건에 따라 DB에서 서비스 운영에 필요한 통계자료를 추출하는 웹 API를 새로 만들기!

백엔드와 프론트엔드

여기서 잠깐 백엔드(Back-end)나 프론트엔드(Front-end)라는 용어를 정리하고 넘어가자. 위키피디아에 따르면 백엔드와 프론트엔드는 이렇게 정의되어 있다.

In software engineering, front end and back end distinguish between the separation of concerns between the presentation layer (the front end) – which is the interface between the user – and the data access layer (the back end). The front and back ends may be distributed among one or more systems.

갓 위키피디아 님에 따르면, 어플리케이션에서 엔드 유저의 눈에 보이지 않는 쪽을 백엔드(back end), 반대로 웹 브라우저 등을 통해서 유저에게 보여지는 쪽을 프론트엔드(front end)라고 한단다. 즉, 브라우저에서 유저와 인터랙션 하는 웹사이트의 UI를 구현하는 것은 프론트엔드 개발이고, 그 UI에 데이터를 뿌려주고, 사용자의 요청을 받아 비지니스 로직대로 처리할 수 있도록 구현하는 것은 백엔드 개발이라고 할 수 있다.

프론트엔드 개발자는 JavaScript, HTML, CSS 등을 이용해서 사용자 친화적인 UI(User Interface)를 구성하는데 주안점을 둔다. 반면에 백엔드 개발자는 사용하는 웹 프레임워크에 따라 Java(Spring, Spark…) 혹은 Python(Django, Flask …) 혹은 JavaScript(NodeJS) 혹은 Ruby(Ruby on Rails)를 이용해서 개발한다. 백엔드 개발자들이 가장 중요하게 생각하는 것은 웹 어플리케이션의 성능과 안정성, 그리고 아키텍쳐이다.

최근엔 백엔드, 프론트엔드, DB 관리, 서버 관리 등 웹 개발에 필요한 기술 전반을 모두 다룰 수 있는 풀스택 개발자(Full-stack developer)들도 시장에서 각광을 받고 있지만, 스타트업의 개발자들은 보통 백엔드 개발 전문 혹은 프론트엔드 개발 전문으로 역할을 나눈다. 백엔드 개발과 프론트엔드 개발은 요구하는 기술이 다르고 초점을 맞추는 것도 다르기 때문에 철저히 전문화된 개발자를 필요로 하기 때문이다.

web dev
웹 개발자들에게 요구되는 기술들. 보통은 한 명의 개발자가 이 모든 것을 다 하기 쉽지 않기 때문에 프론트엔드 개발, 백엔드 개발로 역할을 나누고는 한다. 좀 더 자세히 알고 싶다면 Michael Wales가 Udacity 블로그에 쓴 3 Web Dev Careers Decoded: Front-End vs Back-End vs Full Stack을 참조하자.

가자고는 8명의 개발자가 함께 개발하고 있는데 프론트엔드에 치중하는 개발자가 2명, 백엔드에 치중하는 개발자가 4명, 그리고 그 모두를 개발하고 있는 풀스택 개발자가 1명 있다.

나머지 1명인 나의 역할? 어디에도 속하지 않지만 어디에도 속할 수 있으니 풀스택 개발자라고 치자. ^^

백엔드 개발하기

백엔드 어플리케이션은 서버에서 데이터를 비지니스 로직대로 처리하고 처리한 데이터를 웹 API(Application Program Interface)를 통해 제공하는 역할을 한다. 프론트엔드 개발자들이 우리 눈에 보이는 UI 껍데기를 만들어 놓으면 백엔드 개발자가 개발한 API로 데이터와 리소스들을 불러와서 뿌려주는 것이다.

가자고는 백엔드 프레임워크로 스프링 프레임워크 (Spring Framework)를 쓴다. 스프링은 Java 진영에서 가장 널리 쓰이는 오픈소스 웹 어플리케이션 프레임워크이다. 엔터프라이즈 용으로 개발된 웹 프레임워크이기 때문에 방대하고 기능이 매우 다양하며 유지보수가 쉬운 (쉽나…?) 프레임워크이다. 다만 방대하고 기능이 많은 만큼 진입장벽이 높고, 배우기 어려운 프레임워크이기도 하다.

spring_framework
스프링 프레임워크는 이제는 사실상 Java진영의 엔터프라이즈급 표준 웹 어플리케이션 프레임워크가 되었다. 무엇이든지 할 수 있는 스위스칼 같은 존재랄까…

가자고는 일반적으로 웹 어플리케이션에 적용되는 MVC 디자인 패턴에 따라서 어플리케이션을 뷰(View), 컨트롤러(Controller), 모델(Model)로 나눠서 개발을 하고 있다. 각 컴포넌트들의 역할을 정리해보면…

  • 모델: 관계형 DB에서의 테이블에 대응되는 개념이다. 즉 데이터 스키마라고 볼 수 있다.
  • 뷰: 브라우저를 통해서 유저의 눈에 보이는 UI를 구현한 소스코드와 그 컨테이너에 해당한다.
  • 컨트롤러: 유저의 요청사항(request)를 받아 데이터를 의뢰하고, 가공 후 웹 API의 형태로 돌려준다(response).

뷰가 프론트엔드(JSP, JS, HTML, CSS 등에 해당)에 해당한다고 하면 컨트롤러와 모델이 백엔드에 해당하는 컴포넌트이다. 따라서 웹 API를 만들기 위해서는 처리하고자 하는 데이터들의 스키마(설계도 혹은 틀 쯤으로 생각할 수 있다)를 모델로 정의 및 구현하고, 컨트롤러에서 요청을 받아 비지니스 로직대로 처리하여 돌려 줄 수 있어야 한다.

다만 가자고에서는 (일반적인 웹 어플리케이션들이 그렇듯이) 컨트롤러의 역할을 서비스(Service: 비지니스 로직을 구현한 부분. 추상화된 ‘모델’을 이용하여 이를 가공하고 컨트롤러에 돌려준다.), 리포지토리(Repository: DB와의 인터페이스를 담당한다. ‘모델’의 추상화를 담당하는 부분이다.) 등의 여러개의 레이어로 나누어 개발하고 있다. 이런 구조를 레이어드 아키텍쳐(Layered architecture) 라고 부른다….

mvc_pattern
MVC 패턴의 개념도. (이미지 출처: 구루비 위키)

spring_layered_archtecture
스프링 프레임워크의 레이어드 아키텍쳐. (이미지 출처: petrikainulainen.net)

아, 새로운 용어들이 나오니까 벌써 머리가 아파온다. 자세한 내용은 생략하자… 다음에 좀 더 자세히 얘기할 기회가 있을 것 같다. 여튼 백엔드 개발은 이렇게 복잡한 디자인과 구조, 그리고 웹을 이루는 기반 기술들에 대한 이해를 요구하는 작업이다. 하지만 (이 무렵의) 나에게 이러한 지식과 이해 따위가 있었을리 없다. 그래서…

일단 만들고 보자

그 많은 지식들과 기반 기술들에 대해서 습득할 시간도 없고, 방대한 개발 문서들을 읽을 수도 없다. 숙련된 개발자는 새로운 프레임워크나 라이브러리들을 익히기 위해서 개발문서를 차분히 읽어보면서 기능과 개념을 공부하겠지만 나와 같은 새내기 개발자에겐 아무리 잘 쓰여진 개발문서도 “흰것은 종이요 검은 것은 글자” 일 뿐이다. ‘내가 무엇을 아는지, 무엇을 모르는지’ 전혀 모르는 상태이기 때문이다.

그래서 일단 만들고 싶은 것을 땅바닥에 헤딩해가며 만들어보기로 했다. 그러다 보면 내가 무엇을 공부해야 하는지, 개발 문서에 잔뜩 써져 있는 외계어들이 무엇을 의미하는 것인지도 점점 알게 될 것이다. 다행히 이미 가자고 팀 개발자들이 짜놓은 API 코드가 아주 많으니 참고할 코드도 충분하다.

시작부터 험난하지만 이렇게 나의 첫 백엔드 개발이 시작되었다. 구체적으로 어떻게 했는지 계속 이어서 쓰고 싶지만 이미 충분히 길어졌으니 아 힘들다… 좋은 글귀를 남겨놓고 이번 편을 마무리하자. 다음편에서 계속…

정신적인 존재로서 드넓은 물을 향해 가자.
너는 거기에서 종횡무진으로 살아가며,
마음대로 움직이리라.

요한 볼프강 폰 괴테, “파우스트” 중

By EastskyKang

레저큐 인턴기 4편 – 님과 함께

레저큐에는 직급과 나이에 상관 없이 직원들 간에 ‘님’ 호칭을 쓰고 항상 높임말을 사용한다. 자유롭게 소통할 수 있는 수평적인 조직 문화를 만들기 위해서이다.

나이와 직급이 천차만별인 50명 규모의 조직에서 상하에 상관 없이 서로 ‘님’이라고 부르는 것은 생각만큼 그렇게 쉬운 일만은 아니다. 하지만 ‘님’ 호칭을 쓰는 것은 아주 중요한 규칙이다. 직원들간의 원활한 소통과 창의적인 아이디어가 그 무엇보다도 중요한 스타트업에서 호칭은 조직 문화와 직결되는 문제이자, 조직의 근간이 되는 철학과도 밀접하게 엮여져 있는 문제이기 때문이다.

잡음은 두배로, 메시지는 반으로

우리는 관계의 상하를 따지는 문화에 익숙하다. 자신을 소개할 때 나이를 먼저 이야기 하는 것이 당연하고, 조직이나 단체에서 누군가를 부를 때 직급이나 호칭을 붙여 부르는 것이 더 자연스럽다. 윗 사람은 존경을 받고 아랫 사람은 존중을 받는 이런 문화는 유서 깊고 아름다운 것으로 인식되어 왔다.

그러나 때로 이런 문화가 조직원들간의 소통을 방해하기도 한다. 중요한 정보가 확산되지 않고, 창의적인 의견들이 빠르게 제시되지 않으며 때로는 위화감이 조성되기도 한다. 결국 이러한 문제점들이 조직에 아주 큰 비용으로 돌아오는 경우가 많다. (우리는 이런 사례들을 많이 보아 왔다.)

meeting-image
회의 때의 모습을 생각해보자. 어떤 회의 모습이 떠오르는가? 상석에 앉은 사람이 일장연설을 펼치는 동안 직위에 따라 도열한 아랫 사람들이 열심히 고개만 끄덕이는 회의? 아니면 활발하게 서로 토론하고 직급, 나이의 고하에 상관없이 누구나 자유롭게 발언하는 회의?

현대 경영학의 아버지, 피터 드러커는 “명령 계층 수를 최소화해서 조직을 가능하면 ‘수평적’으로 만드는 것이 조직구조의 원칙”이라고 말했다. 모든 명령의 전달 단계마다 잡음은 두 배로 늘어나고, 메시지는 반으로 줄어들기 때문이다. 즉, 조직의 계층을 최소화해야 합리적인 의사결정이 이루어지고, 효과적인 소통이 이루어 질 수 있다는 것이다.1)

peter-drucker
현대 경영학의 아버지, 피터 드러커. 그는 노동자들이 지식으로 생산활동을 하는 지식 사회에서는 수평적 조직 문화가 중요하다고 주장했다.

이런 철학은 기업들로 전파되었고, 특히 IT 스타트업들을 중심으로 수평적 조직문화를 극단적인 형태로 운영하는 사례들이 나타나기 시작했다. 가장 잘 알려진 사례 중 하나는 Half-Life, Counter-Strike, Portal 의 제작사이자 Steam이라는 게임 배급플랫폼으로 유명한 Valve라는 회사이다. 이 회사는 최소한의 경영진만 남겨두고 조직의 구조와 관리자 직위, 직급 자체를 완전히 없애버렸다. 심지어 팀의 조직도, 직원들이 스스로 하고 싶은 프로젝트에 합류해서 팀을 정할 수 있도록 했다.2)

valve-corporation
밸브 사의 오피스 모습. 이 회사에는 직급도 없고 심지어 정해진 팀도 없다. (이미지 출처: The Wall Street Journal, Who’s the Boss? There Isn’t One.)

이런 문화가 Valve 사에 가져온 효과는 명확하다. 직원들 개개인이 가지고 있는 권한, 특히 결정과 판단의 자유가 대폭 확장되고, 직원들이 얼마든지 창의성을 발휘해서 제품을 개발 할 수 있게 되었다. 실수가 있더라도 빠르게 개선되고, 서로의 실수나 실패가 감추어지는 일이 적어졌다. 직원 개개인의 의견과 동기를 존중하는 수평적인 구조의 회사 문화가 탁월한 성과로 이어졌다.

IT 스타트업의 ‘기업문화’에 대해

물 건너 우리나라에서도 IT 기업들을 중심으로 나이와 직급에 상관 없이 호칭을 통일하고, 나아가서 수평적인 조직 문화를 추구하려는 시도들이 일어나고 있다. 네이버에서는 직급 대신에 ‘님’ 호칭을 쓰고 카카오에서는 서로를 영어 이름으로 부른다. 물론 직원들끼리는 직위와 나이에 관계 없이 항상 높임말을 사용한다.

레저큐와 같은 IT 스타트업에서는 수평적 조직 문화가 더욱 더 중요하다. 스타트업에서는 조직원 개개인의 전문성과 생산성이 굉장히 중요한 문제기 때문이다. 팀의 규모가 작을수록 개개인이 가지고 있는 전문성과 능력을 극대화 시키는 것이 중요한데 그러기 위해서는 모든 조직원들이 동등한 위치에서 의사를 피력하고, 자신의 가지고 있는 전문화된 지식을 최대한으로 활용 할 수 있어야 한다.

물론 수평적 조직 문화가 회사의 성과를 보장하는 ‘만능 해결책’은 아니다. 단점 역시 명확하다. 2013년 미디어를 떠들석하게 했던 valve 사의 집단 해고 사건이 이를 보여준다. (이 때 퇴사했던 이들은 valve 사는 아무도 ‘인기 없는 일’을 맡아 하지 않으려고 하고, 오히려 은밀한 내부정치가 횡횡하는, ‘고등학교’와 같은 조직이었다고 주장했다. 3)) 게다가 수평적 조직문화는 형성하기도 유지하기도 어렵다. 누가봐도 수직적인 의사결정이 이루어지고, 소통이 종적으로 일어나는 조직에서 직원들이 서로를 ‘님’이라고 부른다거나 높임말을 사용하는 것이, 진정으로 소통의 장벽을 제거하는 수평적 조직을 만들 수 있는 것이 아닌 것이다.

lol-asking-parent-anbu
모두가 ‘님’이라는 존칭을 쓰는 완전한 수평 조직, 게임 세계. 그러나 ‘님’이라는 호칭이나 수평적 문화를 만들겠다는 것이 중요한게 아닌 것 같기도…

하지만 수평적이고 합리적인 조직은 젊은 구직자들에게 매력적이다. 많은 청년들이 자신의 의사가 존중받고, 자신의 능력을 자유롭게 발휘할 수 있는 조직에서 일하고 싶어한다. 그 동안 연봉과 복지가 회사를 결정하는데 가장 중요한 요소였다면 이제는, 젊은 인재들에게 조직이 얼마나 수평적이고 민주적인지도, 취업 하고 싶은 기업을 정하는 중요한 지표 중 하나가 된 것이다.

내가 인턴을 하면서 경험한 레저큐는 수평적이고 자유로우며 합리적인 기업문화를 만들기 위해서 노력하고 있는 회사였다. 생각보다, 이렇게 즐겁게 일할 수 있고, 직원 개개인이 존중받는 다는 느낌을 받게 해주는 조직은 흔치 않다. 물론 이런 기업문화를 계속 유지하고 가꾸어나가기는 쉽지 않을 것이고, 회사의 규모가 점점 커질 수록 중대한 도전들에 직면하게 될 것이다. 조직원들이 함께 그 도전들을 잘 극복해나가고 좋은 문화들을 계속 가꾸어나면서 성장하는 기업이 될 수 있으면 좋겠다. 🙂

References

  1. 조영탁, “수평조직을 구축하라!”
  2. 밸브 신입사원 안내서
  3. 노트A – “밸브 수평 관리 구조의 함정”

by EastskyKang

레저큐 인턴기 3편 – EastskyKang 님이 leisureq/gajago에 push했습니다.

가자고는 매우 복잡하고 방대한 소프트웨어 시스템이다. 전체 소스코드가 500만 줄에 달하고 서브시스템(sub-system)이 5개가 넘는다. 아무리 뛰어나고 생산성이 높은 개발자라고 하더라도 이렇게 크고 복잡도가 높은 소프트웨어를 혼자서 개발할 수 없을 것이다.

가자고 팀에는 6명의 개발자가 있고, 이들이 협업하며 동시에 가자고 프로젝트를 개발한다. 그런데 여기서 잠깐 생각해보자. 도대체 어떻게 협업해서 소스코드를 작성하는걸까? 개발해야 하는 프로젝트는 하나인데 작업을 하고 있는 개발자는 여러명이다. 제일 먼저 상상할 수 있는 방법은 아마, 아래와 같은 모습일 것이다.

개발자 A와 B가 동시에 어떤 시스템을 개발하고 있는데 이들이 각자 다른 부분을 수정하고 있다. 이 프로젝트는 굉장히 잘 모듈화되어있고, 개발자들은 굉장히 전문화되어서 분업이 잘 이뤄지고 있다. 이들은 업무 시간 동안 열심히 코딩을 하고, 각자 수정한 부분을 퇴근하기 전에 합치는 작업을 수행한다. 야근이 잦지만 뭐, 아직까지는 양호하다.

쉽게 상상할 수 있는 그림이다. 그런데 문제가 생겼다.

어느날 개발자 A와 B가 실수로 동시에 같은 부분을 수정했다. 이때부터 문제가 생긴다. 아무리 비슷한 실력의 개발자더라도 생각하는 방식과 코딩 스타일이 크게 다르다. 이 둘은 서로 ‘충돌’이 난 부분을 모여서 같이 고치기 시작했고, 각자가 ‘같은 일’을 하도록 짠 코드가 완전히 다르게 작성되었다는 것을 깨달았다. 기억을 더듬어 일일히 수정한 코드를 한줄한줄 비교해봐도 어떻게 코드를 합치는 작업을 해야할지 결정하기가 쉽지 않다.

불쌍한 개발자 A와 B가 밤샘 작업을 통해서 수정하고 합치는 작업에 성공했다고 해보자. 그러나, 만약 개발자가 2명이 아니라 5명으로 늘어난다면 어떨까? 전체 시스템의 코드가 100만, 1000만 줄에 육박한다면 어떨까?

panic
다 망해버려라! (이미지 출처: http://www.itworld.com)

개발자의 영원한 친구 Git과 GitHub

다행히도 세상에는 버전 컨트롤 시스템(Version Control System)이라는 훌륭한 것이 존재한다. 이름에서 유추할 수 있듯이, 개발자가 작성한 소스코드의 버전을 관리하고 협업을 가능하게 해주는 시스템이다. Git이나 Subversion, Mercurial 등이 여기에 속한다.

가자고는 근래의 많은 개발 프로젝트들이 그렇듯이, Git이라고 불리는 VCS를 사용하고 있다. 참고로 Git은 Linux의 아버지, Linus Torvalds가 발명한 것이다. 리눅스 커널(리눅스 OS의 핵심부)을 개발할 때 전 세계 수많은 개발자들의 협업과 배포 버전 관리를 할 수 있는 방법이 필요했는데 적당한 방법을 찾지 못해 짜증이 난 Torvalds가 무려 2주만에 Git을 개발했다고 한다.

linus_torvalds_nvidia_fxxk_you
현존하는 가장 위대한 프로그래머, 오픈소스계의 영원한 아이돌, Linus Torvalds. (Linus Torvalds를 구글에 검색하면 제일 위에 이런 사진이 뜨는데 어떤 상황이었는지는 이 글을 참조…)

마이크로소프트 (악의 제국…) 페이스북, 트위터, 모질라 등 굵직굵직한 기업과 단체에서 Git을 사용하고 있다. 뿐만 아니라 전 세계의 수많은 개발자들, 학생들도 Git을 이용해서 소스코드를 관리한다.

Git의 방식은 프로그래머가 소스코드를 수정하고나서 ‘커밋'(commit)을 하면, 그 때까지의 수정 기록들을 커밋 단위로 모두 저장하는 것이다. 따라서 열심히 수정한 소스코드가 날아가버릴까봐 걱정할 필요도 없고, 지금 작업한 것을 버리고 예전 버전의 소스코드로 되돌리는 것도 자유롭게 할 수 있다. 뿐만 아니라, 버전을 분기시켜서 별도로 관리할 수도 있다. 커밋을 줄줄이 이어놓은 것을 하나의 ‘브랜치'(branch)라고 하는데 이 branch를 새로 분기시켜서 새로운 버전의 소스코드를 작성하는 것이다.

git_branch
Git branch. Git에 대해서 더 자세히 알고싶다면 여기 혹은 여기을 참조하시길… (이미지 출처: git-간편안내서)

여전히 풀리지 않는 의문이 하나 있다. Git을 써서 소스코드의 버전을 관리하기 좋다는 것은 알겠는데 어떻게 여러명의 개발자들이 Git으로 협업을 할 수 있는 걸까? 이런 의문에 대한 답이 Git 원격저장소(Git remote)라고 불리는 기능이다. 쉽게 말하면 서버나 클라우드 어딘가에 Git 저장소를 만들어놓고 여러명의 개발자들이 접근 할 수 있도록 하겠다는 것이다. 이런 Git 원격저장소를 호스팅하는 서비스가 여러군데 있는데 이 중에서 제일 유명한 것은 당연 자유소프트웨어의 성지(?)라고 불리는 GitHub이다.

github_logo
깃허브의 로고. (문어고양이…?) 깃허브는 social coding을 표방한다. 개발자들이 사진이나 글 대신에 소스코드를 공유하고 같이 협업하는, 즉 개발자들의 SNS이다.

GitHub는 개발자들이 무료로 git 저장소를 만들고 접근할 수 있도록 해준다. 다만 전제조건이 있는데, 무료 저장소는 모든 유저들이 볼 수 있도록 공개로 해놓아야한다. 이런 특성 때문에 많은 오픈소스 프로젝트들이 GitHub를 이용해서 git 저장소를 호스팅한다. 참고로 2016년 기준으로 가장 인기 있는 github 오픈소스 저장소는 트위터에서 만든 웹 UI 프레임워크 bootstrap, 구글의 angular.js, 페이스북의 react 등이다.

가자고도 GitHub를 이용하는데 우리의 소중한 소스코드를 누구에게나 공개할 수는 없기 때문에 GitHub의 기업용 유료계정을 통해 Git 저장소를 비공개로 관리하고 있다. 각 개발자들은 GitHub에 올라가 있는 Git 저장소를 자신의 개발머신에 ‘복제'(clone) 하고 자신의 커밋을 GitHub 저장소로 ‘푸쉬'(push) 하는 식으로 공동작업 한다. 이 과정에서 ‘풀 리퀘스트'(pull request)라는 기능을 사용하기도 하는데, 간단히 말하면 개발자가 자신이 개발하려는 기능을 아예 새로운 브랜치 에 만들어놓고 코드 리뷰를 요청하는 것이다. 이 브랜치는 프로젝트의 ‘마스터 브랜치'(master branch: 프로젝트의 기본 브랜치. 보통 실 서버에서 운영하고 있는 어플리케이션의 코드에 해당)와는 별도로 운영되기 때문에 코드 리뷰를 한 사람이 머지하기 전까지는 서비스에 아무런 영향을 끼치지 않는다.

github_gajago_repository
GitHub에 올라가 있는 가자고 저장소. 얼마전에 1주년을 맞이했다.

EastskyKang pushed to master at leisureq/gajago

나도 Git와 GitHub를 꽤 오래 전부터 써오고 있었다. 다만 지금까지 협업을 할 만큼 복잡한 시스템을 개발해 본 적이 없었기 때문에 늘 Git 저장소를 혼자서 썼을 뿐이다. 앞에서 얘기했듯이 혼자서 쓰더라도 Git과 GitHub는 굉장히 훌륭하다. 적어도 아래 그림과 같은 상황은 생기지 않는 것이다.

version_management_failured
최종…최종…최종… 버전관리 실패의 예 (이미지출처 : http://slowalk.tistory.com/)

하지만 역시 Git과 Github의 진가는 여럿이서 동시에 개발을 할 때 발휘된다. 특히 Git을 효과적으로 쓸 수 있게 해주는 몇가지 툴을 함께 사용한다면 여러명이서 동시에 개발하면서 발생할 수 있는 비효율(위에서 우리의 개발자 A와 개발자 B가 겪었던…)을 거의 느끼지 않고 협업을 할 수 있다. 심지어 각자가 고친 소스코드를 리뷰하고 함께 고민하는 과정에서 자연스러운 성장을 경험하기도 하고, 이전에는 찾을 수 없었던 문제들을 발견해내어 고치기도 한다. 1+1 = 1.5 였던 것이 1+1 = 3 정도가 되었다고나 할까…

나의 첫 커밋은 회사에 입사한지 정확하게 4일 뒤에 이루어졌다. 수정한 코드 라인은 정확하게 1줄… 고작 이 한줄을 고쳤을 뿐인데도 혹시나 내가 수정한 코드 때문에 서비스에 장애가 날지도 모른다는 걱정에 덜덜 떨면서 커밋을 했던 기억이 난다. (물론 모바일 앱의 개발에 필요한 플러그인을 추가해준게 다라서 뭔가 문제가 있었더라도 아무일도 일어나지 않았을 것이다 ^^;)

first_commit
가자고 저장소에 등록된 나의 첫 커밋. 수정한 줄수는 정확히 한줄.

6개월이 지난 지금, GitHub에 기록된 EastskyKang의 커밋은 총 197번. 대략 20000 줄의 코드를 추가하거나 수정했고, 수정의 범위도 예전에 비해서 훨씬 넓어졌다. 참으로 장족의 발전이 아닐 수 없다 🙂

이제는 매일같이 브랜치를 새로 만들고, 코드를 수정해서 풀 리퀘스트를 만들고 이슈와 코멘트를 남기고 브랜치들을 머지하고 있다. 때로는 고급 Git 기능들을 이용하기도 한다. 하지만 이 기간동안 내가 배운 것은 단순히 프로젝트를 이해하고 Git을 쓰는 법을 배운 것 뿐이 아니었다. 이 과정에서 자연스럽게 여러명의 개발자들과 협업하고 같이 프로젝트를 발전시켜가는 방법을 배울 수 있었다.

협업은 혼자서는 절대 할 수 없었던 일들을 가능하게 해준다. 특히 개발 프로젝트에서의 협업은 때로 1+1 > 3 의 기적을 만들어내기도 한다. 개발자들은 항상 어떻게 해서 협업의 효율성을 높이고 협업의 생산성을 높일지 늘 고민한다. Git과 GitHub도 그런 개발자들의 문화와 오랜 고민에서 탄생한 결과물이라고 할 수 있을 것이다.

협업의 중요성과 더 나은 협업에 대한 고민, 내가 가자고 팀에서 인턴을 하면서 얻을 수 있었던 가장 소중한 배움이다.

by EastskyKang

레저큐 인턴기 2편 – 첫 출근

첫 출근

1월 18일, 첫 출근날 아침. 꿈의 랩탑인 맥북프로 레티나가 주어졌다. 15인치 화면에 RAM이 16 GB나 달려있는 ‘크고 아름다운’ 녀석이다.
설레는 마음으로 전원 버튼을 누르자 ‘쫘안’하는 따스한 부팅음과 함께 검은 화면에서 흰색 사과가 떠오르고, 곧! 널찍하고 시원한 화면이 나타난다.

maxresdefault.jpg
~~내 몸 값보다 비싼~~ 맥북 프로 15인치. (이미지 출처: DetroidBORG)

신나는 마음을 진정시키고 개발 환경을 세팅할 차례다. IDE(Integrated Development Environment: 통합 개발환경)와 플러그인, 개발툴들을 설치하고 테스트 환경을 세팅한다. 가자고 팀에서는 Jet Brains 사의 Java용 IDE IntelliJ를 사용하는데 학교에서 vim만 사용하던 내게, IntelliJ 이거, 정말 신세계다.

마지막으로 GitHub에서 가자고 프로젝트를 클론해서 내려받는다. 자, 이제 개발을 시작할 모든 준비를 마쳤다. 마침내 가자고 프로젝트의 소스코드를 열어볼 시간이다. 아무래도 Java가 익숙하니 백엔드 코드를 먼저 살펴보자…

어라 근데 뭔가 이상하다… 분명 Java로 작성된 코드인데 세상에, 이게 무엇인가. 내 눈앞에 펼쳐진 소스코드는 왜 이렇게 생소한걸까? 웬 듣도 보도 못한 Annotation 들이 덕지덕지 달려있는 건가. 클래스는 왜 이렇게 많으며 무슨 처음 듣는 용어들은 왜 이렇게 많은가.

아아, 뭔가가 잘못되어가고 있다. 하지만 진정하고 프론트엔드 코드를 살펴보자… 여기는 그래도 뭔가 좀 이해할 만한 것이 있을 수도 있다. 그러나 나의 희망은 곧 눈앞에 모습을 드러낸 암호문과 같은 프론트엔드 소스코드와 함께 산산조각이 나버리고 만다. 그제서야 비로소 깨달았다. 그동안 내가 해온 프로그래밍이 장난에 불과한 것이었다는 걸…

school vs world.jpg
젠장, 학교를 5년이나 다녔는데! (이미지출처: http://preemploymentassessments.com/)

컴퓨터공학을 공부한다는 것, 프로 개발자가 된다는 것.

학부 컴퓨터공학(혹은 컴퓨터과학) 수업에서도 프로그래밍을 한다. 단순한 알고리즘을 구현하는 간단한 코딩을 할 때도 있지만 때로는 꽤나 복잡한 시스템을 구현하기도 한다. 이를테면 DB 시스템을 구현하거나 linux 커널을 해킹한다거나하는 것들 말이다. (사실 linux 커널 해킹 수준이 되면, 그 누구도 절대 단순한 프로그래밍을 한다고 할 수는 없을 것이다.)

그럼에도 불구하고 현업에서 프로그래밍을 한다는 것과 학교에서 프로그래밍을 한다는 것은 완전히 다른 일이나 마찬가지다. 사실 어느 것이 ‘우위에 있다’고 얘기하기 보다는 ‘다른 영역의 일이다’라고 얘기하는 편이 나을 것 같다. 구체적으로는 이런 것들이 다르다.

  1. 학교에서의 프로그래밍과 현업에서의 프로그래밍은 초점과 지향점이 다르다. 컴퓨터공학 수업은 우리가 사용하는 컴퓨터 기술들의 토대에 대해서 가르친다. 따라서 프로그래밍도 원리와 이론의 학습이나 검증을 목표로 한다. 반면에 현업 프로그래밍에서는 이론보다는 구현 그 자체가 더 중요하다. 사실 너무나 당연하다. 그 구현이 곧 회사의 비지니스이기 때문이다.
  2. 문제의 핵심이 다르다. 학교에서의 프로그래밍에서 핵심은 아이디어이다. 협업에 대한 고려와 코드의 질에 대한 고려는 상대적으로 중요도가 덜하다. 그러나 현업에서의 프로그래밍은 코드의 질과 협업에 대한 고려가 가장 중요한 요소 중 하나이다.
  3. 접근 방법이 다르다. 학교에서의 프로그래밍은 현실적인 문제들에서 자유로울 수 있다. 문제들을 추상화시키고 단순하게 생각해도 괜찮다. 현업에서는 그렇지 않다. 항상 현실적인 문제들과 맞닥뜨리고 계속해서 새로운 균형을 찾아나가야 한다. 반면에 현실적으로 큰 문제가 되지 않는 것들은 과감히 무시할 수도 있다.
  4. 기술의 범위가 다르다. 학교에서의 프로그래밍은 가장 로우레벨의 기술들에서부터 차근차근 구현해나간다. 현업 프로그래밍에서는 이미 개발되어 있는 기술들을 얼마나 빠르게 잘 활용하느냐가 중요하다.

컴퓨터공학을 전공한 학생들 중에는 뛰어난 프로그래밍 실력을 가진 학생들이 많다. 그러나 모두가 그런 것은 아니고, 사실 그럴 필요도 없다. 컴퓨터공학에서 뛰어난 프로그래밍 실력을 요구하는 분야는 일부에 불과하기 때문이다. 이를테면, 알고리즘이나 전산학 이론에 대해 공부하고 연구하는 학생들은 프로그래밍 언어보다 수학에 더 익숙하다.

마찬가지로, 좋은 프로그래머가 되기 위해서 반드시 컴퓨터공학을 전공할 필요는 없다. 프로그래밍에서 컴퓨터공학적 지식을 요구로 하는 경우 역시 일부에 불과하기 때문이다. 그보다 자신의 코드의 품질에 집착하고, 얼마나 프로그래밍 생산성을 높일 수 있는지에 대해서 고민하는 사람이 더 좋은 프로그래머의 자질을 가진 사람이라고 할 수 있을 것이다.

difference_between_a_programmer_a_developer_a_computer_scientist.png
프로그래머와 개발자 그리고 컴퓨터 과학자. 학교는 컴퓨터과학자를 길러내는 곳이지 프로그래머나 개발자를 길러내는 곳이 아니다. (이미지 출처: http://www.improgrammer.net/)

다시 처음부터 다시 처음! 처음!

나의 인턴 생활의 첫 날은 ‘현업과 학업의 차이’라는 아주 근본적이면서 또한 아주 거대한 간극에 대한 깨달음으로 귀결되었다. 그러나 이대로 포기할 수 없다. 나의 뇌가 백지 상태임을 깨달았으니 첫 획부터 다시 차근 차근 그려나가야 한다.

그 첫 획을 긋기 위해서, 부랴부랴 데이터베이스의 구조부터 공부하기 시작했다. 가자고는 관계형 데이터베이스 (key와 value들의 간단한 관계를 여러개의 테이블로 정리한 형태의 데이터베이스) 시스템 MySQL을 이용하고 있고, 복잡한 구매와 상품 정보를 저장하기 위한 수십개의 테이블들이 서로 얽혀 있기 때문에 이 관계들과 구조에 대해서 제대로 이해하는 것이 개발을 위한 첫걸음이라고 할 수 있다.

처음엔 몇개의 테이블을 JOIN 해서 데이터를 가져오는 간단한 SQL(Structured Query Language: 관계형 데이터베이스 시스템에서 데이터를 관리하기 위해 이용하는 프로그래밍 언어)스크립트부터 시작했다. 이를테면 특정 상품을 2016년 1월 한달 동안 구매한 고객들의 리스트라던가 1월 한달 동안 어떤 상품 옵션을 통해 발생한 매출을 구해본다던가, 하는 것들이다.

그리고 나서는 점점 복잡한 데이터들을 추출할 수 있는 쿼리 명령어들을 짜봤다. 특히 마케팅이나 매출 집계에 활용할 수 있는 각종 통계 데이터들을 추출하기 위한 쿼리를 작성했다. 활발하게 구매활동을 지속하고 있는 고객들, 다소 장기간 동안 구매활동이나 접속 기록이 없었던 고객들의 리스트 등…

그렇게 레저큐에서의 첫 일주일 동안은 가자고 프로젝트 소스코드는 단 한줄도 손대지 않은채, SQL 문법과 DB 구조에 충분히 익숙해지기 위한 훈련을 했다. 조금 감을 잡고 나서는 쿼리 성능에 중요한 요소들이 어떤 것들이 있는지, 어떤 식으로 쿼리 최적화를 할 수 있는지 고민도 해보면서.

사실 SQL 스크립트를 작성하고 최적화하는 작업은 굉장히 지루한 작업이다. 그러나, 나의 오랜 학부 생활은(햇수로는 7년에 달한다…) 적어도 매우 중요한 한가지 가르침을 내게 남겨주었다. 항상 새로운 지식을 터득할때는 최초의 문턱을 넘기 위해 지난한 시간들을 견뎌내야 한다는 것. 그래서 조금은 우습지만, 나의 첫 커밋(commit)을 잠시 연기해두고 가장 기초가 되는 것들부터 차근차근 공부해나가기 시작했다. 마치 운동 선수들이 본격적인 시합에 앞서서 곳곳의 세밀한 근육들을 단련시키는 것처럼 🙂

By Eastsky Kang

레저큐 인턴기 1편 – 시작하며

시작은 거창하게

This is just the beginning, the beginning of understanding that cyberspace has no limits, no boundaries.
이것은 시작일 뿐입니다. 사이버 세상은 한계도, 경계도 없다는 것을 이해하게 되는 시작 말입니다.

Nicholas Negroponte, co-founder of MIT Media Lab.

할일이 없으면 생각이 많아진다. 오늘이 그랬다. 무던히도 더웠고 마침 아무런 계획 없는 일요일이라 빈둥거리다 문득 이런 생각이 들었다. ‘우와! 우리는 정말 신기한 시대에 살고 있구나!’ 이게 갑자기 무슨 소리인가 싶지만 오늘 하루 있었던 일을 떠올려보면 이런 생각이 드는 것도 무리가 아니다.

  1. 아침. 지구 반대편, 스위스에 있는 선배와 마치 옆에 있는 것처럼 실시간으로 카카오톡 메시지를 주고 받는다.
  2. 점심 무렵. 넷플릭스로 영화 한편을 본다. 미국 대통령 암살 사건에 대한 영화인데 이거 완전 내 스타일이다. 어떻게 골랐을까? 그냥 넷플릭스가 이걸 보라고 추천해주고 아이패드에 끊김 없이 영화를 전송(스트리밍)해주기까지 했다.
  3. 무더운 오후. 날씨가 너무 덥다고 생각하며 온라인 쇼핑몰에서 흰색 반팔 티셔츠를 하나 구입한다. 클릭 몇번으로 마음에 드는 티셔츠를 선택하고 결제까지 완료했다. 아마 내일이나 늦어도 모레 쯤 우리 집 앞에 택배로 도착할 것이다.
  4. 저녁 즈음. 음악을 듣다가 곡에 대해서 궁금해져서 구글에 검색을 한다. “구프타프 말러, 교향곡 6번”. 고급 정보가 주르륵 쏟아진다. “말러 교향곡 중에서 고전적 형식미와 혁신적인 요소들을… 불라불라” 수 분 내에 나는 말러의 인생과 그의 교향곡들에 대해 전문가가 된다.
  5. 하루 종일. 언제나 그렇듯, 페이스북을 공연히 들락날락 거리며 친구들의 여름 휴가 사진을 흘깃흘깃 훔쳐본다. 아 부럽구나 나도 어디론가 떠나고 싶다 생각하며.

20~30년 전만 해도 누가 알았겠는가, 이런 세상이 오게 될지. 남녀노소 가릴 것 없이 전세계 모든 사람이 현실 세계와 인터넷 세계, 두개의 평행 세계에서 살아가고 있다. 하나의 세계에서 살아가는 것만 해도 충분히 터프한 일인데 사람들은 두개의 세상에서 동시에 살아가는 고달픔을 마다하지 않는다. 왜 그런가? ‘인터넷 세계의 나’가 전지전능하기 때문이다. 수만 km 를 날아 지구 반대편 사람과 대화를 할 수 있고 쇼핑몰에 갈 필요 없이 마음에 드는 물건들을 살 수 있다. 심지어 가만히 앉아만 있어도 내 어리석은 친구들은 스스로 자기가 뭘하고 있는지, 어떤 생각을 하고 있는지 주기적으로 보고를 해준다. 오늘은 어느 카페에 가서 어느 원산지의 커피를 마셨다느니, EU를 탈퇴한 영국 때문에 주식이 망했다느니, 유로 2016 결승컵은 누구에게 돌아갈지 궁금하다느니…

facebook-graph-network
초연결사회이다. 지구 상의 모든 인류가 인터넷을 통해 서로 연결되어 있다.

인터넷 그리고 웹 프로그래머

이게 전부 다 인터넷이란 것 덕분이다. 그런데 놀랍게도 인터넷은 만들어진게 채 30년이 되지 않는다. 우리가 인터넷이라고 부르는 WWW(World Wide Web – 월드와이드웹)은 유럽 입자 물리 연구소의 컴퓨터 과학자인 팀 버너스 리(Tim Berners-Lee)에 의해 1989년에 개발되었다. 처음에는 학자들이 서로 빠르게 학술 정보를 교환할 수 있도록 하기 위해서 이런 세계를 고안했다고 한다. 어째 이런 고상한 기술을 친구들이 어떤 디저트를 먹었나 훔쳐보는 용도로 사용하고 있는 내 자신이 비참하게 느껴지긴 하지만 우리는 닐 암스트롱을 달에 보낼 때 사용했던 컴퓨터보다 몇 배 더 좋은 컴퓨터를 쓰고 있고 그 컴퓨터로 앵그리버드를 쏘아 보내며 살고 있는 세대가 아닌가. 원래 세상은 그런것이라고 위안을 해본다.

angry-bird
우리는 NASA의 과학자들이 닐 암스트롱을 달에 보낼 때 썼던 컴퓨터보다 몇 배는 더 좋은 컴퓨터로 앵그리버드를 날려 보내고 있다.

여하튼 WWW이 탄생하고 나서 얼마후 세상에 웹 프로그래머 라고 불리는 사람들이 나타났다. 이들은 스스로를 해커(Hacker)라고 부르며 인터넷 세상에 무엇인가를 뚝딱뚝딱 만들어내는 신기한 사람들이다. 채 30년이 지나지 않아서 이들은 WWW 세계에 검색엔진, 온라인 쇼핑몰, 소셜 네트워크라는 어마어마한 것들을 만들어 낸다.

웹 프로그래머들의 능력은 대단하다. 요새는 한명의 웹 프로그래머가 하루 밤 사이에 웹 사이트 하나 만들어 내는 것은 일도 아니다. 더 신기한 것은 이들은 심지어 자기가 만든 것을 인터넷 세상에 공짜로 공개하기까지 한다는 것이다. “누구나 가져다 쓰시오. 발전 시킬 수 있다면 더 좋음.” 자본주의 논리로는 쉽게 이해할 수 없는 행동이다. 왜 이런 짓을 할까? 요약하자면 내가 만든 것을 다른 사람들과 같이 쓰면 더 나은 것으로 발전시킬 수 있기 때문이다. ~~사실 어차피 돈은 다른 방법으로 벌 수 있다~~

이젠 이들의 엄청난 능력과 특별한 문화가 ‘일반인’들에게도 별로 낯설지 않다. 요새는 일반인들도 전공과 무관하게 금방 해커가 된다. 오픈소스와 클라우드, 그리고 인터넷 세상에 널려있는 수많은 정보들을 이용하면 생각보다 그리 어렵지 않다. 해커가 해커를 만들어내고 또 다시 그 해커들이 새로운 해커들을 만들어낸다. 언제까지? 세상 사람들 모두가 해커가 될 때까지.

새옹지마

사실 10년 전만 해도 이 정도는 아니었다. 대학 입시를 앞두고 있었던 2008년 쯤, 어느 과에 지원해야 하나 하는 깊은 고민에 빠져 있는 내게 컴퓨터 과목 선생님이 하신 말씀이 아직도 기억에 생생하다. “어디를 가도 다 괜찮아. 그런데 컴퓨터과는 가지마. 여긴 3D야.” 그 때만 해도 컴퓨터 공학의 위상은 이랬다. 이 분야는 소수의 재능있는 친구들의 영역이었고 나와 같은 범인들에게는 위험하고, 지저분하며, 고통스러운 분야였다. 2009년에 나의 모교를 졸업한 150명 정도 되는 학생들이 이공계열 대학으로 진학 했는데 그 중에 컴퓨터 공학과로 진학했던 사람은 손에 꼽힐 정도로 적다.

지금은 어떨까? 서울대학교 컴퓨터공학부의 정원이 50명 남짓인데 모든 전공 과목마다 150명이 들어갈 수 있는 대형 강의실들이 꽉꽉 들어찬다. 컴퓨터공학 학생들 50명에 복수전공, 부전공 학생 50명, 그리고 타과생 50명이 같이 수업을 듣기 때문이다. 강의실이 좁아서 수업을 하기가 쉽지 않다는 교수님들의 투정이 그냥 투정으로만 들리지는 않는다. 심지어 갑자기 개설해야하는 전공과목 숫자가 늘어나서 강의할 교수님이 부족하다는 얘기까지 들린다. 미국, 유럽, 중국… 어딜가나 컴퓨터공학(혹은 컴퓨터과학)과가 가장 인기가 많다. 참으로 글로벌하게, 인생사 새옹지마가 아닐 수 없다.

컴퓨터 공학의 위상이 이렇게 변한것은 지난 10년 동안 컴퓨터 기술과 IT 산업이 엄청난 속도로 발전했기 때문이다. 컴퓨터 과학의 발전과 함께 프로그래머란 사람들이 어마어마한 일들을 저질렀고 그들이 세운 구글, 페이스북, 마이크로소프트, 애플 같은 회사는 전세계에서 가장 덩치가 큰 회사들이 됐다. 전 세계에 스타트업 열풍이 불고, 프로그래머들의 몸값이 높아지고 있다. 새벽녘 드럼통에 개발자들이 불 피워놓고 기다리고 있으면 봉고차에서 “여기 자바 2명!” 라고 외치는 시대는 확실히 지나갔다.

yogi-java-du-myung!
IT 산업의 흑역사: 여기 자바 2명 타요!

멀리 돌아서

나는 2013년에 컴퓨터공학 복수전공을 시작했다. 여러가지 이유가 있었지만 사실 컴퓨터 공학을 공부하게 된 동기 중에 하나는 인터넷 세상에 대한 호기심이었다. 웹 기술과 소프트웨어 공학이 만들어낸 이 엄청난 변화, 도대체 어떻게 이런 일이 가능한 것인지에 대한 궁금증, 그리고 나도 해커들 같이 강력한 ‘힘’을 가진 사람이 되면 좋겠다는 생각. 그 때는 그 시작이 컴퓨터 공학을 공부하는 것이라고 생각했다.

그러나 꿈과 현실은 늘 다르다. 학교에서 열심히 공부를 한다고 해서 그런 능력을 얻을 수 있는 것은 아니라는 것을 깨닫는데 그리 오랜 시간이 걸리지 않았다. (그렇다고 후회를 한다는 것은 아니다! 나중에 여기에 대해서 좀 더 자세히 얘기해볼까 한다.) 열심히 공부했지만 마지막 학기가 되기까지 그 동기를 충족시킬 만한 변화를 찾기는 힘들었다.

그래서, 졸업하기전 마지막으로 새로운 도전을 한 번 더 시작하기로 했다. 스타트업에서 웹 프로그래머의 삶을 경험해보자! 웹 프로그래밍에 대해서 배우는데 웹 프로그래머로 일하는 것 보다 더 좋은 방법이 어디있겠는가? 갑자기 새로운 흥분이 느껴졌다. 오 이제야 말로 나도 이제 해커들의 세계로 들어간다! 근데 한가지 문제가 있었다. 나는 코딩 실력도 형편 없고 웹 프로그래밍의 웹자도 모른다는 것이었다. 아니 세상에 컴퓨터공학을 전공한다면서 코딩도 능숙하지 않다니 도대체 학교에서는 무엇을 가르친단 말인가? 라고 생각할 수도 있다. 근데 원래 그렇다. 컴퓨터 공학을 공부한다는 것이 프로그래밍을 잘하게 된다는 것을 의미하지는 않는다.

여하튼, 방황하고 있던 그 때에 이 미천한 공학도에게 한 회사가 기회의 손을 내밀었다.

다시 본론으로

레저큐는 여행 레저 전문 이커머스(e-commerce) 서비스 가자고를 운영하고 있고 빠르게 성장하고 있는 IT 스타트업이다. 복잡한 웹 시스템을 어떻게 구축하고 운영하는지 경험할 수 있고, 무엇보다도 복잡한 오프라인 비지니스 로직을 어떻게 인터넷 세계의 소프트웨어로 구현해낼 수 있을지 고민할 수 있는 기회를 가질 수 있다는 점에서 새내기 프로그래머에게 최고의 직장이다.

사실 무엇인가를 처음부터 시작해야한 다는 것은 꽤나 고통스러운 일이다. 2016년 1월에 레저큐 가자고 팀에 합류하고 나서, 밑바닥부터 공부를 해야했다. 지루하고 힘들었지만 비로소! 이 과정에서 내가 기대했던 것들을 배울 수 있었다. 웹이란 것이 대체 무엇인지, 웹 프로그래밍은 어떻게 하는 것인지, 프로그래머의 삶이란 것이 어떤 것인지, 성장하는 스타트업은 어떤 문화를 가지고 있는지.

어느새 6개월이 지났다. 기술적으로 성숙하기엔 충분하지 않은 시간이다. 하지만 그 동안 겪었던 일들, 가졌던 생각들을 간단하게 정리해보려고 한다. 새내기일 때의 시각과 감상은 ‘헌내기’의 그것보다는 미숙하고 무딜테지만 나름의 풋풋함과 신선한 시각들을 담고 있을 것이므로.

독자가 아무도 없다고 해도 사실 별 상관 없다. 이 글을 쓰면서 내가 얼마나 성장했는지 확인하고, 또 앞으로 나는 엔지니어로서 어떻게 살아가야 할 것인가를 차분히 고민해보게 될 것이다. 여느 때와 조금 다르게 글을 쓴다는 것이 가슴 설렌다.

By Eastsky Kang