http://www.yes24.com/product/goods/106729751

 

데이터 파이프라인 핵심 가이드 - YES24

데이터 파이프라인의 모든 단계를 기초부터 탄탄하게 설명한다!데이터 파이프라인은 데이터 분석의 성공을 위한 기이다. 수많은 다양한 소스에서 데이터를 이동하고 컨텍스트를 제공하기 위해

www.yes24.com

책 목차:

01_데이터 파이프라인 소개: https://inhyeok-blog.tistory.com/m/28

02_최신 데이터 인프라: https://inhyeok-blog.tistory.com/29

03_일반적인 데이터 파이프라인 패턴: https://inhyeok-blog.tistory.com/30

04_데이터 수집: 데이터 추출:

05_데이터 수집: 데이터 로드:

06_데이터 변환하기:

07_파이프라인 오케스트레이션:

08_파이프라인의 데이터 검증:

09_파이프라인 유지 모범 사례:

10_파이프라인 성능 측정 및 모니터링:

 


이 책에서는 일괄 처리/스트리밍 데이터 수집, 직접 구축하는 것/제품을 구매하는 것 과 같이 데이터 파이프라인을 구축할 때 일반적인 의사결정사항에 대한 내용을 다룬다.

 

1. 데이터 파이프라인이란?

 데이터 파이프라인은 다양한 소스에서 새로운 가치를 얻을 수 있는 대상으로 데이터를 옮기고 변환하는 일련의 과정이다. 일반적으로는 데이터 추출, 데이터 가공, 데이터 유효성 검사를 포함한 여러 단계로 구성되며, 때때로 머신러닝 모델이 포함되기도 한다. 이러한 과정은 데이터 크기, 상태, 구조 등의 환경에 따라서 달라진다.

Data pipeline의 일반적인 구조

2. 누가 파이프라인을 구축할까?

 데이터 엔지니어이다. 데이터 엔지니어는 요구사항을 파악하고 확장 가능한 프로덕션 상태로 전환하는데 도움을 준다. 또한 데이터 유효성과 적시성을 보장하는 것을 중시한다. 이러한 역할을 수행하기 위해서 데이터 엔지니어들은 아래와같은 공통적인 기술을 가지고 있다.

 - SQL과 데이터 웨어하우징 기초

 - 파이썬 그리고/또는 자바

 - 분산 컴퓨팅

 - 기본 시스템 관리(Cloud, Linux, Loging 등)

 - 목표 지향적 사고방식

 

3. 왜 데이터 파이프라인을 구축할까?

 경영진은 깨끗한 차트와 대시보드를, 마케팅은 소셜 미디어에서 깔끔하게 포장된 통찰력을, 고객 지원부서는 예측 수요 모델의 산출물을 기반으로 콜 센터 직원을 최적화 하기도 한다. 이런 결과물들은 데이터 파이프라인을 거쳐서 보여지는 것이며, 이를 위해서 데이터 파이프라인에서는 원본데이터 정리/정형화/정규화/결합/집계/마스킹/정제 등의 작업이 일어난다. 

 

4. 어떻게 데이터 파이프라인을 구축할까?

 일반적으로 Python/Java(요즘은 Go가 치고올라오고있다) Sql이 사용된다.

관계 데이터 모델의 개념

용어테이블 vs 릴레이션

릴레이션과 테이블의 차이는 추상적 개념과 이를 나타내는 구체적 표현의 차이인데 릴레이션은 추상적 개념(abstract concept)이고 테이블은 이 릴레이션을 기술하는 하나의 구체적 표현(concrete representation)인 것이다. 사실상 하나의 릴레이션은 여러 가지 형태의 테이블로 표현될 수 있는데 이와 같이 하나의 개념을 설명하는 표현 방법, 즉 구현 방법은 항상 여러 가지가 있을 수 있다. 테이블은 모든 애트리뷰트 값이 동일한 튜플을 하나 이상 가질 수 있다. 일반적으로 집합은 두 개의 동일한 원소를 허용하지 않기 때문에 테이블은 튜플 들의 집합이 아니고 튜플 들의 다중 집합이다. 즉 정리하면 릴레이션은 추상적 개념의 표현이며, 테이블은 이 릴레이션의 구체적인 표현이라 볼 수 있다.

  1. 관계 데이터 모델의 기본 개념
    • 속성(애트리뷰트, attribute, 열)
      각 속성은 서로 다른 이름을 이용해 구분한다.
    • 투플(tuple, 행)
      고객 한명에 대한 실제 속성 값 6개를 모아둔 것으로, 고객 개체의 인스턴스다.
    • 도메인
      속성 하나가 가질 수 있는 모든 값의 집합으로, 원자 값만 속성 값으로 사용할 수 있다. (ex. LANK의 도메인은 vip, gold, silver, bronze/ AGE의 도메인은 INT, NAME의 도메인은 CHAR(20))
    • 널 값
    • 차수(degree)
      하나의 릴레이션에서 속성의 전체 개수를 릴레이션의 차수라고 한다.(ex. Member 릴레이션은 차수가 6이다.)
    • 카디널리티
      투플의 전체 개수, (행의 갯수 == 데이터의 갯수)
  2. 릴레이션과 데이터베이스의 구성
    *고객 릴레이션 Member(ID, NAME, AGE, LANK, JOB, POINT)를 생각한다
    • 릴레이션 스키마(=릴레이션 내포, relation intension)
      릴레이션의 이름과 릴레이션에 포함된 모든 속성의 이름으로 정의하는 릴레이션의 논리적 구조( ex. MEMBER(ID, NAME, AGE, LANK, JOB, POINT) )
    • 릴레이션 인스턴스(=릴레이션 외연, relation extension)
      어느 한 시점에 릴레이션에 존재하는 투플의 집합
    • 데이터베이스 스키마와 데이터베이스 인스턴스
      일반적으로 DB는 릴레이션 여러 개로 구성된다. 즉, 데이터베이스 스키마는 릴레이션의 스키마를 모아둔 것이다.
  3. 릴레이션의 특성
    1. 투플의 유일성 : 하나의 릴레이션에는 동일한 투플이 존재할 수 없다.
      각 투플의 모든 원소를 비교해서 투플의 동일성을 검사하는 것은 비용이 많이 든다. 따라서 키(Key)를 선정해서 유일성을 보장한다.
    2. 투플의 무순서 : 하나의 릴레이션에서 투플 사이의 순서는 무의미하다.
      DB는 위치가 아닌 내용으로 검색되므로, 투플의 순서는 중요하지 않다.
    3. 속성의 무순서 : 하나의 릴레이션에서 속성 사이의 순서는 무의미하다.
      속성 값 역시 위치가 아닌 이름으로 접근하므로, 하나의 릴레이션에는 이름이 같은 속성이 존재할 수 없고, 이름도 속성의 의미가 명확히 드러나는 것으로 사용하는 것이 좋다.
    4. 속성의 원자성 : 속성 값으로 원자 값만 사용할 수 있다.
      모든 속성값은 다중 값을 가질 수 없다(ex. Member.JOB = (회사원, 학생) 은 불가능하다.)
  4. 키의 종류
    • 슈퍼키 : 유일성의 특성을 만족하는 속성 또는 속성들의 집합( ex. ID or (ID, NAME) or (NAME, ADDRESS) )
    • 후보키 : 유일성과 최소성을 만족하는 속성 또는 속성들의 집합( ex. ID or (NAME, ADDRESS) <- (ID, NAME)은 NAME이 없어도 되므로 최소성을 위반한다. )
    • 기본키 : 후보키들 중에서 기본적으로 사용할 키(필수 선택)
      • 널 값을 가질 수 있는 속성이 포함된 후보키는 기본키로 부적합하다
      • 값이 자주 변경될 수 있는 속성이 포함된 후비키는 기본키로 부적합하다
      • 단순한 후보키를 기본키로 선택한다
    • 대체키 : 기본키로 선택되지 못한 후보키들
    • 외래키 : 다른 릴레이션의 기본키를 그대로 참조하는 속성의 집합
  5. Member(ID, NAME, AGE, LANK, JOB, POINT, ADDRESS)를 고려하자

