플랫폼 64비트 OS가 32비트 OS보다 우수하 다고 생각해서는 안 된다 056 Intel 64(EM64T)나 AMD 64와 같은 64비트 아키텍처를 채택한 CPU가 보급 되자, 윈도우즈나 리눅스에서도 64비트가 이용되는 경우가 많아졌다. 지금 까지 주류였던 32비트



Similar documents
Microsoft PowerPoint - chap01-C언어개요.pptx

Microsoft PowerPoint - chap02-C프로그램시작하기.pptx

이도경, 최덕재 Dokyeong Lee, Deokjai Choi 1. 서론

H3250_Wi-Fi_E.book

Windows 8에서 BioStar 1 설치하기

Microsoft PowerPoint - chap03-변수와데이터형.pptx

[Brochure] KOR_TunA

Microsoft PowerPoint - 02_Linux_Fedora_Core_8_Vmware_Installation [호환 모드]

*2008년1월호진짜

The Pocket Guide to TCP/IP Sockets: C Version

특허청구의 범위 청구항 1 삭제 청구항 2 단일 개의 운영체제를 갖는 클라이언트 단말에 있어서, 제1 운영체제와, 상기 제1 운영체제 하에서 사용되는 파일을 저장하는 메모리; 및 상기 메모리에 저장된 파일을 운영체제 제공장치로 전송하고 상기 메모리를 포맷하며, 상기 운

슬라이드 1

Microsoft PowerPoint 자바-기본문법(Ch2).pptx

Microsoft PowerPoint - chap04-연산자.pptx

Microsoft PowerPoint - chap10-함수의활용.pptx

슬라이드 1

1. auto_ptr 다음프로그램의문제점은무엇인가? void func(void) int *p = new int; cout << " 양수입력 : "; cin >> *p; if (*p <= 0) cout << " 양수를입력해야합니다 " << endl; return; 동적할

JAVA 프로그래밍실습 실습 1) 실습목표 - 메소드개념이해하기 - 매개변수이해하기 - 새메소드만들기 - Math 클래스의기존메소드이용하기 ( ) 문제 - 직사각형모양의땅이있다. 이땅의둘레, 면적과대각

PowerPoint 프레젠테이션

TTA Journal No.157_서체변경.indd

q 이장에서다룰내용 1 객체지향프로그래밍의이해 2 객체지향언어 : 자바 2

Chapter ...

Microsoft Word - windows server 2003 수동설치_non pro support_.doc

SIGIL 완벽입문

예제 2) Test.java class A intvar= 10; void method() class B extends A intvar= 20; 1"); void method() 2"); void method1() public class Test 3"); args) A

152*220

슬라이드 1

JVM 메모리구조

제11장 프로세스와 쓰레드

RHEV 2.2 인증서 만료 확인 및 갱신

wtu05_ÃÖÁ¾

Microsoft 을 열면 깔끔한 사용자 중심의 메뉴 및 레이아웃이 제일 먼저 눈에 띕니다. 또한 은 스마트폰, 테블릿 및 클라우드는 물론 가 설치되어 있지 않은 PC 에서도 사용할 수 있습니다. 따라서 장소와 디바이스에 관계 없이 언제, 어디서나 문서를 확인하고 편집

<4D F736F F F696E74202D20B8AEB4AABDBA20BFC0B7F920C3B3B8AEC7CFB1E22E BC8A3C8AF20B8F0B5E55D>

gnu-lee-oop-kor-lec06-3-chap7

<B1DDC0B6B1E2B0FCB0FAC0CEC5CDB3DDB0B3C0CEC1A4BAB82E687770>

PowerPoint 프레젠테이션

설치 순서 Windows 98 SE/Me/2000/XP 1 PC를 켜고 Windows를 시작합니다. 아직 컴퓨터에 프린터를 연결하지 마십시오. 2 PC에 P-S100 CD-ROM(프 린터 드라이버)을 삽입합니다. 3 설치 프로그램을 시작합니다. q CD-ROM의 PS1

1

PathEye 공식 블로그 다운로드 받으세요!! 지속적으로 업그래이드 됩니다. 여러분의 의견을 주시면 개발에 반영하겠 습니다.

경우 1) 80GB( 원본 ) => 2TB( 복사본 ), 원본 80GB 는 MBR 로디스크초기화하고 NTFS 로포맷한경우 복사본 HDD 도 MBR 로디스크초기화되고 80GB 만큼포맷되고나머지영역 (80GB~ 나머지부분 ) 은할당되지않음 으로나온다. A. Window P

Adobe Flash 취약점 분석 (CVE )

메일서버등록제(SPF) 인증기능적용안내서 (HP-UX - qmail) OS Mail Server SPF 적용모듈 (Perl 기반) 작성기준 HP-UX 11.11i qmail 1.03 spf-filter 년 6 월

PowerPoint Presentation

연구노트

JUNIT 실습및발표

<5BB0EDB3ADB5B55D B3E2B4EBBAF12DB0ED312D312DC1DFB0A32DC0B6C7D5B0FAC7D02D28312E BAF2B9F0B0FA20BFF8C0DAC0C720C7FCBCBA2D D3135B9AEC7D72E687770>

쉽게 풀어쓴 C 프로그래밍

Microsoft PowerPoint - 04-UDP Programming.ppt

PowerPoint Presentation

17장 클래스와 메소드

Microsoft PowerPoint 웹 연동 기술.pptx

Spring Boot/JDBC JdbcTemplate/CRUD 예제

