NFT 개념​

• 블록체인을 활용해 디지털 콘텐츠를 포함한 자산의 원본성을 보장하고 소유권을 주장할 수 있게 하는 가상 토큰
• 온라인 및 메타버스 내에서 생성된 컨텐츠를 위한 저작권 증명을 위해 필요.

NFT 구성도, 구성요소​

NFT 구성도​

NFT 구성요소​

구분	구성요소	비고
표준 프로토콜	ERC-721	NFT
	ERC-1155	다중 토큰
기술요소	NFT Contract	스마트 계약
	NFT Metadata	컨텐츠 태그
	NFT Mint	NFT 발행
	IPFS	NFT 미디어 데이터 저장

NFT 비교​

구분	FT	NFT
토큰 정보	토큰 이름 및 약어	고유 정보
상호 교환성	O	X
분할성	O	X
활용	송금, 물품 구매	자산 소유권

NFT 고려사항​

• NFT가 디지털 자산의 소유권은 증명하지만 저작권은 별도 소유가 가능하므로, 제도적 관리 필요

블록체인 개요​

블록체인 개념​

• 탈중앙화된 P2P 네트워크를 기반에 합의알고리즘을 통해 무결성을 제공하는 분산 원장 기술

블록체인 배경​

• 합의속도와 보안성 강화를 위해 프라이빗 블록체인 등장, 투명성과 분산성을 향상시키기 위해 하이브리드 블록체인 확장

퍼블릭 블록체인, 프라이빗 블록체인 구성도, 구성요소 비교, 한계점​

퍼블릭 블록체인, 프라이빗 블록체인 구성도​

• 프라이빗 블록체인은 특정 통제 기관에서 트랜잭션 합의 처리

퍼블릭 블록체인, 프라이빗 블록체인 구성요소​

구분	퍼블릭 블록체인	프라이빗 블록체인
참여주체	누구나	지정된 사용자
소유자	없음	특정 기관
탈중앙성	높음	낮음
확장성	낮음	높음
보안성	낮음	높음
투명성	높음	낮음
트랜잭션 속도	느림	빠름
합의알고리즘	PoW, PoS	PBFT, Raft 등

퍼블릭 블록체인, 프라이빗 블록체인 한계점​

• 퍼블릭 블록체인은 투명성과 탈중앙성이 높지만, 속도와 확장성이 낮음
• 프라이빗 블록체인은 속도와 확장성이 높지만, 투명성, 분산성이 낮아 하이브리드 모델 등장

하이브리드 블록체인 개념, 특징​

하이브리드 블록체인 개념​

• 퍼블릭 블록체인과 프라이빗 블록체인의 장점 결합, 일부 데이터를 공개로 유지하고 민감 데이터를 비공개 트랜잭션 처리

하이브리드 블록체인 특징​

구분	내용	비고
참여주체	일부 공개, 일부 허가된 사용자	퍼블릭, 프라이빗 체인 혼합
탈중앙성	부분 탈중앙화	퍼블릭 체인의 장점
합의 알고리즘	DPoS 등 혼합	다양한 합의알고리즘 사용

하이브리드 블록체인 활용방안​

구분	내용	비고
공공	투명성 요구 높은 공공기록 관리	민감데이터 프라이빗 체인
금융	금융 거래 투명성	고객 정보 프라이빗 체인
민간	기업 내부 기록, 거래 스마트 계약	비지니스 민첩성, 보안성

• 다양한 요구사항에 따라 데이터 접근, 검증방식 조절 가능

음성 데이터 마이닝의 개요​

음성 데이터 마이닝의 개념​

• 음성 신호나 데이터를 기계적으로 처리하여 화자의 의견, 감정에 대한 정보를 도출하는 과정

음성 데이터 마이닝 배경​

• HMI(Human Machine Interface)가 기존의 텍스트에서 음성으로 변화하고 있고, 톤과 인토네이션의 차이로 같은 문장이라도 화자의 감정 파악 가능

음성데이터 마이닝의 구성도, 구성요소​

음성데이터 마이닝의 구성도​

음성데이터 마이닝의 구성요소​

구분	내용	비고
처리기술	음성 데이터를 디지털 형식으로 변환하고 처리하는 기술	STT, Media Codec, ADC
분석기술	음성 데이터를 분석하고 의미를 도출하는 기술	데이터 분석 인프라, 시계열 분석 알고리즘, 감정 분석 알고리즘, 상황인지 컴퓨팅

