Thinking, Writing, and.

문제를 해결하는 방법에 대해 생각해 봤습니다. 먼저 문제가 무엇인지 정확한 진단이 필요할 것입니다. 그리고 그 문제에 대한 대증요법이 아닌 정확한 해결책이 필요할 것입니다. 여러 조직들을 경험해 보면, 문제에 대한 정확한 진단을 하지 못하는 조직은 대부분 역량이 부족한 상태였습니다. 문제 자체를 이해하지 못하기 때문에 그것이 어떤 문제인지 알 수가 없는 상태인거죠. 그런 상태에서 나오는 답이 문제를 해결할 수 있을리 없습니다.역량을 충분히 갖춰 문제를 잘 진단하는 조직 중에서 이해가 잘 안됐던 부분 중 하나는 문제를 정확하게 해결하는 것이 아니라 일종의 대증요법(?)을 사용하는 것이었습니다. 예를 들면 하드웨어에 예상하지 못했던 exceptional case가 있어서 어렵고 critical한 불량이 발생..

개발 중인 inference 엔진의 test coverage를 어떻게 올릴 수 있나에 대한 고민을 하고 있습니다. 상대적으로 개발(휴먼) 리소스가 부족한 상황에서, 팀원분들이 굉장히(🤣) 빠르게 개발을 진행하고 있어서, 솔직히 테스트를 약하게.. 진행했던 부분들에서 삐걱거리게 시작했거든요. 테스트가 중요하다는 것은 명확한 사실이나, 개발(휴먼) 리소스가 부족한 것도 현실이라 어떻게 해야 하나 싶었는데, 요즘 agent에 대한 이야기들이 많이 나오길래 한 번 간단하게 구현해 봤습니다. 개발한 코드에 대해서 pair programming 하는 것처럼, unit test agent가 계속해서 code를 테스트 해줄 수 있으면 어떨까?하는 간단한 생각부터 출발!유명한 OpenHands는 open source ..

술자리에서 빠지지 않고 나오던 주제에 대해서 생각해 봤습니다. 주로 조직 문화 개선, 불합리 개선, 일하는 방법 개선 등등의 이야기를 쭉 하고 나면 항상 공통된 결론으로 귀결되는 뭐 그렇고 그런 이야기 입니다. 항상 이러한 불합리한 것들 개선하려고 보면, 반대되는 의견들이 있거든요. 주로 안정을 추구하거나 아니면 자신들에게 이득이 되지 않는다고 판단함으로써 단단한 껍질 속에 숨어 버리는 자라처럼 목을 쏙 집어 넣어버리고는 개선을 거부하는 의견들 말입니다. 참 신기하게도, 이렇게 안정을 추구하는 쪽은 항상 똘똘 뭉쳐있습니다. 대체 어떻게 그런 구심력을 갖게 되는 것인지 너무 궁금하지 않나요? 너무 부러워요. 어쩜 그렇게 똘똘 뭉쳐서 탄탄하게 자신들의 의견을 서로서로 방어할 수 있는지. 🤔 개선을 말하는 ..

오늘은 그 동안 제가 지내왔던 조직들을 관찰했던 내용 중에서 성향과 성향이 충돌하는 상황, 그리고 그 상황이 어떻게 조직의 발전을 저해하는지에 대한 이야기를 해보려고 합니다. 많은 사람들이 함께 지내는 곳이기 때문에 회사 내에서, 그리고 작게는 개발 팀 내에서도 성향과 성향의 충돌은 당연합니다. 문제는 이러한 성향의 충돌이 이성적이고 합리적으로 풀어나갈 수 있냐는 아닙니다. 제가 경험했던 것 중 가장 흔하게 보이고, 가장 심각한 문제를 보이는 것은 혁신 vs 안정 이었습니다. 조직 내에 문제가 있으면 여러분들은 어떻게 하시겠습니까? 어떤 사람들은 조직 내 문제가 있으면, 문제가 뭘까 파악하고 그 문제를 어떻게 "해결"할 수 있을까 생각합니다. 그리고 그 답을 찾아오는데, 그것이 갖는 파급효과를 꼼꼼이 따..

