퇴사하는 친구와의 Farewell

Posted by on

센트럴 친구랑 업무 이외로 콜을 하는건 참 드문 일인데, 퇴사라는 이유는 더욱 낯선 것 같다.

떠나는 친구는 업무적으로 인연이 좀 있는 친구다. 회사의 고난과 역경의 시기가 2016년에 찐하게 있었다. 정말 미국 본사와 다방면에서 찐하게 불편하게 지내는 시절이었다. 그 시기의 한복판에서 한국팀과 미국팀의 일원으로 태평양을 사이에 두고 심각하게 불편한 사이였으니까. 미국팀 친구들한테 너네가 와서 좀 느껴봐라 이야기를 했더니, 정말 왔다!!! 일주일 남짓 사이에 많은 이야기를 나눴고, 소주도 많이 먹었다. 이메일과 Conference call로만 떠들던 서로의 차이에 대해 완전한 이해는 아니지만 적어도 차이가 있다는 걸 알게는 됐다. 그리고 문화와 환경의 차이를 본인들이 단기간에 메꿀 수 없다는 것도 알았다. 차이를 인정하고, 서로가 어떻게 Player Focus를 해야할 지 방향을 잡은 다음부터는 일이 착착 진행되었다. 이전과 같은 충돌도 더 이상은 없어졌다. 한국팀이 하고자 하는 방향과 미국팀의 방향 사이에 절충점을 찾았고 서로 합을 맞춰가면서 썩 훌륭한 소위 콜라보를 했던 것 같다.

그 미국팀의 실질적인 개발자였다.

이후 미국 출장때면 항상 자리에 찾아가 얼굴도 보고, 지나가다가도 반갑게 인사를 했던 것 같다. 이 친구는 꾸준히 업무를 담당했고, 한국팀이 “도와줘~” 라고 이야기하면 어김없이 등장했다. 그치… 이러면 정말 친구라고 이야기할 수 있지. 그러고 보면 정말 친구였구나… ㅋ

인수인계하면서 솔직히 제일 컨텍스트를 잘 아는 너가 없어져서 솔직히 걱정된다고 우려를 전했다. 하는 만큼, 아는 만큼 끄집어내서 다음을 책임질 친구에게 넘겨준다고 했다. 이 친구도 이야기를 했지만 머리속에 있는거랑 마음속에 있는 거랑은 분명 다르다. 심정적으로 이해하던 친구가 아닌 머리로 이해하는 다른 친구와 앞으로 일을 해야하는구나 생각하니 머리가 아프다. 아무래도 그쪽 일을 담당하는 친구는 골치 좀 썩겠구나 싶다.

젊은 친구다. 이제 30대 초반이다. 좋은 시점이고 Microsoft로부터 투자까지 받은 회사라고 한다. 새로운 시도를 하는 친구들이 항상 부러운 시절이다. 더구나 기존에 하던 분야와 다른 분야라니.

잘 해보라고 이야기했다. 잘 성장하고 자기 개발/발전 잘 해서 이 시절이 지나면 한번 얼굴 보자구 이야기를 했다. LA가 아니라 시애틀로 간다는게 함정이긴 하지만. 뭐 언제 시애틀 갈 기회가 있지 않을까? 되면 연락해서 얼굴보면 되겠지.ㅎㅎ

그나저나 내가 그 시점까지 과연 버틸지가 의문이네~~~?

콜 마지막에 그 친구가 끊기전에 한 말이다. 좋았다.

Bye bye, my friends~

Spring-boot 2 이제 JUnit5 지원한다.

Posted by on

정확하게 이야기하면 Spring-boot 2.2 버전부터.

이전에 JUnit5를 Spring-boot 2.x 버전에서 사용할 수 있다고 글에서 봐서 써볼려고 했다. 하지만 Surefire 관련된 dependency가 해결이 안되어 있었다. 이걸 기억해서 매번 그걸 exclude 시킬 수는 없는 노릇.

JUnit4에서 테스팅 framework의 고전이 걍 끝났나 싶었다. 더 이상 뭘 한다는 이야기를 못들어서. JUnit5 이야기를 듣고, 반갑긴 했지만 결국에는 제대로 써먹기에는 무리!

주로 개발하는 Framework 환경이 Springboot 환경인데, 어슬프게 지원되면 내가 짠 코드의 문제인지 프레임워크 설정 문제인지 가늠이 안되니까. 좋은 시도를 하고 있구나 정도로 받아들였는데, 최근에 프로젝트를 셋업 과정에서 2.2 버전에서는 기본으로 잘 지원하는걸 알게됐다. 이제 본격적으로 이 테스트 코드를 작성하면 되나? 테스트 코드를 새로 짜는 기회보다는 수정할 일들이 최근에는 더 많아서. 새롭게 작성하는 기회가 생긴다면 좀 더 추가적으로 정리해봐야겠다.

Something new in JUnit5

가잔 큰 차이점은 기존 Junit4와는 달리, Jupiter라는 새로운 package naming을 갖는다. 그리고 모듈화를 통해 Runtime 환경과 테스트 라이브러리가 분리되어 보다 다양한 환경에서 제공될 수 있는 기반을 제공한다. 뭐 좀 더 널리 활용되길 기대하는 마음이 한가득이라는 것은 모든 소프트웨어를 만드는 사람의 입장이 같은 것 같다.

JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

Vintage는 JUnit3,4와의 호환성을 위해 존재한다. 이전 테스트 환경에서 돌리고 싶다면 이 Vintage 설정을 다로 잡아야 한다.

Annotation

Lifecycle을 관리하는 Annotation들의 이름이 바뀌었다.

  • BeforeClass -> BeforeAll
  • AfterClass -> AfterAll
  • Before -> BeforeEach
  • After -> AfterEach

이름만 바뀌었지 하는 짓은 같다.

DisplayName annotation

이번에 추가된 신규 annotation 가운데 테스트의 의미를 아예 자연어로 기술할 수 있도록 도와준다.


@DisplayName("테스트 깨지면 안됨")

void shouldItNotBeBroken() {

...

}

이렇게 작성해서 테스트가 돌면, “테스트 깨지면 안됨” 이라는 자연어로 IntelliJ 테스트 결과에 잘 표시된다. 테스트 메소드 이름이 의미를 잘 전달하도록 해야, 테스트 자체의 유지보수가 가능하다고 이야기를 쭉 해왔는데, 다른 위치에 테스트의 Semantic을 기록한다는게 테스트 메소드 이름의 유지 보수에 과연 도움이 될지는 의구심이 있다. 적절한 중요의 미를 살리면 확실히 도움이 되긴 할거다. 아마도 누군가는 무조건 @DisplayName(“…”)를 적어야 한다고 Governance 하는 인간들이 언젠가는 등장하지 않을까?

Spring integrated tests

Spring 환경에서 Integration 테스트 혹은 Unit test를 할 때 @RunWith(SpringRunner.class) Annotation을 사용했다. 5에서는 기반 환경을 지칭할 때 @ExtendWith(SpringExtension.class)를 사용해서 테스트를 작성하면 된다.

 

Exceptional Tests

이전 모델에서는 Exception 발생 케이스에 대한 테스트를 위해서는 “expected”라는 변수를 통해 @Test Annotation을 테스트 수준에서 설정했다. 5에서는 “assertThrows()”라는 신규 assert 메소드를 이용해서 발생하는 Exception을 잡고, 그 Exception이 우리가 기대하는 Exception과 동일한지를 평가하는 방식으로 변경되었다. 기존에 Exception을 테스트했던 코드들이 좀 많다면 유지보수하는데 애를 먹을지도…

이것 이외에 추가된 assertAll, assertTimeout 메소드들은 앞으로 테스트를 작성할 때 상당히 도움이 될 것 같다. 이 링크에서 상세한 사용법을 확인할 수 있다.

 

 

 

Spring-security를 활용한 JWToken 인증하기

Posted by on

퍼블릭 환경에서 제공되는 API 서비스를 만들 때 가장 고민되는 부분은 보안이다. API가 제공하는 기능이 민감한 정보가 아니라면 개발자 입장에서 행복하다. 하지만 값어치가 나가는 유료 정보나 개인 정보 혹은 개인화 기반 정보가 제공되는 경우에는 고민이 깊어진다.

General Web Security

보안 정책을 웹 환경에서 구현하는 방법은 여러가지가 있을 수 있다. 보호 대상의 성격에 따라 다를 수 있고, 서비스 혹은 시스템의 연계성에 의해서 방법이 변경될 수 있다. 그럼에도 큰 맥락에서 2가지 기능으로 이 보안 정책은 구현된다.

Authentication

인증은 말 그대로 접근할려는 사용자 혹은 시스템이 맞는지 확인하는 절차다. 일반적으로 ID/Password를 이용한다. 요구되는 보안 사항이 높지 않은 경우, 이것만으로도 충분하다. 물론 이것보다 간단하게 생각되는 방식이 API Key 방식이다. 하지만 ID/Password나 API Key나 따지고 보면 같다. 개발자 관점에서 값을 하나를 사용할지 두개를 쓸지 차이뿐.