고객(고객아이디, 고객이름, 나이, 등급, 직업, 적립금), 주문(주문번호, 주문고객, 주문제품, 수량, 단가, 주문일자) 두개의 릴레이션에서 주문고객이 외래키 이다. 이때 외래키를 가진 릴레이션(주문 릴레이션)을 '참조하는 릴레이션'이라 하고, 기본키를 가진 릴레이션(고객 릴레이션)을 '참조되는 릴레이션'이라 한다.외래키 도메인과 기본키 도메인은 동일해야한다.외래키를 포함해서 기본키를 구성할 수도 있다.

외래키가 자기 자신을(본인 릴레이션)을 참조할 수도 있다.  
외래키는 NULL값을 가질 수 있다.  
외래키는 유일성이 보장되지 않는다.

관계 데이터 모델의 제약

무결성 제약조건(integrity constraint): 데이터에 결함이 없는 상태, 즉 데이터가 정확하고 유효하게 유지된 상태(사용자의 잘못된 요구에 의해 데이터가 부정확해지지 않도록 보호)

  1. 개체 무결성 제약조건: 기본키를 구성하는 모든 속성은 널 값을 가질 수 없다.
  2. 참조 무결성 제약조건: 외래키는 참조할 수 없는 값을 가질 수 없다.

'DB' 카테고리의 다른 글

데이터 모델링  (0) 2022.04.10
데이터베이스 시스템  (0) 2022.04.09
데이터베이스 관리 시스템  (0) 2022.04.09
데이터베이스 기본개념  (0) 2022.04.09

데이터 모델링과 데이터 모델의 개념

데이터 모델링(data modeling): 현실세계에 존재하는 데이터를 컴퓨터 세계의 데이터베이스로 옮기는 변환과정
추상화(abstraction): 현실세계의 특징을 잘 묘사하는 데이터를 뽑아내는 것

개념적 모델링(conceptual modeling): 묘사하고자 하는 대상에 대한 중요 데이터를 추출하여 개념 세계로 옮기는 작업
논리적 모델링(logical modeling): 개념 세계의 데이터를 데이터베이스에 저장할 구조를 결정하고 이 구조로 표현하는 작업
개념적 모델링 + 논리적 모델링 = 데이터 모델링

데이터 모델(data model): 데이터 구조+연산+제약조건

개체ㅡ관계 모델

개체-관계 모델 : 개체(entity)와 개체 간의 관계를 이용해 현실 세계를 개념적 구조로 표현하는 방법
개체-관계 다이어그램 : 현실 세계를 개체-관계모델을 이용해 개념적으로 모델링 하여 그림으로 표현한 것

  1. 개체
    개체(entity): 현실 세계에서 조직을 운영하는데 꼭 필요한 사람이나 사물같이 구별되는 모든 것

    개념적으로만 존재하는 사건이나 개념도 개체가 될 수 있다.
    개체 타입(entity type): 개체를 고유한 이름과 속성들로 정의한 것
    개체 인스턴스(entity instance), 개체 어커런스(entity occurrence): 속성이 실제 값을 가지므로서 실체화 된 개체
    개체 집합(entity set): 특정 개체 타입에 대한 개체 인스턴스들을 모아놓은 것

  2. 속성
    • 단일 값 속성과 다중 값 속성
      단일 값 속성: 인스턴스당 하나의 값만 있는 것(ex. 고객 이름, 고객 적립금)
      다중 값 속성: 인스턴스당 여러개의 값을 가지는 것(ex. 고객 전화번호, 책 저자)
    • 단순 속성과 복합 속성
      단순 속성: 더는 분해할 수 없는 속성(ex. 고객 아이디, 책 이름)
      복합 속성: 의미를 분해할 수 있어 값이 여러개의 의미를 포함하는 것(ex. 주소, 생년월일)
    • 유도 속성
      저장 속성: 값이 실제로 저장되어 있는 속성(ex. 가격, 할인율)
      유도 속성: 값이 별도로 저장되는 것이 아니라 기존의 다른 속성 값에 유도되어 결정되는 속성( ex. 판매가격 = (가격*(1-할인율)) )
    • 널 속성
      널 값: 아직 결정되지 않았거나 모르는 값, 존재하지 않는 값
      널 속성: 널 값이 허용되는 속성
    • 키속성
      키 속성: 개체 집합에 존재하는 각 개체 인스턴스들을 식별하는 데 사용

      키를 둘 이상의 속성들로 구성하기도 함

  3. 관계

관계 타입(relationship type): 개체와 개체 사이에 정의된 구매 관계(관계 타입도 속성을 가질 수 있다.) (ex. 고객(개체)과 책(개체) 사이에 구매(관계 타입) 정의, 구매의 속성으로 구매일자(속성), 결제방식(속성)을 가진다)
관계 인스턴스: 관계타입이 실제 값을 가지므로서 실체화 된 관계
- 관계의 유형
관계 참여하는 개체 타입의 수에 따른 분류: 이항 관계(개체 타입 2개가 맺는 관계), 삼항 관계(개체 타입 3개가 맺는 관계), 순환 관계(개체 타입 1개가 자기 자신과 맺는 관계)
매핑 원소의 수, 즉 매핑 카디널리티(mapping cardinality) 기준으로 분류 : 일대일, 일대다, 다대다
- 일대일 관계
- 일대다 관계
- 다대다 관계
- 관계의 참여 특성
A와 B의 관계를 생각한다
A의 모든 개체 인스턴스가 관계에 반드시 참여해야 하는 상황 : 'A가 관계에 필수적(or 전체) 참여한다'
A의 개체 인스턴스 중 일부만 관계에 참여해도 되는 상황: 'A가 관계에 선택적(or 부분) 참여한다'
- 관계의 종속성
A와 B의 관계를 생각한다
개체 B가 독자적으로는 존재할 수 없고, 다른 개체 A의 존재 여부에 의존적인 상황: '개체 B가 개체 A에 종속되어 있다' -> A가 존재해야 개체 B가 존재할 수 있고, A가 삭제되면 B도 삭제한다(생명주기가 A에 종속적이다) 이때 A를 강한 개체, B를 약한 개체fk gksek.
4. E-R 다이어그램

