우리동네에서 책을 읽으며...

 

안녕하세요 린생입니다.

 

이 책을 읽으면서 많은 생각을 하게 되었다

닉네임이 린생(인생) 이것처럼 나만의 레버를 당긴 앤드류의 이야기가 궁금했다.

 

여기서 레버라고 하는 것은 우리들에게는 쉽게 표현해 도전이라는 말로 대체가 될 수 있을 거 같다.

하지만 여기서 말하는 나만의 레버가 모든 도전을 말하고 있는 것이 아니라는 것을 책을 읽으면서 알게 되었다

 

단순히 유튜브와 드로유앤드류의 이야기를 들어보면 이게 무슨 이야기인지 다들 알것 같다

 

책을 읽고 리뷰를 쓰는 것이 내 인생에 두 번째인 거 같다.

 

내 인생의 러키 드로우

위의 제목은 이 책을 시작하면서 나오는 첫 문장이다.

 

나는 아직 레버를 당기지 못했다.

하지만 레버를 당기고 싶다. 

 

내가 왜 나는 레버를 당기지 못했지...?

앤드류와 나의 차이는 무엇일까...?

 

나는 이 책을 읽고 나와 앤드류의 차이는 생각, 행동 이 두 가지에서 차이가 있다고 생각했다.

 

처음 경제를 공부하기로 마음을 먹고 많은 투자책을 다들 추천했지만 나는 럭키 드로우라는 책을 선택했다.

 

흠... 

 

내 주변 사람들에게 내가 경제 공부를 하고 있다고 말을 하면 대부분 어떻게 공부하는지를 묻어보곤 한다.

나는 책을 읽는 걸로 시작하고 있다고 대답을 한다. 그래서 어떤 책을 읽고 있는지 물어보면서 자신도 읽겠다고 하는 사람들이 많았다.

하지만 그들은 그 책을 다 읽지 않고 중간에 다른 주제의 책을 읽거나 다른 행동을 했다. 

 

서론에서 말한 거처럼 나는 태어나서 책을 끝까지 읽어본 적이 없었다.

 

하지만 최근에 한 권의 책을 다 읽고 두 번째 책으로 럭키 드로우 책을 다 읽었다.

 

내가 하고 싶은 말이 무엇이냐고?

 

내가 이 책을 읽겠다고 목표를 가진 이유 첫 번째 책을 목표 등은 명확했다. 하지만 다른 사람은 그냥 내가 하고 있는 것을 흉내내기 위해서 잠시 따라한 것뿐인 거 같다.

 

나는 지금 내가 하고 싶은 것은 내 인생을 살아가는 것이다. 그래서 경제를 공부하고 있다. 그 와중 드로우 앤드류라 사람을 알게 되었고 그가 자신의 인생을 살아가는 모습을 유튜브로 남기고 이 이야기를 책으로 출간했으니 나에게는 이 책이 꼭 읽어하는 책이 된 것이다.

 

나도 나만의 레버를 당기고 싶으니깐

 

 

Draw 1 결과는 모르지만 두렵기보다는 설레는 순간

첫장의 이야기는 즉흥적으로 레버를 당긴 미국 인턴쉽의 대한 이야기였다. 이 첫 장을 읽으면서 나도 즉흥적으로 선택한 코딩이라는 레버가 생각났다.

 

나는 항공기계과를 다니면서 내가 무엇을 하면서 먹고살아야 되는지 고민이 많았다. 그래서 나는 순간적으로 스마트 혁명이라고 불리는 모바일 개발 분야의 관심을 가지게 되었고 컴퓨터공학과라는 레버를 당기게 되었다. 그래서 대한민국에서 모두가 다 아는 회사의 앱 개발자가 되었다. 

 

하지만 Draw 1 를 읽어보면 알다시피 앤드류 또한

 

시니어 디자이너 앤드류 최

 

라는 명함의 자부심을 느끼다가 회사에서 퇴사를 한 후 명함의 힘은 내가 아닌 회사에서 왔다는 걸 느꼈고 배신감이 들었다고 말을 했다.

나도 내 회사에 자부심을 가지고 있지만 그건 어디까지나 회사의 명함이지 나를 표현하는 명함이 아니다.  린생 너도 레버를 당겨야 돼!.

이렇게 앤드류가 나에게 말을 하는 느낌이었다.

 

Draw 2 내가 설 무대가 없다면 직접 만드는 수밖에

이번 장에서는 앤드류가 자신의 레버를 당기게 된 이야기를 하게 되었다. 작은 실패를 경험한 이야기와 자신의 경험을 살려 레버를 당긴 이야기였다.

 

앤드류는 과외를 하면서 생계를 이어가는 이야기를 하면서 실패 경험담을 소개한다.

 

신기하게도 나도 과외를 한 적이 있다. 앤드류와 마찬가지로 나도 동일한 문제가 발생하였다. 나 또한 과외를 하면서 카드결제 수단이나 많은 질의응답에 답변을 다는 시간이 많아졌고 이것이 나에게 지속 불가능하다는 생각을 가지게 되었다. 

 

앤드류 역시 나와 같은 경험을 했다는 게 신기하였다. 

 

이렇게 돈을 버는 방식이 나를 위해서 일하는 방식이라고 처음에는 생각하였지만 그건 아니었던 거 같다. 처음 이것을 하지 않기로 결심할 당시 많은 마음에 아픔이 있었지만 이 책을 읽고 알게 된 거 같다.

 

단지 이건 나만의 레버가 아니었다는 걸

 

그리고 앤드류가 중요하게 말하는 포인트가 이번 장에서 나오는 거 같다. 계획보다 기회를 쫒는다. 

 

이 말을 뜻을 아직도 모르겠다. 

 

왜 모를까...?

어떻게 하면 알 수 있을까...?

 

앤드류에게 물어보자 ㅎㅎ

 

Draw 3 나는 내일도 내일을 한다.

3장을 읽으면서 마음에서 무엇가 움직이는 것을 느꼈다. 

내가 처음으로 책을 읽으면서 많은 사람들이 생각났다.

 

내가 처음 코딩을 배운다고 이야기할 때, 내가 처음 유튜브를 시작한다고 말할 때, 내가 무엇가를 공부하고 있다고 말 할 때

그들은 나를 보고 많은 이야기를 하다면서 모두 부정적이 이야기를 하였다. 

 

