백곰술사의 IT Insight

[IT OffShore 도입 배경]

최근 IT OffShore가 한국 IT업계에서 화두가 되고 있습니다.

IT OffShore가 한국에서 논의되기 시작된 것은 2000년 후반부터 였지만

일본이나 미국처럼 활성화되지는 못하였습니다.

그 이유로는 아래와 같이 생각해볼 수있습니다.

    1. IT대기업(SDS, CNS, C&C 등)이 그룹사 기반의 매출 의존

    2. 아직까지는 지속되었던 경제성장기반의 팽창사회

즉, 사업환경/비용 측면에서 IT OffShore를 도입할 필요가 없었습니다.

하지만

제 4차산업혁명의 핵심기술인 BigData, BlockChain, AI등은

기존 산업영역의 경계붕괴(Big Blur), 신기술 기반 회사와의 경쟁을 심화시켰으며

금융권을 예를들면 FinTech -> TechFin이라고 할 정도로 기술주도적 Big Blur가 발생하게 되었습니다.

이러한 Digitalization Big Blur사회에서 기존 산업영역은 경쟁력확보 및 비용절감을 요구받게 됩니다.

따라서 아래의 키워드가 사업의 중요방향이 됩니다.

    "비용절감", "적자생존", "Digitalization"

즉, 사업환경/비용 측면에서 Digitalization을 통한 비용절감이 필요해진 것입니다.

결론적으로

대한민국의 IT환경은 팽창사회에서 -> 수축사회로 전환되었으며

IT OffShore는 수축사회를 맞는 IT분야의 비용절감 차원의 하나로 도입되었습니다.

고급기술자를 중급기술자로 중급기술자를 초급기술자로 초급기술자를 IT OffShore로 아예 넘기는 것이지요 .. ^^

IT업계에 종사하는 한 명의 노동자로 이런 추세는 참 마음이 아픕니다.

다른 얘기이지만

우리나라는 미국처럼 Job Transformation이 자유로운 나라가 아닙니다.

그렇기 때문에 우리나라는 노동법이 노동자중심으로 보호장치가 잘 마련되어 있습니다.

외부에서 보기에는 노동법이 노동경직성이 존재한다. 노동생산성이 부족하다라고들 합니다.

하지만 노동법의 유연화를 위해서는 제도적/법적으로 선제적 Job Transformation의 유연성을 지원해야 합니다.

노동자의 업역 이동이 유연하지 않은 상태에서 노동시장 유연화는 실업자만 양산시킬 뿐입니다.

다시 돌아가서

위와 같은 IT OffShore는 도입시 여러 고려사항이 있습니다.

저도 IT OffShore를 위해 담당업무 OffShore화 분석 수행 중이며,

이미 IT OffShore를 경험하신 주변 지인분께 여러 의견을 듣고 고려사항을 정리해 보았습니다.

[IT OffShore 도입 시 고려사항]

[개요]

최근 한 대학생이 구글맵을 통해 확진자 추적 서비스를 제공한다는 소식을 듣고 조금 의아 했습니다.

질병관리본부에서 제공하고 있는 실시간 서비스가 따로 없는건가..?

알아보니

아직 질병관리본부에서는 코로나바이러스같은 긴급질병재난을

질병관리본부 게시판 통계현황으로 "게시"하고 있더군요.

기 구축된 보건의료 빅데이터 연계 플랫폼에 비해 실시간 전파 체계는 조금 약하다고 생각이 되었습니다.

메르스 때의 교훈으로 진단키트를 개발하여 코로나바이러스 때 잘 대응하였고

코로나 바이러스의 경험을 토대로 실시간 전파 플랫폼을 갖출 것으로 예상됩니다.

그렇다면 실시간 전파 플랫폼은 어떤 기술 기반으로 갖춰지는 것이 좋을까요?

제 생각에는 Open API, LOD 두 형태의 데이터 제공이 다 가능한 플랫폼이면 좋을것 같습니다.

개발 측면에서는 Open API, Symentic Web

데이터 전파 측면에서는 LOD가 더 효율적이어서 그렇습니다.

