바이너리의 단점

마지막 업데이트: 2022년 7월 11일 | 0개 댓글
  • 네이버 블로그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 트위터 공유하기
  • 카카오스토리 공유하기
[그림 3] 고수준·저수준 컨테이너 런타임 관계와 도커 아키텍처

GpgStudy 포럼

가만히 생각해보니 꼭 그렇지가 않은 것 같더라구요.
왜냐하면 STL이 템플릿 기반으로 작성된 것이고, 템플릿이라는 것이 일반적으로 코드를 작성하면 그 코드를 컴파일러가 컴파일 시점에 해석하여 각 데이터타입에 해당하는 코드로 만들어주는 것이니.

범용적으로 처리하기 위한 코드가 더 추가되는 것이 아니라
( 범용적으로 처리하기 위한 코드가 추가되는 단점이 있는 것이 아니라 )
다만 ( 컴파일러가 해당하는 데이터타입들에 대한 코드를 실제로 만들기 때문에 )
컴파일러가 신뢰성이 없다면 만들어지는 코드도 (바이너리도) 신뢰성이 없어진다

정리하자면 '컴파일러에 너무 의존적인 코드이다' 라는 것이 STL의 단점이 아닐까 라는 생각이 드는데, 이 생각이 과연 맞는걸까요?

지지 않으려는 마음은 가짜
이기고 싶은 마음이 진짜

전체글 글쓴이: 비회원 » 2008-07-15 17:01

풍류협객 작성: 흐흠. 제가 생각하고 있는 것을 말씀드려보자면
정리하자면 '컴파일러에 너무 의존적인 코드이다'( STL코드를 판단하는 컴파일러에 따라 안습인 코드도 나올 수 있다 ) 라는 것이 STL의 단점이 아닐까 라는 생각이 드는데, 이 생각이 과연 맞는걸까요?

이미 STL 은 표준화가 되어있는 녀석이고 따라서 표준 REF. 에 의해 반드시 이러이러한 것을 만족시켜야 한다라는 것이 어느정도 정의되어있습니다.

STL의 중요한 점 중 하나는 복잡도(Time complexity - 혹은 Big O 에 의한 알고리즘 복잡도)의 보장입니다.

따라서 어떤 컴파일러를 쓰던간에 표준을 만족하는 컴파일러라면, 반드시 STL의 특성이 그대로 구현 되어야 할 것입니다.

물론 특수한 케이스나 성능이 상수배 만큼 차이나는 경우는 있겠지요.

그러나 STL의 정의나 표준을 살펴볼 때 STL 자체가 컴파일러에 의존적이다! 라고 말할 사항은 거의 없을 것으로 생각합니다.

물론 예전에 STL이 여기저기서 제대로 구현되기 시작할 초창기만 하더라도 특성을 타곤 했죠. ( VS 6.0 시절 SGI 헤더와 비교 하던 때도 있었죠.. )

여하튼 표준이 제정되어 그것이 제대로 산업에서 굳어지기 시작한 지금은 컴파일러 의존성이크다 라고 보기엔 문제가 있다고 생각합니다.

전체글 글쓴이: 풍류협객 » 2008-07-15 17:21

풍류협객 작성: 흐흠. 제가 생각하고 있는 것을 말씀드려보자면
정리하자면 '컴파일러에 너무 의존적인 코드이다'( STL코드를 판단하는 컴파일러에 따라 안습인 코드도 나올 수 있다 ) 라는 것이 STL의 단점이 아닐까 라는 생각이 드는데, 이 생각이 과연 맞는걸까요?

이미 STL 은 표준화가 되어있는 녀석이고 따라서 표준 REF. 에 의해 반드시 이러이러한 것을 만족시켜야 한다라는 것이 어느정도 정의되어있습니다.

STL의 중요한 점 중 하나는 복잡도(Time complexity - 혹은 Big O 에 의한 알고리즘 복잡도)의 보장입니다.

따라서 어떤 컴파일러를 쓰던간에 표준을 만족하는 컴파일러라면, 반드시 STL의 특성이 그대로 구현 되어야 할 것입니다.

물론 특수한 케이스나 성능이 상수배 만큼 차이나는 경우는 있겠지요.

그러나 STL의 정의나 표준을 살펴볼 때 STL 자체가 컴파일러에 의존적이다! 라고 말할 사항은 거의 없을 것으로 생각합니다.

물론 예전에 STL이 여기저기서 제대로 바이너리의 단점 구현되기 시작할 초창기만 하더라도 특성을 타곤 했죠. ( VS 6.0 시절 SGI 헤더와 비교 하던 때도 있었죠.. )

여하튼 표준이 제정되어 그것이 제대로 산업에서 굳어지기 시작한 지금은 컴파일러 의존성이크다 라고 보기엔 문제가 있다고 생각합니다.

제가 설명을 잘 못 드린 듯 합니다.
제가 의도한 의미는 '컴파일러에 따라 코드의 성능이 달라질 수 있다' 라는 것이 아니라 다른 의미였습니다.
( 해당 부분의 구문은 수정하도록 하겠습니다 )

템플릿을 이용한 프로그래밍에서
데이터 타입에 따른 실제 코드는 컴파일러가 생성하는 것이므로

각 데이터 타입의 특성에 따라 하나 하나 직접 만든 자료구조나 알고리즘보다는
STL을 사용한 일반적 프로그래밍의 코드가 ( 컴파일러가 각 데이터 타입의 특성에 따라 그렇게 만들어주지 않는 이상 ) 성능이 떨어지는 것이 아니겠는가 ?

라는 . 그래서 컴파일러에 의존적인 코드가 아니겠는가 라는 의미였습니다.


