구르는 동그라미

지능형 로봇 개발 및 보급 촉진법 개정안이 시행되면서 테헤란로에서 로봇 배달서비스를 시작했다고 합니다.
우아한형제들의 배달 로봇 '딜리'와 뉴빌리티의 배달 로봇 '뉴비'가 배달을 시작했다고 하는데요,

제가 기억하기로는 우아한형제들의 로봇 배달의 골은 실내-외 주행을 모두 커버하는 서비스였고, 뉴빌리티의 로봇 배달은 저렴한 배달료로 실외 주행만을 제공하는 서비스였습니다.
다만, 시행법에 따라 우아한형제들 또한 현재는 실외 주행만을 제공하고 있는 것 같습니다.

사람을 인식하고 멈추는 동작도 좋으나, 구석으로 숨는 기능이 있어야 보행에 방해되지 않을 것 같은데요, 구체적인 동작은 찾아볼 수 없네요.

치솟는 배달비가 부담되고, 배달 건수도 줄어들고 있다는데, 로봇 배달이 해결책이 될지도 궁금합니다.

이전 회사에서 SSD FW를 개발할 때에는 sprint에 작업하기로 한 task가 변경되는 일이 거의 없었습니다.
제품의 완성 기한이 정해져있고, 필요한 기능들이 추가되면 수시로 backlog에 넣지만, 이 sprint에 작업 순서를 바꿔서 완료해야 하는 일은 거의 없었어요.

일정을 크게 나누어서
- SSD의 일반 동작부터 개발/검증 하고
- 특수 상황의 동작을 개발/검증 하므로
큰 일정 내에서는 급하게 순서를 변경할 필요가 없었어요.
간혹 특정 모듈이나 기능에서 예상 보다 버그가 많이 나오거나, 해결에 시간이 오래 소요되면, 하던 작업을 멈추고 투입되기도 했지만요.

현재 회사에서는 서비스를 제공하기 때문에, 주기/비주기적으로 개선 버전을 배포합니다.
이 때, 배포 주기와 개발 sprint 기간이 일치하지 않다보니 기획적으로 기능의 배포 순서가 바뀌면 backlog task의 우선순위가 바뀌거나, 예정에 없던 task가 생기기도 합니다.

작업량이 많아서 두 sprint로 나눠서 작업하려다가, 중간에 우선순위가 바뀌면 참 찝찝하기도 하고,
우선순위가 바뀔정도로 급한 일이 들어왔다는 얘기라서 task 크기에 따라 정신없이 바빠지기도 합니다.

네,  계속 바쁘네요

석사를 마치고 입사했던 첫 회사에서 저는 예상보다 스트레스를 많이 받았습니다.

주변에서 주는 스트레스 외에 업무를 하면서도 스스로 받는 스트레스가 많았어요.

새 프로젝트에 들어가면서, 서로 코드 리뷰를 진행하며 한참 개발에 열을 올리던 시기였습니다.

기존의 코드를 기반으로 개선하는 것이 아니라, 각 모듈별 기능을 정의한 후 새롭게 작성하는 프로젝트였어요

이 프로젝트의 코드가 이후 후속 프로젝트의 기반 코드가 되는 것이었지요.

몇몇 책임/수석급 선배분들께서 제가 코드 리뷰/분석을 할 때 스트레스를 많이 받는 것 같다는 얘기를 해주셨습니다.

이후에 코드 리뷰/분석을 하다가 돌아보니, 확실히 스트레스를 받고 있었어요.

특히, 기존의 안좋았던 코드를 답습하면서 가독성이 굉장히 나쁜 코드를 볼 때 스트레스가 심했습니다.

 - 의미를 명확히 알 수 없는 변수 (e.g. bool request - request를 해야하는 것인지, request를 했다는 것인지)

 - state(enum)를 가지면서 boolean 값에 따라 두 가지 상태를 내포하는 복잡한 상태 천이

 - 등등

모처럼 새롭게 만드는 프로젝트인데, 저는 몇몇 동료분이 대체 왜 그러는지 이해할 수 없었습니다.

당시의 저는, 이렇게 작성된 코드들은 전부 '하기 싫어서 대충 작성한' 결과라고 생각했거든요.

이런저런 조언을 해주시던 선배분들은 그것이 '하기 싫은 결과'가 아니라 그 사람의 '한계'라는 얘기를 해주셨던 기억이 납니다.

