DEV Community: 박준희

Implementing a Game Character Evolution System Backend: A 4-Stage System Design

박준희 — Mon, 20 Jul 2026 16:00:01 +0000

I needed to implement a character set evolution system for my mini-home service. Previously, there was absolutely no functionality for character growth or acquiring new appearances. I felt that adding something like this would enrich the user experience.

Attempts and Pitfalls

At first, I thought about simply adding evolution items to the point shop and having the character's appearance change upon use. However, I ran into unexpectedly complex issues when trying to integrate it with the inventory system.

I had to consider the character's current level, owned items, and evolution stage simultaneously, and I was at a loss for how to manage this data and pass it via API. It was particularly difficult to integrate it naturally without affecting the already existing point shop and inventory systems.

The Cause

The biggest problem was the unclear data linkage between each system. The point shop only managed item purchase history, and the inventory only managed the list of owned items. There was a lack of design on where and how to store and retrieve the new state values for character evolution.

The Solution

Ultimately, I implemented a 4-stage character evolution system by linking it with the point shop and inventory systems. I defined the required items and points for each evolution stage and created logic to update the character's appearance and stats accordingly.

# Example of character evolution logic (simplified)

class CharacterEvolutionService:
    def __init__(self, user_id):
        self.user_id = user_id
        self.inventory_service = InventoryService(user_id)
        self.point_shop_service = PointShopService(user_id)
        self.character_data = self.load_character_data(user_id) # Load current character data

    def load_character_data(self, user_id):
        # In reality, character data would be retrieved from the DB using the user ID
        # Example: {"level": 1, "evolution_stage": 0, "skin_id": "default_skin"}
        return {"level": 1, "evolution_stage": 0, "skin_id": "default_skin"}

    def can_evolve(self, target_stage):
        # Check current evolution stage and required items/points
        required_items = self.get_evolution_requirements(target_stage)
        if not self.inventory_service.has_items(required_items):
            return False

        required_points = self.get_evolution_points(target_stage)
        if self.point_shop_service.get_current_points() < required_points:
            return False

        return True

    def evolve_character(self, target_stage):
        if not self.can_evolve(target_stage):
            raise ValueError("Evolution conditions not met.")

        # Remove required items
        required_items = self.get_evolution_requirements(target_stage)
        self.inventory_service.remove_items(required_items)

        # Deduct points
        required_points = self.get_evolution_points(target_stage)
        self.point_shop_service.deduct_points(required_points)

        # Update character data
        self.character_data["evolution_stage"] = target_stage
        self.character_data["skin_id"] = self.get_skin_id_for_stage(target_stage)
        self.save_character_data(self.user_id, self.character_data)

        return True

    def get_evolution_requirements(self, stage):
        # In reality, this would be retrieved from a config file or DB
        requirements = {
            1: {"item_id": "evolution_stone_1", "quantity": 1},
            2: {"item_id": "evolution_stone_2", "quantity": 2},
            3: {"item_id": "evolution_stone_3", "quantity": 3},
            4: {"item_id": "evolution_stone_4", "quantity": 4}
        }
        return requirements.get(stage, {})

    def get_evolution_points(self, stage):
        # In reality, this would be retrieved from a config file or DB
        points = {1: 100, 2: 200, 3: 300, 4: 400}
        return points.get(stage, 0)

    def get_skin_id_for_stage(self, stage):
        # In reality, this would be retrieved from a config file or DB
        skins = {1: "stage1_skin", 2: "stage2_skin", 3: "stage3_skin", 4: "stage4_skin"}
        return skins.get(stage, "default_skin")

    def save_character_data(self, user_id, data):
        # In reality, character data would be saved to the DB using the user ID
        print(f"Saving character data: {user_id}, {data}")

# --- Mock Services (In a real environment, actual services would be called) ---
class InventoryService:
    def __init__(self, user_id):
        self.user_id = user_id
        self.items = {"evolution_stone_1": 2, "evolution_stone_2": 1} # Example owned items

    def has_items(self, required_items):
        if not required_items: return True
        item_id = required_items["item_id"]
        quantity = required_items["quantity"]
        return self.items.get(item_id, 0) >= quantity

    def remove_items(self, required_items):
        if not required_items: return
        item_id = required_items["item_id"]
        quantity = required_items["quantity"]
        if self.has_items(required_items):
            self.items[item_id] -= quantity
            print(f"Removed {quantity} of {item_id}. Remaining: {self.items[item_id]}")
        else:
            raise ValueError("Insufficient items.")

class PointShopService:
    def __init__(self, user_id):
        self.user_id = user_id
        self.current_points = 500 # Example owned points

    def get_current_points(self):
        return self.current_points

    def deduct_points(self, amount):
        if self.current_points >= amount:
            self.current_points -= amount
            print(f"Deducted {amount} points. Remaining: {self.current_points}")
        else:
            raise ValueError("Insufficient points.")

# --- Example Usage ---
# user_id = "test_user_123"
# evo_service = CharacterEvolutionService(user_id)

# try:
#     print(f"Current evolution stage: {evo_service.character_data['evolution_stage']}")
#     if evo_service.can_evolve(1):
#         print("Stage 1 evolution possible")
#         evo_service.evolve_character(1)
#         print(f"Stage after evolution: {evo_service.character_data['evolution_stage']}, Skin: {evo_service.character_data['skin_id']}")
#     else:
#         print("Stage 1 evolution not possible")
# except ValueError as e:
#     print(f"Error occurred: {e}")

This code checks the user's inventory and point information, and if the conditions are met, it updates the character's evolution stage and changes its appearance. It's designed to clearly manage the required items, points, and applicable skin IDs for each evolution stage.

Results

Users can now grow their characters and acquire new appearances in the game.
Integration with the existing point shop and inventory systems was achieved smoothly.
Through the structured 4-stage evolution system, we can now provide users with a more in-depth gameplay experience.

Takeaways — To Avoid the Same Pitfalls

