DB를 냉장고처럼 쓰자 - 데이터베이스와 냉장고의 공통점

냉장고를 고를때 냉장고 내부 기술에 대한 깊이있는 공부보다 가격, 기능, 브랜드와 같은 요소에 중점을 두는 것처럼, 데이터베이스 관리 시스템(DBMS) 또한 DBMS가 지원하는 SQL 표준, 기능, 평판과 브랜드 등을 선택의 기준으로 삼고 있으며, 도입 비용이 거의 소요되지 않는 오픈 소스 DBMS를 통해서도 기업의 핵심 업무를 충분히 소화할 수 있음을 "DB를 냉장고처럼 쓰자 - 상품화된 DBMS(Commodity DBMS)"에서 다루었습니다.

 

우리의 삶과 깊은 연관성을 가진 냉장고와 데이터베이스, 이 둘 사이에는 어떤 공통점이 있을까? 냉장고와 데이터베이스 사이의 공통점을 통해서 데이터베이스에 대한 이해가 막연하게 "복잡하다, 어렵다"에서 냉장고 처럼 내 바로 옆에 있는 친숙한 도구로 다가왔으면 하는 바램입니다.

■ 기능의 핵심은 안전한 보관

음식을 저온 상태로 장기간 보관할 수 있는 냉장고는 현대인의 삶에 없어서는 안될 존재임에 틀림없습니다. 물론 전기가 공급되지 않는 곳이나 수렵과 채집이 삶의 방식이라면 냉장고가 그리 필요하지 않을 수 있지만 다양한 삶의 방식이 존재하고 음식물의 생산지와 소비지 간의 거리가 멀어지고 유통 경로가 복잡해지며, 기간 조차 길어진 지금의 생활 방식에서 냉장고는 있는듯 없는듯 그 존재 감은 미미하지만 삶의 핵심 요소 임에 틀림없습니다.

 

현대 사회를 정보화 사회가 부르는 기저에는 바로 컴퓨터를 기반으로 하는 "정보"가 있습니다. 그리고 그 정보가 적절하게 생산, 가공, 유통 및 재생산 되는 과정에는 다양한 단계의 데이터베이스가 그 기반 시스템 역할을 담당하고 있습니다. 개인 스마트폰의 주소록에서 부터 은행의 계좌 정보, 교통 정보, 식탁에 오르는 쇠고기 이력 정보까지 삶의 곳곳에 데이터베이스는 있는듯 없는듯 그 존재 감을 잘 드러내지 않지만 정보의 핵심 역할을 수행하고 있습니다.

 

냉장고와 데이터베이스를 접해본 사람이라면 누구나 떠올릴 수 있는 공통점은 바로 기능의 핵심이 내용물의 안전한 보관에 있다는 것입니다. "안전한 보관"이라는 말은 몇십년 땅에 묻어두는 타임캡슐과 같은 보관의 개념이라기 보다는 몇가지 한계점이나 장해 요소로 부터 내용물을 지켜낸다는 의미가 적절할 것입니다.

- 빈번한 사용

냉장고와 데이터베이스 모두 빈번한 사용을 전제로한 보관이라는 공통점이 있습니다. 아이들을 키우다 보면 "냉장고 문좀 그만 열어라!"는 잔소리를 입버릇 처럼 하게되는데, 그만큼 냉장고는 내용물의 들고나는 빈도가 높은 편입니다. 데이터베이스도 마찬가지로 회원제를 기반으로 하는 블로그만 해도 하나의 포스팅 페이지를 보여주기 위해서는 마흔번 이상의 쿼리문을 수행합니다. 이렇게 빈번한 사용에도 불구하고 망가지지 않고 내용물을 안전하게 보관하는것, 이것이 데이터베이스의 핵심 기능입니다. 아래는 블로그 한페이지를 보여주기 위해서 수행되는 쿼리문의 예제입니다.

SET CHARACTER SET utf8 ;

SELECT * FROM spamips WHERE ip = '121.185.222.111';

SET SESSION collation_connection = 'utf8_general_ci';

SELECT name, value FROM tc_ServiceSettings;

SELECT value FROM tc_PageCacheLog WHERE blogid = 1 AND name = 'globalCacheStorage' LIMIT 1;