다르게 얘기하자면
절차적으로 작성한 코드는 작성한 코드와 컴파일러가 생성한 바이너리의 코드가 일대일 대응인 반면
일반적으로 작성한 코드는 작성한 코드와 컴파일러가 생성한 바이너리의 코드가 일대다 이므로
아무래도 최적화 할 수 있는 여지가 없는 것이 아닌가 라는 얘기도 되겠네요.

지지 않으려는 마음은 가짜
이기고 싶은 마음이 진짜

시즌인가. stl은 일정 시기마다 한번씩 까이는 것 같네요;;

전체글 글쓴이: 그레이오거 » 2008-07-15 17:29

개인적으로는 stl 많이 씁니다. 주로 vector, deque, map, multimap, string이죠.
2005 쓰기 때문에 컴파일러 걱정도 크게 하지 않습니다. 그래서 boost같은 추가적인 확장 없이 걍 기본 그대로 씁니다.
critical section 문제나 추가기능이 필요한 녀석들은 간단한 wrapper를 만들어 씁니다.

단지 다들 아시는 몇가지만 주의합니다. 예를 들자면.

vector에서,
- reserve 제대로 안하고 실시간 push_back 했다간 피본다.
- clear가 clear가 아니다
- 실수로 범위 외 참조했다간 지옥을 볼 것이다

map에서,
- 집어넣을때는 최대한 insert(::value_type())을 애용한다
- 삽입/삭제가 심.각.하.게 느리므로 로딩타임 외에는 감히 시도하지 않는다
(그래서 꼭 필요한 경우는 vector 두개를 사용해 맵 비스무리하게 만든 커스텀 자료형을 사용합니다)
- 인덱싱은 바이너리 서치로 이루어지므로 최대한 key로 문자열을 사용하는 만행은 피하자

머 stl의 장점은 잘 아실테고 몇몇 단점만 조심하면 충분히 신뢰할만하고, 안정적이며, 쓰기 편한데다, 적절히 빠르고, 무엇보다 팀원간 자료구조 문제로 다툴 일이 없어서 좋더군요.

하지만 이 몇몇 단점이 심하게 치명적이라 아무생각없이 쓰면 난리난다는데는 동의합니다.
반드시 케이스별로 프로파일링 해 보아야만 하며, 각 자료형의 특성을 만족시켜주어야만 합니다.
안그랬다 본 피가 산넘고 물건너 바다를 이룰 정도라. ㅠ_ㅠ

음. 아무래도 속도가 많이 떨어지죠.

전체글 글쓴이: sangduckx » 2008-07-15 17:57

물론 STL에 많은 종류들이 있지만.

MS에서 기본적으로 제공해주는 STL은 성능이 몇십%가 정도가 아니고 특화된 것이랑 몇 천%씩 성능차이가 나는 경우가 흔하니까. -_-;;

Re: 시즌인가. stl은 일정 시기마다 한번씩 까이는 것 같네요;;

전체글 글쓴이: masque » 2008-07-15 18:08

전체글 글쓴이: 풍류협객 » 2008-07-15 18:15

그레이오거/ STL을 까려고 쓴 글이 아니라
잘 사용하려면, 단점도 확실히 알아야 하지 않을까 해서 질문 드린 것입니다.

모든 일에는 장점과 단점이 있을 테니까요

지지 않으려는 마음은 가짜
이기고 싶은 마음이 진짜

Re: 시즌인가. stl은 일정 시기마다 한번씩 까이는 것 같네요;;

전체글 글쓴이: mastercho » 2008-07-15 18:17

그레이오거 작성: 단지 다들 아시는 몇가지만 주의합니다. 예를 들자면.

vector에서,
- reserve 제대로 안하고 실시간 push_back 했다간 피본다.
- clear가 clear가 아니다
- 실수로 범위 외 참조했다간 지옥을 볼 것이다

map에서,
- 집어넣을때는 최대한 insert(::value_type())을 애용한다
- 삽입/삭제가 심.각.하.게 느리므로 로딩타임 외에는 감히 시도하지 않는다
(그래서 꼭 필요한 경우는 vector 두개를 사용해 맵 비스무리하게 만든 커스텀 자료형을 사용합니다)
- 인덱싱은 바이너리 서치로 이루어지므로 최대한 key로 문자열을 사용하는 만행은 피하자

vector 의 reserve 요거 정말 신중하게 안하면 피 볼수 있습니다
약 수년전 , 아무 생각없이 [솔직히 코딩이 귀찬아서. ] reserve 안하고 그냥 push_back 한적이 있습니다

문제는 극도로 자주 호출되는 함수 였고
[한 frame당 많게는 수백번까지]

그 함수내에서 push_back 이거 한 4-5번 하고 vector를 제거하는 코드가 들어 있었습니다
뭐 그당시 CPU를 30%이상 거의 넘게 쓰지 않다보니 , 뻔히 알고 있는 주의사항을 흘겨버렸었죠

결과는 충격적이었습니다
CPU가 수십%이상 올라가더군요

아무리 대충썼거늘 이런 결과가 -_-; 나올까 하며 vector를 배열로 바꿨더니
cpu 증가가 1%도 안되더군요 .

그 후 vector에 자주 삽입을 하게 되는 코드를 실행할때는 reserve를 확인합니다
[물론 이것도 귀찬아서 reserve가 꼭 필요한 코드에만. ]
그러다가 fix_vector 같은 것을 연구해보기도 했습니다
우습게도 이런게 있을거 같은데 인터넷을 아무리 뒤져도 없더군요. 그래서 그냥 만들어봤습니다
[ viewtopic.php?t=13222&highlight=fix_vector ]

