KT S/W DEVELOPER CONFERENCE 2019
in Trend
트렌드 파악 및 개발자 취업 정보를 얻기 위한 KT 개발자 컨퍼런스 참가 후기
KT 소프트웨어 개발자 컨퍼런스는 KT 소프트웨어개발단의 옥경화 단장님의 말씀을 시작으로 시작되었습니다. 5G 시대를 맞아 내부적으로 많은 변화를 도모하고 있으며 특히 애자일과 데브옵스를 반영하기 위해 노력하고 있다고 하셨습니다.
개발자 컨퍼런스는 옥경화 단장님 이 후로 2개의 키노트와 3개의 트랙으로 구성되어 소프트웨어 개발자 관련자들에게 많은 도움이 될 수 있는 강의들이 있었습니다. 1트랙은 5G와 관련되어 있었으며 2트랙은 KT의 소프트웨어 테크놀로지, 3트랙은 KT의 기가지니와 관련된 AI 강의들 이었습니다.
KeyNote1: KT SW개발 추진 전략 및 방향, 조성은 상무님
조성은 상무님은 IOT 플랫폼 개발 담당 및 스마트 서비스 개발 담당을 하고 계셨으며 KT는 5G 상용화와 더불어 134년 대한민국 통신역사 주도하는 곳이라고 말씀하셨습니다.
또한 현재 KT의 소프트웨어 개발 추진 전략 및 방향에 대해서는 기존의 안전성과 효율 보다는 고객의 가치와 속도, 그리고 내재화된 SW 플랫폼 역량 중요 하다고 강조하셨습니다. 끝으로 소프트웨어의 중요성이 강조되고 있는 시대인만큼 KT 내부에서도 소프트웨어 개발역량 향상에 대해 중점을 두고 있다고 하셨습니다.
- SW핵심 분야 개발 역량 축적
- IOT, AI, GIS(Geo master, One Navi), 5G 몰입형 미디어(Real 350, e스포츠 Live), 5G Connected Car
- SW Ready-made 프레임워크
- Pizzeria Framework,
- 개발자 문화
- 애자일 개발 문화, 소통하는 애자일 컬쳐, 코칭, 쏘단 컬쳐웨이브(외부 기술 교류, 시니어 주니어 만남, 개발자 실패케이스 공유 등)
KeyNote2: 한국에서도 애자일과 DevoOps 할 수 있다 IBM Korea 공진기
애자일과 데브옵스를 잘하는 방법에 대해서 애자일이 도입되게 된 배경과 애자일과 데브옵스에 방해가 되는 요소를 개인과 팀, 회사차원에서 분석해주셔서 개발자를 희망하는 일원으로서 지녀야 할 태도와 기업과 팀에서 목표로 두어야 할 문화에 대해 알 수 있던 강의었습니다.
애즈일은 기존 소프트웨어 개발 방법론에서 워터폴 방식의 대안으로 요구분석 설계 만들고 검증, 관리, 기존의 배치방식이 오래걸리고 검증이 오래걸린다는 단점을 탈피하기 위해서 등장했습니다. 그러나 조금씩 만들고 확인하는 애자일 방식 한국에서 적용은 쉽지 않았다.
데브옵스는 개발과 운영의 접합으로 개발팀이 운영되는 서비스를 지속적으로 관리함으로써 결함 및 오류에 대한 대처를 포함하여 더욱 기민하게 발생하는 문제들을 처리할 수 있습니다.
한국에서 애자일과 데브옵스를 방해하는 블로커들을 정의하고 이를 극복하기 위한 컴퍼니, 팀, 개인의 역할을 알려주셨습니다. 분명히 한국에서는 외국의 문화를 바로 적용하기 어려운 부분이 있지만 개인의 차원, 팀, 회사 차원에서 블로커들을 제거하는 방법을 계속해서 도모하여 효과적으로 애자일과 데브옵스를 적용할 수 있도록 해야한다고 하셨습니다.
Tools - SCM (Source Control Management)
데브옵스나 애자일에 대한 의지를 표방
회사 - 비트버켓, 깃헙 엔터프라이즈 팀 - 깃랩, git branch 관리 전략 수립 개인 - 깃 커맨드 공부, fit -svn
깃을 안쓴다면 발전할 의지가 없는 것이다. 회사가, 팀이 하지 않더라도 개인으로 git을 사용하는 태도가 필요하다.
Tools - Editor Company - IntelliJ IDEA / PyCharm 개인 - ATOM, Visual Studio Code
기존에 익숙한 도구들을 뿌리치고 새로운 것을 받아 들일 수 있는지가 중요하다.
Tools - Issue & Communications
보고서, ITSM, Groupware -> Company - Jira, Confluence, slack Team - Redmine, 개인 메신저 사용 지양 개인 - 시스템 숙지 및 효율적 이용
보고를 위함이 아니라 관련된 내용들이 개발자에게 추적 행위를 하기 쉽다. 개발이 생산성 있고 재미있게 된다.
Development & Environment
망분리, 개발서버, 개발 랩탑,
Company - 개발용 외부 망, 소스반출 검토, 클라우드 K8s 적극 도입, 개발용 Mac 지원 Team - 팀내 proxy repo 구성, 자동화/툴 도입&개발
폐쇄망에 의존하는 경우 docker나 npm등 기능을 사용할 수 없음, 툴들이 리눅스 아니면 맥기준으로 나오므로 맥을 쓰는 것이 개발생산성에 도움이 되고 생각보다 소스 자체는 중요하지 않고 관리나 끌고가는 것이 중요함.
Open & Share
부서, 팀간 경쟁 -> 전사 표준
Company - 개발 공유문화 장려(상대평가를 지양, 안좋은 사례를 공유할 수 있도록), 사내 소스코드 오픈(소스코드가 그렇게 중요하지 않다, IBM에서도 다른 오픈소스를 보며 아키텍쳐와 트렌드를 공부함), SAML, OAUTH, 사내 API 공개(IBM은 인트라넷 관련 API 공개 되어있음)
Team - 타 팀의 Best Practice 활용, Lesson learned 공유
개인 - 팀 내 기술 스터디, 기술 교류
Organization & KPI
복지부동 - 조직 내 혁신을 원하지 않는 조직 상부 -> 별동조직 팀을 만들어서 사보타주 방지 KPI - 장애시간, 장애횟수, 일부러 안정적인 것을 추구 하지 않음,
Company - Matrix 구성 및 평가, SCM / issue 툴 통한 정량 평가 별동조직 도입 - 팀을 넘어서 비슷한 Role을 가진 직원들을 모음 ex) DBA, FrontEnd 개발자, UX기획자
Team - MTTR, 배포횟수 등 도전적 KPI 리포팅 도구 활용
Structure
갑 (발주사) 을 (구축사 SI, 운영사 SM) 병 (협력사) 이러한 산업구조가 데브옵스를 막는 가장 큰 문제로 담당자가 개발을 하지 않습니다. 데브옵스의 강점은 운영과 개발이 연동되는 것으로 개발 따로 운영하는 사람 따로라면 데브옵스가 의미가 없습니다. 외국의 경우 갑의 기업도 반 정도는 개발자를 투입하기 때문에 외주형태의 SI 개발이라도 데브옵스가 가능한 측면이 있습니다. 쉽게 배울수 있는 환경이 된만큼 스스로 학습하고 내 움직임이 회사를 바꿀 수 있다는 인식을 해야합니다.
Track3 session1
GiGA Genie Eco; AMK + GenieBLock, GiGA Genie Inside
박성준 책임연구원, 딥러닝 쪽, GPU 인프라구축(클러스터)
기가지니 스피커 - 음성인식, 음성합성, 자연어처리, 추천, KT가 통신회사지만 솔루션들이 오래전부터 연구개발 해왔다. AI 인공지능 스피커가 뜨면서 관련 연구들이 빛을 발하게 되었다. 6~7년전 연구 결과, 기가지니 스피커의 핵심 엔진으로 들어가게 됨,
써드파티에서도 음성 API들을 활용할 수 있도록 패키지화, 예제, 관련 어플리케이션 제작 등, 음성인식 서버, 음성 합성 서버, 각각 의 서버로 통신, 패키지화 하여 앞에 게이트웨이를 두고 써드파티 단말에서는 게이트웨이를 통해 통신하도록 개선, 관련 내용들이 문서화되어 잘 사용되고 있음,
Ai Makers Kit - 인공지능 스피커 장난감, 라즈베리파이 기반 스피커& 마이크& 음성처리 칩, 클라우드 AI API를 잘 사용할 수 있는지 Best Practice를 만들기 위해 깃허브에 모두 공개함, 관련 예제를 찾아보면 간단한 나만의 AI 스피커를 만들 수 있음,
AI Voice Kit + 라즈베리 파이 -> AI MAKERS Kit 개발자가 직접 조립 및 코딩을 통해 자기만의 AI단말/서비스를 제작할 수 있도록 H/W와 인공지능 API 제공
AMK 소개 - 관련 가이드 및 예제 문서화 잘 되어있음, API를 사용할 수 있는 인증키를 발급,
스마트 쓰레기통에 활용한 사례가 있음, 음성으로 쓰레기통이 뚜껑이 열리는 정도,
기가지니에서 바로 음성 서버를 접속하는 방식에서 서비스처리(음성서버, 대화서버, TTS서버) 게이트웨이를 두는 패키지화를 함,
딥러닝 기반 호출어 학습을 위해 연구원님들이 많은 테스트를 수행함, 커스텀 호출어 학습을 연구 진행 중,
호출어 인식 예제 음성 인식 예제 - GRPC 프로토콜 사용, 기가지니 RPC 라이브러리화 음성인식의 어려운점, 주변 환경에 따라 인식율이 매우 차이가 남, 상태코드 200 인식중, 201 인식완료 몇 줄안되는 코드로 음성합성, 음성인식을 만들 수 있음 자연어처리 - 명령어로 장치제어는 가능하나 대화는 패턴규정이 어려우므로 미흡한 점이 있음
https://github.com/gigagenie/ai-makers-kit 블록코딩 개발 환경 구축,
GiGA Genie inside 써드파티 단말에서 기가지니 서비스를 이용할 수 있도록 지원하는 시스템,
기가지니 SDK가 써드파티 단말에 들어감, 음성데이터를 스트림으로 클라우드 플랫폼 전달, 리턴받은 값을 단말에서 처리
모바일 앱 전용 SDK, 리눅스를 비롯한 거의 모든 OS 지원
서비스 제공 2가지 기가지니 기본 서비스 써드파티 특화 서비스
좋은 코드를 만들고 싶으나 데드라인이 있어서 그러기가 힘들다, 요구사항이 제대로 명시되지 않은 사항에서 대략적으로 일이 진행됨,
Track2 Session2
쿠버네티스 기반의 5G-V2X mediation cluster 개발
김성화 대리님 커넥티드 카 플랫폼, 자율주행 플랫폼 Mediator 개발,
5G V2X 자율주행 플랫폼 개발, V2X : Vehicle to Something, 자동차가 보행자, 인프라, 다른 차량과 연결된다
기본 차량 한대의 인식범위로는 정보범위가 제한됨, 인프라(신호등), 사람(비보호좌회전) 등 연결되어 더욱 많은 정보를 얻을 수록 다양한 환경에 대응 가능,
V2X wave 로드 사이드 유닛을 사용한 통시느 6Mbps 대역폭, 별도의 플랫폼 필요 없음, 별도의 기지국 구축필요함 기지국을 많이 가지고 있으니 이것을 활용해서 V2X를 활용할 수 없을까, C-V2X(셀룰러 기반) 기존 기지국 활용, 새로운 플랫폼 필요함, 이 때 필요한 플랫폼 개발에 착수함,
5G 네트워크 구조 - center와 edge, 플랫폼도 edge와 center로 설계
Edge - V2V 기능 커버(차량 to 챠량), 데이터 리소스 매니징, 표준을 준수하는 메시지 규격, 모든 X의 데이터 중계 V2X Mediator - 모든 X의 데이터를 중계한다.
V2X Mediator 환경에 영향이 적은 구조, Fault Tolerance, Resource Managing에 강력, 수집과 처리, 제공이 서로 영향을 받지 않음, 필요한 메시지 셋 추가/제외가 유연한 구조
5G edge 현재 8개, 앞으로 추가 될 예정, 엣지들 마다 서버의 환경, 커널단, OS, 자바 버전이 다를 수가 있음, 따라서 환경에 영향이 적은 구조 -> 도커 컨테이너 사용, 독립된 어플리케이션 설치 가능,
Mediator의 리소스가 차량이 막힐 때가 있고 아닐 때가 있음, 탄력적으로 해야 함, 쿠버네티스를 도입하여 사용량에 탄력적으로 대처,
SAEJ2735 표준 - 다양한 규격들을 간섭받지 않고 다른 메시지 셋이 추가되었을 때 유연하게 되처될 수 있도록 처리, VERT.X 프레임워크 사용,
Chain of Responsibility Pattern 책임이 있는 객체가 있고 해당 책임에 따라 객체가 작업을 수행
Mediation cluster 많이 일하는 모듈, 적게 일하는 모듈 리스닝 하는 버티클은 상대적으로 일을 많이하고 RSA같은 버티클은 일을 적게 함, 쿠버네티스들은 사용량이 증가하면 팟 단위로 복제가 되므로 사용량이 적은 버티클들이 같이 늘어남, 효율적이지 않음
버티클은 이벤트 버스를 통해 통신, 쪼개버리니까 이벤트 버스가 다른 버티클을 찾지 못하는 상황 발생, 이벤트 버스에서 데이터를 꺼내갈 때도 문제 발생,
Vert.x의 클러스터 모드를 사용하면 물리적/논리적으로 분리되어도 문제가 없음 -> IMDG를 사용해야 함, 메모리 기반으로 움직이는 데이터 그리드, 데이터 복제 및 동기화, 각자 이벤트 버스를 갖고 있지만 하나의 이벤트 버스처럼 행동, IMDG fault Tolerance - 해결하지 못함, 타 통신사와 인터페이스화 하지 않음,
성숙도, 성능, 레퍼런스 3가지 기준으로 라이브러리를 구분, 헤이즐캐스트가 쿠버네티스의 DNS를 사용하여 컨테이너 환경에서 버티클 팟 들을 찾을 수 있음, 각자의 팟의 위치를 알수있고 데이터 통신 가능
Summary
- KT가 SW 개발에 있어서 어떤 업무를 수행하는지, KT의 인프라를 통해 어떤 개발자가 되고 어떤 업무를 수행하는 지 가늠할 수 있었다.
- KT는 대기업인만큼 조직의 변화를 도모하는 것이 쉽지 않으나 소프트웨어의 중요성을 깨닫고 전사적으로 애자일과 데브옵스를 반영하고 개발내용을 오픈하고 공유하려고 지속적으로 노력하고 있다는 것이 인상적이었습니다.
