[Info]Tags categorized posts and contents patterns..

[AJAX] Ajax Code E xamples.. [Book] About the book.. [CSS] CSS Code E xamples.. [DB] Sql Code E xamples.. [DEV] All development stor...

2017년 2월 24일 금요일

[Spring 레퍼런스] 23장 JMX #1..


출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

이 문서는 개인적인 목적이나 배포하기 위해서 복사할 수 있다. 출력물이든 디지털 문서든 각 복사본에 어떤 비용도 청구할 수 없고 모든 복사본에는 이 카피라이트 문구가 있어야 한다.

23. JMX

23.1 소개

스프링은 스프링 어플리케이션을 JMX 인프라에 쉽고 투명하게 통합할 수 있도록 지원한다.
특히 스프링의 JMX 지원은 네 가지 핵심 기능을 제공한다.
  • 어떤 스프링 빈이라도 JMX MBean으로 자동 등록
  • 빈 관리 인터페이스를 제어하는 유연한 메커니즘
  • 선언적으로 원격(JSR-160 커넥터)에 MBean을 노출
  • 로컬/원격 MBean 리소스를 간단하게 프록시 함
이 기능들은 애플리케이션 컴포넌트가 스프링이나 JMX 인터페이스 혹은 클래스에 의존하지 않고 동작하도록 설계되었다. 사실 애플리케이션 클래스 대부분은 스프링의 JMX 좋은 기능을 위해서 스프링이나 JMX를 인지할 필요가 없다.


JMX?
이번 장은 JMX를 소개하는 장이 아니므로 왜 JMX가 필요한가에 대해서는 설명하지 않는다(또는 JMX가 무엇의 약자인지) JMX를 처음 본다면 이 장 마지막의 Section 23.8, “추가 자료”를 봐라.


23.2 빈을 JMX에 내보내기

MBeanExporter이 스프링 JMX 프레임워크의 핵심 클래스다. MBeanExporter이 스프링 빈을 가져와서 JMX MBeanServer에 등록한다. 예시로 다음 클래스를 생각해 보자.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Java

package org.springframework.jmx;

public class JmxTestBean implements IJmxTestBean {
  private String name;
  private int age;
  private boolean isSuperman;

  public int getAge() {
    return age;
  }

  public void setAge(int age) {
    this.age = age;
  }

  public void setName(String name) {
    this.name = name;
  }

  public String getName() {
    return name;
  }

  public int add(int x, int y) {
    return x + y;
  }

  public void dontExposeMe() {
    throw new RuntimeException();
  }
}

이 빈의 프로퍼티와 메서드를 MBean의 속성과 오퍼레이션으로 노출하려면 다음과 같이 설정파일에 MBeanExporter 클래스의 인스턴스를 설정하고 빈을 전달하면 된다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
Xml

<beans>
  
  <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter" lazy-init="false">
    <property name="beans">
      <map>
        <entry key="bean:name=testBean1" value-ref="testBean"/>
      </map>
    </property>
  </bean>

  <bean id="testBean" class="org.springframework.jmx.JmxTestBean">
    <property name="name" value="TEST"/>
    <property name="age" value="100"/>
  </bean>
</beans>

위 설정 예시에서 적절한 빈 정의는 exporter 빈이다. beans 프로퍼티가 빈 중에 정확히 어떤 빈을 JMX MBeanServer에 내보내야야 하는지 MBeanExporter에 알려준다. 기본 설정에서 beans Map의 각 요소의 키를 해당 값이 참조하는 빈의 ObjectName으로 사용한다. Section 23.4, “빈의 ObjectName 제어”에서 설명했듯이 이 동작은 변경할 수 있다.
이 설정에서 testBean 빈은 ObjectName bean:name=testBean1의 MBean으로 노출한다. 기본적으로 빈의 모든 public 프로퍼티는 속성(attribute)로 노출하고 public 메서드 (Object 클래스에서 상속받은 메서드 포함)는 오퍼레이션으로 노출한다.

23.2.1 MBeanServer 생성

위의 설정은 하나의(유일한) MBeanServer가 동작하고 있는 환경에서 어플리케이션이 돌아가고 있다고 가정한다. 이러한 경우 스프링은 돌아가고 있는 MBeanServer을 찾아내서 (찾았다면)해당 서버에 빈을 등록하려고 할 것이다. Tomcat이나 IBM WebSphere처럼 MBeanServer를 가진 컨테이너에서 어플리케이션을 돌리는 경우 이 동작이 유용하다.
하지만 독립적인 환경이나 MBeanServer를 제공하지 않는 컨테이너를 사용하는 경우에는 이 접근을 사용하지 않는다. 설정에 org.springframework.jmx.support.MBeanServerFactoryBean 클래스의 인스턴스를 추가해서 선언적으로 MBeanServer 인스턴스를 생성해서 이 문제를 해결할 수 있다. MBeanExporter의 server 프로퍼티를 MBeanServerFactoryBean이 반환한 MBeanServer 값으로 설정해서 특정 MBeanServer를 사용한다는 것을 보장할 수도 있다. 예를 들면 다음과 같다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
Xml

<beans>
  <bean id="mbeanServer" class="org.springframework.jmx.support.MBeanServerFactoryBean"/>

  
  <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
    <property name="beans">
      <map>
        <entry key="bean:name=testBean1" value-ref="testBean"/>
      </map>
    </property>
    <property name="server" ref="mbeanServer"/>
  </bean>

  <bean id="testBean" class="org.springframework.jmx.JmxTestBean">
    <property name="name" value="TEST"/>
    <property name="age" value="100"/>
  </bean>
</beans>

여기서 MBeanServerFactoryBean이 MBeanServer의 인스턴스를 생성했고 server 프로퍼티로 MBeanExporter에 전달했다. 자신의 MBeanServer 인스턴스를 전달했을 때 MBeanExporter가 동작하고 있는 MBeanServer를 찾지 않고 전달받은 MBeanServer 인스턴스를 사용할 것이다. 이 부분이 제대로 동작하려면 클래스패스에 JMX 구현체가 당연히 있어야 한다.


23.2.2 이미 존재하는 MBeanServer의 재사용

서버를 지정하지 않으면 자동으로 MBeanExporter가 돌아가고 있는 MBeanServer를 탐지하려고 할 것이다. 딱 하나의 MBeanServer 인스턴스만 사용하는 대부분의 환경에서는 잘 동작할 것이지만 여러 인스턴스가 존재한다면 익스포터가 잘못된 서버를 선택할 수도 있다. 이러한 경우 사용할 인스턴스를 나타내는 MBeanServer agentId를 사용해야 한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
Xml

<beans>
   <bean id="mbeanServer" class="org.springframework.jmx.support.MBeanServerFactoryBean">
     <!-- 제일 먼저 찾을 서버를 지정한다 -->
     <property name="locateExistingServerIfPossible" value="true"/>
     <!-- 주어진 agentId로 MBeanServer 인스턴스를 찾는다 -->
     <property name="agentId" value="<MBeanServer instance agentId>"/>
   </bean>

   <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
     <property name="server" ref="mbeanServer"/>
   ...
   </bean>
</beans>

기존의 MBeanServer가 검색 메서드로 얻은 동적(혹은 모르는) agentId를 가진 경우는 factory-method를 사용해야 한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
Xml

<beans>
   <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
     <property name="server">
       <!-- 커스텀 MBeanServerLocator -->
       <bean class="platform.package.MBeanServerLocator" factory-method="locateMBeanServer"/>
     </property>

     <!-- 다른  정의 -->
   </bean>
</beans>


23.2.3 지연 초기화된 MBean

지연 초기화로 설정된 MBeanExporter로 지연 초기화된 빈을 설정하는 경우 MBeanExporter이 해당 규약을 깨뜨리지 않을 것이고 빈을 인스턴스화하지 않을 것이다. 대신 MBeanExporter는 MBeanServer에 프록시를 등록하고 프록시에서 첫 호출이 발생할 때까지 컨테이너에서 빈을 가져오는 것을 미룰 것이다.

23.2.4 MBean의 자동 등록

MBeanExporter로 익스포트했고 유효한 MBean인 모든 빈은 스프링이 추가적으로 개입하지 않고 그대로 MBeanServer에 등록된다. autodetect 프로퍼티를 true로 설정해서 MBeanExporter가 자동으로 MBean을 탐지할 수 있다.

1
2
3
4
5
6
7
Xml

<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
  <property name="autodetect" value="true"/>
</bean>

<bean name="spring:mbean=true" class="org.springframework.jmx.export.TestDynamicMBean"/>