PowerPoint Presentation


특징 찾아보기 열쇠 없이 문을 열 수 있어요! 비밀번호 및 RF카드로도 문을 열 수 있습니다. 또한 비밀번호가 외부인에게 알려질 위험에 대비, 통제번호까지 입력해 둘 수 있어 더욱 안심하고 사용할 수 있습니다. 나만의 비밀번호 및 RF카드를 가질 수 있어요! 다수의 가

메일서버등록제(SPF) 인증기능적용안내서 (AIX - sendmail) OS Mail Server SPF 적용모듈 (Perl 기반) 작성기준 AIX 5.3 sendmail spf-filter 년 6 월

슬라이드 1

4S 1차년도 평가 발표자료

아이콘의 정의 본 사용자 설명서에서는 다음 아이콘을 사용합니다. 참고 참고는 발생할 수 있는 상황에 대처하는 방법을 알려 주거나 다른 기능과 함께 작동하는 방법에 대한 요령을 제공합니다. 상표 Brother 로고는 Brother Industries, Ltd.의 등록 상

0. 들어가기 전

PowerPoint Presentation

JAVA PROGRAMMING 실습 08.다형성

유니티 변수-함수.key

04 Çмú_±â¼ú±â»ç

ThinkVantage Fingerprint Software

Secure Programming Lecture1 : Introduction

C++ Programming

ThisJava ..

쉽게 풀어쓴 C 프로그래밊

내지(교사용) 4-6부

Microsoft Word - src.doc

메일서버등록제(SPF) 인증기능적용안내서 (HP-UX - postfix) OS Mail Server SPF 적용모듈 (Perl 기반) 작성기준 HP-UX 11.11i postfix spf-filter 년 6 월

A Hierarchical Approach to Interactive Motion Editing for Human-like Figures

<4D F736F F F696E74202D2036C0CFC2B05FB0B4C3BCC1F6C7E2C7C1B7CEB1D7B7A1B9D62E707074>

작성자 : 기술지원부 김 삼 수

<4D F736F F F696E74202D203137C0E55FBFACBDC0B9AEC1A6BCD6B7E7BCC72E707074>

* Factory class for query and DML clause creation * tiwe * */ public class JPAQueryFactory implements JPQLQueryFactory private f

PowerPoint Presentation

< FBBE7B0EDB3EBC6AE5FB5F0C6FAC6AEC6D0BDBABFF6B5E5C3EBBEE0C1A128BCF6C1A4292E687770>


Network Programming

09-interface.key

어댑터뷰

<4D F736F F F696E74202D20C1A63038C0E520C5ACB7A1BDBABFCD20B0B4C3BC4928B0ADC0C729205BC8A3C8AF20B8F0B5E55D>

SQL Developer Connect to TimesTen 유니원아이앤씨 DB 기술지원팀 2010 년 07 월 28 일 문서정보 프로젝트명 SQL Developer Connect to TimesTen 서브시스템명 버전 1.0 문서명 작성일 작성자

PowerPoint Presentation

LATEX과 Mendeley를 활용한 문헌 관리 2017년 2월 6일 제1절 서지 관리 프로그램 연구 주제를 찾거나 선행 연구를 조사하는 가장 대표적인 방법이 문헌들을 찾아보는 것이다. 수없이 많은 논문들을 찾게 되고, 이런 논문들을 다운로드한 후 체계적으로 관리할 필

MySQL-.. 1


PowerPoint 프레젠테이션

Spring Boot

Cluster management software

PowerPoint Presentation

Design Issues


810 & 는 소기업 및 지사 애 플리케이션용으로 설계되었으며, 독립 실행형 장치로 구성하거 나 HA(고가용성)로 구성할 수 있습니다. 810은 표준 운영 체제를 실행하는 범용 서버에 비해 가격 프리미엄이 거의 또는 전혀 없기 때문에 화이트박스 장벽 을

Level 학습 성과 내용 1수준 (이해) 1. 기본적인 Unix 이용법(명령어 또는 tool 활용)을 습득한다. 2. Unix 운영체계 설치을 익힌다. 모듈 학습성과 2수준 (응용) 1. Unix 가상화 및 이중화 개념을 이해한다. 2. 하드디스크의 논리적 구성 능력

Microsoft PowerPoint - java1-lab5-ImageProcessorTestOOP.pptx

ActFax 4.31 Local Privilege Escalation Exploit

Microsoft PowerPoint - Java7.pptx

Transcription:

3장 구축 및 테스트 Tim O Reilly가 말하는 웹2.0에 대해서도 마찬가지입니다. Tim O Reilly는 웹 진화 과정을 개념적으로 명확히 함으로써 웹 진화를 촉진시켰습니다. 웹2.0이 란 말이 널리 퍼지기 시작하면서 웹이나 업계 전체가 활기차게 된 것은 틀림 없습니다. 웹2.0이 해 준 역할이 상당히 큽니다. 타인에게 설명하기는 어렵지만, 커뮤니케이션을 하기 위해 필요한 개념에 대 해 이름을 붙입니다. 그렇게 함으로써 커뮤니케이션이 원활하게 되고, 막연하 기만 했던 개념이 인식되는 형태 가 되어 보급됩니다. IT 아키텍트라는 말도 아작스나 웹2.0처럼 시스템 개발을 원활하게 하고, IT의 질을 향상시키기 위한 요소로서 필요한 개념입니다.