심지어 비웃음을 당하라고 놀리기도 하였다. 처음에는 이것이 매우 힘들었다. 그들에게 설득을 해보려고 했지만 언제나 실패를 하였다. 

이 단락을 읽으면서 처음으로 내가 해 온 일이 그들과 달랐고 그들이 두려움을 느끼고 있다는 생각을 하고 있던 참이었다. 

 

앤드류 말처럼은 두려운 것 같다. 레버를 당길 용기는 없으면서 레버를 당기러 가는 사람들을 부정하고 멸시하면서 내가 하고 있는 일만이 좋다고 자신 최면을 하면서.. 

 

이제는 그들을 설득하지도 나를 비웃 음어도 아무렇지도 않다. 

 

앤드류의 말처럼 이제는 그들이 불쌍하게 느껴진다. 자신의 레버를 당길 용기가 없는 그런 사람이라는 것이..

 

나는 지금 내 분야 말고 나만의 레버를 찾아서 당기려고 하고 있다. 그들에게 내가 레버를 당길려고 한다는 말도 이야기도 하지 않는다. 

오히려 그들은 그렇지 말라고 나에게 말하고 있다. 그렇지만 난 그 레버를 당기러 갈 것이다. 

 

나는 147쪽에 있는 앤드류의 말이 너무 감동이었다. 

 

레버를 당기기 전에 나는 이것이 나만의 레버인지 정말 이게 맞는지 두렵기도 하지만 그것이 하지 않을 이유는 되지 않는다. 아마 앤드류도 그랬을 것이다. 레버를 당기기 전에는 이것이 나의 레버가 맞는지 다른 사람의 레버는 아닌지? 하지만 레버를 당겨보지 않으면 알 수 없다. 

 

나도 나의 레버를 찾을 때까지 당길 것이다.

 

Draw 4 부자는 아니지만 돈은 잘 법니다. 

메시지를 전 할 자격의 대해서 이야기를 하는 부분이 있었다. 여기서 선한 영향력을 가지고 싶다는 사람의 이야기를 해주었다.

다른 사람들이 나에게도 개발을 하고 싶다고 이야기를 하는 사람이 이었다.

 

지인: 개발을 잘하고 싶어요

나: 개발을 해 본 적 있나요?

지인: 아니요

나: 일단 해보세요.

지인: 무엇부터 해야 되는데요?

 

대부분은 이런 식이였다. 처음에는 이것저것 하나하나 다 알려주었지만 그는 실행하지 않았다. 결국 그는 그냥 자신의 레버를 당길 용기가 없었던 거 같다. 

물론 개발을 하는 것이 레버를 당기는 것은 아닐 것이다. 하지만 레버를 당기는 무기는 될 거라고 생각이 든다. 하지만 그는 아무것도 하지 않으면서 무언가를 하고 있는 느낌을 받고 싶은걸일 수도 있겠다는 생각이 든다.

 

아마 앤드류도 선한 영향력을 가지고 있다는 사람에게서도 같은 느낌을 받았을까...?

 

나는 부자가 되고 싶다. 

그리고 노후에 아무것도 안 하면서 내가 하고 싶은 커피를 내리면서 바다를 보면서 살고 싶다.

 

그것을 위해 앞으로 나는 레버를 당긴다. 

 

Draw 5 밀레니엄 후배의 앞서가는 비밀노트

앤드류는 첫 소제목에서 시작하지 못하는 이유의 대해서 이야기를 한다. 이 글을 보면서 정말 그랬다. 밀레니엄 세대는 많은 정보를 인터넷, 유튜브, 인스타그램으로 정보를 얻는다. 정보를 얻는다는 건 그만큼 자기가 할 무엇가의 대한 이해도 있겠지만, 그 길이 얼마나 어려움이 있는지 알게 되는 거 같다. 

 

앤드류가 폭포를 보기 위해서 갔던 길이 알고 보니 폭포를 올라가는 길이였고, 심지어 그 길은 베테랑 들만 가는 험한 길이였다. 하지만 앤드류는 그냥 내가 가는 길이니깐 올라갔다. 정말 멋있다. 

 

밀레니엄 세대는 다들 그 길을 검색하고 정보 들으면서 그 길을 도전할지 말지 선택하고 그 길을 선택했다 하다더라도 중간에 포기하면 이 길은 힘든 길이었으니깐.. 하면서 포기의 대한 위안을 가지는 거 같다. 왜냐하면 그 길을 못 올라가는 핑계를 되는 것이 가장 쉽기 때문이다.

 

여기서 중요한 것은 내가 아는 개발 직군 이외의 길을 하면서 나 역시 다른 이와 동일했다는 것이다. 

 

내가 잘 아는 길, 내가 좋아하는 것을 할 때는 그 그저 그것을 하고 싶고 올라가고 싶다는 신념으로 아무리 높다고 한들 하였다. 하지만 닮고 싶고 것을 할 때는 나 역시 얼마나 그것이 힘든지부터 알고 도전하고 못하면 핑계를 되고 있었다.

 

참.. ㅎㅎ 

 

많은 반성과 앞으로의 도전을 하면서 이 것을 꼭 기억해야겠다. 

 

그래서 지금 하고 있는 것을 포기하지 않는다. 나의 레버라고 믿기 때문이다. 

 

마치며...

나는 이 책을 모두가 알았으면 좋겠다. 이 책을 그럴만한 자격이 있다. 

 

이 책에서는 많은 것을 배울 수 있다. 

 

1. 내가 하는 일이 나의 레버인가?

2. 나의 레버를 당기는 것은 어렵지 않다.

3. 나의 레버를 당길 때는 레버를 당기지 못하는 이들이 나를 무시하거나 당기지 못하게 방해를 한다.

4. 대부분 나의 레버를 찾고 싶어 하지만 핑계만 되면서 하지 않는다.

 

앤드류는 이런 이야기를 이 책에 담아 소개를 하였고 이것을 이야기하고 있다. 

 

이 블로그 글을 읽는 사람이 있다면 묻고 싶다.  지금 나는 누군가의 레버가 되기 위해서 매일 아침 일어나 9시부터 6시까지 일을 하고 있지 않은가? 나의 레버를 당기고 싶지 않은가?

 

나 역시 9시부터 6시까지 일을 한다. 

하지만 그 이외의 시간은 나의 레버를 당기는 시간으로 보내고 있다. 

 

나는 지금까지 남의 위해 살아왔다. 

 

