OTIS | 일하는게 행복한 개발자

안녕하세요 
항상 개발이 즐겁고 
배우는게 너무 좋은
일하는게 행복한 개발자 OTIS 입니다.

Contact.

Email. dhstjrxo123@gmail.com

Phone. 010-4200-6215

Channel.

Blog. https://otis.tistory.com/
GitHub. https://github.com/1domybest

 

 

 

 

 

---

Introduce

2020년 산업체를 제대한후 

바로 6개월동안 개발을 독학한후

국비지원을 통해 6개월간 교육을받았습니다.

그리고 첫 회사에 입사하여 

2년간 1개의 프로젝트를 유지보수를 진행하고 3개의 프로젝트를 A-Z까지

혼자 개발하였습니다.

 

그러다 지인의 기회를 통해 다른회사의 면접기회를 얻어 현재는 

IDID 라는 회사에서 IOS 개발자로 일을 하고있습니다.

첫회사에서 하였던 프로젝트에대한 설명들은

기존에 만들었던 링크로 대체하겠습니다.

2023.01.11 - [일상] - OTIS | 배우는 게 행복한 개발자 [비전공자 출신 개발자 자기소개]

 

 

 

---

Projects

 

Baund

Baund (바운드)

한국 힙합 커뮤니티 어플리케이션

---

Links

 

---

Skills

• ReactNative
• Swift
• Kotlin

 

Position

저는 주로 카메라 쪽을 담당하였습니다.

크게 3가지의 역할을 맡아 진행하였습니다.

 

카메라

• 카메라 코드 유지보수
• DeepAR  을 카메라와 연동하여 카메라 필터적용
• 회사 외부에서 제작한 CPP로 만든 오디오엔진과 기존 카메라와 연동

 인코더

• 녹화기능
• FFMpeg을 사용한 인코더 제작

ReactNative

• RN 과 네이티브를 연결해주는 브릿지 제작
• 비디오 에디터관련 UI제작

 

 

 

 

Projects

Hypy (하이피)

일본 아이돌 성장 어플리케이션

---

Links

---

Skills

• Swift
• SwiftUI
• UIKit
• Object-C

 

Position

카메라, 플레이어, 라이브스트리밍, 담당페이지 (SwiftUI,UIkit) 을 담당하였습니다.

라이브스트리밍

• HaishinKit 이라는 RTMP Encoder 오픈소스를 라이브스트리밍 하여 라이브스트리밍을 제작하였습니다.
• HaishinKit 오픈소스에 데이터를 활용하여 실시간 네트워크 디버깅이 가능하도록 제작하였습니다.
• 웹소켓을 사용하여 실시간 채팅기능을 구현하였습니다.

카메라

• 개인적으로 프레임워크와 오픈프로젝트를 생성하여 멀티세션[전,후면 카메라동시사용]을 사용한 카메라를 직접 제작하였습니다.
• gpupixel 이라는 오픈소스를 활용하여 카메라 뷰티필터 기능을 적용하였습니다.

플레이어

• AVPlayer를 사용하여 VOD, 라이브스트리밍 플레이어를 제작하였습니다.
• AVPlayer에서 받아오는 비트레이트의 크기를 토대로 네트워크 디버깅이 가능하도록 제작하였습니다.

UI

• 실시간 채팅을 위해 UITable을 사용하여 Cell을 재사용하는 전략으로 채팅 UI를 구현하였습니다.
• UIkit을 사용하여 BottomSheet를 커스터마이징 하였습니다.
• UIKit을 사용하여 CustomAlert창을 구현하였습니다.

 

 

 

 

프로젝트에대한 경험

약 4년동안 6개의 프로젝트를 진행하면서
많은것들을 느꼈습니다.

---

1. 언어의 대한 장벽이 사라졌습니다.

 

비록 얕은 지식이였지만 여태 작업했던 프로젝트에서 사용했던 스킬들은

• vue.js
• spring boot
• jpa
• aws ec2
• Swift
• SwiftUI
• UIKit
• Kotlin
• Object-c

이렇게 사용하였습니다. 그렇기 때문에

항상 프로젝트를 진행하면서 배우는것에대해 재미를 느끼고 자신감이 생겼습니다.

그리고 느꼈던건 언어는 실제 언어와 비슷하다는 느낌을 많이 받았습니다.

"나" 라는 사람이 말하고싶은 문장이 있고 그걸 그냥 다른언어로 표현한다는 느낌?