이 예제에서 spring:mbean=true인 빈은 이미 유효한 JMX MBean이고 스프링이 자동으로 등록할 것이다. 기본적으로 JMX에 자동탐지되서 등록한 빈은 ObjectName을 빈 이름으로 사용한다. 이 동작은 Section 23.4, “빈의 ObjectName 제어”에서 설명한대로 변경할 수 있다.


23.2.5 등록과정의 제어

스프링 MBeanExporter가 'bean:name=testBean1'이라는 ObjectName으로 MBeanServer에 MBean을 등록하려고 하는 시나리오를 생각해 보자. MBean 인스턴스가 이미 같은 ObjectName으로 등록되어 있다면 기본 동작은 실패한다. (InstanceAlreadyExistsException를 던진다.)
MBean을 MBeanServer에 등록했을 때 일어나는 동작을 제어할 수 있다. 스프링의 JMX 지원으로 등록과정에서 MBean이 이미 같은 ObjectName으로 등록되었다는 점을 발견했을 때 등록 동작을 제어할 수 있는 세가지 등록 동작을 이용할 수 있다. 이 등록 동작은 다음 표에 정리되어 있다.

Table 23.1. 등록 동작
등록 동작설명
REGISTRATION_FAIL_ON_EXISTING기본 등록 동작이다. MBean 인스턴스가 같은 ObjectName으로 이미 등록되어 있다면 등록하려던 MBean을 등록하지 않고 InstanceAlreadyExistsException를 던질 것이다. 존재하는 MBean에는 영향을 주지 않는다.
REGISTRATION_IGNORE_EXISTINGMBean 인스턴스가 같은 ObjectName으로 이미 등록되어 있다면 등록하려던 MBean을 등록하지 않는다. 기존의 MBean에는 영향을 주지 않고 Exception도 던지지 않는다.
이 동작은 공유된 MBeanServer에서 여러 어플리케이션이 공통적인 MBean을 공유할 때 유용하다.
REGISTRATION_REPLACE_EXISTINGMBean 인스턴스가 같은 ObjectName으로 이미 등록되어 있다면 미리 등록되어 있던 MBean이 등록 해지되고 새로운 MBean이 해당 위치에 등록될 것이다. (이전의 인스턴스를 새로운 MBean이 효율적으로 바꿔치기 한다.)












위의 값은 MBeanRegistrationSupport 클래스(MBeanExporter 클래스는 이 수퍼클래스에서 파생된 클래스다.)에 상수로 정의되어 있다. 기존 등록동작을 바꾸고자 한다면 MBeanExporter 정의에서 registrationBehaviorName 프로퍼티의 값을 변경하면 된다.
다음 예제는 기본 등록 동작을 REGISTRATION_REPLACE_EXISTING로 변경이 어떻게 영향을 주는지 보여준다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
Xml

<beans>
  <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
    <property name="beans">
      <map>
        <entry key="bean:name=testBean1" value-ref="testBean"/>
      </map>
    </property>
    <property name="registrationBehaviorName" value="REGISTRATION_REPLACE_EXISTING"/>
  </bean>

  <bean id="testBean" class="org.springframework.jmx.JmxTestBean">
    <property name="name" value="TEST"/>
    <property name="age" value="100"/>
  </bean>
</beans>


23.3 빈의 관리 인터페이스 제어하기

이전 예제에서 빈의 관리(management) 인터페이스로 약간의 제어를 했다. 익스포트한 모든 public 프로퍼티와 메서드는 JMX 속성과 동작으로 각각 노출된다. 익스포트한 빈의 어떤 프로퍼티와 메서드가 JMX 속성과 동작으로 노출되는지 세밀하게 제어하기 위해서 스프링 JMX는 빈의 관리 인터페이스를 제어하는 광범위하고 확장가능한 메카니즘을 제공한다.

23.3.1 MBeanInfoAssembler 인터페이스

내부적으로 MBeanExporter는 노출될 각 빈의 관리 인터페이스를 정의하는 역할을 하는 org.springframework.jmx.export.assembler.MBeanInfoAssembler 인터페이스의 구현체에 위임한다. 기본 구현체인 org.springframework.jmx.export.assembler.SimpleReflectiveMBeanInfoAssembler는 모든 퍼블릭 프로퍼티와 메서드를 노출하는(이전 예제에서 본 것처럼) 관리 인터페이스를 정의한다. 스프링은 소스수준의 메타데이터나 다른 임의의 인터페이스를 사용해서 생성한 관리 인터페이스를 제어할 수 있는 MBeanInfoAssembler 인터페이스의 두 구현체를 추가적으로 제공한다.

23.3.2 소스 수준의 메타데이터 사용하기 (JDK 5.0 어노테이션)

MetadataMBeanInfoAssembler를 사용해서 소스 수준의 메타데이터를 사용하는 빈에 대한 관리 인터페이스를 정의할 수 있다. 메타데이터는 org.springframework.jmx.export.metadata.JmxAttributeSource 인터페이스로 캡슐화해서 읽는다. 스프링 JMX는 JDK 5.0 어노테이션 (org.springframework.jmx.export.annotation.AnnotationJmxAttributeSource)을 사용하는 기본 구현체를 제공한다. MetadataMBeanInfoAssembler가 제대로 동작하기 위해서는 JmxAttributeSource 인터페이스의 구현체 인스턴스로 설정해야 한다.(기본값이 존재하지 않는다.)
JMX로 내보내도록 빈을 표시하려면 빈 클래스에 ManagedResource 어노테이션을 붙혀야 한다. 동작(operation)으로 노출하려는 각 메서드는 ManagedOperation 어노테이션을 붙혀야 하고 노출하려는 각 프로퍼티는 ManagedAttribute 어노테이션을 붙혀야 한다. 프로퍼티에 어노테이션을 붙힐 때는 읽기 전용이나 쓰기 전용 속성을 만들기 위해서 getter나 setter의 어노테이션을 생략할 수 있다. 아래 예제는 앞에서 본 JmxTestBean 클래스의 어노테이션을 사용한 버전이다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
Java

package org.springframework.jmx;

import org.springframework.jmx.export.annotation.ManagedResource;
import org.springframework.jmx.export.annotation.ManagedOperation;
import org.springframework.jmx.export.annotation.ManagedAttribute;

@ManagedResource(objectName="bean:name=testBean4", description="My Managed Bean", log=true,
    logFile="jmx.log", currencyTimeLimit=15, persistPolicy="OnUpdate", persistPeriod=200,
    persistLocation="foo", persistName="bar")
public class AnnotationTestBean implements IJmxTestBean {

  private String name;
  private int age;

  @ManagedAttribute(description="The Age Attribute", currencyTimeLimit=15)
  public int getAge() {
    return age;
  }

  public void setAge(int age) {
    this.age = age;
  }

  @ManagedAttribute(description="The Name Attribute",
      currencyTimeLimit=20,
      defaultValue="bar",
      persistPolicy="OnUpdate")
  public void setName(String name) {
    this.name = name;
  }

  @ManagedAttribute(defaultValue="foo", persistPeriod=300)
  public String getName() {
    return name;
  }

  @ManagedOperation(description="Add two numbers")
  @ManagedOperationParameters({
    @ManagedOperationParameter(name = "x", description = "The first number"),
    @ManagedOperationParameter(name = "y", description = "The second number")})
  public int add(int x, int y) {
    return x + y;
  }

  public void dontExposeMe() {
    throw new RuntimeException();
  }
}

이 예제에서 JmxTestBean 클래스에 ManagedResource 어노테이션이 붙어있는 것을 볼 수 있고 이 ManagedResource 어노테이션은 여러 가지 프로터티들로 설정되어 있다. MBeanExporter가 생성하는 MBean의 다양한 관점을 설정하는데 이러한 프로퍼티를 설정할 수 있고 더 자세한 내용은 나중에 Section 23.3.3, “소스 수준의 메타데이터 타입”부분에서 설명한다.
age와 name 프로퍼티도 ManagedAttribute 어노테이션이 붙을 것을 볼 수 있는데 여기서 age에는 getter에만 어노테이션이 붙어 있다. 이 어노테이션을 붙힘으로써 두 프로퍼티 모두 관리 인터페이스의 속성으로 포함되지만 age는 읽기 전용이다. 마지막으로 add(int, int) 메서드에는 ManagedOperation 어노테이션이 붙어있지만 dontExposeMe() 메서드에는 붙어있지 않다. 그래서 관리 인터페이스는 MetadataMBeanInfoAssembler를 사용할 때 add(int, int) 오퍼레이션만 가진다.
MetadataMBeanInfoAssembler를 사용하는 MBeanExporter를 설정하는 방법이 아래 설정에 나와 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Xml

