tools - thoughts

Author: haklee

docs/works/tools-and-tales/thoughts/2025/0201-1.en.md

@@ -0,0 +1,21 @@
+---
+title: "4 Years and 4 Months at Zenerate and After (1)"
+---
+
+[:material-arrow-left-bold: Back to post list](../index.md){ .md-button }
+
+`2025. 02. 01.`
+
+After a long journey of 4 years and 4 months at Zenerate, I'm going back to school to finish my undergraduate degree. My extended leave of absence has finally run its course, and now I must truly attend classes. These days, I've been reflecting on my experience as a software engineer at a startup.
+
+## 1. About working as a software engineer at a startup
+
+If we trace back to the time when Zenerate didn't even have its name yet, when we were a small team conducting research on dividing dormitory buildings into multiple rooms, my connection with Zenerate spans just over 6 years. In January 2019, the CTO contacted me, saying my skill set would be a great fit for the project they were working on. This marked the beginning of my work, where I pondered how to structure the thousands of ways to divide a building and store it in a database and how to visualize this information in Grasshopper.
+
+About a year later, as the research project's idea developed, the team became a startup, and in September 2020, after leaving a game company, I joined Zenerate. Knowing nothing about startups, I spent over 4 years growing and experiencing numerous things. My primary role was developing and maintaining backend services, including architectural design engine development. To elaborate, my work involved selecting the necessary technology stack for service development in ever-changing situations, sometimes finding and learning new technologies, determining how far we should improve the perfection of technology, deciding when the service should be operational, distributing tasks to team members, and ultimately implementing the service.
+
+While working, I realized that solving problems isn't just about addressing what's in front of you, but about being able to define the problems themselves. And, perhaps inevitably, problem definition must occur within the context of the market before us - what we want to or need to do. No matter how brilliantly I could develop features, if the development period is too long and we miss the timing to capture users' attention, it's worthless from the company's perspective. Conversely, if we rashly tackle tasks without careful consideration, technical debt accumulates too quickly. When system expansion becomes inevitable, critical bugs emerge, making it difficult to meet new user needs. If users want a faster, higher-performance service, adopting a slightly niche but performance-guaranteed technology can make it hard to find collaborators and research materials. This could potentially impose an overly burdensome workload on the development team. Such workload reduces team flexibility, making new service development challenging and potentially slowing the company's growth. I'm unsure how many problems I've defined, solved, and redefined according to changing circumstances. Looking back, while this work wasn't easy, it was quite interesting.
+
+I believe my 4 years at Zenerate were about exploring paths with no definitive right answers but certainly some wrong turns, navigating step by step through direct experience. I feel honored to have traversed these interesting, challenging, and surprising times alongside the various connections I made at Zenerate.
+
+[:material-arrow-left-bold: Back to post list](../index.md){ .md-button }

docs/works/tools-and-tales/thoughts/2025/0201-1.ko.md

