Offcanvas

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

자칫하면 밑빠진 독··· 흔한 '앱 현대화' 오류 3가지

애플리케이션 현대화는 기업 비즈니스에서 운영되는 기존 애플리케이션과 데이터세트에 유용성과 생산성과 매력을 더하는 관행이다. 애플리케이션 현대화를 호박에 줄 긋는다고 수박이 되지 않는다는 식의 시각도 일부 있다. 하지만 애플리케이션 현대화는 단순히 애플리케이션을 현대적으로 보이게만 하는 것이 아니라, 실제로도 현대적으로 바꾸는 것을 말한다. 그러기 위해서 미래의 어느 시점에는 고쳐져 있어야 할 몇 가지의 문제를 살펴본다. 동료와 고객에게 전하는 조언은 정말 한 번 시도해보고 싶다면, 첫 단추를 잘못 꿰어서 나중에 모든 걸 고치는 일은 없어야 한다는 것이다.   문제는 대부분 지금 내린 결정을 미래에 다시 뜯어 고칠 일이 없을 거라고 생각하면서 순수한 실수를 저지른다는 점이다. 앱 현대화의 내재 가치와 초점을 이해하지 못해서 벌어지는 일이다. 클라우드로 전환하는 중에, 혹은 클라우드로 전환한 후의 애플리케이션 현대화 과정에서 일어나기 쉬운 3대 실수를 소개한다. 충분하지 않은 실수. 애플리케이션은 보통 리프트 앤 시프트 방식을 통해 클라우드로 전환한다. 이때 기업은 “있는 그대로”의 기존 플랫폼과 퍼블릭 클라우드의 유사점을 찾아 코드와 데이터를 옮긴다. 매우 쉬운 일이다. 기업이 기본적인 작업만을 수행한다는 점을 고려하면 클라우드 전환에 있어 가장 비용 효율이 높은 방법이므로 자주 권장된다. 그러나 클라우드 공급업체가 최대한 빠르게 수익을 올리기 위해 리프트 앤 시프트 방식을 자주 권장하다가는 오히려 문제가 복잡해진다. 특정 클라우드 공급자의 기본적인 기능을 활용할 리팩터링이 적용되지 않은 애플리케이션은 클라우드 플랫폼에 최적화되어 있지 않다. 따라서 운영에 비용이 더 많이 들어간다. 성능 저하, 사용자 환경 저하, 기존 관리방식 및 보안 보호 등 기본 요소 부족 같은 문제가 자주 발생한다. 결과적으로 특정 시점으로 돌아가 애플리케이션에서 문제가 되는 부분을 수정해야 한다. 과하게 적용하는 실수. 충분하지 못한 경우만큼 큰 문제는 아니지만,...

앱현대화 클라우드마이그레이션 클라우드이전 업체종속성

2022.07.29

애플리케이션 현대화는 기업 비즈니스에서 운영되는 기존 애플리케이션과 데이터세트에 유용성과 생산성과 매력을 더하는 관행이다. 애플리케이션 현대화를 호박에 줄 긋는다고 수박이 되지 않는다는 식의 시각도 일부 있다. 하지만 애플리케이션 현대화는 단순히 애플리케이션을 현대적으로 보이게만 하는 것이 아니라, 실제로도 현대적으로 바꾸는 것을 말한다. 그러기 위해서 미래의 어느 시점에는 고쳐져 있어야 할 몇 가지의 문제를 살펴본다. 동료와 고객에게 전하는 조언은 정말 한 번 시도해보고 싶다면, 첫 단추를 잘못 꿰어서 나중에 모든 걸 고치는 일은 없어야 한다는 것이다.   문제는 대부분 지금 내린 결정을 미래에 다시 뜯어 고칠 일이 없을 거라고 생각하면서 순수한 실수를 저지른다는 점이다. 앱 현대화의 내재 가치와 초점을 이해하지 못해서 벌어지는 일이다. 클라우드로 전환하는 중에, 혹은 클라우드로 전환한 후의 애플리케이션 현대화 과정에서 일어나기 쉬운 3대 실수를 소개한다. 충분하지 않은 실수. 애플리케이션은 보통 리프트 앤 시프트 방식을 통해 클라우드로 전환한다. 이때 기업은 “있는 그대로”의 기존 플랫폼과 퍼블릭 클라우드의 유사점을 찾아 코드와 데이터를 옮긴다. 매우 쉬운 일이다. 기업이 기본적인 작업만을 수행한다는 점을 고려하면 클라우드 전환에 있어 가장 비용 효율이 높은 방법이므로 자주 권장된다. 그러나 클라우드 공급업체가 최대한 빠르게 수익을 올리기 위해 리프트 앤 시프트 방식을 자주 권장하다가는 오히려 문제가 복잡해진다. 특정 클라우드 공급자의 기본적인 기능을 활용할 리팩터링이 적용되지 않은 애플리케이션은 클라우드 플랫폼에 최적화되어 있지 않다. 따라서 운영에 비용이 더 많이 들어간다. 성능 저하, 사용자 환경 저하, 기존 관리방식 및 보안 보호 등 기본 요소 부족 같은 문제가 자주 발생한다. 결과적으로 특정 시점으로 돌아가 애플리케이션에서 문제가 되는 부분을 수정해야 한다. 과하게 적용하는 실수. 충분하지 못한 경우만큼 큰 문제는 아니지만,...