인증은 서비스에 접근한 존재가 누군지 알 수 있려준다. 여기에서 좀 더 복잡한 그 다음 프로세스를 원한다면 인증이 성공했다를 알려준다. 이 알려준 값은 권한(Authorization) 체크 용도로 활용될 수 있다. System vs. System 사이의 연동이라면 인증 처리만으로도 충분히 권한까지 함께 처리할 수 있다. 만약 사용자에 관련된 이슈라면?

Authorization

권한은 간단히 이야기하면, 인증을 요구하는 요청이 적합한지, 실행 권한이 적절히 부여되어 있는지 확인하는 절차다. Authorization이란 단어를 생각하면 “권한”을 먼저 생각하겠지… 하지만 현실에서는 올바르게 인증된 경우를 체크하는게 일반사다. 실제로 권한을 체크할려면, 권한 관리 시스템(모듈)을 통해 권한 클라이언트가 필요로하는 권한을 가지고 있는지 요청해야 한다. 권한 여부에 따라 True/False 결과만 확인하면 된다. 얼핏 이야기했지만 상당히 복잡하다. 복잡하다는 건 확인을 위한 Operation Cost가 많이 든다는 걸 의미한다. 그래서 이와 같은 권한 체크는 일반 사용자보다는 어드민 혹은 관리 시스템들에 한해 적용한다. 관리 시스템은 통상 내부망에서 동작하기 때문에 이런 복잡성을 굳이 가질 필요가 없다. 쉬운 방법을 충분히 찾을 수 있다.

결론적으로 일반 사용자, 그리고 대용량 사용자 대상 서비스의 경우에는 요청이 올바른 인증 정보를 포함하고 있는지만 확인하는 것만으로도 충분하다.

OAuth and JWT – JSON Web Token

이와 같은 인증 및 권한 관리 체계의 대표적인 모델이 OAuth 모델이다. 이를 구현하기 위해 적용된 기본 기술이 JWT이다. 예전에 JWT가 뭔지 어떻게 활용하면 되는지 정리한 글이 있으니, 더 궁금한 분이 있다면 참고한다. OAuth에 대해 안다고 주접떨기 보다는 아래 2개 링크를 참고하자.

  • https://ko.wikipedia.org/wiki/OAuth – OAuth wikipedia, 기본 개념정도는 이해 가능.
  • https://oauth.net/2/ – OAuth 2.0 standard

간단히 동작되는 Architecture를 머리 속에 그려보면 아래와 같다.

OAuth Authorization Architecture

간단히 그려보면 아래와 같은 일반 구조와 같다.

JWT를 만드는 역할을 Service에서 할 일은 아니지만, Authentication Service에서 만들어준 JWT 값을 가져오고, 올바른지 확인하는 역할은 Client Service의 역할이다. 헤더에서 이걸 가져오고 Public Key를 관리해서 이걸 검증하는 동작은 비슷한 패턴이다. 각 서비스에서 이를 구현하는 건 반복적인 코딩이 될 수 밖에 없다. 그래서 이걸 Spring-Security에서 좀 더 쉽게 할 수 있도록 지원한다.

 

Validating with Spring Security

자, 그래서 인증이 올바른지 체크하는 Spring Security 모듈을 처리해보자.

Maven setting

pom.xml

 

Configuration in Action

Configuration coding in the spring-boot project
이렇게 설정이 준비되면, spring 코딩을 마무리할 시점인갑다.

@Configuration
@EnableWebSecurity
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {
    protected void configure(HttpSecurity http) throws Exception {
        http.cors().and().csrf().disable()
                .authorizeRequests().antMatchers(whitelistedUriPatterns()).permitAll().and()
                .authorizeRequests().anyRequest().authenticated().and()
                .oauth2ResourceServer().jwt();
    }

    private String[] whitelistedUriPatterns() {
        return new String[] {
                "/health",
                "/swagger*/**", "/webjars*/**", "/v2/api-docs"
        };
    }
}

이렇게 처리하면 된다.

주목할 점은 특정 URI들의 경우에는 Load balancing과 내부 테스트등을 위해서는 별도의 인증을 타지 않도록 설정해야 한다는 점이다. 여기에서는 /health endpoint가 대표적이다. 만약 이걸 예외처리하지 않으면 L7 Switch의 경우, 설정된 endpoint가 비정상(401을 반환할 것이기 때문에)이라고 판단해서 Target group에서 이를 빼버리기 때문이다. 예제에서는 Swagger 관련 설정도 예외 처리를 했다.

application.yml

Configuration과 관련된 코딩을 반영했다면, 내부적으로 JWT Token의 Validation을 위한 Public Key endpoint를 추가로 잡아준다. spring.security.oauth2.resourceserver.jwt.issuer-url 속성에 Public Key가 존재하는 URL을 설정해주면 된다.

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://auth.games.com/public

 

물론 이렇게 하지 않고, 별도로 따로 Filter를 하나 만들어서 손수 체크할 수도 있다.

Authorization JWT handling

이렇게 설정을 하고 나면, JWT 객체안에 있는 특정 필드 혹은 객체 정보를 @AuthenticationPricipal annotation을 활용해 끄집어낼 수 있다. JWT내의 특징 필드를 끄집어낼때는 해당 field의 이름을 지정해서 추출한다. 아래 예제에서 subject라는 필드는 JWT의 기본 Claim에 포함된 sub 필드를 의미한다.

@PostMapping("/access/product/{productId}")
public SecurityAction verifyClientExecution(@AuthenticationPrincipal(expression = "subject") String id,
                                            @PathVariable("product") String product,
                                            @RequestBody SecurityInfo info) {
...
}

만약 JWT 전체 값을 참조하고 싶은 경우에는 아래와 같이 Jwt 클래스(org.springframework.security.oauth2.jwt.Jwt)를 파라미터로 지정해서 사용 가능하다.

 

Appendix

 

Hi~ there

Posted by on

새로운 시도라는 건 항상 두려움이다. 있던 틀 안에서의 나는 안전하다. 그 안전함을 벗어나 미지로 향하고 싸워야한다는 건 괴롭기도 하고 어떤 때는 정말 하기 싫다.

와중에 모든 일이 생각만큼 순조롭지도 않고, 별 생각하지도 않았던 곳에서 장애물이 튀어나마 마음도 괴롭고 몸도 괴롭게 한다. 요즘이 아마도 딱 이런 형국이다. 업무적으로도 개인적으로도.

아마도 살아오면서 성공보다는 좌절이 많았고, 그냥 주저앉아서 한걸음도 움직이기 싫은 적도 있었다. 마음대로 되지 않고, 하고 싶어도 할 수 없었다. 그럼에도 어떻게든 일어나 지친 걸음을 내딛었고, 정말 걷기 싫은 걸음을 내딛어 걸었다. 그래서 지금 여기에 있다.

Hi~ There.

어렵지만 그래도 가야겠지. 결론은? 글쎄 해피 엔딩일지 새드 엔딩일지 모른다. 그럼에도 다른 사람이 결론을 내주는 것보다는 성격상 내가 결론을 내는게 좋다. 부디 해피 엔딩이어야 하는데 말이다.

현실에서의 재택 근무

Posted by on

지난 3월 초에 재택 근무에 대해 간단히 글을 적었는데, 어느새 원격 근무를 5월 중반까지 해오고 있다. 회사 전체적으로는 2월말부터 원격 근무를 시작했으니 어느 덧 만 3개월을 다 채워가고 있다. 이 정도의 기간을 재택으로 지내다보니 얼추 이런 근무 형태도 할만하다는 생각이 든다. 업무만 봤을 때 해야할 일들이 거의 적절하게 진행되고 있는 느낌이긴 하니까.

재택 근무의 일상을 정리해보면.

출장을 못가다보니 본사쪽과 일은 지속적으로 챙겨야 한다. 슬랙으로 이야기가 잡다하게 길어질 것 같으면 아침에 콜을 잡지만, 그렇지 않은 경우에는 커뮤니케이션 하는 타이밍을 잘 잡아서 끊어지지 않게 해야한다. 말 그대로 이야기 줄기가 끊어지면 잊혀진다. 끊어진 걸 다시 이어 붙이려면 어렵기도 하고 투자해야할 시간도 많이든다.

그래서 아침 기상 시간은 재택 전과 비슷하게 6시 반이나 7시 사이를 유지한다. 전날 보내 둔 메시지에 대한 답글을 확인하고, 우리쪽 채널에 올라온 요청들이 있는지를 휴대폰으로 확인한다. 일상 다반사가 항상 바쁜 건 아니지만, 답을 얻어야 하거나 논쟁중인 사안이 있다면 후다닥 노트북 앞에 앉는다. 지금 내가 이야기를 던져야지 그 친구들이 답한다. 본사쪽은 오후 4시 근방이라 아직 일하고 있을 시간이다. 30분, 한시간 가량 본사 친구들과 이야기를 하고, 우리가 챙겨야 할 사항들이 있다면 관련 팀 채널에 내용을 전달한다.

출근 준비

