아파치 Kafka 따라잡기 : 확장성과 고가용성을 지닌 메시지 브로커


일단 결론부터 말하자면 매우 실망이다...ㅠ.ㅠ
페이지 수에서 짐작을 했어야 했지만 웬만한 인터넷 자료보다 부실하다고 느껴진다.
다만 국내에서 Kafka를 단독으로 다룬 유일한 번역서인 듯하여 선택의 여지는 없지만
역시 이 책을 사보기 보다는 인터넷을 통해 블로그를 검색하는 것이 더 양질의
자료를 모을 수 있을 것이다.


그런데 문제는 amazon에서 kafka 관련 서적을 검색해도 kafka만 단독으로
다룬 책이 별로 없을뿐더러 그나마 있는 책들도 평이 너무 않좋다.
평균 별점 3개 이하...


도대체 Kafka라는 기술은 전망이 어두운 것인지 아니면 책 따위는 없어도
할 수 있는 쉬운(?) 기술인 건지...-.-


암튼 결론은 Kafka를 공부하기 위해 책을 살 필요는 없다는 것이다.

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^




1. 인공지능은 인류를 위협할 것인가, 인류에게 도움이 것인가?


일고의 가치도 없는 논쟁이다. 어쨌든 인공지능은 계속해서 발전을 나갈 것이고

때론 인류에게 도움을 것이고 때론 인류를 위협할 것이다.


?


인간 만들었고인간 만들어 것이기 때문이다.


그러면 인공지능 스스로가 스스로를 만들어가는 ?

터미네이터의 스카이넷?

매트릭스의 매트릭스?


오늘의 알파고를 보면 가능할 같다.

사실 터미네이터나 매트릭스나 영화니까 마지막에 인간이 승리하는거지

오늘의 알파고를 보니 그런 가능성 조차 여지없이 무너진다.


그러면 인공지능을 만들지 말까?

그것도 말이 안된다.


?


인간 일이니까

수십억의 인간들이인공지능 결사 반대 외쳐도

지구 어느 구석에선가의 ~ 명의 인간들은 들은 척도 하지 않고

결국 만들어 것이다.


결국 옳고 그름의 문제가 아니라 현실적으로 발생할 있은 문제들을 에측하고

이에 대비하는 것이 인공지능을 대하는 올바른 자세일 것이다.



2. 육체, 행동 그리고 아날로그


현재 인공지능에 제공되는 지식과 정보들은 모두 디지털화 데이터들이다.

게다가 정보들은 인공지능 스스로가 직접 경험한 것이 아니라 인간의 경험을

전해들은 것이다. , 간접 경험이다. 말하자면수영을 글로 배웠어요 셈이다.

이런 상황은 분명 인공지능의 한계가 되지 않을까 싶다.


원시시대로 거슬러 올라가 인간이 유인원에서 인간으로 발전해 과정을 살펴보자.

직립보행과 손의 사용.

인간들은 스스로 움직이며 미지의 세계에 부딪쳐가며 지식과 지혜를 쌓아왔다.

이렇듯 자유로운움직임’, 아날로그적인 지식까지 완벽하게 수집이 가능해야 

진정한 지식이 형성되는 것이 아닐까?


대부분의 인공지능 소재 영화에서 인간형 로봇이 등장하는 이유는 바로 이런 까닭이

아닐까?



3. 감정의 문제


인공지능을 소재로 영화들을 보면 거의 빠짐없이감정 가지고 있다.

때론 사랑을 하고 때론 그리워하고 때론 두려워하고

만일 인공지능이 감정을 가질 있다면 오히려 두려움은 반감될 것이다.

인간에게 있어 감정은 양날의 칼이다. 그런 감정을 인공지능도 갖게 된다면

사랑, 연민, 동정, 분노 등으로 인해 논리적이고 합리적인 판단을 수행할 없을 것이다.

만일 감정까지 갖고있는 인공지능을 만들어낸다면

인류는 결국 새로운 인류를 창조한 것이 되고 신의 영역에 올라서는 일이 것이다.


하지만 아무리 기술이 발전을 한다 할지라도감정 불어넣는 일은 불가능해보인다.


인공지능이 두려운 것은 일말의 감정도 없이 모든 선택을 논리에 의해 수행한다는

점일 것이다.


오늘 대국에서의 이세돌 9단도 바로 이러한 점에 적잖이 당황했다고 한다.


결국 1번에서 말한 인공지능을 대하는 올바른 자세 하나는 바로 인공지능은

감정이 없다라는 것을 명확히 인지하는 일이 것이다.



요약하자면

인공지능은 점점 발전해 것이라는

인공지능이완성되기 위해서는 인간과 같이 자유롭게 움직일 있는 육체가 필요하다는

하지만 지금의 수준에서도 인간을 위협하기에는 충분한 같다는