개발자가 되고 싶었지만 나의 레버를 당길 용기는 없었다는 것이다. 지금은 나의 레버를 당기기 위해서 내 개발을 조금씩 이용하고 있다. 그게 지금은 매우 작은 움직임이지만 이것은 나의 무기가 될 것이다. 

 

앤드류는 이 책의 첫 장에서 바닷가를 가는 이야기를 소개한다. 나 역시 개발이라는 것을 하기 전에 그랬다. 그리고 나의 레버를 당기기로 결심 한 날에도 그랬다. 

 

그 결심이 얼마나 큰 결심인지 결심을 해 본 사람을 알 것이다. 

 

내가 하는 일이 정말 내 길이 맞나? 끝이 없이 고민하고 수정하고 앞으로 간다. 

내 앞에 누가 있는지 내 뒤에 누가 있는지는 중요하지 않다. 

내가 그저 앞으로 가고 있다는 것이 중요하다. 

 

책 리뷰를 처음으로 써 본 나에게 이 책은 내 인생에서 영원히 기억에 남을 책이 될 것이다. 

 

올해 회고는 온라인으로 진행하였다.

매년하는 회고인데 온라인으로 진행하니 새로운거 같다 ㅎㅎ

 

1분기

올해도... 이직....?

올해도 이직을 하였다... ㅎㅎ.. 매년 이직을 하면서 느끼지만 이직은 좋은거 같다

처음 회사는 레진코믹스...

두번째 회사는 원티드...

그리고 카카오페이

 

 

앱 개발자라면 누구나 가고 싶어하는? 회사에 들어가게 되어서 너무 좋았다 하지만 걱정도 있었다. 회사와 집 사이의 거리는 좀 멀었다...

왕복 3시간의 거리를 통학을 할려고 하니 자취를 자연스럽게 생각을 하였다. 그래서 좋은 지역이 어디 있을지 찾게 되었다.

 

자취

자취방을 구하는 것은 생각보다 힘들었다..ㅠ

 

처음으로는 수지구청 근처로 방을 보러 다녔다. 수지구청은 위치는 너무 좋았으나 매물로 나온 집이 마음에 들지 않았다.

 

자취하는 지역은 결국 광교를 선택했다. 어느 정도 보증금과 월세를 높여 방을 품질을 높였다. 수원에서 광교가 제일 좋다고 들었는데 처음 방을 보고 마음에 들었던 방이였던거 같다.

 

광교

자취하는 지역은 결국 광교를 선택했다. 어느 정도 보증금과 월세를 높여 방을 품질을 높였다. 수원에서 광교가 제일 좋다고 들었는데 처음 방을 보고 마음에 들었던 방이였던거 같다.

자취를 시작하고 처음으로 광교 호수공원으로 산책을 하였는데... 매우 좋았다....

 

여기로 이사를 온 것을 매우 만족했다 ㅎㅎ 돈을 많이 벌어서 꼭 여기서 정착하고 싶은 마음이였다 ㅎㅎ

 

2분기

입사 및 첫 프로젝트...

입사를 하고 간단한 업무는 많이 하였지만... 대규모 앱 개편을 바로 들어가게 되었다. ㅎㅎ....

회사에서 1.0 버전을 유지하고 있었고 올해 하반기 2.0 개편을 목표로 진행이 되었다. 2.0는 앱 전반적이 개편을 목표로 하고 있어 앱의 기반작업부터 변경 사항이 많았다.

 

iOS13 타켓 및 Combine 도입

 

앱 개편을 하면서 앱 기반의 비동기 처리를 Combine으로 변경하자는 이야기가 팀내의 나왔다.

카카오페이 앱을 독립적으로 iOS 13 버전으로 사용하자는 것이였다. 기존에 사용하는 비동기 처리는 Promise라는 것을 사용했다

 

위의 Promise로 작업 된 비동기 로직을 Combine과 같이 사용하거나 대체를 하는 것이 목표가 되었다.

Combine이라는 비동기 라이브러리는 당시 사용하는 회사가 없어 관련 된 내용이나 참고 문서 또한 참고하기가 어려운 상황이였다. 많은 문제가 있었지만

RxSwift를 사용해 본 경험이 있어 쉽게 적용이 되었던거 같다.

 

3분기

카카오페이 2.0 배포

드디어 카카오페이 2.0을 완료 할 수 있었다. 특히 어려움은 많은 것이 있었지만 몇가지만 소개를 할 까한다. ㅎㅎ

처음으로 CompositionLayout으로 홈을 적용하였다.

https://developer.apple.com/documentation/uikit/uicollectionviewcompositionallayout

 

Apple Developer Documentation

 

developer.apple.com

 

iOS 13에서 나오게 된 새로운 형태의 CollectionView라고 이해를 하면 될 거같다.

새로운 기능에서 어떻게 구조를 만들지 고민이 되었다. ㅎㅎ...

 

많은 예제를 써보면서 익숙해져서 결국 좋은 구조를 만들수 있었던거 같다.

 

IPO 상장

회사의 좋은 소식이 왔다. 내가 다니는 회사가 IPO 상장을 한다는 것이였다. 처음에는 이것이 어떤 의미를 하는지 몰랐다. 하지만 경험을해보니 매우 기뿐소식이였다.

 

 

회사의 상장하는 것이 얼마나 힘든 일인지는 대체로 알 거 같다. 대부분의 개발자는 스타트업에서 일을 한다. 처음에 스타트업에서 일하는 사람은 대부분 점차 대기업으로 이직을 하는 경우를 많이 보았다. 흔히 스타트업 에이스가 되어서 영입을 당하는 경우가 많다.

 

하지만 대기업을 다니다가 스타트업을 가는 경우도 보았을 것 같다. 이런 경우 대부분 exit 또는 상장을 목표로 스타트업에 들어간다. 그치만 대부분의 회사는 창업 몇년이 지나고 망하게 된다. 상장을 한다는 것이 얼마나 어려운 일인지 알 게 된 거같다.

 

나는 이제 막 회사를 입사를 하여 상장을 경험을 하여 큰 보람을 느끼지는 못 했지만 처음 회사를 창업 할 당시부터 있었던 팀장님들의 기뿐은 대단할 거 같다. 더욱이 내가 좋아하는 동료와 함께 이루어낸 성과라서 더욱 뜻 기쁠거같다. 나 역시 그랬다.

 

4분기

 

개발자