8시 즈음에 시작하는 뉴스를 본다. 전에는 다음 뉴스에서 주로 새소식을 들었다면 재택 이후에는 YTN이다. 종종 쉬는 시간에도 가까이에 있는게 TV다 보니 정말 자주 보는 것 같다. 어제 발생한 코로나 이슈들을 중심으로 이야기를 듣는다. 참 세상 개념없는 인간들이 많다라는 걸 이번 사태를 겪으면서 다시금 확인한다. 국내, 국외 모두.

이쯤되서 와이프가 아침먹으라고 힘찬 소리를 들려주신다. 온라인 수업으로 등교해야만 하는 딸네미가 허우적 거린다. 처음 온라인으로 수업이 진행될 때만해도 짜증 대마왕이었다. 하지만 최근에는 동영상 스트리밍도 안정화된 것 같고, 한번 들은 수업을 다시 들어야하는 경우는 없어진 것 같다. (LG, MS 에저 화이팅!) 재택하면서 딸과 같이 밥먹는 시간이 많아졌다는 건 정말 좋다. 물론 전에도 아침은 매번 같이 먹긴 했지만 6시 반에 먹어야만 하는 아침밥이 딸에게 기분좋은 식사는 아니었을테니까. 온라인 수업 시간의 아침밥 먹는 시간은 8시에서 8시 반이다. 이정도만 되도 거의 짜증이 없었다. 전에는 왜 7시 반까지 등교하라고 한거지? 걍 9시까지 등교하라고 해도 충분할 것 같은데. 학교와서 책상에 코박고 잘께 뻔한 걸.

밥 든든하게 먹고 출근 준비한다. 양치하고 면도하고 샤워하고. 단장하고 근무복으로 갈아입는다. 이제 준비 완료!

완전 아재스럽다. 그렇다고 꽃중년도 아니니 걍 스킵. 부장님이 세미정장입고 근무하자라는 인터넷 짤을 보고 아이디어를 얻은 건 아니다. -_-;;; 하지만 넘 편하면 Naive해지는 건 어쩔 수 없이 부장님에게 동의. 전에도 이렇게 입었는데 걍 근무복이라고 생각하자. 사실 미팅하다보면 난닝구(메리야쓰???)부터 잠옷, 샤워 가운까지 다양하게 등장한다. ㅎㅎ; 일만 잘하면 되지, 복장은 편한 스타일대로 입는거지 뭐.

출근해서 업무 시작

회사에 출근했을 땐, 커피 머신에서 내려먹거나 바리스타분께 부탁드려 한잔 먹는게 습관이었는데, 그 습관 버리기 힘들다. 재택에서는 내가 바리스타.

이렇게 내린 커피는 전자렌지의 도움을 받아서 오후까지 먹는다. 물론 그 사이에 믹스도 두봉지쯤은 달달하게 타 먹지만. 막 내린 커피들고 이제 출근한다. 아드님께서 학교로 가버린 이후에는 아들 방이 내 근무처다. (탱큐~ 아들!) 좀만 제대로 된 공간이었다면 더 좋았을걸 하는 아쉬움도 있긴 하지만. 거실 한켠에서 쪼그려서 일하던 때보다는 한결 낫다. 9시 반에서 10시 사이에 자리에 앉아서 이제 본격적으로 근무를 시작한다.

오전 근무는 밤새 온 이메일들을 정리하고, 어제 퇴근 이후에 한국쪽에서 이야기된 내용들을 살펴보는 것으로 시작한다. 대부분 슬쩍 훝어보고 지나가지만, 간간히 참견해야할 내용들이 이메일로 온 경우가 있다. 필요한 것들에 대해서만 회신한다. 메일과 슬랙 훑어보는게 끝나면 이제 아침 데일리전에 해야할 코드 작업이나 할당 작업들을 한다. 데일리에서 공유할 내용들 대부분은 어제 해두긴 했지만 간간히 미진하거나 마무리 못한 꺼리가 있다. 아침 이 시간이 집중이 잘 되기 때문에 나름 일할만 하다. 마무리가 됐다면 Jira Ticket을 Done으로 marking한다.

데일리(Daily)

오전 근무의 하이라이트는 데일리(Daily)다. 에자일을 고집하는 분들이나 전문가들이 이야기하는 Daily는 아니다.Jira 보드 놓고 한일/할일 혹은 넋두리를 한다. 어찌보면 딱 아침 조회다!! ㅎㅎ

11시가 되면 5~7명쯤 개발팟 인원들이 행아웃에서 모인다. 가장 연장자 분이 BGM을 깔아놓으면 사람들이 모일동안 감상의 시간을 갖는다. 얼추 참석자들이 모이면 진행자가 순서대로 Jira 보드에서 담당자를 선택하면 업무 이야기를 공유한다. 오늘 할일이나 어제 겪었던/논의했던 이슈나 Blocker들에 대해 이야기한다. 진도를 많이 빼신 분은 Backlog에서 할만한 일이나 Sustaining꺼리를 물어본다. 동료가 봐줬으면 하는 걸 이야기하면 그걸 도와주거나 아님 팟 리드가 처리되어야 할 꺼리를 백로그에서 뽑는다. 두루두루 이야기하고, 마지막으로 팟 리드가 어떤 일들이 있으면 챙겼으면 좋겠다는 것으로 마무리한다.

형식을 보면 에자일식은 아니고 칸반 스타일인가? 오피스에서 모여서 이야기할 때는 15분안에 끝내는게 목표였고, 대부분 그 시간안에 마쳤던 것 같다. 하지만 온라인으로 진행하면서 전체 시간이 좀 오래 걸린다. 이건 꼭 데일리 뿐만 아니라 거의 모든 회의들이 오피스 미팅룸에서 모여서 하던 것보다는 전체적으로 길어졌다. 한번에 여러 사람이 한꺼번에 이야기할 수 없다는 제한이 있기 때문이기도 하고 같이 얼굴 맞대고 이야기할 기회가 없다보니 다들 한 두마디씩 더 하는 것 같다. ^^;

Work & Break in the afternoon

정리하고 데일리에서 나온 것들 가운데 바로 F/U해야할 꺼리를 봐주고 하다보면 12시다. 12시라고 꼭 밥 시간은 아니다. 하지만 2시간 정도 일했으니 쉬는 시간이 맞긴 하다. 닫혔던 방문 열고 거실로 나가서 가족들과 잠깐 이야기도 하고 새로 나온 코로나 확진자 수도 확인한다. 최근에는 거의 자리수가 한자리 수라서 다행이라는 생각이 든다. 하지만 백신과 확실한 치료제가 나오기 전까지는 끝나도 끝난게 아니라는거.

내가 때를 챙기지 않더라도 따님 덕분에 1시 되기 전에는 거의 점심을 먹는 편이다. 물론 삼시세끼를 다 챙기느라고 와이프 고생이 많다. 와중에 나는 미팅중, 딸은 온라인 수업중이라 와이프만 쥐죽은듯이 거실이나 침실에서 꼼짝도 못한다. 얼떨결에 같힌 신세가 되버렸다. 원래 집에서 낮시간은 와이프의 공간과 시간이었는데, 난데없이 딸과 내가 이걸 빼앗아버렸으니…

점심 먹고, 커피 한잔 후 다시 문닫고 업무 복귀. 데일리를 빼고 하루에 보통 1~2개의 미팅이 있다. 한국팀과 미팅은 거의 한시간을 꼬박 채운다. 참석하는 사람도 좀 많은 편이고 사람당 두서너 마디 이야기가 돌고나면 훌쩍 1시간을 채우는게 다반사다. 미팅 끝나고, 메일이나 슬랙 메시지 보내다보면 두시간쯤이 훌쩍 간다. 거북 형상으로 목이 뻣뻣해질 때쯤이면 거의 3시 근방이다. 쉴때다.

오후에는 한두번쯤은 아파트 주위를 3~4번쯤 돈다. 3월부터 거의 빼먹질 않았다. 덕분에 시간이 이렇게 가고 자연이 이렇게 변해가는걸 눈으로 본다. 그 전에는 제대로 느끼지 못했던 새로움이다. 그러고보니 겨울의 끝자락에 이 생활을 시작해서 이제 여름으로 접어든다.

산보에서 복귀 후 다시 일을 시작한다. 대강 요 무렵이면 집안일의 갱킹이 들어온다. 5시나 6시 근방이면 쓰레기를 버리거나 분리 수거에 관련된 업무 요청이 들어온다. 잘 보여야 후환이 없기 때문에 정 급하지 않으면 바로 처리해야 한다. 그래도 이 시간 타임이 가장 일을 많이 하는 시간대다. 2~3시간 연속으로 몰입해서 일할 수 있는 시간이 많다. 최근 2~3주 사이에는 코딩 이외의 다른 행정 업무들이 많아서 이런 시간을 갖기가 어려웠는데, 대강 마무리해서 다시 코딩에 복귀하고 있다. 이렇게 중간에 쉬어버린 시간이 많으면 예열에도 시간이 오래 걸린다. -_-;;; (몸은 못 속이나?)

퇴근

