- 안영기의 개발실 - (WIZ / bada)

프로그래밍이란 것을 계속 하다 보면, 어느 순간 여러 가지 방법론이 머리 속에 고정관념처럼 박혀 있는 것이 많다.

그런데 여전히 갈피를 못 잡고 있는 것은 code의 notation을 정하는 것이다. 가장 처음에는 변수를 2자 밖에 못쓰던 언어를 사용였는데 모두 대문자 약자로 변수를 구성하였다. 그러다가 C를 하면서는 under_score notation을 썼고 다음에 Pascal을 하면서부터는 자연스레 PascalCase를 사용하게 되었다. 그러면서 한동안은 함수명은 PascalCase, 변수명은 camelCase로 고정되고 있다가 약 2년 전부터는 다시 변수에 under_score를 쓰기 시작했다.

가독성이라는 기준이 해가 가면서 변하는지라, 지금은 camelCase보다는 under_score가 눈에 더 잘 들어오고 있기 때문이다. Notation은 해가 갈 때마다 변하지만 그래도 변하지 않는 것은 그것을 적용하는 목표이다. 그 목표란 최대한 코드를 빨리 읽으면서 실수를 줄이자는데 있다. 파라미터 변수와 멤버 변수를 가려 내고, 클래스와 네임스페이스를 가려 내고 함수와 매크로는 표기법만으로 구분하면서 최대 효율로 작업을 할 수 있게 하기 위함이다. (code를 만들 때의 타이핑은 많아져도 상관없다고 생각한다)

덕분에 그 동안 만든 라이브러리 코드들을 보면 대충 만들어진 시대를 짐작할 수 있게 되었다.

Posted by 슴갈

플랫폼 개발을 하다 보면 사람들 간의 개념 간의 충돌이 많다. 그런 것들은 답이 정해져 있는 것도 아니라 개인이 추구하는 성향에 따라 의견들이 갈리는 것이 대부분이다. 그 중에 하나가, 이 플랫폼으로 개발할 개발자들에게 ‘모든 가능성을 간직한 기본만을 제공할 것인가’ 아니면 ‘최대한 많은 기능을 넣어서 편의성을 도모할 것인가’에 대한 의견 충돌이 제일 처음 생기게 된다.

결론부터 말하자면 나는 전자이다. 플랫폼은 기본만 제공하는 간단한 것이었으면 한다.

이 의견에 반대 사람들이 내는 주장은 대부분 ‘플랫폼 사용을 쉽게 하여 많은 개발자가 사용할 수 있게 하자’라는 것인데 나는 이 부분 때문에 반대를 하는 것이다. 나는 ‘플랫폼을 기반으로 한 애플리케이션 사용에는, 어느 정도 문턱이 있어서 일정 레벨 이상의 개발자들만 뛰어 들어야 전체 결과물의 수준이 높아진다’고 생각을 하고 있다.

회사 내에서도 논란이 되는 부분이 SDK에 OpenGL ES만 지원하면 되는지 아니면 자체 렌더링 엔진을 넣어야 하는지의 선택이 있는데, 이 역시도 위의 선택에 따라 OpenGL ES만 지원하면 된다고 주장하고 있다. Apple 앱스토어의 통계 같은 것은 잘 모르겠지만 내가 예상하는 것은, 잘 만든 소수의 애플리케이션이 대다수의 돈을 벌어 들인다는 생각이다.

개발의 문턱이 낮을 때, 100개의 애플리케이션이 상급 10개 중급 30개 하급 60개로 구성되어 있다면, - (1)

개발의 문턱이 높을 때는 40개의 애플리케이션이 상급 10개 중급 30개만 있게 된다. – (2)

(상급의 애플리케이션이 판매 개수가 훨씬 많고 하급은 판매 개수는 적다는 논리를 적용 한다)

이렇게 되면 겉보기의 전체적인 수익은 (1)이 높아 보일지는 모르겠지만, 유저의 입장에서는 (2)의 경우가 더 신뢰성 있는 애플리케이션을 구할 확률이 높으므로 유저의 수가 더 많이 몰리게 되어 실제 매출이 더 높아진다는 논리이다.

게임 플랫폼이라면, ‘기본 OS의 추상화 + 디바이스 추상화’에다가 2D 그래픽은 frame buffer 접근법만 열어 주면 되고, 3D 그래픽은 OpenGL 같은 것만 열어 주면 된다는 것이다. 하지만 대부분의 사람들은 플랫폼을 종합 선물 세트로 만들려고 하기에 시간과 돈이 많이 투자된다. (라는 생각을 가지고 있다. 하지만 역시 정답은 없다)

Posted by 슴갈

이번 2010년이 들어서 S/W 업계에서 가장 큰 화두는 LG폰 SMS의 2010년 표시 버그일 것으로 생각한다.

