728x90
반응형
SMALL

▶ Data Lake의 탄생 배경 - DW의 한계

거의 모든 기업은 정보시스템을 구축해서 사용하고 있으며 이 정보시스템을 통해 많은
데이터가 생성되고,저장되고,가공되고,분석되고,보고되어 지고 있다. 
이 단계중에서 데이터를 분석하는 부분의 기업의 의사결정에 중요한 기준자료가 되기
때문에 많은 기업들이 이 데이터를 분석하기 위한 솔루션 구축에 많은 투자를 하고 있고
대표적으로 DW (Data Warehouse) 를 많이 사용하고 있다.
DW는 기업의 정보시스템(기간계,지원계,채널계..)으로 부터 생성된 데이터 중 분석가치가
있는 데이터를 주제별로 분류해서 ETL을 통해서 수집하고 이 데이터를 정형화해서
데이터 마트(Data Mart)에 쌓아 놓은 후 각종 분석 View Tool (OLAP,SQL)을 이용해서
정형화되고 시각화된 데이터를 (Dashboard 같은) 의사결정자에게 제공을 하고 있다.
하지만 DW를 사용해보신 분은 느끼시겠지만 DW를 사용하기 위해서는 다양한 데이터를 
그대로 사용하지 못하고 데이터 마트(Data Mart) 라는 규격화된 그릇에 담을 수 있도록
데이터를 가공,편집하는 정형화 작업이 선행되어야 한다. 이 작업이 만만치 않은 작업이다.
또한 먼가 새로운 항목을 추가하는 등 모델을 변경하는 것은 상당한 어려운 작업이 된다.
그리고 제일 DW의 약점이라고 하면 바로 비정형 데이터를 처리할 수 없다는 것이다.
요즘 정보의 형태는 과거 정형적인 데이터에서 비정형 데이터 즉 SNS, 블로그 포스팅, 제품리뷰
,스트리밍, 디바이스 로그 등 과 같은 형태의 데이터가 더 가치를 가진 정보로 각광받고 있는 시대로 변하고
있다.  DW에서는 이러한 비정형 데이터를 처리하는 데 한계가 있다.

이러한 DW의 정보분석의 한계를 극복하고자 나온 것이 바로 "Data Lake" 이다.

 Data Lake의 정의 - 잔잔한 호수

Data Lake는 다양한 원천 데이터를 통합된 단일 형식으로 만들어서 저장하는(Schema-on-write)
DW와는 다르게 원천 데이터를 그대로 원래 형식으로 저장을 하고 나중에 읽을 때 (Schema-on-read)
쉽게 분석할 수 있도록 하는 대규모 저장소의 개념이다 . 
이 Data Lake 개념을 처음 제안한 사람은 데이비드 바틀렛 이라는 GE 직원이었는데 그는 평소
생물학에 관심이 있어 호수(Lake) 를 보면 잔잔해 보이지만 수면 밑으로는 여러 다양한 생물들과
그들의 상호작용으로 생태계가 유지된다는 측면에서 Data Lake 라는 용어를 사용했다고 한다.
낚시에 비유해 보면 DW는 규격화 되어 있는 양식장에서 양식 광어를 낚는 방식이고, Data Lake
호수에서 바로 물고기를 낚는 거라고 할 수 있다.

 Data Lake의 처리방식

Data Lake 에서는 비정형데이터 , 즉 SNS나 로그 같은 데이터를 독립적으로 나누고 다시 취합하는
기법을 사용하는데 보통 이때 사용하는 기술로  하둡(Hadoop) 과 같은 맵리듀스(Map Reduce)  방식의
분산처리기법이다.  독립적으로 나눈 데이터를 하둡분산파일시스템(HDFS)을 통해 분산 서버에
저장하고 , 맵리듀스를 통해 각각의 분산서버에서 병렬처리한다.

 Data Lake 의 구성도

<출처 : 181회 정보관리기술사 모임 : 두드림>

구성요소 세부설명 요소기술
Data Source (생성) 정형/비정형/반정형 Raw  Data  
Ingestion Layer (수집) Raw Data를 웹서버,파일서버,IoT 이용한
스토리지 수집
Database, WebServer,FTP
IoT, Storage
Caching Layer (저장) 수집된 데이터를 저장 SQL, NoSQL, Elastic Search
Processing Layer (처리) 알고리즘 수행, 요구사항 전처리  HDFS
Insight Layer (통찰,활용) 시스템 모니터링, BI, 평가 Data Discovery, Data Dashboard

                                  <출처 : 181회 정보관리기술사 동기화 : 두드림 >

▶ Data Lake  의 장점

1) 데이터의 구조화여부에 상관없이 활용할 수 있다. 
2) 원시 Raw Data를 저장할 수 있으며 이 데이터는 작업자의 이해와 Insight Improves (통찰력) 에 의해
    재정의 될 수 있다.
3) 물리적으로 분산되어 저장되어 있는 대용량의 Raw Data 를 분석할 수 있다.
4) 유지보수 비용이 적게 든다

▶ Data Lake 와 DW 의 비교

