A 7-month journey from Basic to Group Projects: mastering CS fundamentals, discovering the essence of software design, and evolving through AI engineering
The password you enter is used to open, edit, and delete secret comments.
No comments yet.
Seven months passed in the blink of an eye. The anxiety I had at the beginning—wondering if I could finish without falling behind—has vanished, and here I am at the finish line.
I want to take a moment to look back at the long journey from Basic to Challenge, Membership, and the Group Project, capturing the moments I might have missed in the rush.
To be honest, my level of dependence on AI hasn't changed much before and after Boostcamp. However, the quality of that dependence has shifted significantly.
In the past, I would just ask "How do I do this?" and copy-paste whatever code came out. Now, I choose tools based on their specific strengths and combine them to fit my needs. I’m gradually gaining a sense of how to break down questions and what prompts to use to get closer to the desired outcome.
Once, while implementing a Three.js character, I lost an entire day trusting AI. It confidently gave me a solution that didn't actually exist. In the end, I had to find a different way through official documentation and community forums.
On the other hand, it was different when I had a solid foundation. When using Framer Motion, knowing the principles of animation allowed me to give detailed instructions, resulting in much higher quality. I used to wonder what my role would be in an era where AI does everything, but the results varied wildly depending on who was giving the commands. I concluded that to truly master AI, my own knowledge must be rock-solid.
The stronger the foundation, the higher the efficiency of engineering AI.
As a non-CS major, my biggest thirst was for computer science. Before, I was full of questions like "Why do I need to know this?" but through Boostcamp, I experienced firsthand where this knowledge is actually applied.
Because I understand network principles, I can contemplate data communication optimization; because I understand computer architecture, I accept why efficient code is necessary. Concepts like shell scripts, virtual memory, and the OSI 7-layer model were woven into actual projects.
I felt this change most vividly during a CS theory exam at my university. I went in with almost no study time due to the team project, yet most of the questions were topics I had already agonized over at Boostcamp. That was the first time I truly felt what it means for knowledge to be 'internalized.'
A memorable experience during the Basic and Challenge periods was implementing state management ourselves with Vanilla JS. Building components by inheriting classes and handling events without libraries was much trickier than I expected.
This naturally led to a question: "Why does frontend development lean towards functional programming instead of classes?" I organized my thoughts on this in a post titled Why React Pursues Functional Programming.
If I hadn't implemented it from the bottom up myself, I don't think I would have deeply understood the comfort of the declarative UI that React provides.
Watching someone else's PR during a code review session made me seriously think about architecture for the first time.
While I had used AI to generate a folder structure, that person meticulously recorded the step-by-step thinking process behind why they did it that way. I realized then that recording the process, not just the result, is what defines architectural capability.
Something I heard during a coffee chat also stayed with me: the core of frontend architecture is not how finely you divide components, but how well you separate business logic from the UI. I regret not knowing this principle earlier; I might have used my time more effectively instead of obsessing over component details.
After these reflections, I naturally became more cautious about bringing in new technologies. Instead of blindly adding trending stacks, I made it a habit to write ADRs (Architecture Decision Records). It’s a way of asking myself and recording, "Does this technology actually solve a specific problem in our service?"
After the days of making screens first and then struggling to fix the DB later, I have become someone who can draw out the data flow and DB design before starting.
The late Challenge and Membership periods were times of personal pain and emotional exhaustion. There were several days when I just wanted to go to sleep, but what kept me going were my colleagues who were finishing this journey with me.
I felt my passion fading at times, but seeing colleagues on the Slack channels and in Master Classes constantly exploring and sharing opinions gave me energy. I believe we were able to finish the project successfully because I trusted the team and their abilities.
When I shared an interactive PPT site I made for a web accessibility presentation, people told me my "attention to detail and UX are exceptional." It was a moment of confidence that my sense as a design major could be a unique weapon as a developer.
Coffee chats also helped clarify what kind of environment I want to work in: a team where people communicate and create synergy, rather than just doing their individual tasks. The experience of meeting passionate colleagues while staying up all night for seven months left a huge impact, and my desire to work with such people in the future has grown.
A persistent problem I struggle to fix is physical health management. I ran so hard I didn't even know when I was sleeping, and I never knew where to set the limit, constantly overworking my body.
As a non-major, the thought that "I know less than others, so I must work even harder to catch up" always weighed on my heart, and I think I tried to bridge that gap with time.
I know that to become a sustainable developer, I must move away from the method of creating results by burning myself out. Practicing how to set my own standards for compromise in situations requiring fast development is the first task I need to solve in the next stage.
Seven months ago, I was someone who watched talented people from afar, wondering, "How do they even study things like that?" Now, I have learned the way they study, and I am walking that path myself.
I do have some regrets. When colleagues asked, "What do you want to get out of this sprint?" I couldn't answer properly. Everything I was learning was so new that I didn't have the luxury to think about what was important. But now, that question is clear to me. That alone feels like enough growth.
The official activity period is over, but it feels like the real beginning because the tasks ahead are so clear. Through Boostcamp, I've found my direction in how to design, how to use AI, and what to study next.
For now, a project of about a month and a half awaits. At the same time, I plan to take time to understand myself before looking at code. The words from a coffee chat—that you must know yourself before writing a resume—keep echoing in my head.
I also plan to prepare for the Engineer Information Processing certification alongside my university studies and want to build a portfolio site that fully captures my sense of interaction and UX. There’s a lot to do, but I believe that if I break it down and finish things one by one, it will all be done eventually.
To any campers who might read this: even though Boostcamp is over, I hope we can keep sharing our progress and grow well in our respective places.
To all the campers who were with me in Boostcamp Web·Mobile 10, you all worked so hard!