<beans>
  <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
    <property name="assembler" ref="assembler"/>
    <property name="namingStrategy" ref="namingStrategy"/>
    <property name="autodetect" value="true"/>
  </bean>

  <bean id="jmxAttributeSource" class="org.springframework.jmx.export.annotation.AnnotationJmxAttributeSource"/>

  
  <bean id="assembler" class="org.springframework.jmx.export.assembler.MetadataMBeanInfoAssembler">
    <property name="attributeSource" ref="jmxAttributeSource"/>
  </bean>

  
  
  <bean id="namingStrategy" class="org.springframework.jmx.export.naming.MetadataNamingStrategy">
    <property name="attributeSource" ref="jmxAttributeSource"/>
  </bean>

  <bean id="testBean" class="org.springframework.jmx.AnnotationTestBean">
    <property name="name" value="TEST"/>
    <property name="age" value="100"/>
  </bean>
</beans>

여기서 MetadataMBeanInfoAssembler 빈이 AnnotationJmxAttributeSource 클래스의 인스턴스로 설정되었고 assembler 프로퍼티로 MBeanExporter에 전달되는 것을 볼 수 있다. 이것이 스프링이 노출한 MBean의 메타데이터 주도 관리 인터페이스의 장점을 취하기 위해서 필요한 전부이다.


23.3.3 소스 수준의 메타데이터 타입

다음 소스수준의 메타데이터 타입을 스프링 JMX에서 사용할 수 있다.

Table 23.2. 소스 수준의 메타데이터 타입
목적어노테이션어노테이션 타입
Class의 모든 인스턴스를 JMX가 관리하는 리소스로 표시한다.@ManagedResourceClass
메서드를 JMX 동작으로 표시한다.@ManagedOperationMethod
getter나 setter를 JMX 속성의 절반으로 표시한다.@ManagedAttributeMethod (getter와 setter 전용)
동작(operation) 파라미터에 대한 디스크립션을 정의한다.@ManagedOperationParameter와 @ManagedOperationParametersMethod





소스 수준의 메타데이터 타입에서 다음 설정 파라미터를 사용할 수 있다.

Table 23.3. 소스 수준의 메타데이터 파라미터
파라미터설명적용 대상
ObjectName관리하는 리소스의 ObjectName을 결정하기 위해서 MetadataNamingStrategy가 사용한다.ManagedResource
description리소스, 속성, 동작의 디스크립션을 설정한다.ManagedResource, ManagedAttribute, ManagedOperation, ManagedOperationParameter
currencyTimeLimitcurrencyTimeLimit 디스크립터 필드의 값을 설정한다ManagedResource, ManagedAttribute
defaultValuedefaultValue 디스크립터 필드의 값을 설정한다ManagedAttribute
loglog 디스크립터 필드의 값을 설정한다ManagedResource
logFilelogFile 디스크립터 필드의 값을 설정한다ManagedResource
persistPolicypersistPolicy 디스크립터 필드의 값을 설정한다ManagedResource
persistPeriodpersistPeriod 디스크립터 필드의 값을 설정한다ManagedResource
persistLocationpersistLocation 디스크립터 필드의 값을 설정한다ManagedResource
persistNamepersistName 디스크립터 필드의 값을 설정한다ManagedResource
name동작(operation) 파라미터의 표시 이름을 설정한다ManagedOperationParameter
index동작 파라미터의 인덱스를 설정한다ManagedOperationParameter


















23.3.4 AutodetectCapableMBeanInfoAssembler 인터페이스

더 간단한 설정을 위해서 스프링은 MBeanInfoAssembler 인터페이스를 확장해서 MBean 리소스를 자동탐지를 지원하려고 AutodetectCapableMBeanInfoAssembler 인터페이스를 도입했다. AutodetectCapableMBeanInfoAssembler 인스턴스로 MBeanExporter를 설정하면 JMX에 노출하기 위해 빈에 "투표(vote)"할 수 있다.
AutodetectCapableMBeanInfo 인터페이스의 유일한 구현체인 MetadataMBeanInfoAssembler는 ManagedResource 속성으로 표시된 모든 빈을 포함하도록 투표한다. 이 경우 기본 접근은 다음과 같은 설정의 빈 이름을 ObjectName으로 사용하는 것이다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
Xml

<beans>
  <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
    <!-- 어떤 'beans'도 명시적으로 선언하지 않았다. -->
    <property name="autodetect" value="true"/>
    <property name="assembler" ref="assembler"/>
  </bean>

  <bean id="testBean" class="org.springframework.jmx.JmxTestBean">
    <property name="name" value="TEST"/>
    <property name="age" value="100"/>
  </bean>

  <bean id="assembler" class="org.springframework.jmx.export.assembler.MetadataMBeanInfoAssembler">
    <property name="attributeSource">
        <bean class="org.springframework.jmx.export.annotation.AnnotationJmxAttributeSource"/>
    </property>
  </bean>
</beans>

이 설정에서 어떤 빈도 MBeanExporter에 전달하지 않았다. 하지만 ManagedResource 속성으로 표시되었고 MetadataMBeanInfoAssembler가 ManagedResource를 탐지해서 포함시키도록 투표하므로 JmxTestBean가 등록될 것이다. 이 접근방법의 유일한 문제점은 JmxTestBean의 이름이 비즈니스적인 의미를 갖게 되었다는 점이다. Section 23.4, “빈의 ObjectName 제어”에서 정의된 것처럼 ObjectName를 생성하는 기본 동작을 변경해서 이 문제를 해결할 수 있다.


23.3.5 자바 인터페이스를 사용한 관리 인터페이스 정의

MetadataMBeanInfoAssembler에 추가적으로 스프링도 인터페이스 컬렉션에 정의된 메서드 세트에 기반해서 노출되는 메서드와 프로퍼티에 제약을 가할 수 있는 InterfaceBasedMBeanInfoAssembler를 포함하고 있다.
MBean을 노출하는 표준 메카니즘이 인터페이스와 간단한 작명 계획을 사용하기는 하지만 InterfaceBasedMBeanInfoAssembler는 작명 관례에 대한 요구사항을 제거해서 이 기능을 확장함으로써 하나 이상의 인터페이스를 사용하고 빈이 MBean 인터페이스를 구현하지 않다도 되게 한다.
앞에서 본 JmxTestBean 클래스에 대한 관리 인터페이스를 정의할 때 이 인터페이스의 사용을 고려해 봐라.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
Java

public interface IJmxTestBean {

  public int add(int x, int y);

  public long myOperation();

  public int getAge();

  public void setAge(int age);

  public void setName(String name);

  public String getName();
}

이 인터페이스는 JMX MBean의 동작과 속성으로 노출될 메서드와 프로퍼티를 정의한다. 아래 코드는 관리 인터페이스의 정의로 이 인터페이스를 사용하도록 스프릥 JMX를 설정하는 방법을 보여준다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Xml

<beans>
  <bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
    <property name="beans">
      <map>
        <entry key="bean:name=testBean5" value-ref="testBean"/>
      </map>
    </property>
    <property name="assembler">
      <bean class="org.springframework.jmx.export.assembler.InterfaceBasedMBeanInfoAssembler">
        <property name="managedInterfaces">
          <value>org.springframework.jmx.IJmxTestBean</value>
        </property>
      </bean>
    </property>
  </bean>

  <bean id="testBean" class="org.springframework.jmx.JmxTestBean">
    <property name="name" value="TEST"/>
    <property name="age" value="100"/>
  </bean>
</beans>

모든 빈에 대한 관리 인터페이스를 생성할 때 IJmxTestBean 인터페이스를 사용하도록 설정한 InterfaceBasedMBeanInfoAssembler를 볼 수 있다. InterfaceBasedMBeanInfoAssembler가 처리한 빈은 JMX 관리 인터페이스를 생성하는데 사용하는 인터페이스를 구현할 필요가 없다는 점을 이해하는 것이 중요하다.
위의 경우 모든 빈에 대한 모든 관리 인터페이스를 생성하는데 IJmxTestBean 인터페이스를 사용한다. 많은 경우 이는 원하는 동작이 아니고 빈마다 다른 인터페이스를 사용하길 원할 것이다. 이러한 경우에는 interfaceMappings 프로퍼티로(각 엔트리는 빈의 이름이고 엔트리의 값은 해당 빈에 사용할 인터페이스 이름을 콤마로 구분한 목록이다.) InterfaceBasedMBeanInfoAssembler Properties 인스턴스를 전달할 수 있다.
managedInterfaces와 interfaceMappings 프로퍼티로 지정한 관리 인터페이스가 없으면 InterfaceBasedMBeanInfoAssembler가 빈에 반영되고 관리인터페이스를 생성하는 해당 빈이 구현한 모든 인터페이스를 사용할 것이다.

23.3.6 MethodNameBasedMBeanInfoAssembler 사용하기