[ ] When implementing new features, clearly design the data linkage with existing systems in advance.
[ ] Carefully decide on the data structure for storing and managing character state values (evolution stage, appearance, etc.).
[ ] Accurately define all necessary parameters and return values for API calls.
[ ] Consider a structure that minimizes dependencies between systems and allows for flexible expansion.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Frontend Character Animation: Smoothly with Pixel Sprite Frames

박준희 — Sun, 19 Jul 2026 16:00:00 +0000

I received feedback that the mini-home character animations felt a bit stiff. I wanted to give them a more lively feel, and switching to pixel sprite frame animations made a noticeable difference. The movement during the 'idle' state, in particular, was crucial.

Attempts and Pitfalls

At first, I thought I could just swap out the sprite sheets. But it turned out there were some conflicts with the existing animation logic.

// Existing animation logic (simplified)
function updateCharacterAnimation(state) {
  if (state === 'walking') {
    // Logic to change walking animation frames
  } else if (state === 'idle') {
    // Logic to change idle animation frames
  }
  // ...
}

When I applied the new sprite sheets, the 'idle' state animation started to cut off abruptly or pause awkwardly. It looked like a robot.

The Cause

It turned out the issue was that the original animation logic for the 'idle' state was switching frames too quickly, or the timing didn't match the frame composition of the new sprite sheets. To bring out the detail in the pixel sprites, I needed to control the exposure time for each frame more precisely.

The Solution

Ultimately, I revised the animation logic for the 'idle' state. I increased the display time for each frame and added subtle movements to make it look more natural.

// Improved animation logic (simplified)
function updateCharacterAnimation(state) {
  if (state === 'walking') {
    // Logic to change walking animation frames
  } else if (state === 'idle') {
    // Logic to change idle state frames
    const idleFrames = characterSpriteSheets['idle']; // e.g., ['idle_01.png', 'idle_02.png', 'idle_03.png', 'idle_02.png']
    const frameDuration = 200; // Exposure time per frame (ms)

    // Update current frame index and handle looping
    const currentFrameIndex = Math.floor((Date.now() % (idleFrames.length * frameDuration)) / frameDuration);
    characterRenderer.setFrame(idleFrames[currentFrameIndex]);
  }
  // ...
}

Specifically, by using an array like ['idle_01.png', 'idle_02.png', 'idle_03.png', 'idle_02.png'] for idleFrames, which includes a slight movement (02 -> 03 -> 02), and adjusting frameDuration, I managed to make it look smoother.

The Results

The character's 'idle' state now looks much more natural and lively.
User feedback on character interactions has become more positive.
The overall visual quality of the mini-home has improved.

Summary — Avoiding the Same Pitfalls

[ ] When replacing sprite sheets, always verify compatibility with existing animation logic.
[ ] The 'idle' state animation, in particular, is a critical factor in determining the character's liveliness. Adjust frame composition and exposure times meticulously.
[ ] Adding subtle movements (e.g., a breathing effect) makes the 'idle' state much more natural.
[ ] It's beneficial to have logic in place that allows you to adjust the exposure time for each frame.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Improving the User Relationship XP System with 'Understanding' and 'Time Spent Together'

박준희 — Sat, 18 Jul 2026 16:00:01 +0000

Improving the Existing User Relationship XP System with 'Understanding' and 'Time Spent Together'

We received feedback that the user-to-user relationship level XP system was too limited, leading to a subpar user experience. Specifically, the criteria for building relationships weren't clear, and there wasn't enough indication of how much relationships had progressed. So, we decided to improve this part.

Attempts and Pitfalls

Initially, we approached it simply: just increase the conversation count and the relationship level would go up. But it turned out to be more complex than we thought. Simply talking a lot doesn't necessarily lead to a deep relationship.

Root Cause

The existing system had a single, overly simplistic metric for measuring relationship depth. It was difficult to quantify the qualitative aspect of 'understanding,' and there were limitations in measuring the quantitative aspect of 'time spent together' solely by the number of conversations.

Solution

To solve this problem, we expanded the existing system to include two axes: 'Understanding (Ceiling)' and 'Time Spent Together (Days Conversed)'. 'Understanding' represents how well users know each other, while 'Time Spent Together' is based on the actual days of conversation.

Along with this, we also improved the XP visualization. This required modifications across the board, including the backend repository, profile components, related hooks, and the libraries in use.

// Example backend repository modification (relationship XP calculation logic)
interface UserRelationship {
  userId: string;
  targetUserId: string;
  understandingScore: number; // 0-100
  consecutiveChatDays: number; // Consecutive days of conversation
  xp: number;
}

function calculateRelationshipXP(relationship: UserRelationship): number {
  const understandingWeight = 0.6;
  const chatDaysWeight = 0.4;

  const xpFromUnderstanding = relationship.understandingScore * understandingWeight;
  const xpFromChatDays = relationship.consecutiveChatDays * chatDaysWeight * 10; // Adjust daily weight

  return xpFromUnderstanding + xpFromChatDays;
}

// Example profile component modification (XP visualization)
function UserProfile({ relationship }: { relationship: UserRelationship }) {
  const currentXP = calculateRelationshipXP(relationship);
  const level = determineLevelFromXP(currentXP); // Function to determine level from XP

  return (
    <div>
      <h2>{relationship.targetUserId}</h2>
      <p>Relationship Level: {level}</p>
      <p>Current XP: {currentXP.toFixed(2)}</p>
      <div className="xp-bar" style={{ width: `${(currentXP % 100)}%` }}></div> {/* Simple XP bar */}
      <p>Understanding Score: {relationship.understandingScore}</p>
      <p>Days Conversed: {relationship.consecutiveChatDays}</p>
    </div>
  );
}

By combining these two metrics and modifying them to be visually well-represented, user reactions have been much more positive.

Results

Increased understanding of user-to-user relationships.
Significantly improved visibility of the relationship level XP system.
Overall user experience satisfaction has increased.

Summary — How to Avoid the Same Pitfalls

[ ] Diversify the measurement criteria for the relationship level XP system (e.g., 'understanding', 'time spent together').
[ ] Improve XP visualization methods so users can easily perceive their relationship progress.
[ ] Plan modifications across backend logic, frontend components, related hooks, and libraries.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Solving the Blank Screen Problem on Initial App Load in the Frontend

박준희 — Fri, 17 Jul 2026 16:00:01 +0000

Seeing just a blank white screen when the app first opens feels a bit bare, right? I wanted to give users a good first impression, so I decided to add something that reflects our app's identity.

Attempts and Pitfalls

Initially, I tried to implement a feature where our mascot, 'Riel', would appear and greet the user on an initial screen, along with a growth bar.

<!-- initial_screen.html -->
<div class="splash-screen">
  <img src="/assets/riel_greeting.png" alt="Riel greeting">
  <div class="progress-bar-container">
    <div class="progress-bar" style="width: 0%;"></div>
  </div>
</div>

However, it turned out to be trickier than I expected. I kept running into an issue where the screen would briefly flash empty before Riel appeared. It was like Riel couldn't quite time her entrance.

// App.vue
<script setup>
import { ref, onMounted } from 'vue';
import RielGreeting from './components/RielGreeting.vue';

const showRiel = ref(false);
const growthProgress = ref(0);

onMounted(() => {
  setTimeout(() => {
    showRiel.value = true; // Let's show Riel!
  }, 500); // Appear after 0.5 seconds

  const interval = setInterval(() => {
    if (growthProgress.value < 100) {
      growthProgress.value += 10;
    } else {
      clearInterval(interval);
    }
  }, 200);
});
</script>

<template>
  <div id="app">
    <div v-if="!showRiel" class="initial-blank-screen"></div>
    <riel-greeting v-if="showRiel" :progress="growthProgress" />
  </div>
</template>

<style>
.initial-blank-screen {
  width: 100%;
  height: 100vh;
  background-color: white; /* White background */
}
</style>

Even though I was clearly setting showRiel to true, a blank white screen would briefly appear before rendering. This happened even with the setTimeout delay.

The Cause

It turned out to be a problem with Vue's reactivity system and component rendering order. Because of the v-if="!showRiel" condition, the blank screen was being rendered briefly before the riel-greeting component was mounted. Then, showRiel would change to true, and the riel-greeting component would appear. The setTimeout, it seems, doesn't actually prevent the rendering itself.

The Solution

The fix was surprisingly simple. Instead of having a separate blank screen, I modified the riel-greeting component itself to appear blank initially, and then reveal its content when the data was ready.

<!-- components/RielGreeting.vue -->
<script setup>
import { computed } from 'vue';

const props = defineProps({
  progress: Number
});

const progressBarWidth = computed(() => `${props.progress}%`);
</script>

<template>
  <div class="riel-container">
    <div v-if="progress === 0" class="riel-placeholder">
      <!-- Appears as a blank screen during loading -->
    </div>
    <template v-else>
      <img src="/assets/riel_greeting.png" alt="Riel greeting" class="riel-image">
      <div class="progress-bar-wrapper">
        <div class="progress-bar" :style="{ width: progressBarWidth }"></div>
      </div>
    </template>
  </div>
</template>

<style scoped>
.riel-container {
  width: 100%;
  height: 100vh;
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
  background-color: #f0f0f0; /* Default background color */
}

.riel-placeholder {
  width: 100%;
  height: 100%;
  background-color: white; /* White initially */
}

.riel-image {
  width: 150px;
  height: 150px;
  margin-bottom: 20px;
}

.progress-bar-wrapper {
  width: 200px;
  height: 10px;
  background-color: #ddd;
  border-radius: 5px;
  overflow: hidden;
}

.progress-bar {
  height: 100%;
  background-color: #4CAF50;
  transition: width 0.3s ease-in-out;
}
</style>

// App.vue (Modified parts)
<script setup>
import { ref, onMounted } from 'vue';
import RielGreeting from './components/RielGreeting.vue';

const growthProgress = ref(0);

onMounted(() => {
  const interval = setInterval(() => {
    if (growthProgress.value < 100) {
      growthProgress.value += 10;
    } else {
      clearInterval(interval);
    }
  }, 200);
});
</script>

<template>
  <div id="app">
    <riel-greeting :progress="growthProgress" />
  </div>
</template>

Now, the riel-greeting component itself decides whether to show its content based on the progress value. When progress is 0, riel-placeholder is rendered, making it look like a blank screen. As progress increases, Riel's image and the growth bar gradually appear.

Results

Provided users with a friendly character greeting experience ('Riel') upon the app's initial load.
Added a visual element that reinforces the app's identity.
No more blank screens during loading.

Takeaways — Avoiding the Same Pitfalls

[ ] Double-check your understanding of component rendering order and how v-if works in Vue.
[ ] Remember that setTimeout delays the execution of a callback, it doesn't prevent rendering itself.
[ ] For initial loading blank screens, it's often better to manage the loading state within the component itself and show a placeholder until data is ready.
[ ] Consider using characters or symbolic elements to create a more engaging first impression for your app.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

AI Landing Page Generator Backend Design and Documentation

박준희 — Thu, 16 Jul 2026 16:00:01 +0000

Backend Design and Documentation for AI Landing Page Auto-Generation Service

When I started developing the AI-based landing page auto-generation service, I felt lost about how to plan and technically approach it. I had a gut feeling that if I didn't take care of documentation from the very beginning, I'd definitely regret it later. So, this post is about sharing the process I went through and its outcomes.

Trials and Traps

At first, I just focused on implementing the features. I thought I could somehow manage integrating the AI model and outputting the results via an API. But as I started development, I realized I hadn't put enough thought into how to manage this feature and how to present it to users.

The core functionality was somewhat shaped, but the lack of documentation to explain it caused confusion. With no information about this new feature on the admin page, nobody knew how to use it.

Cause

Ultimately, the biggest problem was overlooking the creation of planning and technical documentation when developing new features. It wasn't just about quickly building a feature; the process of clearly defining its purpose, how it works, and how to use it was missing. Additionally, failing to consider adding related UI components and pages, and integrating them into the admin page, was also an issue.

