"I love legal work, but isn't there a way to put this experience to use on a larger scale?"

If you've ever thought that, we'd like to introduce you to a role called Legal Engineer.

This role has been gaining traction at legal AI companies overseas, but in Korea it's still an unfamiliar title. It's hard to guess what the job actually involves just from the name.

To be honest, we ourselves couldn't clearly explain this role until we started hiring for this position. Through researching public information from overseas companies and discussing internally, what became clear was that a Legal Engineer is someone who "turns judgment built through legal practice into product specifications."

The role puts into words the judgments that are made as a matter of course in law firms and corporate legal departments, organizes them into a form the development team can share, and turns them into features anyone can use. What matters most in this role is not engineering knowledge, but practical experience in legal work.

BoostDraft is now hiring a Legal Engineer for the Korean market. This is the first dedicated hire for the Korean market.
This article explains, as concretely as possible, what a Legal Engineer does.

What Does a Legal Engineer Do? 

A Legal Engineer is a role that translates legal expertise into product specifications.

Here, "specification" means the design that determines how software should behave. Giving legal advice or making legal judgments on individual cases is not part of this job.

Legal professionals carry knowledge like "in practice, this is how it works," "this exception can't be overlooked," or "this shouldn't be automated too far." The core of this job is to organize that knowledge and, working with the development team, reflect it in the product. That bridging function is at the center of the work.

A Role You Won't Find Through a Search — a New Career Path for Legal Professionals

Searching for "리걸 엔지니어" turns up almost nothing that explains this role.

This isn't because Korea lacks legal tech companies. Several companies have been founded by lawyers who came from major law firms, and new AI-driven services keep appearing. Still, the role of "placing a legal expert on the product-building side" doesn't yet have a name as a job title.

What this article describes is that role without a name. It means working at a legal tech company like BoostDraft, understanding customers' legal work, and feeding that understanding back into both product development and customer adoption.

Why This Role Is Necessary

A feature that can be built and a feature that gets used are two different things.

Even something technically difficult to implement won't be used if practitioners don't trust it. Only someone who understands legal practice can draw the line on what should become a product feature. That's why this role is needed between legal practice and product development.

Placing a dedicated role at this intersection of legal practice and product development isn't yet an established job title in Korea, but the practice itself is no longer unusual in the West.

 Why Doesn't "Engineer" Require Programming Experience? 

You might be wondering: "I understand the general idea, but is it really fine to have zero engineering knowledge?"

Looking at the name "Legal Engineer" alone, many people picture a software engineer who also happens to know law. It's genuinely difficult to guess the actual content of the job from the name.

Of course, an interest in technology is necessary. You will often discuss things with the development team, understand technical constraints, and think through specifications together. But that is different from being able to write code yourself.

In the industry, this kind of aptitude is sometimes described as being "tech curious." The idea is that what matters is not expertise in computer science, but an attitude of wanting to understand technology and the ability to communicate with the development team in a shared vocabulary.[*1]

For that reason, BoostDraft does not include programming experience in its requirements, and instead places weight on practical experience in legal work.

 What Does a Legal Engineer Actually Decide? 

At the center of a Legal Engineer's discussions is the question: "How should the software behave in the first place?" or “"How would this bring practical value to users?"

To make this concrete, imagine building a product that supports contract drafting and review inside Word — one with features that check whether clause references are correct, detect formatting inconsistencies, and use AI to analyze contracts. Here are three of the questions that come up.

The three examples below were put together based on conversations with BoostDraft's development team and members with hands-on legal experience. They don't describe the actual product specification itself, but they should give a sense of what a Legal Engineer thinks about.

Example 1: Should the System Flag Every Mismatched Reference?

At first glance

Word has a cross-reference feature. Using it, if a referenced clause number changes, the reference number in the body text updates automatically. It might seem like clause-number mismatches could be solved by Word's feature alone.

What happens in practice

Many practitioners don't use the cross-reference feature at all — they type clause numbers in directly. In documents received from the other party, cross-reference settings are often broken, or were never set up in the first place.

On top of that, how clauses are referenced differs by jurisdiction and language. In Korean, this is written as, for example, "제5조 제2항 제1호," while in English, terms like Article, Section, Clause, and Sub-clause are used depending on context. There are also expressions like "본항" that refer to a clause without using a number at all.