그렇기 때문에 인공지능으로 인해 생길 있는문제들을 미리 예측하고 대비해야 한다는 것이다

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

가만히 보니 생각보다 많은 인공지능 소재의 영화들을 봤다.

지금 기억나는 것들 몇가지, "A.I.", "I, Robot", "HER" 그리고 며칠 전 본 EX MACHINA...

물론 그 이전에도 인공지능에 대한 영화가 많았겠지만 내가 직접 본 것 중 기억에 남는것은 이정도네...


-- 가장 오래된 인공지능 로봇에 대한 기억은 아마도 커크 더글라스가 나왔던 새턴3라는 영화의 헥토르라는

로봇이 아닌가 싶다. 자신의 두뇌 소스였던 벤슨의 얼굴 가죽을 뒤집어쓰고 있던 그 그로테스크한 모습은... --

-- 터미네이터 시리즈가 있지만 뭔가 느낌이 조금 이질적 이라서 뺐다 --







소재가 소재인지라 다들 참 재미있게 봤다.

요즘 한창 인공지능에 대한 이야기가 화제거리이다.

특히나 인류 최고의 두뇌 게임인 바둑에, 그것도 세계 최강이라고 할 수 있는 이세돌 9단에게 도전을 하겠다고 나선

인공 지능이 있고 보니 관심이 안갈래야 안갈 수가 없다.


그런데 곰곰 생각해보니 왜 이전까지 이러한 인공지능 소재의 영화를 보면서도 그리 현실감을 느끼지 못한 것은 바로

'감정'의 문제가 아닐까 싶다.


심리학이나 그와 관련된 분야를 공부해본 적도 없고, 인간 뇌의 구조는 더더욱 모르고,

(그냥 내 두뇌는 휘발성 메모리와 유사하다는 것만 알 뿐이고...-.-)


그럼에도 "지능(지식)"과 "감정" 막연하게 뭔가 그 작용이나 발현이 서로 다를 것 같다는 생가...

말하자면 논리라는 것이 그 선후 관계 혹은 변수로 삼을 수 있는 다양한 객체들의 연관을 읽어 결과를 도출하는 것으로

이 것을 통한 지식의 확장은 충분히 이해를 하겠는데, 과연 감정 역시 그러한 과정을 거쳐 발생할 수 있는 것인지..


인공지능 로봇은 부모가 없다는 것에 슬픔을 느낄 것인지...

인공지능 로봇은 자신의 존재가 사라질지 모른다는 것에 두려움을 느낄 것인지...

인공지능 로봇은 자신에게 관심을 기울여주는 대상에게 사랑을 느낄 것인지, 그리고 그에게 아픔을 주었을 때 미안함을 느낄 것인지...

한 발 더 나아가 인공지능 로봇은 다른 인공지능 로봇과 유대감을 느낄 수 있을 것인지...


최근 ZDNET에 실린 우리가 알아야 인공지능 현주소 9가지라는 기사에서 보면 인공지능은 "악"이 될 수 없다고 한다.

인공지능은 단지 '논리연산을 바탕으로 그 연산의 옳고 그름을 따질 뿐 윤리나 가치의 기준을 가지고 판단을 하지는 못한다'라고 할 수 있겠다.


하지만 이 글에서 언급하는 인간보다 더 똑똑해질 수 있다는 말은 여전히 두려움의 대상이 된다.


앞으로 더 어떻게 달라질지 모르겠으나 아주 먼 과거에서부터 아주 먼 미래까지 인류와 인공지능은 "닭이 먼저냐 달걀이 먼저냐"와 같은

순환계 속에서 영원히 태어나고 사라지는 것을 반복해가는 것이 아닐까?


* 참고로 위의 영화 중에서는 가장 최근에 본 엑스 마키나가 가장 현실감 넘쳤다. 감정 보다는 지적 호기심(지적 확장)을 위해 행동하는

  모습이 진짜 인공지능이라면 저럴 수도 있겠구나 하는 생각이 들더라...

 

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

기존에 개인 업무용 iMac에 jenkins와 SVN 서버를 구축하고 사용을 하고 있었다.

그런데 개발용으로 사용하는 iMac에 서버를 구축해놓으니 리소스가 너무 후달려 아무래도

제대로 사용하기가 어려웠다.


마침 이번에 철수하는 인력이 사용하던 iMac을 그대로 사용할 수 있게 되어 서버로 사용하기로 했다.

그래서 개발용 iMac에 있던 각종 서버들을 서버용 iMac으로 옮기기로 했다.

(사실 iOS만 개발할 것 같으면 OSX Server를 사용했을텐데 안드로이드도 함께 개발하다보니

 역시 jenkins가 가장 나은 선택인 것같다.)


안드로이드 설정이야 별 어려움 없이 진행했다. 추가로 N’SIQ Collector 플러그인까지 설치하고,

(추후 PMD까지 설치 예정)


문제는 iOS였다...