단지 실력 부족에 의한 '한계'이거나, 과거 프로젝트가 너무 익숙해져서 그 스타일이 몸에 밴 것일 수도 있을 것 같네요.

저는 최근에 서버 API 변경에 맞춰서 일부 모듈의 리팩토링을 같이 진행하고 있습니다.

API와 직접 연관된 부분만 간단히 수정하려 했는데, 줄줄이 연결된 레거시가 너무 많네요.

깔끔해져 가는 코드를 보면 너무 기분이 좋은데, 예상하지 못한 레거시를 추가로 분석하고, 믿었던 코드에 배신을 당하면서 스트레스가 심해지는 것 같아요.

다시 한 번 생각해 봅니다. 이게 그 사람의 한계였을 것이다.

2022년 10월 22일, 일산 킨텍스에서 한국코드페어 본선 행사의 심사위원으로 참여했습니다.

내가 벌써 심사위원할 짬인가?

제안을 받고서 내가 벌써 그럴 짬인가? 하는 생각부터 들었습니다.
세월이 언제 이리 흘렀는지...

초등부 중등부 고등부를 나누어서 진행이 되었고, 저는 고등부의 심사를 맡았습니다.

처음 해보는 심사위원이라 걱정도 많이 되었고,
학생들이 어떤 작품을 준비했을지도 기대도 많이 되었습니다.

명찰을 받고나니 정말 심사위원을 하는구나! 하는 생각이 들었어요.
잘 간직해야지 하고 신났었는데, 행사가 끝나고서 도로 가져가셨습니다.
어디다 쓰시려구.. 섭섭..

심사를 하다보니 학생들이 준비를 많이 한 것을 알 수 있었습니다.
AI를 활용한 작품도 많았는데, 제가 대학 졸업할 당시 동기들의 졸업작품보다 퀄리티가 뛰어난 작품도 있었습니다.

각 작품에 대해서, 여러 상황에서의 동작에 대해 질문하기도 했는데
학생들도 많은 부분을 고민했었고, 심지어 대응까지 한 학생들도 있었습니다.
훌륭하다...

감탄하며 질문을 하다보니 시간을 많이 오버해버렸어요.
일부 팀이 불참해서 시간을 많이 써도 괜찮다고 전달받았는데, 그래도 너무 오래했나봐요.
미안해요 학생분들..

인터넷 뉴스에도 한 컷 등장했습니다.
- https://v.daum.net/v/20221025140109164

고생했다고 사은품(?)을 주셨어요

무엇이 들었을까요?

.
.
.
.
.
.
.
.

마우스였습니다.
얼마전에 키보드만 바꿔서, 마우스도 바꿀때가 되었는데 좋은 타이밍이네요.

종일 서있느라 힘들기도 했는데,
다음에 또 기회가 되면 참여하고 싶을 정도로 학생들 수준도 그렇고 작품 퀄리티도 높았던 것 같습니다.

다음에 다시 제안 주시면, 시간 오버 안해볼게요😂

저는 새로 접하는 소스 코드를 살펴볼 때 여행을 떠난다고 표현하곤 합니다.
 💬 ☆☆모듈의 코드 여행을 다녀왔습니다

이전 회사에 입사해서 배정된 팀은 구조가 조금 이상했는데 리더를 제외하면 다음의 형태였습니다.

• 수석급 2 명 / 책임급 1 명
• 선임급 2 명 / 사원급 2 명
• 신입사원 3명

사원/선임/책임급은 학/석/박사 입사 2년차 이하였기에, 2년차 이하의 집단이었습니다.

허리층이 없는 구조인데, 원해서 만들어진 구조는 아니었고 인력을 막 모으던 팀이었죠.

팀분들께 프로젝트에 대해서 질문을 하기 좋은 상황은 아니었지만,

저는 도움을 받는 것 보다는 직접 파악하는 것을 선호하였기 때문에 큰 문제는 없었습니다.

오히려 코드 여행을 떠나기에 최적의 팀이었죠.

여행을 다녀오면, 본 것들을 공유 하기도 했고, 자연스레 세미나 준비도 잘 했던 것 같습니다.

그 때는 참 의욕적으로 코드 여행을 떠났는데, 다음과 같은 이유가 있던 것 같습니다.

• 처음 접한 모듈(FTL)이 신기하고 재미있어서
• 빨리 한 사람 몫을 하고 싶어서
• 맡은 업무(버그) 처리를 위해서

이렇게 코드 여행을 떠나면서 스스로 코드를 살펴보던 것이 많은 도움이 되었는데요,