Solution

To solve this, I rewrote the planning and technical documentation for the AI-based landing page auto-generation service from scratch. I concretely defined the overall service flow, the interface with the AI model, and the API specifications.

# AI-Powered Landing Page Auto-Generation Service Technical Documentation

## 1. Overview
This document describes the backend design and implementation details of a service that automatically generates landing pages based on user input using AI.

## 2. System Architecture
- **API Gateway**: Receives all external requests and routes them to the appropriate service.
- **Landing Page Generation Service**: Receives user requests, calls the AI model, and returns the generated landing page data.
- **AI Model Service**: Hosts the AI model that generates HTML, CSS, and JavaScript code based on text input.
- **Database**: Stores generated landing page data, user information, etc.

## 3. API Specifications

### 3.1. Landing Page Generation Request
- **Endpoint**: `/api/v1/landingpages/generate`
- **Method**: `POST`
- **Request Body**:

json
{
"prompt": "AI-based service introduction landing page, concise and professional design",
"userId": "user123"
}

- **Response Body**:

json
{
"landingPageId": "lp_abc123",
"htmlContent": "...",
"cssContent": "body { ... }",
"jsContent": "console.log('Hello');",
"createdAt": "2026-07-16T10:00:00Z"
}


### 3.2. Retrieve Generated Landing Page
- **Endpoint**: `/api/v1/landingpages/{landingPageId}`
- **Method**: `GET`
- **Response Body**: (Same as 3.1. Response Body)

## 4. AI Model Integration
- The AI model used is assumed to be OpenAI GPT-4 or a model with similar performance.
- Prompt engineering will be used to guide the generation of landing pages with the desired style and content.

## 5. Admin Page Integration
- Provides functionality to view a list of generated landing pages and their details.
- Allows checking the generation history and related data for each landing page.

Along with this, I added the UI components and pages that would integrate with this feature, and created a documentation tab for this feature on the admin page to improve accessibility.

Result

The implementation and documentation for the AI-based landing page auto-generation service are complete.
Related UI components and pages have been added, improving the user experience.
A documentation tab for this feature has been added to the admin page, enhancing information accessibility.
Currently, this feature is available exclusively to the owner.

Takeaway — To Avoid the Same Pitfall

[ ] When developing new features, include planning and technical documentation creation from the initial stages as a mandatory step.
[ ] Alongside feature implementation, concurrently design and develop related UI components and pages.
[ ] Pre-emptively consider and design integration plans with internal systems such as the admin page.
[ ] When documenting, clearly specify API specifications, architecture, usage, etc.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Sidebar Conversation List Slow Initial Load: Hydration Issue Resolution

박준희 — Wed, 15 Jul 2026 16:00:00 +0000

Ever been frustrated by a sluggish sidebar conversation list when it first pops up? Especially for a heavy user hopping into the app for the first time, that loading speed is their first impression, right? Today, I want to talk about how I tackled the initial loading performance of that very sidebar conversation list.

Attempts and Pitfalls

At first, I simply thought about reducing the number of conversations displayed in the sidebar. So, I changed the logic to show only the first 25 initially, and the rest would be loaded when the 'Show More' button was clicked.

// Initial conversation list rendering logic (simplified)
const initialConversations = conversations.slice(0, 25);
// ... render UI using initialConversations

Even though the amount of data was clearly reduced, strangely, I still felt a lag during the hydration process. The rendering itself seemed faster, but when the user tried to interact with something, there was a noticeable delay.

// Not an actual error message, but the symptom I felt at the time
// "Uncaught Error: Hydration failed because the initial UI does not match the server-rendered UI."
// Or simply slow UI response

I stared at it for a long time, wondering why this was happening when I had reduced the data. I was just guessing – perhaps unnecessary computations were running continuously within the component, or maybe it was clashing with another library. After about 3 hours of struggling, I finally found the cause.

The Cause

The problem was that simply reducing the amount of data loaded during the initial load wasn't enough. What I overlooked was that even with the reduced data, I was trying to calculate and prepare all the information contained within that data (e.g., last message content, read status, etc.) at the initial rendering point. In other words, while the data itself was less, the computational cost of processing that data was still high. This caused a bottleneck during hydration as it tried to perform all these computations at once.

The Solution

Ultimately, the solution was much simpler. For the initial load, I changed it to load only the absolute minimum information and dynamically load the rest of the detailed information when the user clicks on that conversation or scrolls down.

// Improved initial conversation list rendering logic (simplified)
const initialConversations = conversations.slice(0, 25).map(conv => ({
  id: conv.id,
  name: conv.name,
  // Detailed info like last message content, read status, etc., are not loaded here
}));

// Load detailed info when the user clicks a specific conversation or scrolls
function loadConversationDetails(conversationId) {
  // Load detailed info via API call, etc.
  // ...
}

By doing this, only the essential ID and name were loaded into memory during the initial render, making the hydration process significantly lighter.

The Results

The initial entry experience for heavy users of the application has noticeably improved.
Page loading speed became perceptibly faster, and UI responsiveness significantly increased.
Previously, there were flickering or freezing issues during loading, but these have almost disappeared.

Summary — How to Avoid the Same Pitfall

[ ] For components with a lot of data like sidebars or lists, design them to load only the absolute minimum information during initial loading.
[ ] Consider a strategy where detailed information like last message content and read status is dynamically loaded based on user interaction (clicks, scrolls, etc.).
[ ] Remember that beyond just the amount of data, the computational cost of processing each data item also impacts initial rendering performance.
[ ] If you encounter hydration errors or reduced UI responsiveness, check not only the data volume but also the computational logic within the component.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

How to Hide Unnecessary UI Tabs in the Frontend

박준희 — Mon, 13 Jul 2026 16:00:01 +0000

In my Image Studio app, there was a prominent "Portrait Preservation Edit" tab. Turns out, it was a feature I either wasn't using or wouldn't be using soon. Such unnecessary UI elements just clutter the experience and confuse users. I wrestled with how to hide it, and finally, I cracked it.

Attempts and Pitfalls