구분 DW (Data Warehouse) Date Lake
스키마 Schema-on-write
저장시에 규격에 맞게 저장하는 방식
Schema-on-read
저장은 Raw Data 를 그대로 저장하고
읽을 때 분석하는 방식
접근방법 표준화된 SQL이나 BI 를 통해 접근 SQL, 개발된 프로그램, 빅데이터 분석 Tool 등을 통해서 접근
데이터 Cleansed Raw and refined 
데이터 복잡성 복잡한 통합 (Complex Integration) 복잡한 처리 (Complex Processing)
비용 높다 낮다
데이터 유형 정형, 구조적 데이터  정형, 비정형, 반정형

 

728x90
반응형
LIST
728x90
반응형
SMALL

망중립성은 망제공사업자가 특정 콘텐츠나 CP (Content Provider) 에 대해서 차별,차단을
금지하는 정책으로 망 자체를 공공재로 보기 때문에 차별없이 누구나 참여해서 사용할 수
있어야 한다는 개념이다. 
예를 들면 대표적인 통신기업인 SK,KT,LG 등 ISP 사업자가 제공하는 인터넷망에 접속하면
어느 콘텐츠나 트랙픽 제한이나 차단없이 동등하게 볼수 있어야 한다는 뜻이다.
요즘 한창 이슈가 되는 Youtube 와 같이 대용량 동영상 콘텐츠를 제공하지만 이들은 
인터넷망을 아무 비용지불없이 무임승차를 하고 있을 수 있는 것은 이 망중립성때문이다.
Youtube를 이용하는 사용자는 계속 증가하고 제공되는 동영상 볼륨도 크기 때문에
그만큼 네트워크 트래픽을 엄청 잡아먹기 때문에 일정 요금제에 가입해서 스마트폰을
보는 사용자에게는 안정된 서비스를 제공할려면 지속적인 망투자가 필요하고  이는
only 망사업자의 비용으로 전가될 수밖에 없다. 
그래서 요즘 망중립성에 대한 원칙이 흔들리는 추세이고 실제 2017년 12월 14일에 
미국 연방통신위원회는 망중립성 폐지 방안을 통과시켰고 따라서 망사업자는 구글,넷플릭스
등 OTT사업자등을 대상으로 사용량,속도 등에 따라 차별화된 요금을 부과할 수있게 되었다.

이와 같이 망중립성은 동면의 양면성 처럼 장단점이 있다.
제한된 주파수 할당을 통해 인터넷망이 제공되기때문에 마치 고속도로 통행료 처럼 사용자의
편익에 따라 비용을 부과할 수밖에 없기도 하지만 통신사업자의 독점을 통해 사용자 Lock-In
으로 인해 소비자의 선택권이 제한받을 수 있는 상황이 될 수도 있기 때문이다.

728x90
반응형
LIST
728x90
반응형
SMALL

우리가 보통 인터넷사이트를 이용할려면 우선 회원가입을 통해 ID와 Password 를 설정한 후
로그인을 통해 해당 사이트에 접속을 하고 있다.
해당 사이트는 사용자가 입력한 ID와 Password를 자신의 서버에 저장되어 있는 사용자의 
정보와 대조해서 일치하면 접속을 허용하는 방식인 것이다.
이 ID/Password 인증방식은 지식기반의 인증방식의 하나로 널리 쓰이고 있지만 치명적인
약점 또한 가지고 있다.  사용자의 정보를 각 사이트의 서버에 저장되어 있다는 것이다.
이는 유출의 위험이 항상 있을 수 밖에 없는 구조이다. 물론 암호화 등 다양한 보안조치를 통해
유출의 위험을 줄이고는 있다고 하지만 100% 안전할 수는 없다. 
또한 각 사이트마다 ID,Password를 설정해야 하다 보니깐 잊어버리는 경우도 있고, 보통 동일한
ID.Password로 설정하기 때문에 한곳에서 노출되면 전체가 다 노출되는 위험성이 크다.

요즘은 이런 걸 보완하기 위해 네이버/구글/페이스북/카카오 등에서 로그인서비스를 제공하는
데 이를 연합인증(Federated Identity) 이라고 하는데 OpenID, OAuth  등을이용해서 기존에
가입된 소셜미디어 계정으로 다른 사이트나 앱에 로그인 하는 방법이다.
이로 인해서 개별 회원가입을 해야하는 불편함이 확 줄었지만 이 또한 개인정보 유출 및
해킹에서는 자유롭지 못하다. 오히려 특정서비스로의 개인정보 집중화로 인해 대량개인정보유출
사고가 일어날 수 있다.

이러한 문제점은 모두 개인정보가 중앙서버에 저장되어 있기 때문이다. 그래서 나온 개념이
이 DID (Decentralized Identifiers)  즉 분산ID, 탈중앙화 신원확인시스템이다.
간단히 이야기하면 개인정보를 중앙서버에 저장하는 것이 아니라 각 개인이 가지고 있고
각 개인이 가지고 있는 개인정보에 대한 유효성은 블록체인 기술을 이용해서 인증하는 방식이다.
블록체인을 통해 개인정보를 분산저장하고 한쪽에서 이 개인정보를 위조하더라도 나머지 분산
저장된 개인정보와 비교를 통해서 위조여부를 알수 있는 것이다. 
이는 자기주권(self-soverign) 의 개념을 도입한 것으로 개인정보를 개인 본인이 보관하는 방법으로
사용자는 블록체인에 자기 개인정보를 올리고 자기 스마트폰에 저장하면 된다.

