diff --git a/content/authors/Taeseo Um/_index.en.md b/content/authors/Taeseo Um/_index.en.md new file mode 100644 index 0000000..d569359 --- /dev/null +++ b/content/authors/Taeseo Um/_index.en.md @@ -0,0 +1,7 @@ +--- +title: "Taeseo Um" +image: "https://avatars.githubusercontent.com/u/182990287?v=4" +linkedin: "https://www.linkedin.com/in/taeseoum/" +github: "https://github.com/umtaeseo11" +bio: "ML Engineer" +--- diff --git a/content/authors/Taeseo Um/_index.md b/content/authors/Taeseo Um/_index.md new file mode 100644 index 0000000..d569359 --- /dev/null +++ b/content/authors/Taeseo Um/_index.md @@ -0,0 +1,7 @@ +--- +title: "Taeseo Um" +image: "https://avatars.githubusercontent.com/u/182990287?v=4" +linkedin: "https://www.linkedin.com/in/taeseoum/" +github: "https://github.com/umtaeseo11" +bio: "ML Engineer" +--- diff --git a/content/posts/how-we-use-ai/images/test-importance.png b/content/posts/how-we-use-ai/images/test-importance.png new file mode 100644 index 0000000..cb0fd0e Binary files /dev/null and b/content/posts/how-we-use-ai/images/test-importance.png differ diff --git a/content/posts/how-we-use-ai/images/tony-stark.jpg b/content/posts/how-we-use-ai/images/tony-stark.jpg new file mode 100644 index 0000000..9df1e12 Binary files /dev/null and b/content/posts/how-we-use-ai/images/tony-stark.jpg differ diff --git a/content/posts/how-we-use-ai/images/using-ai.png b/content/posts/how-we-use-ai/images/using-ai.png new file mode 100644 index 0000000..fc46ebe Binary files /dev/null and b/content/posts/how-we-use-ai/images/using-ai.png differ diff --git a/content/posts/how-we-use-ai/index.en.md b/content/posts/how-we-use-ai/index.en.md new file mode 100644 index 0000000..f5785d8 --- /dev/null +++ b/content/posts/how-we-use-ai/index.en.md @@ -0,0 +1,119 @@ +--- +date: '2026-02-19T14:16:19+09:00' +draft: false +title: 'From Copy-Paste to Autonomous Agents: A Subtle Introduction' +cover: + image: "images/using-ai.png" + # can also paste direct link from external site + # ex. https://i.ibb.co/K0HVPBd/paper-mod-profilemode.png + alt: "Coding with AI" + caption: "Coding with AI" + relative: false # To use relative path for cover image, used in hugo Page-bundles +authors: ['Taeseo Um'] # must match with content/authors +tags: ["Agents", "AI", "Tools", "Coding"] +categories: ["Agentic Workflow"] +series: ["From Copy-Paste to Autonomous Agents"] +summary: ["How the ML team at HyperAccel started implemented AI into our development workflow."] +comments: true +--- + +# From Copy-Paste to Autonomous Coding Agents: A Subtle Introduction + +Hello, my name is Taeseo Um, currently on the ML team at HyperAccel. + +There is a running joke among developers that our job has always been about googling the issue, clicking the first link that pops up, then copying from Stack Overflow. In some ways, the arrival of AI coding tools didn't change what we do — it just made us dramatically better at it. Over the past few months, our team has ridden almost every wave of AI-assisted development, from the earliest interactions to the autonomous agents we rely on today. Here's what that journey looked like, what we learned, and where we think it's all heading. + +--- + +## The Early Days: AI as a Smarter Search Engine + +When large language models first became accessible to the world, nobody had a playbook, especially developers. The general mass treated LLMs in various ways: friend, teacher, personal therapist, a generic search engine. What about developers? The initial use case was embarrassingly simple: copy an error message, paste it into ChatGPT, and hope for a useful answer. It was Stack Overflow with a conversational interface, and honestly, it worked surprisingly well. Instead of scrolling through forum threads to find the one answer that matched your exact Python version, you could get a tailored explanation in seconds. + +From there, usage naturally expanded. Developers started asking syntax questions, requesting code snippets, and getting explanations of unfamiliar APIs. The mental model was still very much "I have this specific question, give me an answer that matches what I need.” But a subtle shift was already underway. Once people realized these models could hold context, they started feeding in larger chunks of code — sometimes entire files — and asking higher-level questions about architecture, design patterns, and debugging strategies. The AI wasn't writing all our code yet, but it was becoming a surprisingly competent pair-programming partner (one where I don’t feel embarrassed asking dumb questions to). + +--- + +## Tab Complete Changed Everything + +The real inflection point came with tools like GitHub Copilot and Cursor. Autocomplete had existed in IDEs for decades, but this was fundamentally different. Instead of suggesting variable names and method signatures, these tools were predicting entire blocks of logic. You'd start typing something, maybe even just a comment, and the rest would appear like magic. Press tab. Accept. Move on. Forget. + +It's hard to overstate how much this changed the rhythm of coding. Writing boilerplate, repetitive patterns, and standard implementations went from minutes to seconds. Developers got faster, and perhaps more importantly, they stayed in flow longer. The friction of context-switching to documentation or search engines basically vanished. + +Then the agentic experience arrived. Tools like Cursor evolved beyond simple autocomplete into something more ambitious. You could describe a problem in natural language, and the LLM / IDE would traverse your codebase, identify the relevant files, propose changes across multiple locations, and ask you to review and accept. The developer's role shifted from writing code to directing and reviewing it. It felt like having a junior engineer who could read your entire repository in milliseconds. + +--- + +## CLI Agents and the Rise of Structured AI Workflows + +As powerful as IDE-integrated tools were, we found they still lacked structure. When Cursor introduced the concept of rules — markdown files that defined coding standards, commenting conventions, and general information — we jumped on it. We added rule files to nearly every repository so that anyone using AI-assisted tooling would at least produce code that followed our team's standards. It was a simple idea with substantial impact. + +The next leap was MCPs (Model Context Protocols), which let AI tools connect to external data sources. Suddenly, an agent could pull context from our Confluence documentation, understand our internal documents, and reference design decisions that lived outside the codebase. The AI wasn't just reading code anymore — it was reading our institutional knowledge. + +However, what truly attached a rocket booster to our team’s “let’s improve productivity with AI” mindset was Claude Code. Claude Code introduced the concept of skills, which go far beyond static rules and instead enable structured, multi-step workflows. + +In one of our team repositories, we now maintain a .claude directory to manage skills for planning, feature implementation, writing tests, opening PRs, fetching and incorporating PR review comments, and more. We have also embedded platform-specific hardware constraints, anti-patterns our team learned the hard way, and SDK-specific conventions into either skills or Claude Code rules. + +We will cover in depth how we designed our Claude Code skills files and how we optimized other Claude Code use cases in future blog posts. + +The difference between rule files and skills is similar to the difference between a style guide and a “trained teammate.” +A rule says, “Use pytest, do not use unittest.” +A skill says, “Write a test suite appropriate for this type of module, execute it, automatically fix failures up to five times if needed, and summarize the results in a report.” + +Skills like /implement-tested, /pr-review, and /open-pr have transformed tasks that used to take hours into workflows that now take minutes under human supervision. + +While we had previously experimented with using LLMs for code generation, most approaches were limited to a “single prompt–single response” pattern. Claude Code’s skills allowed us to structure the entire execution flow — from planning → implementation → testing → fixing → reporting — into reusable units. In particular, they significantly reduced the cognitive load of repetitive but mentally taxing tasks, which made a tangible difference in our day-to-day productivity. + +--- + +## The Code Review Bottleneck + +![Importance of Tests](./images/test-importance.png) + +Here's the part nobody warned us about. AI and agentic tools made developers dramatically faster at writing code. Pull requests that used to take a day were being opened in an hour. But code review — the part that requires a human to carefully read, understand, and verify changes -- didn't get any faster. If anything, the bottleneck got worse. The faster code was produced, the longer the review queue grew, and the overall speed of shipping features didn't increase as much as we expected. + +We started using AI for code review in GitHub PRs, and it helped catch surface-level issues. But the deeper question remained: how do you maintain quality at higher velocity? +Our answer has been evolving. We're moving toward a model where AI agents produce a plan.md file before writing any code — a structured document outlining the approach, the files to be changed, and the reasoning behind each decision. Human reviewers then review the plan rather than scrutinizing every line of the implementation. The key constraint is that the changed code must pass a comprehensive test suite. This shifts the burden of correctness from line-by-line review to test coverage, and it stresses the importance of writing excellent tests more than ever. + +There's a critical caveat to this approach: whenever someone creates new tests or modifies existing test code, that work must be human-reviewed. Tests are the contract that makes plan-based review trustworthy. If the tests are weak or wrong, the entire workflow model breaks down. So while we're trying to gradually adopt this leaner review strategy for implementation code, test code remains firmly in the domain of careful human judgment. + +--- + +## What Does the Future Hold? + +We're still early. Not only our team, our company, but the entire software world trying to take advantage of these AI tools are still at the early stages to experience what these black boxes are truly capable of, at least that is my belief. The tools are improving monthly. You know what, no, they are improving daily. Whenever it seems like the AI workflow is stabilizing, there is always a shift. As developers, it is important to always keep an eye on these changes, always be ready to adapt. If you are not ready to adapt to these changes, you will be felt behind. You might be the best programmer in the world, but there will be someone who is a lot less talented than you in programming but knows just enough to fly past you just by knowing exactly how to take advantage of these AI tools. Our team is very open minded to AI tools and understands that this is the present and the future, and because of this collective belief, the speed of our team’s development is accelerating. We see a future where AI agents handle increasingly complex tasks and we are just there to make sure the thing that is getting done fast, is getting done right. People always talk about ‘this model’s context length’. That is important, yes. But as developers who are using these tools to do the dirty work for us, we need to be the ‘context masters’. The ones who fully get the big picture, down to the tiniest details of what needs to be done. The human role will continue shifting from writing and reviewing code toward defining intent, validating architecture, curating test suites, and making smart, fast, important judgement calls. + +The teams that will thrive are the ones investing now in the infrastructure that makes this possible: well-structured skill definitions, comprehensive test coverage, clear architectural documentation, and a culture that treats AI tooling not as a shortcut but as a force multiplier that demands new kinds of discipline. + +We're not replacing developers. We're redefining what it means to be one. + +![The Future](./images/tony-stark.jpg) + +--- + +## Upcoming... + +This post was shared as an introduction outlining the overall direction and key questions we are exploring. In future posts, I plan to cover Skills in more depth, Kernel Agent(s), and other AI tool use cases, detailing not only how to use them but also how we designed and optimized them internally. + +As the teams at HyperAccel continues to find new ways AI melts into our workflow, we will share our journey as we navigate this new paradigm of how we develop code and amazing software. + +## HyperAccel is Hiring! + +The reason why we are writing operating this tech blog is largely too attract top talent! + +If you are interest in the technologies we work with, and want to join this revolution, please apply at [HyperAccel Career](https://hyperaccel.career.greetinghr.com/ko/guide)! + +HyperAccel is full of brilliants engineers. We will be waiting. + + + + + + + + + + + + + + diff --git a/content/posts/how-we-use-ai/index.md b/content/posts/how-we-use-ai/index.md new file mode 100644 index 0000000..de879a4 --- /dev/null +++ b/content/posts/how-we-use-ai/index.md @@ -0,0 +1,116 @@ +--- +date: '2026-02-19T14:16:04+09:00' +draft: false +title: 'Copy & Paste에서 코딩 에이전트까지: 조용한 변화의 시작' +cover: + image: "images/using-ai.png" + # can also paste direct link from external site + # ex. https://i.ibb.co/K0HVPBd/paper-mod-profilemode.png + alt: "Coding with AI" + caption: "Coding with AI" + relative: false # To use relative path for cover image, used in hugo Page-bundles +authors: ['Taeseo Um'] # must match with content/authors +tags: ["Agents", "AI", "Tools", "Coding"] +categories: ["Agentic Workflow"] +summary: [“HyperAccel의 ML 팀이 어떻게 개발 워크플로우에 AI를 도입했는가”] +series: ["Copy & Paste에서 코딩 에이전트까지"] +comments: true +--- + +# Copy & Paste에서 자율 코딩 에이전트까지: 조용한 변화의 시작 + +안녕하세요, 하이퍼엑셀 ML 팀 엔지니어 엄태서입니다. + +개발자들 사이에는 이런 농담이 있습니다. “우리 일은 결국 문제를 구글에 검색하고, 첫 번째로 뜨는 링크를 눌러서, Stack Overflow에서 답을 복사해 붙여넣는 거 아니냐?” +어떤 면에서는 AI 코딩 도구의 등장이 우리가 하는 일을 완전히 바꾼 건 아닙니다. 다만 **그 일을 훨씬 더 잘, 훨씬 더 빠르게** 하게 만들었죠. 지난 몇 달 동안 우리 팀은 AI 보조 개발의 거의 모든 물결을 직접 타 봤습니다. 초기의 단발성 상호작용부터, 지금은 사실상 일상적으로 의존하는 **자율 에이전트**까지요. 이 글에서는 그 여정이 어떤 모습이었는지, 무엇을 배웠는지, 그리고 앞으로 어디로 향하고 있다고 생각하는지 정리해 보려고 합니다. + +--- + +## 초창기: AI는 더 똑똑한 검색 엔진이었다 + +대형 언어 모델(LLM)이 처음 대중에게 열렸을 때, 특히 개발자들에게는 “정답”이나 “정석”이 없었습니다. 대부분 사람들은 LLM을 친구, 선생님, 개인 상담가, 혹은 그냥 새로운 검색 엔진처럼 다양하게 사용했죠. 그럼 개발자들은 어땠을까요? 초창기 사용 사례는 솔직히 말해 **조금 민망할 정도로 단순**했습니다. 에러 메시지를 복사해서 ChatGPT에 붙여넣고, 유용한 답이 나오길 기대하는 것 이였죠. + +그 경험은 “대화형 Stack Overflow”에 가까웠지만, 놀랍게도 꽤 잘 작동했습니다. 예전에는 forum thread를 한참 스크롤하면서 “내 Python 버전과 정확히 맞는 답” 하나를 찾기 위해 시간을 썼다면, 이제는 몇 초 만에 상황에 맞춘 설명을 받을 수 있으니까요. + +그 다음부터는 사용경험이 자연스럽게 확장됐습니다. 개발자들은 문법 질문을 하고, 코드 snippet을 요청하고, 익숙하지 않은 API에 대한 설명을 받기 시작했습니다. 이때의 멘탈 모델은 여전히 “내가 특정 질문을 하면, 내 상황에 맞는 답을 준다”에 가까웠습니다. 하지만 미묘한 변화가 이미 진행되고 있었죠. 모델이 **컨텍스트를 유지할 수 있다**는 걸 깨닫자, 더 큰 코드 덩어리(때로는 파일 전체)를 넣고 아키텍처, 디자인 패턴, 디버깅 전략 같은 **상위 레벨의 질문**을 하기 시작했습니다. 아직 AI가 모든 코드를 쓰는 단계는 아니었지만, 점점 꽤 유능한 페어 프로그래밍 파트너가 되어가고 있었습니다. (무엇보다… 어떠한 질문을 해도 덜 민망한 상대였죠.) + +--- + +## 탭 자동완성이 모든 것을 바꿨다 + +진짜 변곡점은 GitHub Copilot, Cursor 같은 도구들이 등장하면서였습니다. IDE 자동완성은 수십 년 전부터 존재했지만, 이건 근본적으로 달랐습니다. 변수명이나 메서드 시그니처를 제안하는 수준이 아니라, **코드 logic 전체를 예측**하기 시작했으니까요. 뭔가를 조금 입력하거나, 심지어 주석 한 줄만 적어도 나머지가 마치 마법처럼 나타났습니다. Tab을 누르고, 수락하고, 넘어갑니다. (가끔은 “잊어버리고” 계속 진행하죠.) + +이 변화가 코딩의 리듬을 얼마나 바꿨는지는 과장하기 어렵습니다. 보일러플레이트, 반복 패턴, 표준 구현을 작성하는 시간이 분 단위에서 초 단위로 줄었습니다. 개발자들은 더 빨라졌고, 더 중요한 변화는 **플로우(flow) 상태를 더 오래 유지**하게 되었다는 점입니다. 문서나 검색 엔진으로 이동하며 컨텍스트가 끊기던 마찰이 거의 사라졌습니다. + +그리고 그 다음은 “에이전트적인 경험(agentic experience)”의 등장입니다. Cursor 같은 도구들은 단순 자동완성을 넘어 더 야심찬 방향으로 진화했습니다. 자연어로 문제를 설명하면 LLM/IDE가 코드베이스를 훑고, 관련 파일을 찾아내고, 여러 곳에 걸친 변경을 제안한 뒤, 내가 검토하고 수락하길 요청합니다. 개발자의 역할은 “코드를 작성하는 사람”에서 “코드를 **지시하고 검토하는 사람**”으로 이동하기 시작했습니다. 마치 레포지토리를 밀리초 단위로 읽고 (거의) 전부 다 이해해버리는 주니어 엔지니어가 생긴 느낌이랄까요. + +--- + +## CLI 에이전트와 구조화된 AI 워크플로우의 부상 + +IDE 통합 도구들이 강력하긴 했지만, 우리는 곧 한계를 느꼈습니다. **구조(Structure)가 부족**했던 겁니다. Cursor가 rules(룰)이라는 개념—코딩 표준, 코멘팅 컨벤션, 일반 정보 등을 정의하는 마크다운 파일—을 도입했을 때 우리 팀도 바로 도입했습니다. 거의 모든 레포지토리에 룰 파일을 추가해, AI 보조 도구를 사용하더라도 최소한 팀 표준을 따르는 코드가 나오게 만들었죠. 단순한 아이디어였지만 효과는 상당했습니다. + +다음 도약은 MCP(Model Context Protocols)였습니다. MCP는 AI 도구가 외부 데이터 소스에 연결될 수 있게 해줍니다. 갑자기 에이전트가 Confluence 문서에서 컨텍스트를 가져오고, 내부 문서를 이해하고, 코드 밖에 있던 설계 의사결정까지 참조할 수 있게 된 겁니다. AI는 이제 코드만 읽는 게 아니라 **조직의 지식(기관 기억, institutional knowledge)** 을 읽기 시작했습니다. + +하지만 “AI로 생산성을 올려보자”라는 우리 팀의 엔진에 진짜 로켓 부스터를 단 건 Claude Code였습니다. Claude Code는 skills(스킬)이라는 개념을 도입했는데, 이는 정적인 rules를 훨씬 뛰어넘는 구조화된 다단계 워크플로우입니다. 저희 팀 레포 중 하나에서는 이제 .claude 디렉토리를 두고, 계획 수립, 기능 구현, 테스트 작성, PR 오픈, PR 리뷰 코멘트 가져와 반영하기 같은 스킬들을 관리하고 있습니다. 또한 플랫폼에 특화된 하드웨어 제약, 팀이 trial and error로 배운 안티패턴, SDK별 컨벤션 같은 것도 스킬 또는 Claude Code rules로 녹여두었습니다. + +저희가 사용해 온 Claude Code skills 파일을 어떻게 만들었는지, 그리고 기타 Claude Code 활용 사례를 어떻게 최적화했는지에 대한 자세한 내용은 향후 블로그 게시물에서 심도 있게 다룰 예정입니다. + +룰 파일과 스킬의 차이는, 스타일 가이드와 “훈련된 동료”의 차이에 가깝습니다. +룰은 “pytest를 써라, unittest는 쓰지 마라”라고 말합니다. +스킬은 “이 유형의 모듈에 맞는 테스트 스위트를 작성하고, 실행하고, 실패하면 최대 다섯 번까지 자동 수정하고, 결과를 요약 보고하라”라고 말합니다. + +/implement-tested, /pr-review, /open-pr 같은 스킬은 과거에 몇 시간이 걸리던 작업들을, 인간의 감독 하에 몇 분 단위의 작업으로 바꿔놓았습니다. + +기존에도 LLM을 활용해 코드 생성을 시도해 왔지만, 대부분은 “한 번의 요청–한 번의 응답” 구조에 머물러 있었습니다. Claude Code의 skills는 계획 → 구현 → 테스트 → 수정 → 보고까지 이어지는 실행 흐름 전체를 하나의 재사용 가능한 단위로 구조화할 수 있었고, 특히 반복적이지만 인지 부하가 큰 작업을 안정적으로 압축해 주었다는 점에서 체감 생산성에 큰 차이를 만들었습니다. + +--- + +## 코드 리뷰 병목: 아무도 경고해주지 않았던 부분 + +![테스트의 중요성](./images/test-importance.png) + +아무도 미리 말해주지 않았던 문제가 있습니다. AI와 에이전트 도구들이 개발자를 엄청나게 빠르게 만들었습니다. 하루 걸리던 PR이 한 시간 만에 열리기 시작했죠. 그런데 코드 리뷰—사람이 꼼꼼히 읽고 이해하고 검증해야 하는 단계—는 빨라지지 않았습니다. 오히려 병목은 더 심해졌습니다. 코드 생산 속도가 빨라질수록 리뷰 대기열이 길어지고, 진짜 개발 속도는 저희가 기대한 만큼 늘지 않았습니다. + +GitHub PR에서 AI를 활용해 surface-level 문제들을 잡는 데 도움을 받았지만, 더 근본적인 질문은 남았습니다. **더 높은 속도에서 품질을 어떻게 유지할 것인가?** + +그 질문에 대한 답은 계속 진화 중이지만, 최근에는 이런 workflow 모델로 움직이고 있습니다. AI 에이전트가 코드를 작성하기 전에 먼저 `plan.md` 파일을 생성합니다. 이는 접근 방식, 변경할 파일들, 각 결정의 이유를 구조적으로 담은 문서입니다. 이후 사람 리뷰어는 구현 코드의 모든 라인을 샅샅이 보는 대신 **계획(plan)을 리뷰**합니다. 핵심 제약은 변경된 코드가 **포괄적인 test suite**를 통과해야 한다는 점입니다. 이렇게 하면 정확성의 부담이 라인 단위 리뷰에서 테스트 커버리지로 이동하고, 결과적으로 “좋은 테스트”의 중요성이 그 어느 때보다 커집니다. + +다만 여기에는 결정적인 단서가 있습니다. **새 테스트를 만들거나 기존 테스트 코드를 수정하는 작업은 반드시 사람이 리뷰해야 합니다.** 테스트는 plan 기반 리뷰 모델을 신뢰할 수 있게 만드는 계약(Contract)입니다. 테스트가 약하거나 잘못되면 워크플로우 전체가 무너집니다. 그래서 구현 코드에 대해서는 점진적으로 더 ‘가벼운’ 리뷰 전략을 도입하려고 하지만, 테스트 코드는 여전히 신중한 인간 판단의 영역으로 남겨두고 있습니다. + +--- + +## 미래는 어떻게 될까? + +저희 팀, 저희 회사뿐만 아니라, 저는 전 세계가 아직도 초기 단계에 있다고 믿습니다. 도구는 매달 좋아집니다. 아니, 솔직히 말해 **매일 좋아집니다.** AI 워크플로우가 안정화되는 것 같다가도, 언제나 또 다른 변화가 찾아옵니다. 개발자로서 중요한 건 이 변화들을 계속 주시하고, 계속 적응하는 것입니다. 적응할 준비가 되어 있지 않다면, 뒤처지게 됩니다. 세상에서 가장 뛰어난 프로그래머일지라도, AI 도구를 “어떻게 활용해야 하는지”를 아는 사람이 훨씬 빠르게 앞질러갈 수도 있습니다. 우리 팀은 AI 도구가 현재이자 미래라는 점을 이해하고 매우 열린 태도를 갖고 있고, 그 공통된 믿음 덕분에 팀의 개발 속도는 실제로 가속되고 있습니다. + +우리가 보는 미래는 이렇습니다. AI 에이전트가 점점 더 복잡한 일을 처리하고, 우리는 그저 “빨리 되는 것”이 아니라 **빠르게 진행되면서도 제대로 되고 있는지**를 확인하는 역할에 더 집중하게 될 겁니다. 사람들은 항상 “이 모델의 컨텍스트 길이”를 이야기합니다. 물론 중요합니다. 하지만 현장에서 이 도구들을 활용해 ‘더러운 일’을 맡기는 개발자 입장에서는 우리가 **컨텍스트 마스터**가 되어야 합니다. 큰 그림을 완전히 이해하고, 가장 작은 디테일까지 놓치지 않으며, 무엇을 해야 하는지 의도를 정의하고, 아키텍처를 검증하고, 테스트 스위트를 큐레이션하며, 빠르고 중요한 판단을 내리는 사람 말이죠. + +결국 인간의 역할은 코드를 쓰고 검토하는 것에서, **의도를 정의하고, 아키텍처를 검증하고, 테스트를 관리하고, 중요한 판단을 빠르게 내리는 것**으로 계속 이동할 것입니다. + +앞으로 성공할 팀은 지금부터 이런 기반에 투자하는 팀입니다. 잘 구조화된 스킬 정의, 포괄적인 테스트 커버리지, 명확한 아키텍처 문서화, 그리고 AI 툴을 지름길이 아니라 **새로운 규율을 요구하는 증폭기** (force multiplier)로 받아들이는 문화요. + +우리는 개발자를 대체하는 게 아닙니다. +**개발자라는 직업의 의미를 다시 정의하고 있을 뿐입니다.** + +![우리의 미래](./images/tony-stark.jpg) + +--- + +## Upcoming... + +이번 글은 전체적인 방향성과 문제의식을 공유하는 인트로 성격의 글로 생각하며 공유드렸습니다. 이후에는 Skills, Kernel Agent, 그리고 기타 AI 도구 활용 사례에 대해 각각 별도의 글로 나누어, 사용 방법뿐 아니라 내부적으로 어떻게 설계하고 최적화했는지까지 상세히 정리해 글을 올리도록 하겠습니다. + +HyperAccel 내부적으로 AI가 워크플로우에 자연스럽게 통합되는 방식을 끊임없이 탐색하고 있습니다. 그 과정에서 우리는 “코드를 개발하는 방식”이 근본적으로 변화하고 있는 이 새로운 패러다임 속을 항해하고 있습니다. 앞으로도 그 시행착오와 인사이트를 계속 공유하겠습니다. + +--- + +## HyperAccel 채용 중! + +사실 우리가 이 테크 블로그를 운영하는 큰 이유 중 하나는 **최고의 인재를 끌어오기 위해서**입니다! + +저희가 다루는 기술에 관심이 있고, 이 혁신의 흐름에 함께하고 싶다면 아래 링크에서 지원해 주세요. +[HyperAccel Career](https://hyperaccel.career.greetinghr.com/ko/guide) + +HyperAccel에는 뛰어난 엔지니어들이 가득합니다. +함께할 날을 기다리고 있겠습니다.