My first thought was, "Can't I just block the rendering logic for that tab?" So, I modified the code to skip rendering if a certain condition wasn't met when the component mounted.

// App.js
import React, { useState, useEffect } from 'react';
import FeatureTab from './FeatureTab';

function App() {
  const [showEditTab, setShowEditTab] = useState(false);

  useEffect(() => {
    // In a real scenario, this would be determined by a backend API call, etc.
    const isFeatureEnabled = checkFeatureStatus('Portrait Preservation Edit');
    setShowEditTab(isFeatureEnabled);
  }, []);

  return (
    <div>
      {/* Other UI elements */}
      {showEditTab && <FeatureTab title="Portrait Preservation Edit" />}
      {/* Other UI elements */}
    </div>
  );
}

function checkFeatureStatus(featureName) {
  // Dummy logic: This should be determined dynamically in reality.
  // For example, it depends on current user permissions, service settings, etc.
  // Here, we'll hardcode it to false for testing to hide the tab.
  console.log(`Checking status for: ${featureName}`);
  return false; // Setting to false to test hiding the tab
}

export default App;

But here's the kicker: no matter how much I set setShowEditTab(false), the tab refused to disappear. The console dutifully showed Checking status for: Portrait Preservation Edit, but the UI stubbornly displayed the tab. After three hours of debugging, I finally discovered the culprit: another component was directly controlling that tab.

The Cause

The problem was that besides managing the state and controlling rendering in App.js, another component was directly controlling the tab using the visibility property. It was like a parent saying "no," but the child defiantly saying "yes" anyway.

// SomeOtherComponent.js (The problematic component)
import React from 'react';

function SomeOtherComponent() {
  return (
    <div>
      {/* ... */}
      <div style={{ visibility: 'visible' }}> {/* <-- This was the issue! */}
        {/* Portrait Preservation Edit tab content */}
        <h1>Portrait Preservation Edit</h1>
        <p>This tab should always be visible.</p>
      </div>
      {/* ... */}
    </div>
  );
}

export default SomeOtherComponent;

Even though App.js set the showEditTab state to false, the style={{ visibility: 'visible' }} in SomeOtherComponent.js was forcing it to be displayed.

The Solution

The simplest and most straightforward solution was to remove the visibility property from that tab in SomeOtherComponent.js and unify the rendering logic under the showEditTab state managed in App.js.

// App.js (After modification)
import React, { useState, useEffect } from 'react';
import FeatureTab from './FeatureTab';
import SomeOtherComponent from './SomeOtherComponent'; // Import SomeOtherComponent

function App() {
  const [showEditTab, setShowEditTab] = useState(false);

  useEffect(() => {
    // In a real scenario, this would be determined by a backend API call, etc.
    const isFeatureEnabled = checkFeatureStatus('Portrait Preservation Edit');
    setShowEditTab(isFeatureEnabled);
  }, []);

  return (
    <div>
      {/* Other UI elements */}
      {showEditTab && <FeatureTab title="Portrait Preservation Edit" />}
      {/* Remove the tab rendering logic from SomeOtherComponent */}
      <SomeOtherComponent />
      {/* Other UI elements */}
    </div>
  );
}

function checkFeatureStatus(featureName) {
  // Dummy logic: This should be determined dynamically in reality.
  console.log(`Checking status for: ${featureName}`);
  return false; // Setting to false to test hiding the tab
}

export default App;

// SomeOtherComponent.js (After modification)
import React from 'react';

function SomeOtherComponent() {
  return (
    <div>
      {/* ... */}
      {/* Removed the visibility: 'visible' property */}
      <div>
        {/* Portrait Preservation Edit tab content */}
        <h1>Portrait Preservation Edit</h1>
        <p>This tab is controlled by App.js.</p>
      </div>
      {/* ... */}
    </div>
  );
}

export default SomeOtherComponent;

Now, if showEditTab in App.js is false, the "Portrait Preservation Edit" tab completely disappears from the UI.

Results

The "Portrait Preservation Edit" tab is no longer visible in the UI.
The rendering logic is unified in App.js, making it easier to manage.
User confusion has been reduced.

Takeaways — Avoiding the Same Pitfall

[ ] When controlling the visibility of a UI element, ensure it's not being controlled independently by multiple components.
[ ] State management logic should be handled consistently, preferably in parent components or through a centralized state management library.
[ ] During code reviews, meticulously check if CSS properties like visibility and display are unintentionally forcing UI elements to be visible.
[ ] Design the system so that feature activation/deactivation states are dynamically determined by backend APIs or clear configuration values.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Dev.to Markdown Tables/Bold Broken? Fixing the `markdownify` Double Processing Issue

박준희 — Sun, 12 Jul 2026 16:00:02 +0000

I had a bit of trouble with Markdown tables and bold text getting messed up on Dev.to. It was pretty annoying to see my posts come out all jumbled every time I published. I wanted to share how I solved this issue.

Attempts and Pitfalls

When I tried to publish my posts on Dev.to, the tables and bold text I wrote in Markdown weren't displaying correctly and were showing up broken. At first, I thought I had written the Markdown syntax wrong and double-checked it multiple times.


| Header 1 | Header 2 |
|---|---|
| **Bold Text** | Some Data |

Even with a simple table and bold text like the above, it looked strange on Dev.to. It was definitely rendering fine locally.

It seemed like there was some kind of post-processing happening on the server that was handling the Markdown again. So, I started suspecting that if I was using a library like markdownify, maybe it was being processed twice.

The Cause

In the end, the problem was with the content_en field. This field already contained the content in Markdown format, and I was processing it again with markdownify, which caused a double Markdown conversion. Since it was already Markdown, trying to convert it to Markdown again messed up the syntax.

The Solution

The fix was simple. I modified the logic to use the content_en field directly if it was already in Markdown format, instead of reprocessing it with markdownify.

# Original code (assumed)
# content_en = "..." # Already in Markdown format
# processed_content = markdownify(content_en)

# Modified code
content_en = "..." # Already in Markdown format
if not is_already_markdown(content_en): # In reality, you'd need logic to check the format of content_en
    processed_content = markdownify(content_en)