MethodNameBasedMBeanInfoAssembler로 JMX가 속성과 동작으로 노출할 메서드명의 목록을 지정할 수 있다. 아래 코드는 이에 대한 설정 예시를 보여 준다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
Xml

<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
  <property name="beans">
    <map>
      <entry key="bean:name=testBean5" value-ref="testBean"/>
    </map>
  </property>
  <property name="assembler">
    <bean class="org.springframework.jmx.export.assembler.MethodNameBasedMBeanInfoAssembler">
      <property name="managedMethods">
        <value>add,myOperation,getName,setName,getAge</value>
      </property>
    </bean>
  </property>
</bean>

이 코드에서 add와 myOperation 메서드가 JMX 동작으로 노출되고 getName(), setName(String), getAge()는 JMX 속성으로 노출되는 것을 볼 수 있다. 위 코드에서 메서드는 JMX에 노출되는 빈에 매핑된다. 빈과 빈(bean-by-bean)의 메서드 노출을 제어하려면 빈 이름을 메서드 이름의 목록에 매핑하기 위해 MethodNameMBeanInfoAssembler의 methodMappings 프로퍼티를 사용해라.

[UFC] UFC 마감뉴스..


출처 : SPOTV NEWS


















2017년 2월 21일 화요일

[NEWS] 14-02-01 기술 뉴스..


출처 : Outsider's Dev Story https://blog.outsider.ne.kr/


  • asm.js AOT compilation and startup performance : 모질라에서 올라온 asm.js의(asm.js에 대한 이전 글 참고) 로딩 타임 최적화에 대한 글로 현재 SpiderMonkey의 JIT가 어떻게 동작하고 OdinMonkey의 AOT는 어떻게 접근하고 있는지에 자세히 나와 있어서 이 부분에 관심이 있다면 자세히 읽어볼 만 하다. (영문)
    • asm.js에서는 AOT(Ahead-of-time) 컴파일을 사용해서 성능이 예측 가능하도록 한다.
    • 소수 코어로 병렬 컴파일을 통해서 상위계층의(top-tier) 컴파일러가 전체코드를 컴파일하는 비용을 줄인다.
    • 비동기 컴파일로 AOT가 진행되는 동안에도 웹 애플리케이션이 반응할 수 있게 한다.
    • 컴파일한 머신코드를 캐싱해서 웜업(warm-up)시간을 상당히 높인다.
  • Bower components : Bower의 컴포넌트를 검색할 수 있는 사이트. 언제 생긴지는 모르지만, 공식 Bower 페이지에서도 연결되어 있지만 약간 느리다.(영문)
  • A More Modern Scale for Web Typography : 반응형 웹 디자인에서 타이포그래피는 어떻게 처리해야 하는가에 대한 글. 각 기기별로 테스트해서 본문과 헤딩 등이 어떤 크기가 적당한지와 한 라인에 몇 글자가 좋은지를 알려주고 있어서 참고하기 좋고 예제까지 제공하고 있다. 영문이라 한글 타이포그래피는 상황이 좀 다르지만...(영문)
  • JavaScript: The Right Way : JavaScript와 관련된 글이나 정보를 한 사이트에 모아놓은 사이트. 정리가 깔끔하게 되어 있지만 다 영어라서 읽는 데는 부담이 좀 된다. 처음 자바스크립트를 공부할 때 관련 자료를 찾아보는 용도로 좋을 듯...(영문)
  • Mobile A/B testing at LinkedIn: how members shape our apps : 링크드인이 다양한 모바일 클라이언트(안드로이드, 아이폰, 터치 웹)에서 A/B 테스트를 하기 위해서 LiX(LinkedIn Experimentation)라는 인프라에서 JSON에 기반을 둔 A/B 테스트를 어떻게 진행해서 의사결정을 하는지 사례를 공유했다.(영문)
  • Run Chrome Apps on mobile using Apache Cordova : 데스크톱에서 크롬 앱을 돌릴 수 있는 크롬 팩키지드 앱이 아파치 코도바를 이용해서 안드로이드와 아이폰에서 동작할 수 있는 앱을 만들 수 있게 되었다.(영문)
  • Github Guides : Github의 가이드 페이지가 개편되어 Github의 워크플로우, 마크다운 등의 가이드 문서를 볼 수 있다.(영문)
  • YOU MIGHT NOT NEED JQUERY : 라이브러리를 만들 때 불필요하게 jQuery를 의존하게 되는 문제를 조심하라는 의미로 만들어진 사이트로 Ajax나 화면효과 등의 jQuery 코드를 순수 자바스크립트로 구현하면 어떤 코드가 되는지 비교해서 보여주고 있다.(영문)

프로그래밍

  • The Next Phase of Node.js : 그동안 Node.js 프로젝트를 이끌던 Isaac Z. Schlueter가 물러나고 Timothy J Fontaine가 Node.js 1.0을 이끌게 되었다.(Isaac은 커미터로는 계속 활동한다고...) Issac은 글 내용상으로는 npm Inc라는 회사를 새로 차리는 것 같다.(영문)
  • What’s New in Node.js v0.12 – Performance Optimizations : StrongLoop에 Node.js의 차기 안정 버전인 v0.12의 변경사항에 대한 글이 올라왔다.(v0.12가 임박했다는 의미일 듯) 주요 변경사항으로는 writable 스트림에 "corked"모드가 추가되었고 TLS 모듈이 기존에 net 모듈 위에서 돌아가서 발생하던 성능 문제를 해결하기 위해 libuv를 직접 사용하도록 재작성했다.(간단한 테스트 상으로는 더 적은 메모리를 소비하면서 10% 빨라졌다고...) 그외 Crypto와 cluster등의 성능 개선이 이루어졌다.(영문)
  • Let’s Bolt! : Parse에서 그동안 SDK를 만든 경험을 바탕으로 iOS와 안드로이드에서 공통으로 필요한 저수준 라이브러리를 Bolts Framework라는 이름으로 공개했다. 처음 공개한 Bolts의 컴포넌트는 비동기 코드를 쉽게 관리할 수 있는 Tasks 컴포넌트다.(영문)

읽을 만한 링크

  • SlideShare Zeitgeist 2013 : 2013년 슬라이드 쉐어에 대한 통계자료. 사용자들이 비쥬얼한 자료를 좋아하고 모바일 접속이 증가하는 등 슬라이드 쉐어에서 2013년에 어떤 주제에 사람들이 관심 있는 지 등을 엿볼 수 있다.(영문)
  • 3 Million Teens Leave Facebook In 3 Years: The 2014 Facebook Demographic Report : 미국 기준으로 3년 사이에 페이스북의 유저수가 나이별로 어떤 변화가 있었는지를 비교해서 공개한 자료. 이 자료기준으로 3년 사이에 10대(13~17세)가 -25.3% 감소했고 55세 이상은 80.4% 증가한 것으로 나왔다.(추가로 3년 전에 13~17세는 지금 18~24세로 진입했기 때문에 적절치 않다는 의견을 받아서 단순 나잇대로 비교한 변화추이임을 밝힘) (영문)
  • GitHub's Public Speaking Culture : Github의 잭 홀맨이 직원들이 공개적으로 발표하는 것에 대한 좋은 점을 소개한 점. 개인으로써 발표할 때의 좋은 점이라기보다는 회사의 입장에서 직원들이 외부행사 등에서 발표하면 어떤 점이 좋고(광고효과와 구인) Github이 어떤 문화를 가졌는지 설명한 글이다. (영문)
  • 7 unbreakable laws of user interface design : Peter Vukovic라는 디자이너가 UI 디자인에서 지켜야 할 7가지 법칙으로 명확함, 선호하는 행동, 콘택스트, 기본값, 해야 할 행동에 대한 안내, 명확한 피드백, 간결함을 꼽았는데 예시를 들며 설명해서 UI에 관심 있다면 읽어볼 만하다.(영문)
  • Sony Be Moved : Sony가 "Be Moved"라는 캠페인의 일환으로 만든 사이트인데 기존에 보던 parallax scrolling과는 차원이 다른 parallax scrolling를 보여주고 있다.(영문)
  • A-B Testing의 단점과 개선안 : A/B 테스트에 대한 강규영님의 글로 나처럼 실험을 통해서 데이터를 얻는 정도로만 생각하고 있었다면 이 글을 통해서 A/B 테스트의 접근방법과 한계, Multi-armed bandit 문제(뭔지는 글에 나온다.) 등에 대해서 자세히 알 수 있다.(한글)
  • 2013년 웹 관련 통계 정리 : 2013년에 여러 가지 통계데이터를 기준으로 소셜 미디어의 사용률이나 플랫폼의 비율 등이 정리되어 있다. 웹과 관련된 여러 통계와 함께 정리된 내용을 볼 수 있고 상세 데이터에 대한 링크도 있어서 관심 가는 부분은 자세한 데이터를 볼 수 있다. (한글)
  • 제품, 비타민과 진통제 : 스타트업의 아이디어가 꼭 필요한 진통제인지 꼭 필요한 건 아닌 비타민인가 하는 "Is Your Product a 'Vitamin' or 'Painkiller?'"라는 글의 번역 글(한글)
  • 디지털 바루기 - 4화 대한민국 인터넷 아버지 전길남 박사 : 대한민국 인터넷 아버지라 부를만한 전길남 박사님의 업적을 기린 만화(한글)
  • Apple - Thirty Years of Mac : 지난 1월 24일 애플은 30주년을 기념해서 공개한 동영상과 30년간의 애플 모델을 보여주는 인포그래픽 페이지. 별도로 30주년을 기념해서 Macworld에서 이뤄진 애플 임원들의 인터뷰를 번역한 글도 있다.(영문)
  • 최고의 커리어조언 : "로켓에 자리가 나면 일단 올라타라." : 과거에 많이 공유되었던 쉐릴 샌드버그의 하버드 경영대학원 졸업식 축사 동영상에 한글 자막이 추가되었다.(한글)
  • 인터뷰의 질문과 답 : 박상민 님이 IT 환경과 소프트웨어 개발에 대한 인터뷰 내용을 블로그에 공개했는데 좋은 내용이 많이 담겨 있어 읽어볼 만하다.(한글)