플랫폼 64비트 OS가 32비트 OS보다 우수하 다고 생각해서는 안 된다 056 Intel 64(EM64T)나 AMD 64와 같은 64비트 아키텍처를 채택한 CPU가 보급 되자, 윈도우즈나 리눅스에서도 64비트가 이용되는 경우가 많아졌다. 지금 까지 주류였던 32비트 아키텍처와 비교해 보면, 한 번에 연산할 수 있는 비 트 수가 증가되어 성능을 올릴 수 있기 때문에, 64비트 OS를 사용하고 있는 것 같다. 사실, 동작하는 어플리케이션이 32비트임에도 불구하고 64비트 OS 를 채택하는 경우를 본 적이 있다. CPU가 64비트 아키텍처니까 64비트 OS 를 선택하는 것이 베스트라고 단순하게 생각해서는 안 된다. 32비트 바이너리를 64비트 OS에서 동작시켜도 그다지 혜택은 없다 OS는 구축하고자 하는 서버의 하드웨어 스펙과 동작하는 소프트웨어의 특성 을 보고 선택해야 하며, 64비트 OS를 고집할 필요는 없다. Intel 64나 AMD 64는 64비트 모드이지만, 32비트 명령세트로도 처리 성능을 떨어뜨리지 않 고 실행할 수 있는 모드가 하드웨어 레벨에서 준비되어 있다. 그래서 32비트 OS도 64비트 OS도 동작할 수 있다. 또, 64비트 OS에서 32비트 어플리케이 션을 동작시킬 수도 있지만, 32비트 어플리케이션은 OS가 64비트여도 64비 트 모드의 혜택은 받을 수 없다. 튜닝은 현상이 나타내는 메시지를 주의 깊게 파악하여 그 근본 원인을 해결하는 작업이라 고 할 수 있다. 절대 단순히 현상 하나만 파악하여 일시적으로 부분적인 결론을 도출해서 는 안 된다. 078 현상만 보고 튜닝을 서둘러서는 안 된다 64비트 모드는 레지스터를 이용하여 어플리케이션을 고속화할 수 있다. 단, 64비트 어플리케이션으로 컴파일이 되어 있어야 한다. 기존의 32비트 바이 너리를 이용하는 어플리케이션은 64비트 OS에서 동작시켜 보았자 혜택은 3장 _ 구축 및 테스트 191

없다. 어플리케이션에 따라서는 64비트 OS에서 제대로 동작되지 않은 경우 도 있다. 프로그램 사이즈가 커진다 32비트 OS와 64비트 OS를 메모리 이용 관점에서 비교해 보자(그림 3-1). 그림 3-1 OS와 어플리케이션의 선택 64비트 OS를 이용하는 가장 큰 장점은 메모리 제약을 받지 않는다는 점이 다. 32비트 OS에서는 일반적으로 4GB(기가 바이트)까지의 물리 메모리밖에 취급할 수가 없다(32비트로 지정할 수 있는 메모리 주소가 2의 32승 = 4GB 이므로). 한편, 64비트 OS의 경우는 논리적으로 약 1678만 TB(테라 바이트) 의 메모리 공간을 사용할 수 있다. 실제 하드웨어 제약상 이보다는 훨씬 작 은 사이즈지만, 그렇다고 해도 TB(테라 바이트) 사이즈의 메모리를 이용할 수 있다. 가상 기억의 메모리 주소는 가상 주소로 관리된다. 32비트 OS에서는 가상 메모리의 주소도 32비트로 제한된다(32비트 윈도우즈의 경우 절반을 OS에 할당하기 때문에, 어플리케이션은 2GB밖에 이용할 수 없다). 64비트 OS에 서는 이 제약이 해소된다. 지금까지의 설명으로는, 64비트 OS를 이용하는 편이 좋다고 생각될지도 모 른다. 다만, 문제는 메모리의 데이터 양이다. 64비트 어플리케이션을 실행 시키면 주소를 보관하기 위한 포인터의 사이즈가 두 배가 되고, CPU의 명령 코드 사이즈도 커진다. 그래서, 프로그램의 바이너리 사이즈가 커진다. 프로그램을 실행할 때 바이너리를 메모리에 전개하는 경우도 32비트보다 많 은 용량이 필요하고, 캐시의 히트율도 떨어진다. RDBMS와 같이, 취급하는 데이터 사이즈가 큰 어플리케이션은 32비트 어플 리케이션보다 64비트 어플리케이션이 데이터 파일(보존용)의 사이즈가 커진 다는 것도 주의할 점이다. 조작해야 할 파일이 크기 때문에, 파일에서 데이 터를 검색할 때 성능이 좋지 않다. 어플리케이션이 이용하는 메모리의 최대 용량이 32비트 OS의 가상 메모리 가 이용할 수 있는 최대 사이즈를 넘지 않으면, 32비트 OS에서 32비트 어플 리케이션을 이용하는 편이 처리 성능을 높일 수 있다. 64비트 OS에 집착할 필요는 없다. 더욱 더 중요한 것은, 하나의 프로세스가 취급할 수 있는 메모리 공간의 사 이즈다. OS는 실제 탑재되어 있는 물리 메모리보다 많은 메모리 공간을 논 리적으로 이용할 수 있도록 가상 기억 구조를 갖고 있다. 192 3장 _ 구축 및 테스트 193