SELECT id FROM tc_Sessions WHERE id = '1f7b1db546cffffffe5deb1915e48fe7' AND (userid IS NOT NULL OR preexistence IS NOT NULL);

SELECT privilege FROM tc_Sessions WHERE id = '1f7b1db546cffffffe5deb1915e48fe7' AND address = '121.185.222.111' AND updated >= (UNIX_TIMESTAMP() - 3600);

SELECT name FROM tc_Users WHERE userid = 1;

SELECT name, value FROM tc_UserSettings WHERE userid = 1;

SET time_zone = '+09:00';

SELECT value FROM tc_PageCacheLog WHERE blogid = 1 AND name = 'PluginSettings' LIMIT 1;

SELECT CN.*, CNQ.id AS queueId, CNQ.commentid AS commentid, CNQ.sendstatus AS sendstatus, CNQ.checkdate AS checkdate, CNQ.written AS queueWritten FROM tc_CommentsNotifiedQueue AS CNQ LEFT JOIN tc_Comments AS CN ON CNQ.commentid = CN.id WHERE CNQ.sendstatus = 0 and CN.parent is not null ORDER BY CNQ.id ASC LIMIT 1 OFFSET 0 ;

SELECT value FROM tc_PageCacheLog WHERE blogid = 1 AND name = 'skinCache' LIMIT 1 ;

SELECT userid FROM tc_Privileges WHERE blogid = 1 AND acl > 15;

DELETE FROM tc_PageCacheLog WHERE blogid = 1 AND name = 'skinCache' ;

REPLACE INTO tc_PageCacheLog (blogid,name,value) VALUES(1,'skinCache','a:2:{s:4:\"user\";N;s:5:\"owner\";N;}') ;

SELECT COUNT(*) FROM tc_Entries e LEFT JOIN tc_Categories c ON e.blogid = c.blogid AND e.category = c.id WHERE e.blogid = 1 AND e.draft = 0 AND e.category >= 0 ;

SELECT e.*, c.label AS categoryLabel FROM tc_Entries e LEFT JOIN tc_Categories c ON e.blogid = c.blogid AND e.category = c.id WHERE e.blogid = 1 AND e.draft = 0 AND e.category >= 0 ORDER BY e.published DESC LIMIT 1 OFFSET 0 ;

SELECT visits FROM tc_BlogStatistics WHERE blogid = 1 ;

SELECT datemark, visits FROM tc_DailyStatistics WHERE blogid = 1 AND datemark in (20130624,20130623) ;

SELECT * FROM tc_RemoteResponses WHERE blogid = 1 AND entry = 172 AND isfiltered = 0 AND responsetype = 'trackback' ORDER BY written ;

SELECT COUNT(*) FROM tc_Comments WHERE blogid = 1 AND entry = 172 AND parent IS NULL AND isfiltered = 0;

SELECT * FROM tc_Comments WHERE blogid = 1 AND entry = 172 AND parent IS NULL AND isfiltered = 0 ORDER BY written ASC LIMIT 15 OFFSET 0 ;

SELECT t.* FROM tc_Tags t INNER JOIN tc_TagRelations r ON r.blogid = 1 AND r.tag = t.id AND r.entry = 172 AND r.tag = t.id GROUP BY r.tag, t.id, t.name ORDER BY t.name ;

SELECT name FROM tc_Users WHERE userid = 2 ;

SELECT * FROM tc_Categories WHERE blogid = 1 AND id >= 0 ORDER BY parent, priority ;

SELECT title FROM tc_Entries WHERE blogid = 1 AND draft = 0 AND category = -1 ORDER BY char_length(title) DESC ;

SELECT value FROM tc_PageCacheLog WHERE blogid = 1 AND name = 'entry-172-PostsummarizeabsoultePath' LIMIT 1 ;

SELECT name, settings FROM tc_Plugins WHERE blogid = 1 ;

SELECT * FROM tc_DaumView WHERE blogid = 1 AND entryid = 172 ;

SELECT * FROM tc_Entries WHERE blogid = 1 AND id = 172 AND draft = 0 ;

SELECT COUNT(id) FROM tc_Entries e WHERE e.blogid = 1 AND e.draft = 0 AND e.category >= 0 ;

SELECT * FROM tc_Categories WHERE blogid = 1 AND id >= 0 ORDER BY parent, priority ;