프로젝트

  • webkit.js : 웹킷을 자바스크립트로 포팅한 프로젝트로 PhantomJS와 유사하게 웹킷을 자바스크립트로만 구동할 수 있게 하려는 프로젝트다.
  • scrollReveal.js : 스크롤 할 때 HTML 요소가 나타나는 애니메이션 효과를 선언적으로 줄 수 있는 라이브러리

버전 업데이트 [내용 삭제]


My Comment..
뉴스를 또 가져오게 되었는데 한가지 언급할 것이 있어서 이렇게 코멘트 해본다.. 본문 하단에 존재하는 버전 업데이트 타이틀에 포함된 내용들은 삭제를 했다.. 앞으로는 이런 코멘트를 한다거나 버전 업데이트 타이틀 조차도 남겨두지 않을 예정이다.. 내가 기본적으로 뉴스를 가지고 오는 것은 이런 것들이 이 시기에 흥하고, 이슈를 끌고 그랬었구나 정도이다.. 이전 뉴스에서 언급한것처럼 답습정도 말이지.. 그런데 버전은 이미 시점이 꽤 지난 상태에서 그 시기에 버전이 업데이트 된 것을 알필요가 있을까 싶은 생각이 든다.. 솔직히 말하면 지금 새로나온 버전에 대한 스펙도 확실하게 모르는 상황에서.. 흠..;;;

어찌보면 jdk 몇 버전이 몇년도에 나왔었구나라는 것을 기억하거나 다시금 읽어보는 개념이 되는데.. 개발을 하면서 지난 버전을 쓰게된다면, 필요에 의해서 과거 API 를 찾아보긴 하지만.. 업데이트 시점을 딱히 궁금해했던적은 없었던 것으로 기억한다.. 무엇보다 내가 햄의 블로그에서 지난 뉴스를 가지고 오면서 생각했던 취지와는 틀려서 삭제를 하기로 마음 먹었다..

2017년 2월 15일 수요일

[Linux] 터미널에서 vi 키 바인딩 사용하기..


출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

vi를 아주 잘 쓰는 편은 아니지만, 터미널에서도 vi로 코드를 작성하는 경우도 많고 대부분의 에디터에서 vi 키바인딩을 사용하고 있다. vi에 어느 정도 익숙해진 후의 좋은 점이라면 별도로 단축키를 외우지 않아도 된다는 장점이 있다. 새로운 에디터나 IDE를 사용할 때 항상 피곤한 게 새로운 단축키를 외우고 익숙해 져야 하는 문제가 있는데 vi 키바인딩을 쓰면 새로운 도구에서라도 코드 수정은 웬만한 수준으로 바로 할 수 있다.

그러다가 얼마 전에 해커뉴스에서 맥에서 좋은 팁들을 공유하는 스레드를 보다가 쉘에서 vi 키바인딩을 사용하는 방법을 알게 되었다.

set -o vi

위 코드를 .bash_profile 등의 파일에 넣어두면 쉘에서 vi 키바인딩을 사용할 수 있다. 쉘에서 vi 키를 쓴다는 것은 vi에 들어가는 걸 의미하는 게 아니라 쉘 커맨드에서 명령어를 작성할 때 커서를 이동하거나 명령어를 복사하거나 잘라내는 등의 작업을 할 때 쉘 단축키 대신 vi 키를 사용할 수 있다. (물론 모든 키가 다 되는 건 아니다.) ESC를 누르면 일반모드로 나오고 i등을 입력하면 입력모드로 변경할 수 있다. 별거 아닌 것 같지만, 은근 편하다. 참고로 난 Emacs를 사용하진 않지만 set -o emacs 를 사용하면 Emacs의 키바인딩을 사용할 수 있다.

My Comment..
리눅스 관련해서 vi 를 종종 쓰긴한다.. 근데 어지간하면 안쓰기도 하고 잘 모르기도 한다.. 특히나 안쓰는 이유는 혹~~~시라도 문제가 생겨서 날려먹을까봐.. 소스 수정하고 어쩌고 하다가 괜시리 날려먹는건 아닌가 하는 불안감 때문에..

어지간하면 Tool 에서 수정하고 올리고 그러는 방식이 좋긴하다.. 이렇게 간단하게 쓸 수 있는 것도 있구나해서 가져와보긴 했지만 과연 쓰게 될런지는 약간 의문스럽다.. 워낙 새가슴이라.. ㅎㅎㅎ..

[UFC] 맥그리거와 메이웨더가..??


한 동안 그렇게 재미난 뉴스가 좀 안보이다가 웃기다고 해야되나.. 재미나고 흥미로운 뉴스가 하나 올라왔다.. 다름이 아닌 UFC 선수도 아닌 메이웨더코너 맥그리거가 복싱으로 붙을 수도 있다는 내용이었다..

이미 과거부터 둘은 온라인 상에서 상당히 설전이 심했다.. 서로를 비하하는 것은 머 당연한 것이고, 서로의 실력에 의심 또한 심했으며, 싸워서 스스로의 가치를 겨뤄보자는 내용들이 주된 것이었다.. 우리나라였으면, 저런 이슈거리보단 선수 인성이 별로네 어쩌네 하면서 그런것들이 더 이슈가 되겠지..?? ㅎ 무튼.. 난 그러한 뉴스를 볼 때마다 "재들 또 저라는구나.." 라고 생각만 했었는데 오늘 뉴스를 보니.. 대결 확률이 그~~나마 조금 더 높아졌다고 한다..

결국 확률 얘기일 뿐이고 성사되어서 오피셜이 떠야 그게 진짜긴 하지만 만약 둘이 진짜로 싸우게 된다면, 난 무조건 메이웨더의 압승이라고 생각한다.. 관련해서 정찬성 선수도 BJ펜닷컴과 인터뷰를 했는데 "파이터로서 맥그리거의 팬이다. 엄청난 일을 해냈다고 생각한다. 그러나 복싱 경기에서 맥그리거가 메이웨더에게 이길 수 있다고 보지 않는다. 만약 둘의 경기를 두고 베팅을 해야 한다면 내 모든 돈을 메이웨더에게 걸겠다"고 말했다고 한다..

▲ 코너 맥그리거와 플로이드 메이웨더의 가상 포스터.

이 부분은 나 또한 의심없이 동감하는 부분이긴 하다.. UFC 룰로 싸운다면 당연히 맥그리거가 이길 가능성이 높겠지만 순전히 복싱 룰을 통해서 싸운다면 맥그리거가 이긴다고..?? 그건 그냥 본인 스스로의 바램이라고 생각한다..

이것저것 떠나서 경기가 성사된다면, 정말 재미지긴 할 듯 하지만 글쎄.. ㅎㅎㅎㅎ 진짜 그냥 꿈의매치고, 바램일 뿐 아닐까..?? 라는 생각이 든다..

맥그리거.. 당신을 응원하고 UFC 선수로써 사랑하지만, 복싱은 아니라고 본다.. 성사된다면, 메이웨더에게 혼쭐이 나길 빈다.. 사람이 가끔은 정신을 차리는 일도 겪어야지..?? ㅎㅎ

2017년 2월 13일 월요일

[NEWS] 14-01-15 기술 뉴스..


출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