블록체인ID인증은 다음과 같은 단계로 이루어진다.
1. 사용자는 자신에 대한 인증이 필요한경우 Issuer에게  자신의 증명자료와 요청정보를 제공한다.
    (여기서 Issuer 는 지금의 공인인증서 인증기관같은 걸 말한다.)
2. Issuer는 증명자료와 요청정보를 기반으로 Verifiable Claims 를 발급해서 사용자에게 준다.
    (이때 Issuer는 증명자료나 요청정보를 따로 저장하지 않는다. ◀이게 핵심!!!!!)
3. 사용자는 Issuer로부터 전달받은 Verifiable Claims 를 자기 스마트폰에 저장한다.
4. 사용자는 은행사이트 로그인 시 이 Verifiable Claims를 제출한다.
5. 은행사이트는 사용자가 제출한 Verifiable Claims 를 블록체인에서 비교 검사해서
   위조여부를 검사한 후 로그인을 허용한다.
   (DID는 결국 블록체인의 DLT (Distributed Ledger Technology) 상에서 신원을 확인하는데
   사용되는 식별자 역할을 하는 셈이다)

● DID 구성도와 기술요소

                 < 출처 : 118회 정보관리기술사 두드리 동기회 >

Digital Wallet (전자지갑) DID를 개인이 저장할 수 있는 지갑으로 DKMS 을 이용한다.
 ▶ DKMS : DID 즉 사설키를 저장관리하는 표준
블록체인의 분산원장을 통해 검증
DKMS (Decentralized Key Management System)  DID 즉 사설키를 저장관리하는 공개표준
DID Auth (본인인증 Digital Wallet에 있는 DKMS에 저장된 키 기반 본인인증
외부에 정보요청, 전달, 거래 등 수행
Verify Credential 본인 인증을 위해 상대방에게 증명서(DID) 제출
Peer 거래 상대방으로 제출받은 증명서(DID)를 블록체인 분산원장
을 통해 검증한다.
Issue Credential 거래 상대방이 증명이 되었다는 결과를 사용자에게 전달


● DID 와 공인인증서 방식 비교

구분 공인인증서 DID
개념 중앙집중형 분산인증 블록체인 기반 탈중앙화 신원확인시스템
신원관리주체 서비스제공자 이용자 본인
특징 개인정보를 중앙서버에 저장 개인정보는 중앙서버에 저장되지 않고
개인 본인이 자기한테 저장
보안 중앙서버가 실패 단일점
중앙서버의 데이터 유출가능
블록체인 원장에 분산저장되어 무결성및
위조 불가
확장성 서버가 추가되면서 신뢰관계
구축이 필요해서 확장성낮음
노드 추가를 통해 블록체인 원장에 쉽게
확장 가능
기술요소 SSL/TLS, SAML, OAuth,  PKI DID, DLT, DKMS, Digial Wallet, 블록체인


 

 

728x90
반응형
LIST

'디지털서비스' 카테고리의 다른 글

머클트리(Merkle Tree)  (0) 2019.09.19
Data Lake - 데이터 단일 저장소  (0) 2019.09.09
망중립성 (Network Neutrality)  (0) 2019.09.08
제로레이팅 (Zero Rating)  (0) 2019.09.06
도커(Docker)  (0) 2019.09.05
728x90
반응형
SMALL

1. 제로 레이팅(Zero Rating)의 개념

제로 레이팅(Zero Rating)이란 CP(Content Provider) 즉 콘텐츠 사업자와 ISP (Internet Service Provider) 즉
망사업자, 통신사간 제휴를 통해 특정 앱이나 특정 콘텐츠에 대해서는 사용할 때 발생하는 데이터 이용료를
이용자한테는 면제해주는 제도로 글자 그대로 0원 요금제 또는 스폰서 요금제라고 불린다
예를 들어 멜론 같은 경우는 멜론 정액제에 가입한 사용자가 멜론 앱을 통해 음악을 스트리밍 받을 때
발생하는 데이터 이용료를 따로 받고 있지 않다.  또는 각 통신사가 제공하는 고객센터 앱 같은 경우도
앱 내에서 발생하는 데이터 이용료에 대해서는 무료로 하고 있다.
물론 제로 레이팅(Zero Rating)은 사용자는 데이터 이용료를 내지 않고 무제한으로 맘껏 해당 콘텐츠를
이용할 수 있어서 통신비 절감에 좋고 , 통신사 입장에서는 데이터 이용료를 사용자에게 받지 않을 뿐
CP 즉 멜론한테 이용료를 받고 있기 때문에 별 손해가 없는 장사이며 멜론 같은 CP는 가입자를
더 확보할 수 있게 해 주며 음악 스트리밍 사업분야의 진입장벽을 높여 다른 경쟁사업자가 쉽게 진입할
수 없게 할 수 있는 장점이 있어 어쩌면 CP와 ISP 사업자 간이  Win-Win 일수도 있다. 다만 이것만으로
제로 레이팅이 좋다고는 할 수는 없지만...... 아무래도 소비자 선택권이 줄고 독점 형태의 사업자가 발생하고
, 망중립성(Network Neutrality)의 훼손을 가져오게 된다. 
해외에서도 이 제로 레이팅(Zero Rating) 이슈에 대해 '망중립성'이라는 기준 잣대에 의거해서 제로 레이팅을
허용하지 않는 규제를 수립했다가도 최근 또 그런 규제를 일부 해제하는 등 과도기적인 행보를 보이고 있다. 

2. 제로 레이팅(Zero Rating)의 유형

유형 설명
통신사 전략 서비스 보통 망사업자가 자사 고객만을 위해 전략서비스를 제공하면서 네트워크 비용을 추가로 부과하지 않는 경우
예) 통신사에서 제공하는 앱 (고객센터 앱)
무료 서비스/컨텐츠 마케팅/시장 개척을 위해 서비스사업자가 비용부담을 하고 고객들에게 무료로 제공하는 서비스나 컨텐츠
예) Google의 Free Zone
정액제 상품 네트워크 비용이 서비스 요금과 함께 번들링되어 제공되는 정액형 서비스 상품
예) 멜론 정액형 상품
지원시스템형 무과금 서비스 내부 시스템형 서비스 혹은 고객지원형 서비스를 위해 무과금으로 서비스하는 형태
예) 고객센터 앱


