ARM의 Big.LITTLE: 이게 무엇인가? #1/2

모바일 시스템은 성능과 전력의 trade-off가 큰 문제다. 대기 중 기능할 필요가 없는 노트북의 경우는 그나마 나으나 스마트 기기, 특히 계속 통화대기가 필수인 스마트폰은 더욱 심각하다. 하지만 스마트기기의 고성능화를 멈출 수는 없고 배터리 용량을 늘리는 것도 한계가 있다. 이를 해결하기 위해서 ARM은 Big.LITTLE(이후 “빅.리틀”로 표기)이라 불리는 구조를 고안했다.

핵심은 저전력-저성능 코어(리틀 코어)와 고성능-고전력 코어(빅 코어)를 한 칩에 박아넣어서 나누어 쓰는 것. 대기상태나 낮은 부하의 작업에는 리틀 코어만을 구동시키다가 게임, HD동영상 플레이 등 고부하의 작업이 시작되면 리틀 코어를 끄고 꺼두었던 고성능 코어(빅 코어)를 켜서 실행한다는 아이디어다. 한 종류의 코어들만으로 구성된 칩에 비해 얻어지는 이득은 두 가지로,

  1. 대부분의 사용시간을 점하는 저부하 작업에서의 전력 소모가 줄어들고,
  2. 고성능 코어는 성능향상에 좀 더 집중할 수 있으므로 더 높은 최고 성능을 제공할 수 있다.

이 점들을 ARM(과 삼성)은 이 문서와 이 문서에서 다음 그림들과 같이 설명하고 있다. (현 세대에서 ARM과 삼성은 리틀 코어로 Cortex-A7 아키텍쳐를, 빅 코어로는 Cortex-A15 아키텍쳐를 적용하고 있다.)

Cap 2013-08-04 22-13-06-866
녹색 실선으로 칠해진 부분이 고성능 코어만으로 구성했을 때보다 저부하 상황에서 절감되는 소비전력이다.
Cap 2013-08-04 22-14-00-610
Async Architecture는 단일 종류 코어들만으로 구성된 구조를 뜻한다. 전력관리를 위해 코어별로 서로 다른 전압/클럭 주파수를 적용하게 된다.

단점이라면 (동시사용모드인 MP는 아직 제대로 구현되지 않았으므로) 빅, 리틀 코어들을 동시에 구동할 수는 없어서 OS에 제공되는 코어수에 비해 칩이 더 커진다는 점인데, 삼성은 엑시노스 시리즈에서 리틀 코어들이 빅 코어들의 칩 다이 면적 대비 13% 정도만 차지하므로 큰 부담은 아니라고 밝히고 있다. 또한 빅-리틀 코어간 변환(Migration)이 멈추는 느낌이 들지 않도록 매우 빠르게 이루어져야 하는데, ARM은 20000 사이클, 1GHz 속도에서 0.02초 이내에 마칠 수 있다고 언급하고 있다. 실제 최초로 판매된 빅.리틀 구조의 엑시노스 5 옥타 (엑시노스 5410, 갤럭시S4에 탑재)에서 갑자기 느려지거나 잠깐 멈추는 등의 불만은 찾을 수 없는 점으로 보아 이 점도 잘 보완되어 있다고 생각된다. 사실 이 칩의 실 동작으로부터 추정할 수 있는 문제점들이 더 있긴 한데, 일단 이는 이 글의 후속편에서 다루도록 하겠다.

이론상으로는 칩 다이 면적의 증가를 감수할 수 있다면 구동시간과 성능을 모두 잡아낼 수 있는 매력적인 솔루션이다. ARM은 빅.리틀 구조를 향후 핵심 구조로 삼고 계속 발전시키겠다는 전략을 표방하고 있다.