2022.07.29

칼럼 | API, 네트워크 업체 종속의 숨은 위협

대부분 기업은 네트워크의 업체 종속을 우려한다. 기업에 종속 회피 방법을 물으면, ‘표준 인터페이스’ 또는 ‘오픈소스’라고 답한다. 오늘날까지도 종속 회피 조치에 ‘API 관리’를 포함한 기업의 수는 많지 않다. 하지만 API는 현재 가장 빠른 속도로 성장하는 종속 문제이며, 앞으로 중대한 문제가 될 것임이 확실하다.    API는 ‘애플리케이션 프로그래밍 인터페이스(application programing interface)’를 의미한다. 오늘날에는 의미가 확장돼 애플리케이션뿐만 아니라 클라우드, 네트워크에 사용하는 모든 소프트웨어 컴포넌트의 인터페이스를 가리킨다. API는 소프트웨어 조각이 서로 통신할 수 있게 해준다. 따라서 하드웨어 장치가 연결된 환경보다는 소프트웨어 컴포넌트가 연결된 환경에서 필수적이다. 표준 인터페이스만큼이나 중요한 것이다. 하지만 이렇게 중요한 API의 흐름을 추적하는 기업은 극히 드물다.  네트워크 장비에는 4개의 소프트웨어 계층이 있다. 최하단에는 이더넷 인터페이스 칩을 소프트웨어와 연결하는 드라이버가 있다. 그 위에는 일반적인 호스팅 기능을 제공하는 NOS(Network Operating System)가 있고, 그 위에는 특수한 네트워크 기능을 처리하는 ‘미들웨어’가 있다. 최상부에는 통합 커뮤니케이션이나 서비스 거부 공격 완화 등 관리 및 서비스 기능을 하는 네트워크 의존 애플리케이션이 있다. 이들 계층은 API를 다른 계층으로 노출한다.  우리는 이더넷과 광 네트워크, 무선 네트워크까지 다양한 하드웨어 인터페이스에 익숙하다. 또 이더넷 커넥터를 광 네트워크 포트에 연결할 수 없다는 것과 입력 선을 출력 단자와 연결하면 안 된다는 것을 잘 안다. 하지만 API는 물리적 커넥터가 없다.  소프트웨어에서 발생하는 API 문제 API는 메시지 교환 규격이다. 메시지 포맷, 데이터 구조, 요청/응답 동기화 등 모든 측면이 API 규격 내에 설정되어 있고, 전체 ...

네트워크 업체종속성 API

2021.12.10