개발 PC에 구축만 해놓고 한동안 사용을 안했는데 그 사이에 관리해야 할 앱이 하나 추가된 것이다.

문제가 되는 상황은 기존 앱은 하이브리드 앱으로 외부 라이브러리 문제로 Xcode 5.1.1에 SDK를

6.0밖에 사용 못한다는 것이다. 그리고 후에 추가된 앱은 네이티브로 개발된 앱으로 최신 버전의

SDK를 사용 가능하다.


결국 각각 빌드 시 해당 프로젝트에 맞는 SDK를 이용해서 빌드해야 하는데 이 방법을 몰랐던 것이다.


우선 Xcode를 2개 이상 설치한 상황에서 디폴트 Xcode를 선택하는 명령어가 다음과 같다는 것은 알았다.


sudo xcode-select -s /Applications/Xcode.app

sudo xcode-select -s /Users/khiin/Applications/Xcode5.1.1.app 


jenkins 위키 페이지에도 이 내용은 언급되어있다.


https://wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin


이 곳에 보면 Xcode를 멀티로 설치하는 방법과 디폴트로 사용할 Xcode를 선택하는 방법

그리고 런타임 시 Xcode 버전을 선택하는 방법이라는 내용이 있다.


처음에는 런타임 시 Xcode 버전을 선택하는 방법만 사용하면 될 줄 알았다.

천만의 말씀 만만의 콩떡이었다...ㅠ.ㅠ


결과적으로는 위의 2가지 내용을 조합하는 것이 방법이었다.


잡설이 길어졌으니 이만 줄이고 본론으로 가자


jenkins에서 2개 이상의 Xcode 버전을 런타임시 선택적으로 사용하여 빌드하는 방법


*** 기본적으로 jenkins에서 Xcode 빌드 설정은 완료된 것으로 생각하고 설명한다. 기본적인 jenkins에서의 Xcode 플러그인 설정

방법이 필요하신 분은 아래 주소로...


http://mazdah.tistory.com/519


1. 당연히 2개 이상의 서로 다른 버전의 Xcode가 설치된 것을 전제로 한다.


2. jenkins에서 빌드 전에 환경을 설정해주기 위해 Environment Injector Plugin라는 플러그인을 설치해준다. 



3. 각각의 iOS 프로젝트로 이동하여 구성(설정 또는 config) 화면으로 이동한다.


4. 이름과 설명 밑에 나오는 가장 위에있는 선택 옵션을 보면  Prepare an environment for the run이라는 옵션이 추가되어있다. 체크하자


5. 디폴트 상태에서 Script Content에 다음과 같이 입력한다. (파일에 등록한 후 Script File Path를 지정해도 될 것으로 믿어 의심치 않는다...-.-)



6. 일단 jenkins 설정은 끝이다. 그런데 여기서 또하나의 문제가 발생한다. 바로 sudo 명령어...현재 나는 jenkins를 standalone 형태로

    사용 중인데 이렇게 해놓고 빌드하면 위의 스크립트 실행 후 jenkins 콘솔에 패스워드 입력 프롬프트가 떡하니 나타나서 멈춘 상태로

    있다.


7. 그래서 sudo를 패스워드 입력 없이 수행할 방법을 구글링...역시 없는 게 없는 구글...매우 위험한 방법이지만 내부에서만 사용하는 

   서버이니 한 번 사용해보기로 했다. 바로 sudores 파일 편집


    /etc/sudoers 파일을 편집한다. 강력하게 접근 권한 및 소유권이 지정되어있어 잘 편집이 안된다.

   우선 Finder로 파일을 찾아가서 사용 가능한 계정으로 읽기 쓰기 권한을 준 후 편집하였다. 물론 편집 후 권한은 원위치


   대략 다음과 같은 내용이 나오는 위치로 이동하여


   # Same thing without a password

 # %wheel        ALL=(ALL) NOPASSWD: ALL


  다음과 같은 내용을 추가해주었다.


  jenkins         ALL=(ALL) NOPASSWD: ALL


  의미는 jenkins 계정으로 모든 콘솔에서 모든 명령에 대해 sudo를 이용하여 처리할 때 패스워드를 입력받지 않아도 되는

  권한을 주는 것이다. 매우 위험해보인다...-.-


8. 여기까지 하면 5번 단계의 설정에 따라 런타임 시 각기 다른 Xcode 버전과 SDK 버전을 사용하여 빌드할 수 있게 된다.


요고하느라 하루 그냥 보냈다...ㅠ.ㅠ

'IT 이야기' 카테고리의 다른 글

[jenkins] jenkins에서 멀티 Xcode 사용 설정하기  (0) 2016.01.06
블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

오늘도 열심히 구글링을 하려고 구글에 들어선 순간....

구글 두들이 케이크네...

어? 오늘이 내 생일인데...

아니나 다를까...

 

 