참, map의 삽입 삭제 오버헤드는 자료구조책의 균형 tree를 쪽을 보면 이해가 쉽지 않을까 합니다
검색속도의 일관성 및 향상을 위해 삽입 삭제시 , 각 노드마다 깊이 차이를 만들지 않기 위해 tree가
여러가지 일을 합니다
따라서 map를 제대로 쓰기 위해선 균형 tree에 관한 내용은 꼭 읽어보셔야 할거 같습니다
다만 그레이오거님의 "로딩타임 외에는 감히 시도하지 않는다"는 프로파일링을 통해 검증해야 할 사항이라
생각됩니다, 삽입 ,삭제가 충분할만한 조건이 그렇지 않을때보다 더 많지 않을까요?바이너리의 단점 바이너리의 단점


또 map에 string을 넣지 말라는건 좀 의아하합니다
물론 정수형보다 느리다는건 자명하지만
string을 key 써야하는 일은 흔하게 많습니다
극도의 성능을 요구 하지 않는다면
그걸 정수형으로 key를 만들어내는게 더 안좋은 결과를 낼수 있지 않을까 하는데요
[한마디로 , 안좋은 형태로 데이타를 관리해야 하는 문제가 생기고요, 또한 스크립트 코드로 c++ 코드를 노출시키다보면 가장 완벽한 호환성을 가진것으로 string 만한게 없습니다 , 그러다보면 자주 string을 쓰게 되며
map에 string으로 키를 잡게 되는 경우가 -_-; 상당히 빈번하네요 사실
lua나 기타 스크립트에서 쓰는 container들이 다 맵구조로 되어 있지 않씁니까? ]

메모리에 올라와 있는 이런건 그렇게 까지 부담스럽지 않았던거 같았고
그마저 부담이 된다면 hash_map를 쓰면 무리가 없지 않을까 싶은데요

string을 비교하는 루틴을 보면 , 최악으로는 문자열 길이 만큼 비교횟수가 이루어지겠고, 최선은
일반 정수처럼 문자하나에서 바로 비교가 끝나기도 할겁니다

그런것이 고려된다면, 막연히 "최대한 key로 문자열을 사용하는 만행은 피하자"는 말씀은 오해의 여지가 있다고 생각됩니다

그리고 map 이나 set은 꼭 대형 자료구조에서만 쓰이는게 아니라
간단히 중복된 데이터를 넣지 않기 위한 용으로 간단하게 쓸 경우도 많고요

현재 프로젝트에 적절한가가 고려되어 선별적으로 쓰여야 할것이라 생각됩니다


ps
나머진 effective stl 에서 다룬 내용들이니 , 못보신분은 꼭 읽어보셔야할거 같습니다
저도 3번이상 읽었던거 같네요

데이터 분석가 판교데싸

  • Node: 트리에서 데이터를 저장하는 기본 요소 (데이터와 다른 연결된 노드에 대한 Branch 정보 포함)
  • Root Node: 트리 맨 위에 있는 노드
  • Level: 최상위 노드를 Level 0으로 하였을 때, 하위 Branch로 연결된 노드의 깊이를 나타냄
  • Parent Node: 어떤 바이너리의 단점 노드의 다음 레벨에 연결된 노드
  • Child Node: 어떤 노드의 상위 레벨에 연결된 노드
  • Leaf Node (Terminal Node): Child Node가 하나도 없는 노드
  • Sibling (Brother Node): 동일한 Parent Node를 가진 노드
  • Depth: 트리에서 Node가 가질 수 있는 최대 Level