회고를 쓰면서 늦겼다. 3년 연속으로 회고를 쓰면서 올해 난 개발자로 살아간 것이 아닌것을 알았다. 단순히 개발자가 아닌 한 사람을 사람으로서 인생을 즐기면서 사는 모습을 가지고 있었다.

 

처음 회사를 들어 갈 당시의 마음 가짐이 지금 나에게는 없었다. 그 이유가 무엇일까? 흠... 사실 잘 모르겠다. 열정은 열정 대로 사라지고 관심은 개발이 아닌 다른 곳에 있다보니 그런거 같다. 주말마다 개발을 찾던 나에서 주말마다 무엇을하고 보낼지 고민하는 나 자신의 모습으로... 처음으로 돌아가야 겠다고 마음가짐을 한다.  개발자로 살아가는 이상 개발을 언제나 하는 일이며 재미있는 일이다. 그치만 요즘 기초의 대한 이해가 없어 허들을 많이 느낀다. 점차적으로 주니어에서 시니어가 되고 싶은 나에게 시니어가 아직 아니라고 모든것이 말하는 느낌이였다.

 

 

'회고록' 카테고리의 다른 글

2020년 회고록  (398) 2020.12.26
2019년 회고록  (869) 2020.01.09

안녕하세요 린생입니다.

오늘은 처음으로 커피를 추출하는 블로그를 작성해 볼려고 합니다.

바리스타 자격증을 취득하면서 드립커피 내리는 법을 따로 배우지는 못했지만 유튜브를 보면서 배웠습니다.

 

 

이번에 사용하는 원두는 빈브라더스에서 사용하는 벨벳화이트를 사용하였습니다.

원두는 특징은 정확히 확인 알지는 못하지만

산미: ****

바디감: **

정도로 표현이 될 거 같습니다.

추출 과정은 다음과 같습니다.

준비물

  • 원두 25g
  • 뜸들이기 25g
  • 1차 추출 70g
  • 2차 추출 70g
  • 3차 추출 30g

총 170g을 추출 할 목표 입니다.

 

 

원두는 대략 25g을 사용하였습니다. 원두의 색을 봤을 때 밝은 색을 보여주는 것으로 보아 볶는 시간이 짧게 하여

신맛이 강하고 쓴맛이 약하게 추출이 될 것으로 예상이 됩니다.

뜸들이기

 

뜸들이기는 원두를 처음에 넣어서 대략 1분 정도 원두의 응집도를 높이는 작업입니다. 이 부분의 대해서는 나중에 자세히 이야기를 하겠습니다.

처음 25g을 원두를 사용하여 원두의 용량과 같은 물의 양으로 뜸을 들여줍니다.

1차 추출

 

1차 추출은 70g을 물을 사용하여 내려줍니다.

처음으로 내려보는 추출 방식인데 맛이 어떻게 될 지 궁금하지만 뜸들이기를 해준 덕분에 처음 추출의 양을 늘려서 추출해주어도 괜찮습니다.

그래서 70g의 물을 사용하여 1차 추출의 양을 높였습니다.

2차 추출

 

2차 추출은 1차 추출의 물이 어느 정도 빠지고 내려주면 됩니다. 이 타이밍은 흠... 물이 내려오면서 원두가 내려가지 않는 정도에서 유지하면 될 거 같습니다.

3차 추출

 

 

3차 추출은 대략 30g의 물을 사용하였습니다. 3차 추출에서는 1차, 2차에서 어느 정도 원두를 사용하여 내려주는 것이기 때문에 많은 양을 내려주지 않습니다.

완성

 

 

완성하였습니다.!!

마무리

핸드드립을 하면서 처음으로 그램을 측정하면서 추출을 하였습니다. 그램수를 지키는 것과 양 조절, 그리고 내리는 면서 원두를 고리게 물줄기를 만드는 것이 매우 어려웠습니다.

또한 1차, 2차, 3차 추출을 하면서 맛을 비교하면서 마시고 싶었지만 아직은 그냥 내려는 것으로 하여 내려보았습니다.

점차 많은 방식으로 내려보면서 맛을 비교 해보겠습니다.

맛의 평가

산미: 4 / 5

바디감: 3 / 5

쓴맛 : 3 / 5

향은 대략적으로 레몬 정도의 신향을 나타내고 있습니다. 산미가 강하게 느껴진다고 보시면 될 거 같고 쓴맛은 어느 정도 낮지도 높지도 않는 티라미슈의 위의 카카오 가루 정도로 이해 하면 될 거 같습니다.

앞으로 커피 이야기도 잘 봐주세요 감사합니다.

 

안녕하세요 린생입니다.

어느덧 iOS 개발을 시작 한 지 2년이 조금 넘은 시간이 지난거 같습니다. 개발을 하면서 취준, 신입, 1년차 그리고 2년차를 지내면서 조금씩? 성장을 하는 느낌을 받았습니다. 작년에 처음으로 회고록을 쓰면서 1년 동안 나 자신을 돌아보게 되었고 부족 한 부분의 대해서 느끼고 올해는 그 부분의 대해서 채워나가는 해를 보내겠다고 다짐을 했던 거 같습니다.

원티드랩 이직

작년 저는 레진코믹스를 재직을 하다가 원티드랩으로 올해 이직을 하였습니다. 이직을 결심 한 이유는 많은 것이 있지만 많은 경험을 더 해보고 싶어서 이직을 결심하였습니다.

면접의 느낌이 제일 힘들었다.

 

원티드랩에서 면접에서 느낀 점이 많았습니다. 이력서에서 개발 경력을 검진하는 것은 어느 정도 예상은 했지만 그 이외의 것을 많이 보는 느낌의 면접이였습니다.

A/B 테스트의 경험, 왜 이런 테스트를 진행해야하는지?, 어떤 결과가 나와서 어떤 것을 적용하고 보안했는 등을 면접에서 물어보고 대답을 하였습니다.

이러 경험은 회사를 입사하지 않으면 알 수 없는 내용이라 많은 부분에서 배울 점이 있다는 생각이 들었다. 그래서 나는 원티드랩을 선택하여 입사를 하였습니다.

MVVM ... Clean Swift

MVVM 패턴을 적용하면서 많은 문제점의 대해서 느끼고 있던 중이였습니다. MVC 패턴으로 Swift를 공부하고 앱 개발을 하면서 느껴 던 이슈는 비지니스 로직과 View의 로직이 분리하고 싶은 욕구가 많았다. 그래서 MVVM패턴을 적용을 많이 하였다. 하지만 이 부분의 대해서도 문제를 많이 있다고 느겼다.

비지니스 로직이 복잡해지면 ViewModel이 무거워진다.

이런 한 문제를 해결하고 싶었다. 이러한 문제는 Object라는 책을 읽으면서 해결을 할 수 있었다.

 

 

이 책은 강력 추천합니다. 하지만 입문자가 읽기에는 많이 어려운 책이라는 느낌을 받았습니다.

어느 정도 개발 경험이 있고 문제점의 대해서 해결을 하고 싶은 의지가 있는 상태에서 읽으면 도움이 될 거 같습니다.

이 책을 읽으면서 응집도와 결합도의 대한 이해가 높아졌고 회사 프로젝트에 적용 할 수 있었던 거 같습니다.

Clean Swift

 

 

Object 책을 읽고 객체 지향의 대한 이해와 결합도 응집도의 대한 이해를 바탕으로 clean swift를 팀원분들과 적용을 하였습니다.

위의 내용을 보면서 회사에 적용을 할려고 보니 의존성 관계의 대하여 고민이 많았다. 의존성 주입을 ViewController에 하는 점과 단방향 통신의 대한 개념 이해등의 대해서 논의를 하여 위와 비슷하지만 변형 된 형태의 Clean Swift를 적용하게 되었습니다.


오픈소스 개발

올해는 많은 오픈소스를 만들지 못했습니다. 하나의 오픈소스만 만들어 보았습니다.

 

github.com/jungseungyeo/SwiftyContainer 

 

jungseungyeo/SwiftyContainer

SwiftyContainer is very Ez animation!! 😀 👻 🧑‍💻. Contribute to jungseungyeo/SwiftyContainer development by creating an account on GitHub.

github.com

 

 

위의 오픈소스는 간단하게 bottom에서 위로 올라오는 animation을 하는 코드였습니다. 이 코드를 만들면서 중요하게 적용한 것은 POP구조를 가져가고 싶었던 거 같습니다.

구조를 설계를 할 때 는 builder를 생성하고 의존성은 주입하는 부분의 대해서는 Component를 주입하여 의존관계를 형성하게 하였습니다.

바리스타 자격증

커피를 좋아하는 개발자로 지내면서 커피의 대해서 많이 무지했던거 같다. 그냥 좋아하고 카페가는 것만 좋아 하던 중 자격증을 그냥 한 번 취득하고 싶어 커피 자격증을 도전하였다.

 

 

커피 알바를 1년 좀 안되게 하던 나는 금방 배워 나갈수 있었던거 같다. 특히 강사님의 이론적이 내용과 커피 추출 방식을 잘 설명해주고 알려주어서 한번에 자격증을 취득 할 수 있었던 거 같다.

 

 

바리스타 자격증은 취득한 이유는 그냥 내가 커피를 '좋아해요' 라고 말하는 것보다는 저 바리스타 자격증 있어요 이런 말을 하면 정말 커피를 좋아하는 분이구나 이런 느낌을 사람들에게 주고 싶었다.

그리고 개발자를 은퇴하게 되면 커피숍을 만들어서 커피 공부를 하면서 서비스업을 해보고 싶은것이 내 미래의 소망이기도 하여 차차 준비를 할려고 진행하였다.

그래서 내가 좋아하는 카페를 보여주는 앱을 만들어 보고싶다는 생각을 하게 되었고 또 다른 사람들이 좋아하는 카페는 어떤 곳이 있는지 궁금하였다.

그래서 설문을 진행하였고 많은 분들이 설문에 참여를 해주었다.

 

 

익명으로 투표를 하여 누가 설문에 참여를 하였는지는 모르지만 한분 한분 너무 감사한 마음이 들었다. 그래서 그 자료를 바탕으로 앱을 만들려고 하였지만 코로나 사태가 발생하여 일단 중지를 하였다.. 내년에는 꼭 만들어 보겠다.

마치며...

많은 것을 하고 싶었고 하겠다고 다짐했던 한 해 였던 거 같다. 하지만 역시 모든 것을 하지 못 했던 거 같다.

작년에는 누구나 할 수 있고 누구나 한 번 쯤은 해본 일을 하였고 올해는 누구나 하지 못한 일 하나는 해보자고 다짐을 했던 거같다. 하지만 올해 도 역시 누구나 할 수 있고 해본 일을 나 역시 해왔던 거 같다.

특별하게 무엇 하나 한 것이라고는 느껴지지 않지만 그래도 열심히 해왔던 것이 조금은 느껴진다. 만족감도 들고 부족한 부분도 많이 느껴진다.

특히 개발쪽으로는 작년과 비교를 했을 때 더 노력을 하지 않았던 것으로 느껴진다. clean swift를 이제 막 입문하고 이해하고 알아가면서 개발을 조금 더 잘하고 할 수 있었는데 이런 부분에서 부족 한 거 같다.

내년에는 올 해 보다 더 노력하고 성장하는 한해가 되겠다고 다시 한 번 다짐해 본다.

'회고록' 카테고리의 다른 글

2022년 회고록  (422) 2022.01.07
2019년 회고록  (869) 2020.01.09

1. 개인정보의 처리 목적

‘API’는 iOS 어플리케이션 "오늘의스크랩"에서 개인정보를 처리하고 있으며, 다음의 목적 이외의 용도로는 이용하지 않습니다.

 

 

 

 

2. 개인정보처리 위탁

API는 타 업체에 개인정보처리를 위탁하지 않습니다.

 

 

 

 

3. 정보주체의 권리,의무 및 그 행사방법

이용자는 개인정보주체로서 다음과 같은 권리를 행사할 수 있습니다.

① 정보주체는 API에 대해 언제든지 다음 각 호의 개인정보 보호 관련 권리를 행사할 수 있습니다.

1. 오류 등이 있을 경우 정정 요구

2. 삭제요구 : 사용자가 직접 앱을 삭제할 수 있습니다. (Linsaeng.tistory.com에서 요청 할 수 있습니다.)

 

 

 

 

4. 처리하는 개인정보의 항목 작성 

① API 은 다음의 개인정보 항목을 처리하고 있습니다.

1. 디바이스아이디를 활용하여 본인등록을 하기위하여 디바이스아이디를 사용합니다.

디바이스아이디를  API내 서버에 전송합니다.

 

 

 

 

5. 개인정보의 파기