SELECT value FROM tc_PageCacheLog WHERE blogid = 1 AND name = 'entry-queryCache-2106475912' LIMIT 1 ;

SELECT t.name, count(*) AS cnt, t.id FROM tc_Tags t, tc_TagRelations r WHERE t.id = r.tag AND r.blogid = 1 GROUP BY r.tag, t.name, t.id ORDER BY RAND() LIMIT 30 ;

SELECT count(r.entry) AS cnt FROM tc_TagRelations r WHERE r.blogid = 1 GROUP BY r.tag ORDER BY cnt DESC LIMIT 1;

SELECT e.id, e.userid, e.title, e.slogan, e.comments, e.published FROM tc_Entries e WHERE e.blogid = 1 AND e.draft = 0 AND e.category >= 0 ORDER BY published DESC LIMIT 5 ;

SELECT name FROM tc_Users WHERE userid = 4 ;

SELECT value FROM tc_PageCacheLog WHERE blogid = 1 AND name = 'comment-queryCache-1019936935' LIMIT 1 ;

SELECT r.*, e.title, e.slogan FROM tc_Comments r INNER JOIN tc_Entries e ON r.blogid = e.blogid AND r.entry = e.id AND e.draft = 0 WHERE r.blogid = 1 AND r.entry>0 AND r.isfiltered = 0 ORDER BY r.written DESC LIMIT 5 ;

DELETE FROM tc_PageCacheLog WHERE blogid = 1 AND name = 'comment-queryCache-1019936935' ;

REPLACE INTO tc_PageCacheLog (blogid,name,value) VALUES(1,'comment-queryCache-1019936935','...');

- 간단한 장애

냉장고와 데이터베이스 모두 간단한 장애는 극복할 수 있어야 한다는 공통점이 있습니다.  잠깐의 정전만으로도 내용물이 모두 상한다면 냉장고를 마음놓고 사용할 수 있는 사람은 한사람도 없을 것입니다. 데이터베이스도 마찬가지로 컴퓨터가 다운되거나 응용 프로그램이 비정상 종료하더라도 데이터베이스는 데이터를 안전하게 보존하고 시스템이 정상 가동되었을때 정상 동작할 수 있어야 합니다. 데이터베이스 없이 파일시스템에 바이너리 파일로 정보를 구조화해서 저장하는 경우에 가장 큰 위험성은 장애시 일부 내용의 오류로 전체 자료의 홰손이라는 결과를 초래할 수도 있다는 것입니다. 데이터베이스 관리 시스템은 이런 상황을 효과적으로 대처하여 자료가 홰손되지 않도록 하는 것입니다. 물론 장애의 규모가 큰 경우는 냉장고나 데이터베이스 모두 대책에는 한계가 있습니다. 냉장고가 침수되거나, 컴퓨터가 물리적으로 파손되는 상황까지 대비하기에는 냉장고나 데이터베이스 만으로는 무리가 있는 법이지요. 그렇지만, 이런 상황에 대처하기 위한 방안의 하나로 스페어 냉장고를 둔다던가, 데이터베이스 복제나 백업을 수행하는 등의 방안을 수립할 수 있을 것입니다.

- 정해진 용량 한계

냉장고와 데이터베이스의 용량은 무한이 아닙니다. 제품별로 스스로가 감당할 수 있는 용량 한계와 낼 수 있는 성능 한계가 있습니다. 냉장고는 넣을 수 있는 내용물의 양을 리터로 표시하고 있고, 데이터베이스는 테이블, 컬럼, 데이터베이스 단위로 최대 크기와 용량 한계를 나타내고 있습니다. 최근의 DBMS들은 대부분 저장 공간의 한계없이 물리적인 저장소 크기 만큼 무한대로 저장소를 수용하는 형태이지만 일부 소규모 데이터베이스는 아직 용량 한계를 명시하고 있습니다. 즉, 데이터베이스를 사용하는 곳의 특성과 향후 데이터의 증가 추이 등을 감안하여 어떤 데이터베이스를 선택할지 전략적인 판단이 필요 합니다. 고가 대용량의 냉장고를 들여놓고는 맥주캔 몇개 보관하는 것도 어리석지만, 독신자용 미니 냉장고로 4인 가족의 일반적 생활에 문제 없을 거라는 기대도 터무니 없다는 것입니다. 다음은 앞서 소개한 데이터베이스들의 한계치를 나열한 것입니다.(http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems 참조)