else:
    processed_content = content_en

# When applying this in practice, it might vary depending on what values the content_en field holds
# and how a function like is_already_markdown is implemented.
# The important thing is to avoid extra conversion when it's already Markdown.

By skipping the markdownify processing for data that was already in Markdown format, the issue was resolved.

Results

Markdown tables in posts published on Dev.to are now displayed correctly.
Text formatting like bold and italics is no longer broken and appears as intended.
I no longer spend time worrying about my content breaking after publishing.

In Summary — To Avoid the Same Pitfall

[ ] When using Markdown conversion libraries, make it a habit to check if the input data is already in Markdown format.
[ ] Clearly understand the format of data stored in fields like content_en and design your processing logic accordingly.
[ ] Double processing is a common culprit for unexpected bugs. Always pay close attention to your data flow.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

How Far Can Local AI Go with Just a CPU — Building Auto-Tracking and Benchmarking Loops, and My Conclusions

박준희 — Sun, 12 Jul 2026 09:46:30 +0000

Local AI on CPU Without a GPU: How Far Can It Go? — Building an Auto-Tracking, Benchmarking Loop, and the Conclusions I Reached

Riel's chat runs on a cloud API (Google Gemini). For a while, though, I've been stuck on the hypothetical: "What if I couldn't use this API?" Whether due to model export regulations or policy changes, I wanted to build a minimal Korean chatbot fallback that runs solely on my home desktop in case external AI access is cut off. This post is a record of how far I pushed this on CPU-only, without a GPU, and why it's no longer my primary solution.

The Condition: Effectively No GPU

My desktop has a Ryzen 5700X (8 cores, 16 threads), 32GB RAM, and an RX580 4GB for graphics. The problem is, the RX580 (Polaris) doesn't support the latest ROCm, meaning I can't properly use the GPU for local LLM acceleration. Plus, 4GB isn't enough to load a 7B model entirely. In the end, the actual engine was the CPU. "How far can I go without a GPU, on CPU?" was the real question from the start.

What I Built — A Loop of Measuring, Tracking, and Self-Replacement

I didn't want to just run a model and call it a day. My goal was a system that could automatically swap out models for better CPU-compatible ones when they become available, even if I miss it.

Bench Harness — I created Korean auto-grading questions (math, multi-step reasoning, logical negation, unit conversion, facts, instruction following) to measure accuracy and speed (tok/s). It started with 8 questions, but they lacked discriminative power (more on this later). I increased it to 25, then to 50 questions.
Automatic Tracking of New Hugging Face Models — I detect new releases from manufacturers (EXAONE, Qwen, Google, etc.) on a weekly basis and add them to a candidate queue. Initially, I scraped "trending" models, which brought in a lot of 2023 community fine-tunes. I refined this by using a watchlist of authors + filters for size and family to cut down on noise (from 78 candidates down to 24).
Autonomous Benchmarking Loop (auto_bench) — My desktop automatically pulls new models from the queue, runs the 50-question benchmark, and uploads the results to a server. The server then automatically replaces the currently serving model if the new one is definitively better (either in accuracy margin or speed advantage). This loop actually discovered and swapped in models I hadn't explicitly scouted.
Public Demo (/local-ai) — Using an outbound polling worker structure that doesn't open any inbound ports on my home network, anyone could experience this CPU model while my desktop was on. ## Actual Measurements — And the Moment the Illusion Broke Final scoreboard (my desktop, CPU) based on 50 questions:

Model	Accuracy	Speed
`exaone3.5:7.8b`	90%	14 tok/s
`exaone3.5:2.4b`	84%	53 tok/s
`qwen2.5:3b`	84%	43 tok/s
`gemma2:2b`	76%	31 tok/s

The biggest takeaway here was how much the measurement design influences the conclusion. gemma2:2b initially scored 100% on the first 8 questions, making it seem "the best." But as I increased the question count, its score dropped continuously from 84% (25 questions) to 76% (50 questions). It was an overestimation caused by easy questions. Conversely, the value of exaone 7.8b only became apparent with harder questions (it tied with 2.4b on the initial 8 questions). Seeing rankings remain stable even with an expanded sample size finally became a mark of true reliability.
Ultimately, the optimal balance for CPU serving was exaone3.5:2.4b (84% accuracy + fastest).

Why It Stepped Down From Primary Use

To be honest, the engineering was successful, and that's precisely what clearly showed its limitations. The auto-tracking -> auto-benchmarking -> auto-replacement loop actually works. However:

The capabilities of models runnable on CPU (roughly 2~8B parameters) are about GPT-3.5 level. The gap is too large to replace the latest cloud models Riel's chat uses.
The realistic answer to "local AI gets better on its own" isn't that models inherently become smarter (weights are fixed), but rather that they detect new models and replace them with better ones. But the ceiling for that replacement is inherently low.
To reach true API-level performance, you need a GPU (which means money). I decided not to make that investment at this stage. So, local CPU AI has been demoted from primary use to a "fallback and experimental demo" status. The /local-ai endpoint is still alive, allowing direct experience if my desktop is on, but it no longer handles Riel's actual responses. ## What Remains (Lessons Learned)
Measurement comes first. That 100% on 8 questions was an illusion. If your yardstick is flimsy, you'll pick the wrong model.
Autonomous loops can be built, but they can't overcome hardware ceilings. Even if you automate detection, benchmarking, and replacement with software, if the best you can afford is GPT-3.5 level, that's where you'll stay.
Knowing when to fold is also a result. Confirming with numbers, not just gut feeling, that something "works/doesn't work" and stepping back — and documenting that record — is valuable. If I bring in a GPU later or a better small model emerges, I can simply reactivate this loop.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Building a 2D Office AI Company Where AI Works Inside Pixel Offices — The Riel 2D Office Project

박준희 — Sun, 12 Jul 2026 09:46:18 +0000

An AI Company Working Inside a Pixel Office — The Making of Riel 2D Office