올해는 좀 더 새로운 시도를 해보려고 생각하고 있었는데 뭘할까 생각하다가 그나마 내가 많이하는 것 중 하나가 인터넷에서 많은 뉴스나 링크들을 찾아보는 걸 오랫동안 했기 때문에 이런걸 어떤 뉴스레터식으로 제공할 수 있지 않을까 생각했다. 사실 내가 관심가기거나 보는 것들은 대부분 트위터를 통해서 공유하고 있기는 하지만 SNS 특성상 계속 보는 사람이 아니면 확인하기가 어렵고 놓칠 가능성도 높은 문제가 있다. 그래서 링크를 찾아보거나 뉴스들을 보는 건 일상이니까 모아놓으면 어떨까 하는 생각을 하게 되었다.

어찌 보면 이건 약간 실험의 일정이기도 하다.(실험이라는 의미는 해보다 아니다 싶으면 안할지도 모른다는거...) 이렇게 모아놓으면 과연 유용할까하는... 예전에 xguru님의 기술뉴스도 잘 보았고 난하님의 Read Trend같은 형태도 있는데 나는 어떤 형태가 좋을지는 사실 맘을 정하지 못했다. 이런 저런 서비스들을 테스트해봤지만 그다지 맘에 드는 형태는 없어서 그냥 작성하기 편한 포맷을 그대로 이용했다. 따로 편집하는건 공수가 너무 들어서...

링크도 보고 쌓기만 하다가 정리를 좀 해보려니까 생각보다는 좀 만만치 않고(카테고라이징도 계속 고민 중) 첫 모음도 사실 해놓고 보니 만족스럽지는 않은데 하다보면 차차 자리를 좀 잡아가지 않을까 기대하고 있다. 기술뉴스라고는 하지만 지극히 내 관심사에 모은 소식들이고 그렇다 보니 어떤 링크들은 최신이 아닌데 내가 최근에 본 소식들도 있을 수 있다. 지금 생각으로는 한달에 2번을 생각하고 있는데 어떻게 될지는 나도 잘...

  • React Chrome Developer Tools : 페이스북의 자바스크립트 라이브러리인 React의 코드를 디버깅할 수 있는 크롬 익스텐션. (영문)
  • Switchery : 체크박스를 iOS 7 스타일로 꾸밀 수 있는 자바스크립트 라이브러리. (영문)
  • Web Developer Checklist : 웹사이트를 만들 때 웹개발자가 점검해 봐야 할 목록과 그에 대한 관련 서비스가 잘 정리되어 있다.(영문)
  • JavaScript Promise 외 튜토리얼 4종 라이브 소식 : 도창욱님이 HTML5 Rocks의 내용을 번역해서 제공하는 블로그로 최근에 추가된 자바스크립트 네이티브 Promise 등의 내용이 추가되었다. 그리고 해당 블로그에 최근 크롬 개발자 서밋에 대한 내용도 추가되었다.

프로그래밍

읽을 만한 글

  • 집에서 일하기 : 유칼립투스에서 일하는 박상민님이 자신의 경험에 기반해서 원격근무에 대해서 적은 글로 원격근무에 관심이 많다면 읽어볼 만하다.
  • Flat Design vs. Realism : inTacto라는 회사에서 플랫 디자인과 리얼리즘 디자인에 대한 인포그래픽인데 아주 인터렉티브하게 잘 만들어져서 내용보다 인포그래픽 자체가 볼만하다. (영문)
  • 일간워스트 개장기 : rainygirl님이 일간워스트를 만드는 과정을 자세하게 공유한 글로 여러가지 이슈들에 대해서 어떻게 대응하고 발전했는지를 재미있게 읽을 수 있다
  • Introducing Jelly : 트위터의 공동창업자인 비즈 스톤이 Jelly라는 Q&A 서비스를 오픈함.(영문)
  • The Year in Kickstarter 2013 : 킥스타터가 2013년에 어떤 일을 겪었는지 보여주는 프리젠테이션으로 2013년의 펀딩 금액 및 사용자에 대한 통계와 대표 프로젝트가 나와있다. (영문)
  • OP.GG 오픈부터의 1년을 되돌아보며 : [LoL](League of Legends) 전적검색 사이트인 OP.GG를 오픈하고 1년간의 과정을 정리한 글로 서비스를 어떻게 개선하고 장애에 대응했는지가 잘 정리되어 있어서 LoL을 안하더라도 읽어볼만하다.
  • Outage post-mortem : 드랍박스가 지난 10일 장애를 겪은 후 정리한 포스트모템이다. OS 업그래이드 작업을 진행하던 중 해당 서버가 엑티브인지 검사하는 스크립트의 버그로 서버가 엑티브상태인데 업그래이드가 일부 진행되면서 디비의 마스터-슬레이브 연동에 문제가 생겨서 장애가 발생했다고 한다. 파일을 저장하는 서버는 아니라서 파일 손상은 없었다고... (영문)
  • Google to Acquire Nest : 구글이 아이팟의 아버지인 토니 파델이 만든 Nest를 32억달러에 인수했다. Nest는 온도조절장치와 화재경보장치 등을 만드는 회사다. (영문)
  • Stackoverflow.com 의 아키텍처 : 작년 Developer Conference 2013에서 스택오버플로우의 아키텍쳐에 대해서 발표된 내용이 정리된 글로 스택오버플로우가 서버 및 플랫폼이 어떤 규모로 운영되고 있는지 알 수 있다.

프로젝트

  • CocoaSPDY : 트위터가 공개한 iOS, OS X에서 사용할 수 있는 SPDY 클라이언트 라이브러리.
  • iSPDY : Voxer가 공개한 iOS, OS X에서 사용할 수 있는 SPDY 클라이언트 라이브러리
  • hpack : 트위터가 공개한 HTTP 2.0 헤더압축에 대한 자바 라이브러리.
  • AngularFire : 리얼타임 데이터 백앤드 서비스인 Firebase를 AngularJS에서 쉽게 사용할 수 있도록 만든 Angular 바인딩

My Comment..
항상 햄의 포스팅을 가져올 때는 고민을 살짝 하는데 이번 글은 조금 더 고민을 했다.. 다른 이유보단 구태여 과거 뉴스를 왜..?? 라는 부분 때문인데.. 

나 스스로 햄의 글들을 가져올 때 과거의 글을 떠나서 저런 부분이 있었구나.. 저렇게 정리를 했구나 하는 것 때문에 가져오는 것도 있지만, 해당 글처럼 기술 동향을 정리해둔 뉴스 포스팅은 비록 과거글이라고 할지라도 난 부끄럽게도.. 그 마저도 몰랐기에..

저 시점에는.. 이 글로 따지면 2014년에는 저런 기술과 뉴스가 이슈를 이루고 있었구나.. 하면서 어찌보면 과거를 답습..?? 하는 관점에서 고미을 하다가 글을 가져왔다.. 지금도 그렇지만 햄의 글을 과거부터 읽어가면서 몰랐던 기술, 언어, 오류, 뉴스, 생각 등등.. 많이 알아가고 있다..

점차적으로 현실에 가까워지고 있기도 하고 말이지.. 

[Talk] 보안이 정말 그렇게 중요한가..


출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

개개인이 가진 보안의 적정수준이란 건 당연히 다르기 마련이고 상황이나 입장에 따라 달라지게 마련이지만 평소 주위에 만연해 있는 보안에 대한 인식은 너무 과도하다고 생각한다.

큰 의미에서 보안이란 것은 대부분 어떤 가치 있는 무언가를 허가받지 않은 사람이 이용하지 못하도록 막는 것인데 내가 가진 보안에 대한 입장은 이용을 편하게 할 수 있는 수준을 보장한 뒤에 보안을 논해야 한다고 본다. 왜냐하면, 원래의 목적은 그 무언가를 이용하는 것이 1차적인 목적이고 그에 대한 부작용으로 허가받지 않은 사람이 사용하게 돼서 생기는 문제를 막기 위해 보안이 추가된 것이기 때문이다. 하지만 현실은 보안이 너무 과도해져서 이용 자체를 크게 저해하고 있다. 마치 이용을 막는 게 1차 목표인 것처럼...(물론 어디는 보안이 너무 과도하고 어딘가는 보안이 너무 빈약한 문제는 있다.)
예를 들어 보면 나는 집에 들어갈 때 우리 집 현관문에 달린 자물쇠를 열고 들어간다. 자물쇠는 2개가 달렸지만 보통 1개만 사용하고 장기간 비울 때만 2개를 사용한다. 다른 집도 비슷할 거라고 생각하는데 여태 살면서 가정집에 자물쇠 3개 이상 달린 집은 본 적이 없다. 만약 자물쇠가 종류별로 다른 인증체계를 가지고 자물쇠가 10개쯤 달려있다면 하나만 사용하는 것보다 당연히 더 안전할 것이다. 하지만 그렇게 하지 않는 이유는 현관문을 하루에도 수십 번씩 열어야 하기 때문이다. 지문인식부터 시작해서 열쇠를 다발로 가지고 다니면서 현관문을 오갈 때마다 일일이 십여 개씩 열고 다닌다면 보통 제정신이 아니라고 생각할 것이다. 영화에서 편집증에 걸린 사람이 이렇게 하는 거 외에는 실생활에서는 본 적이 없다. 현관문은 아니더라도 창문 등을 통해서 집에 들어오는 방법도 있다. 만약에 나갈 때 버튼 하나만 누르면 쇠로 된 셔터가 내려와서 모든 창문을 막아버리면 당연히 더 안전할 것이다. 마찬가지로 그렇게 하는 사람은 없다. 여기에는 비용문제도 있고 현관문과 마찬가지로 매일 사용해야 하므로 이런 짓거리는 하지 않는다.
좀 과해 보이는 예시일 수도 있지만 내가 느끼기에는 IT에서 이러한 일은 빈번하게 일어난다. 보안은 중요하다는 명목하에서...