6시 반이나 7시쯤되면 따님이 “퇴근했어?“고 물어본다. 상황따라 약간씩 잔업이 있긴 하지만 대부분은 그 시간 즈음이면 슬랙 채널에 “퇴근합니다.” 라고 이야기한다. 슬랙 알람은 7시가 지나면 자동으로 Off된다. 바꿀 수도 있지만 굳이 그러지않는다. 일단 해야만 하는 일들은 처리했고, 해야할 일들은 Calendar에 적어두거나 Ticket으로 정리해뒀다. 이제 정말 놓친 일들이나 내가 하고 싶은 것들을 한다.

오후 내내 놓친 뉴스를 좀 보기도 하고, 못읽은 책을 읽는다. 책을 읽는다고 이야기를 해봐야 하루에 한시간 남짓이 될까말까다.

와이프와 딸과 저녁먹고, 최근 재미있는 드라마나 예능 보면서 이야기를 나눈다. 이전에는 가족과 이야기하는 시간이 평균 30분 넘을까 말까였다면 재택 이후로는 적어도 1시간 이상이 되니까 고건 참 바람직하다. 특히 딸과의 대화 시간이 많이 늘어난 건 개인적으로 기쁜 일이다.

 

재택. 하다보니.

일하는데 있어서 몇가지 보이는 것들이 있긴하다. 일단 준비된 재택 근무를 하기 위해서는 필요한 것들이 많다. 그 가운데서 가장 큰 문제는 가족으로부터의 동의와 협조가 무엇보다도 필수적이라는 것이다. 집에서 일하는 것에 대한 가족의 인식과 협조가 없다면 재택은 불가능하다. 특히 현재의 재택 상황을 봤을 때 더욱 그렇다.

챙김이 필요한 육아를 본인이 병행해야하는 상황에서의 재택은 불가능하다. 차라리 휴가를 내는게 본인의 정신 건강을 위해서 낫다.

커뮤니케이션에서 진심이 보여야 한다. 그래서 온라인 화상 통화에서 얼굴은 가급적 보여줘라. 정장을 입고 있으라는 이야기가 아니다. 말 그대로 얼굴을 보여주라는 것. 대화에서 표정과 제스처는 생각 이외로 많은 것들을 전달한다. 이건 수화에서 왜 표정이 중요한 역할을 하는지와 어찌보면 같은 맥락일 것이다. 한국팀은 그래도 본사 친구들과 콜을 많이 해서 기본적으로 얼굴을 보여줄 것이라고 생각했는데 이외로 거의 보여주지 않는다. 보여주지 못한다면 못하는 그것 자체에 문제가 있다. 육아 관련 예외를 빼고 나머지는 이유가 안된다.

명확한 근무 시간을 명확히 하고 알려야 한다.  본인을 위해서도 협업하는 동료들을 위해서도. 종종 재택이라고 근무 시간을 본인들의 작의적으로 정해버리는 경우가 있다. 근무 시간을 정하는 이유는 협업을 위해서다. 당연히 한국 상황만 놓고 본다면 9시부터 6시 사이를 근무 시간으로 정한 이유는 그 시간이 보편적으로 연락 가능하고 협업이 가능한 시간임을 모두가 암묵적으로 동의하기 때문이다. 메신저 뒤에 숨어서 페이크치다 걸리면 쪽팔린다. 재택이라고 하더라도 근무 시간이 변경된 건 없다. 가능하면 지켜야 하고 못지키면 이야기해서 협업에 방해되지 않도록 알려야 한다.

부재는 알려라. 오피스 공간에서 근무를 선호하는 이유는 고개 돌리면 동료가 옆에 있고, 이야기할 수 있기 때문이다. 온라인으로 일을 하는 경우에도 마찬가지 환경이 되야 한다. 오피스에도 자리 비운다면 자리 비운다고 동료에게 이야기한다. 마찬가지로 행동하면 된다. 재택이라고 다르지 않다.

팀을 생각해야 한다. 재택은 공간적으로 팀을 배제한다. 혼자있는데 뭔, 팀… 때문에 더욱 더 개인화된다. 같은 공간에 팀이 모여있는 공기와 자신만의 공간에서 느끼는 공기는 당연히 틀리다. 팀이 팀으로 느껴지는 이유는 공간적인 이유가 크다. 하지만 재택은 이를 분리한다. 이런 거리감을 인위적으로 줄일 수 없다. 강제로 줄여봐야 파열음만 난다. 스스로 팀원이어야 한다. 자발적으로 팀의 상황을 이해하고 팀의 발전을 위해 기여해야 한다. 정해진 일만 하겠다면 재택과 맞지 않는다. 아니 되려 팀 플레이 자체가 맞지 않는거 아닐까도 싶다.

••••••

재택은 팀 플레이를 시험한다고 보여진다. 공간으로 분리된 상황에서 개인이 팀이라는 인위적인 공동체를 유지할 수 있을 것인가? 이 과정에 스스로 있기도 하고, 결과가 어떻게 나올지 기대된다. 본사에서도 실패했고, 때문에 공간을 중심으로 팀을 유지하는 것이 현재 정책이었다. 이제까지 나도 이에 동감했고, 크게 바뀌지 않았다.

하지만 기대 이외의 결과를 보고 싶다. 당장 재난 형국을 넘어서기 위해서도, 그리고 먼 미래를 위해서도 ^^;

 

원격 근무(Remote working) – 꿈과 현실의 차이

Posted by on

2020년은 파란만장하게 시작했다. 그리고 3월의 어느 시점을 관통하는 지금 개인을 넘어 전세계적으로 “코로나19 바이러스“로 혼란의 도가니 안에 있다.

바이러스의 습격은 한국 기업에게 원격 근무를 선택지로 강요하고 있다. 한 공간에 사람이 모이는 것 자체가 감염의 근거를 제공하기 때문에 업무를 이어가기 위한 어쩔 수 없는 선택이 되버렸다. 몇 일 전직원 휴가를 쓸 수 있겠지만, 그 기간은 몇 일을 못 넘긴다. 감당이 된다면 직원들이 사장님 “쵝오!!!” 를 외칠텐데 말이다.

나도 현재 원격 근무를 시전중이다. 불가항력적인 몇몇 부서를 제외하고는 오피스에 속한 모든 사람들이 원격 근무를 하고 있다. 다른 팀들과 비교했을 때 개발팀은 해외 팀들과 그동안 협업을 해왔고, 그 팀들은 어떤 식으로 원격 근무를 하는지를 봤었으니까… 협업할려고 본사갔더니 이 친구가 원격 근무하는 친구라서 삼실에 안나온다는… 뱅기타고 힘들게 날라왔는데, 정작 만나는게 행아웃(Hangout)이면, 거참…

Nomad?

개발자라면 한번 쯤 원격 근무를 생각해봤을 것이다. 태국의 어느 한 동네에서 호젓하게 자신만의 코딩 세계에 빠져서 일하다가 무더위에 지칠 무렵이면 바다가에서 수영으로 스트레스를 날려버리는. 그리고 늦은 석양을 바라보며 PR 날리고 함께 즐기는 친구들과 바에서 맥주 한잔? 걍 생각만 해도 멋있네.

Financial Case Study: Kim and Ryan Desmond, CodingNomads

하지만 실상은 이렇지 않을까? 서로 갈린 시차로 오해가 생긴 슬랙으로 인해 팀원들과 오해가 쌓인다. 문자의 한계를 벗어나 화상 회의로 진행할려 했으나 화질은 뚝뚝 끊어지고, 웅웅대서 뭔 소리를 하는지 하나도 알아들을 수 없다. 와중에 원격에서 참가한 사람들이 많다보니 서로 이야기할 순서를 못잡는다. 결국 눈치보다가 해야할 이야기를 못하고 마무리된다. 이미 해는 저물어가는데 느려터진 VPN 때문에 PR을 날릴 수가 없다. 이럴거면 때려치라는 매니저의 얼굴이 아른거린다.

Culture of society

각자가 일하는 방식이 있기 때문에 원격 근무는 호불호가 갈린다. 특히 사회 분위기와 관련이 깊달까? 미국처럼 개인 문화가 발달한 곳에서는 원격 근무가 잘 받아들여진다. 개인이 해야할 일을 잘 해내기만 하면 된다. 다른 사람 일은 신경쓸 필요없이 계획된 일들 가운데 자신이 하기로 한 일만 잘 하면 된다. 이런 분위기에서는 원격 근무가 되려 더 좋은 결과를 낼 수 있을 수도 있다. 같은 공간에서 팀으로 일할 때는 업무 외적으로 시간이 소모되는 경우가 크니까.

이에 반해 한국처럼 조직을 우선시하고, 계층적 조직 문화가 발달한 곳에서는 원격 근무가 힘들다. 보고를 우선시 해야하고, 그 사람과 면대면으로 이야기를 해야 일 파악이 순조롭다. 팀이 빠른 협업으로 일을 해나간다는 측면에서 같은 공간에서 함께 일하는 방식이 더욱 효율적이다. 상대방의 얼굴보면서 하는 커뮤니케이션은 화상보다 몇 배는 더 좋은 결과를 만들어낼 수 있으니까. 더구나 슬랙이나 메신저를 통해 이야기를 하는 것보다, 잠깐 등돌려 이야기하는게 속도와 진정성(특히)에서 백배 낫다. 누군가의 뻘소리를 기록하기 위해서 메신저로 이야기하는게 정신 건강에 좋다고 말하지만, 그럴거면 그 사람이랑 일을 말아야지. 정신 건강까지 생각하면서 일을 해야하는거면 일을 안하는게 되려 정신 건강에 좋다.

