9 posts tagged with "테크웰"

Sql Server Bulk Working#

이번에 단독서버를 만드는 업체를 위해 기존에 데이터를 백업하여 작업하는 사항이 생겼다.

현재 운영중인 Sql Server에서 대량 추가, 수정, 삭제 작업을 요구할 때 어떻게 효율적으로 처리해야 하는지에 대한 방법들을 적용시키고 테스트를 진행해보았다.

일반적으로 몇만개의 데이터를 처리할 경우에는 DML 명령어로 처리하면 초~분 단위로 처리가 가능하다.

하지만, 100만개 이상의 데이터가 있는경우 수십분, 수시간의 시간이 소요될 수 있다.

아이랩의 결재정보와 관련된 테이블의 경우 2억개 이상의 Row 데이터가 입력되어있다.

Bulk Insert, Update#

Insert#

Sql Server Bulk Insert

• 대량 Insert의 경우 가지고 있는 데이터를 Bulk Insert 문을 활용하여 작업한다.
• 대량의 데이터를 가지고 있는 테이블을 다른 테이블로 옮기려면 insert into + select 문을 사용한다면 Bulk Insert 동작을 발생할 수 있도록 한다.

다른 테이블에서 옮길경우 Index의 적절한 활용도 중요하다.

만약 대량의 데이터가 있는 테이블에서 Index가 없는 조건으로 Table Scan이 발생할 경우 select 절의 속도가 굉장히 오래 소요되기 때문에 Data Search 부분에서 오래 소요될 수 있다.

전체 데이터를 다 옮겨야한다면 Order By PK 조건을 추가하여 진행하는것이 좋다.

Update#

Update의 경우 Index 조건을 잘 맞춰주고 몇십만건 이상의 데이터라면 일정부분 잘라서 작업하는게 좋다.

대량 작업으로 인한 과도한 메모리 사용 및 Dead Lock 방지

Bulk Delete#

DELETE 작업의 경우 Insert, Update보다 발생하는 엄청난 양의 트랜잭션 로그가 고려된다.

Sql Server의 경우 백업모드가 3가지가 존재한다.

• SIMPLE
• BULK_LOGGED
• FULL

BULK_LOGGED의 경우 대량 로그변경이 일어날경우, FULL 백업 설정의 경우 모든 수정사항이 트랜잭션 로그가 저장되므로 실제 작업을 할때는 Simple 모드에서 설정 후 작업하는게 좋다.

FULL 백업모드에서 몇천만개의 데이터를 추가, 수정, 삭제하면 오랜 시간이 소요되며 트랜잭션 로그파일의 크기가 순식간에 100GB가 넘게되버리는 마법을 체험할 수 있다.

고려할 사항#

• SIMPLE 복구 모드로 설정
• 전체 백업 만들기
• 데이터 삭제
• 인덱스 다시 작성
• FULL 복구 모드로 다시 설정

데이터를 옮기기 위해#

아이랩의 경우 메인 데이터파일의 용량이 약 500GB, 첨부파일 관련 데이터파일의 용량이 약 1.7TB

1. SIMPLE 복구 모드 설정
2. 전체 백업 만들기(31분 소요)

• 백업자료 생성시작 2021.05.19 22:55
• 백업자료 생성완료 2021.05.19 23:26

3. 새로운 데이터베이스에 백업하기(1시간 6분 소요)

• 백업시작 2021.05.19 23:45
• 백업완료 2021.05.20 00:51

4. 필요한 데이터만 남기고 삭제하기

데이터 삭제#

아이랩의 경우는 기관마다 기관번호로 구분되어있어 조건을 설정하여 Delete문을 작성하기는 쉬웠지만 시간상에 문제가 발생했다.

특정기관의 데이터만 남기고 백업본을 남기기 위해서..

DML 명령어로 여러 테이블에서 수천만개의 데이터를 삭제하는 동작을 실행 시 최소 4시간 이상이 소요되는 문제가 발생

TRUNCATE 활용#

기존 데이터를 임시 테이블로 Bulk Insert하여 옮긴 후 다시 원본 테이블로 Bulk Insert 하는 작업으로 시간을 단축

TRUNCATE의 경우 DDL 단위의 명령어로 테이블에 기본정보는 유지하고 모든 데이터를 지울 수 있는데 0.1초만에 처리가 가능하다.

위에 작업으로 기존 1시간30분 이상의 작업에서 1분으로 단축

기존 DB에서 새로운 DB로 옮기기#

WAFS의 크기#

WAFS DB는 1.7TB이며 테이블은 한개만 사용하지만 용량이 너무 크기때문에 백업 생성 후 옮기기가 너무 부담스러운 문제가 발생

새로운 데이터베이스를 생성하여 같은 테이블을 생성 후 기존 데이터베이스 정보를 옮기는 전략

고려사항#