DBMS	Max DB size	Max table size	Max row size	Max columns per row	Max Blob/Clob size	Max CHAR size	Max NUMBER size	Min DATE value	Max DATE value	Max column name size
CUBRID	2 EB	2 EB	Unlimited	6400	Unlimited	1 GB	64 bits	0001	9999	254
DB2	512 TB	512 TB	32,767	1012	2 GB	32 KB	64 bits	0001	9999	128
Firebird	Unlimited	32 TB	65,536	타입에 따라 다름	2 GB	32,767B	64 bits	100	32768	31
Microsoft SQL Server	512 PB	512 PB	Unlimited	30000	2 GB	2 GB	126 bits	0001	9999	128
Oracle	Unlimited	4 GB * 블럭크기	8 KB	1000	Unlimited	4000B	126 bits	-4712	9999	30
MySQL 5	Unlimited	MyISAM:256TB Innodb:64TB	64 kB	4096	4 GB	64 kB	64 bits	1000	9999	64
PostgreSQL	Unlimited	32 TB	1.6 TB	타입에 따라 다름	1 or 2 GB	1 GB	Unlimited	-4713	5874897	63
SQLite	128 TB	최대 파일 크기	최대 파일 크기	32767	2 GB	2 GB	64 bits	-	-	Unlimited

"안전한 보관"이라는 말을 다른 시각으로 뒤집어 보면 데이터베이스는 조직 전체의 건강과 전략에 핵심 역할을 수행하기 때문에 "안전하지 못한 보관"은 조직에 치명적 악영향을 줄 수 있다는 경고로 인식할 수 있다는 것입니다. 당장 은행의 고객 정보 DB가 손상되고 국가 전자정부 DB가 손상되거나 기업내 경영정보 DB가 손상되었다고 생각하면 그로 인한 사회혼란이나 업무 혼란은 자세한 설명을 덧붙이지 않더라도 누구나 쉽게 유추해 볼 수 있는 상황일 것입니다. 냉장고의 음식이 안전하게 보관되지 못한다면 그로인한 육체적, 정신적 고통과 더불어 생활의 큰 불편이 따르는 것 처럼 냉장고와 데이터베이스의 핵심 기능은 내용물의 안전한 보관에 있습니다.

■ 체계적인 관리의 결과

최근에 TV를 틀면 나오는 냉장고 광고 카피 중에 하나가 "Showcase", "Incase"입니다. 양문형 냉장고의 냉장실문에 있던 수납 공간을 Showcase로 분리하여 빈번하게 여닫는 과정에서 자주 사용하는 것과 사용 빈도가 적은 것을 분리하여 체계적으로 관리하도록 도운 아이디어로 냉기가 쉽게 빠지지 않아 전기 절약에도 도움을 줄 수 있으리라 생각 됩니다. 자주 사용하는 음료수나 간단한 음식을 보관하게한 홈바 냉장고도 사용자들의 사용 빈도를 파악해 만든 제품이라 하겠습니다. 물론 가장 사용 빈도가 낮고 오랜 기간 손대지 않는 것은 냉동실입니다. 이와같이 사용자의 사용 패턴을 분석하여 사용자가 체계적으로 음식물을 관리하도록 돕는 제품도 있지만, 단순한 냉장고라도 꼼꼼한 주부들은 포스트잇을 붙여가면서 구입일자, 유통기한, 수량등을 체계적으로 관리합니다. 이러한 관리는 부패해서 음식물을 버리거나, 과도하게 음식을 구입하지 않게 하는 효과가 있습니다.

 