What has to be decided

• How precisely should a manually typed clause reference be recognized?
• If the referenced clause doesn't exist, should this be flagged as an outright error, or simply prompt a confirmation?
• Should relative references like "본항 " be included in the scope of analysis?
• How closely should handling be aligned between Korean and English?
  

What's needed here isn't just knowledge of the law — it's an understanding of practice itself. Without knowing how contracts are actually written and read in Korean practice, you can't decide on a specification for the Korean market.

Example 2: Is It Acceptable to Automatically Fix Formatting Inconsistencies?

At first glance

Inconsistent number formatting, uneven indentation — these kinds of formatting inconsistencies can be easily detected by software. It might seem reasonable to just fix them automatically.

What happens in practice

Every law firm and company tends to have its own formatting conventions. What's correct in one organization may need to be corrected in another.

In contract negotiations, it's common to deliberately preserve the formatting of a document the other party drafted. If formatting is changed automatically, the tracked-changes history fills up with formatting edits, making it harder to see the substantive changes that actually matter.

Something can be technically correct and still produce an undesirable outcome in practice.

What has to be decided

• Should the system fix formatting automatically, or only suggest it as a candidate change?
• Should the system be able to remember formatting rules by user or by organization?
• Should sections you edited yourself be distinguished from sections drafted by the other party?
• Should formatting changes and substantive contract changes be made distinguishable within the tracked-changes history?

Example 3: What Criteria Should AI Use to Flag "Important Clauses"?

At first glance

Load a contract into the AI and have it flag the important clauses. It seems like the parts needing review could simply be surfaced automatically.

What happens in practice

Which clauses matter depends on the type of contract. The clauses you check first in a sale agreement aren't the same ones you check in a services agreement.

Beyond that, which clauses warrant caution shifts depending on which side you're on — buyer or seller, client or contractor. The very same clause can be entirely standard for one party and a point worth negotiating for the other.

Listing "generally important clauses" won't match what actually needs attention in the deal in front of you.

What has to be decided

• How should the contract type be identified? Is the title alone enough to go on?
• Should the parties' respective positions be inferred from the document, or specified by the user?
• Should the criteria for importance vary by jurisdiction?
• Should results be presented as a flat list, or ranked by priority?

Unlike Examples 1 and 2, where a rule can settle the answer, this one requires telling the difference between output that merely looks plausible and output that genuinely holds up in practice.

What the Three Examples Have in Common

In both cases, the question of "how would this bring practical value to users? " comes before the question of what's technically achievable.

Being able to read a contract isn't enough to make this kind of judgment. Only by having experienced how contracts are drafted, reviewed, and negotiated can you decide what should become part of the product's specification and whether a feature will really help in users' actual day-to-day practice.

The role of a Legal Engineer is to bridge the gap between the product development team and the users who actually use the product: to put that experience into words, organize it into a form the development team can share, and turn it into a specification the product can reproduce. That's why BoostDraft values practical legal experience over programming experience.

Testing the Specification in the Customer's World

So far, we've explained that a Legal Engineer is someone who thinks through product specifications. But BoostDraft's Legal Engineers have another major responsibility.

That is supporting customers — lawyers working at corporate legal departments or law firms — so they can make full use of the product, and feeding that experience back into product development.

Every customer builds and reviews contracts differently. During onboarding, you need to understand each organization's workflow and think through, together with them, how the product can be used most effectively there. You design onboarding and training, monitor usage, keep improving, and stay engaged until the product truly takes root in daily work.

Public information from overseas legal AI companies describes the Legal Engineer role in similar terms: identifying customers' operational challenges, designing how the product should be used, supporting adoption through to full integration, and feeding those lessons back into development. This differs from traditional SaaS implementation support in that it involves going much deeper into the customer's actual practice while helping to make change stick.[*2]

At BoostDraft, we don't separate customer support from contributing to product development — both are defined as part of the Legal Engineer role.

Insights gained through conversations with customers flow directly into the next round of specification discussions. Conversely, specifications decided through discussion with the development team are then verified in the field, with the customer, to see if they really deliver value.

To be candid, the scope of this role is broad. But being able to connect a customer's problem directly to a product improvement, without anyone else in between, is a rare kind of role — one that's hard to find where work is divided up.