• 새로운 데이터 베이스 생성 NEW_WAFS
• 기존 데이터베이스에서 특정 데이터를 옮기기

만약 백업을 생성해서 진행했다면 대략 4시간이 소요될 수 있었지만, 해당 작업으로 3분만에 완료되는것을 확인

혹시 모를 상황에 대비해 반드시 데이터는 백업을 해두고 테스트를 진행해자

참고자료#

• MS technet huge date delete

Sql Server Page 구성도#

데이터베이스에서 데이터 파일에 할당되는 디스크공간은 논리적인 페이지로 나뉘면서 연속적인 숫자가 페이지에 매겨진다.

책이 page로 구성되어 있는 것처럼 SQL 서버도 Page로 구성되어 있으며 크기는 8KB 이다.

SQL서버의 가장 기본적인 단위이며, 실제로 SQL서버에 데이터의 접근시에는 페이지 단위로 접근합니다.

페이지는 대부분 Data로 구성되어 있지만 일부 페이지는 인덱스(데이터 위치), 텍스트/이미지, 등등으로도 구성되어 있다.

각 페이지는 96바이트의 헤더로 구성되어 있으며, 헤더는 페이지에 대한 시스템 정보를 저장한다.

Extents#

Sql Server의 Extent는 공간 관리의 기본 단위이며, 하나의 Extent는 연속하는 8페이지이다.

일반적으로 신규 테이블이나 인덱스는 Mixed extent의 페이지를 할당한다. (효율을 위해서)

이후 해당 테이블이나 인덱스가 8페이지로 증가하면 후속 할당을 위해서 uniform extent를 사용하도록 전환된다.

(SQL Server 2016부터 모든 할당의 기본값은 uniform extent를 사용)

PFS 페이지#

PFS(Page Free Spece) 페이지는 Page 할당여부 및 빈 공간의 양을 1바이트로 표시한다.

PFS 페이지는 8088개의 페이지(64MB)의 빈공간을 추적하며, 8088개 페이지 이후에는 새로운 PFS 페이지가 생성된다.

페이지 상태 비어 있음 1 ~ 50% 채워짐 51 ~ 80% 채워짐 81 ~ 95% 채워짐 96 ~ 100% 채워짐

Extent 할당 및 빈 공간 관리#

빈 공간 추적#

PFS(Page Free Space) 페이지는 개별 페이지의 할당 여부 및 각 페이지에 있는 빈 공간의 양과 같은 페이지의 할당 상태를 기록하고. PFS는 각 페이지에 1바이트를 사용하여 페이지의 할당 여부를 기록하고 할당된 경우 페이지의 상태를 비어 있음, 1~50% 채워짐, 51~80% 채워짐, 81~95% 채워짐 또는 96~100% 채워짐으로 기록을 진행한다.

개체에 익스텐트가 할당된 후에는 SQL Server 데이터베이스 엔진에서 PFS 페이지를 사용하여 익스텐트의 할당된 페이지 또는 빈 페이지를 기록합니다. 이 정보는 SQL Server 데이터베이스 엔진에서 새 페이지를 할당해야 할 때 사용된다.

추적되는 각 추가 범위에 대한 새 PFS, GAM 또는 SGAM 페이지가 데이터 파일에 추가된다.

따라서 첫 번째 PFS 페이지 뒤에 8,088페이지의 새 PFS 페이지가 있고, 그다음에는 8,088페이지 간격으로 추가 PFS 페이지가 나온다.

밑에 그림을 페이지1할당 후 PFS 페이지로 페이지가 관리되고, 그 뒤에 GAM 페이지 뒤에 64,000개 익스텐트의 새 GAM 페이지가 있고, 그다음에 나오는 64,000개 익스텐트를 추적한다. (이후 64,000개 익스텐트 간격으로 시퀀스가 계속된다)

Sql Server Index#

인덱스가 없을경우 아래 그림처럼 저장된다.

Clusterd Index#

클러스터 인덱스 구조에서 인덱스 페이지의 루트 노드 및 중간 노드들은 인덱스 행을 포함하게 구성되어 있다.

리프 노드들은 기본 테이블의 데이터 페이지로 구성되어 있으며 기본 테이블 데이터 페이지의 데이터 값들은 인덱스 값을 기준으로 정렬된다.

인덱스 페이지를 통해서 인덱스를 통한 데이터 검색을 할 경우 해당하는 데이터 페이지를 찾아갈 수 있다.

클러스터 인덱스를 생성할경우 아래 그림처럼 생성이 된다.

Non Clusterd Index#

인덱스 페이지의 루트 페이지에는 클러스터와 동일하게 인덱스키와 리프페이지의 페이지 번호로 구성된다.

하지만 클러스터 인덱스와는 다르게 인덱스 페이지의 리프 페이지는 데이터 페이지가 아닌 데이터 페이지의 포인터로