[질병재난 플랫폼 구성도]

[개요]

최근 우리은행, 하나은행의 DLF(국외금리 연계 파생결합펀드) 불완전판매로 많은 투자자들이 손해를 보았습니다.

문제는 DLF를 명확히 알고 투자한 사람은 자기책임을 지겠지만, 대다수의 일반 투자자들은

은행 직원들의 권유 등에 의해 상품의 본질을 정확히 모르는 상태에서 가입하고 피해를 입었습니다.

금융에 대한 법적 규제, 금융감독원을 통한 외부감시 등의 제도적인 완충망을 지속적으로 발전시켰지만

불완전판매 이슈는 예전이나 지금이나 줄어들 기미가 보이질 않습니다.

대체 왜 이런 일이 계속해서 일어날까요?

금융사를 감독하는 관점은 내외부로 나누어 생각할 수 있습니다.

  1. 금융사 내부 Compliance와 Governance

  2. 금융사 외부 금융감독원에 의한 감사

DLF같이 전방위적으로 이루어진 불완전판매는

금융사 내부 Compliance와 Governance가 무너졌다고 생각할 수 밖에 없습니다.

모두가 부인하지만 위와 아래가 실적을 위해 작정하고 Compliance와 Governance를 무시한 것입니다.

우리는 Risk한 상품 판매 모니터링, 영업 중 발생할 수 있는 위법성 등을 방지하기 위해

기존의 금융감독원 정기감사 방식이 아닌, 실시간 대응 체계 SupTech를 도입할 필요가 있습니다.

RegTech도 SupTech와 결합된 RegTech는 의미가 있겠지만

내부 규제 준수의 RegTech는 DLF사태와 같이 언제든 마음대로 규제로직을 변경할 수 있을 것 입니다.

SupTech는 앞으로 금융 소비자보호를 위해 도입 최우선시 될 것입니다.

[SupTech]

SuperVision과 Technology의 합성어로 금융감독원 감독업무에 AI, BigData 등의 기술을 더해

검사의 효율성 및 감독규제 적시성을 높이기 위한 기술입니다.

이번 DLF 사태의 방지를 위한 SupTech의 프로세스 및 개념도는 아래와 같이 생각할 수 있습니다.

[SupTech Process]

  1. 각 금융사를 통한 금융 정보의 수집

  2. 적재된 BigData를 NLU, NLG 관련 AI기술로 분석

  3. 적발된 의심 행위 등에 대한 통제

[SupTech 도입시 고려사항]

변화하는 금융환경 및 상품에 따라 SupTech는 구축부터 운영까지 다양한 관점에서의 고려사항이 존재합니다.

이러한 고려사항을 반영한 도입은 SupTech의 효율성, 신뢰성 등을 높여줄 것입니다.

1. 금융 감독 팩터의 지속적 발굴

   - 금융 감독 팩터의 지속적 발굴이 필수적입니다.
   - 금융상품권 지속적으로 다양하며 변화합니다. 그에 따라 금융감독원에서도 감독을 위한

     팩터 발굴에 지속적 노력을 기울여야합니다.

2. 수집 데이터 투명성 확보
   - 금융감독원이 요구한 감독 팩터를 금융사가 전수제공하는지에 대한 투명성 확보 방안이 필요합니다.
   - 매 분기 SupTech관련 정기 감사를 통하는 방법도 존재하며
   - 금융사들이 보고하는 보고지표와 SupTech로 산출된 지표의 비교로도 투명을 산출하기 위한

     방안이 필요합니다.

3. RegTech와의 연동
   - 금융사가 Compliance 준수를 위해 도입한 RegTech와 연동하여 금융 감독 효율성을 높일 수 있습니다.
   - 금융사 RegTech에 금융감독원 필수 요구사항을 기능기준으로 AddOn하여 제공하는 것도 고려할 수 있습니다.

SupTech는 앞으로 DLF 사태같은 금융 사기 문제를 극복할 핵심 기술로 자리잡을 것입니다.

감사합니다.