<< Previous | Home | Next >>

[번역] 왜 소프트웨어 개발 방법론이 제대로 작동하지 않는가?

이 포스팅은 며칠 전 ycombinator의 트윗(Why don’t software development methodologies work? )을 킵해 놓았다가 좀 더 효율적인 개발에 대한 생각을 정리하고 고민하는 차원에서 번역을 진행해 보았습니다.

방법론이 재대로 작동하는지를 어떻게 알 수 있나?

방법론이 잘 작동하는지 여부는 팀 생산성, 행복, 관계 유지, 예측 가능성, 책임, 의사 소통, 일별 코드량, 맨먼스, 코드 품질, 만들어진 산출물 등 이런 기준에 따라 달라진다. 물론, 어떤 방법론도 올바른 지표를 사용해 측정한다면 잘 작동한다. 하지만, 측정 관점에서의 현실적인 문제 즉, 주어진 시간과 예산 범위 내에 요구사항을 만족시키는 그런 일관된 결과를 제공하는 방법론은 보지 못했다.

어림짐작이지만, 내가 알고 있는 대부분의 프로그래머는 같은 일을 경험하고 있다. 이 부분에서 말할 수 있는 것은 소프트웨어 개발의 모든 요소를 컨트롤 할 수 없기 때문에 소프트웨어 개발 방법론에 대한 정확한 연구는 존재하지 않는다.

이런 생각에 대해 실험을 해 보자. 2개의 프로그래머 팀이 있다고 생각하자. 모두 동일한 요구사항, 일정, 예산, 그리고 동일한 개발 환경, 프로그래밍 언어 및 개발 도구를 사용한다. 한개의 팀은 워터폴/BDUF(big design up front) 방법을 사용한다. 다른 하나의 팀은 agile 기술을 사용한다. 이 사고 실험은 분명 좋은 실험은 아니다. 개개인의 스킬이나 팀원의 성격, 그들의 커뮤니케이션 방법이 개발 방법론보다 더 큰 영향을 미치는 것은 분명하기 때문이다.

2003년 "People and methodologies in Software Development"라는 논문에서 Alistair Cockburn이 정리했는데, 사람과 사람 사이에서, 더 나아가서 순간 순간의 경과 시간 속에서 변하는 사람들의 특성은 팀의 행동과 결과에 영향을 주는 첫번째 요인이다. 그리고 서로 어떻게 잘 지내는지에 관한 문제와 직무에 관한 개인 특성의 적합도(비적합도)는 방법론에서 중요하고 프로젝트 별로 제약 사항을 만든다. 이 결과 사람들의 개인적인 특성은 일반적으로 방법론의 효과에 제한을 가하고 있다는 것을 의미한다.

우리 자신 최대의 적

내가 프로그래밍을 시작한 1970년대의 소프트웨어 개발 체계는 프로젝트 매니저, 비즈니스 분석가, 수석 프로그래머의 계층 구조로 아주 타이트하게 관리되었다. 개발 언어나 도구를 선택하는 것은 허용되지 않았다. 나는 몇개의 크고 복잡한 프로젝트에 참여하고 있었지만, 대개 위에 말한 작업 방식과 크게 다르지 않았다. 성공한 프로젝트도 있었고 그렇지 않은 프로젝트들도 있었다. 지금은 개발 언어나 도구에 따라 개발 방법론이나 일하는 방식을 프로그래머가 선택하는 것이 일반화 되고 있다. 분석가는 대부분 프로그래머 경험의 한부분이 되지 못하고 있고, 프로젝트 매니저는 "팀 리더"나 "스크럼 마스터"의 형태로 왜소화 되었고 관리자의 권한은 무력화된 채 팀의 의견을 정리하는 것 외에는 관리할 수 있는 것들이 없어졌다.

Gantt 차트, 일정, 문서를 활용한 엄격한 관리는 이해 관계자나 고객의 참여를 줄이면서 사용자 스토리를 도출했다. 지금 나에게는 괜찮은 선배들이 감독하고 있다고는 생각되는 프로젝트는 거의 없다. 놀랍게도 프로그래머들은 카우보이 스타일의 코딩(카우보이처럼 내가 룰북이라고 생각하고 개인 좋다고 생각하는 방법으로 개인기에 의존하는 코딩)으로 되돌아가지 않으려 하고 있고, 그들은 또 엄격한 방법론을 만들거나 채택했고 내가 경험한 1980년대보다 더 의식적이다. 사실 오늘날의 프로그래머는 1970년대 COBOL의 현장보다 방법론 측면에서 더 엄격하고 맹신하고 있다. 실제로 나의 최근 프로젝트는 실제 아무런 가치를 만들어내지 못하는 모범 사례나 한, 두명의 멤버가 많은 프로세스를 짊어지고 가는 그런 일상적인 프로젝트에 참여를 하고 있다.

대개 팀의 몇명이서 결정하거나, 혹은 한 명의 독재자가 결정하지만, 한번 프로그래밍 팀이 방법론을 채택하면 엄격하게 따르도록 강요받기 시작하고 곧, 종교(맹신하게)가 된다. 그 결과 소극적 공격(passive-aggresive : 누구나 알고 있지만 뼈저리게 실감하지 못해 실천에 옮기지 못하는 것)으로 인해 그 어떤 방법론이나 기술 결정보다도 생산성을 빨리 죽여버린다.

어떻게 하면 잘할 수 있는가?

내 경험상 Cockburn의 논문이나 Frederick Brooks의 "No Silver Bullet - 은탄환은 없다"에서 "개념의 일관성(Conceptual Integrity)"에 대해 언급한것 처럼 소프트웨어 개발 프로젝트는 팀 구성원중에서 키맨 한명이 구성원들에게 공통된 비전을 공유하는 것이 성공의 열쇠라는 것을 알려주고 있다. 이것은 특히 무언가의 방법론을 지칭하는 것도 아니고 유사한 프로세스가 없는 경우에도 일어날 수 있다. 일을 완료하면 모든 사람들이 프로젝트 도구에 완료라고 클릭하면 되는 그런 팀에서 일하는 느낌을 잘 알것이다. 아직도 내가 이해하기 힘든 부분은 지금보다 BDUF나 비즈니스 분석가가 있던 예전이 더 나쁜 감정을 가지고 있다는 것을 이해할 수 없다.

나는 프로그래머는 의식이나 도구보다는 동료의 말에 귀를 기울이고 동료와 함께 일하는 것에 더 관심을 가져야 한다고 생각한다. 또한, 많은 프로세스나 방법론을 회의적인 시각을 가져야 한다고 생각한다. 이렇게 되면 모든 사람들의 생산성은 마법처럼 올라갈 것이다. 아마 프로그래머에게 사교적인 스킬은 다른 사람들보다는 더 어려운것은 인지 사실이다.(반드시 그렇다고는 생각하지 않지만) 하지만, 사교적 스킬은 다른 개발 방법론을 시도하는 것보다 훨씬 더 성과를 올릴 수 있다.

개발 방법론의 맹신보다는 구성원들을 특성, 역할 등을 잘 조율하고 서로 커뮤니케이션을 통해 비전을 공감하고 내가 같은 방향으로 잘 가고있는지 전체의 흐름은 괜찮은지 등을 서로 이해하면서 진행시키는 것이 중요해 보입니다.

개인적으로 정리해 보면

  • 개발 방법론의 맹신보다는 구성원의 조합 및 개성을 잘 파악하는 것이 중요.
  • 도구에 의한 진행방식보다는 상호 소통을 통해 비전 공감하는 부분이 중요.
  • 개념의 일관성(Conceptual Integrity)이 의미하는 것처럼 누구 한명이 키메이커가 되어 전체의 혼란을 주는 요소를 잘 조율해주는 조율사가 필요.
Tags :

웹사이트 성능이 UX에 미치는 영향

웹 사이트의 성능도 UX의 하나라고 생각해야 한다는 논리가 정당성을 갖는데 좋은 근거가 되는 포스트가 있습니다. 웹 사이트 성능이 제품에 어떤 영향을 미치는가에 대한 다양한 사례를 정리한(Etsy의 Lara Swanson) Web Performance Is User Experience"가 그것입니다. 정리한 내용을 보면 아래와 같습니다.
그리고 위에 제시간 산출 근거의 링크도 정리해 두면 좋을 거 같네요.
Tags : ,

[번역] 좋은 엔지니어와 나쁜 엔지니어의 리더십

1996년 Ben Horowitz가 Netscape 재직시절에 Good Product Manager, Bad Product Manager"라는 글에 모티브를 얻어 Foursquare의 Jason Liszka가 기술인들에게도 좋은 리더십과 나쁜 리더십이 있다는 걸 정리해, "Good Tech Lead, Bad Tech Lead"를 포스팅을 했는데, 내용이 좋아서 개인적으로 내용을 번역해 보았습니다.

1. Teamwork
- Good Tech Lead
좋은 기술 리더는 팀의 성공을 자신의 성공으로 인식해 팀의 멤버 역할을 수행한다. 지저분한 일도 받아들이고, 장애물도 제거해 팀이 100%의 능률을 올릴 수 있도록 한다. 중요한 시스템의 지식이 특정인 한 두명에게 집중되지 않게 하고 자신들 팀의 기술 능력이 퍼지도록 하는 일을 한다.

- Bad Tech Lead
나쁜 기술 리더는 자기 자신을 위해 세간에 이목을 끄는 업무를 맡으며, 그 일을 통해 공을 차지해야만 동기 부여가 된다. 그리고 대규모 엔지니어링 조직의 비용으로 팀에 이득이 될만한 프로젝트에 팀원들을 일하게 하고 팀내(로컬) 최적화를 도모한다. 조직이 아닌 팀의 이익만 도모한다.

2. Technical vision
- Good Tech Lead
좋은 기술 리더는 제품의 기술적인 방향성을 위한 전체 비전을 가지고 있고 또 그것을 멤버들에게 확실히 이해시킨다. 그리고 팀원들에게 특정 기능 영역을 위임하고 그들 스스로가 의사결정을 내리게 한다. 그래서 그들 팀 멤버가 스스로가 영리하고, 서로 믿으며, 프로젝트의 중요한 부분을 차지하고 있다고 인식하게 한다.

- Bad Tech Lead
나쁜 기술 리더는 기술적인 방향을 설명하거나 명시하고 싶어하지 않고, 대신에 의사 결정을 강요한다. 그리고 도움이 되는 문서를 전파하거나 만들면서 얻어지는 효과를 배가시키는 것을 하지 않고 자신의 머리속에 중요한 제도적 지식을 유지한다.

3. Discussion and debate
- Good Tech Lead
좋은 기술 리더는 이야기를 잘 듣고, 건강한 토론을 장려한다. 팀의 토론이 결론에 도달하지 못할 경우에는 결론을 내는데 도움이 되는 생각의 프레임이나 프로세스를 설명해 준다. 그리고 필연적 결론을 가지고 토론을 하지 않는다. 그리고 위대한 아이디어가 자신을 납득할 수 있도록 마음을 열어둔다.

- Bad Tech Lead
나쁜 기술 리더는 결론이 없는 토론을 장시간 방치하고 팀의 생산성을 낮춘다. 토론을 미리 앞서 중단시키나, 혹은 이 문제는 "이미 해결되었으니"라고 말하면서 토론을 묵살한다. 팀이 올바른 결론을 내리기보다는 자신이 논쟁에서 이기는 것에 집착한다.



4. Project management
- Good Tech Lead
좋은 기술 리더는 적극적으로 리드한다. 기술적인 진척상태가 정상 궤도에 있는지 확인한다. 견적을 제시하가 위해, 중간 이정표를 설정하기 위해 팀 멤버로서 일을 한다. 관심 영역을 예측하고 문제가 발생하기 전에 그들이 해결하는 지를 확인한다. 그리고 기술적 장애물을 식별하고 장애물을 해결하도록 팀을 도와준다. 작업이 공유되는 중첩 영역을 식별하고 반대로 충분한 주의가 가지 않는 영역, 자원이 부족한 곳울 찾는다.

- Bad Tech Lead
나쁜 기술 리더는 수동적 자세를 갖는다. 권한을 위임하지만 진행 상태는 팔로우하지 않는다. 중간 이정표를 설정하지 않고 모든것이 마지막 기한까지 처리되기를 기도만 한다. 복잡한 시스템의 end-to-end 테스트를 하는 것을 런칭 전까지 기다리는 자세로 방치한다. 또한, 팀원들이 흥미롭지만, 중요하지 않는 일을 하는데 많은 시간을 허비하게 한다.

5. Pragmatism
- Good Tech Lead
좋은 기술 리더는 실용적이며, 올바로 일을 하는 것과 일을 기한까지 성과를 낼 수 있는 균형을 잘 알고 있다. 급할 땐 절차를 무시하지만 결코 게으르진 않다. 전체의 진행을 차단하는 문제를 일시적 방법이나 해결책 찾기 위해, 런칭을 위한 최소한의 실현 가능한 인프라를 구축하기 위해 자신의 팀을 격려한다. 좋은 기술 리더에게는 디테일도 중요하다. 기한을 지켜 개발하는 것과 마찬가지로, 코드 품질, 코드 리뷰, 테스트가 중요하다고 생각한다.

- Bad Tech Lead
나쁜 기술 리더는 단기적으로 시간을 절약하기 위해 지름길을 선택하지만, 이는 장기적으로 비용을 상승히키고 기술부채 더미를 쌓는 결과를 초래한다. 그리고 임기응변과 완벽을 구분할 줄 모른다.

6. Communication
- Good Tech Lead
좋은 기술 리더는 자신의 역할이 코드를 작성하는 것보다 중요하다는 것을, 효과적인 의사소통이 잡의 필수적인 부분이며, 자신의 팀을 좀 더 효율적으로 만드는데 소비하는 것이 좋은 시간 소비라는 것을 알고 있다. 또한 약간의 커뮤니케이션 오버헤드가 팀 업무를 할때는 필요하다는 것을 인지하고 있고 그들은 전체 팀의 생산성을 위해서 몇몇 개개인의 생산성을 희생이 필요하다는 것도 알고 있다.

- Bad Tech Lead
나쁜 기술 리더는 코드를 작성하는 때가 가장 생산적이라고 믿으며, 커뮤니케이션은 집중을 방해하는 것이라고 생각한다. 그들은 전체 팀의 생산성을 최적화하는 것이 아니라 그들 자신을 위해 가장 최선의 일이 무엇인지가 우선적이라고 생각한다. 그들은 리더 역할에 시간을 투입할 때에 불만을 토로한다.

7. Relationship with Product
- Good Tech Lead
좋은 기술 리더는 제품이 어떻게 작동하는지에 대해 Product Manager나 디자이너들과 대화를 한다. 겉으로는 그들의 의사결정을 되돌리는 경우도 있지만, 심적으로는 제품의 목표를 의식하고 있고, 언제 의견을 수용할지를 알고 있다. 그들은 덜 기술적인 부담을 가진 대체 제품 모형을 제안을 통해 기술적인 제약의 창의적인 해결방안을 찾아주고, PM과 디자이너에게 기술적인 리스크를 이해하는데 도움을 줘 그들 스스로가 트레이드오프(장단점)를 잘 알게 해준다.

- Bad Tech Lead
나쁜 기술 리더는 사전 협의없이 제품에 대한 의사 결정을 다른 부서에 떠넘기고 제품에 대한 오너십을 갖지 않는다. 그들은 기술 제약성으로 인해 뒤로 미루고 또한 대안이나 설명을 해주지 않는다.

8. Resiliency(대응력)
- Good Tech Lead
좋은 기술 리더는 제품 스펙의 변경이 되어도 잘 대응하며, 놀라운 상황이 와도 침착하게 반응한다. 그들은 변경사항이 일어난 곳을 예상하고 코드를 설계해 잘 대처한다.

- Bad Tech Lead
나쁜 기술 리더는 제품 스펙이 변경되었을 때 심란해 하고, 변경이 발생할 가능성이 없는 영역에서 설계를 조급하게 일반화해 버린다.

9. Personality
- Good Tech Lead
좋은 기술 리더는 느긋한 성격이지만, 중요할땐 자기 주장을 한다. 자연스럽게 개입해 리드하고 기술력과 경험을 통해 존경받는다. 그리고 항상 개선할 방법들을 찾는다. 또, 겸손하고 팀 전체의 신뢰를 높인다.

- Bad Tech Lead
나쁜 기술 리더는 대립각을 세우고 공격적이다. 자신의 타이틀이 존경과 권위를 부여 받는다고 생각한다. 그리고 피드백을 받을 때는 방어적이다. 거만하고 자신의 동료들이 열등감을 가져야 자신이 만족감을 얻는다.
Tags :

API - 사용 편이성과 오용 어려움

사실 API의 사용 편의성과 오용 어려움은 양날의 칼이다. 보통 개발자들은 사용자 편의성에 무개를 두고 겉에 보이는 API의 외향에만 신경쓰고, 가용성 확보 등의 서비스에 가장 중요한 리스크 회피를 위해서 "오용 어려움"은 잊어버리는 경우가 많다.

오늘은 이 두가지의 중요성을 떠올리는 중요한 글이 있어서 정리해서 포스팅 해 본다. 아래의 내용은 Linux 커널 개발자 Rusty Russell이 API 설계와 개발에 대한 생각을 쓴 글(APIs: "Easy to Use" vs "Hard to Misuse")을 소개한다.

API를 사용하기 쉽게 만드는 것이 API 설계의 기본적인 목표이다. 자신에게 사용하기 쉽고, 다음해도 자신에게 사용하기 쉽고, 다른 사람에게도 사용하기 쉽게 하는 것이다.

많은 목표가 "사용 편의성"과 대립하지만, 가장 다루기 어려운 것은 "오용하기 어렵게" 하는 요구사항이다. "사용 편의성"은 사용자를 유치하지만, "오용의 어려움"은 사용자를 유지하는 것이다.

이 개념을 분명하게 위해 실생활의 두 가지 예를 보자. 첫째는 "총의 안전 장치"이다. 오용 어려움은 사용의 용이성을 해친다.

두 번째는 Linux 커널의 kmalloc, 동적 메모리 할당 함수이다. 이 함수는 2개의 인자를 가진다. 사이즈와 플래그다. 가장 일반적으로 사용되는 플래그 인자는 GFP_KERNEL과 GFP_ATOMIC이다. 이 예에서는 다른 플래그는 생각하지 않는다.

이 플래그는 갑자기 가용할 메모리가 없어질 때 메모리 할당이 어떻게 되는가를 보여준다. 메모리가 해제되거나 스왑 아웃될 때까지 대기하거나(GFP_KERNEL), 바로 NULL을 반환하는(GFP_ATOMIC) 것이다. 그러나 이 플래그는 불필요한 것이다. kmalloc()은 자신이 슬립(대기)이 가능한지, 안한지를 알 수 있기 때문이다. malloc()를 구현하는데, 아무런 머리를 쓸 필요가 없고, 커널 코더는 일반적으로 쉽게 사용할 것이다. 그렇다면 왜 사용하지 않는가? [정정: Jon Corbet가 특정 설정에 있어서는 그것은 전적으로 쓸데없는 것이 아님을 지적해 주었다. 그리고 우리는 몇줄의 추가 작업이 필요하다.]

왜냐하면 원자 할당은 피해야 때문이다. 제한된 풀에서 가져다 쓰므로 실패하기가 쉬워지고 또한, 다른 원자 할당에 실패도 쉬워진다. 이러한 부담을 저자에 명시하는 것으로, 우리는 원자 할당을 발견하기 쉽고 따라서 오용이 어려워진다.

그리고 우리가 API를 오용하기 어렵게 만들고 싶다면 API 점수를 측정해야하지만, 그것은 다음 기사의 토픽으로 삼는다.
Tags :

LDAP설치 및 설정부터 jenkins, gitlab, nexus 연동까지

Google이 3rd Party용 무료 이메일을 지원하지 않은 이유로 자체 LDAP(Open LDAP)기반의 메일 서버를 운영하는 스타트업이 있을 것입니다. 저희도 내부 시스템 정비 차원에서 LDAP을 도입했습니다.

LDAP은 앞서 설명한 메일(Postfix + Dovecot) 발송/수신 서버, gitlab(소스 저장소), jenkins(빌드), nexus 등의 시스템과 인증부분을 연동해서 사용하고 있습니다.
이후부터는 LDAP을 사용하기 위한 설치 및 설정 방법을 기술합니다.

OpenLDAP 설치

- 패키지를 설치
$ yum install openldap-servers openldap-clients

$ cp /usr/share/openldap-servers/DB_CONFIG.example 
  /var/lib/ldap/DB_CONFIG
$ cp /usr/share/openldap-servers/slapd.conf.obsolete 
  /etc/openldap/slapd.conf
$ chown -R ldap:ldap /var/lib/ldap/
$ vi /etc/openldap/slapd.conf
suffix      "dc=wiseeco,dc=local"
rootdn      "cn=manager,dc=wiseeco,dc=local"
rootpw      {SSHA}XzUYgQ32mglF6HzSTnqA1Dc4Qy/Q9oFz
access to dn.subtree="dc=mail,dc=wiseeco,dc=local" attrs=userPassword
    by self write
    by anonymous auth
    by * none
access to *
    by self write
    by * read

$ chmod 600 /var/lib/ldap/DB_CONFIG
$ chown -Rv ldap:ldap /var/lib/ldap /etc/openldap/slapd.d 
$ chkconfig slapd on
$ service slapd start
$ slaptest -f slapd.conf -F /etc/openldap/slapd.d/

- slapd.conf 의 rootpw에는 암호화된 문자열 생성 방법
$ slappasswd -h {SSHA} -s password
{SSHA}XzUYgQ32mglF6HzSTnqA1Dc4Qy/Q9oFz

- index의 재구성
$ service slapd stop
$ slapindex -v -b dc=wiseeco,dc=local -f slapd.conf
$ service slapd start
$ ldapsearch -x -b 'dc=mail,dc=wiseeco,dc=local'

스키마 정의(mail.schema)

$ cd /etc/openldap/schema
$ vi mail.schema
attributetype (1.1.2.1.1.1 NAME 'mailForward'
    DESC 'forward address'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)

attributetype (1.1.2.1.1.2 NAME 'mailAlias'
    DESC 'alias address'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)

attributetype (1.1.2.1.1.3 NAME 'accountActive'
    DESC 'active or not active'
    EQUALITY booleanMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE)

attributetype (1.1.2.1.1.4 NAME 'domainName'
    DESC 'domain name'
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE)

attributetype (1.1.2.1.1.5 NAME 'transport'
    DESC 'transport'
    EQUALITY caseIgnoreIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)

attributetype (1.1.2.1.1.6 NAME 'mailQuota'
    DESC 'Mail Home Directory Max byte'
    EQUALITY integerMatch    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE)

attributetype (1.1.2.1.1.7 NAME 'mailDrop'
    DESC 'drop address'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)

objectClass (1.1.2.2.1.1 NAME 'mailUser'
    DESC 'mail user Object'
    SUP inetOrgPerson
    MUST ( transport $ homeDirectory $ accountActive 
     $ domainName $ userPassword $ mailQuota )
    MAY  ( mailForward $ mailAlias ))

objectClass (1.1.2.2.1.2 NAME 'mailGroup'
   DESC 'ML Group Account Object'
   SUP inetOrgPerson
   MUST ( accountActive $ domainName $ mailDrop ))

mail.schema 설명

- 스키마의 데이터 속성(attributetype)
속성 이름설명참조
transportSMTP의 transport 설정Postfix
domainName도메인 이름Postfix
accountActive계정의 활성화/비활성화를 TRUE/FALSE로 지정Dovecot
mailQuota사서함 용량Dovecot
mailForward포워딩 메일 주소Postfix
mailAlias이메일 별칭Postfix

- 객체 클래스
objectClass 이름설명
mailUser사용자 이메일 계정

- OpenLDAP 설정
OpenLDAP의 slapd.conf에서 mail.schema의 include함
$ vi slapd.conf
include  /etc/openldap/schema/mail.schema

데이터 준비

- TOP 트리 데이터 작성(top.ldif)
dn: dc=wiseeco,dc=local
dc: wiseeco
objectClass: dcObject
objectClass: organization
o: wiseeco

dn: dc=mail,dc=wiseeco,dc=local
objectClass: dcObject
objectClass: organization
dc: mail
o: mail

- 도메인의 데이터 작성(domain.ldif)
dn: ou=wiseeco.com,dc=mail,dc=wiseeco,dc=local
ou: wiseeco.com
objectClass: organizationalUnit

dn: ou=mimul.com,dc=mail,dc=wiseeco,dc=local
ou: mimul.com
objectClass: organizationalUnit

- 사용자 데이터 작성(user.ldif)
속성 이름설명값 예
cn전체 이름홍길동
sn
uid사용자 IDmimul
userPassword패스워드{SSHA}kb5KrdmDd0ZREoIIfz6BAe94pJvBuQeG
homeDirectory사용자 홈 디렉토리/home/mailbox/wiseeco.com/mimul
mail사용자의 이메일 주소mimul@wiseeco.com
mailForword이메일 포워딩 주소hahojin@gmail.com
mailAlias이메일 별칭webmaster@wiseeco.com
accountActive계정의 활성화/비활성화를 TRUE/FALSE로 지정TRUE
domainName소속 도메인 이름(dn의 dc값)wiseeco.com
mailQuota메일 Quota 용량 설정(M단위)100
transporttransport 기본적으로 dovecot 고정dovecot
mobile핸드폰 번호010-222-3333

$ vi user.ldif
dn: uid=mimul@wiseeco.com,ou=wiseeco.com,dc=mail,dc=wiseeco,dc=local
objectClass: mailUser
cn:하호진
sn:하
uid: mimul
userPassword: {SSHA}GO+oB9xnedb2CiOB741ZlNO6Rm/VCs+k
homeDirectory: /home/mailbox/wiseeco.com/mimul
mail: mimul@wiseeco.com
mailAlias: webmaster@wiseeco.com
accountActive: TRUE
domainName: wiseeco.com
mailQuota: 200
transport: dovecot
mobile: 010-222-3333

dn: uid=sjune@wiseeco.com,ou=wiseeco.com,dc=mail,dc=wiseeco,dc=local
objectClass: mailUser
cn:김선준
sn:김
uid: sjune
userPassword: {SSHA}zpZayqcyHJCzEUCtzbDhuSwQPOeDpbra
homeDirectory: /home/mailbox/wiseeco.com/sjune
mail: sjune@wiseeco.com
accountActive: TRUE
domainName: wiseeco.com
mailQuota: 100
transport: dovecot
mobile: 010-222-3333

dn: uid=pepsi@mimul.com,ou=mimul.com,dc=mail,dc=wiseeco,dc=local
objectClass: mailUser
cn:미물
sn:하
uid: pepsi
userPassword: {SSHA}4aHUI5Q3vCyKTOM8xxYya7/XFMVNJSv4
homeDirectory: /home/mailbox/mimul.com/pepsi
mail: pepsi@mimul.com
accountActive: TRUE
domainName: mimul.com
mailQuota: 100
transport: dovecot
mobile: 010-222-3333

작성 데이터 등록

데이터 등록은 ldapadd 커맨드를 통해 진행한다.
$ ldapadd -x -h localhost -D "cn=manager,dc=wiseeco,dc=local" 
 -w password -f top.ldif
adding new entry "dc=wiseeco,dc=local "

adding new entry "dc=mail,dc=wiseeco,dc=local"

$ ldapadd -x -h localhost -D "cn=Manager,dc=wiseeco,dc=local" 
 -w password -f domain.ldif
adding new entry "ou=wiseeco.com,dc=mail,dc=wiseeco,dc=local"