구성된다.(실제로는 페이지 번호 + 행번호(RID)로 구성)

비 클러스터 인덱스에서 조회를 진행한다면

• 첫번째로 인덱스의 루트페이지를 접근해서 찾는 값이 어떤 리프 페이지에 있는지 확인
• 리프 페이지로 이동 후에 페이지의 내부 행들을 검색해서 데이터의 포인터 정보에 접근
• 포인터 정보를 기반으로 데이터 페이지에 접근

검색 과정에서 총 3개의 페이지(루트 페이지 + 리프 페이지 + 데이터 페이지)를 참조하게 됨.

참고자료#

• mssql 내부 동작방식 참고
• microsft-database-index

코드리뷰#

코드리뷰란, 한 명 또는 여러 명의 개발자가 본인이 만들지 않은 코드의 내용을 점검(examining)하고, 피드백을 주는 과정을 말한다.

여기에서 피드백이란 오타, 버그 가능 성, 개발 표준 등에 대한 의견이 될 수도 있고, 좋은 코드에 대한 긍정적인 피드백이 될 수도 있습니다. 코드리뷰의 핵심은 단순히 코딩 스타일을 일관되 게 유지하거나, 예상되는 문제를 일찍 파악하는 데에 그치지 않고 코드에 대한 책임이 그 코드를 만든 사람 혼자에게 있지 않고 우리 모두에게 있다는 문화를 만드는 데에 있다고 할 수 있다.

코드리뷰의 중요성 및 장점#

코드리뷰로 얻을 수 있는 가장 대표적인 장점으로는 ‘버그의 조기 발견’, ‘개발 표준(convention) 준수’, ‘중복 코드를 방지하고 모듈의 재사용성 증대’와 같은 것들 외에도 많은것들이 있다.

본인은 쉽게 발견하지 못하는 실수를 다른 사람은 금방 발견하여 코드의 부작용(side effect)과 오류를 좀 더 일찍 조치할 수 있으며, 정해진 표준 준수를 통해서 많은 사람들의 개발 결과물이 일관된 스타일을 유지할 수 있도록 도와준다. 또한, 동일한 역할을 수행하는 중복 코드를 빨리 발견하고 이미 만들어진 코드를 재사용할 수 있도록 수정할 수 있다.

“코드 컴플릿(Code Complete)”의 저자 스티브 맥코넬(Steve McConnell)은 책에 서 다음과 같은 실험결과를 통해 코드리뷰의 중요성을 강조합니다.

“소프트웨어를 유지보수하는 조직에서 코드 한 줄을 변경한다고 했을 때, 코드리뷰가 도입되기 전에는 그러한 변경의 55% 정도가 문제를 일으켰다. 그러나 리뷰 과정이 도입된 이후에는 그러한 변경의 2% 정도에서만 문제가 발생했다.”

코드 리뷰의 또 다른 장점으로는 다른 사람의 잘 만들어진 코드를 보면서 배울 기회를 얻을 수 있다. 같은 환경에서 개발을 진행하더라도 개인별로 해당 언어나 프레임워크에 대한 이해도와 경험은 크게 차이가 날 수 있다.

예를들어 코드를 작성하는 사람마다 여러 성향이 있을 수 있다.

• 프로그래밍 언어와 프레임워크가 추구하고자 하는 기본 철학을 이해하고 그에 맞는 방식을 유지하려고 노력하는 사람
• 기존에 다른 환경에서 개발하던 방식을 벗어나지 못하고 현재 환경의 장점을 활용하지 못하는 사람
• 언어나 프레임워크가 기본적으로 제공하는 손쉬운 기능들을 잘 숙지하고 적절히 활용하는 사람
• 이미 만들어져 있는 기능을 사용하지 못하고 직접 불필요한 기능을 추가하는 사람
• etc..

이러한 여러 성향 및 개인 간의 격차를 해소하는 가장 좋은 방법이 바로 코드리뷰이며 이를 통해 조금 더 좋은 방법을 제시해주고 이해 수준을 상향 평준화하는 것이 될 수 있다.

즉, 코드리뷰는 단순히 버그를 사전에 발견하거나 문제점을 찾는 목적을 넘어서 전체적인 조직의 역량을 강화하는 중요한 역할을 한다.

그럼에도 코드리뷰의 가장 중요한 점 한 가지를 뽑는다면 ‘책임자를 추궁하지 않는 문화’의 정착이라고 말하고 싶습니다.

Logi-Spot 코드리뷰

코드리뷰시 확인해야할 것#

기능의정상동작여부#

기본적으로 모든 코드는 존재하는 목적을 가지고 있습니다. 다른 조건을 모두 만족하더라도 원하는 대로 동작하지 않는 코드는 잘못된 코드라고 할 수 있습니다. 코드리뷰의 시작과 끝은 언제나 기능이 원하는 대로 정상 동작하는지 확인하는 작업이 필수

