20181108 SpringOne Tour - Seoul, By Pivotal

Table of Contents

한눈에 보는 정리

  • 코틀린을 이용해도 스프링 프레임워크는 잘 동작한다는 것

    • 코드도 간결하고

    • 맥북은 영어로만 코딩하면 빠르군. 한영 변환 비용은 꽤 비싸다.

  • 피보탈에서 '클라우드 네이티브(Cloud Native)' 에다가 '리액티브(Reactive)' 를 얹었고

  • 리액티브 작동은 개발자가 하나하나 구현하기보다는 플랫폼에 넘기고 스프링 프레임워크 기반의 개발경험을 살려서 리액티브 웹 프로그래밍하면 되고

  • spring cloud gateway 로 라우팅 구현하는 게 편해보였고(YML로 선언하는 것보다는 훨씬)

  • 다들 라이브코딩 앤 스피킹이 자연스러웠고

  • 쿠버네티스까지는 모르겠지만

    • 도커는 능숙하게 쓸 수 있어야 겠다.

  • 조쉬롱은 2년만에 봤는데 발표스타일이 많이 달라져서 유쾌해졌다.

  • 피보탈 클라우드 파운더리 서비스는 언제 이용해볼 수 있을까를 잠시 생각해봄

키노트

  • 노경훈 대표

Note

피보탈은 소프트웨어를 통해 세상을 변화시키려는 기업이다.

  • Pivotal: Transforming how to the world builds software

    • Process: Pivotal Labs

      • Culture(고객의 비즈니스 변화에 중점을 둔 지속적 학습), Process(Practice dispipline, rigor, open to critiquew)

    • Technology: Pivotal Cloud Foundry

      • Tools(Focus on developer productivity), Platform(Any workload, Every Cloud, One secure Platform)

Reactive Spring with Spring Boot(by Kotlin)

Note

자바챔피언이 코틀린으로 스프링 프로그래밍을 한다. 코틀린으로 간결하게 작성하는 모습이 인상깊었다. 코틀린으로 프로그래밍 언어를 전환해도 괜찮겠다는 생각을 하게 되었다. 이건 개인프로젝트로 한번 시도해봄직하다.

리액티브(Reactive)를 통해 성능을 높일 수 있을까?

  • 적은 커넥션으로도 일정한 성능을 유지하며 뛰어난 성능을 확보할 수 있다.

  • 리액티브 프로그래밍을 통해 동일한 스레드를 이용해서 보다 많은 처리를 할 수 있다.

    • 비동기 프로그래밍을 하게 되면,

      1. 콜백을 기반한 처리

      2. 콜백 지옥에 빠지게 된다.

      3. 코드 이해도 하락

      4. 생산성은 떨어진다.

    • 클라우드에 제어 권한을 넘기고 리액티브 프로그래밍을 통해 비즈니스 구현에 집중할 수 있다.

Reactive Stream

  • IT CROWD: 넷플릭스, 지하 전산실 사람들

Heckler가 추천하는 미드

  • Spring Project initializer: Reactive Web, MongoDB 사용

  • ReactiveCrudRepository

  • 코틀린에서는 method가 없고 function 단위 등록되기 때문에 func

  • 리액티브 프로그래밍에서 동작을 위해서는 마지막에 subscribe 를 사용해야 한다.

    • block() 대신 thenMany() 으로 처리

  • 독일사람이 만든 플러그인에서 flapdoodle 이라는 패키지명을 사용한 것이 독특함

@Service
class CoffeeService(private val repo: CoffeeRepo) {
    fun getAllCffees() = repo.findAll

    fun getCoffeeById(id: String) = repo.findById(id)

    fun getOrdersForCoffee(coffeeId: String) = refo.findByName(coffeeId)

    = Flux.interval(Duration.ofSeconds(1))
    .onBackpressureDrop()
    .map{CoffeeOrder(coffeeId, Instant.no())}
}

  • 웹플러스 테스트 @WebFluxTest(CoffeeService::class)

Mockito.`when`(repo.findAll()).thenReturn(Flux.just(coffee1, coffee2))

@Test
fun `Get all coffees`() {
    StepVerifier.create(service.getAllCoffees()) // 위에서 정의한
        .expectNext(coffee1)
        .expectNext(coffee2)
        .verifiyComplete()
}

  • 리액티브 기능을 테스트하려면 시간을 압축하는 것이 중요하다.

@Test
fun `Get`() {
    StepVerifier.withVirtualTime{service.getOrdersForCoffee(coffee2.id!!).take(10)}
        .thenAwait(Duration.ofHour(10))
        .expectNextCount(10)
        .verifyComplete()
}

  • 10초를 테스트 한번으로 압축하는 방법

  • 리액티브 프로그래밍된 코드를 테스트로 확인하는 과정이 중요하다.

Note

이와 관련해서는 지난 카카오2018에서 토비님이 발표한 내용을 살펴보면 좋겠다.

 
@RestController
@Requestmapping("/coffees")
class CoffeeController(private val service: CoffeeService) {
    @GetMapping
    fund all() = service.getAllCoffees()

    @GetMapping("/{id}")
    fun byId(@PathVariable id: String) = service.getCoffeeById(id)
}

  • httpie 좋아요~

    Note

    httpie는 localhost 생략가능하다.

    ex) http :8080/members

  • 리액티브 프로그래밍을 통해서 블로킹없는 기능을 구현했다.