대부분 기업은 네트워크의 업체 종속을 우려한다. 기업에 종속 회피 방법을 물으면, ‘표준 인터페이스’ 또는 ‘오픈소스’라고 답한다. 오늘날까지도 종속 회피 조치에 ‘API 관리’를 포함한 기업의 수는 많지 않다. 하지만 API는 현재 가장 빠른 속도로 성장하는 종속 문제이며, 앞으로 중대한 문제가 될 것임이 확실하다.    API는 ‘애플리케이션 프로그래밍 인터페이스(application programing interface)’를 의미한다. 오늘날에는 의미가 확장돼 애플리케이션뿐만 아니라 클라우드, 네트워크에 사용하는 모든 소프트웨어 컴포넌트의 인터페이스를 가리킨다. API는 소프트웨어 조각이 서로 통신할 수 있게 해준다. 따라서 하드웨어 장치가 연결된 환경보다는 소프트웨어 컴포넌트가 연결된 환경에서 필수적이다. 표준 인터페이스만큼이나 중요한 것이다. 하지만 이렇게 중요한 API의 흐름을 추적하는 기업은 극히 드물다.  네트워크 장비에는 4개의 소프트웨어 계층이 있다. 최하단에는 이더넷 인터페이스 칩을 소프트웨어와 연결하는 드라이버가 있다. 그 위에는 일반적인 호스팅 기능을 제공하는 NOS(Network Operating System)가 있고, 그 위에는 특수한 네트워크 기능을 처리하는 ‘미들웨어’가 있다. 최상부에는 통합 커뮤니케이션이나 서비스 거부 공격 완화 등 관리 및 서비스 기능을 하는 네트워크 의존 애플리케이션이 있다. 이들 계층은 API를 다른 계층으로 노출한다.  우리는 이더넷과 광 네트워크, 무선 네트워크까지 다양한 하드웨어 인터페이스에 익숙하다. 또 이더넷 커넥터를 광 네트워크 포트에 연결할 수 없다는 것과 입력 선을 출력 단자와 연결하면 안 된다는 것을 잘 안다. 하지만 API는 물리적 커넥터가 없다.  소프트웨어에서 발생하는 API 문제 API는 메시지 교환 규격이다. 메시지 포맷, 데이터 구조, 요청/응답 동기화 등 모든 측면이 API 규격 내에 설정되어 있고, 전체 ...

2021.12.10

칼럼 | 클라우드에서 오픈소스의 진정한 가치

클라우드에서 오픈소스를 구동한다고 해서 업체 종속을 막아줄 것이라 생각한다면, 오산이다. 하지만 오픈소스는 분명 개발자에게 자유와 독립을 가져다준다. 최근 IBM의 후원으로 오릴리 미디어가 진행한 설문조사인 ‘클라우드 시대 오픈소스의 가치’에는 희망적인 생각이 가득하다. 예를 들어, 3,400명 이상의 응답자 중 70%가 오픈소스 기반의 클라우드 서비스 업체를 더 선호한다고 답했다. 오픈소스 지지자에게는 대단한 수치이다. 하지만 ‘오픈소스 기반’이 어떤 의미인지를 물어보면, 사정이 달라진다. 결국 현존하는 모든 소프트웨어 제품은 오픈소스를 기반으로 하기 때문이다. 그리고 79%의 응답자는 클라우드에서 업체 종속을 방지하기 위해 오픈소스로 전환했다고 답했다. 이 이야기도 여러 가지 이유로 다소 우스꽝스러운 것이 사실이다.   이렇게 오픈소스에 우호적인 응답 이면에 한 가지 눈에 띄는 사실이 있다. 클라우드 전문 기술 솔루션은 개발자가 코드를 더 빨리 출하하는 데 도움이 되지만, 오픈소스 기술은 개발자가 특정 클라우드 서비스 업체와 독립적으로 자신의 경력을 쌓을 수 있도록 해준다. 다시 말해, 오픈소스는 궁극적인 경력 관리 기술이다.   오픈소스의 마법 같은 현실주의 그렇다면, 미신으로 돌아가 보자. 우선, 약 55%의 응답자가 ‘단일 클라우드 서비스 업체에 특화된 클라우드 컴퓨팅 기술을 배우는 것은 경력 성장을 제한한다”고 답했지만, 모든 개발자 대부분이 정확하게 이렇게 한다. 이유는 대부분 기업이 클라우드 서비스 업체 한 곳에 중점을 두기 때문이다. 물론, 많은 기업이 결국에는 서로 다른 애플리케이션이나 인프라를 다양한 클라우드 서비스 업체로부터 사용한다. 하지만 필자는 ‘어쩌다 보니 멀티클라우드’이지 ‘의도한 멀티클라우드’라고 생각하지 않는다. 의도한 멀티클라우드도 있지만, 매우 드물다. 전임 시트릭스 부사장 크리스티안 레일리가 말했듯이 “언제나 그렇듯 문제는 대체 가능성의 부족이다. 대체 가능성은 매출을 끌어올리지 않는다. 서비스 ...