물론 내 계정으로 로그인 되어있으니 이런 서비스야 간단하게 할 수 있는 것이지만

하느냐 안하느냐의 차이는 상당히 큰 것이다.

 

암튼 구글에게 감사~

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

익히 아는 바와 같이 모바일 오피스는 단순히 신기술의 적용이 아닌 업무 패러다임의 변화이다.

근무시간 내내 창구에 앉아서 고객을 상대하거나 전화를 받아야 하는 영업점 창구 직원이나 
콜센터 직원에게는 모바일 오피스라는 것은 의미가 없다. 

이를 강제로 사용하도록 압박하는 것은 오히려 기존 업무에 대해서도역효과를 내고 말 것이다.

대부분의 기업에서 모바일 오피스를 주관한 부서의 성과에 집착하여 상황을 고려하지 않고 전사 직원에게
모바일 오피스 사용을 강요하는 사례가 적지 않다. 하지만 이 것은 올바른 접근법이 될 수 없다.
이렇게 해서 설치는 하게 할 수 있을지언정 활용도를 높이긴 쉽지 않을 것이다.

모바일 오피스의 전사 확장은 윈도우 업데이트나 PC 업그레이드처럼 전사 차원에서 일괄적으로 
시행해야 하는 것이 아니라 서서히 단계를 거쳐 진행해야 하는 것이다. 

예를 들면 다음과 같은 단계를 생각해볼 수 있다.

1단계
외근직 직원을 위해 외근에 필요한 기능을 중심으로 모바일 오피스를 개발하고 그 대상도 외근직 
직원으로 한정

2단계
비교적 외부 인사와의 미팅이 많은 간부들을 대상으로 고급 기능을 추가하여 간부들에게 확대 적용

3단계
외근이 없는 사무직 직원들을 대상으로 업무를 제외한 사내 활동 (경조사, 동호회 등)을 중심으로 하는
확장 시도

4단계
내근직이면서 주로 고객을 상대해야 하는 직원들을 대상으로 업무PC에 대한 보조 기능(예: ???)을 
추가하여 확장 시도

이렇듯 같은 회사라 하더라도 각각의 업무 영역과 특성이 다른 전 직원을 공통된 하나의 포맷으로 
묶으려 하는 것은 욕심이 앞선 억지스러운 진행이 될 수밖에 없다.

업무 패러다임이 많이 바뀌었다고 하지만 대다수의 기업은 여전히 전통적인 형태의 근무 방법으로 
일을 한다. 본인의 책상에 앉아 본인의 업무 PC를 이용하여 업무를 위해 개발된 소프트웨어를 이용하여 일을 하는 것이다. 

만일 이 패러다임을 변화시킬 자신이 없다면 모바일 오피스도 이 변화 이전의 패러다임에 맞게 설계가 
되고 구축이 되어야 하는 것이 맞는 일일 것이다.

즉, 모바일 오피스는 그 자체로 완결된 하나의 업무 시스템이 아닌 기존 업무에 대한 보조시스템의 역할에
충실해야 할 것이다. 마치 우리가 듀얼모니터를 사용하거나 서브 PC를 이용하는 것과 같이 PC에서의 
업무를 보조할 수 있는 독자적인 기능을 발굴해내고 이 기능을 구현하여 사용하도록 하는데서부터 시작을
해야 할 것이다.

아직 모바일 오피스에 대한 경험이 짧은 탓에 대부분의 기업들에서 어떻게 모바일 오피스를 운영하고 
있는지 구체적인 상황은 모르겠으나 우리나라 기업의 업무 행태에 비추어 보아 아직도 많은 기업에서 
시행착오를 거치고 있을 것이 눈에 선하다.

모든 업무가 마찬가지이겠지만 부디 성과중의의 과욕을 버리고 보다 합리적이고 현실적인 판단하에서
이 새로운 패러다임을 받아들일 준비를 해야 할 것이다. 


블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

예전에도 삼성 전자의 SM업무를 약 4년 정도 하였고

현재는 모 은행의 SM 업무를 3년째 하고있다.

14년 정도의 경력 중 절만이 넘는 7년이 SM 업무였다니…

아무래도 나는 SM 체질인가보다.


하지만 안타깝게도 이제서야 SM 업무를 잘하려면 어떻게 해야 하는가의 문제에 눈을 돌리게 되었다.

흔히들 SM하면 늘 반복되는 업무, 긴장감 없는 생활, SI에 비해 여유있는 근무시간 등을 떠올리게 된다.


그렇다!

대부분의 사람들이 SM는 그저 '늘 하는 일을 하는 것' 정도로 생각하고 있는 것이다.

물론 규모에 따라 장애가 발생했을 경우에 대한 긴장감이 크고 작은 차이는 있을 것이다.

하지만 그 것도 그 때 뿐…


아마 내가 불현듯 이런 생각을 하게 된 것도