소스코드 기호 링크를 조심성 없이 이용해서는 안 된다 057 복사(copy)와 이동(move)에 따라 생성되는 파일이 다르다 기호 링크는 데이터와는 무관하게 파일의 외형만 링크되기 때문에 프로그램 에서 링크된 파일명을 지정하게 되면 원본 파일과 똑같이 취급할 수 있다. 그러나, 링크된 파일명 자체를 이용하여 처리할 경우에는 원본 파일처럼 사 용하면 문제가 발생하므로 주의가 필요하다. 1 다시 말하면, 파일의 이동(mv), 복사(cp) 등의 조작이나 파일의 아카이브 시스템에 산재한 설정 파일을 한 곳에 모아 관리 효율을 높이고 싶을 때가 있 다. 유닉스계 OS에는 파일을 닉네임으로 참조하는 기호 링크 기능이 있어, 이것을 이용하여 관리 효율을 높일 수 있다. 링크할 실제 파일과 기호 링크는 동등하게 취급되므로, 어느 쪽으로 링크해 도 괜찮다고 생각할지도 모른다. 그러나, 그렇지 않다. (tar) 처리 등이다. 링크에는 하드 링크와 기호 링크가 있다. 유닉스계 OS의 파일시스템은 하나 의 파일에 여러 개의 파일명을 붙일 수 있다. 즉, 하나의 파일에 여러 개의 이름을 붙이는 처리가 하드 링크다. 하드 링크의 경우 여러 개의 파일명의 내용이 모두 똑같다. 이에 반해 기호 링크는 닉네임을 붙이는 것에 해당하며, 기호 링크를 하게 되면 파일의 외형만 링크되고, 링크된 파일명과 파일이 존재한 패스가 보관 된다. 즉, 보관된 파일명과 패스 정보를 기반으로 링크를 한다. 2개의 파일명으로 동일한 파일에 접근해야 할 경우에는 하드 링크를 이용하 그림 3-2 cp커맨드와 mv커맨드의 차이 는 편이 좋다. 다만, 하드 링크는 디바이스나 파티션이 다르면 링크할 수 없 다. 또, 대부분의 파일시스템이 디렉토리 하드 링크를 쉽게 작성할 수 없다. 그래서 기호 링크가 많이 사용된다. 1 파일을 저장하면 하드디스크의 어딘가에 저장한 파일의 내용이 기록된다. 그리고 하드디스크에 기록된 정보를 헤더에 저장한다. 즉, 헤더에 있는 위치 정보만을 갖고 있기 때문에 파일을 호출하면 호출한 파일이 갖고 있는 위치 정보를 이용하여 하드에서 내용을 찾아 사용하게 된다. 하드 링크는 이 위치 정보를 갖고 있는 이름을 여러 개 생성한다고 생각하면 된다. 그래서 하나를 지우더라도 하드에서 내용을 찾아 갈 수 있다. 하지만 기호 링크는 위치 정보를 갖고 있는 파일명을 또 한번 다른 이름으로 연결시키고 있기 때문에 원본 파일을 삭제하면 기호 링크 파일들은 위치 정보가 없어져서 무용지물이 된다. 194 3장 _ 구축 및 테스트 195

원본 파일로 기호 링크 파일을 덮어 썼을 경우 복사 커맨드(cp)와 이동 커맨 드(mv)의 결과는 다르다. 그림 3-2처럼 커맨드를 실행하면 cp 커맨드는 참 조할 원본 파일이 갱신되는데 반해, mv 커맨드는 기호 링크에 덮어 써진다. 기호 링크는 읽기 전용으로 사용한다 커맨드 실행 결과의 차이를 의식하지 않기 위해서는 기호 링크는 읽기 전용 으로만 사용하고, 변경이 필요하면 원본 파일을 변경한다는 방침을 세워야 한다. xxx app1 여러 디렉토리에 산재되어 있는 설정 파일을 효율적으로 갱신하기 위해, 하 나의 디렉토리 안에 모아 놓는다(그림 3-3). 기호 링크를 이용한 파일 조작 은 피한다는 방침에 따라 편집을 하기 위해 설정 파일을 모아 놓은 디렉토리 (그림 3-3에서는 ext )에 원본 파일을 넣고, 원본 파일에 기호 링크를 한다. 이렇게 하면, 설정 파일을 모아 놓은 디렉토리 안에 원본 파일들이 모이기 때문에 파일 조작은 신경 쓰지 않아도 된다. 또 한 가지, 기호 링크를 이용하는 데 있어 주의해야 할 점은 기호 링크의 지 연 평가 1 성질이다. 기호 링크를 작성한 시점에 링크한 파일이 존재했다고, 그 파일이 계속 존재한다고는 할 수 없다. 파일이 삭제되어, 이른바 링크가 끊어진 상태가 될 수 있다. 즉, 파일이 존재해도 다른 실체의 파일일지도 모 른다. lib product etc a.conf - /xxx/etc/a.conf app2 b.conf - /xxx/etc/b.conf etc file1.conf - /xxx/etc/a.conf ext 설정 파일을 모아놓은 디렉토리 a.conf b.conf 설정을 변경할 때 편집 대상은 항상 원본 파일 file1.conf 그림 3-3 기호 링크를 이용한 설정 파일 1 지연평가: lazy evaluation으로 진짜 필요해 질 때까지 미루는 것 196 3장 _ 구축 및 테스트 197