논리적 데이터 모델

  1. 논리적 데이터 모델의 개념과 특성
    앞서 설명한 개념적 데이터모델(개체-관계 모델)은 사람들의 머리속에 그려지는 개념적 모델임
    하지만, 이를 논리적 데이터 모델링을 하기 위해서 DBMS의 종류가 중요함
  2. 계층 데이터 모델
  3. 네트워크 데이터 모델

'DB' 카테고리의 다른 글

관계 데이터 모델  (0) 2022.04.10
데이터베이스 시스템  (0) 2022.04.09
데이터베이스 관리 시스템  (0) 2022.04.09
데이터베이스 기본개념  (0) 2022.04.09

데이터베이스 시스템의 정의

데이터베이스 시스템(DBS: DataBase System) : 데이터베이스에 데이터를 저장하고, 저장된 데이터를 관리하여 조직에 필요한 정보를 생성해주는 시스템

데이터베이스 VS 데이터베이스 관리 시스템 VS 데이터베이스 시스템

  • 데이터베이스 : 데이터를 저장해두는곳
  • 데이터베이스 관리 시스템 : 데이터베이스에 저장된 데이터가 일관되고 무결한 상태로 유지되도록 관리하는 시스템
  • 데이터베이스 시스템 : 데이터베이스와 데이터베이스 관리 시스템을 이용해 조직에 필요한 정보를 제공해주는 전체 시스템

데이터베이스 시스템은 데이터베이스, 데이터베이스 관리 시스템, 데이터베이스 사용자, 데이터언어로 이루어져있다.
아래에서 이 4가지 요소를 하나씩 알아보자

데이터베이스의 구조

  1. 스키마
    스키마(schema) : 데이터베이스에 저장되는 데이터 구조와 제약조건을 정의한 것(한번 정의되면 잘 바뀌지 않음)
    인스턴스(instance) : 정의된 스키마에 따라 데이터베이스에 실제로 저장된 값(자주 변경됨)
  2. 3단계 데이터베이스 구조
  • 3단계 데이터베이스 구조의 개념
  • 외부 단계(개별 사용자 관점)
    개별 사용자가 필요한 데이터들만을 바라보는 형태.로그인 담당자는 아이디, 비밀번호, 이름, 나이, 성별, 가입날자만 봄
    주문 담당자는 물품명, 회원아이디, 주문날자, 가격, 도착날자만 봄(여러 테이블을 조인해서)
    외부스키마 : 각 사용자가 생각하는 데이터베이스의 모습을 표현한 논리적인 구조로, 사용자마다 다르다.
  • 개념 단계(조직 전체 관점)
    데이터베이스를 조직 전체의 관점에서 이해하고 표현한다.개념 스키마는 조직 전체의 관점에서 생각하는 데이터베이스의 모습이며, 모든 개별 사용자가 생각하는 데이터베이스의 모습을 하나로 합친 형태다.
    개념스키마: 모든 사용자에게 필요한 데이터를 통합하여 전체 데이터베이스의 논리적 구조를 정의한다.(일반적으로 스키마라고 하면 개념스키마를 의미)
  • 내부 단계(물리적인 저장 장치의 관점)
    저장장치의 관점에서 이해하고 표현한다.
    내부스키마: 전체 데이터베이스가 저장 장치에 실제로 저장되는 방법을 정의한다.
  1. 데이터 독립성
    데이터베이스 구조의 각 단계는 하위단계에 맵핑(사상)된다. 따라서 하위 스키마를 변경하더라도 상위 스키마가 영향을 받지 않게 된다. 이는 곧 데이터 독립성으로 이어진다.
  • 논리적 데이터 독립성
    개념 스키마가 변경되더라도 외부 스키마가 영향을 받지 않는 것(외부/개념 사상 정보만 적절히 수정해주면 된다.)
  • 물리적 데이터 독립성
    내부 스키마가 변경되더라도 개념 스키마가 영향을 받지 않는 것(개념/내부 사상 정보만 적절히 수정해주면 된다.)
  1. 데이터 사전
    데이터베이스를 사용하려면 데이터 이외에 부가정보(스키마/사상정보 등)도 저장해야한다. 이러한 부가정보를 저장하는 곳이 데이터 사전/시스템 카탈로그라고 한다.

데이터베이스 사용자

  1. 데이터베이스 관리자
    데이터베이스 시스템을 운영-관리 한다. 데이터베이스 설계, 구축, 제어주요 업무
    • 데이터베이스 구성 요소 선정
    • 데이터베이스 스키마 정의
    • 물리적 저장 구조와 접근 방법 결정
    • 무결성 유지를 위한 제약조건 정의
    • 보안 및 접근 권한 정책 결정
    • 백업 및 회복 기법 정의
    • 시스템 데이터베이스 관리
    • 데이터베이스 재구성
  2. 최종사용자
    데이터를 조작(CRUD)하기 위해 데이터베이스에 접근하는 사람들
    • 캐주얼 사용자 : DB에 대한 이론적 지식이 있으며, 데이터 조작어를 이용함
    • 초보 사용자 : DB초보수준으로, GUI를 활용
  3. 응용프로그래머
    응용프로그램을 작성할 때 데이터 조작어를 삽입하는 사용자.

데이터 언어

  1. 데이터 정의어(DDL) : 스키마를 정의하거나, 수정 또는 삭제하기 위해서 사용한다.
  2. 데이터 조작어(DML) : 데이터의 삽입-삭제-수정-검색 등의 처리를 요구하기 위해서 사용한다.
    • 절차적 데이터 조작어 : 사용자가 어떤 데이터를 원하고 해당 데이터를 얻으려면 어떻게 처리해야 하는지를 구체적으로 설명
    • 비절차적 데이터 조작어 : 어떤 데이터를 원하는지만 설명 즉, 해당 데이터를 얻으려면 어떻게 처리해야 하는지는 데이터베이스 관리 시스템에 맡김
  3. 데이터 제어어(DCL) : 내부적으로 필요한 규칙이나 기법을 정의하기 위해서 사용한다.
    데이터 제어어를 이용해 규칙이나 기법을 정의하는 이유는 다음과 같은 특성을 보장하기 위함
    • 무결성
    • 보안
    • 회복
    • 동시성