@@ -0,0 +1,21 @@
+---
+title: "제너레잇에서의 4년 4개월과 그 후 (1)"
+---
+
+[:material-arrow-left-bold: 글 목록](../index.md){ .md-button }
+
+`2025. 02. 01.`
+
+제너레잇에서의 4년 4개월의 긴 여정을 마치고 다시 학교로 돌아간다. 영혼까지 끌어다 쓴 휴학이 바닥나서 이제는 정말로 수업을 들어야 한다. 요즘엔 이런 생각을 하고 있다.
+
+## 1. 스타트업에서 소프트웨어 엔지니어로 일하는 것에 대하여
+
+제너레잇에 아직 제너레잇이라는 이름이 없던, 기숙사 건물을 여러 실들로 쪼개는 리서치를 하던 작은 팀이었을 적까지 거슬러 올라가면, 제너레잇과의 인연은 6년이 조금 넘는다. 2019년 1월에 CTO님께서 내가 가진 스킬셋이 팀에서 진행하고 있는 프로젝트와 잘 맞을것 같다고 하시면서 연락을 주셨고, 이를 계기로 건물을 쪼개는 수 만 가지 방식을 어떻게 구조화해서 DB에 넣을지, 이 정보를 어떻게 그래스호퍼로 시각화할지 같은 것을 고민하고 구현했던 기억이 있다. 1년 정도 뒤 이 리서치 프로젝트의 아이디어가 점점 디벨롭 되면서 이 팀은 스타트업이 되었고, 나는 2020년 9월에 게임회사를 퇴사하고 나서 제너레잇에 합류했다.
+
+스타트업의 '스'자도 모르는 상태로 합류하고 나서 4년이 넘는 시간 동안 정말 많은 일들이 있었고, 많이 성장했다. 내 주된 역할은 설계 엔진 개발을 포함한 서비스 뒷단과 연관된 각종 기능들을 개발하고 유지보수 하는 것이었는데, 좀 더 풀어서 설명하자면 매번 다르게 주어지는 상황 속에서 서비스 개발을 위해 필요한 기술 스택을 정하고, 때로는 새로 배워야 하는 기술들을 찾아서 공부하고, 그렇게 공부한 것의 완성도를 어디까지 끌어올려야 할지, 그래서 언제까지 서비스가 돌아가도록 할 것인지 정해서 다른 팀원들에게 작업을 분배하고 서비스를 구현해내는 것이 내가 하던 일이었다.
+
+일을 하면서는 눈 앞에 주어진 문제를 풀기만 하는 것이 아니라 문제를 직접 정의할 수 있어야 한다는 것을 깨달았다. 그리고, 어쩌면 당연하게도, 문제 정의는 우리 앞에 펼쳐진 시장에서 우리가 무엇을 하고 싶은지/해야 하는지 맥락 속에서 이루어져야 했다. 내가 아무리 기능을 기깔나게 뽑을 수 있다고 하더라도 개발 기간이 오래 걸려서 유저들의 시선을 끌 타이밍을 놓치면 회사 입장에서는 말짱 꽝이다. 그렇다고 눈 앞에 있는 일들을 고민 없이 막 쳐내기만 하면 기술 부채가 너무 빠른 속도로 쌓여서 정작 시스템 확장이 불가피한 상황에 각종 치명적인 버그들이 튀어나오면서 유저들의 새로운 니즈를 맞추기 어려워질 수도 있다. 유저들이 더 빠른, 높은 성능의 서비스를 원한다고 해서 성능은 확실하지만 대신 조금 마이너한 기술을 도입하면 같이 일 할 사람을 구하기도 어렵고 자료 검색도 힘들어지는데, 이는 자칫 잘못 하면 개발 팀에 지나치게 부담스러운 업무 로드를 걸 수 있다. 그리고 이런 업무 로드는 개발팀의 유연성을 떨어뜨리고, 이는 새로운 서비스 개발 등을 어렵게 하는 것으로 이어져 결국 회사의 성장을 더디게 만들 수도 있다. 그동안 얼만큼의 문제를 정의하고, 풀고, 바뀐 상황에 맞춰 문제를 다시 정의했는지 모르겠다. 돌이켜 생각해보면 이런 업무가 쉽지는 않았지만 꽤 재미있었다.
+
+제너레잇에서의 4년은 정답은 없지만 오답은 있는 길들을 직접 몸으로 부딪치면서 더듬더듬 찾아가는 시간이었다고 생각한다. 흥미롭던, 힘들던, 놀랍던 시간들을 제너레잇을 통해 만난 여러 인연들과 함께 헤쳐나갈 수 있어서 영광이었다.
+
+[:material-arrow-left-bold: 글 목록](../index.md){ .md-button }

docs/works/tools-and-tales/thoughts/2025/0201-2.en.md