버그의 조기 발견#

코드 리뷰로 얻을 수 있는 장점 중 하나는 버그를 조기에 발견하여 불필요한 비용을 절감할 수 있다.

같은 버그라고 해도 해당 버그를 코드리뷰 단계에서 발견하는 것과 테스트 단계에서 발견하는 것, 그리고 배포 이후에 발견하는 것은 순서대로 더 비싼 비용을 지불해야 하며, 코드리뷰를 할 때는 버그가 발생할 소지가 없는지 점검해야 한다.

가독성과 유지보수 편의성#

가독성과 유지보수 편의성은 자칫 잘못하면 주관적인 견해로 옳고 그름을 따지는 비생산적 논쟁으로 변질될 수 있으므로 가급적 기준을 정하고 해당 기준을 기반으로 검토하는 것이 좋다. 예를 들어, 들여쓰기(indent)의 크기나, 코드 한 줄의 최대 길이, 메소드 호출의 깊이(depth)등의 표준을 정해두면 좀 더 객관적인 기준으로 코드리뷰를 수행할 수 있습니다.

아이랩 팀은 한라인 80줄, 들여쓰기 2칸규칙이 적용중이다. (메소드 호출 길이는..음)

개발 표준(CONVENTION)의 준수 여부#

개발 표준을 잘 정리하고 지키려는 활동이 계속되면 많은 사람이 함께 개발하더라도 어느정도 일관된 개발 스타일을 유지할 수 있다.

테스트 코드의 작성 여부#

모든 개발자가 테스트 코드 작성을 당연시하고 습관적으로 수행하면 더 바랄 것이 없지만, 만약 그렇지 않다면 어느 정도 강제성을 통해 습관을 만들어나가는 노력이 필요하다.

이런 상황에 적합한 것이 바로 코드 리뷰시 테스트 코드의 작성 여부를 확인하는 것.

실제로 수많은 개발자가 동시에 개발을 진행하는 오픈소스 프로젝트들 대부분은 Pull Request 의 기본 조건으로 테스트 코드의 제출을 요구합니다.

테스트 코드를 작성하는 문화는 수많은 개발 조직에서 시도하지만 쉽게 정착하기 힘든 개발 문화 중 하나입니다.

재사용 가능한 모듈의 중복 개발#

개발을 진행하다 보면, 자주 사용할 것 같은 기능들을 모듈화하여 재사용할 수 있도록 만드 는 경우가 많다. 하지만 모듈을 공유하고 모두가 기억하도록 하는 것은 생각처럼 쉽지 않은 일이다.

코드리뷰는 같은 기능을 하는 중복된 모듈의 개발을 막고, 코드의 재사용을 높이는 아주 좋은 방법이다.

만약, 누군가가 재활용할 수 있는 기존 코드를 인지하지 못하고 스스로 중복된 코드를 만들었다면, 코드리뷰 과정에서 같은 기능을 하는 코드가 존재한다는 피드백을 받아 수정할 수 있다.

배울만한 점은 없는지#

코드리뷰에 많은 사람이 오해하는 부분 중 하나는, 경력이 많거나 실력이 뛰어난 개발자가 후배 개발자의 코드를 검사한다고 생각하는 것이다.

코드리뷰의 목적은 코드 작성자에 게 피드백을 주는 것도 있지만, 해당 코드를 보면서 ‘아, 이런 식으로 코드를 작성하는 것도 가능하구나?’, ‘아, 이렇게 쉬운 방법이 있었구나?’와 같은 학습효과도 함께 가지고 있다.

그렇기 때문에 코드를 리뷰할 때는 피드백을 주기 위한 시각과 좋은 점을 배우려는 시각, 이 두 가지 시각의 균형을 맞추며 진행하는 것이 좋다.

글로벌 기업의 코드리뷰#

구글#

구글 코드리뷰 연습

구글은 100% 코드 리뷰, 모든 코드를 리뷰한다고 한다.

물론 Tricorder라는 정적 분석(잠재결함 분석) 도구와 Rosie라는 코드 정리 시스템(Large-Scale Cleanups and Code Changes)을 활용해 사용하지 않는 코드는 없애고 리팩토링이 필요한 경우에 효율적으로 리뷰를 한다고 알려져있다.

Microsoft#

개발자 업무는 개발 50%, 리뷰 50%인 Microsoft

Microsoft의 개발자라면 매일 코드 리뷰를 해야 합니다. Microsoft의 전체 직원 수는 14만 명이고, 이중 44%인 6만 명에 이르는 개발자의 75%가 매일 코드 리뷰를 하고 있다고 알려져 있다.

“리뷰는 당연하다”, 네카라쿠배*와 스타트업#