소스코드 여러 가지의 OS를 이용할 때는 개행 코드를 무시해서는 안 된다 058 유닉스계의 OS로 구축된 시스템은 주로 여러 종류의 OS를 사용한다. 서비 스를 제공하는 서버가 유닉스계 OS로 통일되어 있어도, 관리용 단말이나 개 발용 단말 OS는 윈도우즈가 많다. 다른 종류의 OS로 작업할 때 조심해야 할 것 중의 하나가, OS간의 개행 코드의 차이다. 개행 코드는 유닉스계 OS에 서는 LF, 윈도우즈에서는 CR+LF 다(CR: Carriage Return(0x0A), LF: Line Feed(0x0D)). 단말과 단말 사이에 파일을 전송할 때 쉘 스크립트나 펄 스크립트를 텍스트 파일 그대로 전송하고 있을 것이다. 그러나, 스크립트는 가독성이 있는 텍스 트 형식으로 기재되기는 하지만, 프로그램이 번역되어 실행되기 때문에 개행 코드가 다르면 실행되지 않는 것이 있다. 그림 3-4 전송 모드의 설정 오류 파일 전송은 전송용 프로토콜인 FTP나 SCP를 주로 이용하지만, 이러한 프 로토콜에 대응한 클라이언트 툴의 대부분은 ASCII 전송 모드 와 바이너리 전송 모드 이 두 종류의 전송 방식을 제공한다. 윈도우즈에서 동작하는 클라이언트는 파일 확장자에 따라 모드를 바꿔서 구 축해야 하는 경우가 많기 때문에 주의해야 한다. README.txt 라는 파일은 개행 코드가 변환되어 전송되고, README 파일은 변환되지 않고 전송된 적이 있었다. README 파일처럼 텍스트 파일 이라면 그렇게 심각할 정도는 아니지만, 스크립트 파일의 경우는 개행 코드 가 다르면 실행할 수 없는 사태가 발생한다. 확장자에 따라 전송 모드를 변경한다 파일 전송 툴 안에는 텍스트 형식 파일의 개행 코드를 자동으로 번역하는 기 능을 갖고 있기 때문에, 텍스트 파일을 그대로 전송하려면 주의가 필요하다. 실제로, 개발 환경의 유닉스계 OS머신에서 작성하고 시험까지 통과했는데 도, 윈도우즈 경유로 실제 환경에 전송하여 동작을 확인하려고 하자 개행 코 드가 바뀌어서 실행할 수가 없었다(그림 3-4). FTP나 SCP의 ASCII 전송 모드로 파일을 전송했을 때는, 전송 후에 파일의 개행 코드가 의도한 대로 되어 있는지 항상 확인해야 한다. 개행 코드의 영향을 받지 않는 전자 메일 전자 메일에 첨부해서 서로 다른 OS간에 파일을 송수신할 경우, 기본적으로 첨부 파일은 바이너리 형식으로 송부되고 OS의 개행 코드의 영향은 받지 않 는다. 메일의 첨부 파일은 메일 전송 프로토콜 SMTP 로 첨부 파일을 취급하기 위해, 확장 규격인 MIME으로 전송되기 때문이다. 198 3장 _ 구축 및 테스트 199

SMTP에서는 기본적으로 7비트 이하의 코드만을 취급하는 제약이 있기 때문 에, MIME 인코드로 바이너리 파일을 일단 7비트 이내의 ASCII 코드로 변 경해서 송부한다. 수신 측은 송부된 내용을 디코드해서 바이너리 데이터로 복원한다. MIME은 첨부 파일의 종류를 나타내기 위한 Content-Type에 텍스트 파일 임을 나타내는 text 를 지정할 수도 있지만, 메일러(이메일의 송수신 기능 을 수행하는 프로그램)로 Content-Type을 해석한다. 개행 코드를 변환하 는지 알 수는 없지만, 변환 처리가 생길 수도 있으므로 전혀 없다고 단언할 수 없다. 이와 같이 전송에 이용하는 툴로 인해 개행 코드가 변경되는 위험이 존재한 다. 개행 코드가 변경되는 위험을 회피하기 위해 파일을 작성한 기기에서 tar 나 zip 커맨드로 전송 대상 파일을 압축하여 바이너리 파일로 전송하고, 전송 대상 기기에서 해제하는 것을 룰로 정하면 개행 코드까지 확실하게 전해 줄 수 있게 된다. 하여 송신 측에서 변환할지, 수신 측에서 변환할지 정해 두어야 한다. 로그 출력은 바이트 코드를 많이 사용하지 않고, ASCII 코드만으로 설계하는 것 도 좋은 방법이다. 소스코드는 형상관리 소프트웨어로 관리할 때 문제가 생기기 쉽다. 개발 기 기의 OS 종별에 따라 문자 코드가 다른 상태로 저장되는 사태는 가능한 피 해야 한다. 통합 개발 환경에 따라서는 저장 장소에서 소스코드를 취득한 시 점에 자동적으로 문자 코드나 개행 코드가 환경에 맞춰 변경될 때가 있다. 자동으로 변환되고 있는 것도 모르고, 변환된 채로 저장해 버리면 통합 개발 환경 이외에서는 빌드할 수 없는 사태가 발생할 수도 있기 때문에 특히 주의 가 필요하다. 로그 파일이나 소스코드에도 요주의 여러 종류의 OS가 혼재하는 시스템을 개발할 때는 문자 코드도 주의해야 한 다. UI는 물론이고 네트워크로 교환하는 데이터 내용까지, 데이터베이스를 설계할 때는 문자 코드가 가장 신경이 쓰이는 부분이다. 반면, 로그나 소스코드의 설계는 소홀해지기 십상이다. 프로그램의 보수성 측면에서 로그나 소스코드도 명확하게 규정해야 한다. 로그를 출력할 때 로컬의 로그 파일에는 OS 내에서 사용할 수 있는 문자 코 드로 출력하기 때문에 그다지 문제가 되지 않지만, 로그를 모아 놓는 서버의 경우에는 문제가 된다. 로그를 송신한 곳, 혹은 로그 서버를 수신한 곳에서 문자 코드의 변환 처리가 필요하기 때문에, 대응하고 있는 문자 코드를 조사 200 3장 _ 구축 및 테스트 201

