보통 프로젝트를 새로 만들면 하나의 프로젝트에 모든 코드와 리소스를 때려박아서 개발을 진행한다.

(내가 그럼 ㅇㅇ)

 

하지만 프로젝트 내에 서브 프로젝트를 만들어 소스 코드를 추가하고,

오직 상위 프로젝트에서만 서브 프로젝트의 코드를 알도록 Build Phase -> Dependencies를 이용할 수 있다.

 

프로젝트, 서브 프로젝트

프로젝트내에 서브 프로젝트를 만들어서 관리할 수 있다.

이는 해당 프로젝트의 코드가 많아지면 서브 프로젝트를 만들어 관리하는 것이다.

 

예제 : http://minsone.github.io/ios/mac/ios-framework-part-2-project-subproject-dependencies

 

[iOS][Xcode] Framework Part 2 : 프로젝트, 서브 프로젝트, Dependencies, 그리고 Static, Dynamic Framework

서론 프로젝트를 만들면 해당 프로젝트 내에 서브 프로젝트를 만드는 것에 이야기를 들어본적이 없었습니다. 프로젝트 하나에 모든 코드와 리소스가 다 들어가도록 개발을 했기 때문입니다. 하

minsone.github.io

 

  1. SampleApp 프로젝트를 생성한다.
  2. SampleApp 프로젝트 내에 Service 서브 프로젝트를 생성한다.
  3. SampleApp's General -> Frameworks, Libraries and Embedded Content에 Service.framework 추가

Framework를 만들면 기본으로 Dynamic Framework로 지정된다. 즉, 위의 방식으로 서브 프로젝트들을 많이 만들게되면 SampleApp 프로젝트에는 많은 Dynamic Framework가 임베딩된다.

 

그것이 맞는 방법일까?

그렇다면 Dynamic Framework 프로젝트를 만들고, 해당 서브 프로젝트로 Static Framework를 만들면 어떻게 될까?

-> Dynamic Library에 Static Library의 코드가 복사되기 때문에, 서브 프로젝트는 많아질 수 있어도, Dynamic Framework는 적은 숫자로 유지된다.

 

  1. Service 서브 프로젝트 내에AppLogService 서브 프로젝트 생성
  2. AppLogService -> Build Settings -> Linking -> Mach-O Type을 Static Library로 변경
  3. Service 서브 프로젝트의 Build Phases -> Dependencies 에서 AppLogService Framework 추가

Service 프로젝트는 Dynamic Framework이며, AppLogService 프로젝트는 Static Framework이다.

그러므로 Service 프로젝트가 빌드되면서 Service Dynamic Library에 AppLogService Static Library가 복사될 것이다.

 

코드를 작성해주자

 

AppLogService

 

Service

SampleApp

 

이후 빌드하면, 생성된 Service Framework의 Dynamic Library를 확인하자.

  1. Service.project의 Product -> Service.framework 파일 선택후, 오른쪽에서 Pull Path를 얻는다.
  2. 터미널에서 수행
  3. Service library의 Symbol 목록을 확인하다보면 AppLogService의 코드가 있는 것을 확인할 수 있다.
    이는 Static Linker가 AppLogService Static Library를 Service Dynamic Library에 복사함을 확인할 수 있다.


 

그렇다면, Service 프로젝트는 서브 프로젝트만 관리하는 프로젝트인 경우

만약 Service 프로젝트는 서브 프로젝트들만 관리하는 프로젝트이고, 사용할 때는 AppLogService 프로젝트의 Service를 호출하여 사용한다면 어떻게 될까?

즉, Service 프로젝트에서 AppLogService 프로젝트를 호출하는 코드가 하나도 없고, SampleApp 프로젝트에서만 호출한다면?

 

  1. Service 프로젝트의 Service.swift 코드 제거
  2. SampleAPp의 AppDelegate에서 다음과 같이 코드 작성


  3. SampleApp의 Product->SampleApp.app 파일 선택 후, 오른쪽에서 Pull Path 확인



  4. 터미널로 명령 실행
    SampleApp의 바이너리의 Symbol 목록에서 AppLogService Static Library 코드가 복사된 것을 확인할 수 있다.따라서 Linker가 Static Library를 사용하는 곳에 코드를 복사함을 알 수 있다.

    이야기를 확장해보면, AppLogService의 Service 클래스의 Bundle 위치는 Service 프레임워크가 아니라, SampleApp이 된다.
    만약에 해당 클래스가 Storyboard나 nib를 사용하는 ViewController의 경우, 코드가 있는 Bundle 위치와 Storyboard나 nib가 있는 Bundle의 위치가 달라진다.
    개발자가 예상하지 못한 곳에 코드가 있으면 안되기 때문에, Static Library를 강제로 우리가 원하는 곳에 복사되도록 해야 한다.
  5. 즉, 상위 Dynamic Framework에서 더미로 코드를 사용해줘야 한다.