데이터베이스 관리 시스템의 구성

  1. 질의 처리기 : 사용자의 데이터 처리 요구를 해석하여 처리하는 역할
    • DDL 컴파일러 : 데이터 정의어로 작성된 스키마의 정의를 해석한다. 그리고 저장 데이터 관리자를 통해 DB구축, 스키마를 데이터 사전에 저장함.
    • DML 프리 컴파일러 : 응용 프로그램에 삽입된 데이터 조작어를 추출하여 DML 컴파일러에 전달
    • DML 컴파일러 : 데이터 조작어로 작성된 데이터의 처리 요구를 분석하여 런타임 데이터베이스처리기가 이애할 수 있도록 해석한다.
    • 런타임 데이터베이스 처리기 : 저장 데이터 관리자를 통해 DB에 접근하여 DML 컴파일러로 부터 전달받은 데이터 처리 요구를 실행한다.
    • 트랜잭션 관리자 : DB에 접근하는 사용자 권한이 유효하고, 제약조건 위반여부를 확인하며, 회복이나 병행 수행과 관련된 작업도 수행한다.
  2. 저장 데이터 관리자
    내부단계(물리적 저장위치)에 접근하는 역할

'DB' 카테고리의 다른 글

관계 데이터 모델  (0) 2022.04.10
데이터 모델링  (0) 2022.04.10
데이터베이스 관리 시스템  (0) 2022.04.09
데이터베이스 기본개념  (0) 2022.04.09

데이터베이스 관리 시스템의 등장 배경

파일시스템 : 데이터를 파일로 관리할 수 있도록 파일을 생성-삭제-수정-검색하는 기능을 제공하며, 운영체제와 함께 설치된다.
파일시스템의 단점

  • 같은 내용의 데이터가 여러 파일에 중복 저장된다.응용 프로그램별로 파일을 유지하므로, 같은 데이터가 여러 파일에 저장 -> 데이터 일관성/무결성 유지 힘듬
  • 응용 프로그램이 데이터 파일에 종속적이다.파일의 데이터를 구성하는 방법이나 물리적인 저장 구조에 맞게 작성되어야 한다. 즉, 구조가 변경되면 응용프로그램도 변경해야한다.
  • 데이터 파일에 대한 동시 공유, 보안, 회복 기능이 부족하다.
  • 응용 프로그램을 개발하기 쉽지 않다.데이터 관리를 응용 프로그램이 담당해야 하기 때문에 응용 프로그램 개발이 힘들다.

데이터베이스 관리 시스템의 정의

데이터베이스 관리 시스템(DBMS: DataBase Management System): 파일 시스템의 데이터 중복과 데이터 종속 문제를 해결하기 위해 제시된 소프트웨어로, 조직에 필요한 데이터를 데이터베이스에 통합하여 저장하고 이에 대한 관리를 집중적으로 담당한다.(CRUD, 공유 등의 기능 제공)

데이터베이스 관리 시스템은 중복성, 종속성, 동시 공유, 보안, 회복, 데이터 독립성 문제를 모두 해결해준다.

데이터베이스의 주요기능

  • 정의기능: 데이터베이스 구조를 정의하거나 수정할 수 있다.
  • 조작기능: 데이터를 삽입-삭제-수정-검색하는 연산을 할 수 있다.
  • 제어기능: 데이터를 항상 정확하고 안전하기 유지할 수 있다.

데이터베이스 관리 시스템의 장-단점

1. 데이터베이스 관리 시스템의 장점
  • 데이터 중복을 통제할 수 있다.
  • 데이터 독립성이 확보된다. : 종속성문제 해결
  • 데이터를 동시 공유할 수 있다. : 동시접근
  • 데이터 보안이 향상된다. : 접근제어
  • 데이터 무결성을 유지할 수 있다. : 데이터에대한 연산시 유효성 검사를 하므로서 무결성 유지
  • 표준화할 수 있다. : 데이터에 대한 모든 접근이 DBMS를 통해 이루어지기에, 접근 방식/데이터 형식/구조 표준화 가능
  • 장애 발생 시 회복이 가능하다. : 회복기능
  • 응용 프로그램 개발 비용이 줄어든다. : 데이터관리는 DBMS이 담당 + 데이터 독립성 유지(유지보수 쉬움)
2. 데이터베이스 관리 시스템의 단점
  • 비용이 많이 든다.
  • 백업과 회복 방법이 복잡하다.
  • 중앙 집중 관리로 인한 취약점이 존재한다. : DB/DBMS에 장애 발생하면 전체 마비

데이터베이스 관리 시스템의 발전 과정

1. 1세대 데이터베이스 관리 시스템 : 네트워크-계층 DBMS
  • 네트워크 DBMS
    노드와 간선을 이용한 그래프 형태로 구성하는 네트워크 데이터 모델 -> 구조가 복잡, 변경 힘듬
  • 계층 DBMS
    데이터베이스를 트리 형태로 구성하는 계층 데이터 모델 -> 네트워크 DBMS보다 단순 but 트리로만 데이터 표현은 어렵고, 구조 변경 여전히 어렵다.
2. 2세대 데이터베이스 관리 시스템 : 관계 DBMS

테이블 형태로 데이터를 구성 -> 단순/이해하기 쉬운 구조

3. 3세대 데이터베이스 관리 시스템 : 객체지향-객체관계 DBMS
  • 객체지향 DBMS
    객체라는 개념을 이용해 데이터 베이스를 구성 -> 사용자 정의 Type사용, 비정형 데이터 다루기 등 기존에 없던 요구사항을 해결
  • 객체관계 DBMS
    객체지향 DBMS + 관계 DBMS (장점만)
4. 4세대 데이터베이스 관리 시스템 : NoSQL-NewSQL DBMS
  • NoSQL
    데이터 구조를 미리 정해두지 않음 -> 안정성과 일관성유지를 위한 복잡한 기능 포기, 확장성 증가, 분산처리 특화
  • NewSQL
    안정성과 일관성을 유지하면서도 SQL을 이용해 다양하고 복잡한 데이터 처리를 편하게 요청할 수 있음, 관계 DBMS + NoSQL (장점만)

'DB' 카테고리의 다른 글

관계 데이터 모델  (0) 2022.04.10
데이터 모델링  (0) 2022.04.10
데이터베이스 시스템  (0) 2022.04.09
데이터베이스 기본개념  (0) 2022.04.09

데이터베이스의 필요성

  1. 데이터와 정보

    데이터(data) : 현실 세계에서 단순히 관찰하거나 측정하여 수집한 사실이나 값으로, 자료라고도 한다.

    정보(information) : 데이터를 의사 결정에 유용하게 활용할 수 있도록 처리하여 체계적으로 조직한 결과물

    정보처리(information processing) : 데이터에서 정보를 추출하는 과정 또는 방법(데이터를 상황에 맞게 분석하거나 해석하여 데이터간의 의미관계를 파악하는 것)

  2. 정보 시스템과 데이터베이스

    정보시스템(information system) : 조직 운영에 필요한 데이터를 수집하여 저장해두었다가 의사 결정이 필요할 때 처리하여 유용한 정보를 만들어주는 수단

    • 데이터베이스 : 정보 시스템 안에서 데이터를 저장하고 있다가 필요할 때 제공하는 역할