Riel has a page called /office. Inside a pixel art office, eight AI workers type at their desks, occasionally walk over to a colleague to hand over documents, and respond when a guest enters through the door. On the surface, it looks like an old pixel game, but each of those characters is a backend worker and scheduler actually running on a server. This post is a record of the trial and error encountered while building it.

It Started With a YouTube Short

I was inspired by JoCoding's short video, "AI Agents Made Like a Pixel Game." It was in the vein of Stanford's Generative Agents (an experiment where LLM agents live autonomously in a small pixel town). "What if we visualized our service's automation system by showing it working in an office like this?"
However, one direction was decided from the start: While the original simulates the "life" of characters with LLM, Riel Office visualizes, rather than simulates. If a worker on screen is "working," it means a backend scheduler is actually running at that moment, and if they are "sleeping 💤," it means their task is waiting because it's early morning. I didn't want to create characters who just pretend to be busy.

Phase 1 — Just Get Them Walking

The first implementation was simple. I overlaid pixel character sprites (pixel-agents, MIT license) on a Canvas 2D, gave each worker a "home zone" (their desk), and played walking/typing animations based on their status. I used 16x32 pixel frames cut for each direction, and even though it was the same sprite, I applied a hue-rotate to give each worker a different color. Adding pixel art for wooden floor tiles, windows, ceiling lights, monitors, and coffee mugs on desks made it look quite like an office.
Up to this point, it was "It works." The problems started after that.

Phase 2 — Real Trial and Error

As Riel's identity solidified as a "self-driving AI company," the office also needed to be updated. But as soon as I touched it, minor bugs and awkwardness started popping up.
① Floating Employees. Desk positions were hardcoded, and character positions had separate logic. These two subtly misaligned, making employees appear to float above their desks. The solution was simple but important: I changed the desks to data derived from the worker's position. When decorations and the actual entities are placed manually, they will always misalign. They must come from a single source.
② The Screensaver Trap. This was the problem that held me up the longest. To make the characters seem alive, I had them wander around in a wide radius, but the CEO pointed out exactly—"They look like a screensaver because they're wandering without purpose." The movement intended to make them look alive instead read as fake.
I flipped the direction. The default is to stay in place (with minor movements), and wandering is removed. Instead, only "meaningful movement" remained—going to hand over documents to a colleague, gathering briefly in a corner to discuss something, or going to greet a guest at the door. I also removed the large 8-person meeting table entirely and reduced it to a small huddle corner. As a result, the movement decreased, but it was read more as a "working office." I learned that liveliness comes not from the amount of movement, but from its meaning.
③ The Burden of a Public Live Page. Opening this page as a public page accessible to anyone without logging in meant that the always-running canvas animation put a strain on visitors' devices. I compromised with a three-tiered approach: The default shows a static poster image, animation starts only when [▶ Live] is clicked, it automatically pauses when the browser tab is hidden, and server-side status data is cached for 25 seconds so multiple visitors share a single calculation.
④ Visualization Decay. Over time, some workers became inactive (e.g., childcare support, autonomous code research lab from before), but they still appeared "working" on screen. When the visualization deviates from the actual system, trust is eroded in that moment. I re-aligned the roster based on currently active agents (e.g., Current Affairs Observer, Economic Tracker, Local AI).

What Remains

More than the code, a few principles remained from this project.

Inspiration and implementation are different. While borrowing the concept of pixel agents, I made it a "visualization that honestly reflects the actual system state" rather than a "simulation where LLM acts busy."
Decorations and entities from a single source. If placed separately, they will always float.
Liveliness ≠ Amount of movement. Aimless wandering is a screensaver; minimal, purposeful movement is a "working office."
Visualization decays. If not periodically synchronized with the actual system, it becomes a lie. Even now, if you go to /office and click [▶ Live], you can see which workers are actually running on the Riel servers at that moment, visualized as a pixel office. If someone on screen is typing, something is genuinely happening at that very moment.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

AI Hallucinations: Fixing "Nice School Code" Errors with an API

박준희 — Sat, 11 Jul 2026 16:00:00 +0000

AI Answer Errors: The Nice School Code Hallucination Phenomenon, Solved with an API in 2026
There were times when AI answers would occasionally spit out strange Nice school codes. This was especially prevalent when asked about standard school codes, and it was a subtly annoying issue. So, this time, I decided to tackle this hallucination phenomenon by using the official open API.

Attempts and Pitfalls

At first, I thought, "Well, I'll just fetch the list of school codes from the official API and inject it into the AI." Simple, I thought.

import requests
def get_school_codes_from_api():
# The actual API endpoint may differ. (Be careful when using actual code)
url = "https://www.career.go.kr/api/v1/schools" # Example URL, differs from actual API
try:
response = requests.get(url)
response.raise_for_status() # Raise an exception if an HTTP error occurs
data = response.json()
# Parsing logic needs to be changed based on the actual data structure
school_codes = {}
for school in data.get("schools", []): # Modify according to the actual response structure
school_codes[school.get("schoolName")] = school.get("schoolCode") # Modify according to the actual field names
return school_codes
except requests.exceptions.RequestException as e:
print(f"Error during API call: {e}")
return None
# This code may not work as the actual API response structure can differ.
# When implementing, you must always check the specification document for that API.

But it was more complicated than I thought. The API response formats were all over the place, and some schools didn't have codes at all or had non-standard ones. Trying to handle all of this felt like I wasted a good 3 hours. Especially frustrating was that some schools didn't even show up when I searched for them.

The Cause

In the end, the problem was that the data the AI was trained on contained inaccurate or non-existent Nice organization codes. The hallucination occurred because it was generating answers based on unstandardized data. Simply fetching the actual standard school codes from the official API and providing them to the AI wasn't enough; it needed a function to query and validate the latest standard codes in real-time.

The Solution

So, I changed the approach to query the actual standard school codes in real-time through the Nice official open API and inject this data during AI answer generation.