AppLogService를 SampleAppdㅔ서 import시, Service.AppLogService로 사용할 수 없을까?

SampleApp에서 AppLogService를 import Service.AppLogService와 같은 방법으로 AppLogService 프레임워크를 호출하고 싶을 수 있다.

왜냐하면 AppLogService 프로젝트는 AppLog로 바꾸어서 Service 프로젝트의 AppLog를 담당하는 서비스라고 생각하고 작업할 수 있다.

SampleApp에서 import Service.AppLogService로 import하면, No such module 'Service.AppLogService' 에러 발생

하지만 UIKit의 UIViewController는 import UIKit.UIViewController로 사용 가능하다.

 

따라서 modulemap을 사용하여 원하는 기능을 구현해보자.

 

  1. Service 프로젝트 내에 빈 module.modulemap 을 생성
  2. module.modulemap 파일 내에 코드 추가


  3. Service 프로젝트의 Build Settings -> Packaging -> Module Map File에 코드 추가


  4. Service 프로젝트의 Service.swift 파일에 코드 추가


  5. module.modulemap 파일에 코드 수정


  6. SampleApp의 AppDelegate에 코드 작성


 

 

XCode에서는 Framewokr라는 것을 통해 모듈화 단위의 코드/리소스를 사용할 수 있다.

그리고 외부 소스를 가져다 사용할 때, Cocoapods, Carthage 같은 도구를 사용할 수 있다.

 

Framework에 대해 알아볼 것들

  1. 어떻게 구성되어있는가?
  2. 어떻게 동작하는가?
  3. Static/Dynamic 차이는 무엇인가?
  4. 전체적인 개발방식

Framework

Dynamic Shared Library, Nib 파일, 이미지, 다국어 문자열, 헤더 파일 등과 같이 공유 리소스를 패키지로 캡슐화하는 계층 구조 파일 디렉토리 이다.

그리고 Framework도 Bundle이며 NSBundle로 접근이 가능하다.

또한, 리소스 사본은 프로세스 수에 상관없이 항상 물리적으로 메모리에 상주하며, 리소스 공유로 풋 프린트를 줄이고 성능을 향상시킨다.

 

Dynamic Framework

XCode에서 Framework를 만들면 기본적으로 Dynamic Framework로 만들어진다.

Dynamic Framework는 동시에 여러 프레임워크 또는 프로그램에서 동일한 코드 사본을 공유하고 사용하므로, 메모리를 효율적으로 사용한다.

동적으로 연결되어 있으므로, 전체 빌드를 다시하지 않아도 새로운 프레임워크 사용이 가능하다.

 

Static Linker를 통해 Dynamic Library Reference가 Application 코드(Heap)에 들어가고, 모듈 호출시 Stack에 있는 Library에 접근하여 사용한다.

 

Static Framework

Static Framework는 Static Linker를 통해 Static Library 코드가 Application 코드 내로 들어가 Heap 메모리에 상주한다.

따라서 Static Library가 복사되므로, Static Framework를 여러 Framework에서 사용하게 되면, 코드 중복이 발생한다.

 

Library는 Framework가 아니라 Static Library가 복사된 곳에 위치하므로, Bundle의 위치는 Static Framework가 아닌 Static Library가 위치한 곳이 된다.

때문에 번들을 접근할 때는 스스로가 접근하기보다는 외부에서 Bundle의 위치를 주입받는 것이 좋다.

 

어떤 타입을 사용해야 하는가?

일반적으로 리소스를 스스로 갖고 있거나 전체 소스를 제공하는 경우 -> Dynamic Framework

그렇지 않고 SDK 형태로 배포하는 경우 -> Static Framework

 

 

 

 

 