3. 제로 레이팅 (Zero Rating) 찬반

출처 : https://brucemoon.net/1198143247?category=118957

 

728x90
반응형
LIST
728x90
반응형
SMALL

도커(Docker)는 리눅스 컨테이너 기술을 자동화해 쉽게 사용할 수 있도록 도와주는 오픈소스 프로젝트이다.
즉 컨네이너 안에 어플리케이션을 배치하는 것을 자동화해주는 역할을 한다.
플랫폼서비스(PasS, Platform as a Service) 사업을 하고있던 '닷클라우드' 라는 회사는 PaaS 서비스
를 제공하면서 인프라기술력을 높일 수 있는 방법으로 리눅스 컨테이너 기술을 적극 활용했고
지금은 PasS 사업은 다른 회사에 매각하고 회사명도 '도커' 라 바꾼 후 도커(Docker) 서비스에 집중하고
있다.

<출처 : 네이버지식백과 >

하이퍼바이저는 하나의 Host OS 에서 여러 개의 운영체제(OS) 즉 Guest OS 를 할당해서 사용할 수
있게 도와주는 기술이다. 가상화 환경은 가장 밑단에 깔린 Host OS를 공유한다.
만약 Guest OS가 네트워크를 많이 사용하는 애플리케이션을 돌리면 어떻게 될까. 한정된 Host OS
자원으로는 애플리케이션을 감당하기 어렵게 된다. 하이퍼바이저도 Host OS와 Guest OS, 애플리케이션을
중재하는 과정에서 많은 부하가 걸리게 된다.

도커(Docker)는 하이퍼바이저와 달리 Guest OS를 두지 않고 Host OS 커널을 바로 사용한다.
하이퍼바이저 대신 도커(Docker) 엔진이 올라가, Host OS와 여러 애플리케이션을 연결해주는 역할을 한다.
따라서 도커(Docker)를 사용하면 애플리케이션을 좀더 빠르고 효율적으로 실행시킬 수 있다. 

      [네이버 지식백과] 도커 - 오픈소스 진영의 샛별 (용어로 보는 IT, 이지현)

위 도커(Docker)의 로그를 보면 고래위에 컨테이너가 실려있죠.. 이 컨테이너가 어떤 하나의 완전한
프로그램을 실행하는데 필요한 소스와 런타임 뿐만아니라 시스템도구도 등 완전한 세트가
들어가 있는 거죠.  

도커(Docker)가 뜨는 이유
1. 개발자들은 개발할 때 이전에는 이 프로그램이 돌아가는 환경.OS 등이 먼지를 알고 
   그에 맞게 언어를 선택해서 개발을 했지만 도커(Docker) 가 등장한 이후에는 그런 거 
   신경 안쓰고 개발에만 집중할수 있게 되었다.. 어차피 컨테이너에 실려서 실행되는
   독립적인 구조이기 때문..
2. 기존 가상화 기술에 비해서 도커(Docker) 는 더 가볍고 이식성이 뛰어남.

도커(Docker)의 구성요소

구분 내용
LXC (Linux Container) LXC 로 만든 컨테이너는 고유의 파일시스템,프로세스,네트워크
공간을 가짐.
가상머신처럼 독립적인 공간
이미지 필요한 프로그램과 라이브러리 , 소스를 설치한 뒤 파일로 만든 것
컨테이너 이미지를 실행한 상태


도커(Docker)의 특징

구분 내용
Host OS 공유방식 여러 개의 어플리케이션이 Host OS 공유
빠르고 가벼운 가상화기술 최소한의 리소스만 할당받아 동작하는 방식
가상화 기술은 하나의 노트북에 다른 노트북을 하나 더 올려서 사용하는 방식으로 아무래도 무거울  수밖에 없음.
반면 도커(Docker)는 어플리케이션을 실행하기 위한 파일만 돌리기 때문에 훨씩 효율적이고 필요한 만큼만 CPU나 메모리를 사용하기 때문에 부하가 적음.
이식성 다양한 환경에서 실행
자유로운 개발환경 개발언어, 툴에 상관없이 어떠한 어플리케이션을 만들어도
상관없음.
개발과 운영 호환성 증가 플랫폼에 상관없이 애플리케이션을 신속하게 제공

 

728x90
반응형
LIST
728x90
반응형
SMALL

이 TOC 이론이 발표되기 전에는 어떤 생산시스템의 각각의 기능 (기계,인력등)을 최적으로 향상시키면
그 각각의 향상된 기능의 합이 전체 생산시스템의 기능의 향상이 된다라는 이론이 지배적이었다.

