기본 콘텐츠로 건너뛰기

[언론보도] 사운들리, 아산나눔재단의 '마루180' 오픈과 함께 입주


사운들리가 무려 17대1의 경쟁률을 뚫고 마루180(링크)으로 사무실을 이전했습니다 (기사 링크).


<현 주소>
서울시 강남구 역삼로 180, 마루180 2층



댓글

이 블로그의 인기 게시물

[Insight] 안드로이드 백그라운드 서비스 개발시 고려해야 할 사항

[Insight] 안드로이드 백그라운드 서비스 개발시 고려해야 할 사항

지난 시간엔 사운들리 백엔드에 대해 설명을 드렸었죠. 이번 시간엔 사운들리 서비스중 클라이언트에 해당하는 안드로이드 SDK, 그 중에서도 백그라운드 서비스에 초점을 맞추어 설명을 해 볼까 합니다. 안드로이드의 특징 중 하나로 Service를 들 수 있습니다. 이 서비스란 녀석은 백그라운드에서 실행 될 수 있다는 점이 가장 큰 특징인데요. 물론 iOS 에서도 일부 지원은 합니다만 매우 제한적인 경우(음악 재생 등)에만 사용 가능합니다.
제가 생각하는 백그라운드 서비스 개발 시 유의 사항은 아래와 같습니다. 동작 기간 - 상시 동작 해야 하는가, 특정 조건에서 특정 작업을 할때만 동작 해야 하는가글로벌 프로세스 사용 유무 - 서로 다른 어플리케이션에서 접근이 가능 해야 하는가동작 조건 - 특정 시간 혹은 기간마다 동작 해야 하는가, 특정 이벤트 발생시 동작 해야 하는가그 외에도 많은 부분들이 있지만 일단 저 정도만 고려해도 개인적인 생각으로는 충분히 개발 가능하다고 생각 합니다. 그러면 각각에 대해서 좀 더 자세하게 알아 볼까요?
1. 동작 기간동작 기간에 대해서 이야기 하기 전에 먼저 유저 레벨에서 가장 많이 사용하는 Service 와 IntentService 의 차이점에 대하여 짚고 넘어가보겠습니다. Service 를 상속`Context#startService//Context#stopService` 혹은 `Context#bindService(w/BIND_AUTO_CREATE)//Context#unbindService` 를 통해 수명 조절 (Service 내에서 Service#stopSelf 를 호출하는 방법도 있습니다.)Service 시작된 이후에 커뮤니케이션 가능수명 종료 API(stopService or unbindService) 를 호출 하기 전에는 프로세스가 사라지지 않음 (물론 LMK에 의해서 종료 된다던지 등등이 있지만 여기서는 논외로 하겠습니다.)IntentService 를 상속start…

[스타트업] [Insight] 사운들리 코드 품질 관리 이야기

[스타트업] [Insight] 사운들리 코드 품질 관리 이야기
 안녕하세요 "사운들리"입니다 :)

오늘은 사운들리의 코드 품질 관리에 대해 이야기 해보려 합니다. 몇몇 개발자에게는 지루하고 악몽같은 이야기일 수 있겠네요.
제 경우에는 예전에는 이런 품질이라는 단어를 멀리했지만 결국 제가 작성한 코드에 발목을 많이 잡히다 보니, 자연스레 관심을 갖게 되었습니다.

일단, 어떤 소프트웨어가 좋은 품질의 소프트웨어일까요?
좋은 품질이란?  책에 나올법한 내용을 보면, 아래와 같은 항목을 토대로 소프트웨어 품질을 판단한다고 합니다.
ISO/IEC 9126 : Software engineering - Product quality Functionality: 명시된 요구사항을 잘 충족했는지Reliability: 명시된 조건과 시간 아래에서 일정 성능을 유지 하는지Usability: 사용하기 위해 어느정도의 노력과 자원이 필요한지Efficiency: 소모 자원과 성능간의 효율Maintainability: 수정하기 위해 어느정도의 노력이 필요한지Portability: 다른 환경에서도 사용 할수 있는지출처: https://en.wikipedia.org/wiki/ISO/IEC_9126  뭔가 복잡해 보이지만, 결국 개발자라면 위의 항목은 누구나 추구하게 되는 가치라고 생각 합니다.