Framework

  • 코드(클래스, 프로토콜, 컴포넌트)/리소스들을 모듈화한 모음
  • 사용하는 주체와 IoC(제어의 역전) 관계
  • 특정 개념들의 추상화를 제공하는 여러 클래스나 컴포넌트로 구성되어 있다.
  • 컴포넌트들은 재사용 가능
  • 고수준에서 조작 가능
  • iOS에서 제공하는 Cocoa Touch 프레임워크가 존재한다.

Library

  • Application이 연결할 수 있는, 패키징된 객체 파일들의 모음
  • 사용하는 주체가 기능을 요청하며 사용한다.
  • 즉, 개발자가 만든 클래스에서 직접 호출해서 사용

 

차이점

제어의 흐름에 대한 주도성이 누구에게 있는가에 달렸다.

즉, Application의 Flow를 누가 쥐고 있는가?

  • 프레임워크는 전체적인 흐름을 스스로가 쥐고 있고, 사용자는 그 안에서 코드를 넣는다.
  • 라이브러리는 사용자가 전체적인 흐름을 만들고, 라이브러리를 필요한 곳에서 가져다 쓴다.

다시 말해, "라이브러리는 라이브러리를 사용하는 측에 주도성이 있고, 프레임워크는 그 틀안에 주도성을 갖고 있다" 고 볼 수 있다.

 

 

제어의 역전(IoC)

어떠한 일을 하도록 만들어진 프레임워크에 제어의 권한을 넘김으로써, 클라이언트 코드가 신경쓰는 것을 줄이는 전략

내가 라이브러리의 메소드를 사용하는 것은 쉽게 이해할 수 있다.

결국, 프레임워크의 메소드가 사용자의 코드를 호출한다... 인데

어떻게 프레임워크가 내 메소드를 호출하는가?

  1. 쉬운 방법 : 프레임워크의 event, delegate에 나의 메소드를 등록시키는 것
  2. DI : 프레임워크에 정의된 protocol 을 나의 코드에서 구현, 상속한 후에 프레임워크에 넘겨준다.
    1. 이는 객체를 프레임워크에 주입하는 것이다.

 

 

 


모듈화

하나의 프로젝트에 모든 기능들을 넣어서 개발하다보면 어느 순간 단점들이 생긴다.

  1. 컴파일 속도
  2. 하나의 코드를 고쳤을 때, 발생하는 사이드 이펙트

따라서 모듈화를 통해 결합도를 낮추고, 응집도를 높히는 작업

 

출처 : http://minsone.github.io/ios/mac/ios-enterprise-app-configuration-1

  • Module : 라이브러리를 가진 프로젝트로, 특정 역할(네트워크, Custom UI 등)을 수행, 외부에는 정의한 protocol을 통해 호출가능하게 한다. 
  • Module Package : 모듈들을 관리, 모듈들의 결합으로 기능을 확장
  • Service : 특정 도메인, 서비스를 관리하는 프로젝트
  • Common Service : 인증, 보안 등 다른 서비스에서 공통으로 사용되는 서비스
  • Main Service : 각 서비스들을 호출 및 연결
  • Application : UIApplication에서 제공하는 기능을 받아서 처리

 

장점

  1. 메인 프로젝트에서의 라이브러리 의존성이 사라짐
  2. Widget, Watch 등을 개발할 때, 모듈을 쉽게 사용할 수 있음
  3. Clean Build시에는 빌드가 느리지만, Rebuild시에는 해당 수정 부분만 컴파일되므로 훨씬 빨라짐

 

 

 

 

 

 

 

 

 

 

 

 

 

글쓰는 재주가 없다보니 사실 그냥 남길 것이다... 

6개월이나 지나서 남기는 이유가 무엇이냐? -> 내가 개발자가 될 수 있었던 것은 2020년이 있었기 때문이라고 생각한다.

글은 시간 순서로 작성할 것이다. 사실 기억이 왜곡되거나 사건의 순서가 뒤죽박죽일 수도 있지만... 어차피 나만 보지 않겠는가? 이거?ㅋㅋ

아무래도 상관없다.

끄적여보자

 

2020년 상반기

1. Nexters(넥스터즈) - 1

IT 연합 동아리 넥스터즈

 

NEXTERS | Network for Experts

IT 연합동아리 넥스터즈(NEXTERS)는 IT 생태계의 주인공인 개발자와 디자이너들을 위한 모임입니다. 재능있는 디자이너와 개발자들이 함께 모여 자유로운 분위기에서 어울리고 도움을 주고받으며

