[회고] 소보로(SOBORO), 프로젝트 회고록

들어가기 전에....

안녕하세요, 개발자 1-hee 입니다.

오늘은 처음으로 플레이스토어에 앱을 출시했던 첫 번째 안드로이드 앱 프로젝트 회고록을 작성해보려고 합니다.

아마추어 안드로이드 개발자가 앱 출시 하겠다며 도전했던 7주간의 이야기 지금 바로 시작해볼게요.

 

주제 선정

이번 프로젝트는 인공지능 기술을 사용한 서비스 개발에 도전해보았어요.

저희 팀은 구체적인 주제를 무엇으로 할까 고민하다가 STT와 TTS 기술을 사용해 청각 장애인분들을 위한 서비스 개발해보기로 결정했습니다.

 

이때, 서비스에 대한 홍보성으로 아래와 같이 소개 글도 작성해 보았습니다.

 

Visualize Your Voice, 당신의 목소리를 보여드립니다.
🎵 소보로(SOBORO)는 모든 소리가 하나되는 세상을 지향합니다.

🌎 소보로(SOBORO)는 모두가 나의 목소리로 소통하는 세상을 그리고 싶습니다.

길을 건널 때 신호의 종료를 알리는 소리, 맛있는 냄새가 풍기는 상가를 지날 때 흘려 퍼지는 흥겨운 음악 소리, 계절에 따라 바뀌는 음원 차트의 신나는 음악들... 이 모든 것이 누군가에겐 들을 수 없다는 사실을 알고 계시나요?

소보로(SOBORO)는 AI 음성 인식 기술과 함께 누구나 보편적인 삶을 살 수 있는 사용자 경험을 소개하고 싶습니다.

당신의 소리가 우리의 소리가 되는 곳, 🎵 소보로(SOBORO) 가 함께하겠습니다.

 

---

프로젝트 대표 기능

이번에 만든 프로젝트는 다음의 세 가지 대표적인 기능을 제공했습니다.

 

1. 사용자 맞춤 발음 교정 기능
2. 텍스트 음성 번역 기능
3. 설치 없이 사용 가능한 실시간 상담 서비스

 

위의 세 가지 기능을 통해서 저희 팀은 청각장애인 분들이 공간과 시간의 제약 없이 일상적인 생활을 영위할 수 있도록 도움을 드리고 싶었어요.

물론, 맹목적인 도움의 손길은 오히려 상대방의 입장을 고려하지 않은 행동이 될 수 있다고 생각해서

청각장애인의 삶을 잘 그려내신 웹툰 작가님의 작품도 보면서 작은 부분부터 섬세하게 신경쓰기 위해 다같이 노력했습니다.

 

📌 네이버 웹툰 - 나는 귀머거리다

https://comic.naver.com/webtoon/list?titleId=659934 

나는 귀머거리다

 

물론, 웹툰이 생각보다 재밌어서 정주행했던 것은 안비밀이지만 ㅎㅎ

그래도 진솔하게 청각장애인의 삶을 그려주신 작가님 덕분에 프로젝트를 하면서

구체적인 기능 설계와 테스트를 하는데 많은 도움을 받을 수 있어서 감사한 마음이 들었습니다.

 

---

 

팀 프로젝트의 시작, 그라운드 룰의 설정

저희 팀은 프로젝트 시작 전에 다음과 같이 그라운드 룰을 설정했어요.

아래 규칙의 내용은 어쩌면 상식적이고 당연한 내용일수도 있지만,

그래도 프로젝트를 진행함에 있어서 서로 존중하고 적극적으로 소통하겠다는 우리 팀의 의지를 담은 규칙이었답니다.

 

1. 카톡은 읽씹하지 않기
2. 아침에 기상하면 이모티콘 날려주기
3. 지각하면 커피쏘기
4. 월요일 커피내기 
5. 컨디션 잘 관리하기
6. 이슈 발생 시 꼭 공유해주기 
7. 취업하면 소고기사기!
8. 말할때 쿠션어 사용~
9. 대안없이 반대하지 않기
10. 말할 때 마감기한 알려주기
11. 본인이 맡은 일은 오래 붙잡지 않기 (마감 최대기한 : 2일)

---

프로젝트를 하면서 어려웠던 점은?

프로젝트를 하면서 특별히 팀원 간의 갈등은 없었어서 즐겁게 프로젝트 할 수 있었습니다.

그러나, 안드로이드 앱 개발을 처음 제대로 도전해보게 되어서

앱 내 기능을 구현하는 과정에 종종 어려움을 겪기도 했는데요.

 

그때의 에피소드를 몇 가지 소개 드려보도록 할게요. 😊

 

ep1. 채팅 기능이 이상해...

카카오톡 처럼 채팅을 할 수 있도록 말풍선을 동적으로 만드는 기능을 만들게  되었습니다.

채팅 기능을 구현하는 과정에서 채팅을 치는데 말풍선이 두 번 만들어지는 오류가 있었어요.

카톡처럼 키패드 엔터 버튼을 누르면 한 번만 이벤트가 잡혀서 말풍선이 하나가 생성되어야 하는데,

제가 처음 만든 기능은 말풍선이 두 개씩 만들어지는 이슈가 발생해버렸죠! 😲

 