다만 현실에서 그렇다고 하기에는 아직 문제가 많이 남아있다. 이를 이해하기 위해서 일단 ARM이 이 빅.리틀 구조를 어떻게 구성했는지 알아보자. AMD의 불도저 아키텍쳐처럼 빅-리틀 코어 2개를 각각 붙여서 하나의 모듈로 만드는 방법이 직관적이지만, ARM은 빅 코어들과 리틀 코어들을 각각 클러스터로 묶고, 이를 버스(Cache Coherent Interconnect라 칭한다. 명칭대로 각 클러스터의 L2캐시들을 동일하게 유지하는 것이 역할)로 연결하는 방법을 택했다. 이렇게 함으로서 AMD처럼 완전히 새로운 모듈 시스템을 디자인하지 않고(불도저-파일드라이버 아키텍쳐의 개발지연을 보라.), 각각의 멀티코어 CPU를 통합하는 형식으로 빠르게 개발이 가능했을 것으로 보인다. 또한 리틀 코어와 빅 코어의 숫자가 같을 필요가 없어지는 장점이 있다. (ARM은 제어SW가 너무 복잡해지지 않도록 그 두 숫자가 같기를 권장하고 있기는 하다.) 이를 간단하게 개념화시키면 다음 그림과 같다. (출처)

Cap 2013-08-04 23-11-07-729

 

그리고 리틀-빅 코어간 변환은 세 가지 모드가 있다. 클러스터 변환, CPU별 변환, 그리고 리틀-빅 가리지 않고 모든 코어들을 사용하는 MP모드가 그들인데 이중 MP모드는 아직 제대로 구현되지 않은데다가 빅.리틀 구조의 장점을 대부분 포기하게 되므로 일단 클러스터와 CPU별 변환만을 보자.

클러스터 변환은 단순하게 리틀 코어 클러스터와 빅 코어 클러스터가 몽땅 변환되는 것이다. 즉, 빅.리틀 CPU는 리틀 코어들만 동작하고 있던가 아니면 빅 코어들만 동작하고 있던가 둘 중 하나다. 이렇게 하면 단순히 두 개의 멀티코어CPU 중 하나만 켜서 구동하고 있는 셈이므로 구현이 매우 쉬워진다. 현재 삼성 엑시노스 5410은 이 모드로만 동작한다. 그게 문제인데, 다음 글에서 다루겠다.

CPU별 변환(CPU Migration)은 각 코어들이 자유롭게 리틀-빅, 빅-리틀 변환을 한다. 즉 다음 그림과 같다. (출처는 바로 위 그림과 동일.)

Cap 2013-08-04 23-22-55-521

리틀 코어들 중 부하가 한계치를 넘어서는 하나의 코어만이, 빅 코어 하나를 깨워서 자기 일을 떠넘기는 게 가능한 모드이다. 즉 위 그림처럼 변환이 이루어지고 나면, 저 듀얼-듀얼 빅.리틀 CPU는 리틀 코어 하나(A7 CPU0)와 빅 코어 하나(A15 CPU0)만이 켜져서 동작하는 상태가 된다. 물론 빅 코어가 작업을 끝내고 저부하 상태가 되면 이제 다시 CPU1을 깨워서 넘겨주고 자기는 꺼진다. 이 작업을 OS에서 보면 다음 그림과 같은 형태로 제공된다. (출처)

Cap 2013-08-04 23-28-24-892
이 그림에서는 각 빅-리틀 코어가 1대1로 매칭되는 것처럼 보인다. 이론상으로는 그럴 필요가 없으나, 리눅스에서는 이렇게 여기게 되고 현재 실제 존재하는 칩들은 같은 숫자의 빅-리틀 코어들을 가지므로 실제로도 저렇게 동작하게 된다.

위 그림을 보면, 리틀-빅 코어간 변환 과정에 CPU freq 전환이 표시되어 있다. 바로 여러분들이 윈도 노트북, 데스크탑에서 자주 보는 CPU클럭 전환 기능을 이용하여 리틀-빅 간 변환을 한다. 부하가 걸리면, 리눅스는 리틀 코어의 클럭을 계속 올리게 되는데 빅.리틀 구조에서는 100%이상의 속도로 올릴 수 있도록 지원한다. 즉 100% 이상으로 올릴 때 빅 코어로의 전환이 일어나는 것이다. 빅 코어를 쓰다가 부하가 줄어들어 리눅스가 100% 이하의 클럭으로 내리면 그 때 다시 리틀 코어로 전환하게 되는 구조다. 바로 이런 특성 때문에 CPU Migration은 또한 In-Kernel Switching이라고도 불린다. 리눅스 커널의 컨트롤로 변환이 일어나기 때문이다.