정리

  • '코틀린을 서버사이드 프로그래밍언어로 사용할 수 있을까?' 라는 의문을 한번에 해소할 수 있었다. 자바를 이용했을 때보다 훨씬 간결한 코드를 보면서 내년에 코틀린을 이용한 프로젝트를 준비해보는 것도 좋을 듯 하다.

Cloud-Native Spring

  • 발표자: Josh Long

  • 클라우드 네이티브 자바 쓰는데 2년 걸렸다.

    • 책 표지에 어떤 동물을 넣을 것인지를 치열하게 논의했다.

    • 자바 섬에 사는 새 → 새는 구름속을 날아다닌다. // 열띤 논의를 했다고 한다.

  • http://www.reactivespring.io/

    • 적은 스레드를 가지고 I/O를 효율적으로 사용할 수 있는 패러다임: 리액티브 프로그래밍

@AllArgsConstructor
@NoArgsConstructor
@Data
class Reservation {} // 조쉬롱도 잘 쓰는 @Data... EqualsAndHashCode

  • 라이브 코딩을 통해 빠른 생산성을 보여주고 있다.

  • 인텔리제이를 바탕으로 빠르게 코드생산성은 높이자.

Note

인텔리제이에 왜!! Spring Boot Banner hide 기능이 생긴 것이냐. 분노하는 조쉬 롱. ** https://twitter.com/yanncebron/status/702216038344220672

Cb7FttiW0AAVBJQ 젯브레인 개발자 Yann이 Hide Banner를 비활성화해주겠다고 했던 게 2016년인데 아직도 반영되지 않고 있다. 이렇게!

chatty banner3

이렇게!

멋지지 않은가! 하고 열변을 토함

  • Spring cloud Gateway

    • RouteLocator

      • Spring Boot 2.0.6 사용해야함(2.1.0 버그가 있어서 동작안함)

      • Spring Boot 2.1.0 곧 패치예정

  • Spring Security

    • 하드코딩된 사용자명과 비밀번호를 쓰지 마라. @ROB_WINCH 가 슬퍼한다.

    • 스프링 시큐리티는 스프링 애플리케이션의 WebApplicationContext에 대해 필터링한다.

    • 리액티브웹에서 스프링 시큐리티 필터링을 이용하기 위해서는 ReactiveWebApplicationContext 와 스프링 시큐리티 필터를 연결해줘야 한다.

  • 요청 제어가 가능해짐

  • hedging: 먼저들어오는 것을 사용하겠다.

  • 게이트웨이 구축

  • http 프로토콜을 이용해서 웹 마이크로서비스만 구축하는 것은 아니다. 다양한 프로토콜을 이용할 수 있다.

    • link::https://grpc.io/[gRPC]: 고성능 RPC 프레임워크

    • rSocket: 리액티브 스트리밍을 지원하는 애플리케이션 프로토콜 *현재는 구현해야하는 코드가 많지만 스프링 5.2 에서 지원하면 손쉽게 사용할 수 있을 것이다.

Note

발표자들은 빠른 속도로 한치의 망설임도 없이 구현코드를 작성해갔다. 대다나다!!

Spring Cloud Gateway

  • 발표자: Younjin Jeong

  • Spring Boot를 소개하고 널리 사용되기까지 4년이 걸림

  • 그 다음으로 클라우드기반 개발할 때는 무엇으로 어떻게 할까를 고민할 때 Spring Cloud!

    • 원래는 spencer Gibb가 발표하는 주제다.

Note
스프링 부트 이후의 행보에 대해서는 쉽게 예측하기가 어렵다. @_@)

현재 우리나라에서는 AWS를 이용해서 각 회사에서 필요한 시스템 인프라를 구축하고 관리하는데 익숙해져 있는 탓에 PaaS 에 대한 관심이 그렇게 높지 않다. 인원이 적고 이제 서비스 개발을 막 시작한 스타트업에서는 고려해봄직하다.

한 곳에서 요청을 받아서 사용목적에 따라서 할당(라우팅)해주는 역할을 해준다.

  • What is an API Gateway

    Use API Gateway

  • Reverse Proxy(Nginx)

  • 다양한 분산기법을 사용하고픈 욕구를 충족시켜주는 것이 필요했다.

  • 요구사항

    • Routing

    • Canary-ing(A/B 테스트)

    • Security

    • Monolith Strangling: 모놀리스 분할

    • Monitoring

    • Resiliency(탄력성)

  • SasS

  • Web Server(Proxy)

  • 'Service Mesh'

    • 참고

    • 애플리케이션이 동작하는 모든 서버에 프록시가 존재하며 서비스 디스커버리를 통해서 존재 확인

      • 각각의 컨테이너 안에 로드밸런서가 포함되어 프록시 역할 수행하는지

  • Spring Cloud Gateway(or Netflix Zuul)

  • Project Reactor(Netty 기본내장)

  • 게이트 쪽에서 서버자원을 장시간 점유하게 되는 경우에는 리액티브 프로그래밍이 좋다.

  • Inside the Gateway

  • Ribbon(Ratency 기준 분산가능)

  • Route Configuration 개념 변화: YAML → Java

    • 라우팅할 경로를 지정하는 목적이라면 YAML로 작성하는 것보다 Java 로 구현하는 게 간결해보이기는 한다.

  • wscat: 웹소켓 서버와 클라이언트 사이에서 echo를 날린다

  • Chaos monkey for Spring Boot

    sb chaos monkey architecture

Note

스프링 부트를 위한 카오스 몽키도 있었다(참고: 스프링 부트와 카오스 몽키)