냉장고 처럼 데이터베이스도 제품 측면에서 자료를 체계적으로 관리하도록 돕는 기능이 있지만 사용자가 효과적인 체계화 방법을 적용하는 것이 체계적인 관리의 첩경이라 하겠습니다. 데이터베이스를 체계적으로 관리하는 출발점은 데이터베이스 모델링에서 시작합니다. 업무 요구사항을 분석하여 논리 데이터 모델(Logical data model)을 만들고 이를 근간으로 물리적 데이터 모델을 생성하는 모델링 과정을 통해서 현실의 문제를 데이터 모델에 정확하고 빠짐없이 반영함과 동시에 체계적이고 효율적인 데이터베이스 구성의 기본 바탕을 마련할 수 있습니다. 데이터 모델링을 접하는 많은 이들은 데이터 모델링이 난해하고 복잡해서 전문가만 가능한 것 아닌가? 라는 생각을 할 수도 있지만 실상 현실의 문제를 데이터베이스로 옮겨오고 이 과정에서 정보의 중복 최소화와 일관성 유지에 주안점을 두는 정도만 해도 충분합니다. 모델링 이후 실제 테스트 및 사용 과정에서 냉장고 공간 나누어 사용하기, 레이블 붙이기 처럼 체계적인 관리가 보완될 수 있기 때문입니다. 참고로 아래는 오픈소스 및 무료 데이터모델링 도구들입니다. 

• DBDesigner 4 : http://www.fabforce.net/dbdesigner4/ 대표적인 오픈 소스 모델링 도구, GPL
• CA ERwin® Data Modeler Community Edition : http://erwin.com/products/data-modeler/community-edition 대표적인 모델링 도구로 무료로 배포하는 버전.
• WWW SQL Designer : https://code.google.com/p/wwwsqldesigner/ 웹기반 도구로 국산 CUBRID도 지원하는 오픈 소스 도구, New BSD
• MySQL Workbench : http://www.mysql.com/products/workbench/ MySQL에서 배포하는 도구로 타 DBMS 마이그레이션도 지원, GPL과 상용 라이선스 구분 배포
• SQL Developer Data Modeler : http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html 오라클에서 무료로 개발 배포하는 도구
• SQL Power Architect : http://www.sqlpower.ca/page/architect 커뮤니티 에디션과 상용을 분리 배포, 오픈 소스는 GPL3

냉장고와 데이터베이스 사용자는 자주 사용하는 것은 빠르고 편리하게 접근하는 것을, 오랜 기간 손대지 않는 것은 손실 없는 보존을 원합니다. 이런 관점에서 데이터베이스 관련 기술은 다양한 형태로 발전해 왔는데, 쿼리 캐싱, 플랜 캐싱, 검색 결과 캐싱등의 캐싱을 통한 속도 향상 기법부터, 키와 인덱스를 통한 전형적인 속도 향상 및 일관성 유지 방법, 메모리 데이터베이스를 통한 속도 향상, 장기 보관 데이터 검색을 위한 파티션 기법, 내장 프로시저를 활용한 속도 향상, 트랜잭션 로그를 활용한 데이터베이스 복제, 다중 데이터베이스를 위한 샤딩등 체계적인 데이터베이스 관리를 위한 다양한 기능 들이 소개되고 있습니다. 적절한 데이터 모델링과 DBMS 기능의 효과적 활용으로 체계적인 데이터베이스 관리가 이루어진다면 저장소의 효율적 사용, 처리 속도 향상, 안정적 시스템 운용, 시스템 활용도 극대화등의 결과를 기대할 수 있을 것입니다.

 

DBMS를 선택하기 어렵거나, 이미  사용할 DBMS가 주어진 상황이거나 이미 운영중인 DBMS의 체계적인 관리를 위해서는 "몸에 맞는 사용 전략 수립"이 매우 중요합니다. DBMS 마다 특성과 기능에 차이가 있으므로 DBMS의 특성에 맞는 기능 적용을 검토해야 한다는 것입니다. 사용하는 전략과 방법에 따라 내용물은 무의미한 짐이 될 수도 있고 귀중한 자원의 역할을 감당할 수도 있습니다. 단순한 비즈니스 로직과 크지 않은 데이터량이라면 일반 냉장고에 레이블을 붙여 효율적인 사용을 도모하듯 오픈 소스 DBMS에 키와 인덱스 만으로도 충분한 효과를 볼 수도 있습니다. 내용물의 종류별로 분류 보관하고 자주 함께 사용하는 것들을 용기에 함께 보관하는 등의 방법으로 냉장고 사용의 편의성과 효율을 높이듯 실제적인 데이터 사용 패턴을 감안한 효과적인 데이터모델링으로 데이터베이스 사용 효율을 극대화 할 수 있습니다.

■ 범용과 특수용