필요한 만큼만 전력 많이 쓰고 뜨거운 빅 코어를 가동시킨다는 점에서 CPU별 변환이 되어야 빅.리틀 구조의 장점, 특히 저전력 특성이 살아난다. 실제로 현재 ARM 개발사들의 개발모임인 Linaro의 문서들에서는 클러스터 변환은 언급도 잘 되지 않고 있다. 또한 CPU별 변환을 하려면 각 코어별 클럭 주파수 조정이 핵심이라는 점을 위 문단에서 확인해볼 수 있다.

그런데… 정작 첫 판매물인 엑시노스 5, 그리고 갤럭시S4는 클러스터 변환만이 가능한 상태다. CPU별 변환이 가능하지 않다른 이야기도 흘러나오고 있다. 사실 엑시노스 5410의 구조상 불가능해 보인다. 그렇다. 현재 발매 중인 갤럭시 S4는 발열도 악명이 높은데, 이는 엑시노스 5 5410의 잘못된 설계가 불러온 것이다. 이 점을 까는 게 다음 글의 주제다. 사실 이 이야기를 하고 싶어서 배경지식으로서 이 글을 작성했다고 보아도 무방하다. 기대하시라.

구글 크롬: 첫인상만 우선 간단히

링크: 구글 크롬 웹 브라우저 페이지

구글이 크롬Chrome이라는 웹 브라우저를 발표했다. 필자로서는 대환영이다. 구글의 웹브라우저이기 때문만은 아니다. 옛날부터 속도로는 KHTML 레이아웃 엔진이 가장 빠르다고 생각했는데, 이걸 애플이 가져다가 팔아먹을만하게 뚝딱뚝딱 잘 안 죽고, 비표준도 좀 나오게 고쳐서 자기네 웹 브라우저 사파리에 탑재했다. 그것이 Webkit 엔진이다. 개인적으로는 윈도용 사파리는 빠르긴 한데 너무 무겁고 해서, Webkit 엔진을 탑재한 윈도용 브라우저 (사파리는 윈도용 애플 Core 라이브러리 위에서 돈다. 그리고 그게 아직 안정성이나 성능에서 그닥… )가 나오길 기대하고 있었는데, 마침 구글이 만들어줬다. 예전에 Swift라는 오픈소스 프로젝트가 있었는데, 길게 가지는 못했다. 구글이라면 어떻게든 계속 업데이트를 할 터이니, 윈도에서도 Webkit 엔진의 제 성능을 풀로 쓸 수 있게 된 것이다.

이틀간 주 브라우저로 써 봤는데, dcinside도 생각보다 잘 돌고 네이버도 잘 써진다. 워드프레스는 매우 빠르게 안정적으로 돈다. 기본적인 기능들의 속도나 안정성 면에서 보면 beta판 수준은 넘어선 것 같다. 아직 세세한 기능들이 좀 부족하긴 한데… 다음과 같으신 분들에게 특히 추천한다.

 

  1. 네이버나 다음 웹툰이 너무 느리게 떠염.
  2. 인터넷에서 사진 갤러리들은 왜 이리 느려염? 화면 뜨고 사진 뜨고 다시 제 자리 잡을 때까지 속터져염.
  3. 블로그들을 빠르게 보고 싶어염.
  4. 저는 구글 서비스들을 많이 이용해염.

 

단점으로는… 우선 RSS 리더나, 광고 차단, 마우스 단축키 등 부가 기능들을 제공하지 않는다. 불여우나 오페라에서 잘 제공해주던 Java Script 세부 설정도 지원해주지 않는다. 있는 것은 팝업 차단 기능 정도? 확장 API를 제공하니, 서드 파티로 제공될 것 같기는 한데… 일단은 정말로 기본적인 브라우저만 있다고 보시면 된다. – 어쩌면 RSS 리더는 구글 리더 쓰시고, AdSense나 타사 광고들도 좀 보시고(광고가 떠도 빠르긴 하다), Java script는 사이트에서 제공하시는대로 좀 쓰세요~ 라는 구글이 이야기하는 듯도 하지만. ㅎㅎㅎ

가장 큰 단점으로는… 크롬 구조의 최대 특징인 멀티 프로세스 구조에서 오는 메모리 사용량이다. 불여우FireFox나 오페라 최신 버전들이 메모리 절감에 노력한 것과는 다르게, 엄청 먹어제낀다. 다음 그림은 딱히 그림이나 플래시 별로 없는 블로그와 커뮤니티 탭이 5개 떠 있는 상황에서의 크롬의 메모리 사용량이다.