카오스 엔지니어링은 일반적으로 서비스를 테스트 목적으로 일부러 망가트려보고 이에 대한 시스템의 반응을 바탕으로 더 견고한 서비스를 만들기 위한 엔지니어링을 말한다.

Remember

  • Spring Boot

  • Spring Security

  • Micrometer Support

  • Zipkin Support: Distributed tracing system

Cloud Event Driven Architectures with Spring Cloud Stream 2.0

  • 이벤트소싱을 했을 때 얻게되는 이득은 뭐가 있을까나?

// CreditCard
// DomainEvent implements Event
public void assignLimit(BigDecimal amount) { // command: green note
    if(limitWasAreadyAssigned()) { // invriant - yellow notes
        throw new IllegalArgumentException(); // NACK
    }
    //ACK
    //this.limit = amount;    // 이벤트가 반영되지 않을 수 있다.
    limitAssigned(new LimitAssigned());
}

이벤트가 발생하면 그 결과를 찾아내야 한다. * 신용카드 정보를 저장하기 위해서 필요하다.

  • 신용카드 상태가 변경될 때마다 신용카드 기존 정보가 사라진다.

    • 변경될 때마다 그 정보를 저장한다.

    • 저장정보를 이용해서 필요한 상황이 되었을 때 복구할 수 있다.

    • 도메인 이벤트 이력 저장소(DomainEvent history storage)

    • 상태가 변경되면서 발생하는 모든 값을 파라미터로 전달

  • 이벤트를 스트림에 저장하고 나면 이벤트는 소거(clear)해도 된다.

  • 신용카드 정보가 아닌 이벤트를 저장하는 이유

  • 왜 이벤트소싱을 할까?

    • 도메인에 대한 감사(Auditing) 가능해진다.

    • 문제가 발생했을 때 과거 시점으로 도메인 상태를 복구가능하다.

    • 특정 이벤트에 대한 모니터링을 하는 등 다양한 컴포넌트에서 비교 가능

      • ex) 비슷한 시간에 결제된 항목의 장소를 확인하는 것도 가능하다.

    • 카드결제내역을 비교할 수 있다.

    • 단점

      • 잘못된 이벤트에 대한 처리: Output lug?

      • 작성해야하는 코드가 증가

      • 사고 전환이 필요하다.

  • 절차지향적인 도메인인 경우

    • 누락된 절차를 찾기 힘들다.

  • 메시지소싱(MessageSourcing)

    • Spring Integration

    • input-output 채널에만 집중하면 된다.

  • dependency spring-clout-stream, spring-cloud-stream-bidner-rabbit(MessageQueue)

  • MediaType.APPLICATION_STREAM

  • 예제: http://github.com/pilloPI/credit-cards-producer

Spring, Functions, Serverless and You

  • 발표자: Nate Schutta

  • serverless 는 불가능하다. 어딘가에서는 서버가 있다.

  • 상을 뒤엎을 정도로 화가 났다. Table flap.

  • 기존에 가지고 있던 지식들을 활용할 수 있으니 코드를 삭제하지 마라.

  • 과거 하드웨어 중심시대

    • 인프라를 구축하기 위해 해야할 일들이 많았다.

  • 현재 소프트웨어 중심시대

    • 자신의 고양이를 키우듯

    • 부작용: 공유된 자원(Shared resource): 격리되지 않은 자원때문에 작은 변화가 주변에 영향을 끼친다.

  • (개발)환경을 동일하게 구성하는 것이 어렵다.

    • 과거에는 패치 순서가 다른 경우 다르게 동작할 수 있었다.

      • 복잡하게 이름을 지었다.

  • 서버는 더이상 제약 자원이 아니다.

  • 다양한 클라우드 프로바이더가 생겨났고 서버의 교체가 용이해졌다.

    • ex) 가축에게는 이름을 부여하지 않는다. 숫자를 준다…​. 슬프다.

  • 스크립트를 통해서 실행되는 것을 동일하게 보장할 수 있게 되었다.

  • 서버를 올리는 시간이 단축되었다.

  • IaaS - provision server resources(on premisure)

  • Sometimes on demand self service

  • 큰 힘에는 그에 따른 책임이 따른다.

  • Container != Docker

    • Docker is box!

  • 가상화를 하는 영역이 달라졌다(하드웨어 → 소프트웨어)

    • 도커에게 모든 행위를 알려줘야 한다.

    • docker hub는 커뮤니티 중심이지만 검증된 것은 아니다.

Note

기업마다 애플리케이션 수 만큼 도커 이미지가 존재한다.

도커를 사용하면 그 이미지에 대한 책임을 져야 한다.

  • 패치를 통해 보안업데이트는 수시로 해야한다.

  • meltdown & spectre

  • Kubernetes 개념을 설명

    • 다양한 선택사항이 존재한다.

    • 단순하지 않다.

  • Serverless

    DThZ1jSWsAEgxko

    • IaaS

      • Container

      • Platform

      • Servleress

        • 함수 실행

        • 함수 확장

        • 이벤트 스트리밍 바인드

  • 자신에게 맞는 것을 선택하라.

  • PaaS를 사용하면 인프라 스트럭처를 사용하는 것은 크게 신경쓰지 않아도 된다.

    • 기업의 가치를 어디에 중점을 둘지 고민

  • 다양한 곳에서 사용할 수 있다.

  • 서버리스 환경에서 중요한 건 언어가 아니라 UseCase다!

  • https://projectriff.io/

  • KNATIVE

  • 나에게 어울리는 것은 무엇인가?