앞의 예제를 다시 보면 가장 쉬운 보안해결책은 집에 값진 물건을 두지 않는 것이다. 값진 물건을 두지 않으면(그래서 은행 같은 게 있는 거지...) 설사 보안체계가 뚫리더라도 위험이 크지 않다. 하지만 값진 물건이 있을 수밖에 없긴 한데 그렇다면 이 값진 물건에만 별도의 보안을 추가하면 된다. 당연히 생각해도 온 집안에 물건이 다 중요하진 않을 테니 절대 잃어버리면 안 되는 것만 별도의 금고에 넣거나 하면 된다. 이럴 때는 별도의 인증과정이 들어가도 아무도 불만을 품지 않는다. 번거로운 인증과정을 거칠 정도로 그 안에 들어 있는 것이 중요하기 때문이다. 그리고 이 부분은 이용성에도 문제가 되지 않는다. 내가 냉장고를 열고 물통을 꺼내는 횟수랑 금고에서 황금 송아지를 꺼내볼(우리 집에 그런 건 없다.) 횟수는 당연히 다를 수밖에 없다. 그러므로 물통을 꺼낼 때는 추가로 인증과정을 거치지 않지만 황금 송아지를 꺼낼 때는 추가로 인증과정을 요구해도 크게 문제가 되지 않는다.

하지만 IT 환경을 보면 보안이라는 이유로 너무 많은 걸 보안영역 안에 넣어버린다. 그래서 원래는 이용하는 게 목적이었는데 너무 불편하므로 꼭 필요한 상황이 아니면 이용하지 않으려고 하게 된다. 내가 느끼기에 이 중에 80% 정도는 물통에서 물을 먹기 위해서 냉장고에 자물쇠가 걸려있는 꼴이다. 혹시 냉장고에 들어있는 물통이 나중에 값지게 될지도 모를 일이므로... 심지어 일해서 수익을 내는 회사에서도 이런 역전현상이 수시로 발생한다는데 당혹감을 감출 수 없는데 수많은 개발방법론을 도입해서 생산성을 조금이라고 올리는 것보다 보안을 조금 낮추는 게 훨씬 더 생산성을 높일 수 있을 거라고 본다.

왜 이런 일이 발생했는지는 나도 알 수 없다. 하지만 간단한 애플리케이션을 너무 과도하게 설계에서 성능이 제대로 나오지 않는다면 개발자가 해결해야 할 이슈이듯이 보안 때문에 생산성이 떨어진다면 이를 해결해야 하는 건 보안 쪽이다. 그리고 이런 무리한 요구도 아니고 이미 보안도 어느 정도 지키면서 생산성도 유지할 수 있는 기술은 충분히 개발되었다고 본다.

덧) 물론 이런 얘기를 하면 나중에 보안 문제로 재판 갔을 때 회사가 얼마나 보안에 대해 노력했느냐 하는 부분이 중요하다느니 어쩌느니 하는 얘기가 나오는데 재판을 안 가봐서 그런지 몰라도 별로 동의는 되지 않는다. 그거 해결하기 위해서 보안전문가가 있는 거 아닌가? 내가 개발을 더 쉽고 잘하기 위해서 원래 만들려던 서비스의 목적을 잃어버리고 야크 털만 깎고 있으면 잘했다고 해주나? 개발 열심히 잘했다고? 개발 자체가 목적이 아니라 서비스(혹은 무언가)를 만드는 게 목적이므로 그 중간은 어찌 되었든 내가 알아서 해결하고 결과물이 나와야 하는 거 아닌가?
덧) 왜 개발과 보안이 붙으면 항상 개발 쪽이 지는 걸까....

My Comment..
해당 포스팅을 읽으면서 내 상황과 많이 비교하게 되었다.. 아무래도 금융권쪽에 있다보니 보안이라는 부분과는 악어와 악어새 같은 입장이라고 해야될까.. 업무적인 롤이 되었건 인간관계적인 측면에서건 말이지.. 비교하는 부분이 좀 잘못된 걸수도 있는데 순간 딱 떠오른게 그렇다.. ㅎㅎ..

난 개발이라는 것을 처음 할 때 보안이라는 개념이 없었던 것 같다.. 그냥 아웃풋만 내면 되는거 아닌가..?? 라는 생각을 많이 했는데.. 지내다보니 표준, 취약성, 개인정보 관련 등등 무엇인가 엄청 많더라.. 그런데 그것의 정점을 찍은 것이 현 업무라고 생각한다.. 물론 더 높은 보안 수준도 있겠지만 최소한 내가 경험한 범주에서는 그러하다..

나는 햄의 글과 좀 비슷한 생각이 들기도 하고, 갈팡질팡하기도 한다.. 우선 과거 경험을 얘기해보면, 예전에 우리나라에서 나름 제일 크다고 하는 전산센터에 출장을 간일이 있었다.. 거기서는 보안 이슈 때문에 가방은 물론 호주머니까지 다 검사를 했으며, 담배 안에 무엇이 있는지도 검사했다.. 심지어 라이터는 압수를 했는데 어찌보면 사람이 문제를 일으킨다는 관점에서 물리적인 보안 점검을 그렇게 한다면 이해는 간다 당연히 불편하긴 하지만..

위와 같이 생각을 하면, 보안은 당연히 철저해야된다고 생각이 되기도 한다.. 문제가 생기면 결국 고생하는건 당사자가 되는 것이고 그로인해 문제의 영향도가 어디까지 파생될지 모르니 말이다.. 근데 또 한편으로 SW 개발적인 부분에서 다가서자면 특정 시스템 또는 특정 명령어에 대해서 다 제약을 걸어버리는 경우가 보안의 보편적인 룰일 것이다..

여기서 문제가 개발은 해야되고, 테스트도 해야되고, 오류가 있으면 확인해야될 자료가 있고 그런 것인데 그런 부분이 다 막히거나 특정인에게 요청해서 다시 피드백을 받고 그런 방식을 고수하면서 개발 데드라인은 과거와 똑같다..??? 이런것이 또 하나의 문제라면 문제 같다.. 얘기를 하다보니 이게 참.. 양면 색종이 같다..

보안을 생각하면 최대한 막는 것이 맞지만, 업무의 효율성을 위해서는 풀어주는게 좋고말이지.. 흠..;; 현재 업무하는 곳에서는 이제 어느정도 익숙해지긴 했지만 모든 보안이란 것이 어느 한쪽에 너무 치우쳐서 양극화를 만들어내기보단 그 중간을 유지하는 것이 결론적으로는 제일 좋은 것 같다.. 그 중간.. 중립을 유지하는게 제일 어려운것이 또한 문제긴 한다..

햄이 맨 마지막에 왜 항상 개발쪽이 지는 것일까.. 라고 했는데.. 글쎄 이부분은 현 시점에서는 다 그런건 아닌듯하다.. 머 일하다보면 대부분 지는거 같긴한데.. 그래도 과거와 비교한다면 많이 좋아진 것 아닌가 하는 생각을 살짝해본다.. ㅎㅎㅎ

2017년 2월 10일 금요일

[Book] 나는 공짜로 공부한다..


출처 : Outsider's Dev Story https://blog.outsider.ne.kr/


나는 공짜로 공부한다 - 10점
살만 칸 지음
김희경.김현경 옮김
알에이치코리아(RHK)

교육은.. 어린 시절에 이루어져야 하지만, 어떤 강요도 있어서는 안 된다네. 강요로 얻은 지식은 마음에 남지 않기 때문이지. 어릴 때의 학습은 오락처럼 이루어져야 하네! 그래야 아이의 타고난 소질을 더 잘 발견할 수 있을 것이네. - 플라톤, "국가론"

