System Compleat.

'YZCerberos'에 해당되는 글 231건

  1. 직업 3
  2. Quagga - Simple Router for Linux
  3. sg3_utils 3
  4. 제 1권력, 히로세 다카시
  5. 조직과 업무, 그리고 제품

직업

Stories
(younjin.jeong@gmail.com, 정윤진)

국내에서 일을 하다 보면, 참 많은 사람들을 만나게 된다. 국내에서 컨설팅에 대해 가지고 있는 의견들이 각각 있겠지만, 아무래도 나는 기술 컨설팅이기 때문에 내 입으로 뱉은 말은 적어도 구현이 되어 돌아가는 모습을 보여주어야 하는 경우가 많았다. 뱉어 놓고 동작 안하면 그건 곧 신뢰의 상실이기 때문에, 가급적이면 첫 대면에 해법을 주려고 노력하는 편이다. 하지만, 뭐 도둑놈들 이라는 시각을 내가 그게 아닙니다 할 수는 없을 것 같기도 하다.

Consulting

Image source: http://www.hayderisk.com/userimages/svc_consulting.jpg

실리콘 밸리의 벤처와 일을 본격적으로 한지 대략 1년여가 흘러가고, 그 사이에 많은 벤처 및 그들의 솔루션에 대한 소개 자료들을 받아서 검토해 보면서 느낀건, 참 일하는 방법들 많이 다르구나 싶은 생각이 들 때가 많다. 실리콘 밸리의 벤처 및 그들 업체의 기술자라고 해도 각양각색 천차만별이어서, 누구는 정말 대단하기도 하고, 어떤이는 또 그 반대의 경우도 많다. 사실, 그 반대의 경우가 더 많거나, 아니면 일반적으로 보편적인 수준의 기술자들이 참 많은데 이들이 우리나라 기업과 일을 하게 되면 필요 이상의 신뢰를 확보하는 경우를 많이 보게 된다.

이게 참 어떻게 보면 신비스러운 부분인데, 나름 찬찬히 생각해 보니 이건 일반적으로 국내 기업과 해외 기업이 함께 일하게 되는 경우 한국 회사간의 갑-을 관계가 전혀 발생하지 않는 경우가 많기 때문으로 생각된다. 컨설팅이라는건 기본적으로 도움이 필요한 조직에 적재적소의 도움을 제공하기 위해 행하는 일련의 작업임은 누구나 알고 있다. 여기에 더하여 생각 해 보면, "작업의 의뢰" 란 결국 "도움의 요청"이며, 이 도움에 "댓가"를 지불하기 때문에 실제 업무 관계에 있어서는 오히려 영향력이 외부업체에 더 많이 실리게 되는, 한국 회사간의 관계에서는 참으로 찾아 보기 힘든 사태들이 발생하게 되는 것이다. 더군다나 이 도움을 주는 주체가 외국인을 주축으로 구성되었다면, 도움에 대한 대가는 수직 상승 하게 된다.

이는 역으로 이야기 해 본다면, 같은 한국 회사들 간의 협력에 보통 상하관계가 형성 되는 것이 올바른가 하는 이야기도 될 수 있을 것이다. 이런 현장에서 직접 뛰고 있는 분들 중에는, 실제 개인적인 인간관계에 있어서 별 문제없는, 아니 오히려 친근해 보이기까지 할 수 있는 사람이 외국인을 주력으로 구성된 컨설팅 팀에 대하는 태도와, 필요한 물품을 납품하는 국내 업체의 인력들을 대하는 태도가 극히 상반되는 모습을 보이는 경우를 많이 목격해 왔다.

왜 그럴까? 