소스코드 정의된 것 이외의 것을 가볍게 보아서는 안 된다 상세 설계나 프로그램 개발에 정의되어 있지 않은 미지 상태 에 대해 사전 에 고려를 해 놓으면, 트러블 발생을 미리 막을 수 있다. 설계나 구축 시점에 서는 있을 수 없는 일일지도 모르나, 횟수를 거듭할 수록 상황이 바뀌어 일 어날 수 있기 때문이다. 미리 정의를 해 두는 것이 중요하다. 059 예를 들면, 메소드나 함수의 파라미터는 state 변수고, 외부에서 100이나 200 이외의 상태, 예를 들어 state에 500이 지정되면 state가 200일 때 처리되어야 할 Y처리를 하게 되어 테이블 B가 갱신되게 된다. 또, 300이 추가되면 Z처리(테이블 C의 갱신)를 한다 는 사양 추가가 생겼다 고 하자. 이 때 다른 소스 코드는 전부 수정했는데, 리스트 3-1만 수정하는 것을 깜박 잊었다면 300에서도 Y처리를 하게 되어 테이블 B가 잘못 갱신되 게 된다. 리스트 3-1 state가 100, 200 이외를 고려하지 않는 구축의 예 if( state == 100 ){ // state 가 100 의 경우 X 처리 ( 테이블 A 의 갱신 처리 ) else{ // 그 이외의 경우 Y 처리 ( 테이블 B 의 갱신 처리 ) 미지 상태를 고려하지 않아 오류가 발생 미지 상태란 요구 사양에 기록되지 않은 상태를 말한다. 예를 들면, 다음의 요구 사양이 있었다고 하자. 상태 state 가 100이면 X처리(테이블 A의 갱신)를 하고, 200이면 Y처리(테이블 B의 갱신)를 한다. 이 요구 사양에는 상태가 100도 200도 아닌 그 이외의 경우에 대해서는 어떻 게 취급해야 할 지 기록되지 않았다. 설계자나 프로그래머가 이 요구 사양을 100과 200 이외의 상태는 고려하지 않아도 된다 라고 생각했다면 리스트 3-1과 같이 구축했을 것이다. 리스트 3-1은 100 이외는 모두 200으로 간주한 것이다. 요구 사양을 만족하 고는 있지만, 100이나 200 이외의 상태에 대해서는 고려하고 있지 않기 때문 에, 다음과 같은 트러블이 발생할 가능성이 높다. 이렇게, 누락이나 오류에 의한 버그는 생각 외로 많다. 그리고 이러한 버그 는 늦게 발견될 가능성이 높기 때문에, 설계자나 프로그래머는 정의되지 않 은 것까지도 빠트리지 않도록 주의해야 한다. 설계자는 정의되지 않은 것에 대해 어떻게 처리해야 할지 설계서에 명기해 주어야 한다. 그리고, 프로그래 머는 그 이외의 경우는? 이라고 하는 의문을 갖고 구축하는 습관이 필요하 다. 정의되지 않은 상태를 고려하여 구축했을 때는 리스트 3-2와 같다. 리스트 3-2 state가 100, 200 이외를 고려한 구축의 예 if( state == 100 ){ // state 가 100 의 경우 X 처리 else if( state == 200 ){ // state 가 200 의 경우 Y 처리 else { // 정의되지 않는 state 의 경우 에러 ( 예를 들면, 예외를 발생시킨다 ) 202 3장 _ 구축 및 테스트 203

소스코드 공개 기능 클래스의 인스턴스를 직접 생성해서는 안 된다 060 그리고 나서, 인터페이스 Supplier의 구축 클래스(SupplierA)의 인스턴스로 제공된 dosomething 메소드를 이용하고 있다(리스트 3-3 ). 그런데, 이 구축에는 아무런 문제가 없는 것처럼 보인다. 그러나, 새로운 SupplierB 클래스가 추가되어 인스턴스의 생성 대상 클래스가 SupplierA에 서 SupplierB로 무조건(혹은 특정 조건에서) 바뀐다면 어떻게 될까? SupplierA에서 SupplierB로 바뀐 경우는 의 부분을 다음과 같이 수정하게 일반적으로 자바로 클래스의 인스턴스를 생성하려면 리스트 3-3과 같이 구 축한다. 여기서 Supplier는 공개 기능을 제공하는 인터페이스이고, SupplierA는 구축할 클래스, User는 공개 기능 클래스를 이용하는 클래스다. User 클래스는 Supplier 인터페이스가 제공하는 공개 기능을 이용하기 위해 SupplierA에 new 연산자를 이용하여 인스턴스를 생성하고 있다(리스트 3-3 ). 리스트 3-3 인스턴스를 생성하는 자바 코드의 예 [Supplier.java] public interface Supplier { void dosomething(); [SupplierA.java] pulibc class SupplierA implements Supplier { public void dosomething(){ [User.java] public class User { private Supplier supplier; public void process(){ // SupplierA 의 인스턴스를 생성 Supplier supplier = new SupplierA(); // Supplier 의 dosomething 기능을 이용한다 supplier.dosomething(); 된다. // SupplierB 의 인스턴스를 생성 Supplier supplier = new SupplierB(); 일반적으로 공개된 공통 기능은 다양한 클래스에서 이용된다. 만약, Supplier 의 공통 기능을 이용하는 클래스가 User 이외에도 있었다고 하면, 그것들에 대해서도 똑같이 수정이 필요하다. 리스트 3-3에 나타낸 코드에서 문제점은, 공통 기능을 이용하는 User 클래 스가 직접 구축 클래스의 인스턴스를 생성하고 있는 점이다. User 클래스는 인터페이스 Supplier가 제공하는 공통 기능을 이용하고 싶은 것뿐이며, 인터 페이스 Supplier의 구축 클래스인 SupplierA나 SupplierB에 의존하고 싶지 않다. 공통 기능을 제공하는 측은 구축 클래스에 의존하지 않고 공통 기능을 이용할 수 있도록 배려해야 한다. Factory Method로 간접화한다 이 과제를 해결하려면 Factory Method라는 디자인 패턴을 이용하면 좋다. Factory Method란 오브젝트의 생성을 맡고 있는 메소드 factory method 를 이용 하여 간접적으로 오브젝트를 생성하는 방법을 말한다. 개별적으로 인스턴스 를 생성하지 말고 인터페이스를 이용하여 클래스의 인스턴스를 생성할 수 있 도록 메소드를 준비한다. 204 3장 _ 구축 및 테스트 205

리스트 3-4의 구축 예를 보자. SupplierFactory 클래스로 인스턴스를 생성하 는 클래스 메소드 createsupplier를 준비했다. User 클래스는 클래스의 인스 턴스를 직접 생성하는 것이 아니고 createsupplier를 이용하여 인스턴스를 생 성한다. 인스턴스의 생성을 SupplierFactory 클래스에 맡긴다는 얘기이다. 리스트 3-4 Factory Method의 구축 예 소스코드 거대한 정수 클래스를 만들어서는 안 된다 061 [SupplierFactory.java] public class SupplierFactory { public static Supplier createsupplier(){ // Supplier 의 구축 클래스의 인스턴스를 생성하여 돌려준다 [User.java] public class User { public void process(){ Supplier supplier = SupplierFactory.createSupplier(); supplier.dosomething(); 정수의 정의는 정수 클래스(정수 정의 클래스)에 모여 있다. 자바나 C++은 리스트 3-5와 같이 정수 클래스를 구축한다. 리스트 3-5 정수 클래스의 구축 예 Java 의 경우 public class Construct { public static final int MY_CODE = 100; C++ 의 경우 class Construct { public static const int MY_CODE = 100; 정수 클래스에 정수를 정의하려면, 정적 변수를 나타내는 static 수식자를 붙 이거나 final(c++의 경우는 const) 수식자로 고정 변수라고 정의한다. 정수 클래스에 대한 지침은 대부분 어플리케이션 개발 지침 등에 간결하게 기록되어 있다. 그런데, 대규모 프로젝트임에도 불구하고 역할이나 목적에 따른 정수 클래스에 대한 방침이 없을 때가 있다. 정수가 여기 저기 분산되 지 않도록 정수 전용 클래스를 준비한다는 식의 기록이 있으면, 하나의 정수 클래스에 모든 정수 정의가 집중되어 거대한 정수 클래스가 완성된다. 206 3장 _ 구축 및 테스트 207

일반적으로, 프로그래머가 필요로 하는 정수는 1개 내지 기껏해야 몇 개 정 도다. 프로그래머가 리스트 3-6과 같이 거대한 정수 클래스에서 필요한 정 수를 찾아야 한다고 상상해 보기 바란다. 리스트 3-6 거대한 정수 클래스의 예 Java 의 경우 public class Construct { /** 처리 결과 코드 : 대상 없음 */ public static final int NOT_FOUND = -1; /** 처리 결과 코드 : 정상 */ public static final int SUCCESS = 0; /** 응답 메시지 : 변경 없음 */ public static final String NOT_CNANGE = "Not change."; /** 응답 메시지 : 변경 있음 */ public static final String UPDATED = "Updated."; /** 처리 옵션 : 일반 */ public static final int NORMAL_OPT = 100; /** 처리 옵션 : 확장 */ public static final int SPECIAL_OPT = 101; ( 이하, 다양한 정수의 정의가 끝없이 계속된다 ) 프로그래머는 개발 지원 툴로 오로지 IDE(통합 개발 환경)를 이용하고 있다. IDE에는 프로그래밍을 효율적으로 할 수 있도록 코드 보조 기능(입력 보완 혹은 입력 후보를 제시하는 기능)을 갖추고 있다. 그런데, 정수 클래스가 거 대하다면 코드 보조 기능으로 많은 입력 후보들이 표시된다. 그 중에서 적절 한 정수를 선택하기란 너무 어렵고 작업 효율 또한 크게 떨어진다. 앞에서 말한 거대한 정수 클래스는 처리 결과 코드, 응답 메시지, 처리 옵션 등과 같이 분류하면 된다. 가령, 고객 구분 등 코드 분류마다 독립된 정수 클래스를 작성하는 방침이 있었다면, 필요한 정수 클래스를 설계서에서 모두 찾아 내어 자동 생성하는 툴을 만드는 것이 좋다. 대규모 프로젝트라면 설계서에서 자동으로 정수 클 래스를 생성해 주면 가장 알기 쉽고, 정착하기 쉽다. 정수 클래스의 작성과 더불어 클래스의 이름이나 정수 이름의 네이밍도 중요 하다. 어떤 분류 기준으로 정수 클래스를 분할했다고 하더라도, 각 정수 클 래스에 어떤 정수가 모여 있는지 클래스명으로 예측할 수 없다면 클래스를 분할한 의미가 희미해진다. 분할에 관한 지침(가이드라인)을 조기에 수립한다 적절한 사이즈가 되도록 정수 클래스를 분할하는 작업을 시스템을 구축하는 도중에 하는 것은 바람직하지 못하다. 프로젝트 멤버의 혼란을 가중시키기 때문이다. 정수 클래스의 분할 지침은 설계 공정 초기에 결정하는 것이 바람직하다. 늦 어도 구축 공정에 들어가기 전까지는 수립해야 한다. 방침을 결정하면 어플 리케이션 개발 지침 등에 명기해서, 프로젝트 멤버에게 주지시켜야 한다. 정수 클래스를 분할하는 네이밍도 중요하다 본래 정수 클래스를 마련하는 목적은 다양한 정수를 정수 클래스에 정리하는 것에 있다. 혼재된 상태의 거대한 정수 클래스는 본래의 모습이 아니다. 정수 클래스는 기능이나 목적에 맞게 적절한 사이즈가 되도록 분할해야 한다. 208 3장 _ 구축 및 테스트 209

소스코드 분량이 많은 코딩 규칙을 만들어서는 안 된다 코딩 규칙은 프로젝트 멤버에게 프로그래밍 룰을 알려 주기 위해 작성하는 문서다. 일반적으로 소프트웨어 아키텍트가 정리한다. 코딩 규칙이 너무 많 으면 프로그래머가 그 모든 것을 이해할 수 없게 되어, 결국 준수되지 못하 게 되므로 주의가 필요하다. 실제 상황에 맞춰 기존의 규칙을 수정한다 코딩 규칙 작성은 귀찮고 노력이 많이 드는 작업이다. 프로젝트마다 새로 작 성할 필요는 없다. 다른 프로젝트에서 사용되고 있는 기존의 코딩 규칙을 기 본으로, 사용하는 플랫폼이나 개발 언어에 맞춰 수정하면 된다. 코딩 규칙에 기술하는 항목은 일반적으로는 코딩 스타일이나 코멘트 서식, 식별자의 네이밍, 프로그래밍의 금지 사항, 관례나 팁들, 이 4가지다. 이 중, 코딩 스타일이나 코멘트 서식과 식별자 네이밍 규약을 제정하는 목적 은 소스코드의 가독성 향상에 있다. 소스코드의 가독성이 높으면 프로그램 을 작성한 당사자, 리뷰 담당자 모두 버그를 찾아내기 쉽다. 또, 가독성이 높 으면 다른 프로그래머가 유지보수 할 때 작업 효율이 높아진다. 프로그래밍 의 제약 사항을 적어 놓는 이유는, 프로그래머에 따라 별생각 없이 부적절하 게 코딩을 해 버리는 경우가 있기 때문이다. 프로그래머가 재차 의식을 하면 서 코딩할 수 있도록, 코딩 규칙에서 사용하는 플랫폼이나 개발 언어의 특성 을 고려하여 위험한 내용을 표시한다. 062 관례나 팁들을 나타내는 것은, 알고리즘 등에 따른 차이를 프로그래머에게 인식시켜 처리 효율이 높은 소스코드를 만들기 위해서다(리스트 3-7). 리스트 3-7 관례나 팁들의 기재 예 나쁜 예 루프의 조건식에서 메소드를 호출한다. 성능 문제가 일어나기 쉬워 바람직하지 않다. List list = new ArrayList(); for(int index = 0; index < list.size(); index++){ // 조건부에서 size 메소드를 매회 호출하고 있다! 좋은 예 사전에 size()를 호출, 로컬 변수에 저장하고 나서 그 로컬 변수를 참조한다. List list = new ArrayList(); int size = list.size(); for(int index = 0; index < size; index++){ 필요한 내용을 충분히 알기 쉽게 표시한다 이러한 내용을 모두 포함하게 되면 코딩 규칙의 양이 늘어나서 인쇄했을 때 두꺼워지기 십상이다. 완성도가 높은 코딩 규칙이란 필요한 내용을 충분히 알기 쉽게 나타내야 하지만, 필요 이상으로 상세하고 두꺼운 것은 바람직하 지 않다. 프로그래머가 구축 작업을 할 때는 설계서를 참조하여 IDE(통합 개발 환경) 등의 툴과 서로 대조하게 된다. 코딩 중에 코딩 규칙을 참조할 필요는 없다. 프로그래머가 코딩 규칙을 읽는 것은 구축 작업을 하기 전이어야 하며, 그 때 규칙을 충분히 이해하고 나서 코딩 작업을 해야 한다. 다시 한번 강조하 지만 코딩 규칙이 두꺼우면 전부 기억할 수 없고, 금지 사항 등 중요한 규칙 마저 지킬 수 없게 된다. 그렇게 되면, 어렵게 만들어 놓은 코딩 규칙이 아무 런 의미가 없게 된다. 210 3장 _ 구축 및 테스트 211