SMS의 스펙을 확인 해 보니, 연도는 1byte에 "Swapped Nibble”을 적용한다고 되어 있으며 Swapped Nibble의 정의는 BCD code where nibbles within octet is swapped. E.g.: 0x31 Represents value of 13 라고 되어 있다. 여기서 문제가 되는 것은 BCD인데, Swapped Nibble 이라는 말을 단어 자체로만 들으면 4비트가 서로 바뀌어 있다라는 의미만 내포된 것으로 보이기 때문에 그것이 BCD로 표현될 것이란 예상을 하기가 어렵다. (물론 스펙을 제대로 안 본 사람이 무조건 잘 못이지만…)

그래서 원래는 (year >> 4) + (year & 0x0F) * 10 이어야 하는 공식을 (year >> 4) + (year & 0x0F) * 0x10 로 쓴 것으로 예상한다.

여기에서 특별히 기술적인 내용을 이야기 하려는 것은 아니고, 이런 사소한 실수 하나 때문에 회사의 이미지가 떨어지고 관련된 담당자와 그의 상사들과 QA팀은 큰 화를 입을 것이란 것이라는 것이다. 실수의 경중으로 보면 굉장히 가벼운 실수이긴 하나 파급 효과는 굉장히 크다. 버그 있는 코드는 누구나 만들고 있지만 운도 많이 작용하고 있다는 일례일 것이다.

LG의 개발 상황을 예상해보면, 문제의 코드를 만든 본인은 이미 퇴사 또는 다른 부서로 발령이 났고, 몇 명의 담당자를 거쳐 지금은 사원급 개발자가 인수 받았으며 그 한 명이 국내판 백 종 이상의 양산 코드를 담당하고 있었을...

Posted by 슴갈

최근의 Embedded 용 기기들의 상황을 보면, 기기는 다양해지지만 개발 환경은 유사해지고 있다. 특정한 범용 컴파일러 또는 특정한 범용 라이브러리를 채용하는 기기가 많아졌기 때문이다. 시대의 유행이 독자적인 SDK 보다는 범용적으로 사용하는 표준 부품을 도입하는 업체가 많아져서 이다.

개발의 유행을 선도하는 S/W의 대기업들의 마인드가 바뀌면서, 개발자 개개인도 좀 더 편하게 된 것인데 그래서 새롭게 내세워야 하는 전략은 ‘하나의 컨텐츠를 많은 기기에 이식하기’라 생각한다. 예전 같으면 대규모 작업 중에 하나였던 기기간 포팅이, 위의 유행에 힘입어 보다 쉽게 이루어질 수 있기 때문이다. 이전 같으면 Code Warrior 같은 특정 업체의 솔루션을 이용해야 했던 것인데 지금은 어느 정도 개인의 힘으로도 가능한 시대가 되었다.

위의 ‘전략’을 위해서는 개발자나 개발사는 ‘플랫폼’을 구비해야 한다. 예전의 S/W 플랫폼처럼 거대한 어떤 것이 아닌 표준 부품들을 변화에 유기적으로 대응할 수 있는 수준의 가벼운 플랫폼만 있어도 된다. 사실 이제는 플랫폼이 아니라 추상 계층Abstract Layer이라고 불러도 좋을 정도의 작은 것만 필요하다. (그래픽 출력, 사운드 출력, 표준 입력, 지역화 옵션)

외국의 게임 업체들이 이런 쪽에 많은 경험을 가지고 있고 미리 대비하고 있다는 것이 당연하면서도 신선했다. 아예 이런 추상 계층만 관리를 해주는 업체도 있는데, 이런 업체들은 유명 게임들을 불과 1~2주 만에 낯 선 기기에 포팅을 해 내었다. 단 한 가지 문제가 있는 것은 해상도이다. 하지만 이 해상도라는 것도 추세와 유행이 있다. 이렇게나 많은 해상도가 있지만 최근 나오는 embedded 기기의 해상도로 사용되는 것은 한정적이다. (결국 LCD 제조사에 대한 dependency 때문에)

Posted by 슴갈

나는 지금의 회사에 들어와서 10년 째 SW 플랫폼을 하고 있다. 기술적인 부분은 배제하고도 이 ‘SW 플랫폼’이란 것에 대해서는 할 말이 많다.

한 때 SW 플랫폼이 대단한 붐이었고 유수의 SW 기업들이 SW 플랫폼을 만드는 것에 많은 비용을 투자하고 있었다. 그리고 시대는 ‘open’의 시대가 되어서 너나 없이 자사의 SW 플랫폼을 무료로 공개하고 있다. 이런 식의 붐을 타고 꽤나 승승장구하고 있는 SW 플랫폼이었지만 내부적으로는 이에 의문을 가지는 관련자들도 많았다. 하지만 SW 플랫폼은 우리의 밥벌이었기에 쉽게 공식적으로 내 뱉을 주제는 아니었다.