API는 원칙적으로 개인정보 처리목적이 달성된 경우에는 지체없이 해당 개인정보를 파기합니다. 파기의 절차, 기한 및 방법은 다음과 같습니다.

① 파기절차 

이용자 관련 개인정보는 회원탈퇴를 통하여 모두 파기합니다.

② 파기기한

이용자 관련 개인정보는 회원탈퇴를 통하여 모두 파기합니다.

 

 

 

 

6. 개인정보의 안전성 확보 조치

API는 개인정보보호법 제29조에 따라 다음과 같이 안전성 확보에 필요한 기술적/관리적 및 물리적 조치를 하고 있습니다.

① 개인정보에 대한 접근 제한

개인정보는 앱 실행시에만 사용합니다.

 비인가자에 대한 출입 통제

iOS 모바일에서는 개인정보를 보관하고 있는 내부의 물리적 보관 장소에 직접 접근이 불가능합니다. 해당 권한은 실행시에만 사용됩니다

 

 

 

 

7. 개인정보 보호책임자 작성

① API는 개인정보 처리에 관한 업무를 총괄해서 책임지고, 개인정보 처리와 관련한 정보주체의 불만처리 및 피해구제 등을 위하여 아래와 같이 개인정보 보호책임자를 지정하고 있습니다.

▶ 개인정보 보호책임자 

성명 : Jsy

연락처 : duwjdtmd91@gmail.com

 

 

 

 

8. 개인정보 처리방침 변경

① 이 개인정보취급방침은 시행일로부터 적용되며, 법령 및 방침에 따른 변경내용의 추가, 삭제 및 정정이 있는 경우에는 변경사항의 시행 7일 전부터 공지사항을 통하여 고지할 것입니다. 

② 이 개인정보취급방침은 2020년 05월 05일부터 적용됩니다.

 

 

안녕하세요 린생입니다.

개발을 이제 막 시작한 입문 개발자인 제가 갑자기 Architecture(아키텍처)라는 것이 궁금해졌습니다.

다들 "Architecture(아키텍처)가 뭐야?" 라고 하면 잘 설명을 할 수 있나요????

누군가가 저에게 물어보면 저는 저런 표정이 되곤 합니다.

아키텍처가 무엇인지 감은 오면서 딱 "이것이 Architecture(아키텍처)입니다." 라고 설명이 잘 안되었습니다.

그래서 Architecture(아키텍처)란 무엇인지 대해서 한 번 글을 적어 볼까 합니다. :)


아키텍처란?

