youknowone.text

[youknowone]

SQLAlchemy 1.1 - index_property

SQLAlchemy 1.1에는 index_property라는, Indexable 컬럼 (JSON, ARRAY, HSTORE 등)의 속성 하나를 마치 컬럼과 비슷한 프로퍼티처럼 다룰 수 있는 기능이 추가되었습니다.

제가 추가한 기능이라 소개 시간.

1.1에 추가된 것 소개 문서와 Indexable에 관한 문서로 나누어서 다루어지고 있는데, 이 글에서는 무엇이 좋은지 1.0의 코드와 비교해 보려고 합니다.

먼저 id 밖의 모든 자료는 data라는 JSON 컬럼에 저장하는 모델 Person을 생각해 봅시다.

class Person(Base): __tablename__ = 'person' id = Column(Integer, primary_key=True) data = Column(JSON) # 여기에 모든 속성이 들어간다

만일 data에 name이라는 속성이 들어있다면, 1.0에서는 다음과 같이 접근합니다.

person = Person(data={'name': 'youknowone'}) # 만들 때 print(person.data['name']) # 가져올 때

1.1에 새로 추가된 index_property는 여기서 name을 마치 하나의 컬럼과 비슷하게 다룰 수 있도록 도와줍니다.

class Person(Base): __tablename__ = 'person' id = Column(Integer, primary_key=True) data = Column(JSON) # 여기에 모든 속성이 들어간다 name = index_property('data', 'name')

처음 정의에서 name이라는 index_property를 추가했습니다. data라는 컬럼의 name이라는 키와 연결시킨 프로퍼티라는 뜻이에요.

이 프로퍼티는 만능이어서, 여러분이 SQLAlchemy에서 기존의 프로퍼티에 기대하던 모든 일을 할 수 있어요.

person = Person(name='youknowone') # 생성 assert person.name == 'youknowone' # 조회 person.name = 'sqlalchemy' # 변경 session.query(Person).filter(Person.name.astext == 'sqlalchemy') # 쿼리

이것들을 다시 index_property 없이, 1.0과 호환되도록 써 본다면,

class Person(Base): __tablename__ = 'person' id = Column(Integer, primary_key=True) data = Column(MutableDict.as_mutable(JSON)) # 아까와 달리 내용 변경을 추적하려면 MutableDict로 타입을 감싸주어야 한다. person = Person(data={'name': 'youknowone'}) # 생성 assert person.data['name'] == 'youknowone' # 조회 person.data['name'] = 'sqlalchemy' # 변경. 위에서 MutableDict를 써야만 가능 session.query(Person).filter(Person.data['name'].astext == 'sqlalchemy') # 쿼리

각각의 코드가 훨씬 길어지는 것은 물론이고 MutableDict 역시 도입해서 함께 써야 합니다. 물론 1.0에서도 이걸 일일이 풀어쓰기 보다는 비슷한 인터페이스로 감싸서 쓰기들 원하는 사람들이 있었죠. 이번에는 이 프로퍼티를 직접 만들어 봅시다.

class Person(Base): __tablename__ = 'person' id = Column(Integer, primary_key=True) data = Column(JSON) # 여기에 모든 속성이 들어간다 @hybrid_property def name(self): return self.data.get('name', None) @name.setter def name(self, new_value): data = self.data.copy() # 꼭 복사할 필요는 없지만 name에 바로 대입하면 변경을 추적하지 못해요 data['name'] = new_value self.data = data @name.expression def name(self): return self.data['name']

한 줄의 index_property로 가능하던 일을 세 개의 메서드를 구현해 가며 만들어야만 합니다. 의욕이 꺾이는 일이지요. 그러니 앞으로는 index_property를 꼭 쓰세요.

세줄 요약:

SQLAlchemy 1.1에는 index_property라는게 생겼다.

index_property를 쓰면 JSON, ARRAY 등의 한 index를 가리키는 프로퍼티를 만들 수 있다.

만들고 나면 마치 그 이름의 컬럼인 것과 비슷하게 쓸 수 있다.

[youknowone]

codecov vs coveralls

김현준님의 소개로 coveralls를 쓰던 프로젝트에 codecov를 붙여 보았는데, 앞으로 coveralls에 큰 변화가 없는 한 codecov를 쓰게 될 것 같습니다.

두 서비스가 모두 붙은 상태에서 결과를 비교해 보니, 정말 중요한 차이가 보입니다. codecov는 이 패치의 상태를 정확히 보여줍니다.

비율이 아닌 정확한 줄 수로.

패치 밖에서 바뀐 커버리지가 있는지

패치 안의 코드는 얼마나 커버되는지

coveralls를 볼때는 그냥 테스트 커버리지 올리는 숫자 게임을 하는 느낌이었습니다. 이 패치가 커버리지를 올리는지 낮추는지를 봐서는 패치가 정말 모두 커버되는지 아닌지는 전혀 알수 없지요. 어쩌다 같은 코드를 두줄에 나눠 쓰면 커버리지가 올라가고 합쳐 쓰면 내려갑니다. 정말 중요한건 coveralls에 방문해서 하나 하나 찾아 봐야만 해요.

codecov에서는 패치에 대해 보여주는 상세한 정보를 PR에서 바로 확인하고 특이사항이 있을때만 웹사이트에 방문해서 필요한 정보를 더 찾아보면 됩니다.

양 쪽 모두 전체 프로젝트의 커버리지도 보여주고 있지만, 처음 커버리지 테스트를 했을때나 대규모로 테스트를 추가했을 때 정도에나 관심이 가는 수치이고, 패치 하나 하나를 리뷰할 때는 크게 관심가는 부분은 아닌 것 같습니다.

결론: 커버리지 테스트 하시려면 꼭 codecov 쓰세요.

[youknowone]

Star 수로 보는 내 github

의외의 프로젝트(FoundationExtension)가 상당히 많은 별을 받고 있길래, 뭘 만들었을때 사람들이 가장 좋아하는지 궁금해 한번 정리해봤다.

UI7Kit (1796): 충분히 유용했고, 충분히 신기했다. 나도 내가 안만들었으면 신기했을 것 같은 프로젝트. 만드는 법이 어려운건 아닌데, 그냥 동적 패치 노가다 열심히 하면 된다.

구름 입력기 (156): 세벌식 사용자들의 염원과 맥 내장 입력기 품질에 대한 한이 느껴진다... OS X 버전이 올라가면서 이런저런 문제가 생겨 이제 세벌식을 안쓰면 품질이 더 낫다고 말하기도 뭣 한 상황이 되어버렸다. 장단이 있는 상황.

VisualJSON (119): JSON API를 다루다 보니 필요해서 만들었는데, 나 말고도 다들 필요했나보다. 만들었을 당시에는 맥 앱스토어에서 유일한 무료 JSON 툴이었다. 지금은 더 있을 것 같다.

FoundationExtension (100): Objective-C 코드 조각 모음 같은 프로젝트. 개인적으로 필요해서 계속 만들어 쓰던 프로젝트인데, 의존성으로 들어간 걸 보고 이리저리 퍼진 듯. 문서를 열심히 쓰긴 했다.

XChat Aqua (93): 내가 만든건 아니지만.. 그래도 OS X계 3대 IRC 클라이언트 중 하나. 무덤에 들어갔던걸(abandoned) 어째 겨우 살려내서 명줄만 붙여놓고 있다.

아래는 그 이하의 미묘한 것들.

QRQR (24): 앱 자체의 인기는 별로였는데 zxing-ios의 최소 구현체 예제 같은 느낌이지 않았을까...

itunes-iap (21): iTunes 인앱 결제 검증 라이브러리. 회사를 안다니게 되면서 안 쓴지 오래됐는데 패치만 받아서 연명하고 있다.

sqlite3-objc (14): 음... iOS 처음 할 때 잠깐 쓰곤 한번도 안쓴거라... 쿼리 날리면 결과에 대해 Enumerator 지원하고 C API 그대로 쓰는거보단 살짝 덜 괴롭다.

cdebug (12): 좋은 대체재 추천해주세요.

[youknowone]

세벌식 최종(391) 자판의 개선안

세벌식 최종 자판1은 현재 흔히 두벌식이라 불리는 자판2에 이어 두 번째로 널리 쓰이는 한글 자판이며, 이 글은 세벌식 최종 자판을 써오면서 조금씩 변경해 온 개선안에 대한 설명입니다.

구름입력기에 세벌식 최종 순아래 라는 이름으로 포함되어 있습니다.

설계 원칙

이 안은 다음과 같은 설계 원칙에 근거를 두고 있습니다.

세벌식 최종 자판과 호환성을 유지하며 배열을 변경하지 않는다. - 접근성

한글 조합에는 시프트를 전혀 사용하지 않도록 한다. - 편의성

모아치기가 가능하도록 배열한다. 따라서 한 음절을 입력하는 데 같은 글쇠를 두 번 쓰지 않는다. 특히 가능하다면 두 손가락으로 누르기 어려운 같은 열의 글쇠를 두 번 쓰는 것도 피한다. - 모아치기 지원

이 가운데 세벌식 최종과의 호환성은 개선안을 만드시는 분들은 보통 크게 신경쓰지 않거나 동의하지 않는 조건인 것으로 알고 있지만, 이 원칙에 관해서는 뒤에서 다시 한번 설명하도록 하겠습니다.

배열을 변경하지 않고서도 2와 3을 달성하기 위해 이 개선안은 많은 조합규칙을 충돌 없이 추가하는 데 초점을 맞추고 있습니다.

배열

배열은 설계 원칙 1에 따라 세벌식 최종과 같습니다. 다만 세벌식 최종에서 독립된 글쇠가 아닌 우측의 이중모음 조합용 ㅗ와 ㅜ는 독립적으로 사용하지 않는 한 결과적으로 글자 조합에 영향을 끼치지 않으므로 ㅚ와 ㅟ로 변경해 사용하고 있습니다.

초성 조합

세벌식 최종에서 겹자음을 제외한 모든 초성은 글쇠마다 배당이 되어 있고 겹자음은 같은 글쇠를 두 번 연달아 눌러 입력합니다.

개선안에서는 겹자음은 모두 인접글쇠와 같이 누르는 것으로 조합합니다.

ㄱ+ㅇ => ㄲ ㅈ+ㄱ => ㅉ ㅂ+ㅈ => ㅃ ㄷ+ㅁ => ㄸ ㅅ+ㅎ => ㅆ

2단의 ㄲ, ㅉ, ㅃ 는 모두 손을 기본 위치에서 움직이지 않고 입력할 수 있도록 왼쪽 글쇠와 합자하게 되어 있습니다. 3단의 ㄸ는 ㄹ보다는 ㅁ을 누르는 편이 쉽기 때문에 ㅁ이 선택되었습니다. 1단의 ㅆ는 ㅎ 밖에는 선택권이 없습니다.

이 조합 규칙은 연타를 제거하면서 사용자가 어떤 글쇠를 먼저 누를 지 고민의 여지를 없애기 때문에 사용자는 초성을 거의 1타에 가까운 느낌으로 입력할 수 있습니다. 예를 들어 ㄲ을 입력한다고 하면 사용자의 입력이 ㄱ⇨ㅇ 순서든 ㅇ⇨ㄱ 순서든 ㄲ 입력이 보장되므로 기존의 최종 안에서 연달아 ㄱ을 두 번 누르는 대신 ㄱ과 ㅇ을 동시에 누를 수 있습니다.

초성 조합 규칙은 안마태 자판3에서 겹자음을 입력하는 방법을 차용한 방법입니다.

중성 조합

세벌식 최종에서 중성 조합은 ㅗ 계열 조합과 ㅜ 계열 조합이 나뉘고 이외의 이중모음은 모두 글쇠에 단타로 배당이 되어 있습니다. 그리고 대부분의 모음이 왼손으로 시프트 없이 입력이 가능하지만, 그 중 ㅒ글쇠는 시프트를 사용하고 있고, ㅖ, ㅢ 두 글자는 오른손을 사용합니다.

개선안에서는 세 가지 문제를 개선하고자 합니다.

중성1 - 조합 계열 폐지

세벌식 최종에서는 오른쪽의 조합용ㅗ는 ㅗ 계열 이중모음 조합에, 오른쪽의 조합용ㅜ는 ㅜ 계열 이중모음 조합에 사용하는데, 이는 다분히 기계적인 발상의 조합 방식입니다. 어차피 오른쪽의 조합용ㅗ, 조합용ㅜ 글쇠가 조합에 이용된다면 이 조합 글쇠는 서로 혼동될 여지가 없는 다양한 글쇠를 조합하는데 쓸 수 있어야 합니다. 따라서 다음 조합 규칙을 추가합니다.

조합용ㅗ+ㅓ=>ㅝ 조합용ㅗ+ㅔ=>ㅞ 조합용ㅜ+ㅏ=>ㅘ 조합용ㅜ+ㅐ=>ㅙ

사용 경험상 현실적으로 조합용ㅜ는 조합용ㅗ보다 입력하기 불편한 위치에 있으므로, 대부분의 조합은 ㅗ를 이용하는 편이 낫습니다. 따라서 조합용ㅜ의 용도는 두 번째 모음만으로는 구분이 불가능한 ㅚ와 ㅟ를 구분해 입력하는 데 주로 쓰일 가능성이 높습니다.

어차피 조합용ㅗ와 조합용ㅜ는 이중모음을 입력하지 않을 때는 사용할 이유가 없으므로, ㅚ나 ㅟ를 입력하기 위해 쓰이는 글쇠라면 처음부터 ㅚ나 ㅟ를 바로 입력해 주는 편이 타수를 줄일 수 있습니다.

따라서 ㅚ와 ㅟ는 별도의 조합 없이 조합용ㅗ를 ㅚ에, 조합용 ㅜ를 ㅟ에 배당할 수 있습니다. 이 배치가 바로 위의 배열 절에서 설명한 달라진 단 두 글자입니다. 배열이 일부 변경되었지만 조합용 ㅗ,ㅜ글쇠와 비조합용 ㅗ,ㅜ글쇠만 구분해 사용하면 이전 방식으로도 같은 방식으로 입력할 수 있으므로 혼동의 여지가 없습니다.

중성2 - 시프트 제거

초성과 달리 중성 가운데 ㅒ문자는 시프트를 사용해 입력합니다. 설계원칙2에 따라 시프트는 가급적이면 배제하여야 하는데, 개선안은 이미 많은 이중모음을 한글 모음 결합 규칙에서 벗어나서 조합용 모음을 이용하여 조합하는 것을 허용하고 있습니다. 이미 조합용ㅗ+ㅔ=>ㅞ 와 같은 기능을 편의로 제공하고 있기 때문에 ㅒ 문자도 마찬가지로 조합용 모음을 이용해 조합하더라도 일관성이 더 깨지지 않을 것입니다. ㅒ 문자를 위해 다음 조합 규칙을 추가합니다.

조합용ㅗ+ㅡ=>ㅒ 조합용ㅜ+ㅡ=>ㅒ

ㅡ를 조합에 쓰는 이유는 원래 시프트+ㅡ 입력이 ㅒ문자이기 때문입니다. 이러한 방식의 시프트 위치를 존중하는 조합 규칙은 종성에서도 사용되는 개선안의 일반 원칙입니다.

중성3 - 오른손 입력 제거

이 안은 앞의 다른 개선안과 달리 무조건 효율이 좋아지는 개선안은 아닙니다. 오른손 검지나 중지 4단 1타를 오른손 소지 1단이나 오른손 중지/약지 4단+왼손 검지나 중지 1단/3단 2타로 교환하는 방법입니다. 4

세벌식 최종에서 대부분의 중성 입력은 조합용 모음을 쓰는 이중모음을 제외하면 왼손 검지와 중지로 할 수 있습니다. 하지만 ㅖ, ㅢ는 그렇지 않습니다. 그리고 위의 조합규칙 변경으로 새 단타 모음인 ㅟ가 생겼습니다.

오른손으로 모음 입력하기를 꺼리는 사용자를 위해 다음 규칙을 추가할 수 있습니다.

조합용ㅗ+ㅕ=>ㅖ 조합용ㅗ+ㅗ=>ㅢ 조합용ㅗ+ㅜ=>ㅟ

조합용ㅜ도 마찬가지입니다.

이로서 모음은 1단-3단이 모두 조합문자를 갖습니다. 다만 조합용ㅗ+ㅜ는 다른 조합과 달리 누르기가 아주 어려운 편인데 이미 조합용ㅜ 한 타로 ㅟ를 넣게 개선되었다는 점에서 우선순위를 낮게 줬습니다. 조합용ㅗ+ㅕ=>ㅖ 조합은 ㅖ와 ㅕ가 연관된 문자이기 때문에 그렇게 했습니다.

이 절의 안은 1타로 입력 가능한 글쇠를 2타로 교환하는 방법이므로 사용자의 타자 습관이나 선호에 따라 개선안이 아닐 가능성도 있으니 사용자에 따라 선택해 쓸 수 있어야 하겠습니다.

종성 - 조합글쇠