제품의 완성도를 100으로 본다면 플랫폼의 존재로 인해 90까지는 아주 쉽게 올라올 수 있다. 하지만 그 이후로는 플랫폼의 존재 때문에 더 이상 끌어 올리지 못하고 기껏해야 95정도로 마무리를 짓게 된다. 반면에 플랫폼이 없다면 힘들게 90까지 끌어 올린 후 다시 더 힘들게 100까지 끌어 올릴 수 있다. 개발자들의 노력은 후자가 더 많이 들어 가서 비효율적이지만 최종적으로 평가되는 ‘제품의 완성도’로는 후자가 더 높은 점수를 받는다. 고객은 개발자의 피 끓는 투혼과 노력에는 관심이 없다. 단지 최종 결과만을 가지고 평가를 하게 되는 것이다. ‘열심히 만든 제품’보다는 ‘잘 만든 제품’이 1위를 차지해야 하는 것이 당연하다.

잘 만든 플랫폼이 있으면 2위는 할 수 있을 것이다. 하지만 1위가 되려면 어떻게 해야 할까?

플랫폼의 완성도와 개발자의 노력을 수요 공급 곡선처럼 그린 후, 원하는 제품의 완성도가 나올 수 있도록 그래프를 조정하면 아마 답이 나오지 않을까 생각된다.

(핵심은 말하지 않아서 회사 사람들이 봐도 이의를 제기할 수 없는 적절한 글이 되었다. ^^)

Posted by 슴갈

어떤 순서로 배열해도 잘 굴러가기만 할 헤더의 배열 순서이지만 나는 아래와 같은 방법을 사용하고 있다. 

1. 그 Application의 헤더
2. 사용 Library의 헤더
3. 표준 헤더 

만약 app라는 이름의 application이 avejlib이라는 이름의 Library를 사용하고, 거기에다가 표준 입출력을 사용하고 있을 때 다음과 같이 사용한다는 것이다. 

#include “app_type.h”
#include “app_traits.h”
#include “app_util.h”
#include “avejlib_renderer.h”
#include “avejlib_audio.h”
#include “avejlib_device.h”
#include <stdio.h>
#include <vector>
#include <algorithm> 

이렇게 하면 실제 디펜던시와는 반대로 배열이 되는데, 이렇게 했을 때 library(주로 자체로 만든 것)가 제대로 디펜던시가 설정되었는지를 컴파일 시에 알 수 있기 때문이다.

예를 들어 apputil.h가 <vector>에 디펜던시가 있는데 그것을 내부적으로 해결해 놓지 않으면 위의 경우는 에러가 난다. 그렇게 하는 이유는 ‘어떠한 헤더도 그 헤더를 사용하기 위한 전제 조건을 알 필요가 없어야 한다’라고 생각하기 때문이다. 내가 “apputil.h”를 A()라는 함수를 쓰기 위해 include 했는데, “apputil.h”의 B()라는 함수 때문에 생긴 <vector>에 대한 디펜던시를 알아야 할 필요가 없기 떄문이다. 

참고로 구글의 coding guideline은 이와 반대이며 그들도 그들 나름대로의 이유 때문에 그렇게 했을 것이다.

Posted by 슴갈

Posted by 슴갈

알고는 있지만 내가 잘 쓰지 않는 표준 타입에 size_t와 ptrdiff_t가 있다. size_t는 표준 함수(memset() 등)들의 파라미터에도 쓰이고 있지만 실제로는 unsigned long 등으로 간주해버리기 일쑤였다. VC++은 그렇지 않지만 gcc의 경우에는 원래 그것이 정의되어 있는 <sys/types.h>를 가져와야지만 컴파일 에러가 안 나기 때문에 같은 소스로도 다른 플랫폼에서 빌드가 되지 않기 때문이다.

그런데 이제 64비트 컴파일러 시대가 왔다. ‘16비트 컴파일러 -> 32비트 컴파일러’ 때만큼의 큰 장점은 없기 때문에 그다지 실감은 나지 않는다. 하지만 언젠가 올 미래에는 32비트 보다 더 큰 비트의 운영체제만 존재할 때가 올 것이고 그것 때문에 size_t와 ptrdiff_t를 다시 고려하게 되었다. 실제로 더 빨리 내가 도입해야 할 것은 ptrdiff_t 쪽이며 그 동안 32비트를 가정하고 포인터를 다루었던 많은 부분들이 다시 리뷰가 되어야 한다.

내 생각엔 이 두 개의 타입은 예전부터 언어의 예약어로서의 ‘표준’이 되어야 하지 않았나 생각된다.