너무나 널널한 SM 업무를 하고 있기 때문인지도 모르겠다…^^;;;

게다가 이런 시간에 이런 글을 블로그에 쓸 수 있다는 건 더더욱…-.-


됐고!


도대체 이 SM 업무를 잘하려면 어떻게 해야 할까?

나름 몇가지 리스트를 정리해서 앞으로 업무에 지침으로 삼아야겠다.


1. 상시적/주기적 업무에 대한 체크리스트 마련과 주기적인 확인


앞서도 언급했지만 SM이란 것이 일상적인 업무이다.

늘 같은일을 반복하는 만큼 오랜 시간 하다보면 어느 순간 형식적으로 눈길 한번 주고는

확인을 끝내는 순간이 생긴다.

명확한 체크 리스트와 이에 대한 주기적인 확인만이 이러한 관성을 조금이나마 줄여줄 것이다.


2. 담당 업무에 대한 확실한 관 리


SM의 경우 대체로 정해진 업무를 수행하지만 불특정한 업무가 불규칙적으로 오는 경우가 많다.

직원조회 화면 열심히 수정하고 있는데 일정쪽에 뭐 안된다고 연락오고, 일정 수정이 끝나기도 전에

또 메일쪽 고쳐달라고 연락이 오고…자칫하면 스케쥴링은 커녕 자신이 뭘해야 하는지조차 누락시키는

경우가 발생을 하게된다.


정기적인 업무도 물론이거니와 이런 산발적인 업무에 대한 관리가 잘 이루어져야 할 것이다.


다행이 체계가 잡혀 컨택 포인트가 단일화 되어있고 여기에서 적절히 분배가 된다면 다행이겠으나

그렇지 않은 경우는 스스로가 최소한 목록만이라도 정리를 하고 있어야 한다.


더구나 3번 항목에서도 언급이 되겠지만 자칫 본인이 관리하지 못하는 본인의 업무가 동료에게 전가되어

민폐를 끼치는 상황이 발생할 수도 있기에 최소한 자신의 업무에 대한 관리는 확실하게 해 놓아야 할 것이다.


3. 업무에 대한 전방위적인 관심


SM업무 역시 효용의 법칙을 피해갈 수 없다. 최소의 재화로 최대의 효과를 얻어야 하는 것이다.

즉 최소의 인력으로 최대의 업무를 수행해야 한다…-.-;


그러다보면 본인의 주력 업무가 아닌 다른 업무도 병행해야 하는 경우가 많다.

즉, SM은 어찌보면 수직적 지식보다는 수평적 지식을 가진 사람이 더 적당한 업무라고도 할 수 있는 것이다.


본인의 업무만도 2개 이상의 상이한 업무인데다가 운영 인력이 적기 때문에 동료가 자리를 비웠을 경우(휴가 등)

그 백업의 역할도 해야 한다.


이게 가능하려면 늘 동료들의 업무에 관심을 가지고 있어야하는 것이다.


4. 적극적인 의사소통


사실 SI같은 경우 하나의 소통만으로도 웬만한 것은 다 해결된다…바로…구글신…-.-

사람이 필요하다고 한다면 PL, PM, 옆사람 정도?


하지만 SM의 경우는 좀 다르다.

앞서 언급했듯이 컨택 포인트가 단일화 되어있으면 좀 낫다(그냥 나은 정도?)

그렇지 않다면 사방에서 (뻥 좀 포함해서)벌떼같이 전화를 해댄다.

그 중에는 공손하게 요구사항을 말하는 사람도 있겠지만

지X지X 하면서 왜 이거 안맞느냐? 왜 이거 안되느냐고 어기는 사람

밑도 끝도 없이 '해줘!'로 끝나는 사람 등등

오만가지 사람들이 다 있다.


그리고 또다시 반복되지만 다양한 업무를 소수의 인력으로 운영하다보니 외부 지식통과의

연락도 빼놓을 수 없을 것이다.


맘에 안든다고, 귀찮다고, 부끄럽다고(?) 필요한 의사소통에 소극적이 된다면

SM은 힘들어질 것이다.


실제로 현재 있는 사이트에는 개발은 좀 별로인데 이 의사소통 능력만으로 잘 버티는

특급 개발자가 있다. 이 사람은 비록 자신의 생각을 전달하는데는 좀 서툴지만 암튼

필요하다면 어디든 전화를 돌리고 의견을 교환한다. 그점 하나는(마?) 정말 존경스럽다.


5. 철저한 자기관리


조금은 이기적인 발상일지는 모르겠지만 나는 혹시 SM을 하고자 하는 사람이 있다면

이 5번 항목을 염두에 두고 하라고 얘기해주고 싶다.


운영 업무는 SI에 비해 남는 시간을 어떻게 효율적으로 사용하는가가 그 업무를 하는 기간을

