A record of the intense 7-week journey: from improving onboarding and infrastructure monitoring to implementing real-time sockets and 3D character optimization.
The password you enter is used to open, edit, and delete secret comments.
No comments yet.
링크 정보를 불러오는 중...
The project has finally come to an end. At the beginning, I was worried whether we could implement all the planned features in just seven weeks, but somehow, we pulled it off! Because we were running at full speed, I couldn't keep my ambitious plan of writing weekly retrospectives, but I'm recording our footsteps now.
One teammate suggested a structure similar to Duolingo, where users can experience the service without logging in. Since our project's motto is "Let's solve at least one question easily," everyone agreed. To maintain data for non-logged-in users, we utilized Local Storage. We didn't just store the number of solved questions; since the main page was a long array format, we saved the position of the last chapter solved so users could easily return to where they left off.
I handled the frontend part of the login integration using the standard Fetch API. I separated the handling of Application/JSON and Form Data and wrote the Refresh/Access token logic manually. While this used to take me a week in my first project before Boostcamp, thanks to the experience of implementing HTTP via TCP during the Challenge period, I could work while visualizing how data is carried in headers and bodies.
The Joy of Screens Emphasizing Interaction and Animation
While improving the quiz page, I implemented the effect screen for achieving a Streak. Using Framer Motion and Gemini, I realized once again that I enjoy creating screens with strong visual feedback the most, as it's the perfect environment to display my attention to detail.
Pros:
Cons:
Our service has "Mid/Final Check" stages inspired by Duolingo. Since these don't have separate questions but randomly combine previous ones, the DB design was challenging. Eventually, we introduced logic in NestJS to generate 'Steps' information separate from the DB and used orderIndex to distinguish milestones.
Based on the experience of almost ruining a demo due to build errors in Week 3, I reinforced Husky. I modified it so that a PR is only possible if it passes Lint, Format, Type Check, and Build.
| Component | Role | Description |
|---|---|---|
| Prometheus | Metric Collection | Saves server metrics chronologically |
| Grafana | Dashboard | Unified visualization of metrics/logs |
| Loki | Log Storage | Centralizes application logs |
| Promtail | Log Collection | Delivers container logs to Loki |
| Node Exporter | System Metrics | Monitors CPU/Memory/Disk |
Additionally, I introduced Loki, Grafana, Promtail, and Prometheus to solve the inconvenience of checking production logs. To succeed in the Docker deployment that failed in my individual sprint, I approached it cautiously by pre-checking the actual server. This process was significant in overcoming my fear of server access.
I independently implemented an email notification service to encourage user re-visits. I categorized conditions minutely (e.g., 5 days since joining, 1 week of inactivity) and built an unsubscription system. For security, I issued separate tokens for unsubscribe links so that only authorized users could call the API.
Looking at Technology with a Critical Eye
While introducing the ranking system, I analyzed the caching principles of Next.js and Tanstack Query. I vowed to be a developer who thinks critically about how a technology actually helps our service rather than just using what's trendy.
Pros:
Cons:
I introduced Socket.io for the real-time battle feature. To manage socket events consistently across multiple pages, I designed a dedicated Provider and Hook, encapsulating it so components only need to call the Hook. Although I had to discard my initial code and start over due to continuous errors during merging, we ended up with a scalable structure.
I spent an entire day just putting the character worked on in Blender onto the web. Texture nodes were complex, requiring me to bake them and reconnect images, and I faced issues with Rigify bones not being controlled correctly in Three.js. I realized too late that Rigified bones cannot be controlled directly in that environment. I learned the importance of step-by-step debugging to find the root cause.
While implementing the profile feature showing learning records, I faced timezone issues. I improved this by including the user's local timezone in the HTTP headers. The server now calculates and returns the correct time based on that header, making the system more robust.
Establishing Reference Points for Debugging
I realized how important it is to set a standard to determine whether a problem in the 3D pipeline lies in the model, export settings, or the Three.js code.
Pros:
Cons:
In the final week, I focused on optimization. I applied Gzip and Brotli for resource compression and used subset fonts to drastically reduce size. For the 3D character, I used a hybrid method: Shape Keys (expressions) in Three.js and body motions in Blender. I added user interactions like falling motions upon clicking and eye-tracking to complete the "Wow Point."
I received feedback that it was difficult to see selection relationships in the matching quiz. I improved the UX significantly by providing direct visual connections via SVG rendering when users select options, ensuring they feel confident in their choices.
It's a big regret that test codes weren't properly managed after the mid-point. Tests weren't updated after feature improvements, turning them into "formal passes" just for the build. In the next project, I want to adopt TDD from the design stage.
Thirst for Technical Depth
While feature implementation was perfect, I was disappointed that feedback focused mostly on visual elements. I want to actively create opportunities for "Deep Talks" about core logic and backend architecture in my next project.
Pros:
Cons:
