NFV

Network Function Virtualization.

2012년에 전 세계 12개 대형 통신 사업자가 모여서 자신들이 사업하는데 불편한 점을 해결하기 위해 모임.
White Paper의 요약은 여길 참고.

- Do a single PoP/Site design based on commodity compute hardware;
Avoiding designs involving one-off installs of appliances that have different power, cooling and space needs simplifies planning.
- Utilize resources more effectively;
Virtualization allows providers to allocate only the necessary resources needed by each feature/function.
- Deploy network functions without having to send engineers to each site;
“Truck Rolls” are costly both from a time and money standpoint.
- Achieve Reductions in OpEX and CapEX; and,
- Achieve Reduction of system complexity.

근데 이건 단 2개의 키워드로 정리할 수 있을 듯

1. 돈
혁신의 속도가 빨라지면서 금방 네트웍 기술이 바뀌면 이를 위해 설치했던 전용 장비를 또 다른 전용 장비로 바꿔야 해서 투자 부담이 크다. 만일 이를 commodity H/W를 이용한다면 H/W의 재투자 없이 S/W 변경만으로 변경할 수 있으므로 비용 측면에서 유리하다.

2. 주도권
지금은 특정 기능을 제공하는 전용 장비를 NEP가 제공해야 가능하므로, 사업자가 요구하더라도 결국 NEP의 제품 개발 일정에 혁신의 속도가 맞춰질 수 밖에 없다. 만일 commodity H/W를 이용하고, Open Interface를 제공해서 특정 업체가 아닌 학계나 3rd party 업체가 network appliane를 개발/적용할 수 있게 한다면 ‘혁신의 주도권’이 NEP에서 자신들에게로 돌아올 것이다.

NFV와 SDN의 목적이 유사해 보이지만, 서로 상호 보완적이지, 의존적은 아니라고 언급. 즉 SDN을 사용하지 않고도 NFV에서 원하는 바를 구현할 수 있을 거라고. 예를 들어 그냥 x86서버를 이용하되 OpenFlow를 이용하지 않고도 스위치나 라우터는 만들 수 있다고.

하지만 2가지 혁신이 따로 진행되지는 않고, 결국 NFV에서 SDN을 이용해서 자신들이 원하는 바를 추구해 나가지 않을까? 참고로 SDN은 새로운 newtork architecture로, 1. control/data plane의 분리, 2. Centralized controller, 3. Standard Interface 를 특징으로 갖는다.

참고 사이트

글로벌 소프트웨어를 꿈꾸다

이슈관리 시스템
신입사원은 문서(50%), 프로세스(45%), 선배(5%)로부터 배운다.
Peer Review는 권장하지 마라. 이미 구현된 코드에 대한 이해없이 리뷰를 진행하면 코딩 컨벤션만 확인한다. 코딩에 필요한 요구사항/설계를 먼저 공유/리뷰하라.
Programmer -> Software engineer
기업문화가 중요. 개인적으로는 위의 것도 모두 기업 문화라고 생각됨.
버그 수, 버그 고친 수, 발견 수 등으로 평가하는 건 제대로 된 판단이 불가(p218) 그 보다는 스펙을 적는지, peer review를 하는 지, 문서 업데이트를 잘 하는지, 필요한 주석을 잘 다는지, 이슈 관리시스템을 잘 활용하는 지등으로 평가하는 것이 나을 듯. 그러나 이것보다 역시 중요한 것은 “지금 내가 하고 있는 행위가 그대로 신문에 헤드라인으로 나왔을 때 자랑스러울 수 있는가?를 기준으로 삼을 것.
아는 것만으로는 충분하지 않다. 적용해야만 한다. 하려는 의미만으로는 충분하지 않다. 실행해야만 한다.
에자일의 기법에 현혹되지 말고 그 뜻을 이해하고 적용하자.

서양 격언 “학문 없는 경험은 경험 없는 학문보다 낫다”
장자 “지식을 모으는 것은 오물을 모으는 것과 같다”

이슈 관리 시스템 – 글로벌 소프트웨어를 꿈꾸다

정말 좋은데 왜 안 쓸까?

p48

**중요성**
- 대시 보드 형식으로 모든 직원이 항상 모니터에 띄워놓고 모니터링. 개발자의 업무지시가 대부분 여기에서 온다. 물론 각자의 업무에 따라 tailing가능한 환면
- 출근후 이슈관리 시스템을 확인하여 현재의 상태 파악 가능. 하루의 일과 예상 가능. 경영진도 담당자를 불러서 보고 받는 것을 대체할 수 있음.
- 모든 직원이 사용. 이메일이나 전화를 이용한 이슈 전달을 최소화해야 한다. 각자 자발적으로 참여하는 것이 핵심. 특히 전화는 개발자의 생산성을 저하시키는 주범
- 이슈를 등록. 이메일, 전화 등 다른 모든 커뮤니케이션은 이슈관리 시스템의 보조 수단. 공식적인 요청은 모두 이슈 등록으로 시작
- 이슈는 발견한 사람이 등록. 대리 등록은 되도록 피할 것. 특히 윗사람이 아랫사람에게 시키지 않도록 해야 함.
- 이슈 등록은 되도록 개념 단계와 같이 초기 단계에 함. 그럼으로써 이슈 초기의 진행 과정과 내용도 기록에 남긴다.

**활용**
- 전사적으로 제품이 몇개나 되는지, 버전과 컴포넌트가 몇 개나 있는 지 확인 가능
- 현재 각 제품의 안정성, 즉 버그나 기능 요청이 얼마나 있는 지 혹은 어제 새로 발생한 심각한 문제가 있는 지 확인 가능
- 각 제품의 개발 혹은 유지보수의 진행 상태 확인 가능. 즉 다음 버전이 언제 나오는 지 몇 퍼센트나 이슈가 해결되었는 지를 알 수 있음.
- 어느 개발자 혹은 어느 부서의 업무가 과도한 지, 한가한지를 알 수 있음. 즉 관리자가 필요로 하는 많은 정보를 알 수 있음.
- DB로 관리되므로 필터를 이용하여 보고 싶은 정보를 항상 여러 각도로 볼 수 있음.

**이슈관리시스템 도입이 망설여진다면**
- 전사 커뮤니케이션의 효율성이 높아짐. 생산성이 올라감
- 전사적으로 투명성을 제공. 관리와 개발 모두의 위험요소가 줄어듬
- 온라인으로 정보를 주고받아 종이 문서 감소
- 회의가 줄어 시간 절약
- 이슈에 관한 다양한 통계 제공. 미래 개선의 근거가 됨
- 과거 이슈에 대한 모든 데이터를 저장
- 모든 임직원의 평가를 할 수 있는 중요한 데이터를 제공
- 대화, 모니터링, 투명성의 조합으로 간접결재의 기능 제공. 그룹웨어와 같은 결재기능을 대체할 수 있음.

이슈를 아무나 막 등록하면 쓰레기장처럼 되는 것이 아니는 걱정. 그러나 실상은 그 반대. 누가 정보를 앞단에서 필터링해버리면 정보의 손실이 발생. 쓰레기 정보라고 생각하는 것도 다 귀중한 정보. 이슈관리시스템은 근본적으로 그런 전제하에 생긴 시스템이기 때문에 그에 대한 모든 노하우가 들어있음.

많은 경우에 그렇듯이 지금까지 엑셀로 이슈 관리를 해왔다면 빨리 이슈관리 시스템을 도입하기 바람. 단, 잘못 시작하면 안 하는 것만 못하니 경험 있는 선각자의 도움을 받길.

경영진의 의지에 따라 이슈관리시스템은 엑셀의 대체품 정도로 전락하는 경우도 있고, 단기간에 회사의 생산성을 높이고 리스크는 낮추는 핵심시스템으로 자리 잡을 수도 있다. 경영진의 의지에 따른 임직원의 참여가 중요한데 몇 개월 걸리는 경우도 있고, 몇 년이 걸리기도 하고, 심지어 영원히 절름발이 시스템으로 유지되기도 함. 핵심은 경영진의 강력한 의지.

Smart weather app

IMG 0839

이번에 새로 설치한 앱. 파스텔 톤의 이쁘다는 점외에 다른 점이 있다면 바로 시간별 예상 기온 정보를 시계 모양으로 표현했다는 점이다.

보통 날씨 앱들은 이렇게 정보를 표 형식으로 보여주는 게 대부분.

IMG 0841

그런데 시계 모양으로 표현하니 정말 직관적이다. 화면을 클릭할 때마다 기온, 강수량, 바람 세기 정보 등이 출력된다.

단 한 가지 아쉬운 점이라면 개발자가 외국인이다 보니 국내 지리가 잘 반영되지 않는다는 점. 수원을 지정하면 검색은 되지만 기상 정보가 없어서 안된다고. 그리고 현재 위치 검색으로 찾으면 용산이라고 나오는데 그냥 서울하고 온도 차이가 좀 난다. ‘그냥’ 서울은 어디를 기준으로 하길래…

그래도 간만에 Awesome app.