반면 TOC (Theory of Constratins) 제약이론은 이와는 다르게 각 생산공정 중에서 가장 제약이 되는, 예를
들자면 가장 느린 공정에 의해서 전체 생산속도가 좌우되므로 이 느린 공정을 개선 시키면 전체 속도가
빨라진다는 개념이다.. 즉 각 개별 공정을 각각 개선시키는게 아니라 가장 Critical 한 공정을 찾아서
고것만 개선을 해도 전체 성능이 향상된다는 뜻이다.
이렇게 하면 아무래도 전체를 각각 개선시키는 비용보다는 적게 들기 때문에 비용대비 효과가 좋다고
할수있다.

이 이론과 비슷한 것이 CP (Critical Path) 로 전체 소요시간은 Critical path의 소요시간보다 적을수는 
없다. 즉 전체 소요시간을 줄일려면 딴 경로를 줄여야 소용없고 이 CP의 시간을 줄여야 전체시간이
줄어들수 있다는 것이다.  제약이론도 이 제약공정의 앞뒤 공정을 개선해봤자 이 제약공정때문에
효과가 없기 때문에 이 제약공정을 개선해야 그 효과를 볼수 있다는 뜻이다.

이 제약이론은 이스라엘의 물리학자 엘리 골드렛 박사가 1984년 발표했다. 이 이론으로인해
 JIT (Just In Time)  등 경영혁신기법으로 무장한 일본경제에 밀리고 있던 미국 경제가 살아나는 계기가
되었다고 할 정도로 높이 평가가 되었다..  그래서 이 이론이 다른 나라에도 도입이 되어서 급성장할
까봐 17년동안 이책의 번역을 금지했다는 썰이 있기도 한다.

<출처 : 네이버카페 "한국청년물류포럼" >

제약이론에서 이익을 극대화 하기 위한 조건들로는 다음과 같다.

Throughput (처리량) 을 증대시킬 것
Inventory (재고량) 을 절감시킬 것
Operating Expense(운영경비)를 절감시킬 것

제약이론의 특징은 다음과 같다.

특징 설명
전체 최적화 개별부분의 최적화가 아닌 전체관점의 최적화
제약사항 고려 기업의 제약자원을 고려하여 지속적 개선을 촉구
집중 개선 병목(bottleneck), 즉 가장 약한 부분이 전체를 좌우


제약이론은 프로세스 최적화를 위해서 DBR(Drum-Buffer-Rope)이라는 핵심 개념을 설명한다.

Drum 전체 시스템의 속도는 결국 병목공정의 속도에 의해 결정되므로
모든 공정의 속도는 병목공정의 속도에 맞춰야 한다는 뜻이다.
여기서 Drum 이란 두드리는 드럼의 박자에 맞춰 나머지 사람들이 행진
하듯이 병목공정의 드럼의 박자에 맞춰 다른 공정들이 속도를 맞춰야 한
다는 뜻이다.
Buffer 모든 공정이 Drum에 맟춰서 착착 진행을 하고 있는데 병목공정 이후 공정
중에서 문제가 생겨서 병목공정이 멈춘다거나 지연된다고 하면 전체
공정이 느려지기 때문에 병목공정과 뒷 공정 사이에 Buffer 를 두어 Drum
이 중단되지 않도록 하는 것을 말한다.
Rope Buffer의 경우와 반대로 병목공정 다음의 공정에서 너무 빨리 진행이 되어
버리면 병목공정과 뒷공정 사이에 간격이 벌어지게 된다. 
이를 방지하고자 병목공정과 뒷공정을 Rope 즉 줄로 묶어서 간격이 벌어지
지 않도록 하는 개념이다. 

 

728x90
반응형
LIST
728x90
반응형
SMALL

1. 치질 증상 
몇년 전부터 화장실에서 일을 볼때 먼가 혹같은 것이 돌출되기 시작했고 일을 보고나서
휴지로 뒷처리하면서 같이 밀어 넣어줘야 들어가기 시작했다..
통증은 없었지만 대변 자체가 시원스럽게 나오지 않았고 (이 혹이 막고 있는 느낌..)
뒷처리 하는 것도 휴지가 많이 필요했다...
하지만 통증은 없었기에 그냥 그렇게 지내다가 '치센'이라는 약 선전을 보고 몇 번 사서
먹었지만 먹을 때만 살짝 효과가 있고 그리 큰 호전은 없었다..(약값만 비싸고..)
병원에 가보려고 했지만 머 다들 그렇지만 부위도 그렇구.. 또 수술해야 한다고 하면
또 어쩌나 하는 생각에 그냥 그리 지냈다..
그러다가 혹시 병원에 가면 수술안하고 다른 방법으로도 치료가 가능할지도 모르지 않나
하는 생각에 회사근처 한솔병원에 예약을 했다.. 이 한솔병원은 우리 어머니도 치질수술을
한 곳으로 근방에서는 그래도 인지도 가 있는 항문전문 병원이다..