데이터베이스의 정의와 특징

  1. 데이터베이스의 정의

    데이터베이스: 특정 조직의 여러 사용자가 공유하여 사용할 수 있도록 통합해서 저장운영 데이터의 집합

    • 공유 데이터: 여러 사용자가 함계 소유하고 이용할 수 있어야한다.

    • 통합 데이터: 데이터의 중복을 최소화하고 통제가 가능한 중복만 허용하는 데이터이다.

    • 저장 데이터: 컴퓨터가 접근할 수 있는 매체에 데이터베이스를 저장해야한다.

    • 운영 데이터: 지속적으로 유지해야하는 데이터이다.

  2. 데이터베이스의 특징

    • 실시간 접근이 가능하다: 사용자의 데이터 요구에 실시간으로 응답할 수 있어야 한다.

    • 계속 변화 한다: 데이터베이스는 동적인 특징이 있어 데이터를 계속 삽입, 삭제, 수정하여 현재의 정확한 데이터를 유지해야한다.

    • 동시 공유가 가능하다: 여러 사용자가 동시에 이용할 수 있다.

    • 내용으로 참조가 가능하다: 데이터베이스는 저장된 주소나 위치가 아닌 데이터의 내용, 즉 값으로 참조할 수 있다.

데이터 과학 시대의 데이터

  1. 형태에 따른 데이터 분류

    • 정형 데이터: 구조화된 데이터, 즉 미리 정해진 구조에 따라 저장된 데이터이다. (ex. 엑셀, RDB 등)

    • 반정형 데이터: 구조에 따라 저장된 데이터이지만 정형데이터와 달리 데이터 내용 안에 구조에 대한 설명이 존재한다. 따라서 데이터 내용에 대한 설명, 즉 구조를 파악하는 파싱과정이 필요하고, 보통 파일 형태로 저장된다.(ex. HTML, XML, JSON 등)

    • 비정형 데이터: 정해진 구조가 없이 저장된 데이터다.(ex. SNS텍스트, 이미지, 음성, 영상, 워드 등)

  2. 특성에 따른 데이터 분류

    • 범주형 데이터: 종류를 나타내는 값을 가진 데이터(남자/여자, 1학년/2학년/3학년 등) + 연산이 의미가 없다.

      -> 명목형 데이터: 서열이 없는 값을 가지는 데이터(성별)

      -> 순서형 데이터: 서열이 있는 값을 가진 데이터(학년)

    • 수치형 데이터(양적 데이터): 양적 측면에서 크기 비교와 산술적인 연산이 가능한 숫자 값을 가진 데이터

      -> 이산형 데이터: 단절된 숫자 값을 가지는 데이터

      -> 연속형 데이터: 연속적으로 이어진 숫자 값을 가지는 데이터

'DB' 카테고리의 다른 글

관계 데이터 모델  (0) 2022.04.10
데이터 모델링  (0) 2022.04.10
데이터베이스 시스템  (0) 2022.04.09
데이터베이스 관리 시스템  (0) 2022.04.09

문제 링크: https://www.acmicpc.net/problem/1026

 

1026번: 보물

첫째 줄에 N이 주어진다. 둘째 줄에는 A에 있는 N개의 수가 순서대로 주어지고, 셋째 줄에는 B에 있는 수가 순서대로 주어진다. N은 50보다 작거나 같은 자연수이고, A와 B의 각 원소는 100보다 작거

www.acmicpc.net

 

이 문제를 풀면서 멘탈이 많이 갈려나갔다... 처음부터 방향을 잘못잡고 쉬운문제를 세상에서 가장 어렵게 풀려고 했던 것이다.

내가 이 문제를 풀면서 처음 한 생각은 바로 순차탐색-가지치기 이다. 세상에나...
사실 특정 알고리즘을 코드로 구현하는 것조차 익숙하지 않은 나에게 순차탐색과 가지치기를 구현하는 것은 쉬운일이 아니었고, 2시간을 갈아넣어서 풀었더니 시간초과라고 한다. 우선 나의 사고 과정을 열거해보겠다.

  1. B의 순서를 고정해두고 들어갈 수 있는 모든 A를 선택하는 형태를 보니 이거 그래프모양이 나오네?
  2. 그래프를 그려서 순차탐색을 해보려고 했지만 너무 오래걸릴 것 같아서 중간에 가지치기를 해봐야겠다.
  3. 가지를 어떤 기준으로 칠까? 아래로 갈수록 결과값의 예측이 가능하네? 그럼 각 노드에서 나올 수 있는 최소값을 기준으로 가지를 치자
  4. 최솟값을 구하는 방식으론 뭘할까? A나 B 중에서 최솟값을 모두 곱하고 더하면 이거보단 무조건 큰 결과가 나오게 되어있으니까 이걸로 하자

이런 생각으로 코드를 짰다. 심지어 코드도 개판이다. 이 코드는 더보기에 첨부한다.

더보기
import sys

input = sys.stdin.readline


def initial_sort(A, B):
    mydict = dict(zip(sorted(B), sorted(A, reverse=True)))
    return [mydict[b] for b in B]


def graph_down(A, B, depth, max_depth, last_value, best_value):
    if depth == max_depth-1:
        return B[0] * A[0] + last_value

    min_value = get_expectation(A.copy(), B.copy(), last_value)
    depth_target_b = B[0]
    next_depth_b = B[1:].copy()
    for i in range(len(A)):
        if best_value <= min_value[i]:
            continue
        a_copy = A.copy()
        this_value = last_value + a_copy.pop(i) * depth_target_b
        evaluated_value = graph_down(a_copy, next_depth_b, depth + 1, max_depth, this_value, best_value)
        best_value = min(evaluated_value, best_value)
    return best_value


def get_expectation(A, B, last_value):
    min_value = []
    b_target = B.pop(0)
    for _ in range(len(A)):
        a_target = A.pop(0)
        expected_from_min_b = sum(map(lambda x: x * min(B), A))
        expected_from_min_a = sum(map(lambda x: x * min(A), B))
        temp_ex = max(expected_from_min_a, expected_from_min_b)
        min_value.append(a_target * b_target + last_value + temp_ex)
        A.append(a_target)
    return min_value


depth = int(input())
A = list(map(int, input().strip().split()))
B = list(map(int, input().strip().split()))

A = initial_sort(A, B)
print(graph_down(A, B, 0, depth, 0, float('inf')))

 

그리고 시간초가를 확인하고 구글에 정답을 검색해보는데,,, 세상에나 그냥 가장 큰 숫자와 가장 작은 숫자를 곱해서 더하면 되는거였다. 그 사실을 알고 코드를 짜보니 6줄 나왔다...

import sys

input = sys.stdin.readline
depth = int(input())
A = list(map(int, input().split()))
B = list(map(int, input().split()))
print(sum(map(lambda a: a[0] * a[1], zip(sorted(B), sorted(A, reverse=True)))))

 

지금도 잘 이해할 수 없는 부분이 있다.

 

A의 가장 큰 수와 B의 가장 작은 수가 곱해지고, A의 2번쨰 큰 수와 B의 2번째 작은 수가 곱해지고를 반복했을 때 나오는 결과값이 가장 작다고 확신할 수 있는 근거는 무엇인가?

 