경력개발 업체종속성 멀티클라우드 쿠버네티스

2021.02.24

클라우드에서 오픈소스를 구동한다고 해서 업체 종속을 막아줄 것이라 생각한다면, 오산이다. 하지만 오픈소스는 분명 개발자에게 자유와 독립을 가져다준다. 최근 IBM의 후원으로 오릴리 미디어가 진행한 설문조사인 ‘클라우드 시대 오픈소스의 가치’에는 희망적인 생각이 가득하다. 예를 들어, 3,400명 이상의 응답자 중 70%가 오픈소스 기반의 클라우드 서비스 업체를 더 선호한다고 답했다. 오픈소스 지지자에게는 대단한 수치이다. 하지만 ‘오픈소스 기반’이 어떤 의미인지를 물어보면, 사정이 달라진다. 결국 현존하는 모든 소프트웨어 제품은 오픈소스를 기반으로 하기 때문이다. 그리고 79%의 응답자는 클라우드에서 업체 종속을 방지하기 위해 오픈소스로 전환했다고 답했다. 이 이야기도 여러 가지 이유로 다소 우스꽝스러운 것이 사실이다.   이렇게 오픈소스에 우호적인 응답 이면에 한 가지 눈에 띄는 사실이 있다. 클라우드 전문 기술 솔루션은 개발자가 코드를 더 빨리 출하하는 데 도움이 되지만, 오픈소스 기술은 개발자가 특정 클라우드 서비스 업체와 독립적으로 자신의 경력을 쌓을 수 있도록 해준다. 다시 말해, 오픈소스는 궁극적인 경력 관리 기술이다.   오픈소스의 마법 같은 현실주의 그렇다면, 미신으로 돌아가 보자. 우선, 약 55%의 응답자가 ‘단일 클라우드 서비스 업체에 특화된 클라우드 컴퓨팅 기술을 배우는 것은 경력 성장을 제한한다”고 답했지만, 모든 개발자 대부분이 정확하게 이렇게 한다. 이유는 대부분 기업이 클라우드 서비스 업체 한 곳에 중점을 두기 때문이다. 물론, 많은 기업이 결국에는 서로 다른 애플리케이션이나 인프라를 다양한 클라우드 서비스 업체로부터 사용한다. 하지만 필자는 ‘어쩌다 보니 멀티클라우드’이지 ‘의도한 멀티클라우드’라고 생각하지 않는다. 의도한 멀티클라우드도 있지만, 매우 드물다. 전임 시트릭스 부사장 크리스티안 레일리가 말했듯이 “언제나 그렇듯 문제는 대체 가능성의 부족이다. 대체 가능성은 매출을 끌어올리지 않는다. 서비스 ...

2021.02.24

블로그 | 멀티클라우드라고 업체 종속성이 사라지지는 않는다