저어기 chrome.exe라고 쓰여있는 모든 프로세스들의 메모리 사용량의 합이 크롬 브라우저의 메모리 사용량이다. 최신 OS들의 프로세스가 모두 light-weight화되어서 탭을 새로 띄울 때에는 별 문제가 없는데, 메모리 사용량만큼은 타 브라우저에서 탭 하나에 다른 창으로 모두 띄운 정도로 메모리를 쓴다. 물론, 이는 최적화가 안 되어 있는 beta 버전이므로 앞으로 좀더 나아질 수 있는 부분이다.

크롬의 설계 – 플러그인조차 독자 프로세스로 돌릴 정도로 극단적인 멀티 프로세스화 – 는 구글이 말하는 안정성을 위한 것 외에도 다른 거대한 목적이 있다고 본다. 사실은 이 주제로 쓰고 싶었지만, 밤이 너무 늦었다. 필자도 4시간은 자야지. -_-;; 그건 다음 기회에. 가볍게 단서를 던지자면, 크롬 브라우저는 탭이 창의 맨 상단, 타이틀바에 늘어서는데… 그거? 태스크 바로 안 보이십니까? 

후후후, 다음 글의 제목은 “구글 크롬: 너는 내가 브라우저로 보이니?”가 되겠습니다. 🙂

gmail + Firefox 3.0

필자는 개인적으로 메일이든 RSS 리더건 오프라인 어플리케이션(또는 Rich Client)을 선호했었다. 보안 문제도 있고, 속도도 빠르며 인터페이스가 편한데 굳이 웹으로 처리할 필요가 있나 라는 생각 때문이었다. 이 글도 Windows Live writer로 오프라인에서 작성하고 있는 중이다. 특히나 Java Script는 그 속도가 매우 불편할 정도였다. MS의 Active X 기반은 그 유명한? 보안성 때문에 패스, 그리고 실버라이트 등의 MS 웹 솔루션은 아직 느린 것 같다.

그런데 Firefox 3.0 RC1에서 gmail을 돌려봤더니, 무척 빠르다. -_-;;; 인터페이스도 상당히 개량을 거듭해서 일반적인 기능들만 사용한다면 별 불편함이 없다. IE8도 그렇고, 오페라 9.5도 다들 Java script등의 웹 스크립트 성능 향상에 주력하고 있다고 하니, 언젠가는 나도 웬만하면 웹 어플리케이션을 사용하게 될 지도 모르겠다. 일단 MS live mail로 gmail을 사용하는 건 삽질이 되어버렸다. -_-;

결론? Firefox 3.0 정식판 나오면 꼭 써보시라. 빠르다. ㅎㅎㅎ

역시 웹은 전쟁터인가…

링크: IE7Pro

개인적으로 Firefox의 adblock 기능을 이용하기 위해서 설치하는 부가 소프트웨어이다. 그럭저럭 internet explorer에 널리 알려진 몇몇 기능들을 사용해줄 수 있게 해 주는 프로그램인데, 사실상 광고 차단을 위해서만 사용하고 있다. 플래시 등 무겁지 그지 없는 광고들을 주렁주렁 매달고 있는 한국 웹 페이지들은 플래시만 제한시켜도 2배는 빠르게 뜬다. 사실상 광고 차단 유무에 비하면 브라우저 자체의 속도 차이는 의미가 없을 정도다. 개인적으로는 firefox, opera, IE 모두에 광고 차단을 쓰고 있다. 광고 차단 기능 자체로만 보면 오페라가 가장 최강이라고 생각한다. Content blocker라는 이름인데, 거의 무한정 웹 페이지 내의 객체들을 골라서 차단시켜 버릴 수 있다. 다만 광고 차단 전용은 아니라서 간단히 설정하는 방법은 없다. 잘만 쓰면 막강하지만.

어쨌든간에…

이 IE7Pro는 구글 검색을 기반으로 자기네들 수익사업으로 검색 서비스를 제공하고 있다. 프리웨어로 쓰는만큼 그 정도는 해 주지, 라면서 변경했으나 바로 뜨는 경고 메시지. 구글이 기본 검색 서비스가 아닙니다. from 구글 업데이터. 헉, Sun의 Star Suite 8을 공짜로 쓰려고 구글팩으로 설치해뒀는데, 구글팩의 업데이터 프로그램이 감시하고 있다가 구글을 안 쓰니까 투덜댄 것이다. -_-; 웹, 정말 전장이로구나. ;;;