그럼에도 출근 못한다

어쩔 수 없는 이번 원격 근무는 어쩔 수 없이 재택 근무를 해야한다.

나도 주말에 노트북들고 커피 가게에서 책읽고, 오랫동안 코드짜고, 블로그 글 쓰는걸 좋아하지만… 갈 수 없다. 못 간다. 집에서 어떻게든 일을 해야한다. 얼추 애들이 컷으니까 일하는데 별 지장없는 내 입장이만, 유치원이나 초등학교 다니는 애들이 있는 집은 애들도 함께 쉬고 있다!! 단언컨데 절대 애들이 간만에 집에 있는 아빠, 엄마를 가만두지 않는다. 이 좋은 기회를 어떻게 날릴까. 애들은 본인들은 방학이고 아빠, 엄마는 집에 함께 있는 휴가 기간인데. ㅋㅋㅋ 워킹맘, 워킹대디면 걍 휴가를 내는게 되려 이래저래 눈치 안볼 방법일 수 있다. 하지만 이마저도 쉽지 않은게 역설 ㅠㅠ;;;; 이건 한국만의 현실이 아니라 글로벌 이슈다. 애 있는 집에서는 원격을 못한다.

뭐 꼭 애들있는 집만의 문제는 아니다. 집이라는 공간은 원래 휴식을 위한 공간이다. 누구든 그 공간 안에서 열심히 일할려고 애쓴다고 하더라도 결국은 휴식의 유혹에 시달려야 한다. 소파가 나를 땡기고 침대가 나를 땡긴다. 거기다가 주말이면 항상 눈을 고정하고 있던 TV가 나를 유혹한다. 와중에 아무도 나를 열일하라고, 결과는 어디에 있느냐고 닥달해대는 사람도 없네!

이런 유혹들을 이기고 일을 해야한다. 직장인으로써 해야할 일은 있으니까. 그래서…

  • 집에 계신 분들께 선언을 해둬야 한다. 일하는 시간과 장소를.
  • 팀원들과 일하는 시간을 정한다. 소위 말하는 Core Working 시간을 정해야 한다. 시도때도 없이 연락오는 것에 매번 즉각적으로 응답할 수 없다.
  • 명확해야 할일과 해야할 일들을 스스로 관리해야 한다. 스스로 Loose해지면 망한다.
  • 인상 관리 측면에서 세수랑 머리는 감자.
  • 메신저보다는 화상 회의를 잘 사용할 줄 알아야 한다. 같은 언어권에서도 텍스트는 자칫 오해를 부르기 십상이다.
  • 애가 회상 회의에 갑자기 뛰어들면!!! 놔두고 아저씨, 아줌마들 얼굴 알아두도록 하자. 나중에 용돈 챙길려면 이번 기회에 용모 파악을 잘 해둬야 한다.

 

그래서 개발의 원격 근무는?

원격 근무는 서울에서 일하는 직장인에게 좋은 옵션이 될 수 있다. 당연히 여러 좋은 장점들이 있으니까. 출퇴근에 시간 안버려도 되고, 장소만 적절하다면 집중과 몰입을 만들어내서 더 효과적으로 일할 수 있을테니까. 시간을 조절할 수 있으니 소위 말하는 일과 삶의 균형(??)을 맞출 수 있을지도.

단, 팀의 속도와 성과를 저해하지 않는다는 전제가 담보되어야 한다. 같은 공간에 있음으로써 얻는 가장 큰 장점은 빠른 커뮤니케이션이다. 특히 요즘과 같이 소수로 팀이 만들어지는 경우에는 더욱 더 빠른 소통과 의사 결정이 중요하다. (아마도 이게 제일 중요하지 않을까?) 누구 한명이 커뮤니케이션을 함께 하지 못하면 그 사람을 기다려야하거나 혹은 없는 상태에서 진행해야 한다. 긴급하게 논의해야할 내용이 있어서 메시지를 보냈는데 그 사람이 10분내로 응답하지 않는다면? 그렇다고 찾아볼 수 있는 공간에 있는 것도 아닌 원격에 있는데. 커뮤니케이션이 담보되지 않은 상태는 팀의 업무 진행이 담보되지 않았다는 것과 어떻게 보면 같은 맥락이다. 개발자 3명 ~ 4명 정도가 최선의 개발팀이라고 생각할 때, 누구 하나 제대로 이야기에 어울리지 못하면 개인도 팀도 망가질 가능성이 크다.

Face-To-Face Communication: 6 Reasons to Lead in Person

그래서 혼자 일해도 되는 직종의 경우에는 이 방식이 더 좋은 개인적인 성과를 낼 수 있을지도 모른다. 하지만 개발자는 혼자 일하는 사람이 아니다. 최근에는 더욱 더. 혹자는 스펙만 정해지면 그거 개발하면 되는거지… 라고 이야기하는 사람들이 더러 있다. 가만보면 그런 사람들이 에자일, XP 이야기를 참 열심히 하는 것 같다. “함께 다 같이 잘 해보자!“가 에자일이지, “나만 잘 하면되지!“는 아니다.

원격 근무는 상당히 매력적이다. 그만큼 도전해야할 부분들도 많고. 좋은 방안을 찾을 수 있다면 좋겠다.

– 끝 –

 

참고 글

CRA(create-react-app)에서 IE 지원하기

Posted by on

한국에서 인터넷 서비스는 IE 지원이 없으면 말도 안되는 이야기다. 적어도 작년까지는 확실히 그랬던 것 같다. 그랬을거야…

새로운 Frontend Application을 개발할 일이 있어서, CRA 프로젝를 생성했다. 별 생각없이 열심히 개발했다.

$ npx create-react-app new-app
npx: 99개의 패키지를 19.738초만에 설치했습니다.

Creating a new React app in /Users/tchi/Workspace/works/new-app.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template...
...
We suggest that you begin by typing:

cd new-app
yarn start

Happy hacking!

얼추 개발을 마무리해서 QA분들께 검증을 부탁했더니 IE에서 아예 동작을 안한다는… 응 뭐지?

"browserslist": {
  "production": [
    "> 0.2%",
    "not dead",
    "not op_mini all"
  ],
  "development": [
    "last 1 chrome version",
    "last 1 firefox version",
    "last 1 safari version"
  ]
}

개발 모드에서는 당연히 IE가지고 개발하는 frontend 개발자는 없으니까 그럴 수 있다고 치자. 그래도 IE11 정도면 당연히 지원되어야 하는거 아닌가? 그래도 0.2% 정도는 넘을거고, 죽은 Browser라고 보기에는 Rendering이나 보안 측면에서 나쁘지는 않았으니까. 그런데 왜 기본 동작이 안되는거지. 분명 작년에는 Ajax 관련된 부분을 빼고는 Rendering 정도는 문제가 없었는데 말이다.

ReactJS 사이트를 뒤져보니 CRA 앱에서 지원하는 브라우져 기준이 나온다.

Supported Browsers

By default, the generated project supports all modern browsers. Support for Internet Explorer 9, 10, and 11 requires polyfills. For a set of polyfills to support older browsers, use react-app-polyfill.

음… IE11이 Modern Browser가 아니구나… IE11가 이정도 취급을 받는데, 얼마나 지분이 있는거지 궁금해서 함 찾아봤다. 2019년 11월 기준이긴 하지만 Global 지표로 IE는 아예 지표에서 보이지도 않는다. 흐미…

따로 IE부분만 filtering해서 살펴봤더니 IE 총합이 3.66%이다. 아마도 IE11, 10, 9, 8이 사용되는 IE의 총합일텐데, 3.66% 수준은 정말 충격적이다. 더욱 놀라온 건 한국에서만 Edge를 안쓰는 줄 알았는데 전세계적으로도 버림받은 브라우저라는 것이다. 나름 MS에서 야심차게 개발한 놈인데, 가열차게 시장에서는 외면받았다. 이정도 되니까 MS에서도 Chromium으로 갈아타서 Edge를 다시 만들었겠지.

이정도 쯤 되니까 한국은 상황이 어떻지 하는게 궁금해서 함 찾아봤다. 항상 IE, IE라는 이야기를 많이 들어서 점유율이 30% 이상은 되겠지라는 기대를 했다. 그런데 의외로 한국의 브라우저 통계 데이터에서 IE가 차지하는 비중이 20% 미만이다. 막판에 약간 올라가긴 했지만 전체 비중이 15% ~ 20% 수준에 머문다. 조만간 한국에서도 굳이 Frontend App을 개발할 때 IE를 고려하지 않을 날이 올거라는 희망이 있다는 이야기. 물론 철옹성처럼 바뀌지 않는 금융권이나 공공기관 웹들이 버틸거기 때문에 IE가 아예 사라지지는 않을 것이라고 확신한다. 그럼에도 내가 만드는 앱이 동작되고 지원해야할 브라우저 목록에서 조만간(한 5년?) 사이에 IE가 빠지긴 할 것 같다.

