Dictionary의 키는 왜 Hashable 타입인가요?

• 왜 Dictionary/Set의 탐색은 O(1)인가?
• 왜 Dictionary 탐색의 최악의 경우는 O(n)인가?
• Hashable의 hashValue는 왜 Int 인가?
• Hashing을 왜 하는가?
• 좋은 해싱 알고리즘이 필요한 이유는?

위 질문에 대한 답을 명확히 하기 힘들다면 Array만을 가지고 Dictionary를 직접 구현해보는 것을 추천한다. 그 과정에서 알게 되는 것들로 위 질문들에 대한 답을 찾을 수 있다.

요구사항은 아래와 같다.

• 자료 구조는 Array만 사용한다.
• Hashable 타입은 사용하지 않는다.
• 구현해야 하는 메서드

  func value(forKey key: Key) -> Value?
  func insert(_ value: Value?, forKey key: Key)
  var count: Int { get }
  

변수와 상수의 차이가 뭐에요?

Swift에서 변수를 선언할 때는 var, 상수를 선언할 때는 let 키워드를 사용한다. 보통 변수는 값을 바꿀 수 있는 것, 상수는 값을 바꿀 수 없는 것이라고 말한다. 변수가 기본 자료형일 때는 값을 바꾼다 라는게 무슨 뜻인지 매우 명확하다. 정수 1을 2로 바꾼다, 소수 3.14를 3.15로 바꾼다, true를 false로 바꾼다 등. 반면에 변수가 객체일 때는 생각할게 좀 더 많아진다.

변수가 객체일 때 “값을 바꾼다(mutation)”는 두 가지 의미가 있을 수 있다. 객체의 속성을 바꾸는 것도 될 수 있고, 변수가 가르키는 인스턴스를 바꾸는 것도 될 수 있다.

// 1. 객체의 속성을 바꾼다.
var person = Person(name: "John")
person.name = "Jane"

// 2. 변수가 가르키는 인스턴스를 바꾼다.
var person = Person(name: "John")
person = Person(name: "Jane")

그렇다면 값을 바꾼다는건 이 중에 어떤걸 의미하는걸까? 객체를 var로 선언하면 둘 다 될까? let으로 선언하면 둘 다 안될까? 여기에 객체의 종류까지 추가해서 Person 객체가 struct일 때와 class일 때를 각각 따져본다.

정리하자면 다음처럼 여덟 가지 경우의 수가 나온다.

이를 토대로 던져볼 수 있는 질문들

• var와 let을 나누는 기준은 무엇인가?
• struct와 class가 mutation을 나누는 기준은 무엇인가?
• 값 타입과 참조 타입이라는 것이 영향을 미치는가?
• 객체의 속성을 바꿀때 class와 struct에서는 각각 어떤 일이 일어나는가?
• class와 struct 중에 선택할 때 고려해야 하는 것들은?

등등…

영업 전략에는 Always Be Closing(줄여서 ABC)이라는 유명한 표어가 있다. 거래를 성사시키다라는 뜻의 “Close a deal”이라는 표현에서 온 문구다. 영업 사원의 궁극적인 목표는 거래를 성사시키는 것이다. 그러므로 언제나 거래를 성사시킬 기회를 호시탐탐 노리고 있으라는 뜻으로 해석된다.

프로그래머의 궁극적인 목표는 사업이 돌아가게 해주는 코드를 배포하는 일이다. 하지만 코드를 실환경에 배포하기까지 많은 장애물을 넘어야한다. 코드를 작성하기 전부터 논의해야 할 것도 많고, 코드를 작성하면서는 동료 개발자랑도 맞춰가야하고, 다 작성한 후에도 여러 검증을 통과 해야한다. 대기업에서는 관계자들이 많아서 각 팀의 입장을 조율하느라 일을 진척시키기 쉽지 않고, 스타트업의 상황은 시시각각 바뀌고 개개인이 할게 너무 많아서 벌인 일들이 흐지부지 결론이 안날 때가 있다. 그래서 대기업, 스타트업 구분할 거 없이 일을 끝맺을 줄 아는 능력은 빛난다.

각별한 노력 없이는 일이 막다른 길에 부딪히기 쉽다. 특히 관여하는 팀이 많을수록, 성과가 잘 드러나지 않거나 장기적일수록 그렇다. 자신이 직접적으로 책임지는 일을 잘 마무리하기 위해서 뿐 아니라 내가 크고 작게 관여하고 있는 주위의 수많은 일들의 진행이 탄력을 잃지 않게 할 수 있는 몇 가지 팁이 있다.

1. 타임라인 제시

일이 더 진행되기 위해서 추가적인 작업(연구 조사, 프로토타이핑 등)이 선행되어야하는 경우 대략적으로나마 얼마나 걸릴지 제시해두면 같이 일하는 사람들이 후속 작업을 계획할 수 있다.

2. 후속 회의 시간 잡기

논의가 마무리되지 않았을 때, 해산하기 전에 다음 회의 시간을 잡아버리면 일이 늘어지는 걸 방지할 수 있다.

3. 업무 관리 도구에 기록

일하면서 느낀게 있다면 기억력을 믿어선 안된다는 점이다. 기록해두지 않으면 ‘나중에 하자’, ‘언젠가 하면 좋겠다’ 고 약속한것들은 사라진다. 당장 작업에 돌입하지 못하는 일이라도 일단 관리 도구에 바로 바로 등록해두자.

4. 대안 제시

경험상 일이 막히는 가장 흔한 상황은 누군가가 ‘A 할 수 있어요?’라고 물어봤을때 ‘아니요’ 라고 대답하고 끝내는 상황이다. (개인적으로는 이 질문부터 잘못됐다고 생각하지만 이건 별개의 주제라서 넘어가고) 요청 받은 일을 내가 할 수 없다면 도와줄 수 있는 사람을 알려주거나, 다른 이유가 있다면 왜 안되는지, 무엇을 보완해야 하는지 사소한 것이라도 던지면 상대방은 일을 이어갈 수 있다.

5. 액션 아이템 도출, 담당자 지정

회의의 끝에는 각자 무슨 일을 해야하는지 명확히 알고 헤어지는게 최선의 상황이다. 종종 누가 뭘 할지 정하지 않고 회의를 끝맺는 경우가 있다. 할 일도 뭉뚱그려 팀으로 지정할 때가 있는데 그러지말고 정확히 담당자 개인을 지정하면 나중에 일의 진척을 추적하기 쉽고 개인도 책임감와 주체성을 가질 수 있다.

일을 처리하는건 시냇물이 바다에 도달할 때까지 물길을 계속 터주는 행위와 비슷한거 같다. 일이 계속 진전되도록 사소하더라도 도움을 주거나, 보다 적극적으로 내 선에서 일을 매듭 짓겠다는 마음가짐을 가지면 좋겠다.