국내 스타트업을 중심으로 자동화된 배포와 테스트는 이제 기본기 중의 기본기가 되었다.

테스트 기반의 코딩인 TDD(Test Driven Development)를 필수로 적용하고, 코드 Merge 전에 코드 리뷰는 필수적인 프로세스가 되었다.

국내 IT 선도기업들은 회사에서 표준을 제공하기보다는 팀 상황에 맞추어 자율적으로 코드 리뷰 방법을 결정해서 자율적으로 적용하고 있지만, 대부분의 회사는 GitHub에서 제공하는 PR(Pull Request)을 활용해서 리뷰 요청과 검토를 완료(Approve)하는 방식으로 코드 리뷰를 진행한다고 한다.

우리팀은..?#

현재 아이랩팀은 현재 GitHub에서 Master Branch만 사용중이다.

그 후 로컬환경에서 코드를 작성 Merge후 바로 커밋후 저장소에 Push를 진행하고있다.

앞으로 Pull Request 템플릿을 활용해 필요한 작업은 반드시 코드리뷰 후 Master 브랜치에 Merge를 진행할 예정이다.

• develop 브랜치 생성(Develop에 푸쉬 시, 반드시 Reviewer 한명이상 지정)
• 각자 브랜치를 생성하여 작업
• develop 브랜치에 머지 진행전 PR(Pull Request)를 통한 코드리뷰
• develop에 모두 merge된 소스를 배포시 master에 병합하여 어플리케이션 버전업

Visual Studio Code#

Visual Studio Code는 Microsoft 에서 개발한 Code Editor

• 기본적으로 Dark Theme (눈은 소중하니까요..)
• 무겁지 않은 프로그램
• 각 언어 및 개발환경에 제공되는 수많은 extension
• 등등..

글을 작성한 본인을 포함하여 많인 개발자들이 애용중인 훌륭한 에디터 👍

Visual Studio Code Shortcut#

가볍고 실행하기 좋은 Visual Studio Code(이하 vsc) 에디터를 좀 더 잘 활용하기위해 단축키를 알아보자.

mac shortcut#

window shortcut#

• Mac Shortcut PDF
• Window Shortcut PDF

단축키를 모아보니 우주비행선을 조종해야할 것 같다.

많이 사용하는 단축키?#

1. Mac ⌘ + D & Window Ctrl + D#

현재 커서가 있는 단어와 동일한 단어를 아래 단축키 입력시마다 한번에 수정 가능하도록 커서를 잡아준다.

Tip

• Mac ⌃ + F 단어 찾기 후 ⌥ + Enter
• Window Ctrl + F 단어 찾기 후 Alt + Enter

위에 단축키 통해 원하는 단어 검색 후 입력을 통해 현재 파일의 해당 단어 모두를 한번에 수정 가능하도록 커서를 잡아준다.

2. Mac ⌥ + Click & Window Alt + Click#

위에 단축키를 누른 상태로 마우스로 클릭하는 곳 커서를 모두 한번에 잡아줘 수정하고싶은 부분들을 한번에 수정할 수 있도록 해준다.

Tip

세로로 한꺼번에 편집하고 싶은 부분만 지정할 때 완전 편함.

3. Mac ⌥ + ↓or↑ & Window Alt + ↓or↑#

현재 커서가 있는 줄을 위로, 아래로 한 줄 보낸다. 보내진 곳에 있던 줄은 이동된 줄의 위치로 이동된다.

4. Mac ⌥ + Shift + ↓or↑ & Window Alt + Shift + ↓or↑#

현재 커서가 있는 줄을 복사하여 위 or 아래로 복사해준다.

5. Mac ⌘ + / & Window Ctrl + /#

현재 사용하는 언어를 VSC에서 알아내 알아서 주석 처리를 해준다. (완전 편함.)

6. Mac ⌥ + Shift + I & Window Alt + Shift + I#

드래그된 모든 줄의 끝에 커서를 모두 생성해준다.

Tip

선택한 라인들의 끝에 뭔가 수정하거나 입력하고 싶을때

7. Mac ⌥ + Shift + Drag & Window Alt + Shift + Drag#

마우스 커서가 드래그하는 곳을 세로줄로 드래그후 한꺼번에 편집 가능

단축키는 잘 쓰면 능률도 올라간다.#

개발자 외에도 많은 사람들이 Ctrl + C, Ctrl + V 복사 붙여넣기를 많이 사용하는 것처럼

VSCode에 내장된 단축키를 잘 활용한다면 좀 더 효율적으로 vsc 코드 에디터를 활용할 수 있다는 기대감을 가지면서..

vsc 단축키 잘 사용하다가 다른 에디터에 vsc 만큼 단축키가 없으면 어떻하지..라는 생각도 든다.

what why 왜 필요한가?#