좀 다른 이야기지만, 얼마전 샌디에고의 퀄컴 본사에 입사한 커널 엔지니어이자 친한 친구의 이야기를 들어보면, 해외와 국내, 더 정확하게는 미국과 한국의 기업들이 사람을 채용하는데 필요한 요구조건을 확인하는데 굉장히 다른 방법을 사용한다고 한다. 우리나라는 일종의 스펙 공화국이라고 할 수도 있겠는데, 따라서 국내 1위의 대기업이라고 해도 인터뷰는 보통 이력서를 중심으로 구술하는 형태로 진행 된다. "어디서 뭐했구요, 뭘 배웠구요, 토익은 몇점이고 자격증은 뭐를 가지고 있어요" 로 대변되는 인터뷰의 형태. 하지만, 1차 전화 인터뷰, 2차 현장 인터뷰의 형태로 진행되는 미국 회사들의 면접의 경우, 이력서는 1차에서 이사람이 무엇을 했었는지에 대해서만 확인하고, 2차에서는 실무적인 내용에 필요한 질문을 해당 업체의 엔지니어들과의 만남을 통해 이 사람이 정말 그 내용을 알고 있는지를 확인 한다. 따라서 인터뷰의 내용은 대략 "MMU를 소프트웨어로 어떻게 구현할 수 있을까요", "barrier()와 wmb()의 차이점에 대해 이야기 해 보세요" 와 같이 굉장히 실무적으로 디테일한 질문들을 장장 7시간에 걸쳐서 받게 된다. 그리고 대답도 보통 5초 이내에 시작하지 못하면 "알겠습니다" 되는 분위기 속에서. 그 녀석은 원체 대단한 녀석이라 그 수많은 질문 가운데 대답하지 못했던 것은 단 하나 였으며, 따라서 미국에 비자도 없고, 국내에서 내노라 하는 대학을 졸업한 것도 아닌데, 오퍼는 미국 현지의 아이비 리그 박사 수년차의 대우를 받고, 하고 싶은일 하게 되었다는 해피해피 스토리를 들려주었다.

난, 여기에 많은 답이 있지 않을까 싶다. 이녀석은 틈만 나면 재미로 커널 코드를 보는 녀석이고, 어셈블러따위는 국딩때 즐겨 사용 했던 놈이었던 거다. MIT에서 특수한 목적으로 만든 드라이버에 버그가 있으면 고치고, 커널에 버그가 있으면 고치고, 재미있어 보이는 각 대학 및 오픈 프로젝트에 코드를 반영하는, 그래 그녀석은 분명히 난 놈이었다.

근데 그런 난놈이 국내에서는 그닥... 으로 치환되었었다. 하긴 그녀석 국내 있을때도 그닥.. 레벨은 아니었긴 하지만. ㅋ 이제는 그닥... 으로 대접 받지는 않겠지.


다시 돌아와서, 결국은 이러한 여러가지 사회 문화적 인프라의 차이로 인해 발생하는 해외 근로자와 국내 근로자의 차이, 조직에서 사람을 채용하는데 필요한 것이 과연 무엇인가에 대한 관점의 차이가 프로젝트를 하는데 있어 이게 되냐 마냐를 결정하는 주요한 차이를 가지게 되기 때문에, 높은 비용을 지불 하게 될 수밖에 없게 되며, 갑이 갑이지만 을로서 오버라이드 되는 현상도 나타나는 것이다.
 
하고 싶은걸 계속 하고 또 그래서 여가의 시간마저 좋아하는 것에 투자할 수 있다면, 당연히 다른 사람보다 많은 성취를 이룰 수 있게 될 것이다. 그게 다만 해외에서 더 많이 인정을 받게 될 가능성이 다분하기는 하며, 국내에서는 스펙에 좌절하고, 대기업 문턱을 밟지 못해 눈물을 좍좍 흘리게 될 지도 모른다. 무엇을 어떻게 선택하고 해야 할런지는 본인의 판단의 몫이지만, 결국 일에 필요한 사람은 저런 녀석이 되는게 아닐까.

너무 일반화 하지 않았나 싶은 생각도 들지만, 그게 전반적인 감상인 것도 맞는듯 하다.

개인이 취할 수 있는 가장 최선의 선택은, 해외의 좋은 학교를 졸업하고 거기서 좋은 직장을 얻거나, 한국에 돌아와 거부 할 수 없는 스펙으로 승리를 쟁취하면 되지 않겠나. 굳이 한국에 돌아와야 할 필요가 있겠냐마는. 그럼 어떠한 이유에서라도 그렇게 할 수 없고, 심지어 국내의 좋은 학교도 힘들었다면, 어떨까.

두서 없는 글의 나만의 결론은, 하고 싶은게 있어서 그걸 직업으로 선택하려면 엄청나게 잘 할 수 있어야 한다, 그런 거 같다. 좀 못하더라도 억지로 하는 사람보다야 낫지 않겠는가.


아... 참 사는게 쉬운게 아니에요.

(younjin.jeong@gmail.com, 정윤진)


저작자표시 비영리
,

Quagga - Simple Router for Linux

Techs
( younjin.jeong@gmail.com, 정윤진) 