사실 직관적으로는 이해할 수 있다. 나도 어렴풋 이러한 원리를 생각해서 순차탐색을 할 때 A배열의 최초정렬을 이와 같은 방식으로 했으니까. 하지만 이러한 방식에 논리적인 근거가 없다고 생각되어서 완전탐색을 했는데... 아직까지 많이 부족한 것이 느껴진다.

Chapter 1 자라기


당신은 몇 년 차?

소프트웨어 시장에는 경력(연차)가 높은 사람이 고급 인력이라는 인식이 있습니다. 하지만 저자는 이를 부정하며, 오히려 연차를 기준으로 임금을 결정하는 방식이 관료주의적이며, 결과적으로 조직에 손해를 끼치는 방향이라는 점을 주장하려고 합니다.
존 헌터(John Hunter)는 채용시 고려하는 각 항목들과 실제 직무 수행간에 성과의 상관성을 측정하는 연구를 수행했습니다. 그 결과는

항목 상관성
경력 0.18
학력 0.10
필체 0.02
나이 -0.01
관심사 0.10
작업 샘플 테스트 0.54
아이큐 0.51
구조화된 인터뷰 0.51
성실성(성격테스트 기반) 0.41
꼼꼼함(성격테스트 기반) 0.31

으로 사실상 경력은 직무 수행능력과 연관성이 낮다는 결과가 나왔습니다. 물론 1~2년차의 경우에는 경력이 크리티컬한 상관성을 보여줬지만, 이는 단편적인 예시일 뿐입니다.
존 헌터의 연구는 소프트웨어 개발자를 대상으로 한 연구가 아닙니다. 하지만 톰 드마르코(Tom DeMarco), 티모시 리스터(Timothy Lister)의 연구 등에서 소프트웨어 개발의 경우에도 경력과 생산성은 아예 무관하다는 사실을 밝혔습니다. 반면 유의미한 상관성을 보인 항목이 있었는데, 이는 바로 개발자의 경험이 얼마나 폭넓고 다양했는지에 대한 것입니다. 이로서 경력의 양적인 면보다 질적인 면이 중요하다는 사실을 알게됩니다.
앞서 언급한 연구들은 '잘 뽑는법'에 관한 연구라면, '잘 키우는법'에 관한 연구에서는 업무 능력 향상에 투자한 시간 이 직무 성과와 유의미한 상관성을 보입니다. 이러한 꾸준한 공부는 IT분야와 같이 지식이 계속 업데이트 되는 경우라면 더더욱 큰 전문성의 성장을 이끌어냅니다. 회사 입장에서는 이러한 성장을 위한 시스템을 잘 구축하는 것이 회사와 개발자 모두에게 윈윈하는 방식입니다.
개발자가 성장(경력이 아닌 실력)을 위해서 할 일은 의도적인 수련 입니다. 하지만 업무를 하는동안에 의도적인 수련은 쉽지 않습니다. 이를 도와줄 수 있는 방법이 바로 피드백을 짧은 주기로, 교정할 기회가 있게 얻는 것 입니다. 이를 위해서 각 판단과 상황을 관찰한 결과를 기록해두고 후에 피드백하더라도, 판단의 이유를 명백하게 기억할 수 있도록 하는 것이 중요합니다.

여기서 하고싶은 말은 연차만으로 좋은 개발자가 될 수 없다! 좋은 개발자가 되기 위해서는 의도적인 수련을 꾸준히, 열심히 해라! 였습니다. 의도적인 수련을 위한 팁으로 꼼꼼한 기록을 통한 피드백과 교정을 언급했습니다. 이러한 방식으로 절차적 지식을 축적하고, 수정 할 수 있도록 하는 것입니다.


자기계발은 복리로 돌아온다

잡코리아의 설문에 따르면 하루의 1~2시간 이상을 자기계발에 투자하는 직장인이 3/2이상입니다. 이정도는 기본이라는 것이지요. 게다가 지식이나 능력은 복리로 이자가 붙기 때문에 더욱 노력해야합니다. 따라서 더 빨리 자라고 싶다면 이율을 높히는 법, 지속적으로 현명한 투자를 하는법 을 고민해야 합니다.
저자는 더글라스 앵겔바트(Douglas Engelbart)의 작업 구분방식을 인용합니다.

A : 제작, 개발, 생산, 판매 등과 같이 표면적이고 직접적인 성과를 내는 작업

B : A를 가능케 하는 시스템/프로세스를 설계하는것(A를 개선하는 것)

C : 사고방식과 상호 작용 방식을 개선하는 것(B를 개선하는 것)

이러한 구분 방식 중에서 B와 C 작업에 투자하는 비율을 늘리는 것을 복리로 성장하는 방식이라고 합니다. 즉, 어떻게 하면 더하기가 아닌 곱하기를 할 수 있을지, 어떻게 하면 곱하기의 비율을 높일 수 있을지를 고민하는 것입니다.

저자의 복리성장을 위한 방식은 치열한 성장을 위한 전략입니다. 저의 학창시절 공부법과 시간관리에 대해서 열심히 찾아봤던 기억이 떠오르네요. 그러한 노력덕분에 투자한 시간 대비 좋은 성적이 나왔던 것 같습니다. 하지만 절대적인 시간의 차이는 극복하지 못했지만요. 최근 인간공학(인지공학)이라는 과목을 공부하면서 이와 관련된 내용을 배웠습니다. 그런 지식들을 잘 활용해서 정리하고 활용해 나가는 것이 저의 성장에 큰 영향을 미치겠지요. 이에 대해서는 다른 포스팅에 꾸준하게 정리해나가겠습니다.


학습 프레임과 실행 프레임

저자는 실행프레임(주어진 과업을 이루어야할 성과로 여기는 생각)과 학습프레임(주어진 과업을 배울 경험으로 여기는 생각)에 관한 이야기를 합니다. 당연히 학습프레임이 실행프레임보다 큰 성장을 이루어 냅니다. 하지만 현실은 녹록치 않을 수 있습니다. 업무하면서 학습이 중요하다는 생각을 가지는 것은 어렵습니다. 이에대해 저자는 1년차 개발자 2명을 비교함으로서 답변합니다. 1년밖에 되지 않아서 책만보고 선임들에게 도움을 요청하지 않는 주니어가 있는가 하면, 1년밖에 되지 않아서 선임들에게 도움을 요청하고, 때로는 도움을 주는 주니어가 있었습니다. 결국 시각차이입니다.

저는 어릴적 자기개발서를 읽는 것을 좋아했습니다. 하지만 나이가 들어가면서 자기개발서가 뻔해지고, 지루해졌죠. 이제는 뻔한 문제를 새롭게 접근하는 자기개발서를 더 선호합니다. 이번 챕터는 오만한 제 생각을 부숴주는 글이었습니다. '매사에 배우는 자세로 임해라'와 같은 뻔한 말들은 이미 졸업한지 오래라고 생각했습니다. 하지만 머리로만 알고있는 이런 지식을 저는 전혀 실천하지 않고 있었습니다. 당연히 배워야겠죠. 당연히 성장해합니다. 뻔한말로 잘난척할 생각은 그만 버리고 몸으로 움직여야할 때 입니다.