위키 백과에서 찾아보면 이렇게 정의를 하고 있습니다.(https://ko.wikipedia.org/wiki/시스템_아키텍처)

  • 시스템 구성 및 동작 원리를 나타내고 있다.
  • 구성 요소 간의 관계 및 시스템 외부 환경과의 관계가 묘사된다.

위의 글을 보았을 때 정확한 표현이라고 생각이 들었습니다.

"하나의 서비스가 어떻게 구성이 되며 어떻게 동작이 된다" 라고 표현이 될 거 같습니다.

즉 아키텍처란 서비스의 동작 원리를 나타내는 것입니다.


아키텍처 설계?

구글에 아키텍처 설계라고 검색을 해보면 많은 글이 나옵니다.

글 하나하나 보면 다들 좋은 내용이긴 하지만 개발 입문 자이며 모바일 개발자인 제가 이해하기는 매우 어려웠습니다.

제가 이해가 되지 않았던 이유는 다음과 같습니다.

  1. 각 글마다 설계를 하는 방식과 용어가 다름
  2. 모바일 아키텍처 설계를 하고 싶은데 서비스의 대한 아키텍처 설계 방식을 설명
  3. 내가 무엇부터 만들어야 하는지 모르겠음

위의 이유는 다음과 같은 이유로 발생한 것 같습니다.

  1. 서비스 전체적인 아키텍처 설계를 일반적으로 이야기함
  2. 내가 찾는 것은 iOS의 아키텍처 설계를 알고 싶음

대부분의 글은 1번의 내용을 다루고 있고 우리가 찾고자 하는 것은 2번의 내용을 찾고 있어서 제가 이해하기가 어려웠다고 볼 수 있습니다.

그래서 우리는 각자 iOS에 맞는 아키텍처를 어떻게 해야 할까요?

Apple에서는 아키텍처로 MVC 패턴을 권장하고 있습니다.


MVC패턴이란

MVC패턴을 하는 이유를 한 가지로 설명을 하자면 역할의 분리라고 말할 수 있습니다.

역할의 분리라는 것은 각 객체 별로 하는 역할을 나눈 것을 의미한다고 볼 수 있습니다.

MVC 패턴은 이러한 역할을 3가지로 나누어서 설계를 하는 것을 말합니다.

 

  • M(Model): 앱에서 무엇을 할지를 정의
  • V(View): 앱에서 화면을 보여주기 위해서 정의
  • C(Controller): 앱에서 화면을 어떻게 보여주기 위해서 정의

위 역할로 나누는 것뿐만 아니라 각자 역할 별로 통신 흐름 또한 알 수 있습니다.

위의 MVC 패턴은 다른 곳에서 말하는 MVC 패턴과는 다른 형태를 나타내고 있습니다. 일반적으로 말하는 MVC 패턴의 설계는 아래의 그림처럼 되어 있습니다.

 

역할의 차이점은 없지만 통신의 흐름에서는 차이점을 나타냅니다.

이것은 iOS에서 Controller와 View가 서로 독립적으로 존재할 수 없어 발생하는 차이점입니다.

 

 

위의 그림에서 Controller는 UIViewController를 이며 View는 UIView입니다.

UIViewController는 내부적으로 UIView를 무조건 가지고 있어 Controller와 View 분리가 되지 않습니다.

그래서 처음에 보았던 형태의 통신 흐름을 가지게 되었고 그와 맞추어 설계를 하여야 합니다.

결론

아키텍처라는 것은 일반적으로는 서비스의 설계를 의미하지만 개발자들 사이에서는 각 플랫폼에 맞는 설계를 말합니다. 따라서 서비스에 맞는 설계 속에서 각 플랫폼에 맞는 설계(아키텍처)를 구현해야 하며 iOS에서는 기본 적으로 Apple에서 권장하는 MVC 패턴을 일반적으로 따르게 설계가 되어있습니다.

그래서 우리는 아키텍처를 공부하기 위해서는 MVC 패턴을 기본적으로 알고 있어야 합니다.

 

참고: https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html

안녕하세요. 린생입니다.

올해 2020년 부터는 회고록을 써 볼려고 합니다.

취업

레진코믹스 입사 10월 01, 2018

iOS개발을 시작하고 처음으로 서비스 개발을 하는 회사에 입사를 하였습니다. 만화를 어린 시절 부터 좋아하고 이미지 처리를 잘 하고 싶은 욕심도 있어서 레진코믹스의 입사는 매우 만족 스러웠습니다.

레진코믹스를 처음으로 입사를 하고 3개월을 수습기간을 진행 하였습니다. 수습기간 동안 팀장님이 미션을 주면 그 미션을 수행하고 그 결과를 통해 수습기간을 종료하는 프로세스를 진행하였습니다. 제가 처음으로 했던 업무는 전역적으로 분포 되어있는 UIColor를 한 곳으로 정의하고 사용 할 수 있는 Common한 class를 만드는 업무를 하였습니다. 다소 어려운 작업이 아니였지만 입사 당시 MVC패턴으로 개발을 해왔던 저는 MVVM 패턴을 적용된 코드속에서 어떤 방식으로 UIColor 시스템을 적용을 해야 할 지 고민을 많이 했습니다.

사실 상 MVVM패턴과 MVC 패턴에서 UIColor시스템을 사용하는 것은 그렇게 어려운 문제는 아니였지만 VIewController에서 주입을 해야하는지 ViewModel에서 주입이 되어야 하는지 많은 고민을 하였습니다.

위의 결과를 적용하고 저는 정식으로 레진코믹스 수습기간을 마무리 하였습니다.

RxSwift 도입

회사 팀장님과 이야기를 하면서 서로 RxSwift를 도입을 하자는 이야기가 나왔습니다. RxSwift를 도입 전 대부분의 회사 코드는 Obj-c코드로 구성이 되어 있었고 RxSwift를 도입하기에는 조금 무거운 느낌이 있었습니다. 하지만 Obj-c 코드를 Swift로 Conversion을 하고 다시 Swift코드를 RxSwift로 Conversion하는 것 보다는 Obj-c코드를 RxSwift로 Conversion하는 것이 더욱 좋다는 판단에서 RxSwift를 도입하게 되었습니다.

처음 RxSwift를 사용 할 때 로그인 페이지를 팀장님과 같이 변경을 하였습니다.

그 당시 참고 했던 것은 아래의 자료를 많이 참고 하였습니다.

[RxSwift][Swift3]POP를 이용하여 더 나은 MVVM 구조 만들기

 

[RxSwift][Swift3]POP를 이용하여 더 나은 MVVM 구조 만들기

MVVM MVVM 구조가 잘 작성되어 있는 예제가 많이 없다보니 어떻게 구조를 작성해야할 지 시작하기 어렵습니다. 그 와중에 킥스타터에서 자사 앱을 오픈소스로 공개했습니다. 여기에서 제가 주목한 점은 MVVM 아키텍처를 적용한 프로젝트였다는 점입니다. 그전에 MVVM을 한번 살펴보도록 합시다. -출처 : MSDN Model은 ViewModel에 notification를 전달하고, ViewModel은 View에 notification를 전달합니다. View

minsone.github.io

위의 내용은 간단하게 설명하자면 Input, Ouput을 가지는 MVVM 구조를 만들어서 사용을 하자는 것입니다.

이런한 구조를 공부하면서 점차 RxSwift의 대한 기본 지식과 적응을 할 수 있었습니다.

오픈소스 개발

iOS 공부를 시작하면서 매번 생각 했던 것이 나도 오픈소스를 하나 만들고 보고 싶은 욕심이 있었습니다. 이러한 생각을 했던 이유는 개발 공부를 하고 앱을 만들면서 많은 오픈소스를 사용하게 되었습니다. 오픈 소스를 처음 사용하던 당시 재밌다는 생각을 하면서 동시에 사용하기가 힘들다는 생각을 하였습니다.

사용하기 힘들다고 생각 했던 이유는 사용법과 왜 이걸을 사용하는지의 대한 이유를 모르고 무조건 사용을 하다보니 그렇게 생각을 하게 된 것 같습니다. 그래서 저는 오픈 소스를 개발을 하면 누구나 쉽게 사용 가능하고 어느 앱에서 사용을 할 수 있는 것을 만들고 싶었습니다.

jungseungyeo/SwiftlyIndicator

 

jungseungyeo/SwiftlyIndicator

😀⚙️ SwifitlyIndicator . Contribute to jungseungyeo/SwiftlyIndicator development by creating an account on GitHub.

github.com

위의 오픈소스는 아래의 조건을 생각하고 만들었습니다.

  • 함수 한 줄을 실행이 가능해야한다.
  • 어느 앱에서나 사용 할 수 있어야 한다.

두 가지 조건을 가지고 생각한 것이 Indicator였습니다. Indicator는 어느 앱에서 있고 대기 시간동안 유저에게 노출이 필요하여 만들게 되었습니다.

그래서 많은 UIWindow에서 View를 addsubview를 하고 Center에 위치를 시켜 View에서 Start 함수만 호출하면 자동으로 센터에 Indicator가 나타나게 하였습니다.

오픈 소스를 처음 만들다 보니 배포버전을 1.0.0에서 잘 못 작성된 코드를 넣게 되어 1.0.2버전까지 수정을 하여 배포를 진행하였습니다.

아미톤

AWSKRUG - AWS 한국사용자모임

 

AWSKRUG - AWS 한국사용자모임

국내 최대 클라우드 커뮤니티를 아시나요? AWS 클라우드 기술을 함께 배우고 공유하는 모임입니다. 다양한 학습 소모임과 네트워킹에 참여하세요.

awskrug.github.io

개발자로 생활을 하면서 해커톤을 한번은 꼭 나가보고 싶었다. 해커톤을 기존에 나가지 않았던 이유는 해커톤에서 내가 할 수 있는게 아직은 없을 거 같다는 생각이 많이 들었기 때문이다. 해커톤은 짧은 기간에 많은 것을 만들어야 되는데 나의 개발 속도로는 부족하다는 생각을 가지고 있었고 최근의 들어서야 내가 혼자서도 무엇가를 할 수 있겠다는 생각이 들어 도전을 하게 되었습니다.

아마톤은 AWS기술을 사용해야 하기 때문에 iOS 개발자로 내가 해야하는 역할은 크게 있지 않았다. 그래서 인지 개발 시간 보다 다른 사람들과의 이야기와 어떤 주제를 어떤식으로 풀어내는지를 많이 볼 수 있었다. 다음 해커톤에서는 iOS 기술을 잘 활용 할 수 있는 해커톤이 되었으면 좋겠다는 생각을 했다.

디프만

안녕하세요, 디프만입니다.

 

안녕하세요, 디프만입니다.

디자이너와 프로그래머가 만났을 때

medium.com

구직 활동을 할 당시 iOS를 같이 공부하고 싶었던 저는 디프만이라는 동아리를 가입하여 활동을 하였습니다. 처음 활동 당시 매우 만족하고 새로운 것을 매일 배우는 느낌으로 활동을 하였습니다. 그러다가 운영진 활동을 하게 되었고 3기, 4기, 5기 그리고 6기까지 활동을 하게 되었습니다.

디프만를 처음 활동 당시만해도 Swift도 모르고 있던 저는 어느세 MVC, MVVM, RxSwift, 오픈 소스개발을 할 수 있게 되었습니다. 디프만 활동 당시 많은 사이드 프로젝트를 진행하였고 많은 실패를 경험해 보았습니다. 어떤 방식으로 프로젝트를 진행하면 실패를 하고 사이드 프로젝트를 하면서 어떤 방식으로 진행을 하는게 좋은지등 개발뿐만 아니라 서비스를 만들기 위한 설계도 배울 수 있었습니다.

디프만을 좋아했던 저는 활동을 그만하고 싶었진 이유는 사이드 프로젝트의 한계를 느껴서 그런거 같습니다. iOS 사이드 프로젝트를 하면서 많은 화면을 만들어 보았지만 대부분이 List형태를 가진 CollectionView또는 TableView의 형태를 가지고 있었습니다. 이러한 화면은 기본적으로 만들기가 어렵지 않고 점차 알고 있지만 오래 걸리는 화면을 만드는 내 자신을 보게 되었습니다. 그래서 더 이상 사이드 프로젝트에서는 내가 만족 할 만한 UI를 찾기가 어렵다는 생각을 가지게 되어 디프만 활동을 그만하게 되었습니다.

마무리

2019년의 회고록을 작성을 하면서 느낀 점은 내가 많은 도전을 하지 않은 생각이 들었다. 다들 하는 것을 그냥 해보고 그 경험과 이야기를 쌓는 해였던거 같다. 신기술을 누구보다 빠르게 도입을 한 것이 아닌 안정화가 어느 정도 되고 협업 개발자들이 이미 많은 노하우와 경험을 있는 상황에서 RxSwift를 도입 했던 거 같고, 다들 학생 시절부터 도전하는 해커톤을 직장을 가지고 도전을 하였고 사용하기만 편한 오픈소스 개발을 했던거 같다.

2020년에는 신기술을 누구보다 빠르게 사용하고 실패를 누구보다 빠르게 느끼고 새로운 도전이라고 말 할 수 있는 것을 할 수 있는 한 해가 되고 싶다.

'회고록' 카테고리의 다른 글

2022년 회고록  (422) 2022.01.07
2020년 회고록  (398) 2020.12.26

안녕하세요 린생입니다.

 

오늘은 디자인 패턴 중 Delegate 패턴의 대하여 알아보겠습니다.

 

iOS를 공부하시는 분 들이라면 delegate 패턴은 익숙하고 많이 들어 보았을 것 같습니다.

 

먼저 delegate의 사전적인 의미를 알아보면 

 

 

'위임하다.’ 로 해석을 할 수 있습니다.

 

정말 사전 적 의미와 동일하게 delegate 패턴은 위임하는 패턴입니다.

 

1. Delegate pattern을 사용하는 이유

 

애플에서는 delegate 패턴을 매우 많이 볼 수 있습니다. 

Delegate을 사용하는 이유는 Controller에게 역할을 위임하기 위해서 입니다.

 

이게 무슨 말이냐? 이런 생각을 할 수 있을 거 같습니다.

 

apple에서는 MVC 패턴을 권장하고 있습니다. 

 

MVC 패턴은 Model - View - Controller 로 구성을 하여 개발하는 아키패턴 패턴입니다.

 

출처: https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html

 

이 패턴에서 View에서 사용자가 action을 하면 Controller에게 알려 줄 필요가 있습니다.

 

이러한 상항에서 View의 역할은 오직 사용자의 action을 알려주는 역할만 하고 그 action은 어떻게 처리 할 지는 Controller에게 위임하는 것입니다.

 

2. Delegate Pattern 예시

 

간단한 예시를 만들어 보겠습니다.

 

 

위의 그림에서 MainViewController가 있고 MainView가 있습니다.

 

MainView는 x축 100, y축 100, 사이즈 100을 가지고 있습니다. 

 

MainView에서 버튼이 누린 경우 MainViewController에게 어떻게 알려 줄 수 있을까요?

 

 

이런 방법이 있을 거 같습니다. 

 

하지만 이 방법은 좋은 방법이 아닙니다.

 

그 이유는 View에서 버튼 action의 대해 클릭이라는 행동을 하고 있기 때문입니다. 

view는 유저에게 가장 가까운 위치에 있어 데이터와 정보 보여주는 역할과 이벤트를 받는 역할만 해야 합니다.

 

그러면 어떻게 하면 View에서 Controller에게 알려 줄 수 있을까요? 이런 상황에서 delegate 패턴을 사용하는 것입니다.

 

 

먼저 Protocol을 만들고 그 protocol을 가지고 있는 변수를 만들어줍니다.

 

그리고 protocol에서 button action을 받을 함수를 선언합니다.

 

그리고 controller는 아래와 같이 작성합니다.

 

 

이렇게 만들고 buttonTapped이라는 함수에서 이벤트를 처리 하는 것입니다.

 

이렇게 하여 Controller가 이벤트 처리 후 다시 view에게 알려주는 것입니다.

 

 

이렇게 위에 MVC 아키텍쳐 패턴에 맞게 View가 Controller에게 이벤트를 알려주고 Controller는 다시 View에게 update을 하는 형태가 되는 것입니다.

 

'Swift > 디자인패턴' 카테고리의 다른 글

SingleTon Pattern(swift)  (0) 2018.07.06
Builder pattern(swift)  (2) 2018.07.03
Observer Pattern(swift)  (6) 2018.06.08
Factory Pattern(swift)  (3) 2018.05.30

+ Recent posts