그런데 말입니다.이런 좋은 내용을 마음 속으로만 간직한 채 코드를 작성하면 정말 좋은 소프트웨어를 만들 수 있을까요? 저는 객관적인 방법으로 코드를 평가한다면 좋은 피드백이 될 것이라고 생각합니다. (물론 이 성적표를 남에게 보여주는 것과는 다른 문제에요 ㅎㅎ)
어떻게 품질을 체크하는가  소프트웨어의 품질을 체크하는 데에 다양한 방법과 툴이 제시되고 있는데요, 저는 크게 두 가지로 분류 해보겠습니다.
유저 입장의 품질: 유저의 요구사항에 맞는 소프트웨어인지 체크개발자 입장의 품질: 내가 지금 이 코드를 의도한 대로 잘 작성하고 있는지 체크 유저 입장의 품질은 언급하지 않아도 중요함을 누구나 알고 있습니다. 이…

[스타트업] [Insight] 사운들리 방송 송출테스트 이야기

[스타트업] [Insight] 사운들리 방송 송출테스트 이야기
안녕하세요 "사운들리"입니다 :)


 오늘은 사운들리 사운드 비콘을 방송 콘텐츠에 실어 보내어 시청자의 모바일로 유용한 정보를 전달하기 위해 가장 중요하고, 힘들지만 마치고 나면 모든 팀원들이 가장 뿌듯함을 느끼는 방송 송출테스트 이야기를 하려 합니다.


송출 테스트, 사운들리가 그 어려운 걸 또 해냅니다.
<디지털 방송의 송출 경로>
 위 그림은 우리나라 디지털 방송의 송출 경로의 한 예입니다. 실제 방송국이 지상파인지, 종편인지, 기타 케이블 채널인지 등에 따라 세부적인 변화가 더 있을 수 있지만, 위 그림만 보셔도 충분히 복잡해 보이실 것입니다.
 우리나라는 DMB 등 일부 영역을 제외하고 디지털 방송 영역에서 대부분 미국식 표준 ATSC 관련 표준을 따르고 있지만, 유럽 국가와 뉴질랜드 등은 유럽식 표준인 DVB 관련 표준을 따르고 있습니다. 사운들리가 실제 송출테스트를 통해 증명하기 전까지 마주친 수많은 방송 실무자들, 방송 장비 업계 관계자, 학계 연구자들은 다양한 방송 장비에 의해서 사운들리 사운드 비콘이 유실되거나 왜곡되어 서비스가 불가능할 것 이라며 포기하라고 하였습니다.

 하지만 이렇게 복잡하고 다양한 환경에서 사운들리는 대한민국과 터키에서 모두 서비스를 성공(!)함으로써 미국식 디지털 방송의 대표적인 예인 대한민국과 전형적인 유럽식 디지털 방송의 예인 터키 모두에서 서비스 제공이 가능하다는 것을 증명해 냈습니다 :)


방송 송출, 그 험난한 검증의 시간  그렇다면 이렇게 복잡한 방송망을 거치고 나서도 사운들리 사운드 비콘이 시청자의 모바일로 안전하고 완전하게 전달될 수 있다는 것을 테스트하기 위해 어떤 과정을 거치는지 살펴보겠습니다.

 사운들리가 방송 쪽으로 사업 방향을 잡고 나서 가장 힘들고 오랜 시간이 걸린 부분 중 하나가 방송국들에게 기술의 안전성과 안정성, 정확성을 설득하는 것이었습니다.
기술의 안전성: 시청자 또는 반려 동물에게 선진국들의 가장 보수적인 규제 보다…