이러한 생각은 개발로 시작한건아니고 실제 영어를 공부하게되면서 느꼈습니다.

영어같은경우 갑자기 배우고싶다고 생각해 2018년에 4개월정도 유튜브로 공부를하였습니다.

그때 영어를 문법적으로 공부하지는 않았고 

내가 하고싶은 말들을 한국어로 적고 그게 영어로 뭐지? 라고 생각하면서 계속 상황을 상상하고

연습하였고 그결과

바로 외국인친구들과 많이사귀어서 현재는 원어민까지는아니지만 가깝게한다고생각합니다.

 

---

2. 협업이 재밌었습니다.

두번째 회사를 다니면서 첫 협업을 진행해왔고

저로서는 기존 풀스택을 했던 경험이 있기때문에

협업하면서 서버팀과 티키타카했던 기억이 좋은기억으로 남아있습니다.

그리고 협업을 진행하면서 느낀것들이있습니다.

qa는 만인의 qa 입니다.

단 서버와 기획의 qa는 클라이언트라고 느꼇습니다.

그이유는 서버와 기획단에서는 아무리 잘 제작을해도 실제로 

눈으로 보이지않기때문에 생각지도못한 부분이 발생하기 마련입니다.

그렇기때문에 누구보다 기획서를 잘읽고 그것을 토대로 서버와 기획팀과 소통을 많이 해야
추후에 발생한 버그가 줄어든다는것을 많이 느꼈습니다.

 

---

3. 4년차에 경험할수없는것들을 경험했습니다.

웹,앱 A-Z까지 경험하였고 팀 내에서는 개발에 관해선 의지가 될수있는 사람였습니다.

 

여기에서 의지가 될수있는 사람이라는 말을 하였는데

저도 네이티브가 처음이고 다른사람들도 처음이였지만 첫 프로젝트때

네이티브에 대해 조금이라도 경험이 있었기 때문에

자연스럽게 팀내에서 항상 질문을 받고 도와주는 역할이 되었습니다.

 

그렇기때문에 공통 모듈을 만들때 정말 여러가지것들을 고민한것같습니다.

 

1. 과연 이걸 공통모듈로 만들 필요가 있을까?
2. 데이터를 필요한 데이터를 받아야할까 오브젝트 형식으로 확장가능성을 열어두어야할까?

3. 사용빈도가 적은 이 기능에대해 성능을 고려할 필요가 있을까? 

4. 혹시나 예상치못한 버그가 발생했을시 어떻게 예외처리를 진행해야할까?

 

이러한 것들을 고민해왔고

현재까지는 이러한 결론을 내려서 일에 몰두하고있는것같습니다.

 

---

 

4. 변수명은 길더라도 의미있고 말이되는 변수명

 

한 파일안에 stored 와 isStoredIdol 

이라는 변수명이 존재했을경우에

이게 한사람이 제작한 파일이라면 문제는 없지만
그게아니고 여러사람이 참여하고 제작한지 꽤된 변수명이라면

제3자가 그 파일을 봤을떄 isStroredIdol 이라는 변수명을 봤을때

저장된 아이돌이니? 라는 Bool타입을 추측할수있지만

strored 라는 변수를 봤을때는 주체가 뭔지 추측이 불가능하기에 

주석이 없다는 가정하게 코드를직접 봐야지 알수있고

실제로 비슷한일이 있었습니다.

비록 예시는 짧지만 조금 길더라도 말이되는 변수명을 사용하자라는 생각이 들었고

이러한것들을 팀원들에게 전파하려고 노력했습니다.

 

---

4. 공통모듈을 제작시에 너무 많은것들을 생각하지말고
     확장가능성을 염두해 두되 가장 우선순위는 모듈의 역할에대해 집중하자

 

이건 정말 많이 고민하고 내린결론입니다.

"세상에 완벽한 코드는없고 발생할 변수는 너무많습니다."

언제어디서 일어날지 모르는 상황마저 고려하기에는 너무나 큰 리소스를 가져가고

그렇게 고려해서 만든 모듈들을 실제로 사용할때 복잡하고 가독성이 떨어진다는 느낌을 많이 받았습니다.

또한 추후에 만든 모듈에서 버그가 발생했을시에 너무 복잡하게 만들어놨기에 유지보수도 힘들다는것을느꼈기에

 

제가 내린 규칙은 아래와 같습니다.

 

