Offcanvas

��������� ������

‘개발자’를 알면 '접근법'이 보인다, IT 리더를 위한 지피지기 전략 6가지

모두가 그런 건 아니겠지만 개발자들은 까다롭고 급격한 변화를 꺼리기로 악명 높다. 완료할 때까지 또는 만족스러울 때까지 일을 계속하는 경향도 있다. 그렇다면 IT 리더가 해야 할 일은 무엇일까? 여기서는 무엇이 개발자에게 동기를 부여하고, 혼란을 주는지 그리고 어떻게 하면 팀에서 필요로 하는 리더가 될 수 있는지 살펴본다.     비즈니스 인식을 높여라 모든 리더의 중요한 업무 중 하나는 부하 직원에게 전략적 비전을 제공하는 것이다. 신중함과 집중력을 요구하는 일을 하는 개발자와 협력한다면 더욱더 그렇다. 개발자는 엄청난 양의 복잡성과 싸워야 하기 때문에 (그 결과) 근시안적 태도를 보이게 된다. 의욕적이고 적극적인 개발자라고 해도 그렇게 되기에 십상이다. 따라서 리더가 일상적인 코딩 작업과 더 큰 방향성을 모두 제공하는 게 특히 중요하다.  섬세한 작업이 필요하다. 진행 보고서를 요구하거나 무작정 방향을 제시하거나 혹은 최악의 경우 경로를 변경하는 등의 방식은 일반적으로 환영받지 못한다. 전략적 대화에 개발자를 참여시키는 적절한 방법은 ‘균형’이다. 여기서 ‘메타-인게이지먼트(meta-engagement)’가 중요하다. 개발자에게 이를테면 회의 횟수가 적절한지, 더 큰 목표에 어느 정도 참여하고 있는지 등을 묻는 것은 균형을 맞추는 좋은 방법이다. 또 이를 통해 개발자는 더 중요한 사안을 생각해볼 기회를 얻게 된다.  기술과 비즈니스 인식을 모두 갖춘 개발자를 양성하는 것은 리더뿐만 아니라 비즈니스 및 개발자에게도 매우 중요하다.  ‘의미’를 전달하라 전략과 비즈니스 가치는 개발자와 소통하는 데 중요하지만 ‘목적’ 또는 ‘의미’라고 부를 ‘미션’은 더욱더 중요하다. 전략은 미션을 지원하기 위한 것이다. 미션은 기업의 존재 이유(raison d’etre)다. 기업에 강력한 미션이 있는가? 미션의 핵심이 전사적으로 잘 전파됐는가? 기업의 미션은 모든 직원의 업무에 스며들어야 한다.  여기서 개발자는...

개발자 IT 리더 워라밸 개발자 경험

2022.09.20

모두가 그런 건 아니겠지만 개발자들은 까다롭고 급격한 변화를 꺼리기로 악명 높다. 완료할 때까지 또는 만족스러울 때까지 일을 계속하는 경향도 있다. 그렇다면 IT 리더가 해야 할 일은 무엇일까? 여기서는 무엇이 개발자에게 동기를 부여하고, 혼란을 주는지 그리고 어떻게 하면 팀에서 필요로 하는 리더가 될 수 있는지 살펴본다.     비즈니스 인식을 높여라 모든 리더의 중요한 업무 중 하나는 부하 직원에게 전략적 비전을 제공하는 것이다. 신중함과 집중력을 요구하는 일을 하는 개발자와 협력한다면 더욱더 그렇다. 개발자는 엄청난 양의 복잡성과 싸워야 하기 때문에 (그 결과) 근시안적 태도를 보이게 된다. 의욕적이고 적극적인 개발자라고 해도 그렇게 되기에 십상이다. 따라서 리더가 일상적인 코딩 작업과 더 큰 방향성을 모두 제공하는 게 특히 중요하다.  섬세한 작업이 필요하다. 진행 보고서를 요구하거나 무작정 방향을 제시하거나 혹은 최악의 경우 경로를 변경하는 등의 방식은 일반적으로 환영받지 못한다. 전략적 대화에 개발자를 참여시키는 적절한 방법은 ‘균형’이다. 여기서 ‘메타-인게이지먼트(meta-engagement)’가 중요하다. 개발자에게 이를테면 회의 횟수가 적절한지, 더 큰 목표에 어느 정도 참여하고 있는지 등을 묻는 것은 균형을 맞추는 좋은 방법이다. 또 이를 통해 개발자는 더 중요한 사안을 생각해볼 기회를 얻게 된다.  기술과 비즈니스 인식을 모두 갖춘 개발자를 양성하는 것은 리더뿐만 아니라 비즈니스 및 개발자에게도 매우 중요하다.  ‘의미’를 전달하라 전략과 비즈니스 가치는 개발자와 소통하는 데 중요하지만 ‘목적’ 또는 ‘의미’라고 부를 ‘미션’은 더욱더 중요하다. 전략은 미션을 지원하기 위한 것이다. 미션은 기업의 존재 이유(raison d’etre)다. 기업에 강력한 미션이 있는가? 미션의 핵심이 전사적으로 잘 전파됐는가? 기업의 미션은 모든 직원의 업무에 스며들어야 한다.  여기서 개발자는...

