알라딘MGG와이드바


레거시 코드 활용 전략/오역표 입니다.

백만년만에 포스팅입니다.
AnD 스터디에서 진행했었던 '레거시 코드 활용 전략' 오역표 링크가 날아가서 블로그에 다시 옮겨놓습니다.
이거 덕분에 에이콘 부사장님이 직접 저를 찾아와서는 xUnit Test Patterns 를 번역하기도 했었네요.
그것도 2010년 일이니 까마득합니다.
여기 오역표는 스터디 멤버들과 같이 만든 것이고 지금 다시 읽어보면 오역표에 오역이 있을 수도 있으나 그 당시 자료를 그대로 복원해 올려놓겠습니다. 

감사의 글

  1. 제 삼촌 마틴 - 7
    1. 엉클 밥, 로버트 마틴
    2. 엉클 밥은 로버트 마틴의 별명, 저자의 삼촌이 아님
  2. 중요하지 않은 사람으로 부터 비판적인 것을 분리시키는 일 - 7
    1. 중요한 것과 사소한 것을 분리하기

저자 서문

  1. 응. 지금 레거시 코드를 작성하는 중이야 - 9
    1. 컨설팅하러 와서 보니까, 다들 레거시 코드만 만들고 앉아있어
    2. 친구가 레거시 코드를 작성 하는게 아님
  2. 레거시 코드에서는 몇단계를 거치면 다다르게 되는 것이다 - 12
    1. 레거시 코드에서는 전혀 별개의 과정을 거쳐야 좋은 디자인에 다다른다
    2. but in legacy code, it is something that we arrive at in discrete steps.

1장. 소프트웨어 변경

  1. 만약 담당부서 사람들이 변경하고 싶다는 의사를 철회한다면, 우리는 벌써 이 일을 끝냈을 것이다 - 30
    1. 그 사람들이 마음을 자꾸 바꿔먹지만 않았어도, 벌써 일을 끝냈을 것이다
    2. 잦은 요구사항 변경으로 일정이 늦어지고 있다는 의미
  2. 사람들이 작업할 때는 새로운 특징을 추가하건, 혹은 버그를 수정하건 간에 우리는 끊임없이 바꿀 수 있으나 이는 단지 코드나 다른 인공물을 변화시키는 것에 국한된다 - 30
    1. 사람들 끼리는 기능추가로 부르든 오류수정으로 부르든 언제든 바꿔 부를 수 있지만, 이런 작업들은 사람에 관련된 작업이 아니라 소스코드와 산출물을 변경하는 작업이다
    2. At the people level, we can go back and forth endlessly about whether we are adding features or fixing bugs, but it is all just changing code and other artifacts
  3. 동작은 소프트웨어에 있어서 가장 중요한 요소로 사용자는 바로 이 동작을 따르게 된다 - 30
    1. 동작은 소프트웨어에 있어서 가장 중요한 요소로, 사용자는 바로 이 동작을 따르게 된다
    2. 쉼표 추가. 원문은 두 문장인데 한 문장으로 만들었으니, 쉼표를 추가하자.
  4. 반대로 그들이 사용하고 있는 동작을 변경하거나 삭제하면 버그가 생길 수도 있으므로 - 30
    1. 버그 때문에 잘 쓰고 있던 동작이 바뀌거나 사라진다면
  5. 우리가 만일 코드(HTML과 같은 코드)를 수정해야 한다면 동작까지 변경시킬 수 있다 - 31
    1. 코드(HTML도 코드로 취급한다)를 수정했다면 동작도 변경 됐다고 볼 수 있다
  6. 어떤 조건을 위반 했는지를 - 35
    1. 뭔가 망가트리지 않았는지를
  7. 위반이 아니면 고치지도 말라 - 35
    1. 고장나지 않았으면 고치지 마라