adding new entry "ou=mimul.com,dc=mail,dc=wiseeco,dc=local"

$ ldapadd -x -h localhost -D "cn=Manager,dc=wiseeco,dc=local" 
 -w password -f user.ldif
adding new entry "uid=mimul,ou=wiseeco.com,dc=mail,dc=wiseeco,dc=local"

adding new entry "uid=sjune,ou=wiseeco.com,dc=mail,dc=wiseeco,dc=local"

adding new entry "uid=pepsi,ou=mimul.com,dc=mail,dc=wiseeco,dc=local"

등록 데이터 검색

- ldap 커맨드에 의핸 사용자 조회
$ ldapsearch -p 389 -h 127.0.0.1 -D "cn=manager,dc=wiseeco,dc=local" 
  -w password -b "ou=mimul.com,dc=mail,dc=wiseeco,dc=local" -x "uid=pepsi"
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: uid=pepsi
# requesting: ALL
#

# pepsi, mimul.com, mail.wiseeco.local
dn: uid=pepsi,ou=mimul.com,dc=mail,dc=wiseeco,dc=local
objectClass: mailUser
cn:: 7ZWY7Zi47KeE
sn:: 7ZWY
userPassword:: e1NTSEF9NGFIVUk1UTN2Q3lLVE9NOHh4WXlhNy9YRk1WTkpTdjQ=
homeDirectory: /home/mailbox/mimul.com/pepsi
mail: pepsi@mimul.com
accountActive: TRUE
domainName: mimul.com
mailQuota: 100
transport: dovecot
uid: pepsi
mobile: 010-222-3333

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

- Apache LDAP Studio 툴로 조회
LDAP툴은 Apache Directory Studio™제일 좋아 보이니 다운받아서 사용하세요. 맥용, 윈도우용 다 있습니다.



외부 시스템 연동

- gitlab LDAP 연동(gitlab.yml)
  ldap:
    enabled: true
    host: 'localhost'
    base: 'ou=wiseeco.com,dc=mail,dc=wiseeco,dc=local'
    port: 389
    uid: 'uid'
    method: 'plain' # "ssl" or "plain"
    bind_dn: 'cn=manager,dc=wiseeco,dc=local'
    password: 'password'
    allow_username_or_email_login: true

- jenkins LDAP 연동
Configure Global Security>Access Control>Security Realm>LDAP 선택하고 설정 정보는 아래와 같다.
서버 : ldap://localhost
root DN : dc=wiseeco,dc=local
User search filter : uid={0}
Manager DN : cn=manager,dc=wiseeco,dc=local
Manager Password : password
Display Name LDAP attribute : cn
Email Address LDAP attribute : mail

- nexus LDAP 연동


Tags :

노땅 개발자가 가야할 길

1. 보편적 능력
알고리즘, 데이터 구조, 수학.

2. 시스템적 능력
컴퓨터 아키텍처, OS, 네트워크, 언어 처리, 프로그래밍 언어, 보안, 규약.

3. 열정적 능력
단편적 문제 해결, 각종 소프트웨어 설치, 설정 및 튜닝, 오픈 소스, 기술 트랜드.

4. 커뮤니케이션 기술
4.1 일상 생활 측면에서 긍정적이고, 상대방의 말을 잘 듣거나, 감정 이입을 잘 하거나, 맞장구를 잘 치고, 낯가림을 하지 않는 자세.
4.2 개발 측면에서 자신의 의견을 논리적으로 설명 할 수 있고, 문서화를 잘 하고, 적절한 질문을 하며, 대화 속에서 공감대를 잘 정리하는 능력.

기술 지식 측면에서.
나이 먹으면서 인터넷 서핑에서 얻은 노하우(경험치)는 주로 3번이 늘어나게 된다. 이것으로는 나이든 개발자들에게 바라는 가치를 만들 순 없다.

3번은 시간이 지나면 의미없는 것이 되어 버리는데, 이것도 내 능력이라고 기대고 있는 실정이다. 중요한 건 지나면 의미없는 기술들을 무기라고 생각할게 아니라 어떤 기술이 들어왔을 때 제대로 흡수하는 것이다. 이렇게 되려면 1번과 2번이 왜 중요해 지는지 알게 된다.

3번의 경험적 노하우에서 2번의 이해가 깊어지고 1번 지식으로 묶을 줄 안다면 나이를 먹어도 살아남을 수 있다.

커뮤니케이션 측면에서.
개발자의 대부분은 4.2부분이 중요하다고 생각하나, 실제 업무를 하다보면 4.1의 부족이 선행 경험치를 만들어 상대방에게 선입견이라는 커뮤니케이션 진입장벽을 제공하는 바, 상대방과의 대화에서는 제일 먼저 갖추어야 할 것이 바로 4.1의 생활 커뮤니케이션이다.

4.1이 안되면 또, 상대방으로부터 자율적인 피드백에 없어져 자신에게는 나쁜 습관이 자리를 차지하게 만든다. 거기에 더해 상대방과 생각이 달랐을때 과잉 반박이 자기 조절 기능을 뚫고 나오는 일이 많아진다.

미래에 아무리 개발 문화가 좋아지더라도 위와 같은 기술과 커뮤니케이션의 유연성, 경험치를 잘 조합하지 않는다면 나이든 개발자는 자기 욕심만 가득한 사람으로 존재감이 형성될 것 같다.
Tags :

혁신과 비혁신의 차이

며칠 전에 Re/code를 보다가 기업 문화에 도움이 되는 좋은 아티클 같아 킵해 놓고 았다가 주말에 짬내어 번역해 봤습니다. 제목은 "Can-Do vs. Can’t-Do Culture"입니다.