2022.09.20

경험 경제 시대, ‘API 설계’가 핵심 경쟁우위인 이유

‘경험’이 전부인 세상, 그렇기에 어떤 기업도 홀로 설 수 없는 세상에서 어떻게 경쟁할 수 있을까? 얼마 전까지만 해도 경영진은 좋은 제품을 생산 및 제공하는 데만 신경 쓰는 ‘사치’를 부릴 수 있었지만 오늘날의 경험 경제에서는 그렇지 않다. 오늘날 소비자와 비즈니스 고객은 직관적이고, 자동화돼 있으며, 원활한 경험을 요구한다. 이러한 경험은 제공하는 것만으로도 충분히 복잡하지만 또 다른 새로운 요소가 상황을 더욱더 복잡하게 만들고 있다.  이러한 경험을 ‘독립적으로’ 제공할 수 없기 때문이다. 다시 말해, 고객들이 원하는 직관적이고 원활한 경험은 다른 기업의 데이터 그리고 (다른 기업과의) 상호 작용을 기반으로 해야 한다. 연결된 경험을 제공할 수 있는 역량은 소위 ‘경험 경제’와 ‘API 경제’가 충돌하는 세상에서 지속적인 경쟁력의 핵심이다. 문제는 그렇게 하는 방법이다. 그 해답은 경쟁 우위를 확보하는 열쇠인 ‘API 설계’에 있다.   경험 경제와 생태계 ‘경험 경제’ 개념은 거의 25년 전으로 거슬러 올라간다. 하지만 이를 실현하기 시작한 것은 최근의 기술 발전 그리고 이 최신 기술을 사용한 변혁적인 기술 회사부터다. 한편 항상 그랬던 것처럼 모든 소비자는 거의 즉각적으로 통합되고 원활한 디지털 경험을 요구해왔다. 그 결과, 대부분의 제조 회사조차도 제품과 서비스를 제공하기 위해 기술과 소프트웨어를 활용하고 있으며, (이에 따라) 다양한 기회와 과제가 제시되고 있다. 이러한 진화로 ‘애플리케이션 프로그래밍 인터페이스(API)’라는 기술적 구조가 경영진의 책임으로 자리 잡게 됐다. ‘엔터프라이즈 API 전략 구축 가이드(Guide to building enterprise API strategy)’라는 기사를 쓴 스티븐 J. 비글로우는 “기업들이 수익 창출을 위해 소프트웨어 기반 서비스를 점점 더 활용함에 따라 API 생성 및 유지관리는 비즈니스 전략의 주요 부분이 됐다”라고 말했다. API는 앞서 언급한 ‘기업들이 ...

경험 경제 API 경제 고객 경험 직원 경험 개발자 경험 API 설계 API 개발

2022.07.28

