Initialization

초기화

• 초기화는 클래스, 구조체, 열거형의 인스턴스를 생성하는 과정
• 각 저장속성에 대한 초기값을 설정하여 인스턴스를 사용가능한 상태로 만드는 것
  (열거형은 저장속성이 존재하지 않으므로, case중에 한가지를 선택 및 생성)
• 생성자 메서드 실행의 목적은, 모든 저장속성 초기화를 통한 인스턴스 생성
  생성자 실행의 종료시점에는 모든 저장 속성에 값이 저장되어 있어야 함
• 이니셜라이저의 실행이 완료되었을 때, 인스턴스의 모든 저장속성이 초기값을 가지는 것이 생성자의 역할
  • 생성자의 반대개념인 소멸자
    인스턴스가 해제되기 전에 해야할 기능을 정의하는 부분

```swift class Color { //let red, green, blue: Double // 동일한 타입일때, 한줄에 작성가능 let red: Double let green: Double let blue: Double

// 생성자도 오버로딩(Overloading)을 지원 (파리미터의 수, 아규먼트 레이블, 자료형으로 구분)
// 오버로딩을 통해 파라미터 활용의 자유도가 높아짐

init() {  // "init()" -> 기본 생성자. 저장 속성의 기본값을 설정하면 "자동" 구현이 제공됨
    red = 0.0
    green = 0.0
    blue = 0.0
}

Continue reading

Inheritance

Continue reading

또 한달… 그리고 근황

이쯤되면 그냥 회고를 쓰는 주기를 한달에 한두번으로 그냥 정해놓는게 내 맘이 편하지 않을까…ㅋㅋ 최근 학교 축제에, 아카데미 네트워킹 파티에, 논다는 거에 대한 합리적인 변명거리가 생겨서 공부에 소홀하긴 했다. 변명에 불과한거 나도 알지만 어찌되었건 저번주 4일연속 동트는 모습과 함께 집에 들어왔고 일주일에 50을 태운 날 보며 나란 놈의 긴축정책을 위해 생활비 통장의 잔고를 옮겼다.
별 관심 없을 나란 놈의 근황은 이쯤 해두고 아카데미에서의 근황을 말하자면 우리는 일주일간의 작은 챌린지가 끝이나고 6주간의 챌린지로 넘어갔다. 일주일의 기획단계가 끝나고 어느 정도의 문제정의는 끝이 났고 이제 솔루션에 대한 브레인스토밍을 진행하는 단계까지 왔다. 첫번째 미니 챌린지와는 다르게 두번째 미니 챌린지에서 생각지도 못한 벽에 부딪혀서 조금은 힘든 (그래봤자 결국엔 나 혼자만의 착각이었지만) 상황도 있었다.

두번째 미니 챌린지

첫번째 미니 챌린지는 정말 내가 지금까지 겪어본 (회사에서 일했던 프로젝트를 포함해서) 모든 프로젝트 과정 중 제일 이상적이지 않았나 하고 생각될 정도로 팀원과의 호흡도 좋았고, 시너지도 엄청났었다. 한달 과정이 아니라 조금 더 시간적 여유가 주어졌다면 앱스토어에 런칭까지 할 수도 있지 않았을까 하는 아쉬움도 있긴하다. 어찌되었건 지금은 다른 팀원으로 다른 프로젝트를 하고 있으니 이번 챌린지에 대해 이야기를 해보자면.
팀원에는 공교롭게도 디자이너가 없었고, 남자만 6명이었다. 뭐 디자이너가 없다는 점에서는 프로젝트를 통해 디자이너의 인사이트를 얻을 수 없다는 점이 많이 아쉽긴했지만 남자만 6명인 점은 오히려 좋았다. 파이팅있게 싫으면 싫다고 대놓고 이야기하고, 한번 싸우고나면 더 돈독해지겠지, 맘편하게 싫은 소리 할 수 있겠다라고 생각했는데 내 착각이었던 것 같다. 난 싫은 소리를 할 수 있을 정도로 그렇게 성격이 대범하지는 못하단걸 깨달았다.
팀원들에게 문제가 있었던 것은 아니었다. 다만 나의 남 눈치 잘 보고 소심한 성격에 혼자만의 망상이 곁들어져서 일어난 웃지못할 해프닝 정도로 하자. 나도 나름 트리플 A형에 한 소심 한다고 생각했는데, 우리 팀원 중 절반은 말이 적고 소심한 친구들이었고, MBTI가 I성향의 친구들이었다. 지금 생각해보면 정말 어이없지만 정말 우연찮게 우리는 의견이 너무 잘 맞아 이견이 적었고, 소심하고 남의 눈치 잘 보는 나는 그들의 그 ‘나는 좋아요.’, ‘좋은 생각이예요.’라는 말들이 혹시 프로젝트에 관심이 없는건가? 라고 느꼈다.
어느 날은 회의시간동안 정말정말정말정말(x100) 말이 적었고 나와 한두명정도만 이야기를 한다고 느낀 날이 있었다. 말 수가 적은 팀원들은 이 프로젝트에 관심이 없는가 하는 생각을 갖고 있었던 나는 그날 내 부족한 역량이 그들을 이끌어내지 못했다는 생각에 좌절했고 절망해서 멘탈도 너덜너덜해졌다. (‘좌절’과’절망’이라는 워딩이 굉장히 느낌이 쎈데 농담이 아니라 정말 그정도로 멘탈이 나가있긴 했다.)
다음 날 다른 팀원에게 연락해 함께 식사를 하자고 했고, 큰 맘 먹고 내가 느끼고 있었던 생각들을 이야기 하니까 그 팀원은 놀라면서 내게 이런 이야길 해줬다.

정말 리딩 잘 해주고 계셔서 우리 팀원 중에 꼬마님이 있다는 것에 고마웠고 다들 잘 따라가고 있다. 왜 그렇게 생각하시는 지는 모르겠지만 우리 팀 모두 마음이 너무 잘 맞아서 우리 팀원들 모두 마음에 든다.

그 말을 듣고 그 날 회의를 들어가니
팀원들은 각자의 위치에서 자신의 생각을 잘 이야기 하고 있었고, 행여나 내가 내 멋대로 진행하고 있지는 않았나 하며 생각했던 내가 하는 말들에 모두 고개를 끄덕이고 있었고, 모두의 생각이 잘 어울어진 결과물을 내고 있었다.
정말 웃기게도 낮은 자존감에 갇혀버린 예전 나의 눈에는 보이지 않던 것들이 보이기 시작하니 그제서야 일이 풀리기 시작하더라. 아니 어쩌면 이미 잘 풀리고 있던 일들이었지만 내 눈에만 안보였던 거였을것이다.
정말 아카데미에서의 일어나는 모든 일들은 작은 것 하나하나가 매일매일이 배워나감의 연속이다는걸 느꼈다.

진로에 대한 고민

아직까지 확실히 정한 것도 없고 정해진 것도 없고 깊게 생각한 것도 아녀서 자세하게 어떤 방향성에 대한 고민인지는 적지 않겠다. (생각보다 내 블로그를 보고있던 아카데미 러너들이 많더라..) 다만 개발을 공부해보고 싶어서 애플 개발자 아카데미에 지원을 했지만 두가지 프로젝트를 진행하면서 느낀 점은 내가 정말 개발을 공부해보고 싶은걸까? 하는 점과 생각보다 나는 기획을 재밌어 한다는 점이었다.
내가 개발을 공부해보려는 이유는 생각해보면 하나밖에 없는 것 같았다. 오기. 딱 그거 하나 밖에 설명할 수 없는 것 같다. 하고싶은 건 꼭 해봐야 직성이 풀리는 성격인 나는 영상을 공부해보고 싶어서 신문방송학을 부전공을 했었고, 광고 연출을 해보고 싶어서 광고 회사에서 일도 했었고, 마케팅을 해보고 싶어서 회사에서 마케터 포지션으로 프로젝트도 진행해봤고, 음악이 좋아서 음악사업으로 창업도 해봤고, 교육에 관심이 많아서 교육 사업도 했었다. 그런데 개발을 해보겠다고 입학한 컴퓨터공학과에서는 그저 공부가 싫어서 해보지도 않고 도망친 것 밖에 되지 않는다는 내가 좀 한심해서 공부하는 느낌에 가깝다고 느꼈다.
학부생때 교수님이 말씀하신 기억에 남는 말이 있는데, 그 교수님이 전자공학과에서 1학년 성적을 4.5 만점에 4.5점을 받고 컴퓨터공학과로 전과를 했다고 했다. 당연히 주위 모두가 말렸지만 본인이 4.5점을 받았던 것은 전자공학이 적성에 맞지 않다는 생각이 들었고, 해보지도 않고 적성에 맞는지 안맞는지를 판단하기가 싫어서 열심히 공부해서 나온 결과가 자신의 적성과는 맞지 않았다고 하셨다. 꽤나 멋진 이야기라고 생각한다. 9년이 지난 지금도 기억을 하고 있으니 말이다. 이런 관점에서 난 해보지도 않고 도망친 사람 밖에 되지 않았다.
다만 요즘 드는 생각은 개발만 하는 개발자 보다는 개발을 이해하고 있는 IT 기획자도 나쁘지 않을까 하는 생각이 든다는 점이다. 다만 깊게 생각해보지 않아서 뭐가 내 적성에 맞다고는 단정하진 못하겠다. 내가 스타트업 업계에 있을 때, 음악 서비스 사업을 할 때 서비스 기획자로서의 역할이 재밌었던건지, 교육 사업을 할 때 프로덕트 오너로서의 역할이 재밌었던건지도 사실 아직 잘 모르겠다. 스타트업이라는 업계 특성 상 큰 기업처럼 그 역할이 확실히 나누어져 있지 않았었다는 점도 헷갈리는 이유 중 하나일 수도 있겠다.
뭐 자세한 이야기는 좀 더 생각이 정리된 후에 다시 포스팅을 하도록 하겠다. 어찌되었건 내가 이 챕터를 만든 이유는 이 주제로 아카데미 멘토님께 멘토링을 받은 결과 위의 챕터와 비슷한 느낀점이 있다는 게 이유이다. 그 분이 내 이야기를 듣고 해주신 말씀 중에

충분한 자기객관화 후 자신이 부족하다고 생각하는 결핍은 자기 성장에 분명 중요하다고 생각하지만 그게 자신을 위축시키고 한계를 정해버리는 요소가 되어버리면 안된다.

나 스스로가 부족하다고 생각되서 퇴사를 했던 내게 정말 잘 맞아 떨어지는 말이 아니었을까 싶다. 물론 더 배우기 위해 이 아카데미에 들어왔고 아직 7개월이나 더 배울 수 있는 시간이 있으니 뭐가 되었든 내 성장에 포커싱을 맞춰보려한다. 배울 수 있게 모든 게 준비되어있는 곳에서 내가 할 수 있는 최선의 방식으로 배워갈 수 있는 걸 다 빼먹고 나가야지 ㅋㅋㅋ

결론

그냥 회고를 위해 끄적이는 일기에 결론을 쓰는 것도 참 웃기지만, 요 근래 내 경험을 통한 배운 점을 정리하자면

• 남 눈치좀 그만좀 보자. 그냥 니가 할 수 있는 최선을 다해라
• 우리가 탑티어 역량의 인재가 아닌건 너도알고 나도알고 우리 모두가 안다. 겸손은 좋지만 자신을 깎아내리진 말자
• 결핍은 딱 성장의 동기로만 작용하자 자존감을 깎진 말자

Continue reading

Property & Method

속성

• 구조체 / 클래스의 변수
  • 저장 속성 (stored)
  • 지연 저장 속성 (lazy stored)
  • 계산 속성 (computed)
  • 타입 속성 (type)
  • 속성 감시자 (property observer)

Continue reading

Swift Class & Struct

Class & Struct 클래스와 구조체

클래스와 구조체의 개념이 나오고부터 프로그래밍의 패러다임이 바뀌었음

Continue reading

Swift Function

Function 함수

1. 함수 정의
2. 함수 호출(실행)
   • 반복되는 동작을 단순화해서 재사용 가능
   • 코드를 논리적 단위로 구분 가능
   • 코드 길이가 긴 것을 단순화해서 사용 가능
   • 미리 함수를 잘 만들어 놓으면, 개발자는 사용만 하면 됨 (내부적 내용을 몰라도 사용 가능)

함수의 기본 포맷

```swift func doSomething(name: String /파라미터/) -> String { // 함수 정의 var comment = “(name)! do something!” return comment }

Continue reading

Swift Enumeration

Enumeration 열거형

연관된 상수(케이스)들을 하나의 이름으로 묶은 자료형 (클래스)
케이스가 선택가능한 (한정된) 가지 수로 정해져 있을 때 정의

Continue reading

Swift Collection

컬렉션

데이터를 효율적으로 관리하기 위한 자료형(타입)

• Array (배열)
  • 데이터를 순서대로 저장하는 컬렉션
  • 앱, 웹에서 데이터를 저장, 표시하는 형태
• Dictionary (딕셔너리)
  • 데이터를 키와 값으로 하나의 쌍으로 만들어 관리하는 순서가 없는 컬렉션
  • 데이터가 서버에 저장되어 있는 데이터를 받아오는 형태
• Set (집합)
  • 수학에서 집합과 비슷한 연산을 제공하는 순서가 없는 컬렉션

스위프트 함수 이름 규칙

• Mutating : 컬렉션을 직접적으로 변경할 때는 동사 원형으로 사용
  • (sort() , reverse() , shuffle())
• Non-Mutating : 컬렉션을 변경하지 않고, 리턴형으로 다른 컬렉션을 반환할 때는 분사 형태(-ing, -ed)로 사용
  • (sorted() ,reversed() , shuffled())

Continue reading

Swift Optional Type

옵셔널

• 스위프트의 특징 중 하나인 안정성을 문법으로 담보하는 기능
• 타입을 선언하고 값이 없으면 에러가 나는데 옵셔널 타입은 값을 넣지 않아도 nil이라는 임시 값이 들어가기 때문에 자주 활용

옵셔널 타입

let num1: Int? = 2  // 간편 표기
let num2: Optional<Int> = 2  // 정식  문법

옵셔널은 nil이거나 nil이 아닌 값만 가질 수 있다.

• nil : 값이 할당되지 않아 오류가 발생했을 때
• nil 아닌 값 : 오류가 발생하지 않았을 때 반환하려는 값이 옵셔널로 래핑된 형태의 값

Int (정수형 타입) / Int? (옵셔널 정수형 타입) / Double (실수형) / Double? (옵셔널 실수형 타입)

-> 각각 서로 다른 타입이다.

nil은 실제로 값이 없는 것은 아니고 값이 없음을 표현하는 키워드
실제로 값이 없는 다른 언어의 null과는 실제로 값이 없는 것이 아니라서 다른 것

Continue reading

Swift 기본 문법 정리

이번 포스팅은 인프런의 Ellen Swift Class를 보고 스위프트의 기본적인 문법 부분을 정리 기록하기 위해 한 포스팅이다.
나를 포함해서 Swift 이외의 다른 언어로 알고리즘 문제를 푼 경험이 있다면 그냥 모든 언어에 존재하는 문법이지만 스위프트에서는 이렇게 표현했구나 정도로만 가볍게 보고 넘어가도 될 내용이다.

문자열 보간법

Continue reading