2. 첫 왜래 진료
예약한 날 병원에 가서 진료를 받았는데.. 좀 당황스러운... 가자마자 바지를 벗고 침대에
누우라고 하시더니 침대 벽에는 자세를 그림으로 그려서 붙여 놨는데... 바지를 벗고
옆으로 누우면서 새우자세로 다리를 가슴팍까지 올리는 자세이다..한마디로 민망한 자세
그렇게 누웠더니만 의사가 손가락을 내 항문에 찔러서 이리저리 휘젓는 느낌이 났다
이게 웬 상황.. 나도 넣어보지 않은 똥꼬에 손가락을 찌르는 상황.. 난감..창피..머..
검사 끝나고 의사가 사진을 보면서 바로 "수술해야 합니다" 라고 하시면서 바로 날짜를
고르라고 하시더라구요.. (원래 이 원장님은 말수가 없으신 분이다). 
올것이 왔구나 하는 생각에 이와 할꺼면 빨리 해야지 생각하고 다음주 금토일로 예약을
했다.. 그리고 나서 집사람에게 수술사실을 통보하면서 이야기를 하다가 이왕 할꺼면
빨리 하자고 해서 아예 이번주 금토일로 하는게 어떠냐고 해서.. 그렇게 할려다가
이번주 일요일에 장모님 생신모임이 있어서 , 목금토 로 다시 변경을 해서 예약을 했다.
이때만해도 토요일 퇴원해서 일요일 모임 갔다가 월요일에 출근하면 되겠지 하는
생각을 했었다.. ㅋㅋㅋㅋㅋㅋ

3. 입원 및 수술 
하계휴가 2일을 써서 7월25일 목요일에 입원을 했다.. 입원하고 나서 얼마 있다가
관장을 해주시는데 난생처음 관장은 첨 해보는 거라..... 여자 간호사가 오셔서 무슨
호스를 내 똥꼬에 질러서 주사기로 먼가를 주입하는 느낌... "5분정도 참았다가 화장시
가세요" 라고 했는데.. 난 머 1분도 안되어서 응가가 나올꺼 같은 느낌이 강하게 들어서
바로 화장실로 직해.. 아까 주입한 액체 반, 대변 반이 섞여서 쏟아져 나왔다...
이때부터 벌써 기진맥진... 그러구 침대에서 쉬고 있었는데... 2시 경에 수술하러 가자고
남자 간호사분이 침대를 끌고 오셔서 거기에 누워서 수술실로 직행..
30년전 고2때 축농증 수술 받은 후 첨 수술실에 들어갔다..  
수술실 침대로 옮겨 탄 후 바지를 내리고 마취를 허리에 했다.. 마취주사를 별로 아프지는
않았다.. 그러고 난후 침대에 반듯이 엎어져 있었다. 엉덩이를 깐채로.. ㅠㅠ
그리고 귀에는 해드폰을 쒸어 주었는데 나오는 음악은 무슨 경음악 같은게 흘러나왔다.
이왕이면 가요로 틀어주지.. 
점차 마취의 기운이 엉덩이 부위에 퍼지면서 감각이 무뎌지기 시작했다. 
그러고 한참있다가(20분은 흐른듯..) 의료진이 들어와서 엉덩이 항문쪽을 좌우로 벌려서 
고정하는 느낌이 들었고.. 이후 의사 두분이 먼가 작업(?)을 하시는 거 같은데 아무 느낌이
없었다..  수술시간은 한 15분 정도 걸린거같고..끝나고 항문에다가 먼가 잔뜩 틀어 막고
다시 병실로 옮겨졌다.. 물론 아직 마취상태라서 통증은 거의 없었다..
팔에는 항생제 링거르 꼽은 상태에서 절대 4시간동안 머리를 들지 말라는 당부를 했다.
중간에 머리를 들면 두통이 엄청 온다고...  마취주사를 놓을 때 생긴 구멍으로 뇌척수액이
흘러나오면서 뇌척수액의 압이 낮아져서 두통이 올수 있다고 한다..
4시간 동안 꼼짝없이 있는데 이거 또한 곤역이었다..
다행이 마취주사로 인한 두통은 없었다.. 

4. 수술 첫날밤. (목요일)
저녁에 간단한 죽이 나와서 맛있게 먹었고,, 간호사분이 무통주사를 팔에 달아주셨다.
이 무통주사는 자기가 버튼을 누르면 일정액이 주사바늘을 통해서 몸에 투입되는 방식이다
비싸다고 함.. 10만원 정도 하는듯.. 자주 누를수는 없구 2~30분 지나야 다시 누를수있는
형태로 돌아온다.. 그 전에 눌러봤자 헛심.. 어떤 분은 퇴원해서 너무 아파서 다시 병원에
가서 이 무통주사를 달고 오시는 분도 있다고 한다.
저녁 먹을때까지는 그런데로 살만했다..통증도 그리 심하지 않고.. 거즈만 자주 갈아주었다.
거즈에는 금방 피랑 진액 같은것이 잔뜩 묻어 나온다.. 
그런데. 밤이 되니깐 슬슬 신호가 오기 시작했다.. 엉덩이 부분에 통증이 오면서 계속 응가가
마려운듯한 느낌이 계속 들기 시작했다..통증보다 오히려 이 느낌이 더 참기 어려웠다..
당장이라도 응가가 나올꺼 같은 그 느낌이 밤새 조여왔다.. 통증도 더 심해지고.. 무통주사
를 연신 눌렀지만.. 통증이 나아지지 않아서 간호사 분께 말했더니 진통제를 주사로 놔주시
겠다고 해서 밤 12시 다되어서 주사를 맞았다..이 주사를 맞으니깐 좀 나아지는 느낌이
들었다.. 그렇게 밤새 잠도 못자고 날밤을 지세면서 새벽에 잠깐 잠이 들었다..