혁신은 딜레마라는 말이 딱 들어맞죠? 물론 혁신이라는 본질에 원죄(어렵다는)가 있기도 허지만, 기업이 커가면 커 갈수록 발목을 잡게 되는게 바로 혁신이죠. 이것 때문에 기울어간 회사들도 많이 있기도 하죠? 스스로 혁신에 대한 본질을 생각해 보는 것도 필요하지만, 좋은 인사이트를 통해 생각의 파이를 키워가는 것도 좋을듯 합니다.



신은 몸과 마음에 창조했고, 영혼을 채웠다. 우리가 증오를 가졌을 땐 이미 마음은 텅 빈 것이나 다름없다, 태도에서 나타난다.
- Rick Ross, “Hold On”

합리적인 사람은 세상에 자기를 맞추고, 비합리적 사람은 세상을 자신에게 맞추도록 고집한다. 따라서 발전은 비합리적인 사람에 달려 있다.
- George Bernard Shaw

최근에, 신생 기술 기업의 단점들을 다루는 기사나, 코멘트, 그리고 트윗을 쓰는 행위가 유행하고 있다. 그리고 문제가 일어난 스타트업, 성공한 기업가, 혹은 회사의 아이디어를 헐뜯는 트윗들을 보지 않는 날이 없다. 현재의 희망과 호기심 있는 스타트업 문화를 독선의 우월감으로 보이게 하는 움직임이 일어나고 있는 것 같다.

이 문제가 왜 일어날까? 왜 목소리가 잘못된 방향으로 기울어지고 있는지를 주목해야 하는 것일까? 그리고 기업의 잘못된 점보다 좋은 점을 찾는 것이 왜 중요한 것일까?

기술이란 용어는 "일을 하는 더 나은 방법"을 의미한다. 말은 간단하지만, 실행하는 것은 아주 어렵다. 정보를 저장하는 좋은 방법이나, 유통을 개선하는 방법, 혹은 친구를 만드는 더 좋은 방법을 실현하기 위해서는 오랫동안 습관화된 인간의 경험을 개선하는 것을 의미하기 때문에 매우 어렵다.

어떤 점에서 무언가를 개선하는 것은 논리적으로 불가능한 것 같다. 성서 시대부터 2014년에 이르기까지 어느 누구도 생각하지 못한 것을 우리가 똑똑하게 생각할만한 것을 만들 수 있을까? 심리학의 관점에서 발명이라는 돌파구를 찾기 위해서는 무한정 의심을 해야한다. 기술 스타트업 세계에서는 "불가능"을 상상하기 위하여 우수한 인재들이 모여들고 있다.

사람들은 벤처 캐피탈 리스트인 나에게, 작은 기업은 아주 쉽게 혁신을 실현하고 있는 것처럼 보이는 반면, 대기업들은 혁신을 어려워하는 이유를 종종 묻는다. 이 질문에 대한 내 대답은 일반적으로 상대방을 상당히 놀라게 한다. 대기업은 수많은 좋은 아이디어를 가지고 있다. 그러나 새로운 아이디어를 추구하기 위해서는 많은 계층의 직원들의 동의가 필요하기 때문에 혁신을 일으키기가 어렵다. 한명의 우수한 직원이 아이디어의 단점을 지적하면(때론 과시하거나, 혹은 권력 기반을 다지기 위해) 이것 하나만으로도, 아이디어를 죽이기에 충분하다.

