구르는 동그라미

커리어리에서 HTTP status code 관련 질문글을 보았는데요,
 - https://careerly.co.kr/qnas/912

흥미로워서 조금 찾아보았습니다.

스펙에서는 401을 다음과 같이 정의하고 있습니다.

The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource.

로그인을 "ID/PASSWORD를 이용해 사용자 정보를 가져오는 동작" 이라고 정의하면,

로그인 실패는 사용자 인증에 실패하여 사용자 정보를 가져오는데 실패하는 것이므로 401로 봐도 괜찮을 것 같습니다.

오래전에도 비슷한 질문이 있었네요.

 - https://stackoverflow.com/questions/11714485/restful-login-failure-return-401-or-custom-response

가장 추천을 많이 받은 답변에서는 boolean 형태의 response를 지양하길 바라는데요,

로그인을 "이게 내 계정 정보 맞는지 확인(true/false)하는 동작" 이라고 생각하면,

로그인 실패에 대해 401은 어색할 수도 있겠습니다.

ref: https://www.rfc-editor.org/rfc/rfc9110.html#name-401-unauthorized

오는 11월 15~16 일에 삼성전자 소프트웨어 개발자 컨퍼런스가 개최된다고 합니다.

다양한 분야에 대한 세션들이 준비되어 있네요,

개인적으로는 다음 세션들이 끌립니다.

• SW Toward 6G
• CTF를 통한 해킹 기술 배우기
• UWB 오픈생태계 구축을 위한 표준화
• MPEG-5 EVC 비디오 코덱
• 16일 키노트

사실 놓칠 것 없이 다 흥미로운 세션들 뿐이긴 합니다.

다행히 온라인/오프라인으로 함께 진행된다고 하고,

행사가 끝난 뒤에는 홈페이지를 통해 키노트와 세션 영상을 다시 볼 수 있도록 해준다고 하네요

SSDC: https://www.ssdc.kr/

단편적이고 개인적인 경험에 기반해서 소프트웨어(Software, SW)와 펌웨어(Firmware, 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나 답답할 땐 답답하고 재미있을 땐 재미있는 것 같아요.