음성 데이터 마이닝 적용 방안​

구분	내용	비고
공공	공공 서비스 접근성을 높이고 사회적 포용성을 증대	음성 민원 자동화
기업	업무 효율성 증대 및 운영 비용 절감	회의록 생성 자동화, 무인화 고객센터, AI 경쟁력 강화
민간	개인 편의성 증대 및 새로운 서비스 창출	실시간 번역 제공, 비대면 원격 진료 기반 마련, IoT 기기 제어

음성 데이터 마이닝 성공 포인트​

• 클라우드 컴퓨팅을 활용하여 온디맨드 방식의 데이터 분석/처리로 비용 절감

데이터 저장 특성 개요​

데이터 저장 특성 개념​

• 웹 서비스와 인터넷 패러다임의 변화로 인해 데이터의 저장, 접근, 처리 기술의 발전

데이터 저장 방식 변화의 필요성​

• FS에서 인터넷의 등장으로 DB 공유, 웹3.0의 출현으로 탈중앙화와 소유의 개념을 가진 블록체인 구조에 정보 저장

파일, 데이터베이스, 블록체인 개념 및 비교​

파일, 데이터베이스, 블록체인 개념​

아래 그림

• FS: Inode -> block
• DB: Table, System Catalog
• BlockChain: hash based linked list block + merkle tree

파일, 데이터베이스, 블록체인 상세비교​

구분	파일	데이터베이스	블록체인
개념도
저장단위	파일	테이블	블록체인
저장위치	로컬	중앙 시스템	분산원장
저장속도	빠름	트랜잭션처리, 빠름	합의알고리즘, 느림
데이터 저장 방식	FS API	DDL, DML	합의 알고리즘
트랜잭션	없음	ACID 보장	합의 알고리즘으로 트랜잭션 처리
데이터 중복	단일 데이터	역정규화로 일부 허용	참여자 전체 중복 저장
종류	FAT, NFTS	RDBMS, NoSQL	Public, Private, Hybrid

블록체인 저장 방식의 문제점과 해결방안​

블록체인 저장 방식의 문제점​

• 탈중앙화, 확장성, 보안성 중 모두를 만족할 수 없는 블록체인 트릴레마 존재
• 합의 알고리즘 수행에 시간이 걸리므로, 실시간 웹 서비스에는 부적합

블록체인 저장 특성 문제 해결방안​

구분	내용	비고
레이어링	데이터와 처리계층의 분리로 확장성 향상	오프체인, 사이드체인
샤딩	데이터 불할 처리로 확장성 향상	체인네트워크 샤딩, 코디네이션
하이브리드	중앙집중과 탈중앙화의 절충점으로 신뢰성, 보안성, 실시간성 강화	RDBMS, 카프카 사용

• 블록체인 트릴레마와 실시간성 극복을 위해 데이터를 분리하여 처리

파일, 데이터베이스, 블록체인 적용방안​

파일	데이터베이스	블록체인
개인/기업 데이터저장	엔터프라이즈 어플리케이션	암호화폐
멀티미디어	웹 어플리케이션	공급망 관리
IPFS	빅데이터 분석	스마트 컨트랙트

오토스케일링 개념​

• 시스템 자원 매트릭을 모니터링하여 서버 사이즈를 자동으로 조절하는 기술
• 클라우드 컴퓨팅의 온디맨드 방식을 기반으로 자원 최적화, 고가용성, 온프레미스 대비 운영의 단순화를 위해 필요

오토스케일링의 구성​

Pod, 메트릭모니터링, 로드밸런서 이미지

구성요소​

구분	기능	설명
정책, 모니터링	메트릭 수집, 알람 전송
서버 이미지 배포	Scale-Out, Scale-In, 서버 프로비저닝
서비스 연결	Health-Check, 트래픽 제어

오토스케일링시 서버 추가까지 필요한 경우, Scale-Up이 비용절감의 효과를 가져올 수 있음.

비교​

스케쥴기반, 부하기반​

구분	스케쥴 기반 오토스케일링	부하 기반 오토스케일링
트리거	예약된 시간	트래픽
수치	예측 가능한 부하	실제 사용량 기반
장점	트래픽 증가 지연 방지	효율적인 리소스 사용량
단점	예측을 벗어날시 리소스 낭비, 부족	인스턴스 배포시간으로 인한 지연