이 책은 칸 아카데미를 만든 살만 칸(Salman Khan)이 쓴 책으로 현재의 교육에 대한 비판과 함께 교육이 어떻게 되어야 하는가에 대한 자기 생각과 함께 거기에 맞춰서 칸 아카데미가 어떻게 만들어지고 어떤 시도를 하고 있는지에 대한 책이다. 살만 칸은 유튜브에서 사촌 동생한테 수학을 가르쳐주다가 소위 떠서 다니던 회사를 그만두고 현재의 칸 아카데미를 만들었다. 관심 있다면 살만 칸이 TED에서 한 발표도 볼만하고 jQuery를 만든 존 레식도 현재 칸 아카데미를 다니고 있다. 정확한 전후 관계는 자세히 모르지만, 현재 수많은 교육사이트의 시작점이 칸 아카데미가 아니었나 생각하고 있다.
서비스의 성격상 내가 칸 아카데미를 사용하고 있지는 않지만, 칸 아카데미에 대해서 처음 알게 되었을 때부터 관심이 있었기에 살만 칸의 책이 나왔다길래 읽어보았다. 처음 칸 아카데미에 대해 들었을 때 좋은 인상을 받고 있다가 동영상으로 각자 공부하고 교사가 학생들이 어느 부분에서 어려움을 가졌는지를 시스템에서 확인하고 수업시간에는 교사가 이를 지원하거나 그 부분에서 어려움이 없었던 다른 학생이 도와주게 하는 교육에 대한 영상(다큐였나..)을 보았을 때는 너무 멋져서 반해버렸었다. 처음에는 그냥 칸 아카데미에 대한 관심과 칸 아카데미가 만들어낸 교육적 혁신에 대해 더 자세히 알고 싶어서 보았지만, 책을 읽고 난 후에는 "교육은 어떻게 되어야 하는가?"에 대한 더 진지하게 고민하게 되었고 기존에 너무 당연하다고 생각했던 많은 부분에 대해서 다시 생각해 보게 되었다. 개인적으로 자녀가 있으신 분들은 한 번씩 읽어보면 여러모로 도움이 될 거라고 생각한다.

책의 초반부터 과거의 교육 방식은 완전히 수동적인 학습방법이고 세상은 점점 능동적인 정보처리 방식을 요구하기에 교육방식에서 천 년에 한 번꼴인 전환점이 왔다고 믿기 때문임을 밝히고 있다. 이는 과거에는 어쩔 수 없는 부분이 있다고 하더라도 지금은 기술의 발전으로 인해서 더 나은 교육방식으로 바꿀 수 있는 시대가 왔다는 의미이다.


우리는 그들이 실패하도록 설정해놓고 있다.

이 책에서 여러 가지를 얘기하고 있기는 하지만 가장 큰 것은 사람들은 서로 다른 속도로 배운다라는 부분인 것 같다. 지금의 교육은 모든 학생을 똑같은 속도로 가르치고 있기 때문에 배우는 속도가 느린 학생들(전체적으로 느리거나 특정 부분에서 느리거나)이나 개인적인 이유로 일부 과정에서 등한시한 학생들은 이전 부분을 이해 못했기 때문에 뒤로 갈수록 점점 뒤처지게 된다. 여기에 현재 교육시스템을 이들에게 등급을 매겨서 학생들이 좌절감을 느끼게 하고 배움의 기쁨을 잊어버리게 한다는 것이다. 그래서 살만 칸은 완전학습을 주장한다. 현재의 교육은 70~80점 정도로 진급을 결정하는 데 이는 반대로는 1/4은 모르고 있다는 의미인데 살만 칸은 여기에 반대하고 각자 다른 속도로 배울 수 있게 하지만 하나의 개념을 완전히 이해하고 다음 개념을 이해하도록 한다는 것이다. 여기서 또 하나는 모든 지식은 서로 연결되어 있고 사회에서는 이 연결관계가 중요한데 교육과정에서는 각 부분을 따로 끊어서 관리하므로 학생들도 서로 간의 연관관계를 맺는 기능을 갖지 못한다는 것이다. 그리고 학생들은 원래 수동적이지 않다.는 것이다. 그래서 학생들이 배우는 모든 단계에서 학습에 적극적인 자세를 취하도록 격려받아야 한다는 것이다.


정상이란 당신이 익숙한 것이다.

물론 여기에 숙제, 방학, 시험 등에 대해서 자세한 설명을 자세하게 있다. 이렇게 간단히만 적어놓으면 자칫 이상론으로 보일 수도 있다. 하지만 이 책을 읽으면서 그런 생각이 들지 않는 것은(현실적인 어려움은 별개로 하고) 실제로 칸 아카데미가 이를 현실로 만들고 있기 때문이다. 수년 동안 살만 칸이 칸 아카데미를 통해서 교육시스템에 대해서 고민하면서 실험한 대부분의 내용이 들어있고 실제로 해낸 결과(매우 잘 된 결과라 할지라도)가 있기에 이 책에서 살만 칸이 말하는 내용을 힘이 실려있다.


천재성은 물론이고 창의력을 가르칠 수 있는지는 모르겠다. 그러나 확실히 억압할 수는 있다.

그렇다고 책이 어렵지는 않다. 생각해 볼거리는 엄청나게 많을지언정 어려운 내용은 없고 번역도 잘 되어 있어서 술술 읽힌다. 대신 책 제목은 정말 최악이라고 생각한다. 원제는 The One World Schoolhouse: Education Reimagined인데(책 내용 중에는 한세상 학교라고 번역한듯하다) 이 제목을 "나는 공짜로 공부한다."이라는 싸구려식으로 지은 데는 정말 분통이 터질 정도이다. 누가 책 제목을 지었는지 모르겠지만, 책의 가치를 전혀 보여주지도 않고(공짜라는 거의 상관도 없다.) 이 좋은 책은 아주 평범한 책으로 만들어 버렸다. 서점에서 책 제목을 보고 이 책을 읽을 사람이 과연 있을지 의심이 들고 책 제목을 보고 읽어본 사람은 왠지 낚였다는 생각이 들 것 같다.

오랜만에 좋은 책을 읽어서 기분이 좋다. 초기에 칸 아카데미를 보았을 때 이 좋은 서비스를 국내에선 어떻게 할 수 없을까? 라는 생각을 하면서 서비스를 찾아본 적이 있었는데 zziuni님을 통해서 현재 칸 아카데미에 대해서 꽤 많은 번역이 이뤄지고 있음을 알게 되었다.(나중에 참고해볼 것 같아서 일단 기록!)



My Comment..
해당 글을 보다보니 다른 것보다 하나의 문장에 눈에 들어왔다.. "사람들은 서로 다른 속도로 배운다" 라는 문장인데.. 햄은 아마 다른 의미에서 해당 문장을 집중했을지 모르겠다.. 그런데 난 아이가 태어나고 그 아이를 바라보면서 요즘 부쩍 교육, 정치, 사회 전반적인 문제에 관심을 많이 갖고 있다..

왜냐면 내 아이가 자라나서 지낼 환경들이기 때문이다.. 그런 점에서 볼 때 우리나라의 교육은 무척 잘못됬다고 생각하며, 본문에 지적해준 몇몇 부분은 공감을 상당히 하게 된다.. 나도 그랬지만 다 이해하지 못하고 넘어가고, 남들이 다 넘어가니 나도 휩쓸려서 넘어가고, 결국에 돌아서보면 어떤 것 하나 이해하지도 못하고 기억에 남지도 못한다..

같으 개념으로 볼 수 있는 것인지는 모르지만 우리나라의 교육 자체도 해외처럼 좀 여유있는..?? 가르침의 방식으로 바뀌었음 좋겠다.. 급하게 많은 것을 어린 나이에 빨리 가르치기 보단 아주 작은 것 하나를 가르치더라도 스스로 이해하고 개념을 확실하게 잡으면서 넘어갔음 좋겠다..

아마도 내 아이도 학교에 들어가면 그렇게 배울 것이다 빠르게 빨리 빨리 더 많이.. 같은 시간에 이해를 못하면 못난 사람이 되고, 부족한 사람이 될 것이다.. 우리 나라의 현실이 그러하니 말이다.. 남들보다 못하면 다른것이 아닌 부족한 사람이 되버리니.. 참 안타깝다..


내가 과연 얼마나 지금의 생각을 나중에도 유지할 수 있을지는 모르겠지만.. 혹시라도 추후에 이 글을 다시 보게 되면 생각하자.. 내가 지금 이렇게 생각했다는 것을.. 그리고 우리 아이를 이해하려고 마음 먹었던 것을.. 기억하자..