가치있게 만들어줄 것인가 쓸모없게 만들어줄 것인가를 결정한다고 본다.


막말로 코딩이나 개발을 병맛으로 한다고 해도 운영 시스템 말아먹는 경우는 별로 없다.

즉 업무에 지장을 주지 않는 선에서 최대한 자신의 목표를 설정하고 그 목표에 시간을 할애하는 것이

SM 업무에서 무언가를 얻어나갈 수 있는 제일 큰 것이다.


SM 업무를 하고자 한다면 개인적인 목표 한가지를 잡고 그 목표를 이룰 수 있는 정도의 기간을

하는 것이 좋을 것 같다.


SM업무의 가장 큰 적은 관성과 타성이다.

어느 순간부터 잠시 틈나면 하는 일이라고는 무의미한 웹서핑 아니면 달콤한 꿀잠이다.

(차라리 잠은 피로회복 측면에서 좋아보인다.)


만일 SM 업무를 마치고나서 셀렉트 박스 목록 수정과 네이버 검색어 입력의 달인으로 

남고 싶지 않다면 업무 관리 이상으로 자기 관리 계획을 세워야 할 것이다.


그나저나 난 애초에 여기에 내가 만든 앱 대박날 때까지만 있기로 했는데…

아마 짤릴 때까지 여기 있어야 할 것 같다…ㅠ.ㅠ


두서 없이 쓴 글이라 과장도 있고 놓친 부분도 있고 또 잘못 알고 있는 부분도 있을 것이다.

그리고 많은 내용이 SM/SI 구분 없이 필요한 내용이기도 하고 또 사업장마다 업무마다 다른 특수성들이

있을 것이다.


이 글은 어디까지나 나의 경험에 바탕한 글이므로 이점 양해 바라고

내가 뭘 잘 아나보다하고 나한테 뭔가 질문하려고 하지 말았으면 하는 바람이다…-.-


마지막으로 이 글을 쓰는데 영감을 주신 우리 회사 정모 이사님과

정말 인간적으로는 내 스타일 아니지만 업무만큼은 FM대로하는

김모 PM에게 감사드린다.(하지만 적어도 김모 PM은 감사를 받지 못할 것 같다…)


블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

새로 매버릭스 설치하고 

OS X Server 설치하고

바로 Xcode 통합 작업에 들어갔다.


우선 bitbucket에 있는 repositary 하나 등록하고

Xcode 5에서 bot 생성하고 첫 통합을 시도했다.


떡하니 뜨는 fail 메시지...

그나마 처음 fail은 repositary 인증 설정을 잘못해서 발생한 것이었다.

쉽게 해결하고 다시 통합 작업 진행...


이번에는 통합은 진행되었으나 통합 과정중에 오류 발생...

Code Signing과 Provisioning에 관한 오류다...


요런거...




OS와 Xcode를 몽창 바꿨더니 인증서와 프로비저닝을 제대로 인식 못하나보다.

구글링을 해가면서 뻔하디 뻔한 답을 수차례 시도를 해보았으나 별무신통...

결국 개발 인증서는 새로 생성해서 해결을 하였으나 이번에는 Archive 진행하면서

배포용 인증서와 프로비저닝이 말썽...


아무래도 배포용이다보니 Revoke 버튼을 쉽게 누를 수가 없다...ㅠ.ㅠ

다시 build settings로 가서 애꿎은 Code Signing 설정만 만지작 만지작...


지루하니까 결론만 말하면 다음과 같은 세팅으로 해결 봤습니다.



심플하네요...


밸류를 선택하면 프로비저닝 선택 리스트가 뜨던것도 많이 줄어들어서 현재 사용 가능한 것만 딱 뜨네요.

Xcode 4.5까지는 너줄하게 뜨는게 보기 싫긴 했는데 이렇게 간소화 되니 또 뭔가 빠진듯 아쉽기도 하고...^^;;;


암튼 이 설정으로 해결 봤습니다~

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

한국시간으로 지난 10월 23일 새벽 2시에 애플의 새 OS인 Mavericks(OS X 10.9, 이하 매버릭스)가 정식 출시되었다.

다양한 기능 개선과 추가로 맥 사용자들은 오래전부터 매버릭스가 출시되기를 고대하고 있었다.


*자세한 기능은 … http://www.apple.com/kr/osx/whats-new/


그 기다림의 끝에서 아주 반가운 소식과 함께 매버릭스가 출시되었는데…

바로 '무료 배포'라는 것이다.


그런데 애플 개발자 사이트에 등록한 개발자들에게는 또 하나의 선물이 있었으니…

OS X Server가 그것이다.


원래 OS X Server는 라이언 버전까지는 OS에 통합되어 일반 데스크탑용 Lion과는 달리

OS X Lion Server라는 별도의 OS로 판매가 되었다. 마치 윈도우 Server와 같은 개념이다.