본래 정리할려는 내용으로 다시 돌아가서…

IE를 지원하지 않는 최근 CRA가 IE를 지원하도록 만들려면 react-app-polyfill을 사용하면 된다. npm install react-app-polyfill –save 명령이면 간단하게 최신 polyfill 지원 사항을 CRA 프로젝트에 추가할 수 있다. 물론 이것만으로는 동작하지 않고, 최상위 JS 파일인 index.js 파일에 지원해야할 브라우저 버전에 대한 사항을 import 해줘야 한다.

// These must be the first lines in src/index.js
import 'react-app-polyfill/ie11';
import 'react-app-polyfill/stable';

코멘트에 나온 것처럼 index.js 파일의 가장 앞선 라인에 이 2가지 import 항목들을 추가해주면 크롬에서 돌던 기능들이 자연스럽게 IE11에서도 동작한다. Promise, fetch 등 작년까지만해도 하나씩 잡아줘야 했던 것들이 이 간단한 설정으로 동작한다. CRA를 사용하면 대부분 것들을 Behind the scene에서 처리해주기 때문에 개인적으로 좋아한다. Polyfill에 대한 사항도 마찬가지 컨셉으로 지원해주니 일관성을 제대로 유지하는 것 같다. 물론 Babel 수준에서 마이크로 세팅해서 최적화하는 걸 즐기시는 분들도 있다. 내가 이정도 역량이 있는 Frontend 개발자는 아니기 때문에 UI를 구조화된 코드로 만들 수 있다는 것만으로 만족한다.

Frontend에 개발할 때 모듈화된 CSS를 사용할려면 scss를 추천한다. devDependencies에 node-sass를 추가하고 기본 생성된 *.css 파일의 이름을 *.scss로 변경하고 각 css 파일의 import를 scss 파일로 교체해주면 된다. 진행중인 프로젝트에 적용할려면 짜증나기 때문에 프로젝트 생성 초기에 설정을 변경해주는게 인생 편하다.

– 끝 –

 

반응형 웹 만들기

Posted by on

반응형 웹을 만들어보는게 해보고 싶은 일들 가운데 하나다. 모바일 시대가 이미 20년이 넘었는데, 내가 하던 웹은 PC 환경에 머물러 있었다. 굳이 모바일을 지원할 필요가 없기도 했던게 변명의 이유로 가장 컸다고 자조하고 싶다. 혹은 굳이 내가 그런걸 해야할까? 하는 섣부른 허세가 가득했다.

지금도 작업하는 대부분의 작업이 PC 환경에 국한되어 있다. 일단 UI가 6년전에서 일도 전진하지 못했다. 그러니 새롭게 FE APP을 만들더라도 UI 자체는 그 밥에 그 나물이다.

이번에 새로운 기능 하나 하면서 드디어 구태 의연한 한국식 UI 스타일을 벗어버릴 수 있었다. 이것이 가능한 이유는 굳이 이것 저것 덕지덕지 붙이는 기능들이 없다. 기존 화면들은 화면에 뭘 그렇게 많이 요구하는지 나래비세울 항목들이 많다보니 PC형 화면이 아니면 배치 자체가 힘든 경우가 허다했다. 화면에 노출되는 정보다 간단한 목록이 전부다. PC와 모바일을 동시에 지원해보기 적당한 항목들이고 기능의 크기다.

반응형이라고 해서 거창하게 들리지만 한 기능을 PC와 모바일 2개 채널에 제공해보는 것이다. 예전이라면 한 기능을 2가지 채널에 제공하더라도 각각의 Frontend App을 따로 만들었다. 도메인만 보더라도 PC에서 사용하는 도메인은 www.features.co.kr 과 같은 도메인을 사용했다면 모바일은 m.features.co.kr 형태를 사용했으니까. 도메인이 틀리니 당연히 코드도 틀린 방식으로 가는 걸 자연스러워 했던 것 같다.

예전에는 이런 접근 방법이 상당히 맞는 소리같아 보였는데, 최근에는 이게 뭔 짓인가 싶기도 하다. 같은 기능인데 굳이 m자 붙힌 모바일 도메인을 따로 만들었을까? 도메인과 인증서에 비용도 들어가고, 되려 어플리케이션에서 이걸 감안해서 코드를 짜는게 더 귀찮데… 어쩌면 “남들도 저렇게 하는데 우리도 같이 가는게 맞지!”라고 관성이고 타성이다. 최근에는 이런 것들에 대해 한번씩은 질문할 수 있는 마음이 생긴게 다행이라고 보인다.

반응형이라고 거창하게 이야기를 했지만, 따지고 보면 화면 크기에 대해 어떤 방식으로 보여지는지를 제어하는게 고작이다. 이 부분을 제어하기 위해 지원하는 CSS상의 기능이 미디어쿼리(MediaQuery)라는 것이다. 한참 전부터 존재했던 거지만, 언제나 그렇듯 안 해본게 문제다.  이걸 사용하지 않고 할려면 Javascript로 화면 크기 혹은 UA를 확인해서 화면을 제어해야 한다. 이런 방식은 정말 엄청난 수고를 필요로 하고 관리도 문제다.

...default style for all(pc)...
@media screen and (max-width: 768px) {
body {
background-color: lightgreen;
}
}

위의 코드를 보면 기본으로 PC 환경의 CSS 스타일을 기본으로 사용하고 모바일의 경우에 대한 스타일을 추가로 정의한다. 이렇게 되면 기존 정의된 스타일을 오버라이딩(Overriding)한다. Landscape 상태에서는 화면 폭이 넓기 때문에 굳이 특별한 UI 상태를 정의할 필요가 없다. 우리의 주 관심은 Portrait 상태다.

화면이 짧은 경우, 표시해야 할 정보를 없애거나 표현 형태를 변경해야 한다. 이 방식을 적용할 때 전체적인 레이아웃의 유연성이 담보되야 한다. 음… 테이블(table) 같은 UI 요소를 사용하지 말라는 거다. div, p, span 같은 요소들을 사용하면서 display 속성으로 있는 flex, inline-block들을 활용해서 정보를 배열한다. 그럼 정보를 좀 더 깔끔하게 없애거나 다른 형식으로 표시하는데 유리하다.

물론 숨기는 방식은 별로 선호할만한 방법은 아니다. PC에서 나오는 항목을 굳이 모바일이라고 숨길 필요는 없으니까. 또한 클라이언트로 전달되는 정보 혹은 데이터의 물리적인 양도 바뀌지 않는다. 단순히 안보이는 것 뿐이니까.

개발 출장의 하루

Posted by on

내가 회사에서 가장 많이 출장가는 사람 가운데 한 명이다. 체류 일정으로는 넘사벽 1등이었는데, 최근에는 본사쪽과 좀 더 긴밀하게 일하는 분들이 생겨서 그나마 이 기록도 내줘야 할 듯 싶다. 내가 아닌 다른 분들이 본사 혹은 다른 지역의 개발팀들과 호기롭게 커뮤니케이션하고 함께 일하는 모습 보면 기분이 좋다. 우리가 가기만 했었는데, 최근에는 본사/타지역 친구들이 한국 오피스에 와서 함께 한국의 문제점을 해결하기 위해 일한다. 이야기해보면 본사 개발팀 친구들도 우리랑 비슷한 업무 부담과 기대를 가지고 한국 오피스에 왔다는 걸 알 수 있다. 보면 그 친구들도 와서 일은 참 열심이 한다.

다들 한국이 아닌 외국에 출장 간다는 것에 대한 환상이 있을 것 같다. 나도 처음 출장에는 그런 환상이 있었으니까. 하지만 프로 출장러가 되다보니 실제 함께 출장온 분들이 실망하는 경우가 많다. 물론 첫 3번의 출장에서 완벽한 스케줄을 작성해주신 분들이 계셔서 LA에서 봐야할 곳들은 웬만큼 봤다. (거봐~~~~) 물론 그 다음에 라라랜드가 떠버리는 바람에 더 봐야할 곳들이 생기긴 했지만,.. 굳이… 혹여 어느 분들이 나랑 출장 일정을 함께 할지 모르겠지만, 실망감 최소화를 위해 가장 최근 버전의 일상 동선을 공유해보고자 한다.

~~~~

보통 일을 시작하기 하루 전에 도착한다. 그래서 한국에서 일요일에 출발하고 LA에는 일요일에 도착한다. 와중에 떠난 시간보다 더 빠른 시간에.

많이 피곤할 것 같은 일정이라면 휴식을 위해서 하루 정도 더 여유를 두기도 하지만 굳이 그러고 싶지는 않다. 10시간의 비행의 피곤함도 있지만, 17시간의 시차는 쉽게 하루를 온전히 쉬는 것도 힘들게 한다. 면세 팩소주를 사오는게 일상이 되었기 때문에 도착 당일은 팩소주로 장시간 비행의 피로를 잊어보려한다. 아쉽지만 절반의 성공과 실패로 나뉜다.