아래는 이때 작성했던 소스 코드 중 일부입니다!

 

// 채팅 입력 텍스트
val voiceTransChatText = findViewById<EditText>(R.id.voiceTransChatText);
voiceTransChatText.setOnKeyListener { view, keyCode, keyEvent ->
    if(keyEvent.action == KeyEvent.ACTION_DOWN
        && keyCode ==  KeyEvent.KEYCODE_ENTER){
        Log.d("EDIT::::::","${voiceTransChatText.text}")
        creatChatItem(voiceTransChatText, voiceChatHolder);
    }
    true
}

 

📝 메모 내용

• 키다운할 때 람다식으로 true를 리턴을 해야한다.
• 근데 false를 한 것이 문제였음.

 

이처럼 앱 개발하면서 크고 작은 이슈가 참 많았었는데,

매번 모든 문제 상황을 기록하고 정리해두진 못했지만 그래도 인상 깊었던 이슈들은 꼭 정리해둬서

나중에 블로그에 글로 정리하거나 별도로 저장해두어야지 했는데, 그게 벌써 지금까지 미뤄지고 말았네요..😂

 

---

 

ep2. 스플래쉬 화면이 안 켜져...

앱을 처음 구동시킬 때, 저희 서비스를 소개할 수 있는 컨셉 이미지를 노출시키려고 스플래쉬 화면 기능을 추가 했어요.

이때 사용하려고 직접 일러스트레이터로 이미지도 그려서 에셋으로 사용했었는데요.

 

구글에 스플래쉬 화면을 띄우는 법을 검색해서 그대로 적용했었는데,

앱 구동시 스플래쉬 화면이 노출되었다가 비정상 종료(=ANR)가 발생하는 문제가 생겼습니다.

 

과거 안드로이드 OS 버전에서는 스플래쉬 화면을 액티비티 컴포넌트로 직접 구현해서

일정 시간 노출 시킨 뒤 메인 엑티비티로 이동하는 식으로 많이 구현했었는데,

이번 프로젝트에서는 안드로이드에서 새롭게 API로 제공한 splash API를 사용하게 된 것이 원인이었습니다.

 

안드로이드에서 API로 제공하는 스플래쉬 화면은 최소 API 수준이 높았습니다.

그러나 저희 프로젝트는 API 수준을 26으로 선택했고, 이로부터 문제가 발생했다는 것을 알 수 있었어요.

 

어떻게 지금의 문제 상황을 해결해야하나 고민하다가,

안드로이드 스튜디오에서는 신규 앱들에 대해서 API 31 이상의 환경에서 개발할 것을 권장한다는 문구를 보았고

그러면 안드로이드 스튜디오에서 권장하는 데로 31 수준으로 올리면 되지 않을까 해서

최소 API 수준을 올리는 방법을 선택하게 되었습니다.

 

시간이 지난 지금 생각해보면, 이때도 제가 안드로이드 개발을 잘 몰랐으니

이런 쉬운(?) 선택을 했구나 하는 생각이 들었습니다.

 

진짜 실력있는 앱 개발자라면, 한번 목표로 설정한 API 수준은 변경하지 않는 것이 좋았을 텐데 말이죠...

아마 구글에서도 꼭 바꾸라는 의미는 아니었을 텐데 이때의 제 선택은 조금 아쉽네요..!😅

 

그래도 이때를 교훈 삼아서 이후 개발한 앱 프로젝트에서는

첫 기획에서의 변경이나 중대한 사안이 아닌 경우 가급적 API 수준을 건들지 않고

어노테이션(@xxx)을 통해서 컴파일러가 API 수준에 따라 함수를 구분할 수 있도록 대응했습니다.

---

프로젝트를 하면서 느낀점

이번 프로젝트를 하면서 가장 크게 느낀 것은 안드로이드 앱 개발에 도전하고 출시할 때,

저를 믿어 주고 응원해준 팀원들을 만난 것이 참 행운이다 라는 생각이 들었습니다.

 

앱 개발에 성공했던 경력이 있던 것도 아닌데,

오직 저의 '의지'와 평소의 모습을 보고 저의 가능성을 믿어준 팀원들이 없었다면

과연, 앱 개발에 대해서 지금처럼 자신감 넘치에 도전할 수 있었을까? 하는 생각이 들었습니다.

 

서툴고 실수 투성이었던 초보 앱 개발자인 저를 항상 존중해주는 팀원이 있었기에

아래와 같이 첫 출시 심사에서 실패했음에도 다시 보완하여 도전하는 용기를 얻을 수 있었던 거 같아요.

 

 

어쩌면 제 욕심으로 프로젝트를 할 때, 팀원들을 고생시킬 수도 있었지만

이러한 상황이 오히려 저를 향한 믿음과 존중이 무의미한 것이 되지 않도록 더 열심히 할 동기 부여가 되었던거 같습니다.

 

그래서 더 고마운 마음이 큰 것 같고,

다른 팀에서도 우리 팀원들처럼 팀원을 진심으로 존중하고 응원하는 성숙한 개발자가 되고 싶네요.

 

이상으로 회고록은 마치도록 하겠습니다.
긴글 읽어주셔서 감사합니다 😀