3. 이진 트리와 이진 탐색 바이너리의 단점 트리 (Binary Search Tree)

  • 이진 트리: 노드의 최대 Branch가 2인 트리
  • 이진 탐색 트리 (Binary Search Tree, BST): 이진 트리에 다음과 같은 추가적인 조건이 있는 트리
    • 왼쪽 노드는 해당 노드보다 작은 값, 오른쪽 노드는 해당 노드보다 큰 값을 가지고 있음!

    4. 자료 구조 이진 탐색 트리의 장점과 주요 용도

    • 주요 용도: 데이터 검색(탐색)
    • 장점: 탐색 속도를 개선할 수 있음

    단점은 이진 탐색 트리 알고리즘 이해 후에 살펴보기로 함

    이진트리와 정렬된 배열간의 탐색 비교

    • 매우 복잡함. 경우를 나누어서 이해하는 것이 좋음

    5.4.1. Leaf Node 삭제

    5.4.2. Child Node 가 하나인 Node 삭제

    5.4.3. Child Node 가 두 개인 Node 삭제

    1. 삭제할 Node의 오른쪽 자식 중, 가장 작은 값을 삭제할 Node의 Parent Node가 가리키도록 한다.
    2. 삭제할 Node의 왼쪽 자식 중, 가장 큰 값을 삭제할 Node의 Parent Node가 가리키도록 한다.

    5.4.3.1. 삭제할 Node의 오른쪽 자식중, 가장 작은 값을 삭제할 Node의 Parent Node가 가리키게 할 경우

    • 삭제할 Node의 오른쪽 자식 선택
    • 오른쪽 자식의 가장 왼쪽에 있는 Node를 선택
    • 해당 Node를 삭제할 Node의 Parent Node의 왼쪽 Branch가 가리키게 함
    • 해당 Node의 왼쪽 Branch가 삭제할 Node의 왼쪽 Child Node를 가리키게 함
    • 해당 Node의 오른쪽 Branch가 삭제할 Node의 오른쪽 Child Node를 가리키게 함
    • 만약 해당 Node가 오른쪽 Child Node를 가지고 있었을 경우에는, 해당 Node의 본래 Parent Node의 왼쪽 Branch가 해당 오른쪽 Child Node를 가리키게 함

    5.5.2. Case1: 삭제할 Node가 Leaf Node인 경우

    5.5.2. Case2: 삭제할 Node가 Child Node를 한 개 가지고 있을 경우

    5.5.3. Case3-1: 삭제할 Node가 Child Node를 두 개 가지고 있을 경우 (삭제할 Node가 Parent Node 왼쪽에 있을 때)

    • 기본 사용 가능 전략
      1. 삭제할 Node의 오른쪽 자식 중, 가장 작은 값을 삭제할 Node의 Parent Node가 가리키도록 한다.
      2. 삭제할 Node의 왼쪽 자식 중, 가장 큰 값을 삭제할 Node의 Parent Node가 가리키도록 한다.
    • 기본 사용 가능 전략 중, 1번 전략을 사용하여 코드를 구현하기로 함
      • 경우의 수가 또다시 두가지가 있음
        • Case3-1-1: 삭제할 Node가 Parent Node의 왼쪽에 있고, 삭제할 Node의 오른쪽 자식 중, 가장 작은 값을 가진 Node의 Child Node가 없을 때
        • Case3-1-2: 삭제할 Node가 Parent 바이너리의 단점 바이너리의 단점 Node의 왼쪽에 있고, 삭제할 Node의 오른쪽 자식 중, 가장 작은 값을 가진 Node의 오른쪽에 Child Node가 있을 때
          • 가장 작은 값을 가진 Node의 Child Node가 왼쪽에 있을 경우는 없음, 왜냐하면 왼쪽 Node가 있다는 것은 해당 Node보다 더 작은 값을 가진 Node가 있다는 뜻이기 때문임

          5.5.4. Case3-2: 삭제할 Node가 Child Node를 두 개 가지고 있을 경우 (삭제할 Node가 Parent Node 오른쪽에 있을 때)

          • 기본 사용 가능 전략
            1. 삭제할 Node의 오른쪽 자식 중, 가장 작은 값을 삭제할 Node의 Parent Node가 가리키도록 한다.
            2. 삭제할 Node의 왼쪽 자식 중, 가장 큰 값을 삭제할 Node의 Parent Node가 가리키도록 한다.
          • 기본 사용 가능 전략 중, 1번 전략을 사용하여 코드를 구현하기로 함
            • 경우의 수가 또다시 두가지가 있음
              • Case3-2-1: 삭제할 Node가 Parent Node의 오른쪽에 있고, 삭제할 Node의 오른쪽 자식 중, 가장 작은 값을 가진 Node의 Child Node가 없을 때
              • Case3-2-2: 삭제할 Node가 Parent Node의 오른쪽에 있고, 삭제할 Node의 오른쪽 자식 중, 가장 작은 값을 가진 Node의 오른쪽에 Child Node가 있을 때
                • 가장 작은 값을 가진 Node의 Child Node가 왼쪽에 있을 경우는 없음, 왜냐하면 왼쪽 Node가 있다는 것은 해당 Node보다 더 작은 값을 가진 Node가 있다는 뜻이기 때문임6. 이진 탐색 트리의 시간 복잡도와 단점

                • depth (트리의 높이) 를 h라고 표기한다면, O(h)
                • n개의 노드를 가진다면, ℎ = 𝑙 𝑜 𝑔 2 𝑛 h=log2n 에 가까우므로, 시간 복잡도는 𝑂 ( 𝑙 𝑜 𝑔 𝑛 ) O(logn)
                  • 참고: 빅오 표기법에서 𝑙 𝑜 𝑔 𝑛 logn 에서의 log의 밑은 10이 아니라, 2입니다.
                    • 한번 실행시마다, 50%의 실행할 수도 있는 명령을 제거한다는 의미. 즉 50%의 실행시간을 단축시킬 수 있다는 것을 의미함

                    ScienceON Chatbot

                    ※ 국가연구개발사업의 관리 등에 관한 규정(2012.7.1 시행)
                    에 의해 추후 공개로 전환될 가능성은 있습니다.

                    과제관리기관과의 협의를 통하여 비공개 보고서를 공개로 전환할 수
                    있도록 계속적으로 관리되고 있으며, 현재 비공개 처리된 보고서의
                    열람이 어려운 점 양해 바이너리의 단점 부탁드립니다.

                    보고서 상세정보

                    바이너리 코드 동적고유정보 기반 SW 유사성 감지 기술 개발

                    Measurement of Software Similarity based on Dynamic Characteristics of Binary Codes

                    과제명 바이너리 코드 동적고유정보 기반 SW 유사성 감지 기술 개발
                    주관연구기관 단국대학교 산학협력단
                    연구책임자 조성제
                    참여연구자 박민규, 우진운, 임을규, 최종무, 한환수, 홍지만, 김동진, 장혜영, 최종천, 정윤식, 한용만 . 더보기
                    보고서유형 연차보고서
                    발행국가 대한민국
                    언어 한국어
                    발행년월 2013-03
                    과제시작년도 2012
                    주관부처 문화체육관광부
                    사업 관리 기관 한국저작권위원회
                    등록번호 TRKO201300031765
                    과제고유번호 1375025645
                    사업명 저작권보호및이용활성화기술개발
                    DB 구축일자 2013-12-21
                    키워드 바이너리코드.동적 고유정보.특징정보.SW 유사성.불법 SW 필터링.프로파일.패킹.이기종 컴파일러.SW 버스마크.Binary code.Dynamic characteristics.Feature.SW similarity.Pirated SW filtering.Profile.Packing.Dissimilar compilers.SW birthmark.
                    연구과제
                    타임라인

                    연구과제 성과물(0)

                    참여연구원의 다른 문헌(0)

                    Ⅱ. 기술개발의 목적 및 필요성
                    사무용 소프트웨어 연합(BSA)의 2011년 조사에 의하면 국내SW 불법복제율 40%로 약 7,500억원의 손실액을 보였고, 애플은 앱 스토어 개설 후 유료 앱 불법복제로 4억 5,000만달러의 .

                    Ⅱ. 기술개발의 목적 및 필요성
                    사무용 소프트웨어 연합(BSA)의 2011년 조사에 의하면 국내SW 불법복제율 40%로 약 7,500억원의 손실액을 보였고, 애플은 앱 스토어 개설 후 유료 앱 불법복제로 4억 5,000만달러의 매출손실을 기록하였고, 독일 SW 업체 SAP은 오라클에 13억달러 배상 판결을 받는 등, SW 불법복제 및 표절로 인해 사회·경제·문화적인 피해가 급증하고 있다. 하지만 바이너리코드 수준에서 실행파일의 동일성/유사성을 객관적으로 검증하는 기술에 대한 연구는 매우 미비한 실정이다.
                    BSA에 조사에 의하면 SW 불법복제율을 10% 절감할 경우 미화 15억 달러의 경제성장 효과가 전망되고 약 7억달러의 조세 수입이 증가될 수 있으며 1만개의 신규 일자리 창출이 가능하다.
                    바이너리코드의 정적·동적 고유정보를 기반으로 실행파일들의 동일성 또는 유사성을 비교할 수 있는 기술을 개발하여, SW 불법복제 여부 확인 및 유사 SW 식별, 그리고 코드 표절 여부 등을 확인하여, 의도적 또는 비의도적인 저작권 위반을 방지할 수 있는 환경을 조성하고 SW 산업 육성을 도모하는 것이 본 기술개발의 목적이다.

                    Abstract

                    Ⅱ. Purpose and necessity of the research project
                    The Business Software Alliance (BSA) publishes the yearly study about copyrigh.

                    Ⅱ. Purpose and necessity of the research project
                    The Business Software Alliance (BSA) publishes the yearly study about copyright infringement of software. The Ninth Annual BSA 2011 Piracy Study reported that 40 percent of Korea’s personal computer users admit to pirating software. The commercial value of all these pirated software is $1,223 million in 2011. Apple App Store has lost over $450 million to piracy from July 2008 to January 2010. On November 2010, a US court has ordered SAP to pay rival Oracle $1.3 billion in damages for the theft of intellectual property. The fine is very high and would have a significant impact on the company’s financial
                    performance in 2010.
                    In this way, social, SW piracy and plagiarism have caused serious social, economic and cultural losses. However, very little research has been done to verify objectively the technology research to verify objectively the co-identity or similarity of executable files at binary code-level.
                    BSA estimated that reducing the current SW piracy rate by 10% over four years would contribute $1.5 billion to GDP, increase the tax revenue of approximately $ 0.7 billion, and create an additional 10,000 IT jobs.
                    Therefore, the purpose of this research project is to develop the technology to examine co-identity or measure similarity of MS Windows executable files based on static and dynamic characteristics of binary codes. Using the technology, we can determine whether 바이너리의 단점 SW is illegally copied and stolen, prevent intentional or unintentional infringement of SW copyright, and promote the development of SW industry.

                    바이너리 코드

                    코딩에서 숫자, 문자 또는 단어가 특정 기호 그룹으로 표시 될 때 숫자, 문자 또는 단어가 인코딩되고 있다고합니다. 기호 그룹을 코드라고합니다. 디지털 데이터는 바이너리 비트 그룹으로 표현, 저장 및 전송됩니다. 이 그룹은binary code. 이진 코드는 숫자와 영숫자로 표시됩니다.

                    바이너리 코드의 장점

                    다음은 바이너리 코드가 제공하는 장점 목록입니다.

                    이진 코드는 컴퓨터 응용 프로그램에 적합합니다.

                    바이너리 코드는 디지털 통신에 적합합니다.

                    이진 코드를 사용하면 이진 코드는 디지털 회로를 분석하고 설계합니다.

                    0 & 1 만 사용하므로 구현이 용이합니다.

                    이진 코드의 분류

                    코드는 크게 다음 네 가지 범주로 분류됩니다.

                    • 가중 코드
                    • 비가 중 코드
                    • 이진 코드 십진수 코드
                    • 영숫자 코드
                    • 코드 감지 오류
                    • 오류 수정 코드

                    가중 코드

                    가중 이진 코드는 위치 가중치 원칙을 따르는 이진 코드입니다. 숫자의 각 위치는 특정 가중치를 나타냅니다. 코드의 여러 시스템이 10 진수 0에서 9까지를 표현하는 데 사용됩니다.이 코드에서 각 10 진수는 4 비트 그룹으로 표시됩니다.

                    비가 중 코드

                    이 유형의 2 진 코드에서는 위치 가중치가 지정되지 않습니다. 가중치가 적용되지 않은 코드의 예는 Excess-3 코드와 그레이 코드입니다.

                    초과 -3 코드

                    Excess-3 코드는 XS-3 코드라고도합니다. 십진수를 표현하는 데 사용되는 가중치가없는 코드입니다. Excess-3 코드 단어는 8421의 각 코드 단어에 (0011) 2 또는 (3) 10을 추가하는 8421 BCD 코드 단어에서 파생됩니다. 초과 -3 코드는 다음과 같이 구합니다.

                    그레이 코드

                    가중치가 적용되지 않은 코드이며 산술 코드가 아닙니다. 이는 비트 위치에 지정된 특정 가중치가 없음을 의미합니다. 그림과 같이 10 진수가 증가 할 때마다 1 비트 만 변경되는 매우 특별한 기능이 있습니다. 한 번에 하나의 비트 만 변경되므로 그레이 코드를 단위 거리 코드라고합니다. 회색 코드는 순환 코드입니다. 회색 코드는 산술 연산에 사용할 수 없습니다.

                    그레이 코드 적용

                    회색 코드는 샤프트 위치 인코더에서 널리 사용됩니다.

                    샤프트 위치 인코더는 샤프트의 각도 위치를 나타내는 코드 워드를 생성합니다.

                    BCD (Binary Coded Decimal) 코드

                    이 코드에서 각 십진수는 4 비트 이진수로 표시됩니다. BCD는 각 십진수를 이진 코드로 표현하는 방법입니다. BCD에서는 4 비트로 16 개의 숫자 (0000 ~ 1111)를 나타낼 수 있습니다. 그러나 BCD 코드에서는 이들 중 처음 10 개만 사용됩니다 (0000 ~ 1001). 나머지 6 개의 코드 조합, 즉 1010 ~ 1111은 BCD에서 유효하지 않습니다.

                    BCD 코드의 장점

                    • 십진법과 매우 유사합니다.
                    • 십진수 0에서 9까지만 이진수에 해당하는 것을 기억하면됩니다.

                    BCD 코드의 단점

                    BCD의 더하기와 빼기에는 다른 규칙이 있습니다.

                    BCD 산술은 조금 더 복잡합니다.

                    BCD는 십진수를 나타 내기 위해 이진수보다 더 많은 비트 수가 필요합니다. 따라서 BCD는 바이너리보다 덜 효율적입니다.

                    영숫자 코드

                    이진 숫자 또는 비트는 '0'또는 '1'상태가 두 개뿐이므로 두 개의 기호 만 나타낼 수 있습니다. 그러나 이것은 통신을 위해 더 많은 기호가 필요하기 때문에 두 컴퓨터 간의 통신에는 충분하지 않습니다. 이 기호는 대문자와 소문자, 0에서 9 사이의 숫자, 구두점 및 기타 기호로 26 개의 알파벳을 나타 내기 위해 필요합니다.

                    영숫자 코드는 숫자와 영문자를 나타내는 코드입니다. 대부분 이러한 코드는 정보 전달에 필요한 기호 및 다양한 지침과 같은 다른 문자를 나타냅니다. 영숫자 코드는 최소한 10 자리 알파벳 26 자 (총 36 개 항목)를 나타내야합니다. 다음 세 개의 영숫자 코드는 데이터 표현에 매우 일반적으로 사용됩니다.

                    • 정보 교환을위한 미국 표준 코드 (ASCII).
                    • EBCDIC (Extended Binary Coded Decimal Interchange Code).
                    • 5 비트 Baudot 코드.

                    ASCII 코드는 7 비트 코드이고 EBCDIC는 8 비트 코드입니다. ASCII 코드는 전 세계적으로 더 일반적으로 사용되는 반면 EBCDIC는 주로 대형 IBM 컴퓨터에서 사용됩니다.

                    흔들리는 도커(Docker)의 위상 - OCI와 CRI 중심으로 재편되는 컨테이너 생태계

                    IT 업계 종사자라면 컨테이너(Container)에 대해 한 번쯤은 들어본 적이 있을 것입니다. 애플리케이션과 바이너리, 라이브러리 등을 패키지로 묶어 배포하는 컨테이너는 서로 다른 컴퓨팅 환경에서 애플리케이션을 안정적으로 실행할 수 있으며 개발 환경에 구애 받지 않고 빠른 개발과 배포가 가능하다는 장점이 있습니다. 대표적인 IT 기업 중 하나인 구글은 지메일에서 유튜브, 검색에 이르기까지 모든 제품을 컨테이너에서 실행하고 있기도 합니다. 이처럼 컨테이너 기술은 IT 개발과 운영에 있어서 빼놓을 수 없는 필수 요소로 자리잡았습니다.

                    컨테이너에 대한 관심이 급격히 증가하면서 대부분의 주요 IT 벤더와 클라우드 공급자들은 컨테이너 기반의 솔루션을 발표했고 관련 스타트업 또한 급증해 컨테이너의 생태계를 넓혀왔습니다. 하지만 포맷과 런타임에 대한 특정한 규격이 없다 보니 컨테이너의 미래는 불안했던 것이 사실입니다. 일례로 2013년 출시된 도커(Docker)가 사실상의 컨테이너 표준 역할을 했지만 코어OS(CoreOS)는 도커와는 다른 규격으로 표준화를 추진하려 했습니다. 이러한 문제를 해결하기 위해 2015년 6월 도커, 코어OS, AWS, 구글, 마이크로소프트, IBM 등 주요 플랫폼 벤더들은 애플리케이션의 이식성(Portability) 관점에서 컨테이너 포맷과 런타임에 대한 개방형 업계 표준을 만들기 위해 OCI(Open Container Initiative)를 구성하였습니다. 이후 컨테이너 시장은 OCI의 런타임 명세와 이미지 명세를 준수하는 방향으로 성장하였고 그 과정에서 2016년 12월 쿠버네티스(Kubernetes)의 컨테이너 런타임을 만들기 위한 CRI(Container Runtime Interface)가 등장했습니다.

                    2. 컨테이너 런타임

                    CRI의 등장 배경을 이해하려면 먼저 컨테이너 런타임에 대해 살펴봐야 합니다. 컨테이너를 실행하기 위해서는 다음과 같은 세 단계를 거칩니다.

                    그림1의 1번 이미지 다운로드 2번 이미지를 번들로 압축해제 3번 번들에서 컨테이너를 실행

                    [그림 1] 컨테이너 실행 단계

                    OCI가 만들어질 당시 비공식적 표준 역할을 하던 도커는 컨테이너 런타임의 표준화를 위해 필요한 모든 단계가 아닌 세 번째 단계인 컨테이너의 실행 부분만 표준화하였습니다. 이로 인해 컨테이너의 런타임은 실제 컨테이너를 실행하는 저수준 컨테이너 런타임인 OCI 런타임과 컨테이너 이미지의 전송 및 관리, 이미지 압축 풀기 등을 실행하는 고수준 컨테이너 런타임으로 나뉘게 되었습니다.

                    저수준 컨테이너 런타임(Low-Level Container Runtimes)
                    컨테이너는 Linux namespace와 cgroup을 사용하여 구현합니다. namespace는 각 컨테이너에 대해 파일 시스템이나 네트워킹과 같은 시스템 리소스를 가상화하고 cgroup은 각 컨테이너가 사용할 수 있는 CPU 및 메모리와 같은 리소스 양을 제한하는 역할을 합니다. 저수준 컨테이너 런타임은 이러한 namespace와 cgroup을 설정한 다음 해당 namespace 및 cgroup 내에서 명령을 실행합니다.

                    그림 2는 도커와 runC의 관계도

                    [그림 2] 도커와 runC

                    OCI를 준수하는 저수준 컨테이너 런타임으로 가장 잘 알려진 것은 runC입니다. runC는 원래 도커에서 컨테이너를 실행하기 위해 개발되었으나, OCI 런타임 표준을 위해 독립적인 라이브러리로 사용되었습니다. 저수준 컨테이너 런타임은 컨테이너를 실제 실행하는 역할을 하지만 이미지로부터 컨테이너를 실행하려면 이미지와 관련된 API 같은 기능이 필요합니다. 이러한 기능은 고수준 컨테이너 런타임에서 제공됩니다.

                    고수준 컨테이너 런타임(High-Level Container Runtimes)
                    일반적으로 고수준 컨테이너 런타임은 원격 애플리케이션이 컨테이너를 논리적으로 실행하고 모니터링 하는데 사용할 수 있는 데몬 및 API를 제공합니다. 또한 컨테이너를 실행하기 위해 저수준 런타임 위에 배치됩니다.

                    이처럼 컨테이너를 실행하려면 저수준 및 고수준 컨테이너 런타임이 필요하기 때문에 OCI 런타임과 함께 도커가 그 역할을 했습니다. 도커는 docker-containerd라는 가장 잘 알려진 고수준 컨테이너 런타임을 제공합니다. containerd도 runC와 마찬가지로 도커에서 컨테이너를 실행하기 위해 개발되었으나 나중에 독립적인 라이브러리로 추출되었습니다.

                    그림3의 왼쪽 그림은 고수준 저수준 컨테이너 런타임 관계이며, 오른쪽 그림은 도커 아키텍쳐 그림

                    [그림 바이너리의 단점 3] 고수준·저수준 컨테이너 런타임 관계와 도커 아키텍처

                    CRI(Container Runtime Interface)
                    CRI는 쿠버네티스에서 만든 컨테이너 런타임 인터페이스로 개발자들의 컨테이너 런타임 구축에 대한 진입 장벽을 낮추어 줍니다. 초기 쿠버네티스는 컨테이너를 실행하기 위해 도커를 사용하였는데 이는 쿠버네티스 클러스터 워커 노드의 에이전트인 Kubelet 소스코드 내부에 통합되어 있었습니다. 이처럼 통합된 프로세스는 Kubelet에 대한 깊은 이해를 필요로 하였고 쿠버네티스 커뮤니티에 상당한 유지보수 오버헤드를 발생시켰습니다. 이러한 문제를 해결하기 위해 쿠버네티스는 CRI를 만들어 명확하게 정의된 추상화 계층을 제공함으로써 개발자가 컨테이너 런타임 구축에 집중할 수 있게 하였습니다.

                    그림4는 Kubelet 동작의 흐름과 추상화 계층을 제공하는 CRI(Container Runtime Interface)의 구성도 I

                    [그림 4] Kubelet 동작 흐름과 CRI

                    3. 컨테이너의 새로운 생태계

                    CRI가 만들어진 후 주요 플랫폼 벤더들은 본격적으로 컨테이너 런타임 구축을 위해 노력하였습니다. 그 중 레드햇, 인텔, SUSE, Hyper, IBM 등의 관리자와 컨트리뷰터들이 커뮤니티 중심의 오픈소스 프로젝트인 CRI-O를 개발하였습니다.

                    CRI-O(Container Runtime Interface - Open Container Initiative)
                    CRI-O는 CRI와 OCI에서 바이너리의 단점 유래된 프로젝트로 컨테이너 런타임 및 이미지가 OCI와 호환되는 것에 중점을 두고 있습니다. CRI 표준 컴포넌트를 최소한의 런타임으로 구현하며 쿠버네티스에서 모든 OCI 호환 런타임 및 컨테이너 이미지를 지원합니다.

                    그림 5는 Kubernetes의 Worker node로 도커와 CRI-O 두 가지 방법

                    [그림 5] 쿠버네티스와 도커 및 CRI-O

                    CRI-O는 컨테이너의 실행을 목적으로 경량화했기 때문에 도커가 제공하는 컨테이너 생성 및 이미지 빌드와 같은 기능은 제공하지 않습니다. 즉, CRI-O 덕분에 쿠버네티스는 컨테이너를 실행할 때 도커가 필요없었으나, 컨테이너의 생성 및 이미지 빌드와 같은 과정에서는 여전히 도커를 필요로 했습니다. 이러한 이유로 CRI-O 개발팀은 도커를 대체할 수 있는 새로운 생태계를 만들기 위해 노력하였습니다.

                    도커의 문제점
                    도커가 컨테이너의 생성 및 이미지 빌드를 모두 처리하는데 새로운 툴이 왜 필요할까요? 물론 기존 방식대로 도커를 사용할 수 있습니다. 그럼에도 CRI-O 개발팀이 도커의 역할을 대신할 수 있는 생태계를 위한 툴(Buildah 빌다, Podman 포드맨, Skopeo 스코피오)을 개발한 이유는 다음과 같은 문제점이 제기되었기 때문입니다.

                    도커는 클라이언트/서버 애플리케이션으로 클라이언트인 Docker CLI와 서버인 Docker daemon으로 구성됩니다. 그 중 서버는 컨테이너 이미지 빌드, 관리, 공유, 실행 및 컨테이너 인스턴스 관리와 같이 너무 많은 기능을 담당하는 데몬으로 모든 컨테이너를 자식 프로세스로 소유합니다. 이로 인해 무거울 뿐 아니라 장애가 발생하면 모든 자식 프로세스에 영향을 끼쳐 단일 실패점(Single point of failure)이 될 위험이 있습니다. 또한 클라이언트-서버 모델을 사용할 경우 리눅스의 audit.log를 통해 관리자가 시스템의 보안 이벤트를 감시하고 기록된 정보를 볼 수 있는 audit 보안 기능을 사용할 수 없게 됩니다.

                    그림 6은 fork·exec 모델 및 클라이언트-서버 모델에서의 UID, auid 설정 동작 방식이 있으며, 클라이언트 - 서버의 경우 컨테이너 이미지 빌드, 관리, 공유 같이 많은 기능이 이 있어 무겁고 장애 발생 시 모든 자식 프로세스에 영향을 미치게 된다는 것을 보여주는 그림 [그림 6] fork·exec 모델 및 클라이언트-서버 모델에서의 UID, auid 설정 동작 방식

                    추가로 모든 도커 명령은 루트 권한을 가진 사용자에 의해서만 실행할 수 있어 보안 문제가 발생할 수 있습니다. 이는 아래에 소개하는 Buildah, Podman, Skopeo를 사용하면 해결할 수 있습니다.

                    CRI-O와 함께 사용 가능한 툴: Buildah, Podman, Skopeo
                    Buildah, Podman, Skopeo는 별도의 데몬 없이 전통적인 fork·exec 모델을 사용하며 사용자 네임 스페이스를 이용해 컨테이너를 실행함으로써 단일실패점, audit 보안 기능 사용 및 루트 권한 문제를 해결하였습니다. 도커의 서버가 너무 많은 기능을 가지고 있는 단점은 각 툴 별로 다음과 같이 기능을 나누어 제공하는 방식으로 보완하였습니다.

                    그림 7은 Docker vs.Podnam의 그림으로 도커의 동작 흐름 및 Podman, Buidah, Skopeo의 역할

                    [그림 7] 도커의 동작 흐름 및 Podman, Buidah, Skopeo의 역할

                    Buildah는 CRI-O에서 이미지를 빌드할 때 도커의 종속성을 제거하기 위해 개발되었고 Dockerfile 없이 다른 스크립트 언어를 사용해 컨테이너 이미지를 빌드하는 것을 목표로 합니다.

                    Podman은 pull 및 tag 지정과 같은 OCI 컨테이너 이미지를 유지관리하고 수정하는데 도움이 되는 모든 명령 및 기능을 제공합니다. 또한 컨테이너 작성, 실행 및 유지보수도 할 수 있습니다. 즉, Docker CLI에서 수행할 수 있는 명령은 Podman CLI에서도 동일하게 수행 할 수 있습니다.

                    Buildah와 Podman은 일부 겹치는 기능이 있는데 Buildah는 OCI 이미지를 생성하는 효율적인 도구로, Podman은 그러한 이미지와 이미지를 통해 생성한 컨테이너를 유지하고 관리하는 도구로 이해하면 됩니다. 기술적으로 buildah run은 Dockerfile RUN을 에뮬레이트하며 podman run은 docker run을 에뮬레이트 합니다.

                    Skopeo는 이미지 저장소에서 다양한 작업을 수행하는 명령줄 도구입니다. 기존 도커가 다른 레지스트리에 이미지를 복사하기 위해 pull, tag, push를 사용했다면 Skopeo는 간단하게 copy 명령으로 해당 기능을 제공합니다. 추가로 저장소에 있는 이미지 이름에 대해 로우 레벨 정보를 제공해줍니다.

                    4. 컨테이너의 미래

                    지금까지 도커, OCI, CRI, Buildah, Podman 등 컨테이너 기술의 전반적인 흐름과 생태계에 대해 알아보았습니다. 컨테이너는 온프레미스 환경에서 클라우드 네이티브 환경으로 옮기는 것을 쉽게 해주기 때문에 클라우드 컴퓨팅 분야에서 가장 주목 받는 기술 중 하나로 성장하고 있습니다. 그리고 그 중심에는 단연 도커가 자리잡고 있습니다. 하지만 컨테이너의 표준화가 이뤄진 후 컨테이너 시장은 OCI와 CRI를 중심으로 성장하고 있습니다. 그 과정에서 사실상 컨테이너 표준으로 사용되던 도커의 역할을 대신하는 다양한 기술이 나오고 있으며 그 중 Buildah, Podman, Skopeo는 도커의 기능을 역할별로 나눠 구현하고 있습니다. 이들은 또한 도커의 보안 관련 단점을 보완하며 기존에는 없던 편리한 기능도 추가로 제공합니다.

                    컨테이너 생태계는 계속해서 성장하고 있으며 도커 외에도 사용할 수 있는 다양한 대체기술을 선보이고 있습니다. 향후 컨테이너는 OCI의 설립 목적인 ‘통일된 표준을 통해 어디서든 작동하는 이식성 제공’을 위해 OCI와 CRI 표준을 중심으로 생태계를 넓혀갈 것입니다.

                    ▶ 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
                    ▶ 해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.


0 개 댓글

답장을 남겨주세요