Rommance - Daniel’s

가끔 죽고 싶을 때가 있는데

힘들 때, 아플 때가 그렇습니다.

예를 들어 불치의 암에 걸려 죽게 되었다 싶을 때

바로 죽는 게 아니고,
천천히 아파지면서 죽을 겁니다.

그런데 그냥 그렇게 아프면서 죽는 건 아니고
아픔과 함께 수치스럽게 될 겁니다.
죽어가는 것은 그렇게 아름답진 않으니까요 일반적으로..

냄새도 악취가 날 거고
제대로 몸을 못 가누니까 아마 주변 사람 여럿 힘들게 하겠죠

그런 걸 다 합한 것이 “고통”이라고 불릴 겁니다

전 하나님을 믿으니까 이 고통을 지나 죽게 되면 더 좋은 곳으로 가겠다 싶습니다.

그러나,

역시 내 수한은 내가 정할 수 없고 그 분이 하시는 거겠죠

은혜를 구합니다
평안하고 아름답게 죽을 수 있게

예전에 MP3플레이어 만드는 일을 했었는데,

Shuffle 기능을 어떻게 구현할까 하다가 임의의 수를 하나 뽑으면 그것과 함께 전체 곡 숫자의 조합을 통해 따로 리스트를 만들지 않아도 유일하고 겹치지 않는 순서가 나올거란 맹랑한 생각을 했었습니다. 리스트를 유지하면 메모리가 많이든다, 게다가 겹치지 않게 하려면 이전에 뭐뭐가 있는지를 검색해야 하니까 시간이 엄청 걸리꺼다 라고 생각하고 말이죠. 증명 능력도 없으면서.. 고민하다가 그냥 랜덤+한곡만 저장이었던가 하는 방식으로.. 너무 오래되서 기억나진 않지만요.

나중에 MP3 플레이어 회사에서 일하던 다른친구에게 들었더니 어차피 사용자는 앞뒤 몇곡 순서만 맞으면 아무 상관 없어하므로 일부만 리스트로 가지고 있고 나머지를 랜덤으로 한다고 하더군요.

지금 쓰고 있는 MP3플레이어는 중국산 싸구려입니다. Shuffle 기능이 진짜 쌩 랜덤이라 앞뒤 순서 전혀 안맞습니다. Shuffle 상태서 다음곡으로 넘어가도 아까 그곡으로 돌아오는 경우도 다반사입니다. (프로그램을 발로 짰나.. 하는 생각이)

제가 갖고 있는 LG 샤인폰의 음악 기능은 실제 리스트를 유지합니다. 메모리를 다 쓰는거죠. 근데 곡 번호만 가지고 섞는다면야 뭐 몇십키로바이트 이내에서 해결될 것 같습니다. 메모리 많은 폰은 다 오케이.

이전에 제가 블로그에 게시했듯이 Shuffle 알고리즘이 존재합니다. 피셔 알고리즘이란 것과 일련번호 적힌 카드를 랜덤번호 붙여서 정렬하는 방식이 있죠. 속도도 O(N), O(NLogN) 으로 빠릅니다.

그 일을 그만둔지 꽤 됐지만 그당시 생각하면 발로 짰다 싶을 것 같습니다.

MP3 섞는 것 말고도 성능 높인다고 어셈으로 어플리케이션에서 뮤텍스 만들어 쓰던 일(바이트 단위로!), 최대한 빠르게 접근한다고 통신 파트를 busy-waiting으로 짜고 unblocked 소켓을 쓰며(모바일 기기인데!) 파일은 버퍼링 안하던 일(플래시인데.. 버퍼링 해야 좋은데), 블루투스 칩셋에 프로그램 짤 때는 시리얼 인터럽트 루틴을 최대한 간결히 한다고 삽뜨던 일.. Switch-Case 문이 안빠를 까봐 함수 포인터 배열만들어 점프하던 일 등등. 실제로는 타겟 프로세서에 따라 달라질 수 있는 코드를 얕은 지식으로 최적화했던 것 같습니다. (함수 포인터는 성공적이었지만 나머지는 영..)

작년만해도 수업에서 C 최적화 숙제로 나온 문제에서 캐시에 다 들어가도록 배열 만들고 배열과 인덱스로 접근했는데 실제 타겟 프로세서에서는 오히려 성능이 if문에 밀렸던 게 기억납니다.

이렇게 개발 초년때는 엉뚱한 실수를 많이 합니다.

요즘 학교에 있다보니 저보다 어린 친구들이 많아서 저의 예전과 비슷하게 실수하고 잘못된 최적화를 하는 경우를 봅니다. 기초적인 버그를 만들 때도 있죠. 물론 저도 만듭니다만

그런 때에 ‘개구리 올챙이적 생각 못한다’고, 괜히 그 친구를 나무랄까봐 조심해야지 합니다.

그 친구가 오히려 몇년 뒤에 경험을 쌓으면 저보다 더 잘하는 슈퍼코더가 될지도 모르는데 말이죠.

그리고 지금 저보고 어떤 일을 하라고 하면, 도메인 지식을 먼저 쌓고 누군가 경험 많이 한 사람에게 물어봐야겠습니다. 엉뚱한 접근 안하고 노하우에 따라 짜는 게 수월하지요.