Scale Up, Scale Out​

구분	Auto Scale Up	Auto Scale Out
추가리소스	CPU, Memory	인스턴스
장점	인스턴스, NW관리 없어 간단	높은 확장성, 인스턴스 장애 격리
단점	물리적 한계, 고비용, 시스템 다운타임	복잡한 NW구성, 세션 처리 등

성공포인트​

• maxUnavailable, maxSurge 적절히 조절
• scale down 으로 비용 절감

클라우드 컴퓨팅의 개념​

• 가상화 기술을 이용하여 사용자 필요시 인터넷을 통해서 서비스 형태로 IT자원을 제공하는 컴퓨팅 기법
• 클라우드 컴퓨팅에 대한 고객, CSP의 서비스책임 범위, 인프라 소유권에 따라 서비스모델, 배포모델로 분류

클라우드 컴퓨팅 모델의 구성도, 구성요소, 비교​

클라우드 컴퓨팅 모델의 구성도​

클라우드 컴퓨팅 모델의 구성요소​

• 서비스 모델: 클라우드 자원의 제공 방식에 따른 분류

구분	내용	비고
IaaS	인프라(서버, 스토리지, 네트워크 등)를 제공하는 모델	사용자 관리 책임
PaaS	플랫폼(개발 도구, 데이터베이스, 런타임 환경 등)을 제공하는 모델	공통 관리 책임
SaaS	소프트웨어(애플리케이션)를 제공하는 모델	제공자 관리 책임

• 배포 모델: 클라우드 자원 소유주체와 관리방식에 따른 분류

구분	내용	비고
Private	특정 조직만을 위해 독립적으로 구축된 클라우드 환경	사용자 소유
Public	일반 대중에게 공개되어 누구나 이용 가능한 클라우드 환경	제공자 소유
Hybrid	Private Cloud와 Public Cloud를 혼합하여 사용하는 모델	혼합 모델

배포모델과 서비스모델 비교​

구분	배포모델	서비스모델
목적	지속 가능 서비스 기반	온디맨드 서비스
범위	클라우드 구성 환경	클라우드 서비스
접근	온프레미스와의 연결성	비용 절감

• 온프레미스 서비스의 구성 환경에 따라 배포모델을 선택하고, 비지니스 요구사항과 비용에 맞는 서비스모델을 선택

클라우드 컴퓨팅 활성전략​

구분	활성전략	내용
배포모델	공공기관/지자체 민관협력형 클라우드	공공기관이 민간 CSP와 협력해 전용 클라우드 환경 구축
	금융사 하이브리드 멀티 클라우드	금융권이 퍼블릭·프라이빗 클라우드를 혼합 운영해 보안·효율성 확보
서비스모델	CNCF Cloud Native App	컨테이너·마이크로서비스 기반 클라우드 네이티브 앱 개발 모델
	K-PaaS	국내 맞춤형 PaaS, 개발·운영 환경 지원

• 기업은 목적에 맞는 전략을 활용하여 적절한 모델을 선택

클라우드 컴퓨팅 고려사항​

• 해당 국가의 법, 제도적 규제사항을 만족하기위한 소버린클라우드와 재난시 빠른 복구가 가능한 멀티클라우드 구축 고려

개요​

• 어렸을 때 어디선가 속독 책을 봤는데 기호가 난무하고 암호가 즐비한 책인 줄 알았다.
• 한 번 봐도 큰 효과는 없길래 사기구나 싶었다.
• "당신도 지금보다 10배 빨리 책을 읽는다"란 책 후기에 넘어가 도전해보려고 한다.

기준​

단어 수 기준으로는 이렇다.

• 일반인: 600자/분
• 명문대학생: 1,500자/분
• 따라읽기의 한계치: 3,000자/분
• 속독: 10,000자/분

방법​

완벽하게 하려고하지 않는다. 속으로 따라읽지 않는다. 머리나 몸은 고정한다.

빠르게 보기​

• 가로, 세로, 횡대각, 종대각
  • 눈에서 15~20cm 거리에 둔다.
  • 각 점을 따라 0.5초 이내의 속도 간격으로 눈동자를 크게 움직인다.
  • 1에서 10까지 10에서 1까지 돌아온다.
  • 각각 30초씩 반복한다.
  • 시선을 크고 빠르게 움직이는 것을 의식한다.