5.수술후 두번째 날 (금요일)
전날 밤새 고생한데다가 무통주사 부작용인지 속이 울렁거려서 아침밥을 먹기가 힘들었다.
낮에 집사랑이랑 딸아이가 와서 과일이랑 음료수를 먹고 좀 나아졌다.
퇴원하기전에 한번 응가를 해야지 안그러면 관장을 해야 한다고 해서 응가가 마려웠으면
좋겠는데 전혀 기미가 보이지 않았다.. 그래도 어제보다는 훨 수월하게 하루를 보냈다.

6. 수술후 세번째 날 퇴원 (토요일)
결국 대변을 못봐서 관장을 했지만 머.. 나오는건 별로 없었다. 이때까지도 진통제때문에
그런지 통증은 그리 심하지 않았다.. 그래서 퇴원하고 나서 직접 운전까지 하는 과감한
행동을 했지만 이건 나의 착오였다.. 차를 몰고 바로 작은 처제가 있는 병원에 가서
진통제를 맞고 이후 집에서도 맞을 수 있게 주사바늘을 꽂은 채로 집으로 왔는데..
아뿔사..집으로 오는길에 두통이 밀려오기 시작했다..그래서 타이레놀을 두알 더 먹었는데
와~~통증이 더 심해졌다..  알고보니 무통주사의 부작용이었다.. 무통주사를 빼니깐 
얼마 안있어서 통증이 오기 시작한거다.. 머리가 깨질듯이 아파서 가만히 있지를 못하고
데굴데굴 굴러다니기까지 했다.. 엉덩이쪽 통증은 잊은채....
저녁 9시가 넘어서야 좀 두통이 사라졌고.. 그니낀 이번에는 항문쪽에 통증이 오기시작했다.
그래서 집사람이 진통제를 놔줬고 그제서야 좀 나아지면서 잠을 청할 수 있었다.

7. 수술 후 4일째 (일요일)
아침에 일어나서 다시 진통제 주사를 한대 맞고.. 장모님 생신모임에 갔다.. 진통제때문인지
큰 통증없이 잘 행사를 치루고 왔다. (작은처제에게 감사)

8. 수술 후 5일째 (월요일)
아침에 일어나서 다시 진통제 주사를 맞고 출근을 했다... 
회사에 와서 간신히 앉아있으면서 일을 했다..  그런데 거즈를 자주 갈아줬어야 하는데
그만 그러지 못해서 그만 진물이 사타구니쪽으로 흘러서 그쪽이 쓰라렸다..
그리고 거즈를 댈때 테이프로 고정을 시켰는데 이 테이프 자체 접착제 성분때문에
엉덩이 부분에 더 안좋은 영향을 미친다.. 
권장하는데 스카치테이프 쓰지 마시고 그냥 거즈를 엉덩이에 끼우는 방식으로 하시고
자주 갈아줘야 한다. (엉덩이에 끼우면 움직이다보면 빠지게 되지만 차라리 그게 낫다)
또 하나 권장사항은 병원에서는 2박3일이면 일상생활이 가능하다고 하는데..물론 움직
일수는 있다..하지만 그래도 살을 잘라내는 수술이기 때문에 2박3일후에 바로 출근하는건
비추이다.. 기간은 최소한 1주일 정도는 잡아야 한다.. 
집에 와서 좌욕을 하니깐 좀 사타구니쪽이 나아졌다..

9. 수술 후 6~8일째
수술후 6일째 첨으로 대변을 봤다.. 
아 근데..이때 첨으로 극강의 고통을 맛봤다.. 누구는 마치 톱을 싸는듯힌 느낌이다
항문에서 칼이 니오는 느낌이다..라는 식으로 표현을 했는데.. 머 좀 과장된 표현이지만
정말 응가를 할때와 하고 나서 넘 아팠다... 넘 아파서 벽을 부여잡고 어쩔줄 몰라했다.
이런 느낌은 3일정도 겪었다.. 집에서는 응가한후 좌욕을 하면 조금 통증이 덜했지만
회사에서는 그냥 쌩으로 이 고통을 느낄수밖에 없었다.. 
아 이때..첨으로 수술을 괜히 했나 라는 후회감이 들었다.. 한가지 좋은 건 응가가
시원스럽게 쑥쑥 막힘없이 나와서 그 느낌은 정말 오랜만이었다.. 수술전에는
매번 응가해도 먼가 덜한듯한 느낌이 항상 들었었다...
다행히 3일후에는 응가후 통증이 훨 덜해졌다..

10. 수술 후 4주차
이젠 어느정도 통증은 많이 사라졌으며 응가시 통증도 훨씬 좋아졌다..
그래서 어떤날은 하루에 3번씩 화장실을 가기도 했다..
물론 마그밀이라는 약을 먹어서 그런지 변은 무르게 나왔다..
하지만 여전히 진물은 조끔씩 나와서 거즈는 계속 대고 있어야 했다..

11. 수술 후 5주차
5주차에 접어들자 거즈도 거의 필요없게 되었다. 팬티에 살짝 묻는 경우도 있었지만
거즈를 안대니깐 속이 시원했다.. 거즈를 그동안 3통 정도 쓴듯..
 대변볼때 약간은 항문 구멍이 좁아진 느낌이 나서 응가할때 간혹 잘 안나오는 경우도
