blogging 시스템 테스트 겸 근황.. 하려는 이야기를 하기 전에
조직과 구조#
제가 번역한 책에 나오는 문구로 시작하겠습니다.
“시스템을 설계하는 조직은 필연적으로 해당 조직의 커뮤니케이션 구조를 복제한 설계 구조를 만들어낼 수밖에 없다.” [읽기 쉬운 코드. Chapter 14.2.3]
최근에 몇몇 사람들과 조직의 scaling과 시스템의 도입에 대해서 이야기를 하다가 생각을 좀 하게 되어서 적습니다. :)
제 생각에 시스템과 workflow
라는 것은 “뇌의 부하를 줄여줌으로써 더 중요한 일에 집중할 수 있도록 만드는 것"입니다.
따라서, 작은 조직일 때는 시스템을 구축하는 overhead보다 개인이 감당하는 뇌의 부하 총량이 작은 경우가 많기 때문에 일반적으로 문제가 발생하지 않습니다. 더불어 작은 조직인 경우에는 나름의 암묵적인 룰이 생성되는 경우도 있고요.
하지만, 조직이 커지면 “암묵의 룰"이 더 이상 퍼질 수 없는 크기가 되며, 개인이 감당하는 부하의 총량이 전체적인 “비효율"로 바뀌게 됩니다.
같은 작업을 반복하지 않을 수 있는 장치 혹은 workflow가 설정되어 있지 않아서, 그 작업을 할때마다 “이걸 누구에게 물어봐야 하는 것이지"라는 것을 고민해야 하고, 그때 그때 ad-hoc한 방식으로 움직여야 한다면, 효율적으로 일하는 것을 지향하는 조직이라 할 수는 없을 것입니다.
결과적으로, 조직이 커짐에 따라 시스템과 workflow를 잘 만드는 것은 enginnering manager(특히 C-level들)에게 피할수 없는 일이 됩니다.
이런 시스템은 필연적으로 조직이 scaling됨에도 효율성을 유지하고, 보안문제를 해소하는 것이 목적이 됩니다.
대부분의 시스템은 overhead를 포함합니다. 이런 overhead는 일반적으로 “조직 문화"로 해결할 수 있습니다. 다만, 우리는 이런 “조직 문화"를 선언적으로 생각하는 경우가 많은 것 같습니다.
저는 선언적 이야기를 잘 믿지 않습니다. 결국은 “행동"이 뒷바침되어야 하는 것이기 때문이죠. 예를 들어, 우리 분야의 엔지니어들에게 여러가지 “선언"은 결국 코드와 코드 구조, 문서 공유 시스템으로 나타나게 마련입니다.
선언은 중요하며, 특히 어떤 지향점에 대한 이야기라면, 합의와 지지를 이끌어내는 것이 더 중요합니다. 이를 통해서 행동을 유도해야 하기 때문입니다.
결국 최종적으로 이게 코드와 코드 구조, 개발 flow등의 형태로 나타낼 때까지 그냥 포장인 경우가 많기 때문이죠.
예를 들어, 각 그룹에서 그들만의 비밀을 철저히 유지함으로 하는 생명력을 유지하는 것 사일로 패턴이라는 것이 있습니다. “우리는 열린 대화를 지향합니다.“라고 이야기하면서, 각 팀의 문서, 코드에 대한 접근이 막혀있다면 이건 사일로 패턴을 지향하는 조직이라 생각하면 됩니다.
사일로 패턴은 대부분의 경우에 “보안"의 중요성을 이야기하는 경우가 있습니다. 현실은 “공격받기 싫어하는 마음"이 근저에 존재해서, 그 효율성을 극단적으로 떨어트리는 경우까지 가는 경우가 많죠.
이런 형태를 시스템, 혹은 조직 문화에서 방조, 조장하면서, “우리는 효율성을 중시하고, 열린 대화를 중시한다"고 한다면 이건 “선언"과 “행동"의 불일치로 인해서 정상적인 조직 문화가 형성될 수 없습니다.
“우리는 Best Quality에 가치를 둔다"는 선언은 일반적으로 반복적인 architecture review, design review, code review등의 다양한 review process와 더불어 기술을 공유하는 행위, 측정하고 확인하는 작업들이 뒷받침되어야 합니다.
이 과정을 당연한 “개발의 과정"으로 받아들일 것인지, 혹은 이 과정을 “비용"으로 생각해서 빠른 개발을 위해서 생략할 것인지 역시 행동의 일환이라 할 수 있습니다. (급할때는 일시적으로 생략할 수도 있습니다. 다만, 이런 것이 기술적인 부채가 되어, 나중에 더 크게 돌아올 것이라는 점은 항상 인식하고 있어야 합니다.)
이야기를 나누다보면, 많은 분들이 효율성과 보안을 반대의 용어라 생각하시는 경향이 있습니다만, 효율성과 보안은 상충되지 않는 경우가 더 많습니다.
다만, 이걸 지원하기 위한 보안 인프라에 들어가는 “비용"이 증가하는 경우가 있을 것으로 봅니다.
보안은 실수를 막아주는 것이고, 보안에 민감한 행동에 대해서 일종의 confirmation과정을 부여하는 것이 필요한데, 이를 구현하려면 동작을 logging 하면서 민감한 행동에 대해서 incidence가 발생했음을 확인할 수 있도록 구축되어야 합니다.
하지만, 보안 인프라에 투자를 하지 않는 경우에는 일종의 자기 검열을 통해서 이런 문제가 발생하지 않도록 신경을 써야 하며, 이는 엔지니어의 “뇌에 부하를 주며”, 이로 인해 효율성 문제가 발생합니다. 혹은 극단적으로 효율성을 떨어트리는 경우(“난 뭔지 모르겠으니, 다 막자.” 혹은 “그냥 하지말자” 같은)가 발생할 수 있겠죠.
결국 좋은 조직 문화를 만드는 것은, 좋은 행동을 이끌어내기 위한 것임을 잊지 말아야 합니다.
이를 지원하기 위한 workflow, repository 구조, data sharing system, 그리고 보안 시스템을 어떻게 구성할 것인지는 모두 조직이 공유하고 있는 생각에 기반해야 합니다.
- 어떤 조직 문화를 가질 것인지
- 우리는 어떤 “핵심 가치"를 가지고 있으며, 어떤 것에 우선 순위를 두고 있는지
- 이는 결국 어떤 비전을 가지는지
위의 이야기 역시 선언적인 수준에 그치는 경우가 많습니다만, 이 내용이 바로 “회사의 가치관"을 정하는 것이기 때문에, 이 부분이 “의사 결정"의 기반이 되어야 하는 것입니다.
왠지.. 코칭 같은 내용이 되었네.. 글을 약간 망했네요.
겸사 겸사 근황 몇개#
ISO26262 인증#
저희가 만든 NOC product가 ISO26262 인증을 받았습니다. 신문기사
그간 사용하던 flow가 나쁘지 않았다고 생각하고 있었으므로, 큰 문제가 아닐 것으로 생각했습니다만.. 그럼에도 써야 할 문서와 추가해야할 것들이 상당하더군요.
다른 측면에서는 설계한 것에 대해서 제가 못보던 view를 제공해준다는 점에서는 좋았습니다.
NOC에서 SOC로 확장중#
프로세서 domain에서 video codec 분야로 옮긴지 12년만에 봐야하는 주요 학회가 MICRO, ISCA, ISCAS 쪽이 되었습니다.
Video codec으로 가기 직전에 연구했던 분야가 heterogenous MP/NOC 쪽이어서 멀리 있는 것은 아니지만, 그간 아카데미아 분야에서 완전히 산업계 쪽으로 옮겨간 만큼 catch-up하는데 시간이 좀 걸렸습니다.
이제서야 조금씩 더 cutting-edge 쪽에 다가가고 있다고 생각합니다. (이 이야기는 아직은 cutting-edge는 아니라는 말도 됩니다)
NOC의 범위도 생각보다 많이 넓어진 것 같습니다. 예전에는 wire를 줄이는데 초점이 맞춰져 있었다면, 이제는 더 많은 bandwidth를 전달하는 쪽으로 이전했고, SoC 설계에 대한 service backbone으로 동작을 하는 것을 기대하는 것이 많은 것 같습니다.
SoC의 범위가 바뀜에 따라 NOC에서 chiplet까지 확장하는 것은 너무 당연하게 되었고(그래서 지금까지 3년간 UCIe를 같이 개발했고), SoC 설계의 많은 부분을 지원할 수 있어야 하는 시점이 된 것 같습니다.
일단은 작은 범위부터 출발해야 할 텐데, 점점 주변의 많은 전문가 분들께 도움을 요청해야 할 시점이 된 것 같기도 합니다.
Vibe code?#
사실 짧은 코드를 ChatGPT나 Claude에서 작성하면서도 대단하다고 생각했는데, Vibe Code까지는 아니라고 생각했는데.. (scripting 은 정말 잘해주더군요)
최근에 Gemini AI studio로 간단한 web app을 만들어보고 놀랐습니다. (그리고, 실망도.)
너무 쉽게 어느 정도 그럴듯하게 만들어져서 놀랬고, 제대로 만들기가 생각보다 어려워서 실망했습니다. 그래도 동작하는 prototype을 만들거나 간단한 유틸리티를 만들기는 정말 좋은 것 같습니다.
사실 놀란건, Claude code입니다.
간단한 SystemC 모델링 하나를 Claude code, OpenAI Codex, Gemini CLI를 사용해서 코딩해봤는데.. Claude code는 생각보다 잘해줍니다. 좋은 명령을 내리면 좋은 코드를 짜는데, 가끔은 이상한 짓을 하고, 가끔은 데이터를 조작하기도 하고.. 하지만, 왠만한 junior 엔지니어 보다 좋지 않나.. 하는 생각이 들었습니다.
위에 이야기한 것처럼 코딩이 이상할 때가 있는데, 결과를 주는 시간이 빠르다보니, 나는 계속 설계 지침을 쓰고, 다음 지침을 정리하는 동안에 결과가 나오는 과정이 반복되더군요.
다만, claude code pro티어에서는 약간 빡세게(repository가 커지면) 작업하면 30~40분 정도면 5시간 리밋이 걸린다는 점과, 코딩이 이상해지는 주기가 있는 것 같다는 점이 문제긴 합니다.
참고로, Codex나 Gemini는 각각 잘하는 분야들이 있습니다. Codex는 reasoning effort를 high로 두고 full agent mode로 하면, 꽤 쓸모있게 작업을 합니다. Gemini 역시 pro인 경우에 꽤 쓸모있습니다.
다만, 3개를 하나의 repo에 쓰면 약간 망합니다. 서로 추구하는 바가 약간 다른 것 같습니다.
저는 claude code로 coder, gemini pro로 reviewer 역할을 주고 동작을 시키는데, 상당히 괜찮습니다. 다만, 이때 정확한 지침이 제일 중요하죠.
이 정도 발전 속도라면, 기술 회사에서 사용하지 않으면 안되는 상황까지 올 시점이 곧 도달할 것이라 봅니다. 효율성에서 비교가 안될 겁니다.
Hugo Blog Setup#
Hugo blog를 설정한 건 상당히 오래되었는데, 사실 오류나는 글을 몇개 수정한 다음에는 안쓰고 있었습니다.
문제는 그러다 사용법을 잊어서, 오랫만에 쓰려니 어떻게 해야 하는 것이지 파악하는 것도 시간이 들더군요.
오늘 집에서 github repository를 다시 받아와서 테스트를 하고 있는데 쉽지 다양한 이유로 쉽지 않았습니다.
- 얼마전에 WSL이 꼬여서 다시 설치했는데, hugo를 깔고 보니 버전이 달라서 설정을 살짝 바꿔야 하는데 기억이 나지 않는다.
- ChatGPT 님께 문의를 하면서 진행했는데, front matter를 어떻게 사용했는지 잘 모르겠더군요.
- 테마 어떻게 가져오는 거였지? 뭘 바꿔서 설정했는데..
결과적으로 기억이 잘 안나는 거죠. Blogging system에 이 정도로 정성을 들이는 것은 뭔가 잘못된 것 같아서 잘 찾아보니..
실제로는 그냥 github 자체에서 markdown으로 작성하면 될 것 같군요.
front matter는 snippet으로 넣으면 되겠고요. 그리고, web version vscode가 언제 github과 integration된 거죠? 대단하네요.
그냥 Web에서 post를 작성하기로 결정했습니다. (그리고나서 생각해보니.. 예전에도 그랬던 듯)