teamnexters.com

 

교내에서 항상 프로젝트를 진행하면서 안드로이드만 진행하였다. 당시 항상 팀을 함께 개발했던 친구들과만 팀을 맺었고, 프로젝트 점수는 항상 높았다. 이에 근거없는 자신감이 생겼는지 교외로 나가보고 싶었다.

Nexters에 합격한 후 느끼게되었다. (나 어떻게 뽑힌거지?) 나보다 잘하는 개발자들이 훨씬 많았다. 이때가 내 변화의 시발점이 되었다. 그리고 이 말을 항상 되뇌였다. 우물 안 개구리

 

넥스터즈는 생각보다 큰 동아리였다. 16기 OT 세션에서 내가 개발하고 싶은 서비스를 선택할 수 있었다. 다행히 내가 하고싶은 서비스 팀에 들어갈 수 있었고, 2명의 iOS, 2명의 Android, 1명의 Server 그리고 3명의 디자이너 로 구성된 팀을 꾸려 프로젝트를 진행했다.

 

기존에 Git이라곤 Push/Pull 밖에 사용하지 않았는데, PR을 날려볼 수 있었고, Slack, Zeplin, Notion 등 협업 툴을 다뤄볼 수 있었다.

또한, PM님이 노션 관리를 "정말" 잘해주신 덕에 개발하면서 필요없는 생각은 안할 수 있었다.

 

동아리 기간인 8주동안 개발을 완료하지 못했다. 변명으로는 사실 화면이 많았다고 하고 싶다... 어찌저찌 1달 정도 더 프로젝트를 진행했고, 성공적으로 런칭할 수 있었다.

https://play.google.com/store/apps/details?id=com.nexters.frutto 

 

Frutto - 커뮤니티를 즐겁게 만드는 마니또 앱, 프루또 ! - Google Play 앱

프루또는 커뮤니티를 즐겁게 만드는 마니또 앱입니다. Manito Apps Make Community Fun

play.google.com

2. 알고리즘 공부(백준)

많은 기업들이 슬슬 채용을 위한 코딩테스트로 넘어간 시기였다. 그때까지 난 N/K/L 등 서비스 기업에 들어가고 싶은 생각이 ... 많이 있었다. 하지만 나보다 잘하는 사람들을 많이 봐왔기에 자신감은 바닥을 쳤고, 어렸을 때부터 들었던 대기업들을 최고 목표로, 중견기업이라도 가고 싶다 라는 생각을 품게 되었다.

그런데 왜 알고리즘을 공부했냐? -> 국내 대기업인 S기업이 코테를 본다기에, 다른 기업들도 보겠구나... 하고 공부했다.

 

19년 2학기에 교내 수업을 듣고 있었다. 학점을 위해 이해도 안가는 영어/단어들을 적으며 난리부르스를 추고 있었는데, 옆에서 친구가 노트북 키보드를 탁탁탁 치고 있었다. ??? 지금 저렇게 열심히 필기할 게 있어? 물었더니, 친구는 알고리즘을 풀고 있었다.

나 : "그게 뭔데?"

친구 : "우리가 배운 알고리즘들을 갖고 문제를 푸는 것이다. 정말 재밌다"

나 : "그게 재밌어? 알고리즘 극혐" -> 알고리즘 학점이 전공 점수 중에 제일 낮았다...

쨋든... 이 사건이 기억나서 친구에게 어떻게 공부를 시작해야 하는지 물었고, 친구는 백준 사이트를 추천하였다.

백준

 

Baekjoon Online Judge

Baekjoon Online Judge 프로그래밍 문제를 풀고 온라인으로 채점받을 수 있는 곳입니다.

www.acmicpc.net

이때부터 이리저리 블로그를 찾아다니면서, 기업 코테에는 DFS/BFS/Brute/시뮬 등 비슷한 유형의 알고리즘 문제가 나온다는 것을 알았고

해당 문제들을 천천히 풀기 시작했다.

꾸준히... 알고리즘을 건드렸지만, 백준은 2월부터 7월? 까지 푼 것 같다. 한 6개월쯤..?

