단편적이고 개인적인 경험에 기반해서 SW와 FW 개발의 차이점을 간단히 공유해봅니다. SW나 FW나 답답할 땐 답답하고 재미있을 땐 재미있어요. 📍 너에게 DRAM이란? - SW에서는 DRAM이 빠른 메모리에요. 서버/스토리지에 있는 데이터를 가져오면 OS에 의존해 DRAM에 두고 사용하지요. - FW에서는 DRAM은 매우 느린 메모리에요. 메모리 사용도 자율적이므로, 데이터를 용도에 따라 SRAM/DRAM 중에 선택해서 위치시킵니다. 자주 사용하는 데이터는 되도록(반드시) SRAM에 둡니다. 📍 메모리, 얼마나 줄 수 있는데요? - SW에서 메모리 사용량이라는 것은 데이터의 개수이지 한 데이터의 크기는 아니었어요. 메모리를 너무 많이 사용한다면, 한 데이터의 크기를 줄이기보다는 캐싱하는 데이터의 개수를 줄이는 작업을 수행하곤 했습니다. - FW는 조금 다릅니다. 메모리가 굉장히 제한적이고, 관리하는 데이터가 많지 않기 때문에, 데이터의 개수 보다는 한 데이터의 크기를 줄이는 작업을 수행하곤 했어요. 클래스/구조체를 정의할 때는 메모리가 낭비되지 않도록 변수를 배치합니다. 📖 C/C++에서는 변수 배치에 따라 구조체의 크기가 달라질 수 있습니다. 📍 성능 개선, 가능하죠? SW와 FW는 성능 최적화의 방향이 조금 다릅니다. 성능이 떨어지는 원인이 달랐기 때문인데요. - SW는 처리할 데이터가 많아서 성능이 떨어지곤 했습니다. 이 때는 보통 시간 복잡도를 줄이기 위한 알고리즘이나 자료구조를 사용해서 해결하는데요. 가령, 어떤 아이템을 찾을 때 리스트를 선형 탐색하지 않고 이진 탐색을 하도록 개선합니다. - FW는 반복해서 동작하는 함수/연산이 비효율적이어서 성능이 떨어집니다. 한 순간에 가지는 데이터의 개수는 소수이고, 서로 다른 데이터에 대해 같은 동작을 반복해서 처리하는데요. 아이템이 충분히 많아야 이득을 보는 대부분의 알고리즘보다는, 한 데이터에 대한 연산을 줄여서 최적화 합니다. 데이터가 4개 뿐이라면 이진 탐색에 소요되는 연산량이 선형 탐색에 비해서 오히려 더 많아질테지만, 해상도가 1920x1080인 디스플레이에 한 pixel을 표시할 때의 연산이 5개 줄어든다면, 전체에 대해 천만번의 연산을 줄일 수 있습니다. 1GHz CPU로 0.1초의 시간이 단축되죠. (주사율이 60Hz인 경우, 한 번 그려지는데 0.017초 이내로 소요되어야 한다는 것을 생각해보면 적지 않은 시간입니다.) 📍 버그/문제가 발생했는데 시나리오를 모르겠어요, 그래도 고칠 수 있죠? SW와 FW 모두 충분한 분석과 후보 시나리오를 파악하는 것을 선행합니다. 다만 이렇게 했음에도 후보가 좁혀지지 않을 때가 있는데요. - SW에서는 로그를 추가해서 시나리오를 파악하곤 합니다. 로깅에 메모리나 성능 제약을 크게 받지 않기 때문인데요. 물론, 항상 로그를 확보할 수 있는 것은 아니지만, 많은 경우에 큰 도움을 받을 수 있었습니다. 로그를 확보할 수 없을 때는, 다양한 부분에 방어코드를 추가합니다. 후에 로그가 수집되거나 원인이 파악되면 패치를 합니다. - FW에서는 메모리와 성능 제약을 크게 받기 때문에 로그를 심어서 시나리오를 파악하기 쉽지 않았어요. 심지어 타이밍 이슈였다면, 로그를 심는 순간 재현조차 되지 않기도 합니다. 그 상황이 올 수 있는 많은 경우에 대해, assert를 추가하여 근본 원인에 조금씩 다가가며 접근하기도 했습니다. FW는 방어코드로 해결하지 않았어요, 제품이 팔리고 나면 고치기가 어렵기 때문에 엄밀하게 분석하고 고쳐야 했습니다. 전반적으로 FW가 더 열악한 환경에서 더 깊은 고민을 했었다는 기억인데요, 그게 또 어려운 퀴즈 문제를 푸는 것 같은 재미가 있기도 해서 저는 즐겁게 일했습니다. 또 SW는 런타임 환경에 영향을 많이 받기 때문에 OS 업데이트 등의 외부 요인에 의해서 문제가 발생하면 쉽게 해결되지 않기도 해서, SW나 FW나 답답할 땐 답답하고 재미있을 땐 재미있는 것 같아요.