Engineering Note
Starting the Pletor Tech Blog
Our first publishing principles for using tech.pletor.kr as the source of truth in both Korean and English.
This blog is the source home for what the Pletor team learns while building products.
We publish each post in Korean and English. Both versions share the same translationKey, and each language page uses its own URL as canonical.
One important backdrop is Konduo, Pletor’s integrated operations management platform. Konduo connects infrastructure status, metric and log evidence, alert response, access control, and operating history into one flow, and this blog records the technical decisions and operating lessons we learn while building it.
Publishing principles
- Original articles are published on
tech.pletor.krfirst. - AI-written text is treated as a draft, and the final article is reviewed by the responsible engineer.
- Code examples should be runnable when possible, or at least clear enough to review.
- Security details, customer names, internal URLs, and log samples require a separate pre-publication check.
Article structure
Good engineering writing starts with reproducible context, not a dramatic conclusion.
Problem: What was difficult, and in what situation?
Approach: Which options did we consider?
Result: What improved, and what remains?
Lesson: What standard can the next teammate reuse?
At the beginning, rhythm matters more than volume. We will build the archive with small, accurate posts and organize tags and series as the collection grows.
Further Reading
For more context connected to this topic, these posts are also worth reading.
- A publishing workflow for AI-assisted engineering posts - Shows a repeatable workflow for planning and publishing AI-assisted engineering posts.
- Run Konduo Community with Docker Compose in 10 Minutes - Runs Konduo Community locally and walks through the basic product flow.
- JVM Metrics Alone Cannot Explain a Container - Explains why cgroup, filesystem, fd, and I/O signals matter beyond JVM metrics.