요새 라우터의 기능이나 성능 때문에 리눅스를 대용으로 사용 하려는 경향은 거의 없다. 하지만 Cisco 가 실리콘 밸리의 떠오르는 샛별이 되던 그 시절 즈음 해서, 아마도 ISA 버스를 사용하는 이더넷 랜카드가 대부분이던 그 시절에, LRP ( Linux Router Project ) 라는게 있었다. 지금이야 다들 Cisco 의 config를 모델로한 대부분의 상용 라우터를 사용하지만, 궁했던 그때에는 이런 리눅스 기반 라우터를 많이들 사용하곤 했더랬다.  플로피 디스켓의 추억이 떠올라 검색을 좀 해 보니, 이런 글이.  리눅스로 라우터 만들기

관련하여 LEAP (Linux Embedded Appliance Project) 라는 프로젝트도 있는데, 좀 재미있어 보이는 듯. 역시 좀 오래된 프로젝트인데, 마지막 업데이트가 언제인지는 잘 모르겠다.

http://leaf.sourceforge.net/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=4&MMN_position=18:18
http://sourceforge.net/projects/leaf/files/


아무튼 요새는 이런 정도로 사용 할 필요는 없지만, 간혹, 아주 간혹 시스템 내부에서 간단한 라우팅 프로토콜 설정이 필요한 경우가 있을 수 있다. 단순히 Static 라우팅이 아닌, rip 또는 ospf, 경우에 따라서는 bgp 정도의 구성이 필요한 경우가 있다. 이럴때 간단하게 사용 할 수 있는 도구가 바로 Quagga인데, 필요한 데몬의 조합으로 원하는 구성이 가능하다.

zebra : static 라우팅 및 인터페이스 정의
bgpd :  BGP 라우팅
ospfd :  OSPF
ospf6d : OSPF IPv6
ripd : RIP v2
ripngd : RIP IPv6


다음의 페이지에 간단한 샘플 구성이 있기에 가져와 보았다.
http://www.readytechnology.co.uk/open/bgp/loadbalanced.html

 

이런식의 이중화 구성을 사용하는데가 아직 있는지는 모르겠지만, 어쨌든 필요하면 할 수도 있는 것이므로 간단한 설정의 예제로서 참고하도록 한다.

위의 네트워크 다이어그램에서의 조건은 다음과 같다.

  • r1 과 r2 는 FreeBSD & Quagga 조합의 라우터일 수도 있고, Cisco 7204/7206 일 수도 있다. 어쨌든 분명한건 라우터이다.
  • 각 라우터는 각각의 ISP와 연결되어 있다. 
  • 2950 스위치 2대는 각각 서로 다른 사설 네트워크로 구성되어 있다. (192.168.1.0/24 , 192.168.2.0/24)
  • 이 조직은 외부 서비스 연결을 위해 공인 IP 블럭을 가지고 있다. 각 내부 호스트들은 루프백 인터페이스에 /32 넷마스크의 공인 IP를 하나씩 가지고 있다. 따라서, NAT 구성이 반드시 필요하지는 않다.
  •  각 서버는 리눅스로 동작하고 있으며, 이들의 커널은 Equal Cost Multi-Path 라우팅이 활성화 된 상태로 컴파일 된 것을 사용한다. 이는, 커널이 라우팅 테이블에 다수의 기본 게이트웨이를 가지도록 구성이 가능하므로, 외부로 전달되는 트래픽의 분산이 가능하다. ( 커널 config 옵션은 CONFIG_IP_ROUTE_MULTIPATH=y )
  •  전체 서버에서의 기본 게이트웨이를 포함한 라우팅 구성은 절대 수동으로 하지 않는다. 대신, Quagga 를 전체 서버에 구성하도록 한다. 내부의 서버들에서는, Quagga 의 OSPF를 사용하여 라우터의 주소를 설정하도록 구성 할 것이다.
  • 각각의 라우팅이 장비의 문제 등으로 인해 사용이 불가능한 경우에는, OSPF 프로토콜에 의해 5초 이내로 장애가 감지되며, 이후 라우팅 테이블에서 해당 경로를 삭제한다.
  • OSPF를 사용하여 장애를 감지하는 것이 최선 일 수 있다. 이는 OSPF 가 IP 계층을 기반으로 동작하기 때문이다. 만약 r2에 연결된 2950 에 케이블 문제가 발생한다 하더라도, OSPF는 이러한 상황을 잘 처리 할 수 있을 것이다.  