• 원 운동
  • 눈에서 15~20cm 거리에 둔다.
  • 원 한 바퀴를 왕복하는데 10초 정도로 천천히 시선을 움직인다.
  • 원 운동을 3번 반복한다.
• 기호 2점
  • 눈 가까이 가지고 올 필요는 없다.
  • 좌우의 점만을 교대로 응시한다.
  • 가능한 빠르게 60초 동안 본다.
• 문자 2점
  • 눈 가까이 가지고 올 필요는 없다.
  • 좌우의 점만을 교대로 응시한다.
  • 가능한 빠르게 60~90초 동안 본다.

능동 시야, 수동 시야 늘리기​

• 단계
  • 1단계: 10단어씩 끊어서 그 시야 폭의 가운데를 본다.
  • 2단계: 능동시야를 1행으로, 수동시야를 3행으로 늘린다. 똑같이 문장의 가운데를 본다.
  • 3단계: 능동시야를 3행으로, 수동시야를 5행으로 늘린다. 속독의 시작.
• 시야폭 늘리기
  • 눈에서 15~20cm 거리에 둔다. 마지막 사각형이 수동시야에 들어올듯 말듯한 거리
  • 작은 사각형에서 큰 사각형으로 본다. 큰 사각형까지 봤으면 다시 작은 사각형에서 시작한다.
  • 하나의 사각형을 0.5초 간격으로 본다.
  • 90~180초 동안 반복한다.

요약​

• 따라 읽지 않고, 글자를 더엉리로 보며 이해하는 연습을 꾸준히 하는 것
• 시야 (수동시야)를 넓혀 한 번에 인식할 수 있는 양을 큰 폭으로 늘리는 것
• 전자책은 수동시야에 다음 단락이나 문장이 보이지 않으므로 속독에는 비적합
• 정독으로도 이해 못하는 내용은 속독으로도 이해 못한다.

화이트박스, 블랙박스 테스트 개요​

화이트박스, 블랙박스 테스트 개념​

화이트박스, 블랙박스 테스트 배경​

• 테스트 V모델에서 요구사항/분석/설계/코딩 측면은 개발자 관점의 화이트박스 테스트로 Verification 하고,
• 단위/통합/시스템/사용자 테스트 측면은 사용자 관점의 블랙박스 테스트로 Validation 하게 설계 필요.

화이트박스, 블랙박스 테스트 개념도, 핵심요소, 적용방안​

화이트박스, 블랙박스 테스트 개념도​

• 내부구조를 파악하는지 여부에 따라 기법 변경

화이트박스, 블랙박스 테스트 핵심요소​

구분	화이트박스	블랙박스
테스트기반	소스코드, 제어흐름그래프	요구사항명세서, 유스케이스
테스트설계	문장커버리지, 결정커버리지, 조건커버리지, 경로커버리지	동등분할, 경계값 분석, 오류추정, 원인/결과 분석
테스트목표	코드의 정확성, 안정성, 완전성 검증	기능요구사항 충족여부, UX 및 시스템 동작 검증
테스트시점	개발 초기 단계	개발 후반 단계
테스트자동화	JUnit, Jest 등 단위테스트 프레임워크	Selenium, Playwright 등 UI테스트 프레임워크
장점	숨겨진 결함 발견 용이, 테스트 커버리지 향상	사용자 관점 검증, 비교적 쉬운 TC 설계
단점	높은 비용, 시간 소모, 코드 변경시 TC 수정 필요	숨겨진 결합 발견 어려움, 낮은 TC 커버리지

화이트박스, 블랙박스 테스트 적용방안​

구분	화이트박스	블랙박스
단위테스트	각 함수, 모듈 기능 검증	없음
통합테스트	모듈간 인터페이스 상호작용 검증	여러 모듈 통합 후 기능 검증
시스템테스트	없음	전체 시스템 기능, 성능 검증

테스트시 고려사항​

• 화이트박스와 블랙박스 테스트의 장점을 결합하여 제한적 내부 정보를 활용한 그레이박스 테스트 기법 고려

모듈화​

모듈화의 개념​

• 시스템을 분해하고 추상화하여 SW 성능을 향상시키거나, 시스템의 디버깅, 테스트, 통합 및 수정을 용이하도록 하는 SW 설계 기법