멀티클라우드(Multicloud)을 선택하는 주된 이유가 업체 종속성(vendor lockin) 때문이라는 이야기가 흔하다. 클라우드 제공업체가 많으면 더욱 독립적일 수 있다는 이 가정의 논리는 이해할 수 있다. 그러나 현실은 크게 다르다.   예를 들어, 클라우드에 애플리케이션이 있고 멀티클라우드 아키텍처를 사용하는 경우 해당 애플리케이션 작업 부하와 관련된 데이터를 AWS, 마이크로소프트 애저, 그리고/또는 구글 클라우드 플랫폼 등 2-3곳에 분산시킬 수 있다. 해당 애플리케이션을 위해 1개의 클라우드를 선택하고 표준 마이그레이션 프로세스를 수행해 구성한 후 실행할 것이다. 대부분의 사람은 이런 마이그레이션의 일환으로써 애플리케이션 작업 부하를 클라우드에 네이티브화시켜야 한다는 사실을 모르고 있을 가능성이 높다. 즉, 애플리케이션을 살짝 또는 대대적으로 변경해 API 관리, 거버넌스, 보안, 저장소 등의 네이티브 클라우드 서비스를 활용하게 되는 것이다. 애플리케이션을 클라우드에 네이티브화하면 해당 애플리케이션에 대해서는 스스로 해당 클라우드 제공업체에 종속되는 것이다. 클라우드 네이티브화 접근방식을 취하지 않으면 해당 애플리케이션을 추후에 다른 제공업체로 마이그레이션하기가 더 쉽겠지만 클라우드 네이티브화가 되지 않아 배치가 덜 최적화된다. 고급 애플리케이션 기능(클라우드 네이티브화)을 사용해 업체 종속성을 인정하든지 종속성 탈피를 위해 독립적이지만 덜 최적화된 앱에 만족해야 한다. 단일 클라우드 또는 멀티클라우드 아키텍처를 사용하는지 여부에 상관없이 종속성의 타협은 똑같다. 물론, 필요 시 다른 퍼블릭 클라우드 옵션을 이용할 수 있도록 아키텍처에 다른 퍼블릭 클라우드가 연결, 통합되어 있는 것은 큰 이점이 된다. 하지만 여전히 클라우드 네이티브화와 종속성 탈피 사이의 상충점은 피할 수 없다. 컨테이너를 사용하거나 휴대 가능한 애플리케이션을 작성해 상충점을 피할 수 있다고 생각할 수도 있다. 하지만 거기에도 문제가 존재한다. 컨테이너는 ...

록인 멅티클라우드 lockin 업체종속성

2018.12.21

멀티클라우드(Multicloud)을 선택하는 주된 이유가 업체 종속성(vendor lockin) 때문이라는 이야기가 흔하다. 클라우드 제공업체가 많으면 더욱 독립적일 수 있다는 이 가정의 논리는 이해할 수 있다. 그러나 현실은 크게 다르다.   예를 들어, 클라우드에 애플리케이션이 있고 멀티클라우드 아키텍처를 사용하는 경우 해당 애플리케이션 작업 부하와 관련된 데이터를 AWS, 마이크로소프트 애저, 그리고/또는 구글 클라우드 플랫폼 등 2-3곳에 분산시킬 수 있다. 해당 애플리케이션을 위해 1개의 클라우드를 선택하고 표준 마이그레이션 프로세스를 수행해 구성한 후 실행할 것이다. 대부분의 사람은 이런 마이그레이션의 일환으로써 애플리케이션 작업 부하를 클라우드에 네이티브화시켜야 한다는 사실을 모르고 있을 가능성이 높다. 즉, 애플리케이션을 살짝 또는 대대적으로 변경해 API 관리, 거버넌스, 보안, 저장소 등의 네이티브 클라우드 서비스를 활용하게 되는 것이다. 애플리케이션을 클라우드에 네이티브화하면 해당 애플리케이션에 대해서는 스스로 해당 클라우드 제공업체에 종속되는 것이다. 클라우드 네이티브화 접근방식을 취하지 않으면 해당 애플리케이션을 추후에 다른 제공업체로 마이그레이션하기가 더 쉽겠지만 클라우드 네이티브화가 되지 않아 배치가 덜 최적화된다. 고급 애플리케이션 기능(클라우드 네이티브화)을 사용해 업체 종속성을 인정하든지 종속성 탈피를 위해 독립적이지만 덜 최적화된 앱에 만족해야 한다. 단일 클라우드 또는 멀티클라우드 아키텍처를 사용하는지 여부에 상관없이 종속성의 타협은 똑같다. 물론, 필요 시 다른 퍼블릭 클라우드 옵션을 이용할 수 있도록 아키텍처에 다른 퍼블릭 클라우드가 연결, 통합되어 있는 것은 큰 이점이 된다. 하지만 여전히 클라우드 네이티브화와 종속성 탈피 사이의 상충점은 피할 수 없다. 컨테이너를 사용하거나 휴대 가능한 애플리케이션을 작성해 상충점을 피할 수 있다고 생각할 수도 있다. 하지만 거기에도 문제가 존재한다. 컨테이너는 ...

2018.12.21

회사명:한국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.5