– 결국 잠깐 IE7Pro의 검색 서비스를 써 주고, 구글로 돌아가야겠다. ;;;

MS Live writer – 웹블로그 라이터 간단 소감.

티스토리 만들었다가 MS live writer에 대해서 봤다. 예전에도 웰블로그글을 오프라인 데스크탑에서 작성해서 포스팅하는 툴들에 대해서는 들어봤는데, (간단히 말해서 워드 문서 작성하듯이 블로그 포스팅을 쓴 다음에 클릭 한번으로 올린다는 이야기.) 다들 셰어웨어라서 포기하고 걍 웹에서 포스팅하고 있었는데, MS에서 공짜로 뿌린다는 소식에 Get.

첫 느낌은 괜찮은 .net 프로그램. 오피스인 MS인만큼 잘 만들었다. 느리고 몇가지 기능들이 부족하다는 이야기는 들리는데, 나로서는 별 문제없이 편하게 쓸 수 있었다. 어차피 나야 텍스트 대부분에 그림 한 두장인데, 웬만한 툴을 써도 별 문제 없을 듯 하지만. ;;

MS의 인터넷에 대한 접근은 변했다. 옛날 같았으면 이 정도 프로그램은 무조건 자사의 live 서비스용으로만 제공했을텐데, 다른 표준 서비스들에 대해서도 쓸 수 있도록 공개한 것을 보면 독점 네트워크는 포기한 듯 하다. 물론 이걸 미끼로 해서 Live space (MS가 제공하는 블로그 서비스)로 오세요~ 하는 광고라고 싫어하는 사람들도 있겠지만, 개인적으로는 표준 규격만 지킨다면 괜찮다고 생각하고, 이 정도 광고라면 누구나 하지 않을까? ^^;

대신 이러한 툴을 따로 제작해서 파는 업체들은 이게 제대로 나오면 망하기가 쉽겠다. 차별화도 힘들고, 이미 다 있는 모듈들을 조금만 뚝딱하면 만들 수 있는 MS에 비해서 개발비도 많이 들 거고. 내 생각에는 blogger.com 같은 곳에 인수되는 수 밖에는 없지 않을까 싶다.

단지 이 프로그램을 통해서 구글과 MS의 인터넷에 대한 접근방식이 잘 드러나서 재미있었다. 구글이라면 뛰어난 웹상 에디터를 제공하는 쪽에 무게를 실을 테니까. MS로서는 윈도의 인터넷용 가치를 올리기 위해서라도 오프라인 에디터를 제공하는 쪽이 유리할 것이고. 어느 쪽이 이길까?

Goolge 메신저, Google Talk.

구글이 메신저를 만들었다. 이름하여 Google Talk. 차별화 포인트는 오픈 프로토콜인 Jabber/XMPP를 이용하고 Voice on IP. VoIP를 지원하여 음청 채팅이 가능한 점. 다른 메신저 – Apple MacOS X의 iChat, 리눅스의 GAIM 등 – 에서도 같이 쓸 수 있다. DB를 장악하려는 네이버와는 달리 구글은 웹 뿐만이 아니라 어플리케이션들 또한 무료 및 오픈 규격으로 선보이면서, 네트워크의 접속을 장악하려 하고 있다. 구글 또한 이윤을 추구하는 회사일 뿐이고, 이러한 “인터넷 접속의 오픈 규격화”는 서비스 품질에 대한 절대적 자신감에서 나오는 것일 것이다. 구글을 무조건 찬양하려는 생각은 없지만, 궁극적으로 소비자는 서비스 품질에 만족하기 마련이고 보면 구글의 접근법에 높은 점수를 줄 수 밖에 없다. 최소한 구글은 선택의 자유를 보장하고 있지 않은가?

아마도 나의 이익과 구글의 이익이 합치하는 한, 나는 계속 구글의 지지자로 남을 것이다.

구글 메신저 아이디는 gmail 아이디를 쓰면 됩니다. 제 아이디는 keonil@지메일닷컴. MSN은 퇴근 후에는 로긴 안 하지만, 이 쪽은 컴을 켜 놓으면 계속 접속해있을 듯 합니다.