위의 구성을 바탕으로, 실제 서비스를 구성해 보면 된다. 예제에서는 데비안 리눅스를 사용하였으므로, 이변이 없다면 그냥 우분투를 사용해도 무방하겠다. 공인 IP 주소는 A.B.C.D 로 표현 되었음에 주의 하자.

Quagga 설치 
      apt-get update
      apt-get install quagga iproute

리눅스 인터페이스 설정. 당연히 우분투에서는 /etc/network/interfaces

auto lo
iface lo inet loopback
  up ip addr add dev lo A.B.C.D/32 scope global

# notice that we use `manual' rather than `static', so that we can
# over-ride the scope parameter
auto eth0
iface eth0 inet manual
  up ip link set dev eth0 up
  up ip addr add dev eth0 192.168.1.10/24 scope link

auto eth1
iface eth1 inet manual
  up ip link set dev eth1 up
  up ip addr add dev eth1 192.168.2.10/24 scope link

아래의 내용을 /etc/quagga/zebra.conf 에 구성 

      hostname www1
      password changeme
      enable password changeme

      interface lo
        ip address 127.0.0.1/8
        ip address A.B.C.D/32       (this is your server's real IP)

      interface eth0
        ip address 192.168.1.10/24
        multicast

      interface eth1
        ip address 192.168.2.10/24
        multicast

     !log file /var/log/quagga/zebra.log
아래의 내용을 /etc/quagga/ospfd.conf 에 적용 

hostname www1
password changeme
enable password changeme

interface eth0
 no ip ospf authentication-key
 ip ospf hello-interval 2
 ip ospf dead-interval 5

interface eth1
 no ip ospf authentication-key
 ip ospf hello-interval 2
 ip ospf dead-interval 5

router ospf
  ospf router-id A.B.C.D
  network 192.168.1.0/24 area 0
  network 192.168.2.0/24 area 0

!log file /var/log/quagga/ospfd.log

/etc/quagga/daemons.conf 를 수정.  set zebra=yes 및 ospfd=yes


확인

설정이 완료된 호스트를 재부팅 한다. 재부팅이 완료 되면, ip route 커맨드를 사용하여 여러개의 기본 게이트웨이가 있는지의 여부를 확인한다. 이후에는 라우터 또는 회선을 분리하여 OSPF가 잘 동작하는지 확인 할 수 있을 것이다.

위의 내용 대로 설정 했음에도 불구하고 잘 동작하지 않는다면, 다음의 내용을 확인 해 보도록 한다.

  • 커널이 Equal Cost Multi-Path 설정이 된 상태로 컴파일 되어있는지 확인한다.
  • 커널에서 Multicast 가 활성화 되어 있는지 확인한다. 또한, NIC 및 드라이버가 이를 지원하는지의 여부를 확인하도록 한다.
  • iptables 에 의해 OSPF 가 막혀 있지는 않은지 확인 한다. 만약 기존의 정책에 추가해야 할 필요가 있다면, 다음의 커맨드를 참조한다. 
    iptables --insert INPUT -s 192.168.0.0/16 --protocol ospf -j ACCEPT


이는 예제를 통해서 간단하게 살펴 본 것이므로, 보다 더 알고 싶은 경우에는 구글 검색을 해 보면 되겠다. 다음의 링크에 잘 정리된 Tutorials 가 있으므로 참조 하도록 한다.

Quagga Tutorials


( younjin.jeong@gmail.com, 정윤진)






저작자표시 비영리
,

sg3_utils

Techs
(younjin.jeong@gmail.com, 정윤진)


절대로_찾을수_없을걸_JPG

Image from : https://supcom.hgc.jp/english/img/supcom/DiskArray.jpg

 이런 저런 용도로 JBOD이 리눅스에서 굉장히 많이 사용되고 있다. 뭐 물론 계속 사용 해 왔던 분들에게는 별 문제는 아니지만, 이제 막 이런 장비를 사용하여 Swift 등을 구현하다 보면 아주 간단한 장애 디스크 하나 찾는게 골치 아파질 때가 있다.  물론 디스크 하나 찾기위해 이 도구가 필요 한 것은 아니지만, 이러한 도구 없이 X Window의 힘을 빌리기란 시스템 하는 분들 입장에서는 여간 챙피한 일이 아닐 것이다. 아, 물론 그렇게 느끼시지 않는다면 관계 없다.  살포시 디스크 매니저를 찾아 보자. 

제목에서와 같이, 이 오랜만의 포스팅은 sg3_utils 에 대한 내용을 설명한다. 아 물론, 친절하게 뭐가 뭐다 하고 설명하면 더 좋겠지만, 나는 여기서 더 친절하게 무려 sg3_utils 홈 페이지의 내용 중 가장 쓸만 하다 싶은 내용을 아예 번역을 해 버렸다. 물론 번역이 그다지 나이스한 품질은 아니지만, 일하다가 짬짬히 되는대로 써 놓은 것이기 때문에, 또 별도의 다른 번역 문서도 아직 존재하지 않는 듯 하기에 포스팅을 해 본다. 

아 물론, 각 표에 있는 내용까지 번역을 했더라면 좋았겠지만, 그닥 시간이 허용하지 않아서... 한시간 동안 완전 날림 번역이지만 그래도 영어로는 죽어도 못 보겠다 하시는 분들만 보시면 된다. 

sg3_utils 패키지는, 리눅스에서 디스크 관련 Low Level 작업을 할 때 꽤나 유용한 패키지다. 디스크가 두세개 정도 밖에 없다면 대략 무슨 디스크가 뭔 디스크인지 쉽게 알 테지만, 24개 48개 96개 이렇게 되어버리는 데다가 별도의 RAID 구성마저 하지 않는다면 골치가 아파질 것이다. 

RAID도 없이 그렇게 무식하게 디스크를 쓰는데가 어디 있냐고 물으신다면 Swift 라 답하겠어효... 

클라우드의 싸게 넣어서 준비시키고 쓰다가 쫑나면 교체해 버리고의 컨셉은 디스크 사용에도 적용되기 시작했다. 이는 바로 Swift 가 제공하는 '오브젝트 스토리지'라는 신개념 스토리지 (라고 쓰고 그냥 웹 파일 서비스 라고 읽는다) 에서는, 디스크에 별도의 볼륨 구성 없이 각 디스크를 생짜로 그냥 사용한다. 대부분의 시스템 관리자 분들 께서는 Writeback이니, ZFS의 log이니, RAID Level 이 어쩌고 저쩌고에 능통하시겠지만, 이 단순한 디스크+웹 서비스는 그 간단한 구성 만큼이나 디스크 구성도 간단하게 처리해 버린다. 

따라서 별로 되게 어려울 것은 없지만, 리눅스 그 자체의 안정성이 쵸큼 중요하게 되는 것도 이 서비스라고 할 수 있겠다. Commodity Hardware 에서 어떠한 방법으로 안정성을 구가하는가가 오히려 더 중요한 포인트가 될 수도 있음이다. 

아 물론, 우분투 LTS 버전이 무조건 안정적이다 하시는 분들도 계시고, 여기서 커널 바꾸면 세상 무너지는 줄 아는 분들도 계시긴 하지만, 그런 분들에게 이러한 Low Level 도구는 위험하므로 얼른 다른자료 찾아 보시길 권고한다. 물론, 그까이꺼 LED 따위 고장나면 바로 켜져야 하는거 아냐 하고 생각 하시는 분들 께서도 굳이 이런 난잡한 번역 읽느라 고생 하실 필요가 없음.

자꾸 새는데, 뭐 결국은 sg3_utils 로 해 볼 수  있는 것들이 많고, 보통 Production 단계 이전의 Dev나 STAG 환경에서 마음껏 가지고 놀아보는게 중요하겠다. 

각설하고, 웹 버전으로 보고 싶으신 분들은 아래의 펼쳐보기를 누르시면 된다. 
원래의 작업을 워드로 처음 해 봤더니, pdf 로 만들 수도 있어서 한번 만들어 봤다. 
번역이 좀 구려도 대충 보시라. 

sg3_utils_AUG2011.pdf

 


Swift 에 대해서는 시간이 나면 따로 포스팅을.. 


(younjin.jeong@gmail.com, 정윤진)

 
저작자표시 비영리
,

제 1권력, 히로세 다카시

Stories
(younjin.jeong@gmail.com, 정윤진)


어느덧 날이 밝아온다. 한동안 자동화 코드의 개발과 클라우드의 구조 설계등의 리뷰에 온 정신을 쏟느라 정신이 없었다. 아울러 번역중인 책의 밀린 진도를 빼느라 그 어느때보다 바쁘게 살지 않았는가 싶다.



어디의 웹 페이지에서인가, "공포스럽다" 라는 이 책을 읽은 분의 덧글을 보고 나서 책의 제목이 주는 묘한 마력에 이끌려 이런 저런 리뷰를 찾아 보다가, 결국 구매를 했다. 번역서 라는 부분도 비록 분야는 다르지만 어떤 도움이 되지 않을까 싶었던 부분도 있기도 했지만, 나와는 전혀 관계 없을 것 같은, 그리고 이전에 크게 관심도 별로 없었던 '자본'과 '권력' 이라는 주제가 다른 서적들과는 다르게 분명 어떤 매력이 있었던 것 같다.

책의 내용 및 성향에 대한 간략한 리뷰나 후기들은 간단한 검색으로 쉽게 찾아 볼 수 있다. 오히려 책을 읽는 중간중간, 또 다 읽고 나서도 머릿속을 떠나지 않는 질문들은, 비록 이 책이 말하고 있는 모든 것이 진실이 아니라는 가정을 세우더라도 발생하는 자연스러운 의문들이었다.  대충 몇 가지만 말해 보자면,

- 우리나라에 미군은 언제까지 주둔할 것이며, 그들은 어떤 목적으로 한국에 있는가.
- 국내의 자본들은 과연 그들보다 더 거대한 자본에 의해 침식당하거나 지배관계에 있지는 않는가.
- 리먼브라더스의 몰락과 이로 인한 세계경제의 곤란은 과연 예기치 못한 것이었는가.
- 미국 채권 및 달러, 그리고 금, 석유, 광물과 같은 가치 불변의 자원은 어떤 관계가 있는가.
- 내 개인의 삶은 위의 질문들에 대해 어떻게 대처해야 하며, 대처 한다고 해서 그 결과의 변화가 있는가.

뭐, 이 정도 인 것 같다. 이보다 많은 것들이 있긴 하지만, 웬지 영화 '아일랜드'의 장면이 생각나서 더 쓰는건 오바스럽지 싶다. 이들은 정치적 사상과도 관계가 없으며, 다만 나와는 크게 관계 없어 보이는 돈의 흐름이 내 처지를 결정할 수도 있지 않을까 하는 질문의 연장선이 아닐까 싶다.  단순히 음모론에 너무 빠진것 아니냐 하는 생각이 들기도 하지만, 기실 미국까지 가지 않아도 비슷한 행태는 많은 곳에서 접할 수 있기 때문에, 이 책이 주는 공포가 나와는 아무 관계가 없다 라고 말할 수 있을 처지가 되지도 못하는 것 같다. 

저자는 굉장한 사람이다.  책의 처음과 끝을 동일한 어조로 전체를 관통하는 하나의 주제를 수많은 인명과 기업의 고유명사로 부터 이끌어내고 있다. 이러한 일련의 작업은 분명 개인이 달성하기에는 쉽지 않은 것이며, 이러한 세세한 분석작업을 통해 저자가 확보한 자료는 분명 책에는 넣을 수 없었던 내용들이 더 있지는 않을까 하는 생각마저 들게한다. 


누구나 읽어서 재미지는 책은 아닌 것 같다. 다만, 흥미를 가지고 완독하게 되면 이 책의 진실성을 믿거나 믿지 않거나의 여부를 떠나서, 돈의 흐름에 따른 간결한 인과 관계를 살펴볼 수 있는 좋은 시각을 만들어 낼 수 있지 않을까. 

책의 일부 내용은 깊이 탐구하거나 그 내용을 포스팅하게되면 공격받기 십상이겠다 하는 생각도 든다.  게다가 나는 일본 그 자체에 대한 반감은 크지 않지만, "월가의 비지니스를 이해하지 못한 일본의 군국주의자들에 의한 진주만 공격" 에 대한 저자의 발언 외에 일본의 전사 및 일본 내부 자본에 대한 소개가 없는 점에 대해서는 현재 일본이 가진 경제대국의 호칭에 비추어 볼때 전혀 관계가 없지는 않을 것이라는 의문에서 자유롭지 못한 듯 하다.  

그런 말이 생각난다. "진실은 무겁다."  

좋은 번역서인듯. 

저자의 다른 책 중 한국어로 번역된 책들은 쉽게 찾아 볼 수 있다. 한가지 신기한 것은, 저자에 대한 위키피디아의 소개는 일어와 한국어로만 존재하는 듯 하며, 영문 버전에서는 찾아 볼 수 없다. 

[체르노빌의 아이들]
[원전을 멈춰라]
[왜 인간은 전쟁을 하는가]
[미국의 경제 지배자들]

저자의 후쿠시마 원전 사태에 대한 코멘트 
http://www.sheffnersweb.net/blogs/accuratemaps/announcement/fukushima-nuclear-crisis-worse-than-you-think/


공돌이의 간만의 독서라 즐거웠던 것일까. 

(younjin.jeong@gmail.com. 정윤진) 
저작자표시 비영리
,

조직과 업무, 그리고 제품

Stories
( younjin.jeong@gmail.com, 정윤진 )

오랜만에 전에 다니던 회사의 임원분과, 부사수로 뽑아 놓고 미처 데려오지는 못했던 후임, 그리고 대한민국에서 먹어주는 프론트엔드 개발자를 만나고 왔다. 오랜만의 송파 나들이는 참 일하면서 왜 그렇게 올림픽 공원에 자주 가서 머리를 식히지 못했었나 하는 아쉬움이 새록새록 떠오르는 하루였달까.

가끔 나는 복이 많은 사람인것 같다 라는 생각을 해 본다. 무엇에 그리 미쳤는지 내가 해결 할 수 있거나, 내가 무언가 이룰 수 있는 것들에 대한 갈망이 날이 갈 수록 커지기만 한다. 그로인한 수혜는 지난 수년간 한해한해 무언가 얻지 못했던 한해가 없었던 것이 아닐까. 시스템의 Implementation 이란, 한번 구축하게 되면 자주 손댈일이 없는 마치 저수지와 같은 것임에도 불구하고, 많은 기회를 통해 새로운 시스템들, 새로운 서비스들에 몸담아 그 구조를 생각하고 그 구현을 이루어 냈다. 심플렉스 인터넷을 다니던 시절부터, 기술이사님과 나누었던 수많은 이야기들, 그리고 실제 서비스에 반영할 수많은 오픈 소스들에 대한 사전 연구, 서비스 도입 여부의 타진, 관계 부서장들과의 흡연실 생활 등등등 2년이 채 안되는 기간에 했던 일이라고 하기엔 너무 많은 일들을 정말 즐겁게, 또 다이나믹하게 함께 일하는 사람들과 대화 하며 정보를 나누는, 어떻게 보면 현재 내가 어떻게 시스템을 다루어야 하는가에 대한 수많은 엔트리 포인트를 남겨주었던 회사였다. 아니, 회사도 회사지만 난 아직도 그 기술이사님을 사수로 생각한다.  뭐, 살다보니 서운하게 해 드린 경우도 있었지만.

돌이켜 생각해 보면 개념없이 남의 문제 생긴 시스템을 분석해 주겠다고 솔로 컨설턴트로 활동한 적도 많았다. 나름 5개 이상의 업체와 그들의 시스템적인 문제들, 이를테면 리눅스 솔루션의 솔라리스 포팅이라던가, HPC 클러스터의 구성, 턱시도와 오라클 관련 이슈들, 웹로직을 필두로 한 각종 WAS의 JSP 메모리 leak 추적 등. 매번 매달렸고, 매번 성공했었다. 사실 성공하지 못하면 보수 자체가 없는 것과 더불어, 계약으로 인해 엄청난 손해를 볼 수 있다는 심리적 마지노선의 역할이 중대 했을 수도 있겠지만, 가장 기본적인 요소는 호기심이 아니었을까. 어려울 것 같은 문제는 오히려 쉽게 눈에 띄었고, 쉬울것 같은 문제는 언제나 바로 옆에 있는 답을 알아내기위해 숱한 밤을 지새워야 했다. 지금 생각해 보면, 참 미쳤던게 아닐까.

그 다음 회사도 심각한 시스템/네트워크/스토리지 전반에 문제를 안고 있었고, 그 문제를 해결 하고 싶다는 욕망에 사로잡혀 입사해서 2년을 다녔다. 일본이 주 고객이었던 탓에 총체적인 문제를 해결 하기 위해 한달에 한번의 작업 공지만 허용 되었고, 따라서 모든 것을 처리하는데 총 3개월이 걸렸다. L4 이중화 설정, MSSQL SAN 클러스터, IP Aliasing 을 사용한 다수의 닷넷 서버들. 데이터 센터의 찬바람을 도와주는이 없이 혼자 3개월을 맞고나니, 무릎에 건염이라는 생전 듣도 보도 못한 걸을수도 없는 통증에 모든 작업 이후에는 일주일을 앓아 누워있기도.

그 회사를 수많았던 이유로 인해 정리하고, KT 클라우드에 뛰어든지 다음달이면 이제 만 1년이다. 컴퓨트 클라우드의 구성, 그리고 자동화, DevOps 로서의 역할, 최초 구성단계의 수많았던 시행 착오들을 거치면서 컴퓨트 클라우드 프로젝트는 마무리로 달려가고, 스토리지 클라우드에 몸담아 해외 벤처와의 일종의 가교 역할을 하다 보니, 이게 또 사람이라고 그 짧은 1년에 얻은 수확이 적지않다. 이 회사의 프로젝트가 끝나면 다음 프로젝트들이 줄 서 있고, 이제는 진정한 기술 컨설턴트로서 한발짝 한발짝 다가가고 있는게 아닐까 싶기도 하고.

그런 시간들을 보내고 나서 만난 오늘의 지인들은, 각자의 고민을 내가 함께 지내왔던 시간속에 그대로 머물러 있는채 가지고들 있었다. 조직 내에서의 인간관계, 기술 신뢰도가 떨어지는 협업 구성원들에 대한 불만, 팀의 무관심으로 인한 핵심 업무의 관계 없는 다른 팀으로의 이전 등등. 이 분들의 고민을 듣던 와중에 문득 느꼈던 것은, 지난 1년의 경험으로 다시 한번 그런 상태들을 해결 할 수 있게 도와주고 싶다 라는 것이었다. 물론, 냉정하게 이야기 해서 컨설턴트로의 방문이 아닌 이상, 즉 각 조직에 영향력을 끼칠 수 없는 레벨로의 투입은 의미가 없다. 그리고 대기업과 동일하게 발생하는 중소기업의 인력으로 인한 문제는 대기업보다 더 풀기 어려운 것도 사실이다. 인력 관리가 쉬웠어요 라고 말할 수 있는 조직은 강남의 화류계에도 없으리라.

해답없는 고민들 속에서 스스로의 미래들을 생각하는 모습은 지인들의 보다 좋은 미래에 대한 즐거운 상상으로 이어지게 한다. 어느회사건 내 등 쳐먹었던 회사가 아닌 이상 불편한 관계로 정리 했던 적이 없으며, 그 조직들에 있었던 좋은 사람들은 언제 만나도 즐겁다. 다만, 일견 불합리해 보이는 구성이라도 관리의 입장에서 조율 해야 하는 것은 쉬운일이 아닐것이며, 그 사람들 사이에 연계 되어 있는 여러가지 관계의 매듭이 꼬인데 더 꼬여있는 모습은 진정 유쾌한 광경은 아니리라.


문득, 그런 결론을 내려본다. 서비스를 제대로 만들고 싶고, 좋은 아이템을 추구하고, 잘 팔아먹을 궁리를 하는 이 모든 활동을 통해서 전체의 이익을 상승시키려는 노력을 하는 사람들은, 눈 앞의 패스워드 권한따위와 같은, 같지도 않은 이권에는 관심도 없다. 그것은 이권이 아니라 도구일 뿐일텐데, 이를 권력으로 승화시키려는 움직임은 또한 어느 조직에나 있기에 서글프기도 하다. 큰 기업에는 그들의 룰이 있고, 작은 기업에는 큰 기업이 가지지 못한 무엇이 필요하지 않겠나. 밥그릇이 소중하면 지키려고 하지말고, 농사를 더 잘 짓는 방법을 생각해는 그런 힘 말이다.

서로 다른 전문성을 가지고 있는 사람들이 모여있는, 그런 프로젝트 그룹의 힘, 또 그 전문성을 가지고 있는 사람들 아래서, 일을 어떻게 해야 잘 할 수 있는지 배워가는 후임들을 양성하는, 그런 힘들.
친하다고 전문가 제쳐두고 지 후임한테 일줘서 프로젝트 말아먹는 그따위짓 말고 말이다.


많은 생각이 드는 밤이다. 난 무슨 말이 하고 싶었던 걸까.


( younjin.jeong@gmail.com, 정윤진 )
저작자표시 비영리
,

티스토리툴바