‘경험’이 전부인 세상, 그렇기에 어떤 기업도 홀로 설 수 없는 세상에서 어떻게 경쟁할 수 있을까? 얼마 전까지만 해도 경영진은 좋은 제품을 생산 및 제공하는 데만 신경 쓰는 ‘사치’를 부릴 수 있었지만 오늘날의 경험 경제에서는 그렇지 않다. 오늘날 소비자와 비즈니스 고객은 직관적이고, 자동화돼 있으며, 원활한 경험을 요구한다. 이러한 경험은 제공하는 것만으로도 충분히 복잡하지만 또 다른 새로운 요소가 상황을 더욱더 복잡하게 만들고 있다.  이러한 경험을 ‘독립적으로’ 제공할 수 없기 때문이다. 다시 말해, 고객들이 원하는 직관적이고 원활한 경험은 다른 기업의 데이터 그리고 (다른 기업과의) 상호 작용을 기반으로 해야 한다. 연결된 경험을 제공할 수 있는 역량은 소위 ‘경험 경제’와 ‘API 경제’가 충돌하는 세상에서 지속적인 경쟁력의 핵심이다. 문제는 그렇게 하는 방법이다. 그 해답은 경쟁 우위를 확보하는 열쇠인 ‘API 설계’에 있다.   경험 경제와 생태계 ‘경험 경제’ 개념은 거의 25년 전으로 거슬러 올라간다. 하지만 이를 실현하기 시작한 것은 최근의 기술 발전 그리고 이 최신 기술을 사용한 변혁적인 기술 회사부터다. 한편 항상 그랬던 것처럼 모든 소비자는 거의 즉각적으로 통합되고 원활한 디지털 경험을 요구해왔다. 그 결과, 대부분의 제조 회사조차도 제품과 서비스를 제공하기 위해 기술과 소프트웨어를 활용하고 있으며, (이에 따라) 다양한 기회와 과제가 제시되고 있다. 이러한 진화로 ‘애플리케이션 프로그래밍 인터페이스(API)’라는 기술적 구조가 경영진의 책임으로 자리 잡게 됐다. ‘엔터프라이즈 API 전략 구축 가이드(Guide to building enterprise API strategy)’라는 기사를 쓴 스티븐 J. 비글로우는 “기업들이 수익 창출을 위해 소프트웨어 기반 서비스를 점점 더 활용함에 따라 API 생성 및 유지관리는 비즈니스 전략의 주요 부분이 됐다”라고 말했다. API는 앞서 언급한 ‘기업들이 ...

2022.07.28

블로그ㅣ‘개발자 경험’이 2022년에 가져올 변화

개발자들에게 선택되는 기술이 엔터프라이즈 소프트웨어 시장을 어떻게 변화시켰는지에 관한 내용을 담은 스테판 오그래디의 저서 ‘새로운 킹메이커(The New Kingmakers)’가 나온 지 9년이 됐다. 당시 개발자들은 오픈소스와 클라우드를 선택했고, 컨테이너 오케스트레이션의 주인공으로 쿠버네티스를 캐스팅했으며, 서버리스로 전환했다.   이 접근 방식들은 개발자의 삶을 더 편리하게 만들었기 때문에 인기를 얻었다. 이를테면 개발자들이 애플리케이션을 원활하게 작동시키고, 확장할 수 있도록 했다. 하지만 서비스 및 애플리케이션을 클라우드로 이전할 수 없거나 (또는) 옮기려 하지 않거나 아니면 온프레미스로 실행하는 게 좋다고 보는 기업들도 있다.  개발자들의 싸움은 계속되고 있다. 2022년에는 어떤 일이 일어날까?   #1. ‘플랫폼 엔지니어링’이 데브옵스 및 SRE을 대신할 것이다 개발자들은 애플리케이션을 빠르고 효율적으로 배포하길 원한다. 이는 데브옵스 프로세스와 배포 프로세스를 거쳐 프로덕션 환경까지의 더 많은 협업으로 이어졌다. 이후 구글의 SRE(Site Reliability Engineering) 접근 방식이 인기를 얻으면서, 인프라 관리에 소프트웨어 엔지니어링 원칙을 적용하고 이를 가용성 및 안정성을 개선하는 데 활용했다.  다음 단계는 ‘플랫폼 엔지니어링’이다. 플랫폼 엔지니어링은 티켓을 접수하거나 팀 간에 핸드오프를 수행하는 전통적인 접근 방식이 아니라, 셀프서비스 인터페이스의 형태로 팀 간에 명확한 ‘계약’을 만드는 것이다. 퍼블릭 클라우드를 사용하는 것이 플랫폼 엔지니어링 접근 방식의 예다.  내부 플랫폼 팀은 기존 솔루션과의 통합, 전체 환경의 맥락 인식, 문서화 및 교육을 통한 지원을 제공한다. 기본 플랫폼 팀은 워크플로우, 자동화, 소스 제어 및 셀프서비스를 기반으로 자체 애플리케이션 및 인프라를 만들고 실행하는 방법을 정의한다.  각 팀이 애플리케이션에 기본 기능을 제공하기 ...