– DB, 즉 컨텐츠를 장악하려는 네이버의 전략은 그래서 높게 평가하지 않는다. 구글과 네이버의 차이에 대해서는 나중에 포스팅할 예정.

Avant 브라우저.

자세한 정보와 다운로드: Avant Browser 홈페이지

Firefox의 탭 브라우징과 팝업 차단 기능은 매우 편리하다. 팝업 차단은 몇몇 툴바 등에서도 지원하지만, 10개 넘는 브라우저 창을 띄우다 보면 탭 브라우징이 없는 브라우저는 그 이유만으로도 기피대상이다. 보안 등 수많은 이유로 Firefox를 권하지만 IE 전용 홈피 문제와 함께 역시 속도 면에서 IE가 더 빠른 경우가 많아 이전하기가 그리 녹녹하지 않다.

Avant 브라우저는 IE 엔진을 기반으로 한다. IE의 스킨 및 확장 정도로 생각하면 간단하다. 덕분에 IE와 전혀 차이없게 동작하며, 팝업 차단, 광고 차단, 탭 브라우징이 가능하다. 속도 면에서도 IE에 비해 별 차이가 없다. 특히 광고 차단은 ad나 banner 등의 이름이 들어가 있는 플래시, 그림등을 자동으로 차단하는데, 몇몇 사이트를 수동으로 지정해주면 거의 모든 광고를 로딩하지 않는다. (곧 서핑 속도 향상과 직결된다.~)

따라서 본인처럼 10개 이상의 웹 사이트 창을 열어두는 사람에게는 정말 편리하다. 한글화도 잘 되어 있고, 크기도 작으니 한번씩 깔아보길 바란다.

iPhoto를 PC에서 맛보자 – Picasa

매킨토시에서 가장 인기있는 소프트웨어를 꼽는다면 iPhoto가 아닐까. 디카에서 그림을 앨범처럼 섬네일을 보면서 처리할 수 있는 소프트웨어. 복잡하게 디렉터리 및 파일 이름을 정리하는 작업을 하지 않아도 된다.

ACD See나 다른 프로그램들도 섬네일 기능은 지원하지만, 디렉터리 내에 있는 파일들을 보여주는 것이었고, 느렸다. iPhoto는 필름이라는 범주로 그림들을 묶고, 이들의 섬네일 처리가 빨라서 쾌적하게 그림을 섬네일 브라우징할 수 있다. 거기에 작성 연도, 수정 연도, 이름 순 등 여러가지로 리스팅할 수 있어서 편리하다. 요는, 더이상 그림 관리하는데 디렉터리 구조나 파일 이름 같은 거에 정성들이지 않아도 된다는 것. -_-;

이에 비슷한 프로그램이 윈도우즈용으로 발표되었다. 이름하여 picasa.
왼쪽은 스크린샷.

여기에서 Free Download 가능하다. Google이 인수했다. Hello라는 웹 서비스하고도 엮여 있는데, 쓰는 데 상관은 없다.

스크린샷 사진이 작아서 잘 안 보이는데, 이 프로그램 아직 한글이 깨진다. -_-a;; 그래도 사진 자체를 보면서 작업할 수 있으니 앨범(디렉터리)이나 파일 이름이 깨지는 건 참을 만 하다.

여러 모로 iPhoto 베낀 게 아니냐 하여 논란이 많은데, 이 회사 입장은 iPhoto 발표 전부터 개발해 왔다고 한다. 그런데 문제는 가장 중요한 섬네일 브라우징 UI는 iPhoto 발표 이후 유저들이 “이렇게 해달라,”라는 요구하여 덧붙였다는 것. -_-a;;;; iPhoto에서 가장 중요한 것이 그거 아니던가.

P4 2.66GHz, 512MB Ram의 회사 컴에서는 ACDSee보다 더 매끄럽게 잘 도는데, 과연 P3 1GHz, 384MB Ram의 내 PC에서도 그렇게 돌런지는 모르겠다. 어쨌든, zip 파일 보기 기능이 아니라면 ACD See가 부럽지 않은 그림 관리자.

장점: 빠르다. 그림 찾기 정말 쉽다. 그림 색 보정이 강력하다.
단점: 화면에 많은 도구들이 있어서 실 그림이 표시되는 부분이 비교적 좁다.