회사에서 매주 화요일 기술미팅인 테크톡을 온라인으로 진행하는데, 그 내용을 영상으로 캡쳐해서 유튜브에 올리는 작업을 하고 있습니다. 혼자 말하면서 영상을 캡쳐하는 작업이라면 내가 사용하는 맥북의 기본 마이크 또는, 헤드셋이나 이어셋에 붙어 있는 기본 마이크를 사용하면 됩니다. 하지만 온라인 미팅 내용이나 다른 영상을 플레이 하면서 나오는 소리를 다시 내 영상에 포함하려면 몇 가지 생각해야할 문제가 있습니다.

만약 내 PC의 기본 스피커에서 흘러 나오는 소리를 그대로 기본 마이크를 통해 다시 영상에 넣는다면 주변의 잡음이 오디오에 섞이게 됩니다. 아무리 좋은 비디오편집 도구를 사용한다고 해도 오디오에서 주변 잡음을 제거하는 일이 쉽지 않습니다.

제일 좋은 방법은 PC에서 나오는 오디오를 직접 영상 캡쳐프로그램(QuickTime Player)으로 넣어주는 방법입니다. 그때 필요한 장치가 바로 가상오디오 장치입니다.

macOS 11 이전에는 Soundflower 라는 이름의 가상오디오를 사용했었는데, macOS 11에서 Sourdflower 설치에 어려움이 있습니다. 그래서 검색하다 발견한게 BlackHole 입니다.

how 설치#

BlackHole Download에서 이메일과 이름을 입력하고 구독을 누르면 파일을 받을 수 있습니다. 좋은 프로그램을 무료로 사용하기 위해 구독은 기쁜마음으로 할 수 있습니다. 게다가 이 프로그램은 오픈소스이며 GPL-3.0 License 입니다.

파일을 다운받아 실행하면 BlackHole 2ch 라는 이름의 새로운 오디오기기가 추가됩니다. 추가된 오디오 기기를 확인하기 위해 응용프로그램 > 유틸리티 > 오디오 midi 설정를 실행 합니다.

how 스크린 캡쳐#

맥북에서 스크린 캡쳐는 QuickTime Player를 사용합니다. Command + Shift + 5 키를 누르면 바로 아래 이미지 같이 화면캡쳐 도구가 실행됩니다.

옵션에서 마이크를 BlackHole 2ch로 선택 하면 됩니다. 이때 한 가지 잊지말아야 할 내용은 맥북에서 나오는 출력 오디오도 BlackHole 2ch로 설정해야 한다는 사실입니다. 즉 스피커로 나오는 소리의 출력을 BlackHole 2ch로 우회하는 것이죠.

이 상태로 스크린 캡쳐를 실행하면 맥북에서 실행되는 유튜브 영상과 소리가 깨끗하게 잡음없이 캡쳐됩니다.

more 통합 오디오#

그런데, 여기서 또 하나의 문제가 있습니다. 블랙홀로 출력을 하게 되면 영상을 캡쳐하는 동안 스피커나 이어폰으로 소리를 들을수 없다는 겁니다. 이 문제는 영상을 캡쳐할때 내 목소리를 같이 녹화하지 못한다는 문제와도 연결이 됩니다.

이 문제를 해결하기 위해 mac에서 여러 오디오 장치를 통합 할 수 있는 통합 오디오기능을 이용할 수 있습니다.

위에서 실행했던 오디오 midi 설정을 다시 실행하고 아래쪽 + 버튼을 눌러 통합 기기(Aggregate Device) 를 추가하고 원하는 기기를 체크해서 새로운 입출력기기를 만듭니다.

이 기능을 이용하면 Google Meet 등 온라인 화상회의 내용을 캡쳐할 때 유용하게 이용할 수 있습니다.

즉,

• 화상회의 프로그램의 출력장치를 위 화면에서 만든 통합기기로 선택하고
• 캡쳐 프로그램의 입력장치도 통합기기로 설정하면
• 플레이되는 화상최의 영상을 캡쳐하면서
• 화상회의 대화도 녹음되고
• 이어폰으로 대화내용도 듣고
• 내가 마이크로 하는 말도 녹음이 가능하게 됩니다.

close#

맥북에는 비디오, 오디오 관련해서 다양한 장치와 기능이 있는것 같습니다. 좀더 많은 기능을 확인하려면 오디오 MIDI 설정 사용 설명서를 참고하세요.

more 윈도우용#

윈도우용은 아직 준비중인것 같습니다. 알림을 받고 싶다면 구독~
https://existential.audio/blackhole/windows/

svg#

• SVG = Scalable Vector Graphics 확장 가능한 백터 그래픽 입니다.
• xml 형식으로 그래픽을 정의 합니다.
• 텍스트 기반 웹 표준, 별도의 편집기가 없어도 편집 가능
• W3C 권장사양
• 비트맵 이미지와 비교해 이미지 품질 손실없이 렌더링 가능