어느 수준 이상의 문제들은 너무 어려워서 사실 건드리지도 않았고, 충분히 알고리즘을 이해한 순간부터는 풀었던 문제들은 최대 10번까지는 다시 풀었다. -> 6회 이상부터는 외워졌다. 그래서 최대한 안외운 상태로 풀기 위해, "오늘 푼 문제는 2주 후에 풀기" 규칙을 적용했다.

3. 20년 1학기

직전학기에 6전공을 수강하며 전공학점을 이미 채웠기에, 소위 말하는 "꿀 과목"들만 진행했다.

더군다나 코로나로 인해서 수업들은 온라인 강의 혹은 동영상 강의로 진행되었기에, 알고리즘 공부 / CS 공부 시간을 갖기엔 충분하다고 이때까지는 생각했다.

졸업 프로젝트를 위한 전공 수업 말고는 모두 교양으로 채웠다.

 

4. 네이버 핵데이

https://wlgusdn700.tistory.com/20?category=857175 

 

네이버 핵데이 합격 소식 + 팀 구성 및 프로젝트 방향잡기

2020 Summer 네이버 핵데이에 지원하였다. 대학 단톡방에서 소식을 듣고 지원 사이트를 들어가보니, 제출 가능 시간이 몇시간 안남아서 뭐라썼는지 기억도 안난다... 연합 동아리에서 진행한 프로

wlgusdn700.tistory.com

저때가 제일 생생한 기억일텐데, 저렇게 적혀있으니... 지금은 적을게 없다.

핵데이를 위한 자소서/포트폴리오를 준비해야 했다. 포트폴리오는 교내에서 진행한 프로젝트/동아리 프로젝트/휴학하고 진행한 프로젝트 등

안드로이드 관련 프로젝트들은 간단하게라도 다 적었다. 

그리고 자소서에는 내가 얼마나 열심히 공부하고 있는지?, 지금까지 무엇을 공부해봤는지? 를 적었다.

운좋게 합격해서 핵데이 과정을 진행했고, 인턴 전환 면접에서 떨어졌다.

https://wlgusdn700.tistory.com/110?category=857175 

 

핵데이 1년이 지나서야 후기...

사실 취업하고 이리저리 띵까띵까 놀다가, 이것저것 배우고 공부하면서 핵데이에 대한 기억이 많이 지워지고 왜곡되었을 가능성도 있다. 하지만 내 기억인데 뭐... 적어보자. 핵데이 핵데이에

wlgusdn700.tistory.com

핵데이를 진행하면서 새로운 기술/라이브러리 등을 익히는 것보다는 해당 모바일 플랫폼에 대한 이해가 더 중요하다는 것을 깨달았다.

아무리 신기술들을 공부해봐야, 기본 구동 원리나 플랫폼 지식이 없으면 결국 안쓰느니만 못하다고 느꼈다.

 

5. SW마에스트로 - 1

SW마에스트로

 

SW마에스트로

Application Guidelines SW마에스트로 모집 요강 및 접수 - 연수생 특전 소개, 지원절차 안내, 모집 공고 (SW마에스트로 연수생 지원), 연수생 지원 연수생 특전 IT기기 노트북 등 IT기기 구입비 최대 150만

www.swmaestro.org

우연히 넥스터즈 동아리를 진행하면서, 같은 학교 선배(귀인)를 만났다! 정말 많은 것을 물어봤으며, 많은 것을 배울 수 있었다.

그러던 중, 선배가 SW마에스트로(이하 소마)를 진행했다는 사실을 알았고, 소마에 대해서 찾아보기 시작했다.

핵데이를 진행하고 있던 시기에도 신경을 소마에 더 쏠렸다. 왠지 정부에서 진행하는 거라 그랬던 듯...

어쨋든 자소서도 선배덕분에 처음 써봤으며, 면접 준비도 많이 도와주셨다..! -> 다시 한번 감사드립니다+_+

당당히 소마에 합격했고, 같은 학교 친구와 함께 붙었다..! 사실 3번에서 적었듯이 항상 같은 친구들과 팀을 했다고 했는데... 그 친구 중 한명이다. 다른 팀을 꾸리려고 했으나... 낯선 사람보다는 믿는 사람과 그리고 보다 재밌게 진행하기 위해 친구와 팀을 꾸렸고, 서버파트의 팀원을 구하여 3명이서 팀을 결성했다.

클라이언트/서버/ML 로 이뤄진 팀을 결성했기에, 멘토님들을 전략적으로 선정해야 했다.