Spring Boot & Spring Cloud on Pivotal Application Service(PAS)

  • Younjin Jeong

  • Build once, Run everywhere.

  • 레거피 웹애플리케이션을 컨테이너에 담아서 그대로 배포하는 것은 적절하지 않다.

  • 운영의 영역을 구분지어서 쓰는 일이 있을까? @_@)?

  • 클라우드 게이트웨이, 유레카 등이 소스코드에 반영되어야 하는데 개발자가 그걸 몰라도 될까??

  • full cycle developers - netflix

    1* nN4aj7uohV4v8bnqJCw3g

  • 높은 유연성 → 표준이 복작해진다.

  • 개발자 친화적, 인프라 친화적

  • Spring Cloud Pipeline

  • Container to Container Networking

  • Spring Boot를 이용하면 Factor 12 요소를 쉽게 충족할 수 있다.

Using Spinnaker to Create a Development Workflow on Kubernetes

  • Paul Czarkowski

  • kubectl

  • PKS

    • kubectl 을 통해서 실행

  • kubernetes 101

  • POD

    • 하나 이상의 애플리케이션 컨테이너가 있으며 자원을 공유하며 긴밀하게 연결되어 있다.

  • ReplicaSet

    • 몇 개의 POD을 운영할 지 정의

  • Deployment

    • ReplcaSet 을 정의하고 업데이트 그리고 업그레이드를 정의

  • Statefulset

    • statue fulll application 배포관리

  • Halm

  • spinnaker

    • spinnaker + kubernetes + PCS 를 이용하면 손쉽게 배포 가능

Summary

  • 조쉬롱 캐릭터가 바뀌었다. 예전에는 그렇게 활발한 캐릭터가 아니었는데…​

  • SpringOne Tour 발표트렌드는 라이브코딩이 되었다. 발표장표와 코드를 적절하게 배치하여 개발자들에게 실제로 코드를 보여주고 실제로 동작하는 모습을 보여주면서 흥미와 신뢰를 유발하는 듯 하다.

  • 지난 6월에 있었던 Cloud Native Day in Seoul 보다 훨씬 더 나아졌다.

  • AWSomeday 의 뒤를 이어 SpringOne Tour 도 정기적인 행사로 자리잡게 될까?

  • 나는 아직 스프링 부트를 기반한 애플리케이션 개발 및 운영수준에 머물러 있다. 여기서 이야기하는 API 게이트웨이, 유레카, 서비스 브로커 등의 기능을 이용하기에는 아직 멀고먼 이야기로군.

view raw 20181108_springone_2018_tour.adoc hosted with ❤ by GitHub


저작자표시

'logbook' 카테고리의 다른 글

[log] 클라우드네이티브자바 저자(Josh Long)와 역자(정윤진, 오명운) 사인회  (0) 2018.11.08
[독후감] 클라우드 네이티브 자바  (2) 2018.08.09
[로그] 어느 봄날의 구직활동:: 졸지에 백수였다가 이제 예비 월급쟁이개발자  (6) 2018.04.09
[daily] Spring Camp 로고 초안  (0) 2018.02.22
[diary] 개발장비 업그레이드  (0) 2018.02.01


저작자표시

'logbook' 카테고리의 다른 글

[log] 20181108 SpringOne 2018 tour - Seoul, By Pivotal  (0) 2018.11.09
[독후감] 클라우드 네이티브 자바  (2) 2018.08.09
[로그] 어느 봄날의 구직활동:: 졸지에 백수였다가 이제 예비 월급쟁이개발자  (6) 2018.04.09
[daily] Spring Camp 로고 초안  (0) 2018.02.22
[diary] 개발장비 업그레이드  (0) 2018.02.01


800페이지에 가까운 책을 한번 훑어봤다.
말그대로 훑어봤다. @_@

클라우드 파운드리(Cloud Foundry, CF)나 쿠버네티스 정도가 아니면  "클라우드 네이티브 애플리케이션" 개발은 어렵다는 성철님의 의견에 동의하게 된다.

이제 스터디 일정에 맞춰 예제 작성해보며 직접 부대껴보는 시간을 가져야겠다.

클라우드 네이티브 애플리케이션을 만들어보자꾸나.
저작자표시

'logbook' 카테고리의 다른 글

[log] 20181108 SpringOne 2018 tour - Seoul, By Pivotal  (0) 2018.11.09
[log] 클라우드네이티브자바 저자(Josh Long)와 역자(정윤진, 오명운) 사인회  (0) 2018.11.08
[로그] 어느 봄날의 구직활동:: 졸지에 백수였다가 이제 예비 월급쟁이개발자  (6) 2018.04.09
[daily] Spring Camp 로고 초안  (0) 2018.02.22
[diary] 개발장비 업그레이드  (0) 2018.02.01

[record] 봄날의 구직활동

Warning

각 회사의 면접 중에 받은 문제나 질문에 대해서는 상세히 기술하지 않는다. 각 사내 (보안) 규정을 위반할 가능성이 있다…​. 자세히 알려주지 못해서 미안하다.

시작

설날 직전, 난 백수(White hands)가 되었다.

지.인.의 추천으로 이전 회사에서 하던 서비스(업무)를 직접 기획하고 설계하고 구현하고 운영하는 개발팀장(다른 이들은 CTO라고 불렀지만 나는 개발팀장 정도로 생각)을 한달반 정도 하다가 입사한 기업의 대표와 투자자 사이의 의견차이로 투자 자금 확보에 실패하면서 조기에 [red]#폐업#했다. 한마디로 망.했.다.

Note