Posted by 슴갈

unsigned char* p = NULL;

이라는 코드는 특정한 헤더를 include하지 않는 이상은 컴파일 에러가 나는 코드이다. 하지만 우리 눈에는 이 코드가 아주 자연스럽게 보인다. 게다가 C에서는 0이 아닌 NULL을 쓰는 습관을 길러야 한다고 이야기 해왔고, 일부 기고 글에서는 무효화된 포인터가 0이라는 것은 스펙에 정의되어 있지 않으므로 항상 컴파일러가 제공하는 헤더에 정의된 NULL이라는 값만 써야 한다는 주장도 있다. 그리고 실제 컴파일러도 NULL로 정의된 주소 값에 대해서는 일반 값과는 조금 다른 동작을 한다고도 알려져 있다. (casting이 관련된 경우)

vc++에 정의된 stdlib.h에 정의된 NULL 값을 보자. (Linux용 gcc라면 /usr/include/lunux/stddef.h에 있다)

#ifndef NULL
#ifdef __cplusplus
#define NULL    0
#else
#define NULL    ((void *)0)
#endif
#endif

(최신 버전의 g++에는 __null이 추가된 것 같긴 하지만 모든 컴파일러가 __null을 지원하는 것은 아니므로 일단은 예외로 하겠다)

Pascal의 경우에는 nil이란 예약어가 있어서 언어적으로 0과는 구분을 할 수 있게 해주었고 서로 섞어 쓸 수 없도록 문법적으로 막아 놓았다. 하지만 C++의 경우에는 #define의 값마저도 0과 동일하다. C++이 정상적인 프로그래밍 언어라면 #include 하나 없이도 코딩이 가능해야 한다. (OS API나 IO등의 디바이스 제어와 관련된 부분은 제외하고) 여기서 우리는 #include를 사용해서 NULL의 정의를 불러 올 것이냐, 아
니면 암묵적인 NULL로 통용되는 0을 사용할 것이냐는 문제에 빠진다.

이 문제에 대한 답은 없지만, 나의 경우에는 0을 사용하는 것으로 결정을 했다. 클래스 헤더 정의에서 포인터형의 멤버 변수가 있고 그것을 생성자 등에서 초기화 해야 할 때, 그것을 위해서 때문에 #include를 쓰고 싶지 않기 때문이다. 또한 순수 가상 함수를 정의하기 위한 때에도 같은 이유로 ‘= 0’만 사용한다.

Posted by 슴갈

지금도 그런지는 모르겠지만 가정 처음 C를 접할 때 나오는 함수는 “Hello world”를 출력하기 위한 printf()이고, C++ 책에는 같은 기능을 보여 주기 위해 std::cout였다. C++를 배우려고 하는 사람들이 이전의 C와 가장 이질감을 가지는 부분이 이곳인데 시작하면서부터 C와 C++은 문자 하나 출력하는데도 이렇게 다른 것이구나 라고 생각하게 된다. 

그런데 나와 나의 주위를 보자면, C++을 사용하는 현업에서도 printf()를 썼으면 썼지 std::cout은 거의 사용하는 사람이 없다. iostream의 사용법이 C++의 operator 재정의의 사용 철학을 알리기 위해서 지금처럼 ‘<<’와 ‘>>’를 사용하게 되었다고 들은 적이 있다. 하지만 printf()의 다양한 format을 표현하기 위해서는 알아야 하는 함수(또는 template, 또는 functor)가 너무도 많다. 진수(radix)를 바꾸기 위한 방법도 그렇고 출력 시 고정폭을 지원하게 하는 방법도 너무 귀찮다. (물론 처음부터 C++로 시작한 사람은 그냥 그려러니 하고 사용할 것이다. 도리어 C의 format함수가 더 어려울지도 모르겠다) 

내가 가장 큰 문제라고 생각하는 것은 printf() 보다 직관적이지 못한 부분이 있기 때문이다.예를 들어 아래의 두 가지는 서로 결과가 다르다. 그냥 보면 둘 다 같은 결과가 나올 것 같은데 그렇지 못하다. std::cout에서 결과가 예상한 것과 다르게 나오는 것은 operator의 overloading 때문이다.

#include <stdio.h>

#include <iostream>

int main()

{

char ch = '0';

// 1. printf() 버전

printf("%c\n", ch+0);

printf("%c\n", ch+1);

printf("%c\n", ch+2);

// 2. std::cout 버전

std::cout << ch+0 << std::endl;

std::cout << ch+1 << std::endl;

std::cout << ch+2 << std::endl;

return 0;

}

결과

0  <-- printf() 버전

1

2

48  <-- std::cout 버전

49

50

Posted by 슴갈