모듈화의 장점​

• 모듈 재사용성, 개발과 유지보수성
• 복잡성 감소
• 오류 파급효과 최소화
• 기능 분리가능, 인터페이스 단순화
• 낮은 결합도, 높은 응집도

응집도와 결합도 개요​

응집도와 결합도의 개념​

• 응집도: 하나의 모듈 내부의 처리요소 간 기능적 연관성을 측정하는 척도
• 결합도: 모듈 간의 관련성을 측정하는 척도

응집도와 결합도의 배경​

• 최근 MSA 적용에 따른 모듈화의 중요성이 증가되었고, MSA의 각 서비스 단위(컴포넌트)는 응집도가 높고 결합도가 낮게 구현되어야함.

응집도와 결합도 종류 및 설명​

응집도의 종류 및 설명​

우논시절통순기

종류	설명	응집도
기능적	모든 요소가 단일 기능 수행	높음
순차적	한 기능의 출력이 다른 기능의 입력으로 사용	▲
통신적	동일한 입출력 데이터로 다른 기능 수행	⎮
절차적	기능 요소가 반드시 특정 순서대로 실행	⎮
일시적	기능 요소가 모두 같은 시간에 실행	⎮
논리적	논리적으로 유사하나 관계가 밀접하지 않음	⎮
우연적	모듈 내 요소가 연관이 없음	낮음

• 가능한 높은 응집도를 추구하여 유지보수 용이성 확보
• 모듈 간 결합도는 최소화하여 각 모듈은 높은 응집도 확보
• Co-incidental -> Logical -> Temporal -> Procedural -> Communicational -> Sequential -> Functional

결합도의 종류 및 설명​

내공외제스자

종류	설명	결합도
자료	모듈 간 파라미터 전달	낮음
스탬프	모듈 간 자료구조 전달	⎮
제어	다른 모듈을 제어하기 위해 플래그 전송	⎮
외부	모듈이 SW외부 환경과 연관	⎮
공통	모듈들이 공통 데이터 참조	▼
내용	다른 모듈의 내부 데이터 변경	높음

• 모듈 상호간 낮은 결합도 추구
• 모듈 간 사이드 이펙트(리플 이펙트) 최소화
• Contents -> Common -> External -> Control -> Stamp -> Data

응집도, 결합도 적용방안​

구분	내용	비고
설계	시스템 모듈화, API통신	유지보수 용이성
개발	모듈간 인터페이스 단순화, 명확한 역할 분담	의존성 주입

모듈성을 높이기 위한 고려사항​

• 코드리뷰를 통해 개발단계에서의 의존성 문제, 인터페이스 불일치 등 저해요인 방지
• MSA 설계시 서비스 단위로 높은 응집도, 낮은 결합도를 갖게 설계

몽키테스트, 회귀테스트 개요​

몽키테스트와 회귀테스트 개념​

몽키테스트와 회귀테스트 배경​

• 애자일 개발 방법론 도입으로 소프트웨어의 잦은 변경으로 인하여 자동화되고 연속적인 테스트의 필요성 증가
• 기존 테스트를 지속하면 살충제 패러독스가 발생하므로, 새로운 버그 발견을 위해 몽키테스트 실행

몽키테스트와 회귀테스트 개념도, 구성요소​

몽키테스트와 회귀테스트의 개념도​

• 테스트케이스나 시나리오 없이 예측할 수 없는 방식으로 무작위 테스트

• 코드, 기능 변경 후 기존 기능이 정상적으로 동작하는지 테스트

몽키테스트와 회귀테스트 구성요소​

구분	몽키테스트	회귀테스트
목적	예기치 못한 버그 발견	기존 기능 동작 확인
방식	무작위 입력, 스트레스, 랜덤 클릭	기존 테스트케이스 재실행
시기	주로 시스템테스트 단계	통합, 시스템, 인수테스트 변경시
완료	오류 미검출	사이드이펙트 수정 완료
장점	예상치 못한 행동 시뮬레이션	SW안정성 유지
단점	재현 어려움, 비일관성	살충제 패러독스

통합테스트 계획시 포함할 주요사항​

• 시스템 목적, 범위
• 대상시스템 구조
• 테스트 자원, 일정
• 시작 및 종료 조건
• 테스트 시나리오
• 테스트 방법 및 절차 교육