그나마 다행이었던 것은 개발자 2명에 대한 최종면접 직전에 폐업소식을 들었다는 것이다. 백수를 두 명이나 더 양산할뻔 했으니…​ 다행이라고 생각한다. 그 전까지 사업투자금 확보에 대한 불안함이 있었는데, 소액해외송금업 인허가 신청을 위해서 전산인력을 3명 확보해야하는 상황이라 대표에게 이에 대해 압력을 줬더니 더이상 미루지 못하고 폐업선언을 했다.

사업투자금 확보를 위해 투자자들과 이런저런 의견충돌 및 갈등이 있었던 듯 하다.

나름 욕심을 품고 6월초까지 서비스를 오픈하고 성과가 있으면 그 때 교섭을 다시 해보려는 야심을 펼치기도 전에 접어야 했다.

진행

그 후 한동안 심적안정을 위한 휴식(방콕…​)을 하고있던 내게 Y사에서 근무하시는 분의 연락이 왔다. 회기역 커피점에서 만나 서로의 안부를 물으며 Y사 지원을 제의받았다. 사실 이전에도 입사제의를 받았지만 아무 준비없이 코딜리티 코딩테스트를 봤다가 탈락했다.

Note

어느 기업이든 '사내추천' 시스템이 있다. 추천인을 통해서 회사사정을 공유받고 지원하는 경우이기 때문에 헤드헌터를 통한 지원보다 훨씬 신뢰할만하고 비용적인 측면에서도 저렴하기에 기업에서는 이 쪽을 선호할 것이라 생각한다(헤드헌터 소개인 경우 수수료 부분에 대해서 어떨지도 생각해봐야겠다. 나는 지금까지 헤드헌터를 통해 입사한 경험은 없다. 지난 회사를 나가기 전에 가까운 곳에 IT HR기업이 있었고 회사 이사님이 "회사를 나갈거면 나가겠다는 행동을 보여라. 저 회사에 가서 등록해라."라고 해서 가서 등록을 하긴 했지만 초기 상담을 받는 과정에서 나랑은 맞지 않는 느낌을 받아 크게 신경쓰지 않았다).

지인을 통해 추천받을 때는 지원회사에 대해 정보를 사전수집하는 것이 중요하다.

Y사 입사지원을 준비하고 있던 중에 C사에서 근무하는 형이 입사지원을 제의했다. 지난 2월에 그 팀에서 스프링 부트를 간단하게 소개(https://goo.gl/RTtZ2q)한 적이 있는데 팀에 필요했던 기술요건이 추후 계획과 부합되는 부분이 있었기에 추천도 잘 진행되었다.

Note

이 때 내가 안티팡(Antipang)임을 드러냈다. @_@)> ㅎㅎ…​. 이미 오래전 일이니 다들 웃어넘기며 크게 신경쓰지 않았다.

이 글을 적은 당시에 많은 사람들이 방문했고 나와 비슷한 감정을 느낀 이들의 공감을 얻을 수 있었다. 이 때와는 전혀 다른 분위기를 느낄 수 있다.

C사에 제출하기 위한 이력서를 생성했다. 이력서는 최대한 간단하게 작성하고 있으며 첫 장에 내 개인적인 이력을 확인할 수 있는 내용을 최대한 기재한다.

Tip

이력서를 작성하는 방법에 대해서는,

의 내용을 살펴보기 바란다.

내가 작성한 이력서는 홈페이지를 통해서 김지헌 Java Back-End Developer으로 공개하고 있다.
Note

C사는 팀에 따라서(외국인 매니저 여부?) 영문이력서를 작성해야 한다. 나는 기존 이력서를 크게 훼손하지 않는 선에서 구글번역(…​)을 이용하면서 작성하여 제출했다.

C사의 채용절차는 느긋한 편이다. 채용절차가 진행되는 속도는 팀에 따라 조금씩 다르다. C사 채용절차를 기다리고 있는 사이에 Y사 추천인(잠시 깜빡하고 있었던)을 통해 뒤늦게 채용절차가 진행되었다. Y사 채용사이트에 개인정보 및 이력을 등록했다. 2일 후에 메일을 통해 Y사 코딜리티 코딩테스트 링크가 전달되었다.

이 사이에 W사에 근무하는 지인과 삼겹살을 먹다가 다시 입사제의를 받았다. 지난해 입사제의하면서 추천서 써주겠다고 해서 기다리고 있다가 깜빡하면서 잊혀졌던…​ 일정이 진행되었다. W사 채용사이트에 개인정보 및 이력을 등록했다. 그 후 W사 코딜리티 코딩테스트 링크가 전달되었다.

Y사와 W사 코딩테스트는 일요일에 몰아보기로 하고 코딜리티 코딩시스템을 익히는데 중점을 두었다.

Note

  • 코딜리티 코딩테스트에서 문제를 푸는 특별한 제약은 없다.

    • 당연히 혼자 힘으로 스스로 풀어야 한다.

  • IDE(Eclipse, IntelliJ)에서 작성한 후 코드를 복사하고 붙여넣기도 가능하다.

    • 이건 코딩테스트에 대한 제약사항을 확인한다.

  • 코딜리티 테스트에 대해서는 인터넷 검색을 해보면 설명하는 글이 많으니 설명은 생략한다.

  • 보통 3~4문제를 각 문제별 풀이제한시간 안에 제출하면 된다.