양문형 냉장고, 홈바 냉장고, 붙박이 냉장고, 독신자용 냉장고, 뚜껑식 김치냉장고, 서랍식 김치 냉장고,  냉동고, 업소용 냉장고, 테이블 냉장고, 반찬 냉장고, 육수 냉장고 등등 용도와 용량에 따라 수많은  냉장고의 종류가 있습니다. 그렇지만 일반적으로 가정용 또는 업소용으로 사용하는 범용 냉장고는 용량과 소소한 기능의 차이는 있지만 어떤 냉장고를 사용해도 기능상 큰 차이는 없습니다. 육수용 냉장고 처럼 특수한 용도의 냉장고가 해당 용도에 최적의 기능을 발휘하지만 이런 용도에까지 범용 냉장고가 제 기능을 발휘하기를 기대하는 것은 적절하지 못합니다.

 

데이터베이스도 마찬가지로  대부분 다양한 용도에 활용할 수 있는 범용 DBMS를 사용하고 있지만, 처리속도에 민감한 실시간 운영체제나 중계 시스템, 모바일 시스템, 대용량의 클라우드 시스템등에서는 범용 DBMS 대신 별도의 DBMS를 채택하고 있습니다. ("DB를 냉장고처럼 쓰자 - 상품화된 DBMS(Commodity DBMS)" 참조)

범용 데이터베이스를 다양한 용도로 사용할 수 있다는 점은 장점이기는 하지만, 다양한 상황에 대응하기 위하여 수많은 기능과 코드가 작성된 만큼 단순한 용도로 사용하는 관점에서는 오히려 불필요한 낭비 요소가 많은 것도 사실입니다. 메모리 DBMS를 예로 들면 범용 데이터베이스가 처리해야하는 저장소 관리 관련 코드를 없애는 것만으로도 상당한 속도 향상을 기대할 수 있을 것입니다. 메모리  DBMS, 임베디드 DBMS, Stream DBMS, 다차원 DBMS, XML DBMS, Data Warehouse DBMS 등은 특수한 용도로 사용되는 DBMS의 예입니다.

다음은 다양한 용도에 활용할 수 있는 범용 DBMS의 예입니다.

• Oracle Database 11g
• IBM DB2
• Microsoft SQL Server 2012
• CUBRID 9.1
• MySQL 5.6
• PostgreSQL 9.2
• Firebird 

■ 사용자, 기술지원, 개발자

냉장고와 데이터베이스 모두 위의 그림과 같이 개발자, 기술지원, 사용자로 이루어지는 사용자 계층 구조를 갖습니다. 제품의 성숙도와 안정성 덕택에 사용자-설치, 수리 기사- 개발자간의 접촉 빈도도 높지 않은 편입니다. 다시 말하면 제품 결함으로 기사를 호출할 일도 거의 없고 많은 경우 사용자 차원에서 문제를 해결 한다는 것입니다. 사용자 계층 구조는 제품 관련 지식의 깊이와도 연관성을 갖습니다. 사용자 입장에서는 제품 사용에 많은 지식을 필요로 하지 않습니다. 스위치가 어디있는지, 문은 어느 쪽으로 열어야 하는지 등 기본적인 지식만 있으면 사용에 무리가 없습니다. 사용자 그룹도 소유한 지식에 따라 상담과 사용 요령 가이드를 할 수 있는 사람들과 사용 요령을 익힌 기본 지식 소유자, 최소한의 사용법만을 아는 사용자로 나눌 수 있는데 데이터베이스를 보더라도 DBA, 데이터모델러, 프로그램 개발을 위한 사용자, 단순 DB 사용자등의 다양한 사용자 그룹이 있습니다.

 

사용자 계층 구조를 통해서 이해해야 할 핵심은 사용자로서 DBMS를 대하는 입장으로 제품과 함께 제공되는 매뉴얼, 튜토리얼, 릴리즈 노트, 개발자 버전 배포본 등을 활용하여 제품을 특성을 파악하고 제품의 장점은 최대한 활용하고 단점은 적절한 대안을 찾아 적용하는 전략적 접근이 필요하다는 것입니다. 제품의 성능은 기본적으로는 제품 자체에 기인하지만, 많은 경우 사용자의 제품에 맞는 적절한 사용이 성능의 핵심 요인으로 작용합니다.  아는 만큼 잘 쓸 수 있습니다!