세벌식 최종은 모든 종성을 1타에 입력할 수 있도록 배려하고 있으며 이에 따라 상당히 많은 수의 겹받침이 시프트 위에 배당이 되어 있습니다. 그러나 시프트는 다른 글쇠가 누르기 동작만 처리하는 것과 달리 누름과 뗌 사이에 들어가는 모든 키에 영향을 끼치기 때문에 시프트 누름과 뗌 앞뒤로 타속을 떨어뜨리고 리듬감도 나쁘게 만드는 주요 요소입니다. 하지만 종성에는 중성과 달리 기존에 쓰던 조합 문자도 없기 때문에, 시프트 대신 글자 조합에 써 넣을 수 있는 글쇠를 하나 배당해야합니다. 이 글쇠는 (로 정합니다.

(가 선택된 이유는 소지로 입력할 수 있는 글쇠 중 다른 글자 조합 중에 입력할 가능성이 엄청나게 높은 ,와 .를 제외하면 가장 가까운 글쇠이기 때문입니다. 소지가 아닌 다른 손가락을 쓰는 글쇠를 고를 경우 검지-중지-약지-소지 순으로 자주 눌리는 글쇠가 배치된 세벌식 최종 특성상 이 글쇠를 초성 다음에 연달아 입력하기가 불편해집니다. 게다가 (는 충분히 가깝기 때문에 소지가 다른 글쇠 입력에 쓰이는 경우에 대비해 약지로 누르기도 쉽습니다. 앞으로는 이 ( 글쇠를 '종성조합글쇠'로 명명합니다.

기본 정책은 종성을 누르기 전에 종성조합글쇠를 누르면 다음에 눌리는 종성후보글쇠(시프트에 겹받침이 할당된 글쇠)는 시프트를 누른 상태에서 눌린 것으로 간주한다 입니다.

시프트를 누르지 않고도 종성이 할당되어 있던 위치에 조합 규칙을 추가합니다.

종성조합글쇠+ㅎ=>ㄲ 종성조합글쇠+ㅆ=>ㄺ 종성조합글쇠+ㅂ=>ㅈ 종성조합글쇠+ㅅ=>ㅍ 종성조합글쇠+ㄹ=>ㅌ 종성조합글쇠+ㅇ=>ㄷ 종성조합글쇠+ㄴ=>ㄶ 종성조합글쇠+ㅁ=>ㅊ 종성조합글쇠+ㄱ=>ㅄ

문제는 시프트를 누르지 않았을 때는 중성이 할당된 영역입니다. 일단은 이 영역에도 마찬가지로 위와 같은 규칙을 추가합니다.

종성조합글쇠+ㅛ=>ㄿ 종성조합글쇠+ㅠ=>ㄾ 종성조합글쇠+ㅕ=>ㄵ 종성조합글쇠+ㅐ=>ㅀ 종성조합글쇠+ㅓ=>ㄽ 종성조합글쇠+ㅣ=>ㄼ 종성조합글쇠+ㅏ=>ㄻ 종성조합글쇠+ㅔ=>ㅋ 종성조합글쇠+ㅗ=>ㄳ

종성 - 설계원칙3

대부분의 경우 이 규칙으로 충분합니다.그런데 이 경우 '삶'이라는 글자를 입력하려고 하면 한 글자 입력에 ㅏ 글쇠를 두 번 눌러야 합니다. 설계원칙3 위반입니다.

기본적으로 사용자는 겹받침이 필요할 때만 종성조합글쇠를 누르게 됩니다. 따라서 ㅏ를 눌렀을 경우 종성조합글쇠가 있는 것만으로 ㄻ을 입력하고자 했던 것으로 간주해도 무리가 없습니다. 따라서 종성조합글쇠가 눌린 경우 따로 종성후보글쇠를 누르지 않으면 현재 사용중인 모음 위치의 시프트 종성이 사용된 것으로 간주합니다.

ㅕ+종성조합글쇠+(다른 글쇠 없음)=>ㅕㄵ ....

명백하지만 일일이 나열하기엔 장황하므로 이 경우의 표는 생략합니다.

한편 기본 정책을 위에서는 "종성조합글쇠를 종성후보글쇠 전에 누른다"와 같이 설명했지만, 이 조건은 모아치기에 큰 약점으로 작용합니다. 매 글자를 조합할 때 종성조합글쇠가 들어가는 조건을 생각해보면 이 글쇠는 시프트 겹받침을 입력할 때에만 사용되는 글쇠임을 알 수 있습니다. 이 조건을 이용하면 모아치기를 배려해 다음과 같이 개선된 조건을 제시할 수 있습니다.

한 번 초성이 입력된 후 그 다음 초성이 입력되기 전까지 종성조합글쇠가 입력되면 조합 중이던 글자의 종성은 종성조합글쇠를 누른 것으로 간주한다

종성 - ( 입력하기

( 위치를 종성조합글쇠로 할당했지만 실제로는 (도 입력해야할 때가 있습니다. 세벌식 최종은 ,. 위를 제외한 모든 글쇠에 서로 다른 문자가 할당되어 있으므로 옮기기도 쉽지 않고, 무엇보다 글쇠 옮기기는 설계원칙1 위반입니다.

위의 추가 조건을 읽어보면 종성조합글쇠는 초성이 입력된 뒤에 입력되어야만 안전하게 효력을 발휘할 수 있습니다. 따라서 초성이 없는 상태, 즉 한글 조합 중이 아닌 상태에서 (를 누르면 시프트 역할 대신 ( 키의 역할을 하게 할 수 있습니다.

이 방법은 한글 조합중에는 (를 사용할 수 없게 만들어 방향키 등으로 조합 상태 탈출을 해야 하기 때문에 세벌식 최종보다 약간 퇴보한 것입니다. 하지만 통상의 타자생활에서 (글쇠의 빈도가 종성 겹받침보다는 낮다는 점과 이때 종성조합글쇠가 가져다 주는 상당한 이득과 비교해 이 손실은 조금 양보하기로 했습니다.

최종과 호환성을 일부 포기해도 된다면 (를 많이 입력하는 환경을 배려하기 위해 거의 쓰이지 않는 ㄽ 자리를 (나 조합탈출 키에 배당할 수도 있을 것입니다. (시도해 보지는 않았습니다)

모아치기

기본적으로 이 개선안은 세벌식 최종의 설계를 해치지 않기 때문에 연달아 쳐야 하는 글쇠와 시프트를 제거한 것만으로도 순차치기에서 많은 이득을 볼 수 있습니다.

하지만 그보다 더 매력적인 개선 결과는 세벌식최종보다 더욱 모아치기에 적합하게 변경되어 더 높은 비율로 모아치기가 가능하다는 점입니다.

다만 몇가지 제약조건이 있는데, 먼저 초성은 다른 글쇠와 섞이면 안됩니다. 초성은 중성과 종성이 어디 달라붙을지 결정하는 글쇠이기도 하고 종성조합글쇠의 효력 경계가 되기도 합니다. 게다가 겹자음의 경우 두 개의 초성 글쇠를 쓰기 때문에 두 개의 초성 글쇠 사이에 다른 글쇠가 들어갈 경우 분간할 방법이 없습니다.

하지만 초성만 따로 입력하고 나면 그 뒤로는 중성 위에 놓인 겹받침을 제외한 모든 글쇠는 순서 없이 눌러 모아치기를 할 수 있습니다. 중성 위에 놓인 겹받침의 경우 종성조합글쇠가 어떤 중성 타자가 중성 입력이고 어떤 중성 타자가 종성 타자인지 구분할 방법이 순서밖에 없기 때문에 무조건 첫 중성은 중성으로, 둘째 중성은 종성으로 취급할 수 밖에 없습니다.

따라서 개선안으로는 대부분의 글자를 2회에, 일부 겹받침이 든 글자는 3회에 걸쳐 모아칠 수 있으며 이는 기존 세벌식 최종의 시프트를 포함한 4회 ('꿇'의 경우 ㄱ>ㄱㅜ>시프트>ㅀ>시프트떼기) 가량보다 개선된 것입니다. 앞에서도 이야기했지만 시프트는 누름과 뗌 동작 모두 조합되는 글자에 영향을 끼쳐 타속을 크게 떨어뜨리기 때문에 시프트 1회 제거는 단순히 1회 타자를 줄이는 것 이상의 가치가 있습니다.

타자 사례

설명만 읽고서는 동작을 이해하기 힘드니 예시를 들어 최종과 비교해 보겠습니다. 비교 용이성을 위해 여기서는 쿼티 자판 기준으로 입력 글쇠를 표시합니다.

아래에서 > 표시는 입력할 글쇠가 아닌 모아치기 경계 표시입니다. 현실적으로 최종이든 개선안이든 초성과 중종성을 결합하는 모아치기는 가능한 상황에서도 실제로 활용하기는 어려우므로 경계로 표시합니다.

단어 세벌식최종 개선안 까치 k>k>f>o>d kj>f>o>d 귀뚫개 k>9d>u>u>b>R>k>r k>9>iu>b[w>k>r 얘기 j>G>k>d j>/g>k>d 예의1 j>7>j>8 j>7>j>8 (동등) 예의2 j>7>j>8 j>/g>j>/g (장단점이 있다) 많음 i>f>S>j>gz i>f[s>j>gz 닫김 u>f>A>k>dz u>f[a>k>dz 삶 n>f>F n>f[ 닳다 u>f>R>u>f u>f[>r>u>f

세벌식 최종 호환성

세벌식 최종 호환성을 이야기하기 전에 왜 세벌식 최종을 선택했는지부터 설명해야할 것 같습니다.

표준 두벌식을 제외하면 가장 대중적인 자판이며 현재 세벌식 자판을 지원하는 입력기에서는 빠짐없이 지원되고 있다.

한글 조합에만 집중했을 때 비슷한 인지도와 지원 배경을 가진 390보다는 배치도 조금 더 낫고 리듬감은 훨씬 우수한 편이다.

모든 중/종성이 1타로 입력하게 배치되어 있어 조합용ㅗ/ㅜ 활용과 종성조합글쇠 추가가 용이하다.

호환성을 깨뜨리지 않으려는 이유는 다음과 같습니다.

규칙 추가만으로 자판을 개선할 경우 대부분의 세벌식 이용자인 최종 사용자들이 손쉽게 자신에게 필요한 규칙만 익혀 골라 쓸 수 있습니다. 즉 기존의 세벌식 이용자들에게 뛰어난 접근성을 보장하면서도 쉽게 타자 효율을 개선할 수 있습니다.

혹시 개선안을 이용할 수 없는 환경을 맞닥뜨리더라도 (예를 들어 대부분의 날개셋 자판은 윈도 밖에서는 이용할 수가 없습니다) 최소한의 불편으로 최종 배열을 그대로 사용할 수 있습니다. 사실상 모든 시스템이 최종 자판과 390 자판은 지원합니다. 만약 기존 자판과 전혀 다른 개선안을 쓰고 있었을 경우 최종이나 390을 배웠던 사용자라면 조금씩 다른 규칙을 계속 신경써야하고 그렇지 않다면 (전혀 모르는 다른 세벌식 자판보다는 그나마 인쇄된 배열이라도 볼 수 있도록) 아예 두벌식을 써야할 수도 있습니다. 세벌식 자판에 익숙해져 온 분들이라면 쓸 수만 있다면 모아치기 없는 세벌식 최종이라도 두벌식보다야 더 낫다고 생각합니다.5 이 개선안을 쓰는 사용자는 기본적으로 세벌식 최종을 익히고 있으니 최종을 쓰기는 어렵지 않습니다. 즉 개선안을 사용하기 어려워지더라도 자판 역호환성이 뛰어납니다. (최종으로 돌아가기 쉽습니다)

효율적인 배치를 한 자판입니다. 최선이라고 할 수는 없을지 몰라도, 세벌식 최종의 배열은 이미 그 자체로 빈도와 손가락 꼬임을 줄이기 위해 잘 설계된 배열입니다. 배열 변경은 필수적으로 추가 연구를 수반하고, 그 변경이 개선인지 개악인지 알기는 어렵습니다. 게다가 개선이라 하더라도 이미 상당히 최적화 된 최종 자판의 배열과 비교해 그 개선 정도는 미미한 편입니다. 그렇다면 조그만 이득을 위해 학습 비용을 올리기보다는 이득을 포기하고 학습 비용을 낮추는 편이 더 나을 수도 있습니다.

동의하기 어려운 분들도 있으실 것 같습니다. 요즘의 세벌식 사용자분들은 보통 더 나은 배열을 위해 새로 배우는 번거로움을 마다하지 않고 배워 온 분들이니까요. 배열이 다른 개선안을 만들어내고 배워가는 것도 개개인의 관점에서는 좋은 투자라고 생각합니다. 하지만 어디까지나 학습비용과 포기비용의 적정선에 대한 철학과 취향의 차이로 이해해 주시고 '최종 자판을 크게 바꾸지 않고도 더 나은 타자를 하려면 이런 방법도 있구나' 정도로 생각해 주시면 좋겠습니다.

구현체

맥으로 옮겨 오기 전에 쓰던 날개셋 구현체와 맥에서 쓰는 구름 입력기가 있습니다. 둘 모두 구현이 완벽하지 않으며 현재 새로운 구현체를 만들고 있습니다.

맥을 쓰기 시작한게 2008년 즈음이라 날개셋 구현체는 그 이전세대의 기능으로만 구현되어 있습니다. 지금은 더 나은 구현이 가능할 수도 있습니다.

다운받기: https://github.com/youknowone/3finalnoshift

도저히 손으로 하나 하나 추가하는 방식으로는 거대한 종성 조합 규칙 테이블을 실수 없이 구현할 자신이 없어 구현하지 못한 미구현 기능이 있습니다. 위에서 'nf[' 을 입력하면 '삶'이 나와야한다고 설명했지만, 이 구현체는 '사'에 종성조합글쇠가 들어간 상태로만 처리되고 f을 한번 더 입력해야 '삶'이 입력됩니다.

버그도 있는데, 초성이 명확한 글자 경계로 동작하지 않아서 이중모음과 받침을 함께 모아쓸 경우 가끔 모음이 다음 글자로 밀려나는 경우가 있습니다.

맥에서는 구름입력기 최신 버전을 받으면 바로 사용할 수 있습니다. 여기도 마찬가지로 버그가 있어서, 'nf['이 '삶'으로 조합되는 기능은 지원되는 대신 그 이후에 이중모음이 무한히 대치되면서 조합되는 문제가 있습니다. 날개셋 파일의 버그와 달리 실제로 오타에는 크게 영향을 미치지 않는 버그이니 걱정하지 않으셔도 됩니다.

날개셋과 마찬가지로 받침을 먼저 입력 후 이중모음을 넣으려 할 경우 다음 글자로 밀러나는 문제가 있습니다.

비호환 개선안

세벌식 최종과의 완벽한 호환을 포기하면 몇가지 추가적인 개선안을 도입할 수 있습니다.

첫째로는 개선안에서는 모든 한글 낱자를 시프트 없이 입력할 수 있으므로 쿼티 자판과 상당히 높은 특수기호 호환성을 가질 수 있습니다. 일단 0-9 위의 시프트를 쓰는 모든 특수문자는 제자리에 배열이 가능합니다. 남는 자리에는 빠진 배열을 더 넣을 수도 있고, 기호에 따라 ㅂ, ㅌ, 조합용ㅗ 세 글자만 제외하면 아예 모든 배열을 쿼티와 맞춰 넣을 수도 있습니다.

둘째로는 종성 ㅄ의 조합 방식을 개선할 수 있습니다. 현재 위에서 서술한 규칙에 따르면 '없'은 'jt[x'로 입력해야 합니다. 그러나 실질적으로 현대 한국어에서 ㄽ은 더이상 사용하지 않는 문자이고,6 ㅄ은 '값'과 '없'이 대부분의 사용례를 차지한다는 점을 고려하면 'jt['까지 입력했을 때 '엀'이 나오는 것보다는 '없'이 나오는 편이 더 유리하다는 점을 짐작할 수 있습니다. '값'을 조합할 때는 기존의 위치가 더 편하므로 기존 조합 방식은 유지해야하고, ㄽ 받침이 꼭 필요할 때는 시프트를 눌러 입력하거나 t를 한번 더 눌러 입력할 수 있습니다. 이 경우 ㄽ이 사용되는 단어는 모두 중성이 ㅗ 이므로 같은 자리를 두번 연타해야 하는 걱정도 없습니다. (위치상 검지를 두 번 쓸 가능성이 높지만, 불편을 감수하고 중지로 입력할 수도 있습니다. 어떤 경우든 사실상 쓰이지 않는 낱자이니만큼 불편을 무시해도 좋은 드문 경우라고 생각됩니다.) 이 안은 구름입력기의 구현에는 들어가 있는 구현입니다.

셋째로는 ㅖ, ㅢ, ㅟ 가운데 하나를 없애고 이 자리에 (를 배당하고 현재의 ( 자리는 종성조합글쇠로 전용하는 방법이 있습니다. 이쪽은 아직 아이디어가 다듬어지지 않은 단계라 정말 실용적일지는 잘 모르겠습니다.

넷째로는 ㅢ와 ㅒ의 빈도차 및 ㅢ가 ㅣ와의 조합으로 이루어진다는 점을 고려해 조합용ㅗ+ㅡ 자리에는 ㅢ를 배당하고 조합용ㅗ+ㅗ 자리에 ㅒ를 배당하여 잘 쓰이지 않는 ㅒ 글자의 편의성을 떨어뜨리는 대신 자주 쓰이는 ㅢ 글자의 편의성을 올리는 방법입니다. 개인적으로는 조합용ㅗ+ㅗ는 최종의 ㅢ 배열에 비해 불편했지만, 조합용ㅗ+ㅡ는 조금 더 낫다고 생각되었습니다.

각각 나름의 이득이 있을테고, 이 영역으로 넘어가면 각자의 취향에 따라 제가 미처 생각지 못한 다양한 개선안이 있으리라 생각됩니다. 어디까지나 기본은 모두에게 권하기 좋은 호환 개선안이고, 이 부분은 사용자 필요에 따라 개별적으로 개량될 수 있다고 생각합니다.

세벌식 최종으로 널리 알려졌지만, 391자판이 정확한 이름이라는 지적도 있습니다. 글에서는 널리 알려진 이름인 세벌식 최종을 사용합니다. ↩︎

KS X 5002 ↩︎

http://ahnmatae.com/ 이용자 수는 다른 배열에 비해 적은 듯 싶지만, 완전모아치기, 엄지 사용, 독특한 조합 방식으로 큰 주목을 받아 배열 특성 자체는 널리 알려져 있습니다. ↩︎

처음 자판을 만들때는 이 규칙을 추가해서 썼지만, 저는 더 이상 이용하지 않고 원래의 단타 ㅖ, ㅢ, ㅟ를 그대로 이용하고 있습니다. ↩︎

윈도에서 맥으로 바꿨을 때 이 부분이 가장 불편하면서도 다행스러웠습니다. 개선안 대신 보통 세벌식 최종을 써야 해서 불편해졌지만, 배열은 똑같이 유지해 왔기 때문에 불편함만 조금 감수하면 전혀 헷갈림 없이 그대로 세벌식 최종으로 돌아올 수 있었습니다. 구름 입력기는 이런 불편함을 해결하기 위해 개선안을 직접 구현하고자 만들게 된 입력기입니다. ↩︎

‘곬’, ‘물곬’, ‘옰’, ‘외곬’, ‘통곬’ 다섯 단어에 쓰인다고 하지만 모두 거의 사용되지 않는 단어이고, 맞춤법 개정 전에 '돐'에 쓰이는 경우가 있었지만 현재는 거의 '돌'로 쓰이고 있습니다. ↩︎

[youknowone]

스위프트 optional과 nil

자료형

자료형 T에 대해,

T: nil을 가질 수 없는 자료형.

T?: 원래 자료형이나 nil을 가질 수 있는 optional 자료형. 자료를 꺼내 쓰려면 명시적으로 ! 연산자로 T로 변환해야 한다.

T!: 원래 자료형이나 nil을 가질 수 있는 optional 자료형. 묵시적으로 T와 T? 중 적절한 자료형을 골라준다.

안전한 코드를 위해서는 T, T?이 일반적으로 권장될 것이고, T!은 objective-c id와 유사한 특성상 objective-c 브릿지에 널리 쓰이고 있다.

연산

!: T?을 optional이 아닌 T로 unwrap하는 후위연산자.

let opt: Int? = 5 // nil을 넣으면 아래 문장이 불법 let value = opt!

== nil, != nil: 원칙적으로 T?는 unwrap하지 않는 한 nil과만 비교할 수 있다. T!의 경우 nil과 비교하면 기본적으로 T?로 취급된다. (이전에는 그 자체로 nil이 아님을 표현하는 - 제정신이 아닌듯한 - Bool이었는데, 다행히 변경되었다)

if-let: optional이 nil이 아닌 경우 unwrap한 변수를 if 스코프 내에 만드는 if문

let opt: Int? = 5 // nil을 넣으면 else 블럭 실행 if let value = opt { // value는 Int, 이 안에서만 스코프가 살아 있다. } else { }

??: A ?? B는 A != nil ? A : B 라는 뜻이다.

let opt: Int? = value ?? default // value가 nil이라면 default를 대입

?. : obj.prop 대신 obj?.prop으로 프로퍼티에 접근하면 obj가 nil이면 nil을, nil이 아니라면 obj.prop의 자료형 T에 대해 결과를 포함한 T?를 반환한다.

let v1 = obj.prop // obj가 nil이면 크래시, nil이 아니면 T let v2 = obj?.prop // obj가 nil이면 nil, nil이 아니면 T? // obj가 nil이 아니라면 v1 == v2!

이상 ??와 ?.을 짬뽕하면 전통적으로 objective-c에서 nil에 대한 메서드 호출이 안전한 것 같은 동작을 흉내내서

let v = obj?.prop ?? default // obj 가 nil이 아니면 prop을, nil이면 default를 리턴

같은 게 된다.

id v = [obj prop] ?: default; // 와 등가

if-let 을 쓴다면

if let value = obj?.prop { // obj 가 T?인 경우 }

라던가 여러가지 변주가 가능

Swift를 쓰면 objective-c보다 nil 객체 처리가 장황하지 않냐던 사람이 있어서 설명 겸 정리.

이런 저런 걸 섞어 쓰다 보면 나는 LLVM 크래시는 덤이다. 버그를 회피하면서 코딩하면 결국은 장황해지는 건 사실.

[youknowone]

스위프트로 for-in 컨테이너 만들기

애플 스위프트 책에 for-in 컨테이너 만드는 법이 없다는 이야기가 있었다. Sequence 프로토콜을 구현하면 된다.

다음은 0부터 100까지 생성하는 시퀀스

class HundredContainer: Sequence { var count = 0; typealias GeneratorType = GeneratorOf<Int> func generate() -> GeneratorType { return GeneratorOf<Int>({ if self.count < 100 { self.count += 1 return self.count } else { return nil; } }) } } var c = HundredContainer(); for i in c { println(i) }

[youknowone]

목차 - 스위프트 프로그래밍 언어

훑어보기

안녕, 값

제어 흐름

함수와 클로저

객체와 클래스

열거형과 구조체

프로토콜과 확장

제너릭

언어

아직 없엉

[youknowone]

제너릭 - 스위프트 프로그래밍 언어

제너릭 함수나 자료형을 만들 수 있다.

func repeat<ItemType>(item: ItemType, times: Int) -> ItemType[] { var result = ItemType[]() for i in 0..times { result += item } return result } repeat("knock", 4)

다른 예제

// Reimplement the Swift standard library's optional type enum OptionalValue<T> { case None case Some(T) } var possibleInteger: OptionalValue<Int> = .None possibleInteger = .Some(100)

옮긴이: 오브젝티브-C의 고대전근대적 자료형 지옥에서 헤어나오신 것을 축하드립니다. 만세!

where로 프로토콜 구현 여부, 두 타입이 같을 것, 특정 수퍼클래스를 가질 것 등 조건을 지정할 수 있습니다.

func anyCommonElements <T, U where T: Sequence, U: Sequence, T.GeneratorType.Element: Equatable, T.GeneratorType.Element == U.GeneratorType.Element> (lhs: T, rhs: U) -> Bool { for lhsItem in lhs { for rhsItem in rhs { if lhsItem == rhsItem { return true } } } return false } anyCommonElements([1, 2, 3], [3])

단순한 경우에는 where 없이 <T where T: Equatable> 대신 <T: Equatable>으로 쓸 수 있습니다.

[youknowone]

프로토콜과 확장 - 스위프트 프로그래밍 언어

프로토콜

protocol로 프로토콜을 선언할 수 있다.

protocol ExampleProtocol { var simpleDescription: String { get } mutating func adjust() }

클래스, 열거헝, 구조체 모두 프로토콜을 적용할 수 있다.

class SimpleClass: ExampleProtocol { var simpleDescription: String = "A very simple class." var anotherProperty: Int = 69105 func adjust() { simpleDescription += " Now 100% adjusted." } } var a = SimpleClass() a.adjust() let aDescription = a.simpleDescription struct SimpleStructure: ExampleProtocol { var simpleDescription: String = "A simple structure" mutating func adjust() { simpleDescription += " (adjusted)" } } var b = SimpleStructure() b.adjust() let bDescription = b.simpleDescription’

SimpleStructure에는 구조체를 고친다는 표시로 mutating 예약어를 사용했다. 클래스는 항상 고칠 수 있으므로 SimpleClass에는 쓰지 않았다.

옮긴이: 오브젝티브-C의 프로토콜과도 비슷하고, 자바의 인터페이스나 C++의 순수 추상클래스의 개념과도 한층 더 가까워졌다. 오브젝티브-C에서 프로토콜은 2.0까지는 거의 카테고리 확장에 힌트를 주는 정도였다. (런타임에서 어떤 프로토콜을 구현했나 정보는 갖고 있지만 런타임에 구현되었다고 표시되어 있다고 꼭 구현되어 있다는 보장도 없었고, 역엔지니어링 밖에는 어떤 경우에도 쓰는 걸 본 적이 없다) 스위프트에서는 오브젝티브-C 3.0의 프로토콜 개념을 거의 그대로 가져가고 있다.

확장

extension으로 기존의 자료형에 기능을 확장할 수 있다. 다른 데 선언한 자료형은 물론이고 라이브러리나 프레임워크에 있는 자료형도 변경할 수 있다.

extension Int: ExampleProtocol { var simpleDescription: String { return "The number \(self)" } mutating func adjust() { self += 42 } } 7.simpleDescription

옮긴이: 오브젝티브-C의 카테고리 확장과 같은 개념이다. 하지만 역시 모든 타입을 확장할 수 있다.

프로토콜과 자료형

프로토콜을 자료형 이름처럼 쓸 수 있다. 이 경우 프로토콜 밖에 선언된 메서드는 사용할 수 없다.

let protocolValue: ExampleProtocol = a protocolValue.simpleDescription // protocolValue.anotherProperty // Uncomment to see the error’

[youknowone]

열거형과 구조체 - 스위프트 프로그래밍 언어

열거형

enum으로 열거 자료형을 만든다. 열거형에도 메서드를 만들 수 있다.

옮긴이: 비슷한걸 제공하는 주류 언어는 생각나지 않습니다… Rust..? 추가: ditto 님의 제보에 따르면 자바가 꽤 오래 전부터 지원한다고 합니다. 자바야 미안해...

enum Rank: Int { case Ace = 1 case Two, Three, Four, Five, Six, Seven, Eight, Nine, Ten case Jack, Queen, King func simpleDescription() -> String { switch self { case .Ace: return "ace" case .Jack: return "jack" case .Queen: return "queen" case .King: return "king" default: return String(self.toRaw()) } } } let ace = Rank.Ace let aceRawValue = ace.toRaw()

열거할 원래의 자료형과 첫 값은 명시해야한다. 이후의 값부터는 자동으로 순서대로 매겨진다. 문자열이나 부동소수점 열거형도 만들 수 있다.

toRaw와 fromRaw로 변환할 수 있다.

열거형의 멤버 값은 단순한 다른 이름이 아니라 실제의 값이다. 없는 값은 switch에서 다룰 필요가 없다.

enum Suit { case Spades, Hearts, Diamonds, Clubs func simpleDescription() -> String { switch self { case .Spades: return "spades" case .Hearts: return "hearts" case .Diamonds: return "diamonds" case .Clubs: return "clubs" } } } let hearts = Suit.Hearts let heartsDescription = hearts.simpleDescription()

예제에서 let hearts에서는 자료형을 추론할 수 없으므로 Suit를 포함한 전체 이름을 써야하지만 switch에서는 이미 자료형을 알고 있으므로 Suit는 쓸 필요가 없다.

구조체

struct로 구조체를 만든다. 메서드와 초기화를 포함해 클래스와 비슷한 동작을 지원한다. 구조체는 항상 값이 복사되고 클래스는 항상 참조만 전달된다는 것이 다르다.

옮긴이: 델파이의 record/class와 같은 정책이다.

struct Card { var rank: Rank var suit: Suit func simpleDescription() -> String { return "The \(rank.simpleDescription()) of \(suit.simpleDescription())" } } let threeOfSpades = Card(rank: .Three, suit: .Spades) let threeOfSpadesDescription = threeOfSpades.simpleDescription()

값이 있는 열거형

열거형은 연관된 값을 가질 수도 있다.

enum ServerResponse { case Result(String, String) case Error(String) } let success = ServerResponse.Result("6:00 am", "8:09 pm") let failure = ServerResponse.Error("Out of cheese.") switch success { case let .Result(sunrise, sunset): let serverResponse = "Sunrise is at \(sunrise) and sunset is at \(sunset)." case let .Error(error): let serverResponse = "Failure... \(error)" }

switch에서 각 enum 값에 연관된 값을 뽑아올 수 있다.

[youknowone]

객체와 클래스 - 스위프트 프로그래밍 언어

객체와 클래스

클래스 선언

class로 클래스를 만든다. 프로퍼티는 클래스 안에 있다는 점을 제외하면 상수나 변수 선언과 같다. 메서드는 함수와 같다.

class Shape { var numberOfSides = 0 func simpleDescription() -> String { return "A shape with \(numberOfSides) sides." } }

인스턴스 생성

클래스 명에 괄호를 붙여 인스턴스를 생성한다.

var shape = Shape() shape.numberOfSides = 7 var shapeDescription = shape.simpleDescription()’

초기화/종결화 함수

초기화 함수를 만들 수 있다.

class NamedShape { var numberOfSides: Int = 0 var name: String init(name: String) { self.name = name } func simpleDescription() -> String { return "A shape with \(numberOfSides) sides." } }

self로 name 프로퍼티와 실행인자를 구분한다. 모든 변수는 init이나 선언 중 하나에서 초기화가 되어야 한다.

옮긴이: self와 프로퍼티 정책은 오브젝티브C와 달라졌다. 이름 충돌이 없으면 name으로 멤버 변수에 접근할 것이다.

종결화 함수도 deinit으로 만들 수 있다.

서브클래스

이름 뒤에 콜론과 수퍼클래스를 쓴다. 루트 클래스는 없다. 수퍼클래스의 메서드를 덮어쓰는 메서드는 override로 표시해야한다. 표시하지 않으면 오류이다. 실제로 덮어쓰지 않는데 override가 표시된 경우도 오류이다.

옮긴이: NSObject, Object, TObject 등등 모든 객체가 상속해야 하는 표준 클래스가 없다는 뜻이다.

class Square: NamedShape { var sideLength: Double init(sideLength: Double, name: String) { self.sideLength = sideLength super.init(name: name) numberOfSides = 4 } func area() -> Double { return sideLength * sideLength } override func simpleDescription() -> String { return "A square with sides of length \(sideLength)." } } let test = Square(sideLength: 5.2, name: "my test square") test.area() test.simpleDescription()

프로퍼티

단순한 값으로 된 프로퍼티뿐 아니라 getter와 setter를 만들 수도 있다.

class EquilateralTriangle: NamedShape { var sideLength: Double = 0.0 init(sideLength: Double, name: String) { self.sideLength = sideLength super.init(name: name) numberOfSides = 3 } var perimeter: Double { get { return 3.0 * sideLength } set { sideLength = newValue / 3.0 } } override func simpleDescription() -> String { return "An equilateral triagle with sides of length \(sideLength)." } } var triangle = EquilateralTriangle(sideLength: 3.1, name: "a triangle") triangle.perimeter triangle.perimeter = 9.9 triangle.sideLength

perimeter의 setter에서 새 값은 묵시적으로 newValue라는 이름이 붙어있다. 바꾸고 싶으면 set 다음에 소괄호로 둘러싸고 이름을 넣어줄 수 있다.

init시 접근 순서에 주의:

서브클래스 프로퍼티 설정

수퍼클래스 초기화 실행

이제 수퍼클래스에서 정의한 프로퍼티 사용 가능

옮긴이: 프로퍼티 정책은 C#이나 델파이의 정책과 거의 비슷하다. 명시적 getter, setter는 완전히 C#과 같다. 오브젝티브-C 2.0 이상에서 멤버 필드를 전혀 사용하지 않고 프로퍼티만으로 프로그래밍을 해왔다면 그와도 비슷할 것이다.

프로퍼티 이벤트

프로퍼티를 계산할 필요는 없지만 바뀌기 전이나 후에 할 일이 있을 경우 willSet, didSet을 이용한다.

class TriangleAndSquare { var triangle: EquilateralTriangle { willSet { square.sideLength = newValue.sideLength } } var square: Square { willSet { triangle.sideLength = newValue.sideLength } } init(size: Double, name: String) { square = Square(sideLength: size, name: name) triangle = EquilateralTriangle(sideLength: size, name: name) } } var triangleAndSquare = TriangleAndSquare(size: 10, name: "another test shape") triangleAndSquare.square.sideLength triangleAndSquare.triangle.sideLength triangleAndSquare.square = Square(sideLength: 50, name: "larger square") triangleAndSquare.triangle.sideLength

옮긴이: 오브젝티브-C KVO에서 익숙하게 쓰던 패턴이다

메서드 이름

함수는 함수 값만으로 호출할 수 있지만 메서드는 첫 매개변수를 제외하면 반드시 메서드 매개변수 이름을 함께 붙여서 호출해야 한다.

class Counter { var count: Int = 0 func incrementBy(amount: Int, numberOfTimes times: Int) { count += amount * times } } var counter = Counter() counter.incrementBy(2, numberOfTimes: 7)

옮긴이: numberOfTimes는 메서드 시그내처의 일부인 셈이다. 오브젝티브-C의 메서드 작명과 호환되게 하려는 의도인듯.

선택적 자료형

선택적 자료형을 쓸 때 이름 뒤에 ?를 붙이면 nil이 아닐 경우 ? 이후부터는 무시된다. nil이 아니라면 값을 풀어(unwrap) 쓴다.

let optionalSquare: Square? = Square(sideLength: 2.5, name: "optional square") let sideLength = optionalSquare?.sideLength

[youknowone]

함수와 클로저 - 스위프트 프로그래밍 언어

함수, 클로저

기본 함수

func, 함수 이름, 괄호 안에 매개변수를 순서대로 써 로 함수를 선언한다. ->로 반환값 자료형을 선언한다.

func greet(name: String, day: String) -> String { return "Hello \(name), today is \(day)." } greet("Bob", "Tuesday")

투플 반환값

투플로 여러 값을 반환할 수도 있다

func getGasPrices() -> (Double, Double, Double) { return (3.59, 3.69, 3.79) } getGasPrices()

동적 인자

여러 값을 배열 꼴로 받을 수도 있다.

func sumOf(numbers: Int...) -> Int { var sum = 0 for number in numbers { sum += number } return sum } sumOf() sumOf(42, 597, 12)

내부 함수

함수 안에 함수를 겹쳐 만들 수 있다. 겹쳐 만든(nested) 함수는 바깥 함수의 변수에 접근할 수 있다.

func returnFifteen() -> Int { var y = 10 func add() { y += 5 } add() return y } returnFifteen()

옮긴이: 파스칼/에이다의 내부 함수와 동등하다. 일반 함수이므로 값을 캡처하지 않는다.

함수 자료형

함수는 일급 자료형이다. 다른 함수를 반환하거나 실행인자로 받을 수 있다.

func makeIncrementer() -> (Int -> Int) { func addOne(number: Int) -> Int { return 1 + number } return addOne } var increment = makeIncrementer() increment(7) func hasAnyMatches(list: Int[], condition: Int -> Bool) -> Bool { for item in list { if condition(item) { return true } } return false } func lessThanTen(number: Int) -> Bool { return number < 10 } var numbers = [20, 19, 7, 12] hasAnyMatches(numbers, lessThanTen)

클로저

함수는 클로저의 특수 사례이다. 중괄호({})로 감싸 이름 없이 클로저를 만들수 있다. in 으로 함수형과 코드를 분리한다.

numbers.map({ (number: Int) -> Int in let result = 3 * number return result })

자료형을 추론할 수 있는 경우 더 간편하게 쓸 수도 있다.

numbers.map({ number in 3 * number })

실행인자를 이름 대신 숫자로 접근할 수 있다.

sort([1, 5, 3, 12, 2]) { $0 > $1 }

[youknowone]

제어 흐름 - 스위프트 프로그래밍 언어

제어 흐름 (control flow)

조건문: if switch 순환문: for-in for while do-while

개괄

조건/순환 변수에는 소괄호를 쓰지 않아도 된다. 코드 몸통은 반드시 중괄호 안에 들어간다.

let individualScores = [75, 43, 103, 87, 12] var teamScore = 0 for score in individualScores { if score > 50 { teamScore += 3 } else { teamScore += 1 } } teamScore

if, if로 선택적 자료형 풀기

if문의 조건은 반드시 불린 표현식이다. if score { ... }는 오류.

선택적(optional)자료형의 경우 if와 let을 함께 쓸 수 있다.

※ 선택적 자료형이란? 어떤 값을 가질 수도 있고 가지지 않을(nil) 수도 있을 경우 자료형에 물음표(?)를 붙여 선택적 자료형을 표현할 수 있다.

옮긴이: Objective-C를 포함해 C계열 언어에서 널 접근 오류는 고질적인 런타임 오류였다. nil을 가질 수 있는 변수와 아닌 변수를 자료형 수준에서 엄밀히 나누어 명시적으로 변환하여 쓰도록 하여 논리 오류로 인해 널 접근을 하지 않도록 언어 수준에서 방어해 주고 있다.

var optionalString: String? = "Hello" optionalString == nil var optionalName: String? = "John Appleseed" var greeting = "Hello!" if let name = optionalName { greeting = "Hello, \(name)" }

선택적 자료형의 값이 nil이면 조건은 false로 평가해 건너뛴다. 값이 있다면 풀어내서(unwrap) let의 변수에 대입한다. 이 변수는 코드 블럭에서 쓸 수 있다.

switch

switch는 모든 자료형과 다양한 비교를 지원한다.

let vegetable = "red pepper" switch vegetable { case "celery": let vegetableComment = "Add some raisins and make ants on a log." case "cucumber", "watercress": let vegetableComment = "That would make a good tea sandwich." case let x where x.hasSuffix("pepper"): let vegetableComment = "Is it a spicy \(x)?" default: let vegetableComment = "Everything tastes good in soup." }

switch 안의 코드를 실행하고 나면 밖으로 빠져나온다. 다음 case로 진행하지 않으므로 명시적으로 break할 필요가 없다.

옮긴이: c 형식 switch에서 끔찍한 문제였던 명시적 break가 사라진다. let x where x.hasSuffix(“pepper”)에 주목해야 한다. case 안에서 다시 if문을 쓰는 식으로 처리하는 대신 보다 편리한 문법을 제공하여 명시적 break를 유용하게 사용하던 사례를 제거하고 있다.

for-in으로 딕셔너리에서 키-값 쌍을 순회할 수 있다.

let interestingNumbers = [ "Prime": [2, 3, 5, 7, 11, 13], "Fibonacci": [1, 1, 2, 3, 5, 8], "Square": [1, 4, 9, 16, 25], ] var largest = 0 for (kind, numbers) in interestingNumbers { for number in numbers { if number > largest { largest = number } } } largest

while, do-while

while로 특정 조건이 될 때까지 반복할 수 있다. 반드시 한 번은 실행하도록 할 수도 있다.

옮긴이: C계열 언어와 상동

var n = 2 while n < 100 { n = n * 2 } n var m = 2 do { m = m * 2 } while m < 100 m

for, for in

인덱스가 있는 순환문도 만들 수 있다. ..로 범위 를 만들수 있다. 다음 두 순환문은 동등하다.

var firstForLoop = 0 for i in 0..3 { firstForLoop += i } firstForLoop var secondForLoop = 0 for var i = 0; i < 3; ++i { secondForLoop += 1 } secondForLoop

..로 범위를 만들면 마지막 값이 빠지고 ...로 범위를 만들면 마지막 값도 포함된다.

[youknowone]

안녕, 값 - 스위프트 프로그래밍 언어

스위프트 프로그래밍 언어 - 요약본, Apple Inc.

하나 이상의 절차적 언어를 알고 있는 편이 좋습니다. 원문에서도, 번역에서도 기본적인 개념에 대해 설명하지 않고 있습니다.

Hello world.

println(“Hello, World”)

main 함수는 사라졌다. 세미콜론도 항상 쓰지는 않는다.

옮긴이: 파이썬, 루비 등에서 진입점 없이 첫 줄부터 코드로 보는 개념과 일치한다.

단순 값 (Simple value)

상수, 변수, 자료형 추론

let으로 상수를 만들고 var로 변수를 만든다.

var myVariable = 42 myVariable = 50 let myConstant = 42

자료형(type)을 항상 명시할 필요는 없다. 컴파일러는 myVariable 변수를 보고 첫 값인 integer로 변수 자료형을 추론(infer)한다.

명시적 자료형 선언

추론이 불가능한 경우 명시할 수 있다.

let implicitInteger = 70 let implicitDouble = 70.0 let explicitDouble: Double = 70

명시적 자료형 변환

값은 묵시적으로 다른 자료형으로 변환할 수 없다. 반드시 새 자료형의 새 인스턴스(instance)를 만들어야 한다.

let label = “The width is “ let width = 94 let widthLabel = label + String(width)

문자열 포맷 문법

문자열에 다른 값을 넣는 포맷 문법이 있다.

let apples = 3 let oranges = 5 let appleSummary = “I have \(apples) apples.” let fruitSummary = “i have \(apples + oranges) pieces of fruit.”

배열, 딕셔너리

배열과 딕셔너리는 대괄호([])로 만든다. 접근할 때도 대괄호([])에 인덱스나 키를 써서 넣는다.

var shoppingList = ["catfish", "water", "tulips", "blue paint"] shoppingList[1] = "bottle of water" var occupations = [ "Malcolm": "Captain", "Kaylee": "Mechanic", ] occupations["Jayne"] = "Public Relations”

옮긴이: 오브젝티브-C 3의 배열, 딕셔너리 단축표현이나 파이썬/루비/php5.4의 배열/딕셔너리를 연상할 수 있다.

빈 배열이나 딕셔너리는 초기화 문법으로 만듭니다.

let emptyArray = String[]() let emptyDictionary = Dictionary<String, Float>()

자료형 추론이 가능한 경우 []나 [:]로도 가능하다.

shoppingList = [] // 장보러 가서 뭐든지 담는다

[youknowone]

1BTC

내가 비트코인 까페에서 본 일이다.

누런 맥북을 든 거지 하나가 #bitcoin 에 접속해 떨리는 손으로 1 BTC가 든 주소 하나를 내놓으면서,

"황송하지만 이 주소가 못 쓰는 것이나 아닌지 좀 보아 주십시오."

하고 그는 마치 선고를 기다리는 죄인과 같이 다른 접속자의 말을 쳐다본다.

오퍼는 주소를 한참 보다가, 1 사토시를 송금해 보고

"좋소."

하고 말해 준다. 그는 '좋소'라는 말에 기쁜 얼굴로 맥북 힌지를 붙들고 절을 몇 번이나 하며 채널을 떠난다. 그는 뒤를 자꾸 돌아보며 클라이언트를 살피더니 계산대로 찾아 들어갔다. 맥북을 손에 쥐고 한참 꾸물거리다가 클라이언트가 켜진 화면을 내어 놓으며,

"이것이 정말 1BTC이오니까?" 하고 묻는다.

까페 주인도 호기심 있는 눈으로 바라보더니,

"이 코인을 어디서 해킹했어?"

거지는 떨리는 목소리로

"아닙니다, 아니에요."

"그러면 버려진 맥북을 길바닥에서 주웠다는 말이냐?"

"누가 그렇게 큰 돈이 든 맥북을 버립니까? 암호화는 안 하나요? 어서 도로 주십시오."

거지는 손을 내밀었다. 까페 주인은 웃으면서

"좋소."

하고 맥북을 내밀었다.

그는 얼른 움켜쥐고 가슴에 품고 황망히 달아난다. 뒤를 흘끔흘끔 돌아다보며 얼마를 허덕이며 달아나더니 별안간 우뚝 선다. 서서 그 맥북이 방전되지나 않았나 만져 보는 것이다. 거친 손가락이 누런 맥북의 배터리 잔량 단추를 누를 때 그는 다시 웃는다. 그리고 또 얼마를 걸어가다가 어떤 골목 으슥한 곳으로 찾아 들어가더니 벽돌담 밑에 쪼그리고 앉아서 맥북을 무릎에 놓고 들여다보고 있었다. 그가 어떻게 열중해 있었는지 내가 가까이 선 줄도 모르는 모양이었다.

"누가 그렇게 많이 도와 줍디까?"

하고 나는 물었다. 그는 내 말소리에 움찔하면서 맥북을 덮었다.

그리고는 떨리는 다리로 일어서서 달아나려고 했다.

"염려 마십시오, 뺏어가지 않소."

하고 나는 그를 안심시키려 하였다.

한참 머뭇거리다가 그는 나를 쳐다보고 이야기를 하였다.

"이것은 훔친 것이 아닙니다. 맥북을 주운 것도 아닙니다. 누가 저 같은 놈에게 1BTC를 줍니까? μBTC 한 번을 받아 본 적이 없습니다. 사토시 하나 주시는 분도 백에 한 분이 쉽지 않습니다. 저는 한 푼 한 푼 얻은 코인에서 몇 μBTC씩 모았습니다. 이렇게 모은 돈이 mBTC가 되었습니다. 이러기를 일천 번을 하여 겨우 이 귀한 'BTC' 하나를 갖게 되었습니다. 이 코인을 얻느라고 여섯 해가 더 걸렸습니다."

그의 뺨에는 눈물이 흘렀다.

나는 "왜 그렇게까지 애를 써서 그 코인을 만들었단 말이오? 그 코인으로 무얼 하려오?"

하고 물었다. 그는 다시 머뭇거리다가 대답했다.

"소수점이 아닌 BTC 한 개가 갖고 싶었습니다."

[youknowone]

UI7Kit - 0.0.1에서 1k starred repo까지

지난 두 달간 UI7Kit1에서 겪은 경험은 특별한 것이었다. 잊지 않기 위해 정리해 본다.

시작

지금까지 (앱 만드는 주제에) 한번도 iOS나 OS X의 미리보기 버전을 설치해 본 적이 없었는데, iOS7은 시뮬레이터로 좀 구경이나 해보려는 마음으로 WWDC 이후 나온 따끈따끈한 Preview1을 설치해 보았다.

몇 GB짜리 xcode5를 다운받고 설치하느라 좁은 SSD 정리만 한참을 했는데2, 기본 앱을 이리저리 구경하고 나서는 그다지 해볼 만한 게 없었다. 시뮬레이터에는 원래 기본 앱이 다 든 것도 아니고, 기본 앱이 iOS의 모든 컨트롤을 쓰고 있는 것도 아니니까. 그래서 그 다음에는 이전에 개발한 앱들이 iOS7에서 어떻게 보이나 하나씩 돌려보기 시작했다. 회사에서 개발 중인 게임들은, status bar가 겹쳐서 나오는 문제를 제외하면 전혀 문제가 없었다. 게임이야 모든 화면을 게임 엔진이 그려주니 그럴법 하다.

그 다음에는 내가 만든 앱을 하나씩 올려보기 시작했다. 그런데 이게 웬걸. 첫 앱부터 말썽을 부리기 시작했다. 범인은 FoundationExtension3이었다. Foundation이나 UIKit의 빠진 기능을 채우자고 만들기 시작한 프로젝트인데, 그 '빠진 기능' 가운데 하나로 넣은 심볼이 iOS7 UIKit에 실제로 들어가 버린 것. FoundationExtension을 잽싸게 패치하자 제대로 빌드가 되기 시작했다.

앱들은 뭐 그냥... 처참했다고 해두자. FoundationExtension에는 UUID 동작을 iOS 버전별로 적당히 골라 호출해 준다거나 하는 구현도 들어 있었는데, 여기서 아이디어가 떠올랐다. iOS7의 UI을 기본으로 이전의 OS에 호환성을 제공하면 이 인기 없는 프로젝트에도 볕이 들 날이 오지 않을까? FoundationExtension에는 UIKit7이라는 타겟과 브랜치가 추가되고 간단한 구현이 들어가기 시작했다.

첫 버전

가장 널리 쓰이는 기능이 첫 목표로 정해졌다. 모든 앱에는 navigation bar는 들어간다. 그리고 최소한 내가 만든 모든 앱에는 table view가 들어간다. 일단 navigation bar와 table view가 들어간 앱을 하나 만들어야겠는데, 빨리 기능을 테스트해보고 싶은 생각에 급한 김에 FoundationExtension 기능 테스트에 쓰던 앱을 그냥 패치하기 시작했다. 지금도 이 버전 기반의 테스트 앱이 아직 쓰이고 있다.

navigaiton bar의 눈에 보이는 부분 구현은 생각보다 쉬웠다. 애플은 iOS5에 navigation controller를 원하는 navigation bar와 toolbar로 생성할 수 있는 API를 추가했다.4 여기서 최소 지원 버전이 iOS5로 정해졌다.5 UINavigationBar를 상속한 UI7NavigationBar를 만들고 UI7NavigationController를 만들어 모든 초기화 함수에서 항상 navigation bar를 교체하도록 오버라이드 했다. 결과는... 일단 안 돌아갔다. Interface Builder를 사용하면 모든 컨트롤은 Interface Builer에 지정된 클래스로 초기화된다. 결국 손으로 UINavigationBar를 찾아 클래스를 바꿔주어야 했다. 기술에 관한 이야기를 좀 장황하게 했는데, 꽤 중요한 부분이다. Interface Builder에서 매번 클래스 이름을 바꾸는 것이 참을 수 없을 정도로 귀찮았기 때문에, 이건 아무리 결과가 잘 나와도 나라면 쓰지 않을 라이브러리였다. 쓰기 더 쉽고 더 간단해야 했기 때문에, UI7Kit은 두 번째 목표를 정했다. "기존의 UIKit을 동적으로 패치해서 귀찮은 작업 없이 UI7Kit이 동작하게 만들 것". Objective-C는 C처럼 보이지만 동적 언어이다. 런타임에 클래스와 메소드를 교체하고 고칠 수 있다. 앱이 UIKit을 불러온 다음 UIKit의 구성요소를 모두 UIKit과 호환되는 UI7Kit으로 바꿔 넣으면 앱이 보기에 UIKit은 UI7Kit과 구분되지 않는다. 앱은 마치 iOS7에서 돌아가는 것 처럼 iOS6에서 돌아갈 수 있다. 이름도 이때 UI7Kit으로 바꿨다. 헤더를 찾을 때(UIKit7)와 각 클래스에 접근할 때(UI7-) 어디 7이 들어가나 몰라 헷갈리는 게 너무 싫었다.

navigation bar와 비교하면, table view는 꽤 고통스러운 작업이었다. 먼저, cell과 section은 table view의 핵심 구성요소이다. cell은 UITableViewCell을 패치하면 된다. 그런데 table view만 고쳐서 section header와 footer를 고칠 방법이 어딜 봐도 없었다.6 section header와 footer는 delegate와 dataSource에서 조금씩 나뉘어 처리된다. 결국 나는 delegate와 data source가 설정되는 순간 이것들을 패치해 iOS7의 동작을 흉내내 보기로 했다. delegate와 data source는 UIKit의 구성요소가 아닌 사용자가 정의하는 부분이기 때문에, 무슨 일이 일어날 지 알 수가 없다. 그저 사용자가 예측을 벗어난 특별히 이상한 일을 하지 않기를 바라기로 했다.7 Objective-C에서 서로 엮인 두 개 이상의 메소드를 동적 패치하는 것은 처음 해 보는 일이었다. 끔찍한 일이었다. 코드는 충분히 장황했고, 예제가 겨우 돌아가는 코드를 만들었다.

겨우 컨트롤 두 개를 붙였는데, 이미 코드의 규모나 형태는 "FoundationExtension의 신기한 기능으로 집어넣는다"에서 많이 벗어나 있었다. FoundationExtension은 "꼭 있어야 할 것 같지만 애플이 빠뜨린 기능의 확장"을 철학으로 삼는데, 여기에 맞지도 않았다. 프로젝트는 분리되어야 했다. 여기서 새로 패키지를 만든 것이 UI7Kit의 첫 버전인 0.0.1이다. 충분히 멋진 기능이고, 누구나 꿈꿀만한 목표라는 생각이 들었다. 밤이 늦었지만 다음 날이 되면 누군가 비슷한 목표의 프로젝트를 만들 것 같은 기분이 들어 기다릴 수가 없었다. 게다가 그 날은 WWDC 이후 이틀이 지난 때였는데, 하루를 더 보내는 것은 그냥 하루라기보다는 내가 보낸 시간의 50%를 허비하는 것처럼 느껴졌다. 눈길을 끌 만한 소개와 자료를 만들기 시작했다. 이 첫 버전은 지금 보면 거의 훌륭한 사기에 가까운 느낌이 드는데, 4천줄 정도의 코드로 상당히 많은 컨트롤을 지원하게 된 지금이나 600줄 정도의 코드에 눈에 보이는 첫 화면을 겨우 처리하는 그 때나 스크린캡처를 본 첫 느낌은 큰 차이가 없기 때문이다.

문제의 스크린캡처. 훌륭해 보인다. 하지만 어떤 버튼을 누르더라도 실망했을 것이다. (이 버전을 보고 10초만에 감탄과 실망을 하는 사람을 직접 보았다)

업로드

프로젝트를 만들자마자 커밋도 하기 전에 구름옥상 위에서 코딩하는 도인8 께서 관심을 보이셨다. (쓰고 있으신지는 잘 모르겠다)

내가 만든 Objective-C 프로젝트는 보통 CocoaPods에 업로드한 이후에 CocoaPods을 통해 쓰는 사람이 생기는 경우가 많았기 때문에, 이번에도 제일 먼저 CocoaPods으로 패키징을 했다.9 제대로 돌아가지 않는 프로젝트를 CocoaPods에 올리는 것은 처음이라, 직접 푸시하지 않고 풀 리퀘스트를 보냈다.10 CocoaPods 풀리퀘스트를 보고 프로젝트를 찾아오는 사람도 조금 있지 않을까 하는 바램도 있었다. 실망스럽게도(?) 풀 리퀘스트는 꽤 빨리 처리되었는데, 의외의 효과를 보게 되었다. CocoaPods는 새 프로젝트를 소개하는 트위터 계정[^CocoapodsTwitter] 을 갖고 있다. 이 CocoaPods 트위터는 생각보다 많이 주목받고 있었고, UI7Kit은 CocoaPods 트위터에서 소개되며 상당히 빠르게 알려지게 된다.11 레딧의 iOSProgramming 서브레딧에도 소개를 올렸는데, 트위터에 비하면 크게 주목받지는 못했다. 몇 시간 뒤에는 github trending repos에 올라갔다.12

이런 주목은 살짝 당황스럽기도 한 것이었는데, 아마 "응당 받아야 할 것 이상을 받고 있다" 같은 느낌이었던 것 같다. (사실 잘 모르겠지만) 이유를 생각해 보자면, 먼저 WWDC 직후인데다 인터넷에는 한참 iOS7에 관한 찬사와 비난이 끝없이 쏟아지고 'Jony Ive redesigns ~'가 한창 인기여서 좋은 의미로든 나쁜 의미로든 iOS7의 UI에 관한 관심이 최고조에 달했을 때였다. 둘째로는 스크린캡처가 내 기대보다도 더 훌륭했다.13 아마 대부분은 프로젝트를 실행해보지 않았을 것이다. 심지어 이미 상당한 구현이 되어 있다는 기사14도 나왔다. 프로젝트의 목표와 스크린샷을 보고 사람들이 어떻게 판단했을지 짐작할 만하다.

이후에는 프로젝트 소개를 위해 해커뉴스15 에 프로젝트를 올리거나, 소개 영상을 만들거나, Cocoa Controls16 에 소개를 올리기도 했다. 먼저 해커뉴스는, 전반적으로 프로젝트 페이지 자체를 홍보하기에 적합한 인상은 아니다. 많은 점수를 받는 링크는 보통 '흥미로운 기사거리'에 적합한 특징을 가진 링크다. 하지만 트위터와 레딧에서의 반응으로 프로젝트 페이지 자체가 적당한 흥미거리가 될지도 모른다고 생각해 일단 시도해 보게 되었다. 지금 생각하면 프로젝트 페이지보다 다른 사람이 쓴 기사를 링크하는 게 나았을지도 모르겠다는 생각이 든다. 이 링크도 어느 정도의 홍보 효과를 거두었지만, 그리 큰 효과는 아니었다.11 해커뉴스 자체보다는, 해커뉴스를 통해 트위터와 해커뉴스를 인용하는 사이트를 중심으로 알려졌다고 보는 것이 더 적당한 해석이라고 생각한다.

소개 영상은 어느 정도 준비가 갖춰진 후에 동적 패치의 간단함에 초점을 맞추어 만들어졌다. "신기하다" 정도의 반응으로 공유되기를 기대했지만, 그렇지 않았다. 유명한 소프트웨어도 아니고, 놀라운 결과가 나타나는 것도 아니고(UI7Kit은 결과보다는 과정의 놀라움이 크다), 꼭 써야해서 볼 필요가 있는 것도 아니다. 하지만 Github 이슈에 접근하지 않는 사용자를 위한 질문 창구의 역할 정도는 한 것 같다. 17

한편 Cocoa controls는 전체적으로 뜻밖의 경험의 연속이었다. 나는 GUI에 관련된, 스크린샷을 보고 써 보고 싶어질 만한 라이브러리는 만들어 본 적이 없었기 때문에, Cocoa controls에 프로젝트를 등록해 본 것은 이번이 처음이었다. Cocoa controls는 살짝 당황스러운 등록 정책을 갖고 있었다. 사이트의 메인 메뉴에 Cocoapods이 있고, 대부분의 컨트롤이 Cocoapods 설치를 기본으로 갖고 있어 막연히 Cocoapods와 비슷하겠거니 생각했지만, 전혀 그렇지 않다.18

내가 처음 UI7Kit을 Cocoa controls에 등록했을 때, 44개의 프로젝트가 큐 되어 있다는 알림이 나타났다. 그리고 이 수는 하루에 일정 수 이상은 줄어들지 않았다. 그래서 거의 비슷한 시기에 등록했음에도 불구하고, Cocoa controls에서 실제로 프로젝트가 노출되기 시작한 것은 상당한 시간이 지난 뒤였다. 한편, 그런 정책 때문에 오랫동안 전면에 노출되어서인지는 몰라도, Cocoa controls에 프로젝트가 노출된 이후의 효과는 상당했다.11 Cocoa controls의 모든 프로젝트는 운영자가 직접 확인 후 승인하는 과정을 거치는 것 같다. UI7Kit이 마음에 들었는지 아니면 정적인 스크린샷이 프로젝트에 대해 불충분한 정보를 준다고 생각했는지는 몰라도, 테스트 앱이 동작하는 비디오도 하나 만들어 주었다.19

더 놀라운 것은 그 다음 주에 일어났다. Cocoa controls에서는 Controls of the week을 선정하고 있었다. 20 사이트 안에서는 접근성이 나쁜 블로그에서 운영되는데도 파급효과는 큰 편이었다. 11 Cocoa controls의 메인은 최근에 올라온 프로젝트에 초점을 맞추거나 등록된 프로젝트를 찾아보기 좋게 되어있다. 그리고 선정된 컨트롤은 Cocoa controls의 트위터를 중심으로 공유된다.

글을 쓰던 중인 최근에는 Bountysource라는 오픈소스를 위한 펀드를 모으는 서비스에도 등록을 해보았다.21 IRC 채널에서 친절한 상담을 받으며 이용 중이며, 끝나는 대로 내용을 추가해 보도록 하겠다.

업로드 - 정리

영어권에서 접근할 수 있는 Objective-C 프로젝트의 주요 공유 경로는 트위터라고 밖에는 생각할 수 없다. 그리고 개발자 커뮤니티에 효과적으로 트윗을 전달할 수단을 갖고 있지 않다면, 효과적인 트윗을 만드는 방법은 Cocoapods나 Cocoa controls라고 생각된다. 나는 아마 앞으로 어떤 Objective-C 라이브러리를 만들더라도 Cocoapods와 Cocoa controls를 최우선으로 고려할 것이다. 해커뉴스에 올렸던 글도 해커뉴스에서는 빠르게 사라졌지만 해커뉴스를 인용하는 트위터를 중심으로 상당한 공유가 이루어졌다.

단, Cocoapods은 간단한 링크와 소개만 트윗하므로 이름과 짧은 소개로 매력적인 프로젝트 소개를 전달할 수 있도록 해야 한다. Cocoa controls는 대기에 가장 오랜 시간을 써야 하므로, 프로젝트가 완성되지 않았더라도 일단 등록하여 대기열에 올려두고 그 전까지 적당한 퀄리티로 만들어 내는 것이 중요하다. 둘 모두 한 프로젝트는 한 번밖에 쓸 수 없는 기회이다. 필요하다면 가능한 최고로 매력적인 시점까지 공유를 연기하는 것도 한 가지 방법일 수 있다.

영상은 눈길을 끄는 영상을 제공하지 못하는 한 큰 쓸모는 없어 보인다. 해커뉴스는 흥미로운 기사를 위한 곳이다. 사람들이 좋아할 만한 기사를 제공하는 것이 중요하다.

영어를 제외한 언어 중에서는 일본어와 중국어로 가장 많은 내용이 공유되었다. 그리고 내가 직접 올린 소개 이외에 번역된 소개가 공유되는 곳도 일본어과 중국어로 된 곳이 대부분이다. 중국어와 일본어를 몰라서 어떤 내용이고 어떤 경로로 알려진 것인지 확인하기는 어려웠다. 하지만 가능하다면 활용할 수 있는 방법을 찾아보는 것도 좋겠다.

안타깝게도 한국어로 된 내용은 거의 보지 못했다.

Cocoapods

Cocoapods은 이래저래 고민거리를 많이 던져주었다. 일단 나 스스로는 master spec 외에도 별도로 private spec을 운영하며 가능한 모든 코드를 Cocoapods으로 패키징하고 있다. Xcode에서 코드가 꾸준히 업데이트 되는 외부 라이브러리를 다룰 방법이 거의 없기 때문이기도 하고, ARC 옵션이나 리소스를 관리하는 가장 쉬운 방법이기 때운이기도 하다.

하지만 많은 사람에게 Cocoapods는 장벽이기도 하다.22 일단 첫 설치가 어렵다. (아마도 아직 Cocoapods를 사용하지 않은 대부분의 사람들은) 한 번도 안 써본 rubygem을 써야하고, rubygem으로 Cocoapods를 설치한 이후에도 master spec을 초기화해야 한다. (이 부분이 왜 필요한 지 설명하는 것도 어렵고 설명하지 않고 헷갈리지 않게 실행하도록 돕기도 어렵다.) Podfile은 템플릿으로 생성되지 않아 문법을 알고 있어야 하며, iOS SDK 버전을 명시하지 않으면 뭘 해야 할지 모를 에러도 발생한다. 이 모든 장벽을 넘어 Cocoapods을 사용 중이던 사람들에게도 문제는 남아있었다. Cocoapods의 이전 버전을 쓰며 다른 프로젝트와 함께 쓰면 문제가 생기는 등 추적하기 어려운 문제도 있었다.

나는 README의 한 절과 두 번째 영상의 대부분을 Cocoapods를 한 번도 쓰지 않은 사용자가 하나씩 따라올 수 있도록 하는데 소비했다. 그런데도 충분히 쉽지 않다. 게다가 사람들은 Cocoapods과 잘 모르는 프로젝트에 이중의 거부감을 가지고 프로젝트를 대하게 된다. 조금만 어려워도 "안 쓰고 말지" 라고 생각하기 쉽다.23 어떻게 이 장벽을 넘을 수 있을지 모르겠다. Cocoapods 없이도 프로젝트에 일단 접근할 수 있도록 따로 패키징을 해야할까? 파일이 하나거나, 아니면 소스코드만 포함해도 된다면 문제가 조금 더 쉬웠을지도 모르겠다. Cocoapods로 된 의존성이 있고, 리소스 파일도 수십 개씩 들고 다녀야 하는 상황에서는 개발에 쓸 시간을 낭비하지 않고 이 문제를 해결할 좋은 방법이 떠오르지 않는다.

진행

UI7Kit은 야간에, 주말에 조금씩 작업되고 있다. Bountysource에 제안을 쓰며 목표를 정리하고 우선순위를 정하고 있는데, 일단은 "인터페이스 빌더에서 아무 컨트롤이나 막 끌어다 놓고 iOS6로 실행하면, iOS7처럼 보이게 해준다"가 UI7Kit 1.0의 주 목표이다.

지금까지는 작업 우선순위를 그냥 내키는 대로 잡았지만, 앞으로는 회피할 수 있는 문제나 크게 문제 없이 넘어갈 수 있는 빠진 구현은 뒤로 미루고 특정 앱에서는 아예 쓸 수 없게 만들만한 큰 문제부터 다루어야겠다고 생각만 하고 있다. 언제나 그렇듯이 이슈가 쌓이면 닫고 싶고, 특히 그게 어떻게 손대야 할 지 막막한 일 대신 라인 단위로 구현할 코드가 떠오르는 쉬운 일이면 더욱 그렇다. 게다가 닫을 사람이 나 밖에 없다는 느낌은 쌓이는 이슈 갯수는 더욱 참고 볼 수 없게 만든다.

UI7Kit을 만들며 뼈저리게 느끼는 것은 시간이 정말, 정말, 정말 부족하다는 것이다. 올해 초에 Rust 패치 몇 개를 만들며 생각보다 진도가 잘 안나가 답답하게 느꼈던 기억이 난다. 나름 익숙한 작업으로 돌아와서도 똑같은 증상을 겪다 보니, 문제가 정말로 시간 부족이라는 것을 깨닫고 있다. UI7Kit을 시작하며 아직 완성되지 않은 덜 만든 것들에 대해서는 미련을 싹 버리고 중지시켰다. 하지만 이미 만든 것에 대한 버그 리포트까지 무시하기는 꽤 어려운 일이다.24 UI7Kit은 UI 복제구현과 Objective-C 동적패치를 한다. 둘 모두 노동집약적인 프로그래밍이다. 다른 작업을 하느라 시간을 뺏기고 나면, 그 주에는 금방 commit 수 그래프가 뚝 떨어지게 된다.25 1.0이 iOS7 출시 이전의 현실적인 목표이길 바란다.

현재 버전이라고 하고 싶은데, 새로 작업한 내용을 아직 스크린샷에 반영하지 못했다.

마무리

사실, 글을 처음 쓰기 시작할 때는 UI7Kit 의 구현에 관한 이야기와 관련된 기술적인 이야기도 함께 다루어볼 요량이었다. 하지만 글이 생각보다 길어져 버린데다 뒤로 갈수록 졸렬해지고 있고, 이 글의 첫 줄을 쓴 지도 이미 4일이 지났고, 글만 쓸 수도 없으니 나머지 이야기는 다음으로 미루어야겠다. 심심할 때마다 짧은 글로 한 편씩 쓸 수 있지 않을까 생각하고 있다. 구현에 관한 이야기는 쉽게 잊지도 않을테고 git log로 쉽게 회상할 수도 있을테니까.

https://github.com/youknowone/UI7Kit UI7Kit은 iPhoneOS의 첫 버전에서부터 크게 변하지 않았던 iOS의 UI가 iOS7에서 갑자기 바뀐 충격(?)을 어느정도 흡수해주는 라이브러리이다. 이전 버전의 iOS 앱들을 iOS7 앱처럼 보이게 만들어 UI를 버전 별로 두 벌 관리하거나, 서로 다른 버전의 OS에서 똑같이 보이게 하기 위해 많은 노력을 들이지 않을 수 있도록 도와준다. ↩︎

XCode4가 만든 derived data 디렉터리가 10GB가 넘어가 있었다. 그 이후로 어제 Preview4를 받느라 다시 한번 지웠는데, 그동안 다시 4GB가 되어 있더라. SSD에 두자니 덩치가 크고 하드로 옮길수도 없고 이거 참...... ↩︎

https://github.com/youknowone/FoundationExtension/ 문제의 커밋은 이것 ↩︎

initWithNavigationBarClass:toolbarClass ↩︎

나중에 알게 된 것인데, iOS5 아래는 지원할래야 할 방법이 없다. UI을 새로 그리기 위한 API의 대부분이 iOS5에서 추가되었다. 한참 아이폰 앱 만들던 때만 해도 iPhoneOS3 호환을 포기할 수 없던 때였기 때문에, iOS SDK에 대한 내 기억은 거의 iPhoneOS3 시절에 머물러 있다. 그래서 모두 UI7Kit을 개발하면서 처음 안 기능인데, 낡은 UI 문제에 관해 어쨌든 애플이 놀고 있진 않았다는 생각이 들었다. "iPhoneOS가 나온 이래 UI가 거의 바뀌지 않았다"라고 했지만, 최근에는 어쨌든 컨트롤을 커스터마이즈하려는 개발자들의 욕구를 어느 정도 들어주는 편이었던 셈. 그리고 iOS7이 나온 이후의 현실적인 iOS 최소버전이 iOS5가 될 것이라는 점을 생각하면, iOS5에서 iOS7과 UI를 맞출 수 있다는 것은 중요한 문제다. iOS6때 UI가 바뀌었다면, 많은 개발사와 개발자들이 iOS4.3 지원이냐 새 UI냐의 갈림길에서 고통받았을테고, 수 많은 외주 개발자들이 iOS4.3 지원과 새 UI 처리를 동시에 요구받으며 이미지와 버튼만으로 '갑'의 디자인을 소화하느라 진땀 뺐을테다. ↩︎

지금 이 문제를 만난다면, section과 관련된 private class를 하나씩 패치해 볼 것 같다. 하지만 두 달 전에는 지금보다 기교가 많이 떨어지는 상태였고, 그런 생각은 전혀 나지 않았다. ↩︎

하지만 결국 지금, UITableView를 해킹하는 또 다른 라이브러리인 Sensible table view와 함께 쓰면 문제를 일으키고 있다. 아직 왜 그런지는 살펴보지 못했다. ↩︎

나는 사실 저장소를 만들고 첫 릴리즈를 하고 나면 "아 내가 이런 멋진 걸 만들다 말았지만 속세의 사람들은 몰라줄테니 스스로 Star로 이 수고를 치하하리로다" 라고 하고 수줍게 Star를 누른다. 하지만 내가 만든 프로젝트 중 가장 인기있는 프로젝트에서 혼자 짝짜꿍할 기회는 도인(@lqez)께 뺏겼다. ↩︎

cocoapods.org Xcode + Objective-C 환경에서 쓰는 라이브러리용 패키지 매니저이다. CocoaPods 없는 Xcode는 MacPorts와 homebrew 없는 OS X가 되니 꼭 써야 한다. OS X를 안 쓰는 사람들을 위해서라면, 데비안에 aptitude가 없고 레드햇에 yum(은 커녕 rpm도)이 없는 그런 느낌이다. ↩︎

CocoaPods는 푸시 권한 정책이 매우 관대한 편이다. 문제 없는 spec을 몇 개 보내면 바로 권한을 준다. 반대로 이야기하면, 푸시 권한은 있지만 뭘 푸시해도 되는지 잘 모르기 때문에 확신이 없으면 풀 리퀘스트를 보내게 된다. 풀 리퀘스트 ↩︎

gitego.com/youknowone/ui7kit 첫 24시간동안은 추적되지 않았다. 그래프에서 주요 포인트로 첫 부분과 변곡점 셋이 있는데, 맨 처음이 CocoaPods 트위터 + iOSProgramming subreddit + github daily trend, 16 June이 hackernews, 15 Jul이 cocoacontrols, 22 Jul이 cocoacontrols의 control of the week이다. gitego 덕분에 프로젝트의 주요 지표로 Star를 사용할 수 있게 되었다. github 프로젝트 페이지의 pv를 확인하거나 저장소를 클론한 수를 추적할 수는 없기 때문이다. ↩︎ ↩︎ ↩︎ ↩︎

이 영광은 집을 사는 날 액자에 걸어 가보로 남기도록 하겠다. 집이 충분히 클 때만... ↩︎

스크린 캡처는 물론 실제로 동작하는 시뮬레이터의 캡처였지만, 그 이상은 아니었다. 심지어 화면에 보이는 테이블 뷰 셀을 눌러 다른 화면으로 들어가면, 뒤로 버튼조차 바뀌지 않았다. 나도 cocoacontrols를 둘러보면 실제로 프로젝트를 실행해 보기 전에 어떤 프로젝트는 괜찮아 보이고 어떤 프로젝트는 그렇지 않아 보인다고 대충 미리 판단을 하고 실제로 그게 필요해지기 전까지는 써 보지 않는다. 그러니까, 결국 대부분은 써 보지 않으므로 프로젝트의 가치는 결국... ↩︎

New Open Source Project Bringing iOS 7 Style To iOS 5 and 6 UIKit Interfaces 괜찮아. 이제 정말로 거의 다 되니깐. ↩︎

Hacker news ↩︎

Cocoa Controls는 OS X나 iOS의 UI 컨트롤을 업로드할 수 있는 사이트이다. 운영자가 직접 리뷰하고 승인한다. Cocoapods와 깊은 관계가 있는 것 같은 인상을 느끼는 사람이 많지만, 컨트롤을 업로드하거나 이용하는 과정 자체는 그렇지 않다. ↩︎

글을 쓰는 현재 영상 2개의 조회수는 합쳐서 550회 정도이다. ↩︎

Cocoapods는 소스코드를 등록하고 의존성 관리를 도구를 이용해 할 수 있도록 돕는다. 올라온 프로젝트가 외부로 공유되는 경로는 트위터 뿐이다. Cocoapods에서는 올라온 풀 리퀘스트를 점검하고 머지하기는 하지만, 프로젝트를 평가하지는 않는다. 한편 Cocoa controls는 개발을 보조하는 툴이라기 보다는 반쯤은 큐레이트에 가깝다. Cocoapods에 등록되어 있을 필요도 없고 소스가 공개되어 있을 필요도 없다. 비록 사용자가 올린 프로젝트만 대상으로 하지만, 마음에 드는 프로젝트를 선정하고 공유하기도 한다. ↩︎

Cocoa controls - UI7Kit Video는 원래 없는 탭인데, 프로젝트가 마음에 들었는지 정적인 스크린샷이 프로젝트를 잘 드러내지 못한다고 생각했는지는 몰라도 영상을 만들어 주었다. 감사합니다. ↩︎

Cocoa contorls blog - UI7Kit 블로그에서는 댓글 등의 활동이 일어나지는 않는다. 하지만 Control of the week은 트위터의 @cocoacontrols 계정에서 공유되고, 이 트윗에 대한 반응은 적지 않다. ↩︎

Bountysource - UI7Kit Bountysource는 gittip 느낌의 오픈소스를 위한 fundraising 서비스이다. 생긴 지 얼마 되지는 않은 것으로 보인다. ↩︎

Cocoapods와 관련된 이슈만 4개였던 것 같다. ↩︎

나는 Objective-C 라이브러리가 Cocoapods으로 배포되거나 최소한 Xcode에서 library target으로 정리되어 있지 않으면 엄청나게 귀찮아지면서 이리 저리 미루다 다른걸 먼저 해보거나 그마저도 없으면 그냥 다른 일을 먼저 찾는다. 그걸 다시 해 보러 돌아오는 때는 지금 당장 꼭 해야할 때이다. 아마 Cocoapods를 처음 쓰는 사람은 비슷한 느낌을 받을 것이다. ↩︎

어... 그러니까 이렇게 말하면 누군가 예외를 알고 있다는 눈빛으로 쳐다보겠지만... 그게 거기엔 나름의 변명이... ↩︎

UI7Kit graph ↩︎