그 사이 C사 전화면접을 진행했다. 제출한 이력서를 기준으로 경력에 대해 이야기하고 그 경력에서 사용한 기술에 대한 내용과 프로그래밍과 관련된 질의응답시간을 1시간 정도 가졌다. 면접자와 면접관 서로가 기분상하지 않게 조심조심스럽게 진행됐다.

코딜리티 코딩테스트는 일요일 오전 커피한잔을 마시고 치뤘다. 오전과 오후로 나눠 시험을 치뤘다.

Note

각 시험마다 4문제 중 1문제씩 못풀거나 빼먹거나…​

3/4 는 맞춰야 코딩테스트 통과라고 생각하면 되겠다.
Warning

문제를 알려달라는 요청은 거절한다.

문제가 영어라는 정도는 알려줄 수 있다! 파폭이나 크롬에서 구글번역기 애드온을 추가하여 문제를 번역할 수 있다. 전체 페이지를 번역하는 것이 아니라 페이지 중 일부를 선택하여 번역하면 문제를 이해하는데 어려움은 없다.

채용절차를 진행하는데 기본적 역량을 갖췄는지 확인하는 '전화면접’과 '온라인 코딩테스트' 후 1차면접을 진행했다.

Note

순서는 Y사, C사, W사 순으로 진행되었다.

C사이나 W사 경우에는 조금 느긋한 일정으로 진행되어 나도 그러려니 하고 느긋하게 준비했다.

이메일로 가능한 면접일을 안내하고 그 중에 자신이 가능한 날짜를 선택하여 회신하면 된다.

Y사 면접일에는 출판준비중인 '부트 스프링 부트' 교정본을 전달할 일이 있었다. 거기서 개발자들 사이에서 유명한 페북댓글봇 황후순님을 뵙고 함께 Y사로 이동했다.

1층에는 Y사에서 운영하는 카페가 있다. 그 곳 한켠에는 회의 및 면접을 진행하는 방들이 있다. 1층에서 추천인과 그 분과 함께 일하는 지인이 내려와 간단하게 인사를 하고 면접에 대한 이런저런 이야기를 들을 수 있었다.

Tip

면접에 필요한 정보는 최대한 많이 획득해두는 것이 좋다. 준비된 것과 그렇지 않은 것의 차이는 크다.

인재채용담당자가 내려와 면접실로 나를 안내했다. 면접실에는 CTO를 포함한 4명의 면접관이 기다리고 있었다. 이력서를 기준으로 경력을 확인하고 코딜리티 코딩테스트에 대한 이야기를 나눴다.

Note

시간에 좇겨 풀어낸 코드라 복기하자니 부끄러운 것들이 많았다. 그런 코드에 대해서 '이렇게 작성했으면 어땠을까요? 이러면 더 좋지 않겠어요?' 라는 질문에 대해서 어떻게 대응할지 준비를 못했다.

"시간에 좇겨 작성하다보니 그렇게 되었다."

라고 자기변명을 할 뿐.

한켠으로는, 면접관들은 언제나 좋은 코드와 해결법을 제시할 수 있다는 점을 간과한 것도 있다. 그들은 나와 달리 느긋하게 코드를 살펴보고 풀어볼 수 있었다고 생각한다. '입장 차이가 있었다’고 부끄러운 자기 변명을 해본다.

자기변명을 하는 순간부터 위축되어버렸다. 질문에 대해서 제대로 대응하지 못했다. 면접을 마치고 나온 후 다음날 탈락안내메일이 도착했다. 이 때가 03/16이었다.

Note

Y사 추천인을 통해서 조금 더 자신감 있게 자신을 이야기 하라는 피드백을 받았다.

면접이란게 결국은 '나를 채용해라. 이 회사에 필요한 사람이다.'라고 면접관을 설득시키기 위한 자리다. 이에 중점을 두고 자신의 이력을 작성하고 설명해야 한다. Y사 면접에서는 자신감 있게 대응하는 것이 당락을 결정하는 중요 요인이 아닐까 싶다.

Y사 코딜리티 코딩테스트에서 답안제출 후에는 그 코드에서 나올 수 있는 질문이나 개선점에 대한 답변을 준비해두자.

코딜리티 제출코드를 가지고 역량을 확인하기는 쉽지 않다. 이를 보완할 수 있는 것 중에 하나가 온라인 활동을 많이 하는 것이다. 나는 '허니몬’이라는 이름으로 블로그 및 커뮤니티 활동을 해왔다. 그리고 내가 작성한 코드에 대해서 살펴볼 수 있도록 사이트와 깃헙을 공개했다.

Note

깃헙을 활용하는 방법에 대한 보다 자세한 내용은 깃허브(GitHub)로 취업하기 - Sujin Lee를 읽어보기 바란다.

Y사 면접에서 미흡하고 아쉬웠던 점들을 정리했다.

내용정리02

다음 면접은 C사. 잠실에 위치한 C사 17층에서 면접이 진행된다. C사은 면접을 진행하기 위한 별도의 공간이 마련되어 있다. 1층 로비에서 본인의 이름을 말하면 임시출입카드를 받고 17층으로 이동하여 데스크에 이야기하면 면접자를 위해 예약된 미팅룸을 안내받을 수 있다. 그 공간에서 오전 10시부터 오후 4시 30분까지 면접이 진행되었다.

두 번의 비디오콜(해외에 있는 매니저와 관리자)과 C사 개발자들과 두 번의 대면 면접이 있었다. 면접 사이 점심때는 추천인과 점심을 먹고 이런저런 이야기를 했다.