이전 글 "R&R을 따지는 놈이 범인?" 편에서 조직 문화를 해치는 썩은 사과를 한 번 찾아봤습니다. 여러 분들의 의견은 어땠는지 궁금합니다. 범인 맞나요? 🧐오늘은 조직 문화를 해치는 범인을 또 한 번 찾아보려고 합니다. 조직을 보면 자신의 의견을 (그것이 부정적인 것일수록 더욱 크고) 당당하게 제시하고, 이 의견에 대해 사람들에게 동조를 구하면서 분위기를 만들어가는 사람들이 있습니다. 저는 이런 사람들을 "빅 마우스"라고 부릅니다. 이 빅 마우스들의 주변에는 대부분 조직의 방향에 불만이 좀 있더라도 순응하는 어린양들이 주로 존재하죠. 그래서 빅 마우스는 이들의 의견을 조직의 상부에 대리 표출해 주는 역할을 맡으면서, 어린양들로부터는 지지를 받고 조직의 리더 계층으로부터는 신임을 얻게 됩니다. 조직 ..

사업화 제품을 개발하는 팀의 역량 정도를 파악하는 여러 지표들이 있는데, 개인적으로 경험해 본 조직들 중 비슷한 역량을 갖는 팀이 공통적으로 하는 것이 있어서 신기했던 경험이 있습니다. 사업화 과제에서, 정말 긴급하고, 중요하게 다뤄지는 문제 중 하나는 "이슈(불량) 해결" 입니다. 일정이 미뤄지기도하고, 생산 라인이 멈추기도 하고, 고객에게서 항의 메일이 오기도 하고, 아예 사업이 부러지는 경우가 발생하기도 하죠. 그래서 사업화 제품을 개발하는 팀 중 몇몇 팀들은 자체 역량 강화를 위해 종종 또는 자주 "기술 세미나" 라는 것을 하는데요. 신기하게도 "XXX 불량 분석 방법", "XXX 불량 분석 노하우 공유" 이런 류의 기술 세미나를 하는 조직 들이 있습니다. 경험해보신 적 있으신가요? 이슈에 대한 ..

개발 프로젝트를 진행하다보면, 항상 (유연성이 요구되는) 잡음이 발생하는 문제들을 겪습니다. 보통 이런 문제들입니다. "개발 언어는 무엇으로 할 것인가?" "어떤 아키텍처로 할 것인가?""우리의 workflow는 어떻게 할 것인가?" 사실 이런 문제는 유연성과 큰 관련이 없어야 하는 질문들 같습니다. 명확한 답이 있어야 할 것만 같거든요. 이 문제를 해결하기 위한 최적의 시스템 아키텍처가 무엇인가? 우리 팀의 최고 효율을 낼 수 있는 workflow가 무엇인가? 우리 시스템에서 가장 빠른 속도를 낼 수 있는 개발 언어로 어떤 것을 선택할 것인가? 등등이요. 정답이 있을 것 같아서 그걸 찾아내고 싶지 않나요? 그래서 각 candidate의 비교를 통해 장단점을 파악하고, 점수화하여 합리적으로 선택을 할 수..

얼마 전 “R&R을 따지는 놈이 범인이다”라는 주제와 관련된 글을 몇 편 읽었습니다.관련된 글들을 보면 다양한 이야기가 있었습니다. • 조직 간의 협업 문제, • 팀장과 개발자 간의 명확한 R&R 정립, • R&R이 부족할 때 발생하는 갈등 등이 주된 내용이었습니다.저는 이 주제에 대해 개발 조직 관점에서 제 생각을 한 스푼 얹어 보고자 합니다.개발을 하면서 경험했던 다양한 개발자 유형을 R&R을 기준으로 분류해 보면, 크게 다음의 세 가지로 나눌 수 있었습니다.1. R&R에 따라서 일한다.내 R&R이 아니더라도, 긴급한 업무일 경우 적극적으로 협업한다.2. 철저하게 R&R에 따라서만 일한다.내 역할이 아닌 업무는 명확히 선을 긋는다.3. R&R에 따라서 일한다. 하지만 내 R&R에 제약을 두지 않는다...