그러던 것이 Mountain Lion으로 오면서 아예 OS X Server라는 서버 모듈만을 별도로 분리하여

판매를 하게 되었다. 즉, Mountain Lion을 데스크탑에 쓰다가 별도로 OS X Server를 구매하여

설치하면 바로 서버 버전의 OS가 되는 것이다. 기존 OS X Server의 가격은 $19.99이다.





이 OS X Server를 개발자들에게 무료 배포한 것이다.


그런데 이상한 점이 있다.

일반적인 개발자들이라면, 특히 애플 기반의 개발자들이라면 특별히 서버 모듈같은 것은 사용할 일이

없을텐데…


어쨌든 공짜니까! 양잿물보단 훨씬 좋으니까! 일단 다운로드 받아 설치를 해보았다.

그리고 서버 관리 콘솔을 실행시켜 찬찬히 보다보니….그 전에 보지 못했던 것들 중 유독 하나가

눈에 띈다.


Xcode…




상세한 도움말도 지원한다.




그렇다! 이번 업그레이드를 통해 OS X Server에 맥 OS 기반의 개발 IDE인 Xcode가 통합된 것이다.

용도는 CI(Continuous Integration)이다.


프로세스는 이렇다.


서버 콘솔의 Xcode 항목에서 Repositary(SVN과  Git 지원)를 등록한다.

사용할 이름과 URL 그리고 인증 방식을 선택하여 입력하면 된다.







Xcode IDE에서 등록된 Repositary와 연동되는 BOT을 다음과 같이 생성한다.


1. Scheme(빌드 대상)과 이름 및 서버 선택



2. 빌드 스케쥴과 빌드시 수행할 액션 그리고 빌드 전에 clean 수행 여부를 설정



3. 빌드 성공 혹은 실패시 메일을 전달 받을 메일 주소 설정




이렇게 설정해 놓으면 BOT 생성시 등록한 스케쥴에 맞춰 프로젝트 환경에 따라 빌드, 분석, 테스트, Archive 및

최종 커밋까지 자동으로 수행이 된다.


이렇게 진행된 작업은 Xcode IDE 내에서나 웹을 통해 그 결과를 확인할 수 있다.


Xcode 화면





web 화면





사실 CI는 소스코드 무결성 유지와 테스트 및 빌드 그리고 최종 생산품 제출에 이르기까지

그야말로  개발 전과정에 대한 통합이 이루어지는 시스템이다.  이러한 과정에서 개발자들은 보다 신속하게

빌드를 진행할 수 있고 보다 빨리 소스 상의 오류를 감지할 수 있게 된다.


이러한 막강한 기능과 역할에 비해 다른 개발 시스템에 비해 관심도가 그리 높지 않은 형편이다.

꽤 역사가 오래된 Cruise Control부터 최근의 Travis까지 다양한 Tool들도 존재한다.

자세한 내용은 위키피디아 참조 : http://en.wikipedia.org/wiki/Continuous_integration


현재 일하고 있는 곳에서는 Jenkins(구 Hudson)를 사용하고 있는데 Jenkins도 MAC 환경하에서

Xcode 빌드를 지원하여 iOS 개발자로서는 매우 유용하게 사용을 하고 있다.

그런데 새로운 OS X Server와 Xcode5에 이러한 기능이 통합되어 MAC/iOS 개발자들은 최적화된 환경을

제공 받을 수 있게 된 것이다.

(다만 나는 아쉽게도 안드로이드도 함께 관리를 해야 하는 입장이어서 jenkins를 버릴 수는 없다)