@@ -0,0 +1,21 @@
+---
+title: "4 Years and 4 Months at Zenerate and After (2)"
+---
+
+[:material-arrow-left-bold: Back to post list](../index.md){ .md-button }
+
+`2025. 02. 01.`
+
+After a long journey of 4 years and 4 months at Zenerate, I'm going back to school to finish my undergraduate degree. My extended leave of absence has finally run its course, and now I must truly attend classes. These days, I've been reflecting on my experience as a software engineer at a startup.
+
+## 2. About architectural design automation(or, generative design)
+
+Zenerate is a company creating architectural design automation(or, generative design) services. This dramatically increased the difficulty of our work because it was hard to find similar companies, so we had to build everything from scratch without any reference materials. Even after carefully defining the service specifications and technology stack, finding people to develop it together was not easy. This is a problem faced by all companies dealing with architectural design automation, which is why the few services created by companies around the world have completely different features. Some generate only large buildings, some only small buildings, some create real-time design proposals but don't show various options, and some take a few minutes to generate design proposals after inputting conditions but can create dozens or hundreds of plausible buildings that fit within the land.
+
+Contemplating how to structure buildings, what data structures to use to represent them, what details can or cannot be expressed through this representation method, and how to efficiently store and process buildings filled with geometric information - this is what I believe is the core of architectural design automation. Since accidentally encountering this field at [Boundless](https://www.boundless.kr/) in 2016, I have somehow (though I wandered a bit in between) continued to create related services, and I believe there are still plenty of things to research and try.
+
+The problem is that not many people are interested in this field. Because it's intertwined with architecture, understanding architecture is necessary to conduct related research and development, and a certain level of knowledge across various areas of development centered on data structures (especially those related to geometric shapes) is also required. One might think we could find such developers among programmers. But the moment you try to find developers who have worked with geometric information, the pool suddenly shrinks, and when you try to find those among them who are interested in architecture... really just a handful remain. Then what if we look for developers among architects? These days, such people have somewhat increased, but finding those with sufficient understanding of data structures and algorithms is as difficult as finding a needle in a haystack. A bit of a tangent, but developers who know how to develop usually call themselves computational designers. However, through recruiting, I've found that this term alone tells me absolutely nothing about what work they've done or what technologies they can handle. So I really dislike this term.
+
+I wish we could find more people seriously engaged in architectural design automation. I've been searching continuously until now, and I'll probably continue searching in the future.
+
+[:material-arrow-left-bold: Back to post list](../index.md){ .md-button }

docs/works/tools-and-tales/thoughts/2025/0201-2.ko.md

@@ -0,0 +1,21 @@
+---
+title: "제너레잇에서의 4년 4개월과 그 후 (2)"
+---
+
+[:material-arrow-left-bold: 글 목록](../index.md){ .md-button }
+
+`2025. 02. 01.`
+
+제너레잇에서의 4년 4개월의 긴 여정을 마치고 다시 학교로 돌아간다. 영혼까지 끌어다 쓴 휴학이 바닥나서 이제는 정말로 수업을 들어야 한다. 요즘엔 이런 생각을 하고 있다.
+
+## 2. 건축 설계 자동화에 대하여
+
+제너레잇은 건축 설계 자동화 서비스를 만드는 회사다. 바로 이 점이 업무 난이도를 드라마틱하게 높였는데, 유사한 아이템을 개발하는 회사들을 찾기 어려워서 뭘 하려고 해도 참고할만한 자료 없이 바닥부터 쌓아나가야 했고, 열심히 서비스의 스펙을 정하고 기술 스택을 정해도 같이 만들어나갈 사람을 찾는 것이 쉽지 않았기 때문이다. 이는 건축 설계 자동화를 다루는 모든 회사들이 비슷하게 겪고 있는 문제인데, 그래서 세계 곳곳에 있는 한 줌 정도 되는 다른 회사에서 만든 서비스를 사용해보면 제공하는 기능이 전부 제각각이다. 어디는 큰 규모의 건물만, 어디는 작은 건물만 생성해주고, 어디는 실시간으로 설계안을 만들어 주지만 다양한 안을 보여주지는 않고, 어디는 조건 입력 후 설계안 생성에 몇 분 정도 시간이 소요되지만 땅 안에 들어갈 수 있는 그럴듯한 건물을 수십, 수백 가지를 만들어준다.
+
+건물을 어떻게 구조화하고 이를 어떤 자료구조를 활용하여 표현할 것이며, 이 표현 방법으로는 건물의 어떤 디테일들을 표현할 수 있는지/없는지 고민하는 것, 그리고 도형 정보들로 가득한 건물을 어떻게 효율적으로 저장, 처리할 수 있는지 방법을 고안하는 것. 이것이 건축 설계 자동화 분야의 핵심이라고 생각한다. 2016년에 [경계없는 작업실](https://www.boundless.kr/)에서 우연히 이 분야를 접한 뒤로 어쩌다 보니 (중간에 방황을 조금 하긴 했지만) 지금까지 관련된 서비스를 만들어 왔는데, 아직 더 연구해볼만한, 시도해볼만한 것들이 충분히 많다고 생각한다.
+
+문제는 이 분야에 관심을 가지는 사람이 그리 많지 않다는 것이다. 건축과 엮여있는 분야다 보니 관련 연구 및 개발을 하기 위해서는 건축에 대한 이해도 필요하고 자료구조(특히 도형과 연관된)를 중심으로 한 개발의 여러 영역의 지식도 어느 정도 필요하다. 이런 조건에 맞는 사람을 개발자들 중에서 찾으면 되겠다고 생각할 수도 있겠다. 하지만 개발자들 중에서 도형 정보를 다뤄본 개발자를 찾으려고 하는 순간 갑자기 풀이 확 줄어들고, 그 중에서 건축에 관심이 있는 사람을 찾으려 하면... 정말 한 줌 정도 남는다. 그럼 건축가들 중에서 개발하는 사람들을 찾는다면? 요즘에는 이런 분들이 조금 늘어나고 있긴 하지만, 자료구조와 알고리즘에 대한 이해가 충분한 분들을 찾는 것은 건초에서 바늘을 찾는 수준으로 어렵다. 조금 딴소리인데, 개발을 할 줄 아는 건축가들은 보통 스스로를 컴퓨테이셔널 디자이너라고 부른다. 그런데 리크루팅을 하면서 보니까 도대체 저 단어만으로는 이 사람이 지금까지 무슨 작업을 해왔고 어떤 기술을 다룰 줄 아는지 전혀 알 수 없더라. 그래서 나는 이 단어를 매우 싫어한다.
+
+건축 설계 자동화를 진지하게 다루는 사람들을 더 찾을 수 있으면 좋겠다. 지금까지도 계속 찾아다니고 있었는데, 아마 앞으로도 계속 찾아다니지 않을까 싶다.
+
+[:material-arrow-left-bold: 글 목록](../index.md){ .md-button }

docs/works/tools-and-tales/thoughts/2025/0201-3.en.md

@@ -0,0 +1,21 @@
+---
+title: "4 Years and 4 Months at Zenerate and After (3)"
+---
+
+[:material-arrow-left-bold: Back to post list](../index.md){ .md-button }
+
+`2025. 02. 01.`
+
+After a long journey of 4 years and 4 months at Zenerate, I'm going back to school to finish my undergraduate degree. My extended leave of absence has finally run its course, and now I must truly attend classes. These days, I've been reflecting on my experience as a software engineer at a startup.
+
+## 3. Graduation looming ahead
+
+As life flowed by, I entered university in 2012 but still haven't graduated. When I first enrolled, I never imagined that my thesis advisor would leave the school before me, or that I'd be attending classes with students more than a decade younger... I think I've done everything I wanted to do since my 20s until now. Starting with architectural design major, I added an interdisciplinary major in media arts, and even a minor in computer science, taking as many classes as possible - I just checked and found out I've completed 222 credits. I've also gained diverse industry experience by taking leaves of absence. I feel like I've done enough exploring and it's time to graduate.
+
+The issue is that I need to complete my graduation project. There's an architecture department graduation exhibition next semester. After 8 years of development work where I've learned to draw service architecture diagrams and create programs, now I need to draw architectural diagrams and plan programs. I'm really-really-really worried about how to avoid a career gap while successfully graduating.
+
+While working at Zenerate, I created a architectural design engine that generates building masses and floor plans for units within them, so I could consider using this topic for my graduation project. However, I'm not really considering this option. First, directly subscribing to and using the service is problematic because various regulations and building types are based on US standards. Additionally, reimplementing the engine I developed to fit the graduation project would mean exposing the know-how I've built up at Zenerate, so I'm not considering it as an option.
+
+I'm currently thinking about creating experiential spaces through game-like methods. As I've written in previous posts, if space is a platform that mediates people's experiences, and if an architect's job is to design spaces and experiences and suggest methods to create them, then I don't think it's strange to handle virtual space design within the realm of architecture. However, rather than creating 'spaces' as mentioned earlier, I want to focus more on the process of 'creating' itself, and I'm thinking about methods to express the space I want to create - corresponding to traditional architectural diagrams and drawings. The result will likely be an application running on smartphones or computers with associated servers and databases. Whether this approach to the graduation project will be acceptable remains to be seen once I actually take the class, but for now, I've started learning Unity.
+
+[:material-arrow-left-bold: Back to post list](../index.md){ .md-button }