가장 학습하기 힘든 직업이 살아남는다

인공지능의 등장은 우리의 방향을 고민하게 합니다. 언젠가 대체될 지도 모르는 능력을 키우는 것은 의미 없는 행위가 될 수도 있으니까요. 저자는 인공지능 시스템에 비해 인간이 유리한 영역을 '암묵지', '직관'이 작동하는 회색 영역이라고 언급합니다.
저자는 컴퓨터로 대체되기 힘든 변수 중에 5가지의 카테고리를 추립니다.

  • 독창성 : 주어진 주제나 상황에 대해 특이하거나 독창적인 생각을 해내기, 혹은 문제를 해결하는 창의적인 방법들을 만들어내기
  • 사회적 민감성 : 타인의 반응을 알아차리고 그 사람들이 왜 그렇게 반응하는지 이해하기
  • 협상 : 사람들을 화해시키고 서로 간의 차이를 조정하려고 노력하기
  • 설득 : 다른 사람들이 마음이나 행동을 바꾸게 설득하기
  • 타인을 돕고 돌보기: 개인적인 도움, 치료, 감정적 지지, 혹은 동료, 고객, 환자 같은 타인들에 대한 기타의 개인적 도움을 제공하는 것

이러한 기준에서 우리는 컴퓨터로 대체되기 힘든 변수에 해당하는 능력을 키워야 합니다. 이런 업무를 수행하는 개발자를 프로그래머 가 아니라 소프트웨어 개발자 라고 이야기합니다. 소프트웨어 개발자는 소프트웨어를 뭘 만들지를 고민하고 설계하는 부분이 포함되며, 그 과정에서 타인과 상호작용하는 업무가 많습니다. 앞서 이야기한 독창성, 협상, 설득 등에서 차이가 나는 것입니다.

개발공부를 하면서 자주 듣던 이야기가 코드몽키가 되어서는 안된다 는 것이었습니다. 또한 김범준의장님(배달의 민족)은 개발자란 비지니스 벨류를 만들어 내는 사람이다 라고 말했습니다. 앞서 언급한 내용들과 일맥상통하는 이야기입니다. 이 책이 쓰여진 시점에는 없었지만, 지금은 자동으로 프로그래밍을 해주는 서비스까지 나왔습니다. 아직까지는 여러 이슈가 남아있지만 이러한 서비스들이 상용화 되는 것도 조만간일 것입니다. 제가 어떤 방향으로 나아가야할지는 명확합니다. 대체불가능한 개발자가 되자!


달인이 되는 비결

달인이 되는 비결은 꾸준히 반복하되, 실력을 개선하려는 동기 가 있어야하고 구체적인 피드백을 적절한 시기 에 받아야 합니다.


수십 년 동안 전문가가 안 되는 비결

논문<Conditions for intuitive expertise>에 의하면 전문가의 믿을 수 있는 직관이 형성되려면 타당성피드백 이 필요합니다. 즉, 예측할 수 있는 일정한 규칙(타당성)과 즉각적이고 명확한 결과(피드백)이 필요하다는 것입니다. 하지만 소프트웨어 개발의 경우는 타당성도 낮고 피드백도 낮은 편입니다. 따라서 타당성을 높이기 위해 변수를 제한하고 실험을 하면서 규칙성과 인과관계를 찾으려고 노력해야하며, 주변사람들에게 피드백을 적극적으로 구해야합니다.

 


당신이 제자리걸음인 이유

실력을 높히기 위해서는 의도적 수련이 필요하고, 특히 의도적 수련을 질적으로 발전시키 위해서 동기와 피드백이 필요하다고 언급했습니다. 저자는 이에 추가적으로 적절한 난이도가 필요하다고 말합니다. 이는 미하이 칙센트미하이의 몰입이론과 일치하는 부분입니다. 미하이는 작업 난이도와 실력이 비슷한 부분에서 몰입을 경험하고, 최고 수준의 집중력을 보이며, 학습능력과 퍼포먼스가 최대치가 된다고 이야기합니다. 만약 작업 난이도보다 실력이 뛰어나면 지루함을 느낄 것이고, 작업 난이도보다 실력이 저조하면 불안감을 느낄 것입니다. 둘다 바람직한 상태는 아닙니다. 따라서 우리는 지루하거나 불안한 상황일 때 몰입하는 상황으로 우리의 상태를 이동시킬 필요가 있습니다. 지루할 때는 작업 난이도를 높히거나(추가적인 작업 수행하기/요구 수준 높히기, ex 자동화 테스트 만들기/요청을 100개 처리하는 환경 구축 -> 1000개 처리하는 환경 구축) 실력을 낮추는 방법(제약조건 달기, ex 디버거 안쓰기)으로 몰입 상태로 이동하고, 불안할 때는 작업 난이도를 낮추거나(작업 분할하기, ex 테트리스 만들기 -> 화면 가운데 사각형 그리기) 실력을 높혀서(전문가의 도움/도구 활용/비슷한 경험 복기, ex 페어프로그래밍/괜찮은 디버거 사용) 몰입 상태로 이동합니다. 이렇듯 몰입상태를 유지하는 것은 성장과 생산성 향상에 매우 중요한 요소인데 이를 잘 수행하기 위해서는 본인이 어떤 상태인지 아는 메타인지 가 중요합니다. 이를 위해서 계속해서 본인의 상태를 체크하는 활동이 필요합니다.
적절한 난이도 설정은 개인의 성장에도 중요한 요소이지만, 팀장으로서 팀원들에게 적절한 난이도를 설정해 주는 것도 중요합니다.


의도적 수련의 일상적 에시


프로그래밍 언어 배우기의 달인

전문성에 따라서 업무의 성과는 극명하게 나뉩니다. 미군에서 개발한 지뢰탐지기는 탐지율이 일반군인 10%, 전문가 90%로 80%나 차이가 나기도 했죠. 이러한 전문가의 방법을 배우려면 작업분석 이라는 기법을 활용해서 기술을 뽑아내기도 합니다. 그 방법은 전문가에게 구체적인 사건에 대해 말하도록 유도하는 것 입니다. 예컨데 유명한 개발자에게 언어를 습득하는 방법을 뽑아내기 위해 최근 언어 학습 경험을 물어보는 것이죠. 아래에서는 저자가 개발자에게 전문성을 뽑아낸 과정을 서술합니다.
첫째로, 이 전문가는 해당언어(Go)의 튜토리얼을 읽으면서 어떤 것을 만들고싶은지(단어 갯수 세기 프로그램) 고려하면서 튜토리얼을 읽는다고 합니다. 그리고 만들고 싶은 프로그램을 만들 수준이 되면 튜토리얼을 멈추고 해당 프로그램을 구현하고 다시 튜토리얼을 읽습니다.
둘째로, 이 전문가는 표준 라이브러리 소스코드를 읽습니다. 언어를 배운다는 것은 문법과 키워드를 익히는 것이 아니라 코드 스타일을 익히는 것이라고 생각하기 때문이죠. 이러한 관점에서 언어를 배우기위해 가장 효과적인 교보재는 해당 언어의 표준 라이브러리가 작성된 방식입니다. 즉 전문가는 튜토리얼을 공부하는 것 만으로는 그 언어의 숙어와 패턴, 스타일을 배우기 불충분하다는 것을 알고 있는 것이죠.
셋째로, 다른 사람의 코드에 내가 필요한 기능을 추가합니다. 실제로 해당언어로 구현된 오픈소스를 다운받아서 새 기능을 추가했습니다. 이때 전문가는 아주 작은 기능 하나를 추가합니다. 이러한 방식으로 실제 코드의 감(읽고 쓰기)를 익히는 것입니다. 게다가 피드백은 덤이죠.