그 결과로 인해, 의욕이 없는 문화(Can't Do Culture)가 태어난다.

혁신이 어려운 점은 정말 혁신적인 아이디어는 그 당시에는 나쁜 아이디어로 보여진다는 점이다. 현재까지 어느 누구도 좋은 아이디어라고 생각하지 않았기 때문에 그것이 혁신적으로 인정받게 된 것이다. 아마존이나 구글 등의 창조적인 대기업은 혁신에 의해 경영되는 경향이 있다. 래리 페이지는 일방적으로 나쁘게 보이는 좋은 아이디어에 투자하고 하지 말라고 하는 의견에는 귀를 기울이지 않는다.

이렇게 해서, 할수 있다라는 의욕적인 문화(Can-Do Culture)를 만들어낸 것이다.

몇몇 사람들은 기술 스타트업 산업계를 퇴보한, "의욕이 없는 문화"를 가진 하나의 대기업으로 바꾸려하고 있다. 나는 이 비극적인 추세를 반전하게 하기 위해, 또한, 이 도전에 맞서기 위해 이 글을 썼다.

기술을 무시하는 수사적 표현들은 최근에 시작된 것은 아니다. 때때로, 기업이나 발명이 유용하지 않다는 점에서는 부정적 비판이 때론 유효할 수 있지만, 그러나, 중요한 것은 기업이나 발명이 유용한 경우에도 부정적 비판이 종종 대국적 관점을 흐트리게 한다는 것이다. 여기에서는 아래의 두가지 역사적 사례를 통해 설명을 돕고자 한다. :

컴퓨터

1837년 Charles Babbage는 "분석 엔진"이라는 세계 최초의 범용 컴퓨터를 만들려고 했다. 이것이 현대에 와서는 튜링 컴퓨터라고 불리었다. 다르게 표현하자면, Babbage가 만들려고 했던 컴퓨터에 충분한 지원이 투입되었더라면, 이 머신은 오늘날 가장 강력한 컴퓨터가 계산할 수 있는 모든 것을 수행할 수 있었을 것이다. 이 컴퓨터가 계산 속도는 좀 더 느리고, 좀 더 큰 공간(엄청 느리고 엄청 컸을지도)을 차지했을지도 모르지만, Babbage가 설계한 것은 오늘날의 컴퓨터와 비슷한 계산 용량을 자랑했다.

Babbage는 작동하는 버전의 컴퓨터는 말들지 못했지만, 1837년에는 나무를 사용해 증기를 통해 동력을 얻도록 설계해 컴퓨터를 만드는 노력은 매우 놀랄정도의 야심찬 프로젝트였다. 결국, 1842년 영국의 수학자이며 천문학자인 George Biddel Airy가 분석 엔진은 "쓸모 없는"이라고 하며, Babbage의 프로젝트를 포기하도록 영국 재무부에 진언했다. 영국 정부는 곧바로 이 프로젝트의 중단 결정을 내렸다. 회의 주의자들에 의해 좌절되고 잊혀진 뒤 1941년에 Babbage의 원래의 아이디어가 세상에 나왔다.

그 뒤 171년 후, Babbage의 비전이 옳았고, 컴퓨터에 쓸모없는 것이 아님을 누구나 알게 되었다. Babbage의 인생에서 가장 중요한 것은 100년이나 빨리 태어난 것이 아니라, Babbage가 훌륭한 비전을 갖고 있었고 그 비전을 추구하는 의지를 가지고 있었던 것이다. Babbage는 현대에도 많은 사람들에게 큰 자극을 주고 있다. 반면, George Biddel Airy는 선견지명이 없는 미치광이로 비춰지고 있다.

전화

전화를 발명한 Alexander Graham Bell은 발명품과 특허를 당시의 전신 공급자 선두업체인, 웨스턴 유니온에 $100,000에 팔기위해 제안했다. 하지만, 웨스턴 유니언은 내부 위원회의 보고서를 바탕으로 이 거래를 거절했다. 아래에 보고서 전문의 일부를 올린다. :
"전화기는 전신선을 통해 말 소리를 전송된다고 주장했다. 우리는 소리는 너무 작고, 알아들을 수 없다는 점이 발견했다. 그리고 송신기와 수신기 사이의 전선이 긴 경우 소리가 작아진다. 기술적으로도, 이 장치가 앞으로 몇 마일의 거리를 알아들을 수 있는 소리를 보낼 수 없다고 본다.

허바드와 벨은 "전화기"를 모든 도시에 설치하는 것을 원하고 있다. 그 아이디어는 멍청한 것이다. 게다가, 전신국에 사용료를 내고 명확하게 쓴 메시지를 미국 내 모든 도시에 보낼 수 있는데, 이 볼품없고 비현실적인 장치를 누가 사용하고 싶겠는가?

웨스턴 유니언의 전기는 지금까지 전보 기술을 크게 발전시켜 왔다. 우리는 터무니없고 비현실적인 아이디어를 가지고 있는 외부 그룹에게서, 또한 실제적인 문제와도 너무 동떨어져 있어 채택할만한 이유는 전혀 보이지 않는다. G.G. Hubbard의 공상적인 예측은 매우 장및빛일지 모르지만, 무모한 상상을 기반으로 하며, 현 상황에 맞는 기술과 경제적 사실의 이해가 부족하다. 또한, 장난감만도 못한 장치의 명백한 단점을 무시하는 태도가 보인다.

이상의 사실을 감안하여, $100,000에 특허를 양도하라는 G.G. Hubbard의 제안은 분명히 비합리적이다. 이 장치는 웨스턴 유니온에게는 쓸모 없기 때문이다. 그래서 구매는 추천 할 수 없다.

인터넷

오늘날의 우리 모두는 인터넷의 중요성을 인정하고 있다. 그러나 이마저도 최근의 현상이다. 1995년 천문학자 Clifford Stoll은 뉴스 위크에 "웹 세상이 되지 않는 이유"라는 제목의 기사를 쓰고 다음과 같은 비통해하는 분석을 기록했다. :
그래서, 거기엔 사이버 비즈니스가 존재한다. 인스턴트 카탈로그를 보고 쇼핑을 할 수 있다. - 단지 제품에 커서를 맞추고 클릭하면 거래가 이루어진다. 미래엔 네트워크를 통해 항공권을 주문하고, 식당을 예약하고, 판매를 협상하게 될 것이다. 상점은 구식의 산물이 될 것이다. 그렇다면, 나의 쇼핑몰은 어떻게 한달 동안 인터넷에서의 매출보다 많은 매출을 오후 반나절만에 얻을 수 있을 것인가? 인터넷에서 신뢰할 만한 송금​​ 수단이 있을지라도 - 지금 있을수 없지만, - 네트워크는 자본주의 필수 구성 요소인, 점원을 없애버린다.
영리한 사람들이 같은 실수를 범하고 있다는 것은 무엇일까? 기술을 미래에 할수 있는 잠재력이나, 지금 할 수 있는 능력을 보지 않고 당시의 할 수 없었던 점(결점)에 집착하고 있었던 것이다. 이것은 반대론자들이 가장 범하기 쉬운 실수이다.

의욕이 없는 문화(Can’t-Do Culture)의 가장 피해자는 누구일까? 아이러니하게도 비판을 좋아하는 혐오자들이다. 아이디어와 회사의 잘못된 점에 초점을 맞추는 사람들은 두려운 나머지 다른 사람들이 어처구니 없다고 생각하는 아이디어들을 시도할 수 없게 할 것이다. 또한 그들은 질투 때문에 훌륭한 혁신가로부터 배울 수도 없을 것이다. 그리고 너무 완고해 뛰어난 젊은 엔지니어가 자신보다 먼저 세상을 바꾸고 있다는 것을 발견하지 못한다. 거기에 더해, 너무 냉소적이어서 주위 여러 사람들에게 위대한 일을 하도록 격려할 수도 없다. 결국, 후세에 조롱거리가 된다.

싫어하지 말고 만들어라.
Tags :