아침에 일어나는 시간은 언제나 다름없이 새벽이다. 대부분 “약속의 새벽 3시”에 한번 깬다. 더 잘 수 있다면 눈에 선 핏줄이 훨씬 덜하다. 한번 깨면 다시 자기 힘든 스타일이라 처음 잘 때 잘 자길 기도한다. 하지만 기도발이 약한지 성공 확률은 20%가 되지 않는다.

일반 수면 유도제를 몇 번 시도해봤지만 정신만 몽롱하지 새벽 그 약속을 못어긴다. 왜 깨는겨!!! 결국 처방받은 수면제가 정답이다. 한 알이면 4시간, 두알이면 확실히 8시간 이상 잔다. 단 술먹고 먹으면 영영 못깨어날 수 있으니 조심하자.

최근에는 아침 6시 즈음에 호텔에 있는 운동 시설에서 걷기나 자전거 타기를 한다. 한국에서 하지도 않는 운동을 출장와서 한다는 것도 우숩다. 하지만 하면 조금이라도 일상 생활에 도움이 된다. 이번 출장에는 일정의 절반 동안 아침 운동을 했는데, 한날과 안한 날의 차이가 있다. 조금이라도 즐겁게 일하고 싶다면 권한다. 하지만 과도한 운동은 코피를 동반할 수 있으니 조심하자.

운동하고 씻고 출근 준비를 마치면 얼추 8시 혹은 8시 반이다. 여러 사람들과 함께 온 출장이라면 불러서 같이 이동하거나 출발 시간이 안맞으면 걍 “우버(Uber)” 불러서 출근한다. 주로 묶는 호텔과 캠퍼스(본사 사무실)까지 안밀리면 10분, 15분이다. 지하철타고 출근하는데 못해도 한시간 이상인데, 도어 투 도어(Door-to-Door)로 이 시간밖에 안걸린다는 엄청 매력적이다.

캠퍼스에 도착하면 항상 빌지 카페에 가장 먼저 들른다. 하루 시작은 역시 핫 아메리카노다. 유기농 빵도 9시 전에는 남아있는데, 특히 애플 파이랑 크로와상은 일품이다. 커피랑 빵은 다른 식당에 맛이 뒤지지 않는다.

출장와서 매번 같은 아메리카노만 시켜먹다보니 특이했나보다. 카페 직원이 얼굴만 보고 “아메리카노?” 라고 간단히 묻고 내 이름을 컵에 적는다. 처음에는 신기하기도 했지만, 이쯤되니 카페 고참 직원들은 내 이름을 기억하고 있다.  웃어야 할지 울어야 할지 모르겠다. 그럼에도 웃으면서 내 이름을 불러주니 즐거운 경험이다.

커피도 받았고, 간단히 배도 채웠으니 이제 일할 시간이다.

오전에는 보통 1개 회의를 잡거나 잡지 않는다. 보통 첫주에 진행하는 미팅의 2/3 정도는 출장 오기 전에 모두 잡는다. 내 출장은 대부분 한국 업무를 구현하기 위해서다. 일을 하기 위해서 필요한 사람들이 누구인지 사전에 파악하고, 일정을 확인 한 다음에 출발 비행기 타기전에 미팅을 잡는다. 사실 상대편에게 미팅을 잡아달라 부탁하면 제대로 된 적이 거의 없다. 사실, 그 친구들은 관심이 없다. 그 친구들은 내가 도움을 받아야 할 사람들일 뿐이다. 목마른 사람이 우물 파는게 당연하다. 컨텍스트를 알리는 이메일이나 슬랙 메시지를 사전에 보내놓고, 캘린더 빈 시간에 꽂아넣는다.

미팅에서 이야기를 하다보면 후속 미팅이 잡히고, 이러면 2주일 정도 본사 친구들과 해야할 일들에 대한 충분한 의견 교환이 이뤄진다. 그렇다고 항상 원하는 결과가 만들어지지 못하지만, 적어도 내가 이런 생각을 가지고 있고, 그 친구들은 내 생각에 대해 어떻게 생각하는지, 이걸 바탕으로 전략을 수정할지 혹은 개발 방향을 어떤 방식으로 구체화할 것인지를 한국 팀 내부에서 논의할 수 있다.

미팅은 한국식 미팅과는 거리가 멀다. 대부분 기본 미팅 시간은 30분이다. 물론 격론이 오가거나 화제꺼리가 많으면 시간을 초과하는 경우도 생긴다. 이런 일이 예상되는 경우 드물게 1시간 미팅을 잡기도 한다. 종종 10분, 15분만에 “아, 그거였구나!” 하면서 싱겁게 마무리 되는 경우가 많다. 시간을 초과하는 경우도 있다. 이러면 “정리가 된건야 만거야??” 싶게 아리송하게 마무리된 미팅이 되어 버릴 수 있다. 출장와서 잡은 미팅을 의미없이 날려버리지 않을려면 핵심되는 이야기 중심으로 이야기하고, 시간 관리를 타이트하게 해야한다.

어느 정도의 이슈가 의견이 교환했기 때문에 다음 내용 정리는 슬랙이나 이메일로 이뤄진다. 손쉽게 이슈가 정리된다면 실행 아이템을 Jira ticket으로 만들거나 Favro Card로 만들어두고 멘션(Mention) 해준다. 이러면 그 일이 어떻게 굴러가는지 나도 트래킹을 할 수 있다.

물론 대부분 미팅에서 회의록을 작성한다. 본사 친구들이 작성하는 경우에는 대부분 회의하면서 문서를 작성한다. 물론 한국에서 출장간 사람들이 작성하는 경우도 있긴 하지만 미팅이 끝난 후 기억을 더듬어 적는 편이다. 나를 포함해 같이 출장을 가는 친구들은 두어명을 빼고는 토종 한국인이기 때문에 듣고 말하는 것만으로도 벅차다. 그나마 회의록을 작성한다는 것만으로도 예전에 비하면 장족의 발전이라고 생각한다. 한국에서도 미팅하면 회의록을 작성할려고 하지만, 특히 출장와서 진행하는 미팅에서는 일종의 Evidence 차원에서도 우리가 이런 이야기를 나눴다라는 사실을 기록할 필요가 있다.

Google docs로 작성된 회의록은 전체 Share로 관련된 사람들에게 전달한다. 회의에 참석한 사람들 뿐만 아니라 다른 관심있는 사람들도 문서를 볼 수 있어야 한다. 그래야 논의된 이슈와 결과/결정에 대해 누구든 확인할 수 있고, 필요한 경우에 코멘트를 붙여가면서 추가적인 정리가 이뤄질 수 있다. 처음에는 특정한 몇몇 사람들을 찍어서 보냈었다. 하지만 본사 친구들처럼 열린 커뮤니케이션이 되려 회의 내용이 정보로써 팔딱팔딱 숨쉬게 만들어 준다는 걸 느끼게 되서 1~2년 전부터는 특별한 경우가 아니라면 코멘트 가능한 전체 공유 링크로 전달한다. 물론 굳이 회의 내용을 안봤으면 하는 친구까지 보는 바람에 의미없는 논쟁이 생긴적도 있긴 하지만, 이 과정을 넘어서면 논쟁한 본사 직원도 어느새 친구가 된다.

오전 미팅이 있는 경우에는 거의 이 미팅 하나로 오전을 채운다. 없다면 밤사이 한국에서 온 메일들을 보거나 출장과 관련된 코딩 작업을 진행한다. 개발자는 출장전에 출장의 목표를 설정하고, MVP(Minimum Viable Product)를 정한다. MVP를 달성하기 위한 수단으로 회의나 담당자를 만나러 다닌다고 보면 된다. 특히나 한국에서 본사 시스템/플랫폼과 관련된 개발을 하는 경우, 17시간이라는 시차 문제 때문에 제대로 지원받지 못한다. 몇 년이 흘러도 이 부분은 어떻게 개선이 안된다. 그래서 출장을 오가고, 이 기간을 통해 해결되는 경우가 많다.

아무리 본사 친구들이 문서를 잘 만든다고 하더라도 항상 문서는 코드를 따라오지 못한다. 같은 시간대에 있고, 책상이 바로 옆자리에 있는데 굳이 문서를 볼 필요가 뭐가 있나? 걍 그 친구한테 잠깐 책상으로 가도 되겠나 물어보고 이것 좀 이상한거 같은데 봐달라고 하면 대부분 기꺼운 마음으로 대답해준다.

얼추 점심 시간이 되면 회사 구내 식당으로 가서 밥을 먹는다. 밖에 나가서 먹으면 이동하는 시간도 많이 들 뿐더러 오후에 미팅이 있는 경우에는 서둘로 돌아와야 한다.  더구나 구내식당보다 맛있으리라는 보장도 거의 없다. LA 로컬 음식을 몇 번 먹어봤지만, 그나마 캠퍼스의 식당이 평균 이상이다. 그리고 언제나 김치가 있다!! 의외로 맛이 있다. 특정 팀과 관련된 일을 주로 하는 경우에는 종종 해당 팀과 점심을 먹는다. 가장 어려운 영어가 생활 영어다. 용어 자체도 기술 용어를 한참이나 벗어난 이야기들을 하는데… 열심히 듣고, 열심히 밥을 먹는다.