이미 현업에서 어마어마하게 업적을 이루신 분들이기에, 대하기가 어려웠지만... 팀장이라는 명목하에 어떻게든 비벼가면서 멘토님들을 선정(?)했다.

 

아이디어를 선정하고, 직접 아이디어의 성공을 위한 시장을 조사하고, 논문/특허들을 조사하는 과정을 처음으로 겪었다.

처음엔 너무 신기하고 배우는 것도 많고 재밌었다. 하지만 글만 보고, 브레인스토밍을 진행하면서 수익이 될지 생각하고, 평가를 위해 다시 아이디어를 보완하는 과정이 약 1달 동안 진행될수록, 우리는 개발이 하고 싶어졌다. 하지만 기획 심사를 통과하지 못하면 몇차례 다시 심사를 받아야 했기에, 우린 개발 시작을 위해 자료조사를 하고... 또 하고... 또 했다.

그렇게 팀원들과 멘토님들의 도움 덕분에 기획 심사에서 단번에 통과할 수 있었다.

 


2020년 하반기

6. Nexters(넥스터즈) - 2

16기 넥스터즈(20년 2월)가 끝난 이후, 17기 운영진으로 발탁되었다.

사실 내 인생에서 이토록 바쁜 시기는 이때이지 싶다... 2분기에 동시에 핵데이, 소마, 운영진, 학교, 알고리즘 공부를 병행하게 되었으니...

내가 잘 해냈으리라고 아무도 못 믿을 것이다..! 실제로 잘 해내지 못했기 때문이다!

학교는 (꿀)과목들만 골랐지만, 과제와 레포트를 제출해야 했다. 학점은 이때부터 포기했다. 그냥 졸업만 하자! 라는 생각으로 대애애애충 했다.

알고리즘 공부는 안바쁠 때는 하루에 3~4문제까지도 풀었지만, 하루에 쉬운 문제라도 한 문제씩 푸는 것을 목표로 변경했다.

그렇게 17기 넥스터즈를 어떻게 꾸려나갈 지에 대한 회의를 진행했다.

주 1회 회의였지만, 코로나 이슈로 인해서 불안해하는 회원들과 대관 이슈가 겹쳐서 이것저것 찾아보는 데에 많은 시간을 소요했다.

물론 이것도 어찌저찌... 최선은 다해서 진행했다.

 

그렇게 17기 넥스터즈를 운영진으로써 참여했고, 동시에 팀에 iOS 개발자로 들어가게 되었다.

아직 iOS에 대해 1도 모르지만, 혼자 어떻게든 개발해내고 싶어 알고리즘은 포기하고 프로젝트 개발에만 몰두했다.

혼자서 진행하기엔 너무 많은 화면과 기능이었지만, 어떤날을 밤을 새기도 하면서 개발하면서 iOS와 안드로이드의 차이점을 조금씩 이해할 수 있었고, iOS 개발을 익혀나갔다.

 

하지만 기간 내에 프로젝트를 완성할 수 없었고, 약 1년이 지난 지금 그 프로젝트의 iOS를 다시 진행하려고 마음을 먹었다.

7. 디자인 씽킹 과정

소마에서 디자인 씽킹 과정을 신청하라기에, 팀원과 함께 신청하였다.

3일 동안 아침부터 저녁까지 판교에서 디자인 씽킹 과정을 수강했다.

처음엔 너무 당연한 이야기를 어렵게 푸는 것 아닌가? 싶었다.

하지만 듣다 보니, 당연하지만 행동하기에 어려운 것들이었으며, 생각하는 관점을 넓힐 수 있었다.

당시에 내 목표만을 이루기 위해, 내가 스스로 정한 길 위에서 나는 달려가려 했지만, 과정을 수료하면서 소통과 소통하는 방법 등에 대한 중요성을 깨닫게 해주었다.

 

8. SW마에스트로 - 2

프로젝트는 태블릿과 모바일 App이 필요한 프로젝트였다. 따라서 태블릿은 안드로이드, 모바일은 iOS로 개발을 시작했다.

동시에 팀장 역할까지 맡았기에, 멘토님들과의 소통, 팀 프로젝트 관리 그리고 아무래도 프로젝트를 소마 측의 지원금을 통해서 진행하다보니 제출해야하는 서류들이 너무 많았다. -> 다시 말해 뭐하나 제대로 하지 못한 무능력한 팀장이었다...