(맥 OS X 상에서의 jenkins를 이용한 CI 시스템 구축은 다음 링크를 참조 : http://mazdah.tistory.com/519)


애플은 가장 앞서서 개발자-벤더-사용자가 통합되는 IT 생태계를 만들어왔다. 이 생태계를 통해 이익을 얻는

사람들이 많겠으나 그중 가장 이익을 얻고 있는 것은 개발자가 아닌가 한다. 그리고 그걸 증명이라도 하듯이

애플은 개발자들에게 더 나은 환경을 제공해주고 있다.


비록 국내에서 아이폰의 점유율이 높지 않아 OS X 기반의 개발자들의 입지가 좁아지고 있는 것은 사실이지만

이런 개선들이 지속적으로 이루어진다면 앞으로의 전망은 밝을 것으로 기대된다.

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

글 이전일 : 2013/05/03 15:50 


최초 작성일 : 2008.12.10

많은 소규모 SI업체들이 상황이 어려워질 때마다 입버릇 처럼 하는 말이 있다.

'솔루션 하나 만들어야지...'

사실 영업에 전적으로 의존을 하여 프로젝트를 수주하는 것으로 연명하는 소규모 SI업체에게 있어서
하루 하루가 불안한 연속이 아닐 수 없다. 그래서 안정적인 회사 운영의 기반으로 그럴 듯한
제품 하나 만들어서 팔아먹는 것은 마치 은행에 큰 돈을 예치하고 여유있게 이자를 타먹는
아주 여유로운 기분일 것이다.

하지만 모두 알고있거니와
SI업체로 시작해서 쓸만한 솔루션을 만든 회사는 아직 본 적이 없다.
얼핏 수많은 프로젝트를 거치면서 쌓이 Knowhow를 통해 무언가 그럴듯한 솔루션이 나올법도 한
SI업체에서 제대로 된 솔루션이 나오지 않는 다는 것은 역설적인 상황으로 보인다.

하지만 대기업 SI업체들이 시작을 독식하는 상황에서 중소 SI업체가 외도를 할 만한 여유를
갖는 것 또한 상상하기 힘든 현실이다. 아무리 기존 인력을 활용하여 최대한 비용을 줄인다
하더리도 솔루션 개발이 그리 싸고 빠르게 이루어지는 것이 아닌만큼 중소규모의 SI업체에서
자체적으로 솔루션을 개발한다는 것은 쉽지 않은 것이 사실이다.

그럼에도 불구하고 SI업체로서 솔루션 개발에 손을 대고 싶다고 한다면 자신들이 수행한
프로젝트의 Knowhow를 축적하고 이를 분석하여 명확한 타겟과 기술을 설정하고 이를 통해
외부적으로 투자를 받는 것이 가장 확실한 방법이 될 것이다.

가장 중요한 것은 'Knowhow를 축적하고 이를 분석'한다는 것이다.
'솔루션'이란 말 그대로 어떠한 '문제'에 대한 해결책인 것이다.
문제도 알지 못하는 데서 해결책이 나올 수는 없다. 이런 점에서 다양한 영역의
다양한 문제를 정리하고 분석한다는 것은
솔루션 개발의 출발점이자 가장 중요한 부분이라 아니할 수 없다.

이렇게 출발점이 정해졌다면 다음으로는 2가지 방향이 있다고 본다.
하나는 이미 출시된 제품을 벤치마킹하여 보다 나은 기능의 새 제품을 만들어 내는 일,
또 하나는 중장기 플랜을 설정하여 전혀 새롭고 혁신적인 기술의 제품을 만들어 내는 일이다.

첫 번째의 경우는 모델로 삼을 대상이 존재하고 기존의 시장 영역도 있기 때문에 기술적인 실패의
위험은 적겠지만 선발 업체와의 경쟁이 쉽지만은 않을 것이다.

두 번째의 경우는 전혀 새로운 제품을 만들어낸다는 점에서 기술적인 투자에 많은 부담이 생길
것이고 새로운 시장을 개척해야 하는 위험이 있으나 일단 성공을 하게 되면 선발업체로서의
입지를 굳건히 세울 수 있을 것이다.

정작 가장 중요한것은 경영진의 의사 결정이다.
이제까지 말한 준비 단계 및 방향성에 대해 숙고하고 결정을 내려야 하며
일단 결정을 내린 후에는 과감하게 추진을 할 수 있어야 한다.

어설프게 '솔루션이나 한 번 만들어 볼까?' 하는 안이한 생각으로는 시간과 돈의 낭비
그 이상도 이하도 아닌 것이다.

어플리케이션 개발이 그렇듯이 이러한 사업의 진행 또한 충분한 시간을 통해 분석을 하고
설계를 하여야 그 진행이 탄탄해 지고 결과 역시 만족스러울 것이다.

이제 SI 분야만 남은 우리 회사역시 끊임없이 솔루션 개발에 대한 문제제기는 있어왔지만
단 한번도 성공적인 결과를 남긴 적이 없다. 외부 그룹웨어를 인수하여 판매를 해보았으나
결과는 좋지 않았다. 그도 그럴 것이 아무리 개발팀을 함께 인수했다고 하나 단지 유지 보수를
위한 인력일 뿐 그 솔루션의 미래에 대한 고려는 전혀 없다시피 했기 때문이었다고 생각한다.

여기서 또 하나 추가할 수 있는 내용은 바로 '솔루션의 미래'다.
만들어놓기만 하고 관리를 하지 않은 솔루션이라면 그야말로 사생아일 뿐이다.
기술은 계속 변화하며 기술의 변화는 사회의 변화와 상호 작용하며 주변의 많은 것들을
변화시킨다.

이런 변화의 소용돌이에서 변화를 따라가지 못하는 솔루션이란 일회용 종이컵에 불과한 것이다.

두서 없이 이야기가 길어졌다.
세줄 요약으로 마무리를 짓겠다...^^;;;

1. '솔루션'의 정의를 명확히 하고
2. 문제 상황을 축적, 분석하여 방향성을 잡아서 개발하며
3. 끊임 없이 업그레이드 되는 솔루션을 만들어야 한다.

부디 성공적인 솔루션이 탄생하기를...

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

Tag 솔루션