있었다.. 힘을 주면 간신히 나오기는 하는데.. 힘주기가 너무 두려웠다..왜냐.. 재발할까봐
그래서 식이섬유를 많이 섭취하기 위해 채소,과일을 많이 먹었는데..그런 날은 변이
확실히 무르게 나오고, 고기나 기름진거 밀가루 이런거 먹은 날에는 변이 좀 단단해져셔
항문구멍을 통과못하는 느낌이 나곤 했다... 
그래도 이제는 좀 살만해졌다... 변도 시원하게 보고 통증도 거의 없고..진물도 더이상
나오지 않았다..  다른 사람 후기를 보면 2달이 지나도 진물이 나온다는 둥.. 좋지 않은
예후를 보이는 사례도 있어서 나름 걱정을 했다.... 어떤 분은 재수술까지...와~~정말
재수술하다고 생각하면 정말 죽고싶다는 충동이 들정도로 ..무서웠다..
다행히 가끔 변이 안나와서 변비 비스무리한 증상이 있는 경우랑 아직까지는 항문구멍이
좁다는 느낌 말고는 지금은 거의 정상상태로 돌아온거 같다.
  

 

 

 

 

 

728x90
반응형
LIST

'나의일상' 카테고리의 다른 글

베트남 다낭 여행 후기  (0) 2020.01.10
728x90
반응형
SMALL

COCOMO II 는 실제 개발된 소스를 가지고 비용을 산정하는 고전적인 기법이다.
규모요인(Scaling Driver)과 가격요인(Cost Driver) 등을 이용하여 프로젝트의 생산성, 가격을
결정하는 모델이다.
COCOMO 는 소프트웨어를 구성하고 있는 모듈과 서브시스템의 비용합계를 계산하는 방식
으로 구조적방법론에 적합은 했지만 이후 객체지향모델이 나오면서 이에 맞게 수정보완한
것이 COCOMO II 이다. 
COCOMO II 는 소프트웨어 개발프로젝의 진행정도에 따라 아래와 같이 3단계로 나누고
각 단계별로 각각 다른 비용산정모델을 적용해서 해당 소프트웨어의 규모를 산정하는
기법이다.

Application Composition 응용 조합 모델
Early Designed Model 초기 설계 모델
Post-Architecture Model 설계 이후 모델


<참고>
   기존 COCOMO의 문제점
  -   소프트웨어 제품을 하나의 개체로 보고 승수들을 전체에 적용
  -   실제 대부분의 대형시스템은 서로 상이한 서브 시스템으로 구성
  
-   전통적인 COCOMO 모델의 문제점 극복을 위해서 COCOMO II 모델 등장

분류 응용조합모델
(Application Composition)
초기설계모델
(Early Design)
구조설계모델
(Post-Architecture Model)
설명 초기단계에서 시제품 개발시 적용. 즉 프로토타입을 보고
입출력화면 중심의 사용자UI 갯수를 파악해서 객체점수(Object Point)를 산출하고 이
를 바탕으로 SW규모를 산정
한다.
• 개발 범위에 속한 객체(입·출력 화면 등)를 찾는다.
• 객체에 의해 제공되는 기능의 복잡도를 세 가지(단순형, 보통형, 복잡형)로 분류한다.
• 객체의 개수에 가중치(단순형, 보통형, 복잡형)를 부여하여 결과 값을 산출한다
초기 설계 단계쯤 되면 1단계보다는 시스템의 구조와 기능을 좀 더 상세히 알 수 있다. 그러므로 1단계보다 더욱 정확한 예측이 가능하다.  구조 설계 이후가 되면 시스템에 대해 어느 정도 자세한 윤곽이 드러난다. COCOMO 방법이 처음부터 원시 코드의 라인 수를 계산하는 무리한 방법을 썼다면, 3단계에서는 이미 기능 점수가 나왔기 때문에 COCOMO에서 제안한 LOC에 의해 소요되는 노력을 추정하는 것이 크게 어렵지 않다. 즉 3단계에서는 기능 점수를 바탕으로 한 LOC를 추정하여 소프트웨어 규모를 산정할 수 있다.
크기 Application Points FP + 언어종류 FP + 언어 LOC
목적 UI, 3GL 컴포넌트 개수를 통해 노력 추정 자세 기능 탐구 시스템에 대한 자세한 이해
SW 개발/유지보수 노력도 측정

구조설계이후(Post-Architecture Model)  모델의 계산방식 
  : 규모요소 (규모,가격) 와 노력가중치를 사용하여 측정

구분 규모요소 설명
규모요인
(Scaling Driver)
경험성 개발하려는 소프트웨어와 비슷한 소프트웨어의 개발 경험 정도
개발유연성 소프트웨어 개발에서 허용되는 유연성 정도
프로세스 성숙도 개발 조직의 소프트웨어 개발 프로세스 성숙도
가격요인
(Cost Driver)
제품 복잡도 제품에 대한 5가지 영역의 복잡도 수준
플랫폼 가변성 OS, DB, Complier와 같은 플랫폼의 가변성 정도
소프트웨어 도구사용 프로젝트에서 사용되는 자동화 도구의 종류와 사용정 도를 나타내는 비용인자
개발일정 프로젝트 팀에게 부과되는 일정 제약 정도를 나타내는 비용인자
728x90
반응형
LIST

+ Recent posts