일정은 산출했지만, 실제로는 그것들보다 훨씬 오래 걸렸다. 그 이유로는 내가 멘토님들과의 맺고 끊음을 칼같이 하지 못하여, 다른팀들에 비해 2배이상의 멘토링을 잡아버린 것이다. 멘토링도 좋지만, 당시 우리에게 필요한 건 개발에 몰두할 수 있는 "시간"이었다.

 

결국 끝까지 맺고 끊음을 하지 못해, 우리의 목표보다 완성도는 현저히 떨어진 결과물이 나왔다.

그리고 수료를 약 2주 앞두고 난 취업을 하여, 2주 때문에 수료증을 받지 못한다.

 

9. L사 입사

하반기 서류를 가고 싶었던 곳들에 모두 썼다. 그리고 가장 빨리 발표난 곳에 바로 입사를 하였다.

왜냐하면... 다른 곳들에 붙을 자신감이 없었기 때문이다...

 

내가 어렸을 때부터 바라던 대기업에 입사하였다. 처음엔 좋았다. 교육, 회사 소개, 문화 그리고 월급! 이 좋았다. 

내 힘으로 내가 번 돈을 만져보는건 처음이었다(알바 제외...)

하지만 개발 교육을 진행하면서 느꼈다. 물론 자바 개발자가 되는 것은 알고 있었다. 그리고 자체 서비스 개발을 못하는 것도 알고 있었다. 그런데도 아직 난 모바일 개발을 하고 싶었다. 

이미 입사는 하였지만, 남은 전형들이 있었기에 좀 더 노력했다. 내가 원하는 모바일 개발을 하기 위해...

 

10. K사 입사

정말 운이 좋게 K사에 최종 합격하였다..!

바로 다음날, 동기들에게 퇴사를 선언했다. 아직도 동기들과는 가끔 연락하며 지낸다.

다른 것보다 원하던 모바일 개발을 할 수 있게 되어 가장 기뻣다. 실제 개발자들이 어떻게 개발할지?, 무엇을 개발하는지? 등과 같은 질문을 얼른 팀원들에게 하고 싶었다.

그리고 동시에 무서웠다. 내가 잘할 수 있을까? 실수하면 어떡하지? 등등의 걱정이 앞서기 시작했다.

하지만 OT를 통해서 두려움이 싹 사라졌다. 듣던대로 자유로운 분위기였다. (사실 뽕 주입돼서 망각했을 수도 있다.)

 

그렇게 2020년을 보냈다.

 


지금까지 살아온 해 중, 가장 회고를 작성하고 싶은 해였다.

그만큼 나 스스로 열심히 준비했다고 생각하기 때문이다.

 

가끔 생각한다. 내가 고등학생으로 돌아간다면 공부를 더 열심히 할 것인가? -> YES!! 당연! 이라고 답할 것이다.

하지만 이때로 돌아간다면 똑같은 생활을 하겠는가? -> NO, 자신 없다. 그리고 이때처럼 많은 것을 동시에 하기보다는, 몇가지에만 몰두하고 싶다.

 

중간중간에 더 많은 사건이 있었지만, 큼지막한 기억들만 적어보았다.

첫 꿈은 크지 않았다. 중견기업에 가서 3500만 받으면 소원이 없겠다...

하지만 더 많은 사람들과 이야기하며, 개발자 세상과 IT 업계에 대해서 들으면서 꿈을 키웠다. 그리고 꿈이 커진만큼 스스로도 맞춰야겠다는 생각을 했다. 개구리가 우물 밖으로 나가기위해 발버둥을 시도하는 것이다. 그렇게 개구리는 우물 밖으로 나가서 자신보다 훨씬 거대하고 잘난 생물들을 마주하여 뒤쳐질 때도 있었지만, 그 친구들을 통해 세상에 적응하는 법을 배우게 되었다.

 

난 아직 쪼렙 개발자라서 아는 건 많지 않지만, 그만큼 배우고 싶은 것들이 많다.

그건 좋은 것 같다!

 

자리잡고 조리있게 쓰고싶었다만... 이미 시간도 많이 지났고 기억도 안나서 주저리주저리 혼자 적어봤다.

 

 

 

 

 

 

 

 

 

 

 

 

+ Recent posts