오후에 대부분의 미팅이 몰려있고, 3개 정도 제대로 컨퍼런스 룸에서 회의를 마치고나면, 공허할만큼 기운 빠진다. 빌지 카페에서 커피를 충전해도 마지막 미팅쯤이면 말이 잘 안나온다. 더구나 잠을 잘 못잔 경우에는 내가 생각하기에도 듣는 친구들에게 민망할 정도로 말이 꼬인다. 정책이나 상황을 설명해야 하는 미팅의 경우에는 매우 많이 난감하다. 하지만 기술 미팅의 경우에는 말로 하다 안되면 화이트보드를 이용하면 된다. 화이트보드 없는 회의실이 없으니까.

개발자들끼리도 말만 가지고 시스템이나 서비스의 동작을 설명하는건 어렵다. 한국말로 해도 어려운데, 그것도 살짝 정신줄 놓은 영어로 하는 판이니… 일면식 없는 상대끼리 얼마나 갑갑하겠는가? 이럴때 유용한 물건이 화이트보드와 노트북(랩탑말고)이다. 네모, 동그라미, 그리고 선. 이게 대부분이다. 좀 더 고급진 그림에는 실린더도 등장하지만. ㅎㅎ

모든 미팅을 마치면 잠깐 쉬었다가 미진했던 코딩을 하거나 미팅에서 나온 내용들을 확인하한 작업을 한다. 특히나 미팅에서 논의된 내용들이 MVP 관련 사항이고, 막혔던 부분들에 대한 것들이라면 정말 즐겁다. 특히 권한 때문에 진행이 안되던 경우, 미팅에서 “어, 그래? 그거 내가 주께~ 근데 그거 누가 못준다고 해?, 아… 그 친구 원래 그래. 미팅 끝나고 개발자 권한 줄테니까 함 해봐, 슬랙으로 핑줄께!” 이런 이야기들이 오고 갔다면 정말 좋다. “원래 그런” 친구들은 어디에나 있다는 걸 새삼 깨닭는다.

코딩 작업을 하다보면 저말 잘 이해가 안되는 부분들이 생기기도 한다. 뭐 찬찬히 보고 관련된 다른 부분들을 공부한다면 충분히 답이 나오겠지만, 출장 기간은 짧다. 지금 이 지점에서 이 길이 맞다라는 걸 확신하지 못하고 한국으로 돌아가면 몇 일 걸릴 일이 몇 달이 걸린다. 당장 궁금하기도 하고 해결해야 할 일이기 때문에 미팅한 친구한테 핑 때리고 데스크로 간다. 옆에 붙어서 막힌 코드를 보여주고, 내가 원하는 것과 현재 코드의 문제점을 확인한다. 대부분 마법같은 환경 설정에서 뭔가가 빠졌거나 권한 부족이다.  거의 대부분은 그 친구의 자리에서 해결된다. Damn!!

저녁이 되면 LA의 교통은 정체 지옥으로 변한다. 오후 4시부터 시작된 정체는 7시 반까지는 최소 이어진다. 처음 출장왔을 때 정체는 5시 반부터 시작됐고, 밀려도 서울 정도는 아니었는데 요즘은 15분 걸려오는 호텔을 45분, 1시간 걸려 도착한다. 저녁 먹으로 아예 4시 근방에 출발할게 아니라면 대부분은 근방 소텔이나 “우버 이츠(Uber eats)”로 해결한다. 최소 3일에 한번, 저녁은 한식을 먹는다. 소텔에 있는 순두부집에서 저녁을 많이 먹었는데, 사람들이 질려한다. -_-;;;; 우버 이츠라는 신세상을 발견한 다음에는 K타운 갈 일이 더욱 없어졌다. 굳이 그 오래 걸리는 길을 차타고 갈 이유가 없으니 말이다.

보통 퇴근은 캠퍼스에서 밥을 먹는 경우에는 8시쯤 퇴근한다. 밥도 먹고 밀리는 순간도 피하고. 이렇게 돌아와서 씻고 뻣으면 그대로 잔다. 그대로 잘 수 있다면 상당히 행복한 케이스다. 뒤척이다가 맥주 한잔? 와인 한잔 하는 파티와 어우리게 될 수도… 물론 분위기 좋은 바에가서 먹는 경우는 없다. 대부분 호텔방에서 어울려서 먹는다. 주인장이 되버린 방 주인은 다음날 크리링을 신청해야겠지만. 처음 출장와서 한동안은 술을 마시면 그나마 잠을 자는데 도움이 됐지만 지금은 이래도 그만 저래도 그만이다. 어떤일이 생겨도 아침에 일어나는 시간은 약속의 그 시간이기 때문에 되려 늦게까지 이야기하느라 잠을 못자면 다음 날이 더 힘들다.

이렇게 일정을 마쳤으면 이제 방으로 돌아와 잠을 청한다. 여러 음악앱을 깔아서 써봤는데, 내 취향을 알아주는(??) 뮤직을 틀어주는 앱은 유투브인 것 같다. 김광석 노래나 클래식 10곡 깔아놓고 잠을 청한다.

주말을 낀 출장의 경우, 대부분은 잔다. 잘 수 있을때까지 잔다. 12시간 이상 침대와 몰아일체가 되어 있으면 허리가 끊어질 정도로 아프다. 연속으로 이렇게 잔적은 없지만, 드문드문이라도 이정도 자면 그나마 괜찮다. 적당히 깬 후 호텔 비스트로에서 커피 한잔 먹은 다음, 저녁 먹으로 간다. 보통 주말은 K타운 고기집에서 하루 한끼 먹는 식사를 해결한다. 이렇게 먹고 나면 다음 날 일요일도 12시간 이상 잘 수 있다. 물론 이렇게 잔다고 하더라도 항상 새벽 3, 4시에는 뭔 약속이라도 한 것처럼 귀신같이 눈이 떠진다. 하루 한끼가 말이 되냐고 할지 모르지만 잘 수 있을 때 자는게 그 다음 주의 시간을 위해 꼭 필요하다.

이렇게 평일의 출장 일상은 이렇게 흘러간다. 주말이 끼지 않은 출장의 경우에는 금요일 밤이나 토요일 아침에 한국으로 출발하는 비행기를 탄다. 어찌됐든 한국에 돌아와서 랜딩하는 순간, 넘 기분이 좋다. 참 신기한 일이지만, 집에 와서 김치찌개랑 소주 한잔 먹고 잠자면 그 못자던 잠이 한꺼번에 쏟아진다. 10시간 가까이를 논스톱으로 잔다.

출장후에는 출장에서 논의된 이야기들을 내부적으로 가능한 빠르게 공유하고, 그 다음 스텝을 F/U해야 한다. 망각의 동물이 사람이다. 나도 까먹지만, 본사에서 나랑 미팅한 그 친구들도 까먹는다. 후속 작업이 바로 이어질 수 있도록 해야지 본사에서 미팅한 내용들이 자연스럽게 이어져 결과로 매듭될 수 있다. 다음 한주는 지난 주 출장의 내용들을 공유하고, 어떤께 후속 작업을 진행할지 팀에 있는 친구들이랑 이야기해야 한다. 마무리와 새로운 시작을 잘 하자.

– 끝 –

일 시킴 당하기

Posted by on

매니저이긴 하지만 개발자다. 각자 해야할 일들이 많다. 하지만 일의 우선 순위는 매니저로써 혹은 리더로써의 일들이 항상 높은 우선 순위를 가진다. 심적으로는 코딩을 하고 싶다. 그리고 코딩하면서, 로직의 흐름에 몸을 맡기고 있으면 아무 생각도 없다. 하지만 종종 이런 몰입 상태를 유지하다가는 정작 팀의 결정 사항들이 뒤로 밀려지거나 처리할 문서들이 한가득 쌓인다. 결국 우선 순위는 팀에 영향을 미칠 수 있는 일들이 먼저다. 코딩과는 거리가 있는 ㅠㅠ

하지만 팀에서 개발자로써의 지분을 가지고 있기 때문에 해야만 하는 코딩도 있다. 까먹거나 방만해질 때 “일로써 코딩“을 해야한다. 나름 부지런하다고 생각하지만 놓친다. 하지만 옆에 나보다 더 부지런한 친구들이 있다. 내가 다른 일을 하고 있거나 띵가띵가 거리고 있다가 그 친구들이 함께 놀지 않는다. 각자의 일 스타일로 계속 결과를 만들어낸다. 나의 결과가 그들의 결과와 합쳐져야 제대로 된 시스템을 완성할 수 있다. 앞서 나가는 코드 결과를 PR로 받아봤을 때, 나도 그들에게 PR을 보내고 싶다. 즐거운 자극이고, 상당한 압박이다.

본사 출장중에 여러 풍경들이 있지만, 가장 내가 좋아하는 풍경이다. 비록 코딩을 했던 건 아니지만, 이제 코딩을 할 수 있다. 즐거운 마음으로 PR을 만들어야지. “워크홀릭(Workaholic)”이라지만 당장은 일에서 즐거움을 찾을 수 있으니 것도 나쁘지 않다. 주 52시간이 실행되면 이것도 쉽지 않을테니 즐길 수 있을 때, 즐기자.