개발자 개발자 경험 소프트웨어 개발 쿠버네티스 데브옵스 플랫폼 엔지니어링 SRE

2022.01.03

개발자들에게 선택되는 기술이 엔터프라이즈 소프트웨어 시장을 어떻게 변화시켰는지에 관한 내용을 담은 스테판 오그래디의 저서 ‘새로운 킹메이커(The New Kingmakers)’가 나온 지 9년이 됐다. 당시 개발자들은 오픈소스와 클라우드를 선택했고, 컨테이너 오케스트레이션의 주인공으로 쿠버네티스를 캐스팅했으며, 서버리스로 전환했다.   이 접근 방식들은 개발자의 삶을 더 편리하게 만들었기 때문에 인기를 얻었다. 이를테면 개발자들이 애플리케이션을 원활하게 작동시키고, 확장할 수 있도록 했다. 하지만 서비스 및 애플리케이션을 클라우드로 이전할 수 없거나 (또는) 옮기려 하지 않거나 아니면 온프레미스로 실행하는 게 좋다고 보는 기업들도 있다.  개발자들의 싸움은 계속되고 있다. 2022년에는 어떤 일이 일어날까?   #1. ‘플랫폼 엔지니어링’이 데브옵스 및 SRE을 대신할 것이다 개발자들은 애플리케이션을 빠르고 효율적으로 배포하길 원한다. 이는 데브옵스 프로세스와 배포 프로세스를 거쳐 프로덕션 환경까지의 더 많은 협업으로 이어졌다. 이후 구글의 SRE(Site Reliability Engineering) 접근 방식이 인기를 얻으면서, 인프라 관리에 소프트웨어 엔지니어링 원칙을 적용하고 이를 가용성 및 안정성을 개선하는 데 활용했다.  다음 단계는 ‘플랫폼 엔지니어링’이다. 플랫폼 엔지니어링은 티켓을 접수하거나 팀 간에 핸드오프를 수행하는 전통적인 접근 방식이 아니라, 셀프서비스 인터페이스의 형태로 팀 간에 명확한 ‘계약’을 만드는 것이다. 퍼블릭 클라우드를 사용하는 것이 플랫폼 엔지니어링 접근 방식의 예다.  내부 플랫폼 팀은 기존 솔루션과의 통합, 전체 환경의 맥락 인식, 문서화 및 교육을 통한 지원을 제공한다. 기본 플랫폼 팀은 워크플로우, 자동화, 소스 제어 및 셀프서비스를 기반으로 자체 애플리케이션 및 인프라를 만들고 실행하는 방법을 정의한다.  각 팀이 애플리케이션에 기본 기능을 제공하기 ...

2022.01.03

금융기업 HSBC가 ‘최고의 개발자 API 포털’을 구축하려는 이유