첫번째 방법은 적극적 읽기로, 무언가를 읽을 때 구체적인 질문이나 목적을 가지고 있는 방법을 말합니다. 죽은 공부를 하지말고 적극적으로 질문을 던지고 목적을 가지고 공부하라는 것이죠.

 


실수는 예방하는 것이 아니라 관리하는 것이다

실수를 대하는 문화는 크게 두가지가 있습니다. '실수 예방', '실수 관리'. 실수 예방은 실수를 저지르지 말라고 요구합니다. 따라서 실수한사람을 비난하고, 처벌하고, 당사자는 실수를 감추게 됩니다. 하지만 실수 관리는 실수가 더 나쁜 결과를 내기전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수를 통해 배우는 분위기입니다. 비용측면에서도 실수관리 문화가 수익성이 높습니다. 그 이유는 실수를 통해 학습해야만 실수를 줄일 수 있기 때문입니다. 개인의 실수를 비난하고 예방하기만 한다면 결국 실수한 경험이 공유되지 못하고, 더욱이 이를통해 무엇인가를 배울 수도 없습니다.

 

나의 실수를 대처하는 방식은 극명하게 실수예방 이었습니다. 실수가 발생하더라도 수습하기 바쁘고, 없었던 일처럼 지나가게 하기위해서 노력헀죠. 우리학교 교수님께서 디자인띵킹에 대해서 강의하실때도 유의미한 실패를 반복하라고 이야기 하곤 하셨습니다. 이런 이야기들이 같은 맥락에서 있는 것 같Chapter 1 자라기습니다. 실패,실수를 적극적으로 활용하고 관리하도록 합시다. 저자의 홈페이지에 있는 실수노트를 작성하는 것도 좋은 방법같습니다.

실수 노트 양식은 다음을 참고로 합니다.
제목 : 이 실수에 기억하기 좋은 이름을 붙입니다.
관련인 : 해당 실수에 관련있는(결과에 영향을 주거나 받거나) 사람들을 적습니다
타임라인 : 가로로 수평선을 그리고 어느 시점에 실수가 발생했고, 언제 최초 감지 되었고, 언제 최초 회복 작업을 시작했는지 표시합니다. 그 외에 중요 한 사건들이 있으면 역시 표시합니다.
실수 시점 분석: 실수 시점에 대한 자세한 설명입니다. 구체적으로 실수가 무엇이었는지. 원래는 뭘 했어야, 혹은 안했어야 했는지를 적고, 왜 그런 실수가 일어났는지 적습니다.
감지(detect) : 무엇을 보거나 듣고 처음 실수를 감지했는지. 그리고 당시에 어떤 (부정적) 미래가 펼쳐지리라 추측했는지.
회복(recover) : 회복을 위해 무엇을 했는지. 당시 다른 옵션은 무엇이 있었는지. 왜 그 옵션을 선택했는지.
결과 : 그 후에 결과적으로 어떻게 되었나.
교훈 : 다음번에 비슷한 실수를 어떻게 더 빨리 감지할 수 있을지, 어떻게 더 빨리 회복할 수 있을지, 혹은 실수 발생 전 시점의 행동 자체를 어떻게 교정하면 좋을지.

작가 홈페이지


뛰어난 선생에 대한 미신

이제껏 학습의 중요성과 조건 등을 살펴봤습니다. 이 글과 다음 글에는 배워도 별로 효과를 보지 못하는 경우를 알아봅니다.
뛰어난 선생은 많이 알고있는 사람이 아닙니다. 본인의 지식이 익숙해지면서 암묵화 되는 경우가 있기 때문이죠. 실례로 의사가 간단한 수술법을 가르칠 때도 성공적으로 수술을 진행하기 위한 지식의 30%만 가르치고 있다는 연구가 존재합니다. 이러한 현상을 극복하기 위한 방법은 학생과 선생이 인지적 작업 분석 같은 방법을 사용해 보는 것입니다. 학생의 경우 자신과 학생에 대한 분석을 잘하는 선생을 고르는 것이 유리한 전략일 것입니다.


나홀로 전문가에 대한 미신

어떤 기술적 실천 법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요 합니다. 예컨데 상사가 내가 하는 일을 보고 반대하면 그를 설득해야 하며, 하다가 모르는 것이 생기면 주변에 물어봐야 하니까요. 세상의 어떤 일도 골방에서 혼자 이루어 낼 수 없습니다.
존 가트맨은 자신의 책 신뢰의 과학에서 신뢰가 깨어져 있는 상태에서는 어떤 행동을 해도 악의적으로 보인다는 연구를 언급합니다. 직장에서도 비슷합니다. 팀장이 선의로 책을 선물해도 팀원들은 '나 보고 이런 거 모르니 공부하라는 얘기야? 지는 뭘한다고..'와 같이 생각할 수 있는 것이죠. 이러한 신뢰를 사회적 자본이라고 합니다. 사회적 자본이 좋은사람은 사회적 기술이 일반적으로 뛰어납니다.
전문가는 도메인지식 뿐만이 아니라 사회적 자본과 기술도 뛰어납니다. 벨 연구소는 뛰어난 연구자의 결정적인 특징은 사회적 자본, 특히 소셜 네트워크의 차이였습니다. 뛰어난 연구자는 같은 부탁을 해도 훨씬 더 짧은 시간에 타인의 도움을 얻었습니다. 개발자의 경우도 다르지 않습니다. 시니어 개발자에게 초보개발자에게 해줄 조언을 적어보라 했을 때, 뛰어난 개발자들의 70%는 동료와의 협력을 언급하는 반면 실력이 그저그런 개발자들은 20%만 동료와의 협력을 언급했습니다.
그럼 사회적 기술을 키우기 위해선 어떤 방법이 있을까요? 기본적으로 일상에서 하는 인사, 대화, 질문 등에 신경쓰면서 이를 기록하고, 복기하고, 다른 인터랙션을 가정해 보는 것 만으로도 도움이 될 수 있습니다.

취직이 다가올 수록 사회적 기술을 등한시 하게 되는 것 같습니다. 지금 급한건 코딩테스트, 개발능력이라고 느껴지기 때문이겠죠. 하지만 저자는 제게 그렇지 않다고 이야기하고 있습니다. '세상의 어떤 일도 골방에서 혼자 이루어 낼 수 없다고'.

 

+ Recent posts