1. 확장성을 고려하되 제작시 분기처리가 너무 많다고 판단되고 이것으로인해 성능이 저하가 된다면 깔끔히 포기

2. 1번의 연장선으로 최대한 깔끔히 제작하고 필요시에 추가로 또다른 모듈을 제작하고 필요시에 그때 병합하자

3. 병합시에 전체를 다 병합할필요는없고 수정이 자주일어나는 부분부터 스텝바이스텝으로 병합하자 

 

 

---

 

5. 아무리 바뻐도 기본적인 성능은 챙기자

항상 만들기 바뻤던 상황임에도 불구하고 최대한 성능을 끌어내고자 노력을 많이하였습니다.

그러한 이유로 개인적으로 회사를 위해 프레임워크와 라이브러리를 만들어서 코드에 병합시켜 배포를 진행하였습니다.

 

이건 개인적 욕심으로 제작하게되었고 그누구도 시키지는 않았지만 개인적으로 약 2년가까이 카메라를 유지보수 제작하면서

불편한점도 많았고 최소한 이 기능에대해서는 할수있을만큼 공부를 해보자는 욕망이 생겼습니다.

그리하여 제작한 라이브러리 오픈 프로젝트를 약 1개월정도 주말마다 공부하여 제작하였고 산출물은 아래와 같습니다.

 

https://github.com/1domybest/CameraManagerLibrary

GitHub - 1domybest/CameraManagerLibrary

 

그리고 깃허브를 통해 처음으로 Documents를 배포해 보았습니다.

https://1domybest.github.io/CameraManagerLibrary/documentation/cameramanagerframework/

Documentation

 

 

---

5. 수학에 대한 기술적 부재

Hypy 프로젝트를 진행하면서 

여러가지 제약들이 있었습니다.

첫번째는 기존 Baund에서 사용하는 DeepAR 프레임워크에서 뷰티필터에대한 기능을 제공하지만

비용적인 문제로 인해 사용이 불가하여 어쩔수없이 관련 뷰티필터 오픈소스를 찾던도중
gpupixel 를 찾게되었고 프로젝트에 적용하였습니다.

 

여기까지는 크게 문제는 없었지만 라이브스트리밍을 제작하게되면서

서로다른 오픈소스에서 필요로하는 타입과 구조가 다르기때문에 통합하는데 힘이 들었습니다.

기본적으로 2개의 프로젝트 둘다 카메라 에서 나오는 샘플버퍼를 화면에 띄어주고있었고

그렇게하다보니 메인쓰레드에 문제가 발생하였습니다.

 

그래서 첫번째는 두개의 프레임워크에서 1개의 렌더링을 off시켜야하는데
gpupixel 같은경우 cpp로 제작되었기에 바꾸는게 쉽지가않았습니다

 

결국은  HaishinKit 의 카메라 view를 사용하기로 결정하였고

여기에서 또다른 문제가 발생하였습니다.
두개의 프레임워크에서 지원하는 타입과 프레임의 포맷이 다르기때문에

강제로 바꿔서 렌더링및 RTMP통신을 진행해야하는데

여기에서 성능에대한 이슈가 발생하였습니다 30FPS 로 지정하였지만 여러 연산과 메인쓰레드를 사용하기때문에

특정순간에 FPS가 떨어지는 이슈가 발생하였고 이러한 이유때문에 초반에는 이대로 사용하다
위에 말씀드린 라이브러리를 제작하여 오픈소스2개를 통합하는 작업을 하였습니다.

이것을 토대로 카메라 라이브러리를 제작하면서 실력에 많은 도움이 되었고 자신감이 생겼습니다.

그리고 한번 뷰티필터 라이브러리를 제작해보고 싶다는 열망이 생겼고

기존에도 Metal 을 사용하여 익숙했지만 뷰티필터를 만들려면 그래픽관련 알고리즘이 많이 필요하고 

이러한 알고리즘을 이해하려면 수학적지식이 필요하다는것을 많이 느꼈습니다.

서론이 많이 길었지만 그렇기때문에 요즘 중학교 수학부터 다시 공부하고있습니다.

 

 

 

5. 산출물

영상의 길이문제로 전체를 몇가지에대해서만 산출물을 올려봤습니다.
자세한 건

앱을 다운로드받아 직접 확인이가능합니다.

 

 

gpupixel 을 사용한 뷰티필터

라이브스트리밍 및 플레이어와 실시간 채팅기능

 

 

 

지금까지 읽어주셔서 감사합니다.