면접을 진행하는 동안 분위기는 부드러웠다. 면접을 진행하는 과정에서 평가기록을 위해 타이핑을 해야하는 점에 대한 양해를 구하기도 했고 서로 조심스러웠다. 면접 후 금요일 면접관들의 협의를 통해 합격통보를 받았다. 그 후 C사 채용팀에서 연락이 왔고 처우협의를 위한 증빙서류를 제출했다.

Note

실제 경력을 확인하는 용도로 건강보험 득실 혹은 국민연금 가입증명 서류 및 전직장에서 받은 연봉을 확인하기 위한 용도로 연봉계약서 혹은 원천징수영수증을 요청한다.

다음 면접은 W사. 2층에서 안내를 받아 17층으로 이동하여 3명의 면접관을 대면했다. 이력서에 기재된 경력과 기술에 대한 질의응답이 있었다.

Tip

모르는 것은 모른다고 빠르게 대답하고 다음 질문으로 넘어갔다. 면접을 마치면 생각나는 경우도 많은데, 굳이 시간을 끌며 떠올리려고 하다가 리듬을 깨는 것보다는 모르는 것은 모른다고 하고 다음 질문으로 넘어가자.

이왕이면 사전에 준비를 해두는 것이 좋다.

내용정리01
Note

W사에는 지인들을 귀찮게해서 이런저런 이야기를 많이 들을 수 있었다. 그 배경지식을 기반으로 면접을 진행했다. 경력이 쌓이고 사람들 앞에서 발표를 했어도 면접은 긴장된다. 그래도 조금은 느긋하게 생각을 정리하고 전달할 수 있도록 노력했다.

W사 1차면접을 마친 후 얼마되지 않아 C사에서 연봉을 제시했다.

Tip

지금 다른 곳도 면접을 진행중이라는 이야기를 하면서 슬쩍 튕겼다. 이 밀당은 사전정보와 기술이 필요하다. 지인찬스를 사용하여 자신이 적절하다고 생각하는 연봉을 요구하며 조정해간다.

W사 1차면접을 통과후 추가적인 자기소개하는 글을 작성하여 제출했다.

Note

  1. 자기소개글을 쓰는데 2일을 소비했다. 글쓰기란 어렵고 어렵다…​.

그리고 03/30 W사 최종면접을 진행했다. 조금 일찍 도착해서 W사에게 근무하고 있는 후임에게 점심을 얻어먹고(!!) 커피를 마시러 간 곳에서 아는 분들을 만나 급히 자리를 정리하고 일어났다. W사 옆에 있는 카페에서 제출한 이력서와 자기소개를 훑어보면서 면접을 준비했다.

Tip

위 내용을 보고 질문에 대한 나만의 답변을 준비해봤다.

사전에 나올법한 질문과 그에 대한 답변을 정리해보면 답변하는데 큰 도움이 된다.

면접실에서 2명의 최종보스와 면접을 진행했다. 이 때는 입사가능한 곳이 있다는 안도감을 가지고 아주~ 느긋하게 대응했다. 약간은 과한 것 같다 싶을 정도로…​

나는 2년 전에 W사 시니어 개발자로 추천받은 적이 있다. 그 때의 나는 시니어(Senior) 개발자가 아니었고 제대로 입사 준비도 하지 않은 상태여서 당연하게도 떨어졌다. 너무 쉽게 생각했었다. 사실 시니어로 입사제의 받았다는 것도 몰랐다. ^^;

'최종면접에서 2년 전 이야기를 하며 지금의 내가 그 당시로 돌아간다면 붙을 수 있을까?' 라는 질문을 받았다.

나는 지금도 시니어 개발자가 아니라고 생각한다. 이 '시니어 개발자’라는 기준은 상대적이다. 당시 요구되었던 '시니어 개발자’는 '주니어 개발자’들을 교육하고 이끌면서 프로젝트를 관리할 수 있는 능력을 가졌느냐 정도였다고 생각한다. 어디까지나 내 생각이지만…​

Warning

최종면접을 진행한 후에 내 개인적인 생각으로는 탈락하지 않았을까 생각을 했는데 내 예측과는 다르게 통과했다. 허얼?

결과

  • Y사: 탈락

  • C사: 합격

  • W사: 합격

정리

Important

W사 2018/04/16 입사확정
Note

최대한 많은 회사를 지원하고 가고 싶은 우선순위를 정해 꼭 가고 싶은 곳은 후순위로 배치하여 많은 면접을 보면서 기록으로 남기며 만반의 준비를 갖추길 바란다.
Important

제일 중요한 것은 [red]#회사를 다니면서 구직활동을 하는 것#이다.

나(!!)처럼 섣부르게 회사를 뛰쳐나와서 진행하는 구직활동은 시간이 지날수록(통장잔고가 줄어들고 바닥을 보이면) 조급해질 수 있다. 그로 인해 최선을 다하지 못하고 가고 싶은 곳에서 탈락하면 얼마나 마음이 아프겠는가? 떨어진 회사도 몇 개월 뒤에 [red]#재응시#할 수 있다.

그러니 가급적이면 회사를 다니면서 구직활동을 하자.