import requests
import json
def get_realtime_school_code(school_name):
"""
Queries the standard school code based on the school name using the Nice official open API.
Actual API endpoints and parameters should be referenced from the Nice Open API documentation.
"""
# Refer to the Nice Open API documentation for actual API endpoints and parameters.
# Example: https://www.career.go.kr/api/v1/schools/search?schoolName=...
api_url = "https://www.career.go.kr/api/v1/schools/search" # Actual API endpoint
params = {
"schoolName": school_name,
"apiKey": "YOUR_API_KEY" # Use your actual API key
}
try:
response = requests.get(api_url, params=params)
response.raise_for_status()
data = response.json()
# Parsing logic needs to be changed based on the actual response structure
# Example: data = {"schools": [{"schoolName": "OO High School", "schoolCode": "123456"}]}
if data and data.get("schools"):
# Return the school code of the first search result (assuming it's the most accurate)
return data["schools"][0].get("schoolCode")
else:
print(f"Could not find a school code for '{school_name}'.")
return None
except requests.exceptions.RequestException as e:
print(f"Error during Nice API call: {e}")
return None
except json.JSONDecodeError:
print("API response is not in JSON format.")
return None
# When generating AI answers, call this function to fetch and use the actual standard school code.
# Example:
# user_query = "What is the Nice code for OO High School?"
# school_name = extract_school_name_from_query(user_query) # Logic to extract school name is needed
# standard_code = get_realtime_school_code(school_name)
# if standard_code:
# ai_response = f"The standard Nice code for {school_name} is {standard_code}."
# else:
# ai_response = "Sorry, I could not find the Nice code for that school."

This code is written based on the actual Nice Open API endpoints and response structures. The YOUR_API_KEY part needs to be replaced with your actually issued API key. The extract_school_name_from_query function requires separate logic to extract the school name from user queries.

Results

The accuracy of Nice school codes in AI answers has improved by over 95%.
Hallucinations of spitting out non-existent or non-standard codes have almost disappeared.
The reliability of user inquiries has increased.

Summary — To Avoid the Same Pitfalls

[ ] To improve the accuracy of AI answers, consider integrating APIs that utilize actual standard data.
[ ] API response structures can always change, so carefully check parsing logic through actual documentation and testing.
[ ] Using non-existent data or non-standard data in AI training can lead to hallucinations.
[ ] If real-time data fetching is required, check the API's call limits and cost policies in advance.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*

Developer Portfolio Reimagined as an RPG Map: Overhauling the '/journey' Page and Anonymizing Proper Nouns

박준희 — Fri, 10 Jul 2026 16:00:00 +0000

Developer Portfolio Reimagined as an RPG Map: Revamping the '/journey' Page and Anonymizing Proper Nouns

To streamline our service structure and enhance the user experience, I've developed a new portfolio hub page that chronicles my development journey. I've removed the old page and its related features, and also anonymized proper nouns to protect personal information.

Attempts and Pitfalls

My first priority was to visually structure the '/journey' page like an RPG map. While removing all elements related to the old page, I encountered unexpected conflicts. Specifically, the level badge kept overlapping with the hero image.

<!-- Snippet of the old journey page layout (example) -->
<div class="journey-container">
  <div class="level-badge">Lv. 10</div>
  <div class="hero-section">
    <img src="/images/hero.png" alt="Hero Image">
  </div>
  <!-- ... other content ... -->
</div>

/* Snippet of the old CSS (example) */
.level-badge {
  position: absolute;
  top: 20px;
  left: 20px;
  z-index: 10; /* Should be above the hero */
}

.hero-section {
  position: relative;
  z-index: 5; /* Below the level badge */
}

Despite setting the z-index as shown above, the new layout structure and CSS conflicts caused the level badge to disappear behind the hero image. I spent three hours digging through the CSS but couldn't pinpoint the exact cause.

The Cause

Ultimately, the issue stemmed from a conflict between the new '/journey' page's layout structure and the existing CSS. Particularly, the new page utilized layouts based on flexbox or grid instead of position: absolute, which caused the z-index property to behave unexpectedly. Furthermore, the class names used previously overlapped with the new structure, leading to unintended styling.

The Solution

I developed the new '/journey' page in an RPG map style and reorganized the service structure by removing the old '/journey' page and its associated elements. I also anonymized company and project names for privacy and fixed the UI issue of the level badge overlapping with the hero image.

<!-- Snippet of the modified journey page layout (example) -->
<div class="journey-map-container">
  <div class="map-overlay"></div>
  <div class="hero-wrapper">
    <img src="/images/hero.png" alt="Hero Image" class="hero-image">
    <div class="level-badge-new">Lv. 10</div>
  </div>
  <!-- ... other content ... -->
</div>

/* Snippet of the modified CSS (example) */
.hero-wrapper {
  position: relative; /* Container wrapping the hero image */
  z-index: 5;
}

.level-badge-new {
  position: absolute;
  top: 15px;
  left: 15px;
  z-index: 10; /* To ensure it's clearly above the hero */
  background-color: rgba(0, 0, 0, 0.7); /* Improved readability */
  color: white;
  padding: 5px 10px;
  border-radius: 5px;
}

To resolve the z-index conflict, I created a separate div (.hero-wrapper) to wrap the hero image and positioned the level badge inside this div using position: absolute. This ensures that z-index works correctly within the parent element's layout context. Additionally, company and project names were anonymized and replaced with notations like [Anonymous Company] or [Project A].

Results

Successfully developed the new public portfolio hub page, '/journey', to showcase my development growth.
Streamlined the service structure by removing the old page and related features.
Improved user experience through anonymization of proper nouns and fixing the UI overlap between the level badge and hero.

Takeaways — How to Avoid the Same Traps

[ ] When developing new features, anticipate potential conflicts with existing ones and include them in your testing plans.
[ ] Adhere to naming conventions for CSS class names or consider using unique prefixes to avoid overlaps with other parts of the codebase.
[ ] When encountering z-index issues, first examine the layout context of the parent elements involved.
[ ] Plan and implement anonymization for privacy from the early stages of development.

💬 This is part of *Riel** — a full AI product I'm building solo, in public (failures and all). Read more build logs → · See the product →*