2장. 효과적인 피드백 활용

  1. 나는 이 원인들을 '편집하고 기도하기' - 37
    1. 나는 이 방법들을 '편집하고 기도하기'
  2. 덮고 수정하기 - 37
    1. 감싸고 수정하기
    2. cover - 덮다, 감싸다, 보호하다, 엄호하다.
    3. 감싸서 보호한다는 의미
  3. 계획을 세우고 - 37
    1. 계획을 주의깊게 세우고
  4. 계획에 반하는 사항이 - 37
    1. 뭔가 망가트리지 않았는지
  5. 개인 시간을 투자해서라도 - 37
    1. 추가 시간을 투자해서라도
  6. 여러분이 주의를 기울이면 표면적으로 여러분이 바라는 목적지로 인도해줄 것이다 - 37
    1. 가장 중요한 핵심 바로 그곳에 "주의"를 기울여야 한다
    2. The "care" that you take is right there at the forefront
  7. 하지만 이렇게 얻는 피드백을 통해 우리는 좀더 꼼꼼히 - 38
    1. 같은 양의 주의를 기울이면서도, 피드백을 함께 활용하면, 우리는 좀더 꼼꼼히
    2. We still apply the same care, but with the feedback we get, we are able to make changes more carefully
    3. 문장 일부분 번역 빼먹음 - We still apply the same care,
  8. 테스트 자체가 좋은 목적일 수도 있고 - 38
    1. 물론 그것만으로도 훌륭한 목표지만,
    2. 그것은 앞 문장을 의미 - "정확성을 보여주기 위한 테스트"
  9. 적용 범위 - 42
    1. 커버리지(coverage)
    2. "적용 범위"는 의미가 와닿지 않는다. 적당한 번역은 떠오르지 않음.
  10. 우리가 좀더 자주 테스트 루틴을 돌릴 경우 오류 지역화에 빠질 우려가 있다는 것이다 - 42
    1. 테스트를 자주 돌려야만 오류를 지역화 할 수 있는데, 
    2. 오류 지역화는 좋은것이다.
    3. 대규모 테스트는 시간이 많이 들어 자주 돌릴 수 없어서 좌절하게 된다는 의미
  11. 테스트 루틴에는 연속되는 부분이 있게 마련이다 - 42
    1. 보통은, 연속체가 있기 마련이다.
    2. Naturally, there is a continuum
    3. continuum - 다른 여러 클래스를 사용하는 덩치 큰 클래스를 "연속체"라고 이름 붙인 듯 함
  12. 시간이 1/100로 줄어든다면 - 43
    1. 시간이 1/100로 줄어든다면
  13. 테스트 덮개 - 44
    1. 테스트로 감싸기(Test Coverings)
  14. 이것을 생성하는 것은 매우 쉬운 일이다 - 45
    1. 이것을 생성하는게 쉬울까?
    2. How easy will it be to create one of those?
    3. 쉽지 않고 오히려 어렵다는 의미
  15. 우리는 서블릿을 매개변수로 받지 않도록 코드를 수정할 수 있다 - 45
    1. 경우에 따라 서블릿을 매개변수로 받지 않도록 코드를 수정할 수 있다
    2. 뒷 문장에 나오는 조건을 만족할 경우에 수정 가능 하다는 의미
  16. 제자리 - 46
    1. 적절한 자리에
    2. in place - 적절한 자리에, 적소에
  17. 침습성(스며들어 젖는 성질) - 47
    1. 침습적(공격적이라 해가되는)
  18. 덜 보수적이라면 그 부분을 즉시 고칠 것이다 - 48
    1. 덜 보수적이라면 그 부분을 별 생각없이 바로 고칠 것이다
  19. 4줄 삭제
    이렇게 하면 더 이상 서블릿을 받지 ... 확인하려면 정확한 테스트가 필요하다. 
    1. 이 내용은 45p 그림 윗부분에 있는 내용이다. 글자는 조금 다르지만 내용은 같다. 삭제하자.
    2. 추측하면 copy & paste 실수로 이전 페이지 내용이 엉뚱한 곳에 틀어박혀 있는 것이다.
    3. c&p는 코딩할때만 합시다.
  20. 하지만 이것은 그 위험도에 따라 다를 수 있다 - 47
    1. 가능하지만, 위험도가 얼마나 되는지 따져봐야 한다.
    2. We can do that, but it depends upon how much risk is involved
    3. 문장 일부분 번역 빼먹음 - We can do that,
  21. 오류가 큰 문제이거나 일상적이라면 경우에 따라 알맞은 대응을 해야 할 것이다 - 47
    1. 오류가 크게 문제가 될 때면, 보통의 경우 오류는 큰 문제인데, 그럴때는 보수적으로 신중해져야 한다.
    2. When errors are a big deal, and they usually are, it pays to be conservative.
  22. 레거시 코드에서 하루하루의 목표는 변경 자체가 아니라 변경시키는 행위이다. 각 프로그래밍 에피소드의 - 48
    1. 레거시 코드에서 하루하루의 목표는 변경이다. 하지만, 변경만으로 끝나서는 안된다. 우리는 기능적 변경을 함으로써 제품에 가치를 추가하는 동시에 테스트에 보호받는 부분이 더 많아지도록 시스템을 고쳐야 한다.
    2. The day-to-day goal in legacy code is to make changes, but not just any changes. We want to make functional changes that deliver value while bringing more of the system under test.
    3. 문장 하나를 완전히 빼먹음.
    4. 어색한 부분이 발견되면 원문을 참고하면 되지만, 문장을 아예 빼먹는건 답이 없다.
  23. 혹 그런 기법들을 사용하길 원한다면 관련 서적을 참고하길 바란다 - 50
    1. 그런 기법들을 사용할 기회가 오면, 반드시 적용해 보길 적극 추천한다
  24. 설계를 어떻게 하면 잘 하는지를 보여줄 것이다 - 50
    1. 어떻게 하면 더 나은 설계로 개선하는지 보여줄 것이다
  25. 이때의 잘 이뤄진 설계는 문맥 종속적이고 종종 이전 설계보다 몇 개의 관리 가능한 단계를 더 가지게 된다 - 50
    1. "더 나은"이란 의미는 상황에 따라 다른데 이전 설계보다 운영 개선하기가 몇 단계 정도 쉬워졌다는 것을 의미할 때가 많다.
    2. where "better" is context dependent and often simply a few steps more maintainable than the design was before.

3장. 감지와 분리

  1. 감지: 언제 코드가 계산하는 값들에 접근할 수 없는지를 감지하기 위해 의존관계를 제거한다 - 52
    1. 탐지 확보 - 코드가 변경하는 값에 접근 하지 못할때, 탐지하기 위해 의존관계를 깨트린다
    2. Sensing - We break dependencies to sense when we can't access values our code computes
    3. Sensing 과 sense 구별하는게 좋지 않을까?
  2. 분리: 언제 코드를 테스트 하니스에 넣어 실행할 수 없게 되는지를 구분하기 위해 의존관계를 제거한다 - 52
    1. 분리 확보 - 테스트 하니스에 넣어 실행할 코드 조각을 얻지 못할때, 분리하기 위해 의존관계를 깨트린다
    2. Separation - We break dependencies to separate when we can't even get a piece of code into a test harness to run
  3. 하지만 테스트할 때는 sale 클래스가 객체를 FakeDisplay로 여겨야 한다 - 58
    1. 하지만 테스트 코드에서는 FakeDisplay 객체로 취급해야 한다

4장. 봉합 모델

  1. 봉합
    1. 이음매(seam)
    2. 이동현(jeddli)(http://jeddli.tistory.com/)님이 적절한 단어를 골라 주셨습니다. 
  2. 봉합 : 봉합(seams)은 프로그램 안에서 동작을 변화시킬 수 있는 위치를 말한다. 이때 동작을 변화시키기 위해 코드를 편집할 필요는 없다. - 64
    1. 이음매(seams)는 그 위치의 코드를 변경시키지 않으면서 프로그램의 동작을 변화시키는 위치를 말한다.
  3. 자, 그러면 CAsyncSSlRec 클래스를 하위클래스하고 PostReceive 메소드에 덮어쓰면 어떨까? - 64
    1. 자, 그러면 CAsyncSSlRec 클래스를 하위클래스하고 PostReceive 메소드를 오버라이드(override)하면 어떨까?
    2. override를 덮어쓴다고 번역하기 보다 영어 용어를 그대로 사용하는게 이해가 더 쉽다.
  4. 불명확한 버그를 숨기기 위한 매크로를 만들기도 하는데 이런 일은 쉬운일에 속한다 - 68
    1. 매크로를 작성할때 엄청나게 찾기 어려운 버그를 만들기 쉽다
  5. 참조를 분해할 때 어떤 방법을 사용하든 간에 - 71
    1. 사용중인 언어가 참조를 해석하는데 어떤 방식을 사용하든 간에
  6. 전처리 봉합과 연결 봉합은 의존관계에 침습성을 가지고 있다. 따라서 대안이 없는 경우를 감안해 이를 남겨 놓을 것이다 - 81
    1. 전처리 이음매와 연결 이음매는 일단 사용을 미뤄두고, 의존관계가 널리 퍼져 더 나은 대안이 없는 경우에 사용한다

5장. 레거시 코드를 위한 도구

  1. 이런 종류의 작업은 좀 더 정확히는 통합 테스트를 위한 프레임워크와 적합성 영역이다 - 93
    1. 이런 종류의 작업은 FIT와 Fitness의 영역이라 보는게 더 적절하다

6장. 고칠 건 많고 시간은 없고

  1. 날짜를 게시하고 새로운 항목을 추가하기 전에는 그 새 항목이 - 100
    1. 날짜를 게시하고 새로운 항목을 추가하기 전에 그 새 항목이 ('는' 삭제)
  2. 침투성 - 101, 109
    1. 침습적
  3. 여기서는 지불을 기록할 필요가 있는 한 부분에 LogPayDispatcher 클래스를 생성했다 - 118
    1. 이제 지불을 기록해야할 곳에서 LogPayDispatcher 클래스를 생성할 수 있다

7장. 코드 하나 바꾸는 데 왜 이리 오래 걸리지?

  1. 그림에는 나타나 있지 않지만 그 두 클래스가 서로 종속되어 있는 경우라면 더 좋다고 할 수 있다 - 126
    1. 두 클래스 모두 그림에 나오지 않은 또 다른 클래스들에 의존하고 있을 가능성이 크다
  2. 다음에 ConsultantSchedulerDBImpl, AddOpportunityFormHandler를 수정할 때는 재컴파일할 필요가 없다 - 127
    1. 이제 ConsultantSchedulerDBImpl를 수정해도, AddOpportunityFormHandler는 재컴파일할 필요가 없다

8장. 특징, 어떻게 추가할까?

  1. 비교를 통한 프로그래밍 - 140, 148, 151
    1. 차이에 의한 프로그래밍(Programming by Difference)
  2. 의존관계 - 140, 149 등
    1. 상속
  3. 하지만 의존관계를 사용한다는 것 자체가 반드시 제자리 의존관계를 유지해야 한다는 뜻은 아니다 - 140
    1. 하지만 상속을 사용했을때, 제대로 올바르게 상속을 사용했다고 장담 할 수 없다.
    2. But just because we use inheritance initially doesn't mean that we have to keep it in place.
    3. 이 문장의 주어는 과연 무엇일까? 이 문장은 과연 깔끔한 영어 문장일까? 미국애들이 볼때 문장구조나 의미가 명확할까?
  4. 오버라이딩하는 메소드 안에 있는 현재 오버라이딩하려는 메소드를 호출할 수 있는지 확인한다 - 150
    1. 오버라이딩 메소드에서 오버라이드 되는 메소드를 호출할 수 있는지 확인한다
  5. 가끔씩 일어나는 추상적인 오버라이드는 - 151
    1. 가끔씩 일어나는 구체(concrete) 오버라이드는

9장. 뚝딱! 테스트 하니스에 클래스 제대로 넣기

  1. 코드를 변화시키는 일은 참 어려운 일이지만 멋진 작업이기도 하다 - 153
    1. 이는 정말 어렵다
    2. This is the hard one
    3. 9장 제목의 작업이 어렵다는 의미 (테스트 하니스에 요놈의 클래스를 못 집어넣겠어요!)
  2. 테스트 하니스에서 클래스의 구체적 예를 드는 것은 쉬운 일이지만, 불행하게도 얇은 이 책을 통해 제시하기란 결코 쉬운 일이 아니다 - 153
    1. 테스트 하니스에서 클래스의 인스턴스를 만들기가 쉽다면, 이 책은 무척 얇아졌을 것이다
  3. 테스트 하니스는 그 안의 클래스와 함께 쉽게 만들어지지 않는다 - 153
    1. 여러 클래스들을 엮어 테스트 하니스를 만들기는 쉽지 않다
    2. The test harness won't easily build with the class in it
  4. 구조 - 153, ...
    1. 생성자(constructor)
  5. 그리고 제자리 테스트 안에 둘 필요가 있겠네 - 153
    1. 그리고 당연히 테스트 하니스 안에 집어 넣어야지
  6. 에이, 이것은 이 클래스 상에 있는 가장 단순한 생성자로 3개의 매개변수를 받는 것 같은데, 생성하기도 어렵지 않겠네 - 154
    1. 세상에, 제일 단순한 생성자도 파라미터가 3개나 되네. 하지만, 생성하기가 그렇게 어렵지는 않을거야
  7. 단지 방어적인 것이었는지 - 154
    1. 단순히 방어 심리였는지
  8. 클라이언트가 유효한 신용을 갖고 있는지 - 154
    1. 고객의 신용이 유효한지
  9. 클라이언트들이 얼마나 많은 신용을 갖고 있는지를 - 154
    1. 고객이 어느 정도의 신용을 갖고 있는지
  10. 우리는 왜 그것이 최상이고 쉬운지(혹은 어려운지)를 알아내기 위해 수 차례 분석했다. 하지만, - 154
    1. 생성하기 쉬운지 어려운지 알아내기위해 엄청나게 분석해도 되긴 하지만,
    2. 분석하지 말고 그냥 코딩해서 컴파일 에러가 나는지 보라는 의미
  11. 구조 - 154, ...
    1. 생성(construction)
  12. 따라서 이 테스트 하니스에서 이 클래스를 획득하는 것은 다소 쉬워 보이는데 정말 그러할까? - 156
    1. 그래서, 테스트 하니스에 이 클래스를 생성하기는 쉬워보인다. 그렇지 않나?
  13. 실제로 그리 빠르지는 않다 - 156
    1. 너무 서두르지 마라
  14. 서버에 RGHConnections를 구축하는 것은 좋은 생각이 - 156
    1. 서버에 RGHConnections 연결 접속을 하는 것은 좋은 생각이
  15. 방법 - 156, ...
    1. 메소드(method)
  16. 그것은 RGHConnections 이 연결을 ~~~ 집합처럼 보인다 - 157
    1. 여기서 RGHConnection은, RFDIReportFor나 ACTIOReportFor 등 비즈니스 중심 메소드뿐만 아니라 connect, disconnect, retry 메소드 등 연결을 구성하는 기전을 다루는 메소드들의 집합을 가지고 있는 것처럼 보인다
    2. 에이콘 공식 정오표 참조
  17. 만듬 - 157
    1. 만듦
  18. 고약하게도 그것들이 원할때마다 누구나 설정할 수 있는 공개된 변수가 존재한다 - 158
    1. 더 고약한 사실은, 변수가 public이라 아무나 값을 변경할 수 있다는 점이다
  19. 규칙을 클래스와 달라 테스트를 가능하게 한다 - 158
    1. 클래스를 테스트 가능하게 만들때 적용하는 규칙은 기존의 코딩 규칙과 다르다
  20. 제작 코드 - 158, ...
    1. 제품 코드(production code)
  21. (문장누락)
    1. 책을 덮어버리진 않으셨겠죠?
    2. Are you still there?
  22. 그렇다면 시스템 안에서는 항상 그 작업이 수행되겠군 - 159
    1. 우리가 맨날 하는 짓이군
    2. 기존 시스템이 엉망이라 파라미터에 null을 넘기는 짓을 자주 한다는 의미
  23. 실제로 하나의 객체를 갖는 동작이 필요하다면, 당신은 그 지점에서 객체 하나를 생성한 후 - 160
    1. 동작하는데 정말로 객체가 필요하다면, 그때 가서 객체를 하나 생성한 후
  24. 선택할 수 있다면 제작 코드에서는 - 160
    1. 다른 선택의 여지가 없는 경우가 아니라면 제품 코드에서는
  25. 어떤 라이브러리들은 그렇게 하도록 기대하지만, 차라리 새로운 코드를 작업하는 것이 더 효과적이다 - 160
    1. null 값을 넘겨야하는 라이브러리도 있다는 사실을 알고 있지만, 새로운 코드를 작성할 때면 더 나은 대안을 찾아야 한다
  26. 제족 코드에서 널을 사용하려 한다면 널이 되돌아오고 널을 전달시킬 곳을 찾고, 다른 프로토콜을 고려하자 - 160
    1. 제품코드에서 널을 사용하고자 하는 유혹이 느껴진다면, 널을 리턴하거나 전달하는 곳을 찾은 다음, 다른 방식(protocol)의 사용을 고려해보자
  27. 위 코드는 클래스의 생성자 코드 중 일부분이다 - 162
    1. 이제 클래스 생성자의 일부를 살펴보자
  28. 커서를 만들기 위해 사용한 코드는 모두 클래스 외부로 옮길 수 있다 - 166
    1. 커서를 만드는데 사용한 코드를 모두 클래스 밖으로 옮기려 시도해 볼 수도 있다
  29. 그러나 테스할 곳이 없다면 이는 안전하지 못하고, - 166
    1. 그러나 적절한(in place) 테스트가 없다면, 이는 안전하지 못하고
  30. 파기 - 167, ...
    1. 갈아치움(supersede)
  31. 제작 코드에서 파기 방법은 - 167
    1. 제품 코드에서 갈아치움 메소드
  32. 다른 자원을 관리하는 것을 파기하는 객체가 있다면 이는 심각한 자원 문제를 일으킬 수 있다 - 167
    1. 우리가 갈아치운 객체가 다른 리소스들을 관리했다면, 심각한 리소스 문제가 생길지도 모른다
  33. 우리는 느낄 필요가 있기에, - 168
    1. 우리는 탐지(sense)해야 하기 때문에,

14장. 우릴 미치게 하는 라이브러리 의존관계

  1. 좋은 코드는 제작이나 테스트 환경 내에서 수행된다는 - 260
    1. 좋은 코드는 제작 환경과 테스트 환경 양쪽 모두에서 실행된다는

서든어택2가 선정성 논란 캐릭터들을 삭제한다고 한다. 게임 이야기


서든어택2에서 선정성 논란이 되고 있는 '미야', '김지윤' 캐릭터를 삭제한다고 한다.
아직 공식 홈페이지 캐릭터 소개란에는 남아 있다.

게임 트릭스 순위를 보면 서든어택2는 2016년 7월 13일 현재 10위권 밖으로 밀려났다.
(2016년 7월 8일부터 7위 -> 8위 -> 8위 -> 10위 -> 10위권 밖. 단, 서든 어택은 여전히 4위다.)


과연 서든어택2가 5위권 안에서 히트치고 있었더래도 이런 조치를 했을지는 의문이다. 한국 사회가 성숙해 지는 속도를 게임이 따라가지 못해 생긴 결과로 보여 아쉽다. 서든어택2가 문화를 선도해 나갈 수 있었더라면 좋았겠지만 이정도 대규모 팀이 개발하는 게임은 헐리우드 영화처럼 기존의 성공 공식을 쉽게 버리기 어렵다. 결과적으로는 이게 함정이 된 셈이지만...

게임에서 선정적인 여성 캐릭터가 완전히 사라지지는 않을 것이다. 그래도 이번 일은 한국 게임 개발에서 하나의 분기점이 될 만하다. 캐릭터를 만들 때마다 여성 유저에게 불쾌감을 주지는 않을지 한 번 생각하는 계기가 되리라 본다.

엔씨소프트 블로그에 올라온 '블소, 북미에 가다 #2 양성평등을 둘러싼 말말말'에도 꼭 읽어보자.


[아꿈사] 2016년 7월 19일 오후 7시 판교에서 여름모임 합니다. 모임

[아꿈사] 2016년 7월 19일 오후 7시 판교에서 여름모임을 갖습니다.
아꿈사 네이버 카페에서 댓글로 참가신청해 주시면 됩니다.

라인에서 테크니컬 라이터로 계시고 '웹 기획자가 알아야 할 서비스 글쓰기의 모든 것'의 저자 중 한 분이신 이인실 차장님이 '엔지니어가 자주 틀리는 표현. 네이버와 라인의 문서 공유와 관리, 라인에서 하는 일'을 주제로 강의하십니다.
그리고 이수안님이 'TensorFlow를 활용한 머신러닝 기초'를, 최성기님도 웹서버 관련된 주제로 강의합니다.
그 외에도 발표하고 싶은 게 있는 분들은 발표신청해 주시면 됩니다.

그리고 판교 쪽에서 10-20명이 저녁 7시에 모일 수 있는 장소를 섭외 중입니다.
판교에는 토즈 같은 게 없어서 스터디 모임하기가 영 어렵네요.
좋은 장소 있으면 알려주세요. 감사합니다.
 



'왕좌의 게임' 시즌 6에 출연한 아역 배우 Bella Ramsey(스포일러 없음) 사는 이야기

왕좌의 게임 시즌 6에 눈길을 끄는 아역배우가 한 명 나온다. 12세 배우인 Bella Ramsey는 북부의 Bear Island의 지도자인 Lyanna mormont 역할을 맡았다. 스토리 흐름으로도 그렇고 연기도 굉장히 인상적이라 기억에 남았다. 나뿐만 아니라 다른 사람들도 좋아했나 보다.


사람들이 이 배우를 좋아한다는 걸 알게 된 George RR Martin의 트윗이 인상적이다.

거의 데스노트 급이라 다들 댓글로 No라고 외치고 있다.

이 분은 전에도 이런 사진을 올리더니 등장인물 죽이는 거에 재미들린 거 같다.

어쨌거나 시즌7에서도 출연할 듯하니 기대된다.


'이상한 모임' 이모콘 720 후기 모임

'이상한 모임' 이모콘 720 후기
발표자료는 Google Space에서 확인 가능하다.

주말 컨퍼런스가 얼마만인지 모르겠다. 게다가 전혀 모르는 모임이라 더 설레고 떨리더라. 여러가지 이유로 외부 활동을 줄였더니 가벼운 우울증이 찾아와서 참여해 봤는데 굉장히 만족스러웠다. 내가 잘 접해보지 못한 웹, 앱 개발 얘기가 많아서 더 그랬을 것 같다.

이모콘 720은 '이상한 모임'이란 곳에서 주최한 라이트닝 토크 모임 컨퍼런스였다. '이상한 모임'은 제목으로부터 느껴지듯 아직은 정확한 방향성을 모르는, 혹은 일부러 잡지 않는 모임으로 보인다. IT 종사자가 거의 대부분이고 강연 발표자나 참석자 대부분이 20-30대로 보이며 게임 개발자가 굉장히 적었다는 게 나로서는 특이한 점이었다. 관심 있는 분들은 이상한 모임 슬랙에 초대 요청을 보내보는 것도 좋겠다.
720은 7분 20초간 가볍게 발표한다는 의미로 붙은 숫자다. 페차쿠차랑도 비슷해 보이나 전체 발표 시간 제한만 있을 뿐 한 장당 시간 제한은 없다. 아꿈사에서도 시도해 볼 만한 방식이 아닐까 싶었다.
OnOffMix로 150명을 신청받았고 가격이 4만원이었다. 자원봉사자가 무려 11명. 티셔츠도 다 맞춰 입고 후원(스폰서)도 받았다. 세미프로 컨퍼런스 느낌이었다. 행사 진행 면에서도 배운 점이 많았다.

발표를 들으면서 메모했던 내용을 간단히 정리해 올려본다. 기억과 짦은 메모를 가지고 정리한 것이라 잘못 써 놓은 글이 있을 수 있다.

1부
제목:웹 표준은 어떻게 돌아가는가?
웹표준에 대해. W3C (W3C의 GitHub) WhatWGECMA(자바스크립트, JSON), IETF
W3C의 조직구조 소개
권고안(Recommendation)이라는 이름처럼 표준(standard)이 나왔다고 해서 꼭 지켜야 하는 건 아니다. 대신 안 지키면 비웃음은 좀 당하겠지.

안정수 @findstar @메쉬코리아 깃헙
제목:클라우드 인프라에서 필요한 어플리케이션 관리
AutoScaling. Automate Automation.

장동현 @jgbossassa
제목:프로젝트, 외주 주실려구요?(PM)(인력소개소)
M/M(맨먼스)로 계산할 때 한 명이 한 달에 6백만원으로 10M/M라면 6천만원이 든다. 이걸 비싸다고 생각한다면 개발하지 마라.
개발자들에게 '이거 진짜 간단한 건데 구현해 줄 수 있어'라고 접근하는 사람들에게 꼭 보여주고 싶어서 발표 준비했다.
10년차 미만은 중급. 대기업은 고졸은 프리렌서로 받지 않는다.

제목:Fastlane으로 iOS/Mac 프로젝트 관리
수 백개가 넘는 앱을 관리하려면 Fastlane 같은 걸 쓰면 좋다. CI가 있는 대규모 팀이라면 꼭 이걸 쓸 필요는 없다.
-> 한 회사(스마트스터디)에서 관리하는 앱이 수 백개나 넘을 수 있다는 점에서 놀랐다.

제목:팀원 관리와 프로젝트(비 생산시간, 소통비용 줄이기)
개발환경은 최대한 좋게 만들려고 노력하고 있다. 모니터는 16:9보다 16:10이 좋다.
(컨텐츠 개발자는 위,아래로 긴 모니터가 필요하다. 개인 취향으로는 HP 모니터를 좋아한다.)
Grap은 스타벅스, 신세계에서 사용 중이다.(퇴근 중을 설정할 수 있어서 주간조, 야간조 확인하기에 좋다.)
스크럼에서의 일일 스크럼을 온라인으로 한다. 웹에 오늘 한 일, 오늘 할 일 등을 쓰면 대표인 자신이 새벽 2시까지 확인해 comment를 달아놓는다.(비동기 스크럼 같은 느낌)

김진중 @golbin (골빈해커) @야놀자
제목:관리자가 되었습니다.
나쁜 점:하는 일이 없다.(회의만 줄창. 어떤 일을 직접 해 냈다는 성취감이 없다.)
좋은 점:많은 일을 할 수 있다.(프로젝트 개발팀을 관리하는 조직을 관리하는 식으로 간접적이기는 하나)
나쁜 점:끊없는 불평을 듣는다.(여러 사람이 다양한 불만을 얘기하고, 이들 주장이 대부분 다 맞는 얘기다.)
좋은 점:시야가 넓어진다.(개발자일 때보다...)
'야놀자'를 기술 중심 회사로 만드려고 노력 중이다. 입사했을 때에는 회사가 조엘 테스트를 2개 밖에 통과 못 했지만 지금은 10개를 통과한다.

제목:툴을 이용한 비개발자들의 커뮤니케이션 관리(feat. 심장이 두근두근한 공인회계사)
Jira, 컨플루언스를 사용한다.
POC(Proof Of Concept) 진행(-> 이게 일반적으로 쓰이는 용어인가 보네)
Slack 에 RSS 피드기능이 있네.(-> 몰랐다)
컴알못인 회계사들도 약 파는 노력을 계속 했더니 어느 순간에 협업도구를 잘 사용하더라.
협업도구 관리자의 핵심 덕목:더 귀찮은 일을 안하기 위해 귀찮은 일을 한다.

제목:우리 회사의 커피는 멀쩡할까?
커피의 97%는 물, 3%만 커피다. 물 관리가 가장 중요하다.
아무 오래 전엔 열매로도 수출했으나 열매를 그대로 판매하면 재배할까봐 삶아서도 수출했다. 과육에도 카페인이 있다.
나는 하루 10잔씩 커피를 마신다. 아내가 임신했을 때에도 커피를 마셨고 9살, 6살 아이들에게도 보약 먹이듯 조금씩 주고 있다. 카페인이 몸에 안 좋다는 주장이 있지만 북유럽만 해도 에스프레소를 매일 3-5잔씩 마신다. 한국에서는 아직 커피 문화가 정착되지 않아 이런 논란이 있는 게 아닌가 생각한다.
본인에게 맞는 적당량을 찾아 마신다면 카페인을 너무 걱정하지 않아도 되지 않을까...
(-> 내가 얼마 전에 '카페인 권하는 사회'(중앙북스, 2015)를 읽었기 때문에 이 부분은 사실 잘 모르겠다.)

송요창 @totuworld @아라소판단
제목:새벽을 사는 유부남의 시간 관리
7개월(?)된 아이 아빠. 새벽 5시부터 나의 시간을 가질 수 있었다.
빨래, 밥짓기 등의 활동을 하면 뽀모도로 테크닉처럼 중간중간 쉬어줄 수 있다.
덕분에 4개월 동안 블로그 11개, 웹서비스 하나, 이상한 모임에서 발표를 할 수 있었다.

제목:잉여의 잉여력 관리하기
ifttt.com
체력 관리. 꾸준히 운동을 한다. 많이 잔다. 얼마나 걸었는지 뭐 그런 것도 측정.

중간 홍보 시간

피라미드 조직 vs 아메바 조직
Facebook group of work <- 이건 GRAP이었나? Flow이었나?

헤드샷 필름 - 영화 홍보, 영상 제작
IT 서비스 소개 영상 제작도 하고 있으니 이용해 달라.


2부
아샬
제목:개발자는 어떻게 작업을 나누고 정복하는가?
코끼리를 먹는 방법:한 입씩 나누어 다 먹을 때까지 먹는다.
일감을 잘 나누자. Checklist, JIRA
Git Merge Hell -> Rebase를 써라.
(-> 나는 Perforce가 참 좋다.)

박정훈 @xelion
제목:우리 제품의 품질은 왜 이따구인가(품질관리)
Legacy - 소스 코드 뿐만 아니라 기업 문화에도 레거시가 생긴다. '전에 이런 거 해 놨는데 망했어. 그러니까 시도 하지마'라는 것들이 늘어난다. 그 당시에 왜 안 되었는지를 분석하고 극복할 생각을 하지 않고 그냥 포기해 버린다.
품질 관리는 양치질처럼 습관과 버릇이 중요.
Q:교육을 시켜주려 해도 배우려 들지 않는 팀원에게는 어떻게 해야 하나? A:공부를 안 하는 사람에게는 억지로 시켜도 안 되더라. 이런 사람들에게는 교육이 아닌 '행함(doing)'을 통해서 배울 수 있도록 적당한 일을 계속 주자.

제목:내 코드를 믿지 마라
'코딩 스타일'을 언급했으나 노현석님 팀에 명확한 코딩 컨벤션은 없다고. Android 자동 포맷을 우선 기준 삼으려 한다고 한다.
SOLID 중에서 S,D를 언급(아직도 SOLID가 유효하구나.)
Lint:잠재 에러, 코드 관리
IntelliJ 사용 중. 안드로이드 쪽에서는 Code Inspection 사용. Android Lint 라는 것도 있구나.
Lint 돌려보고 코드 체크 해보고, 해당언어가 지향하는 코드 컨벤션을 살펴보라는 얘기를 하고 싶었다고...

저스틴
제목:Serverless 코드 관리: AWS Lambda vs Azure Function (발표자료) (관련 블로깅)
동영상 자료는 oCam(오캠)으로 만들었다고...

윤인성 @RINTIANTTA 프리랜서 작가 (블로그)
제목:프리랜서 시간 관리 기법
한 일을 10분 단위로 엑셀에 기록. 30분 단위. 6초 단위로 스크린샷 찍는다. (동영상 크기는 30분에 30M 정도?)
이렇게 했더니 2년에 20여권의 책을 집필, 번역할 수 있었다. 화장실 가는 시간을 줄이기 위해 이온 음료를 마신다.(다들 헉...)
스컬핑도 취미 중 하나.
https://www.livecoding.tv/ 로 다른 사람 코딩하는 모습도 본다.
(-> 개인적으로는 가장 자극을 많이 받은 발표. 많이 반성했다.)

제목:남다른 사람들의 남다른 에버노트. (a.k.a 에버노트 훔쳐보기)
정리 컨설턴트 - 하루 15분 정리의 힘. -> 내가 하는 일이 아니라면 기록해 놔 봐야 다시 읽지 않는다.
정리를 잘 하는 사람들은 자신이 써 놓은 노트를 다시 읽으면서 영감을 얻더라.
나는 하루 30분씩 에버노트 정리시간을 갖는다.
Q:에버노트의 가격 정책 변화에 대해서 어떻게 생각하느냐? A:유저 95%가 무료 사용자다. 서비스에 비용을 지불하면 서비스의 품질이 올라간다.

제목:커뮤니티로 이직한 뒤의 자기 관리
병원비가 많이 나와서 취직하기로 결심.
수면 위생에 관심을 갖게 되면서 졸피뎀을 끊었다. (무엇이 은지를 죽음으로 몰고 갔는가. 스틸녹스(졸피뎀)의 위험)
기술 블로그가 나의 이력서가 된다.

이재현 iOS @TAROMATI
제목:할일관리도구 관리하기
Omni Focus - 좋으나 비싸다. 기능이 너무 많다. ()
GTD(Get Thing Done):실천하기가 어렵다. (-> 공병호씨가 번역한 책이 있다.)

오남경 @ALCION 디자이너 @코인원
제목:사이드 프로젝트로 재미를 관리하는 방법(디자인)
Dribbble - Show and tell for designers, Behance(Online Portfolios on Behance)(->지역 필터 가능)
'동그란 애플워치' 시안 만들어 올려봤는데 Bloter에 인터뷰가 올라올 정도로 호응이 좋았다.
내가 만든 작품을 공개하기를 두려워 하는 사람들이 많더라. 완성도가 떨어지더라도 일단 올려서 공유해라. 완성도보다 타이밍이다.
댓글에 상처 받을 수는 있다. 커뮤니티를 잘 선택해서 올려보자.

신예진 @ROYE @파킹스퀘어 경영지원
제목:이렇게 관리 잘하는 사람을 구인하세요.
재무회계관리:SmartA(다만 비싸다.)
영수증:자비스
공식문서 관리:Docswave

강상모(알음알음) @sangmo
제목:서류에 뽑히는 이력서 관리하기
면접관은 이력서를 보고 면접자에게 질문을 한다. 즉, 면접 때 받을 질문을 내가 고른다고 볼 수 있다.(-> 이 얘기는 정말 좋았다.)
헤드헌터들로부터 갑자기 연락이 쏟아진다면 나를 너무 저가에 내놓은 게 아닌가 생각해 봐라.
회사를 옮길 경우 5-10% 정도 연봉 인상을 기대할 수 있고, 잡 시커(Job seeker)일 경우 그쪽 연봉 테이블에 맞춰서 받거나 시세에 맞게 갈 가능성이 높다.
이 자리가 누가 나가서 생긴 것인지, 그 회사가 새로운 모멘텀이 생겨서 생긴 건지 확인해라.

뒷풀이
동남아에 스타트업 협업 공간이 잘 되어 있다. 가격도 싸다. 태국 치앙마이는 정말 가보고 싶어졌다.
드론 레이싱 취미가 재미있어 보였다. 속도가 70-100km까지 나온다더라. 조종사는 아날로그로 영상을 보는데 생각보다 레이턴시가 없었다. 주말이면 공원을 빌려서 새벽 6시에 모여 트랙을 설치한 뒤 경주한다. 유명한 중학생 드론 레이서 김민찬님은 아버지가 4살 때부터 아이 키보다 큰 RC헬기를 가지고 놀게 했었다.(영재교육) 보통 국내 대회 상금은 300만원이나 조만간 총상금 1억원(1등이 4천만원?)짜리 대회가 열린다고.
스위프트를 쓰고 싶어서 iOS6 -> iOS7으로 옮기자고 회사에 설득해 왔는데 정말 어려웠다. 그런데 의외로 금융 쪽은 굉장히 보수적임에도 불구하고 경쟁사의 지문인식 결제 시스템을 보더니 최소사항을 iOS8으로 올리는 걸 바로 허락하더라. 기술적인 이유가 아닌 마케팅 적인 이유, 혹은 제품의 관점에서 경영진을 설득하라.

1 2 3 4 5 6 7 8 9 10 다음


Yes24위대한게임의탄생3

위대한 게임의 탄생 3
예스24 | 애드온2