new study project with D3#

d3js.org

앞으로 테크톡 시간에 제가 시리즈로 진행할 프로젝트에 대해 소개할까 합니다. 제목에도 있듯이 디쓰리 라는 이름을 가진 자바스크립트 라이브러리를 이용한 프로젝트 입니다. 디쓰리는 데이터 비주얼라이제이션을 위한 그래픽 라이브러리 인데요, 데이터 비주얼라이제이션이란 말 그대로 데이터를 보여주는 방법. 즉, 데이터 시각화를 의미합니다.

이 분야에 우리회사는 이미 아주 깊숙히 들어와 있고 관련된 리얼드리드, 리얼피봇, 리얼리포트 등, 제품도 이미 만들었고, 만들고 있습니다.

이런 시각화 라이브러리인 디쓰리 D3 를 이용해서 테크톡 시간에 진행 할 수 있는 간단한 무언가(?)를 만들어 볼 계획입니다.

example#

Times Sunday Review 2013년 기사

이 페이지는 미국의 타임즈지에 2013년에 올라온 기사인데요, 2007년 부터 2012년까지 S&P 500에 올라온 기업들이 법인세를 어떤 세율로 내고 있는가에 대한 데이터를 그래프로 표현한 겁니다.

자세히 보시면 애플에 부과한 세율이 14% 인데요 이 세율이 너무 낮게 책정되었다는 의회 청문회를 기사로 작성하면서 그 근거 데이터를 비주얼하게 보여준 기사라고 할 수 있습니다.

또 The View by Industry 버튼을 누르면 업종별로 펼쳐서 그래프를 볼 수도 있습니다. 여기서 애플은 정보기술 업종의 다른 기업들에 비해서도 아주 낮은 세율을 적용받고 있는걸 볼 수 있습니다. 물론 금액을 표시하는 시가총액을 나타내는 원의 크기를 보면 대표적인 기름 회사인 엑슨모빌 같은 기간산업 기업들과 비슷한데도 불구하고 부과되는 세율은 아주 작다는 것을 한눈에 알 수 있습니다.

이런 형식의 그래프를 버블 차트라는 이름으로 부르는것 같습니다. 저도 아직은 잘 모르겠지만 공부를 하다보면 알 수 있겠죠?

plan#

일단 디쓰리 D3 학습을 통해 알게된 내용을 매주 테크톡 시간에 발표하고 테크웰 문서에 올려놓을 계획입니다. 그리고, 매주 공부한 내용을 블로그를 통해 텍스트로도 올려놓을 생각입니다.

지금 하고있는 업무가 있기 때문에 많은 시간을 할애하지는 못하겠지만 그래도 틈틈이 공부해서 2달 안에 뭔가 작은 결과물을 하나 만들어서 볼 계획 입니다.

초급 개발자들도 같이 참여할 수 있게 내용은 처음부터 쉽게 작성하고 테크톡 시간에는 학습한 내용에 대한 리뷰만 발표하겠습니다.

methods#

D3를 학습하는 방법은

• 매주 조금씩 학습
• 테크웰에 학습하면서 작성한 문서 공개
• 테크톡 시간에 간단하게 학습한 내용 또는 학습할 내용을 발표

resource#

여러가지 산발적인 리소스들, 하지만 그들이 향하는 방향은 단 하나 여야 한다. 데이터 시각화.

• svg
  • w3schools
  • mozilla
• d3 examples
  • observable
  • vega-lite
• data
  • learn
    • data science
  • samples
    • github wooritech
    • ilab service request
    • realdesk
• others
  • kaggle

trace#

백패킹이나 캠핑의 생태계에 leave no trace (LNT) 라는 말이 있습니다. 우리가 어딘가에서 머무르고 있다가 그 자리를 떠날 때, 쓰레기 같은 흔적을 남기면 안 된다는 의미에서 사용하는 말입니다. 하지만, 일반적인 회사의 생태계에서 이런 말을 듣는다면 "놀았네" 라는 말을 들을 수도 있을 것입니다. ㅋㅋ

개발자로서 나는 가능한 한 많은 발자취를 남기려고 애를 썻던것 같습니다. 온라인이건 오프라인이건 여러 가지 방법으로 많이 남기려고 노력 했습니다. 물론 그 흔적들을 한눈에 볼 수 있는 방법은 없지만 찾아보고자 마음먹으면 방법은 있을 것입니다.
하지만, 나는 정말 해야 할 일들을 한 것인가에 대한 의문이 들 때가 있습니다. 예를 들어 - 그럴 리는 없겠다 싶지만 - '혹시 하지 말아야 할 일을 한 것은 아닌가?' 또는 '하지 않아도 되는 일을 한 것은 아닌가?' 하는 생각들 입니다.