글로벌 금융기업 HSBC가 경쟁력을 확보하기 위해 주목하는 영역이 있다. 일련의 자체 API(Application Programming Interface)에 액세스하고 사용하려는 이들을 대상으로 가능한 최고의 개발자 경험을 구축하는 것이 그것이다. 2018년 1월 13일부터 발효된 영국의 오픈 뱅킹(Open Banking) 규정에 따라 해당 국가 내 상위 9개 은행(일명 CMA9)은 고객 데이터를 일련의 안전한 API를 통해 제3자에게 공개하게 됐다. 이 밖에도 은행들은 2019년 9월 14일에 발효된 전 유럽 2차 결제지침(PSD2)과 제3자가 연결할 공개 API가 포함된 RTS(Regulatory Technical Standard)를 의무적으로 준수해야 한다. 이 규정의 핵심은 핀테크(Fintech) 기업들이 고객 데이터를 활용하여 더 나은 신용평가를 제공하거나 은행에 상관없이 모든 지출을 범주화하는 서비스를 제공할 수 있도록 함으로써 은행 부문의 경쟁을 높여 혁신을 유도하는 것이다. 또한 이를 통해 은행들은 고객 기대치가 바뀌면서 경쟁력 있는 제안을 하게 될 것으로 당국은 기대하고 있다. HSBC의 API 접근방식 지난 20일 샌프란시스코에서 열린 드림포스(Dreamforce) 컨퍼런스에서 발표 중 HSBC의 커머셜 뱅킹 수석 API 설계자 존 피닉스는 이 규정에 대응하는 해당 은행의 ‘API 온리’ 전략에 관해 이야기했다. 그는 “API 전략은 단순히 우리가 기존의 기능을 제공하려는 것 이상이다. 새로운 생태계를 구축하고 새로운 비즈니스 모델을 제공하는 것이 중요하다”라고 말했다. 그에 따르면 HSBC는 ‘하나의 메인프레임 애플리케이션’을 ‘더 작은 비즈니스 로직(Logic)’으로 분할하고 있다. 이를 통해 제3자는 대출평가 등의 뱅킹서비스를 직접 주플라(Zoopla) 같은 부동산 웹사이트에 통합할 수 있다. 또는 HSBC가 이런 것들을 가져다 자체적인 새로운 애플리케이션을 구축해 이전보다 훨씬 적은 노력으로 새로운 서비스를 제공할 수 있...

HSBC 핀테크 오픈 뱅킹 API 포털 개발자 경험

2019.11.22

글로벌 금융기업 HSBC가 경쟁력을 확보하기 위해 주목하는 영역이 있다. 일련의 자체 API(Application Programming Interface)에 액세스하고 사용하려는 이들을 대상으로 가능한 최고의 개발자 경험을 구축하는 것이 그것이다. 2018년 1월 13일부터 발효된 영국의 오픈 뱅킹(Open Banking) 규정에 따라 해당 국가 내 상위 9개 은행(일명 CMA9)은 고객 데이터를 일련의 안전한 API를 통해 제3자에게 공개하게 됐다. 이 밖에도 은행들은 2019년 9월 14일에 발효된 전 유럽 2차 결제지침(PSD2)과 제3자가 연결할 공개 API가 포함된 RTS(Regulatory Technical Standard)를 의무적으로 준수해야 한다. 이 규정의 핵심은 핀테크(Fintech) 기업들이 고객 데이터를 활용하여 더 나은 신용평가를 제공하거나 은행에 상관없이 모든 지출을 범주화하는 서비스를 제공할 수 있도록 함으로써 은행 부문의 경쟁을 높여 혁신을 유도하는 것이다. 또한 이를 통해 은행들은 고객 기대치가 바뀌면서 경쟁력 있는 제안을 하게 될 것으로 당국은 기대하고 있다. HSBC의 API 접근방식 지난 20일 샌프란시스코에서 열린 드림포스(Dreamforce) 컨퍼런스에서 발표 중 HSBC의 커머셜 뱅킹 수석 API 설계자 존 피닉스는 이 규정에 대응하는 해당 은행의 ‘API 온리’ 전략에 관해 이야기했다. 그는 “API 전략은 단순히 우리가 기존의 기능을 제공하려는 것 이상이다. 새로운 생태계를 구축하고 새로운 비즈니스 모델을 제공하는 것이 중요하다”라고 말했다. 그에 따르면 HSBC는 ‘하나의 메인프레임 애플리케이션’을 ‘더 작은 비즈니스 로직(Logic)’으로 분할하고 있다. 이를 통해 제3자는 대출평가 등의 뱅킹서비스를 직접 주플라(Zoopla) 같은 부동산 웹사이트에 통합할 수 있다. 또는 HSBC가 이런 것들을 가져다 자체적인 새로운 애플리케이션을 구축해 이전보다 훨씬 적은 노력으로 새로운 서비스를 제공할 수 있...

2019.11.22

IDG 설문조사

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.5.0.9