The Environment at BoostDraft

Now, let us introduce not just the "Legal Engineer" role, but our company as well.

BoostDraft is a Japanese company. Our core product is BoostDraft, a local add-in for Microsoft Word that supports the drafting and review of contracts and other legal documents.

Drafting a contract involves far more than the text itself — checking clause consistency, cross-references, formatting, and tracked changes all take up a great deal of detailed work. Each of these tasks may look simple on its own, but maintaining high quality across a large volume of documents adds up to a significant burden.

BoostDraft aims to automate this kind of repetitive work so legal professionals can focus on more important judgment calls. Two features stand out for handling highly confidential legal documents: it works inside Word without disrupting people's existing workflow, and it runs locally, meaning document data is never sent externally.

BoostDraft has already been adopted by 3 of the top 5 law firms in Korea. In Japan, it has been adopted by 17 of the top 20 law firms.

Some notable characteristics of this environment:

• You'll be part of the entire process from product-market fit to scaling the business. This isn't starting from zero — the product is already in use, and the work is about taking it to the next stage.
• You'll be close to the management team and can learn directly from their perspective on strategy and product development.
• The development team includes members based overseas, so English is used on a daily basis.
• Many of our customers are organizations that hold themselves to high quality standards in the legal field.
• The environment is fully remote with flexible working hours.

This Is the First Dedicated Hire for the Korean Market

Right now, BoostDraft has no one dedicated full-time to the Legal Engineer role for the Korean market. Members with legal expertise or a license to practice law are effectively covering something close to this role alongside their other work.

The dedicated position for the Japanese market is also very new. A member with legal experience had been contributing ideas to product development from time to time, and that involvement has just recently been formally carved out into the role of "Legal Engineer."

In other words, even in Japan, we're still building this way of working, largely by trial and error.

Whoever takes this position will be asked to do two things at once.

The first is to define what the Legal Engineer role looks like for the Korean market.

How should the kinds of questions raised in this article's two examples be prioritized, discussed, and worked through — and with whom? None of that is settled yet. Rather than stepping into an established model, you'll be the one building it.

The second is to determine the specifications that fit Korean contract practice.

As shown in the examples above, some decisions can only be made by someone who understands Korean legal practice: what should be flagged as an error, how far to automate, and where to leave the judgment to the practitioner. You'll be the one drawing that line first for the Korean market.

And there's one more thing worth noting about this job: the sheer reach of it.

If you work in a company's legal department or at a law firm, the people directly affected by your judgment are limited to the organization or the cases you're handling. A Legal Engineer is different. If you translate the frustrations you've felt in your own practice into the product's specifications, the work of every other practitioner facing the same problem changes too.

This isn't about solving one case at a time — it's about changing the underlying assumptions shared by everyone dealing with the same problem. We believe that the fact that what you've felt in your own practice can directly become something that helps someone else is one of the things that makes this job compelling.

We'd Like to Talk With People Like This

We're not simply looking for someone with legal knowledge.

We're looking for someone who, drawing on practical legal experience, has thought: "Isn't there a better way to do this?" or "Does this task really need to be done by a person?"

• Someone who has felt that time in legal practice is spent on tasks that could genuinely be made more efficient
• Someone interested in putting into words the judgments and workarounds they make almost unconsciously
• Someone who enjoys working through problems that don't yet have a fixed answer, in discussion with others
• Someone who wants to change the work of legal professionals more broadly through a product, not just case by case

If you feel ready to put your experience to use in your next career step, we'd love to talk. The judgment you've built up in the field is exactly what we want to bring into our product going forward.

Curious whether your background is a fit? The specifics — language requirements, experience level, and more — are all in the job posting below.

▶ View the job posting and apply here: https://apply.workable.com/boostdraft/j/F200634AD7/

[*1]: LawFuel, "Lawyers Are Training AI to Do the Work They Used to Hate . . . And It's Working" https://www.lawfuel.com/lawyers-are-training-ai-to-do-the-work-they-used-to-hate-and-its-working/

[*2]: Legora, "The rise of the Legal Engineer: Making AI work in law" https://legora.com/blog/the-rise-of-the-legal-engineer-making-ai-work-in-law