지금은 구조가 다소 어색한 프로젝트를 보는 것에 거부감이 없고, 동작이 잘 정리되지 않은 코드도 조금 더 빠르게 파악할 수 있게 된 것 같습니다.

(덧)

개인적으로는 입사 초기에 프로젝트 구조를 깊게 잘 파악했던 덕분에,

• 이후에 TF팀에서 새롭게 모듈을 설계할 때도 활발히 참여할 수 있었고,
• 중요 모듈을 메인으로 개발할 수 있었고,
• 다양한 버그 이슈 대응에도 투입되었고,

꽤나 중요한 팀원이 될 수 있었던 것 같습니다.

HR과 퇴사 면담 때, 팀 리더로 부터 잡아야하는 인재라는 얘기를 들었다며, 리텐션 옵션을 제안 받기도 했습니다.

참 감사하고, 보람있는 순간이었죠.

다만, 쓰레기같던 옆 팀 리더 때문에 퇴사하는 것이었기에, 제안은 거절하고 나왔습니다.

커리어리에서 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

2년차 주니어를 지원하고 있습니다.

팀을 옮겨온 분이어서, 프로토타입 기능을 개발하면서 적응을 유도하고 있는데요,
필요한 부분에선 소극적이고, 수용해야 할때는 고집을 부려서 스트레스가 심합니다.

어떻게 하면 좋을지 고민을 해야겠어요.

이전에 3년 정도의 개발 경력이 있는데 중고신입으로 입사했다고 들었는데,

신입사원과 별로 차이가 없어서 실망스러운 것도 있습니다.

설계를 고민을 좀 해야하는데 고민의 흔적이 전혀 없어요.

한 번은 이상한 구조를 "어색하니 수정합시다" 라고 코멘트를 남겼더니, "저는 어색하지 않습니다" 라는 답이 왔어요.

이곳 저곳을 살펴야 하는 큰 구조 변경을 요구하면, 일단 반항적인 자세를 취합니다.

코드와 본인을 일체화해서 방어적인 것인지, 일이 커지니 짜증을 내는 것인지 알 수가 없어요.

상대가 스트레스받지 않게 최대한 좋게 말하고 돌려 말하니 무작정 거절해도 된다고 생각하는가 봅니다.

이제는 "이상한 것"과 "불쾌한 것"을 직설적으로 얘기하고 있습니다.

상대의 스트레스 보다 나의 스트레스가 더 중요하니까요.

남을 배려하지 않는 사람까지 배려하고 싶지가 않네요.

오는 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나 답답할 땐 답답하고 재미있을 땐 재미있는 것 같아요.

저는 IDE로 Visual Studio를 가장 좋아하는데요,
제가 주로 사용하는 단축키(shortcut) 항목들을 간단히 공유합니다.

Tools > Options > Environment > Keyboard

Edit.LineUpExtendColumn & Edit.LineDownExtendColumn

생산성의 끝판왕 multi-cursor 기능입니다.
Visual Studio 2017 까지는 multi-cursor가 같은 column에서만 인식이 되어서 불편한 점이 있었습니다.
필요할 땐 Visual Studio Code를 이용했는데 Visual Studio 2022에서는 보완되어서 너무 좋네요.

Edit.CollapseCurrentRegion & Edit.ExpandCurrentRegion

조건문이나 switch case 문이 너무 길어 현재 scope가 어디에 포함된 것인지 확인하기 어려울 때 사용합니다.
위 예시에서는 CollapseCurrentRegion를 이용해서 현재 case가 무엇인지 확인하고 있습니다.

Edit.CommentSelection & UncommentSelection

CommentSelection의 default shortcut은 Ctrl+K, Ctrl+C 입니다.
양손을 모두 이용해야하는 조합이어서, 저는 왼손으로만 조합이 가능하도록 shortcut을 설정해서 사용하고 있습니다.

View.NavigateForward & View.NavigateBackward

default shortcut도 사용하기 좋습니다.

Edit.PeekDefinition

함수로 이동하지 않고, 현재 flow를 보면서 함수 내부 동작을 간단히 확인하고 싶을 때 사용합니다.

그 외 Visual Studio의 default shortcut은 다음 링크에 정리가 잘 되어있습니다.

• https://learn.microsoft.com/ko-kr/visualstudio/ide/default-keyboard-shortcuts-in-visual-studio?view=vs-2022
• https://learn.microsoft.com/ko-kr/visualstudio/ide/productivity-shortcuts?view=vs-2022