입사지원과정과 확인해야할 점들을 정리해보면 다음과 같다:

  1. 지원가능한 최대한 많은 회사 지원

    • 가고 싶은 회사는 우선순위를 정해서 [red]#가고 싶은 곳일수록 마지막#에 둔다.

      • 지원한 회사에 대한 정보를 사전에 수집한다.

        Note

        • 지원회사 분위기(투자확보, 안정성, 근무자들의 만족도, 추후 사업계획 등)

        • 지원회사 채용절차 확인

        탈락되었을 때 피드백을 주는 곳이 있고 그렇지 않은 곳이 있는데 어떻게든 피드백을 확보하여 다음 면접에서 피드백 받은 내용을 개선해야 한다.

    • 이력서에 기재한 이력을 상기하고 사용기술에 대해 정리한다.

  2. 코딩테스트 준비

    • 코딜리티(codility.com)

      • 코딜리티 레슨을 풀어본다.

    • 자신이 주력으로 사용하는 언어에서 제공하는 API 익히기

      • loop, array, casting, condition, swtich-case 문법 수련

      • Java: Integer, String, int[], String[], List 등의 기본 API 사용법 수련

  3. 기술면접 대비

    • 손코딩

      • 화이트보드에 적어보기

      • 적으면서 입으로 설명하기

    • 질의응답노트 정리

      • 이력서에 기재한 프로젝트에서 사용한 기술 중심

      • 프로젝트에 대한 경험

      • 프로젝트에서 수행한 업무

  4. 임원(혹은 최종)면접

    • 업무에 대한 태도를 살펴볼 수 있는 질문을 많이 함

    • 회사에 대한 질문 준비

  5. 연봉협상(이 부분은 후회하지 않도록 잘 해야겠다 싶다. 내가 제일 취약한 부분임)

    • 연봉

    • 스톡옵션

      • 보통은 입사후 일정기간이 지난 후에 행사할 수 있는 경우와 해마다 일정비율로 행사할 수 있는 경우가 있음

      • 개인적으로 스톡옵션보다는 연봉을 더 주는 게 좋다. 장기근속자는 회사의 성장가능성을 보고 스톡옵션을 받는 것도 괜찮겠다.

  6. 입사

    • 자신의 회사선택 기준

    • 같이 일할 동료 및 팀에 대한 이해

    • 연봉

    • 입사 후 빠르게 적응하기 위한 자신만의 노하우

Y사, C사와 W사 모두 올해도 대대적인 인력충원을 계획하고 있다.

이직을 희망하는 개발자들에게 많은 기회가 열려있다. 잘 준비해서 좋은 결과 얻기 바란다.

구직전략을 잘 세워서 각 기업에 맞춰 잘 준비하기 바란다.

P.S. 입사확정 후 조금 더!

입사가 확정된 후, W사 TechHR팀에서 내가 지원했던 팀이 아닌 다른 팀에 합류하는 것이 어떻겠냐는 제안을 했다. 이때 잠시 고민을 했다. 지원했던 팀에는 초창기에 함께 일했던 지인이 있었고 그 지인과 함께 서비스를 만들어갈 수 있을거라는 기대를 안고 지원했었는데, 정작 회사에서 내 지원의사와는 다른 팀을 제안했기 때문이다.

이 제안을 받았을 때 C사와 W사 사이에 선택에 대한 고민을 하게 됐다. 같이 일하지 못한다면 굳이 W사를 들어갈 이유가 없다는 생각도 가지고 있었다.

그러다가 문득, 얼마 전 나에게 소갈비살을 얻어먹으셨던, 멘토링 전문가가 떠올라 연락을 드렸다. 그 분을 통해서 배치받은 팀의 팀장이 누구인지 알게되어 페북메신저를 통해 연락을 드렸다. 예전에 토비의 스프링 책읽기 스터디를 함께 했던 분이었다. 다음날 회사로 찾아가 커피를 마시며 업무에 대한 이야기와 내 선택을 확정지을만한 이야기를 듣고 마음의 결심을 내렸다.

Note

입사가 확정된 후에는 본인이 일하게될 부서나 업무를 알 수 있게 된다면 그와 관련된 이를 만나서 이야기를 나누는 것도 중요하다. 본인이 합류해서 어떤 역할과 업무를 수행해야할지 파악하면서 자신의 성향이나 목표하는 바와 일치하는지 확인하는 과정이 필요하다.

이런 호기를 부릴 수 있는 것은 다른 선택지도 가지고 있었기 때문이다. 후회를 남기지 않도록 입사에 최선을 다하였다

입사를 확정하고 C사의 지인에게 연락하여 결정사항을 전했다.

그리고 나는 2018/04/10 ~ 2018/04/16 까지 세부에서 다아빙을 하고 2018/04/16 아침에 귀국하여 출근할 예정이다.

view raw 2018-04-09-findjob-of-march.asc hosted with ❤ by GitHub
저작자표시

'logbook' 카테고리의 다른 글

[log] 클라우드네이티브자바 저자(Josh Long)와 역자(정윤진, 오명운) 사인회  (0) 2018.11.08
[독후감] 클라우드 네이티브 자바  (2) 2018.08.09
[daily] Spring Camp 로고 초안  (0) 2018.02.22
[diary] 개발장비 업그레이드  (0) 2018.02.01
[소개] 협업도구 Microsoft Team Services  (0) 2017.11.08
책상정리를 하다가 나온 초안들.


여기서 훨씬 이뻐졌다.
저작자표시

'logbook' 카테고리의 다른 글

[독후감] 클라우드 네이티브 자바  (2) 2018.08.09
[로그] 어느 봄날의 구직활동:: 졸지에 백수였다가 이제 예비 월급쟁이개발자  (6) 2018.04.09
[diary] 개발장비 업그레이드  (0) 2018.02.01
[소개] 협업도구 Microsoft Team Services  (0) 2017.11.08
[월급쟁이개발자] 인수인계  (0) 2017.11.05

+ Recent posts

티스토리툴바