곰곰이 생각해 보면 가야 할 길을 미리 정하고 남긴 발자국이 아니라 여기저기 다니면서 흔적만 잔뜩 만들어 놓은것 같은 느낌입니다.

올해에는 흔적 남기는 일을 잠시 멈추더라도 가야 할 길을 미리 정하고 가야겠습니다. 다시 말해서, 장기적으로 또는, 단기적으로 목표를 계속 되짚어 점검하면서 일을 해야겠는 생각입니다.

로드맵을 통해 목표 설정하기.#

draft#

완성된것 보다 더 많은 영감을 주는 미완성들이 있습니다.

여러 가지 프로젝트를 동시에 개발 하다 보면 외부 라이브러리나 패키지를 사용할 일이 많이 있습니다. 이런 외부 프로그램을 사용해 보기 위해 연습용 디렉토리를 만들고 코드를 만들어 보는데 실제로 연습을 완성한 것도 있지만 그렇지 못한 미완성의 코드들도 많이 있습니다.

이것들을 한군데 모아놓고 시간 날 때 하나씩 열어서 코드를 보다 보면 그것들을 만들 당시의 기억이 떠오를 때가 있습니다. 그때는 왜 그런 생각을 했었는지, 지금은 어떻게 생각이 바뀌었는지, 또 어떤 지식이나 방법들 때문에 지금은 그런 방식을 사용하지 않는다든지 등등 여러 가지 생각들이 떠오르기도 하고 잘못된 습관이나 지식을 다시 깨닫게 되기도 합니다.

올해에는 이런 경험을 같이 공유해 보면 좋겠다는 생각을 해 봅니다.

샌드박스에 연습 공유하기#

read#

글을 읽는 다는건 무지 귀찮은 일입니다.

유튜브같은 영상물을 자주 보다보니 더더욱 글을 읽는 것이 불편하고 힘들어 지는것 같습니다. 글과 영상에는 각각의 장단점이 있습니다. 개인적으로, 아무리 잘 만들어진 강좌 영상 일지라도 글에서 얻게되는 안정된 느낌의 지식은 기대하기 어렵다고 생각합니다.

꼭 이런 이유에서만은 아니지만 올해에는 더 많이 읽고, 또 읽는것에 멈추지 않고 정리까지... 해야 겠습니다.

📚 추천 바랍니다.#

write#

글읽기 만큼이나 글 쓰기도 귀찮은 일입니다.

요즘들어 깃허브에 올리는 이슈, 업무적인 메일이나 단순 기록, 문자를 보내거나 채팅에 쓰는 글 말고 글쓰는 일이 거의 없는것 같습니다. 조금 오랜시간 고민하고 생각하면서 글쓰는 일은 거의 없는 것 같습니다. 더군다나 작년엔 코로나로 취미생활도 못하는 바람에 동호회 카페에 후기 같은 것도 작성할 일이 많지 않았습니다.

올해는 가끔이라도 생각하면서 글을 써야 겠습니다. 생각하면서 글을 쓰고 지우고 고치고 하다보면 조각이 사라진것 처럼 보이던 퍼즐의 한 부분이 맞춰지는것 같기도 합니다. 지금처럼 블로그에 글도 자주 올려봐야 겠습니다.

블로그에 글쓰기#

custom blog page#

도큐사우러스가 제공하는 블로그 목록페이지를 조금 수정했습니다. 도큐사우러스의 블로그 플러그인 페이지에 대한 연습 정도로 생각하고 변경할 수 있는 아래 네개의 페이지 중 목록과 내용 페이지만 수정했습니다.

writing, what?#

테크웰 사이트의 블로그 포스트 작성은 아무런 제약이 없는게 맞겠죠? 누구나, 어떤 내용이든 작성해서 공유하면 좋을것 같습니다. 물론 사이트는 외부에 공개되겠지만 보안사항이 아니면 관계없을것 같습니다.

writing, how?#

blog 디렉토리에 기존에 작성된 내용을 참고하세요. 2019 폴더는 내용에 포함된 경로등의 오류로 일단 새로운 사이트에 포함시키지 않았습니다. 필요하면 추가하면 나중에 추가하기로 하죠. 다시한번, 작성 방법은 기존 작성된 포스트나 도큐사우러스의 블로그 작성 가이드 를 참고하세요.

CropImg#

CropImg 라는 이름의 이미지 잘라내기 컴포넌트를 사용해 보세요. 사용법은 소스코드를 참고하거나 기존에 작성된 블로그 포스트를 참고하세요.

CropImg 사용예#

소스 이미지의 상단 50픽셀을 잘라낸것 처럼 상단으로 이동시켜 보여줍니다. 아래 내용을 마크다운파일 내부에 입력하면 이미지를 표시할 수 있습니다. 이 컴포넌트는 완전히 테스트를 마치지 않은 미숙한 컴포넌트 입니다.