AI 네이티브 회사에서 실제로 벌어지고 있는 일들 (리트머스 김응진 대표)

한 줄 요약

외주 개발사 리트머스의 김응진 대표가 조쉬와 만나 회사를 '일하는 플랫폼'으로 바꾼 과정을 보여 줍니다. 직무를 컨설턴트 하나로 합치고 워크벤치·넥서스·파운드리라는 사내 시스템으로 에이전트를 관리하면서 생산성이 세 배 넘게 올랐다고 느낀다는 이야기예요.

전체 내용 정리

리트머스가 AI에 매달린 건 "미래가 없다"는 위기감 때문이었어요

김응진 대표는 2021년에 창업했어요. 지금은 이커머스 데이터 분석 솔루션과 외주 개발 사업부인 리트머스, 두 사업을 함께 운영하고 있습니다. 두 사업 모두 사람이 일의 대부분을 하는 인력 중심 구조거든요.

그래서 작년 말부터 AI를 아주 무겁게 봤다고 해요. 계기는 단순했습니다. 기존 방식대로 가면 LLM이 좋아질수록 회사가 하던 일이 그대로 잠식되는 구조라고 판단한 거예요. 반복 업무는 AI가 가져가고 결국 여러 일을 관제하고 총괄하는 사람들만 남을 거라고 김응진 대표는 봅니다. 그렇다면 무엇을 자동화해야 LLM과 경쟁하지 않으면서 오래 가는 회사의 경쟁력이 되느냐, 이 질문을 계속 붙잡고 있었다고 해요.

여기서 나온 키워드가 OS(운영체제)입니다. 운영체제가 컴퓨터의 많은 걸 관장하듯 회사가 일하는 방식 자체의 플랫폼이 돼야 한다고 보고 이걸 'AIOS'라고 불렀어요. 앞으로는 에이전트로 여러 업무를 복합적으로 처리하는 영역이 중요해지고 기업의 경쟁력은 현실에서 부딪히며 얻은 경험을 그 안에 녹여 내는 데서 나온다는 생각이에요.

김응진 대표가 보는 AX(AI 전환)의 단계도 흥미로워요. 지금 가장 뜨거운 건 교육이라고 봅니다. 개인 생산성을 올리는 데서 시작하는 게 쉽고 그래야 조직이 바뀌니까요. 그다음은 부서별로 프로젝트를 띄워 원래 하던 업무 A를 자동화해 보는 단계입니다. 마지막엔 전사 차원에서 데이터를 어떻게 관리할지, 개인이 자기 업무 경험과 맥락을 담아 만든 에이전트를 어떻게 공유하고 고도화할지 같은 문제가 생겨요. 이때부터는 ERP 수준으로 전체를 관제하는 솔루션이 필요하다고 해요.

그럼 생산성은 실제로 얼마나 올랐을까요? 생산성이 올랐다고 느낀 근거를 묻자 김응진 대표는 지표를 꼽았어요. 최근 리트머스는 모든 포지션을 통합하는 중이거든요. 세일즈, PM, 개발자를 나누지 않고 모두가 이 일을 다 하는 컨설턴트 형태의 역할로 바꿨습니다.

조직 체계를 이렇게 바꾼 뒤로 생산성이 세 배 이상 높아졌다고 느낀다고 해요. 여기서 생산성은 같은 매출 대비 투입 인력 수가 많이 줄었다는 뜻이에요.

조쉬가 이게 기존 전문성을 넓히는 건지, 아예 다른 직무를 맡는 건지 물었는데요. 확장에 더 가깝다는 답이 나왔어요. 확장이 특히 잘된 쪽은 개발이에요. LLM이 개발을 워낙 잘하다 보니 PM이 개발을 같이 하거나 세일즈가 개발을 같이 하는 식으로 영역이 넓어지고 있습니다.

조쉬는 예전엔 PM·디자이너·개발자·QA 네 명이 한 세트로 들어갔다면 이제는 두 명, 때로는 한 명이 처리하기도 한다는 흐름을 짚었어요. 한 사람이 프로젝트를 몇 개 맡는지는 단가에 달려 있다고 해요. 5천, 8천 규모면 사실상 그 프로젝트에만 집중하고 1~2천 규모라면 협업하면서 몇 개를 함께 맡는 편이 맞다고 봅니다.

워크벤치·넥서스·메모리, 세 층으로 회사의 맥락을 쌓아요

리트머스 AI 운영 체계의 첫 번째 축은 워크벤치(workbench)예요. 쉽게 말하면 직무나 업무별로 만든 레포지토리입니다. 세일즈라면 세일즈에 필요한 컨텍스트를 레포에 다 넣고 에이전트도 거기에 세팅해 둬요. 세일즈·기획·디자인·영상 편집마다 워크벤치가 있고 개인 업무는 전부 거기서 합니다. 상황에 따라 Codex를 쓰든 Claude를 쓰든 상관없어요.

두 번째 축은 넥서스(Nexus)예요. 회사의 핵심 정보를 부어 주고 권한을 관리하는 일종의 ERP입니다. 경영진에게는 급여·계약·평가 정보까지 열리고 직무에 따라 열리는 데이터가 달라져요. PM이라면 프로젝트 진행 상황을 읽고 쓸 수 있는 식이죠.

워크벤치와 넥서스는 MCP(Model Context Protocol, AI가 외부 도구에 접속하는 표준)로 연결돼 있어요. 넥서스가 MCP를 만들어 개인별로 발급하고 에이전트에게는 에이전트별 토큰이 따로 나갑니다. 넥서스에는 정해 둔 스키마에 맞는 정형 데이터만 저장해요. 반복적으로 쌓이는 데이터는 중앙에서 API 키로 넥서스가 직접 수집하고요.

세 번째 축이 메모리예요. 외주사는 프로젝트별 맥락이 아주 중요한데, 문서로만 두면 찾아가기가 어렵거든요. 그래서 시맨틱 검색(의미 기반 검색)이 되는 저장 공간을 따로 씁니다. 몇 월 며칠에 누구와 미팅했고 어떤 정책이 협의됐다는 식으로 맥락을 한두 문장씩 정리해서, 미팅 한 번에 수십 개씩 저장해요. 카카오톡 대화도 저장하고 에이전트가 작업할 때 관련된 내용을 검색해 가져갑니다. 메모리 역시 프로젝트별로 나뉘어 권한이 걸려 있어요.

권한 관리는 시행착오가 컸다고 해요. 김응진 대표가 느낀 건 권한을 처음에 톱다운으로 설계하면 실무를 반영하지 못한다는 점이었어요. 넥서스 권한 체계를 세 번 정도 크게 갈아엎었다고 합니다. 처음엔 역할별로 접근 페이지만 나눴는데, 읽기와 편집을 나눠야 했고 MCP로 무엇을 호출하고 업데이트할 수 있는지도 정해야 했죠. 게다가 세일즈와 PM이 합쳐지는 식으로 조직이 바뀌니 권한도 다시 풀어야 했어요.

결국 인증과 권한 관리만 하는 시스템을 최근에 따로 만들었어요. 데이터 읽기, 화면 접근 여부를 전부 키로 정리하고 그 키로 처리합니다. 사람이 머릿속으로 개념화해 짜기엔 너무 복잡해서 컨텍스트와 요청 사항을 한 에이전트에 계속 넣고 에이전트가 정리한 걸 확인한 뒤 업데이트하는 방식으로 관리하고 있어요. 여기에 테스트 케이스가 중요하다고 덧붙였습니다.

공용 에이전트와 파운드리로 에이전트를 관리하고 고도화해요

다음은 전 직원이 같이 쓰는 에이전트 화면이에요. 오픈소스인 Open WebUI를 커스텀해서 ChatGPT처럼 쓰는 곳입니다. 요청 사항 정리, 홈페이지 수정, PM 전용, 자사 솔루션용 같은 에이전트 프로필이 있고 필요한 사람에게 하나씩 열어 줘요. 예를 들어 홈페이지 프로필에는 블로그 글 업로드, 랜딩 페이지 서비스 변경 같은 스킬이 특화돼 있습니다. 실제 실행은 회사 서버 컴퓨터에서 돌아가요.

이렇게 하는 이유가 있어요. 각자 에이전트를 만들면 함께 고도화하기가 어렵거든요. 같이 쓰는 에이전트를 두면 세션 기록이 쌓이고 그걸 바탕으로 고도화할 수 있습니다. 응답마다 좋은지 나쁜지 평가하고 피드백을 남기면 에이전트를 아는 사람이 그 로그를 보고 스킬을 고칩니다. 권한을 열어 주거나 동작을 제한하는 식으로요. 이 루프를 계속 돌리면 에이전트가 같이 고도화되는 시스템이 된다고 해요.

김응진 대표는 에이전트 고도화가 생각보다 어렵다고 말해요. LLM이 에이전트를 설계하고 튜닝하는 일에는 아직 잘 맞춰져 있지 않고 워크플로를 정의하는 게 워낙 중요해서 구조를 정확히 아는 사람만 고칠 수 있거든요. 그래서 가장 잘 아는 사람이 관리하는 컴퓨터 안에서 에이전트를 돌려 모든 동작을 통제하고 피드백은 팀원 누구나 남기게 하자는 게 지금 방향이에요.

그 관리를 맡는 개발자용 플랫폼이 파운드리(Foundry)예요. 에이전트 실행(run)이 하루 몇백 개씩 돌기 시작하면 잘 돌았는지, 끝났는지조차 관리가 안 되거든요. 파운드리에는 작업 단위인 티켓, 지금 돌고 있는 작업, 실패나 문제를 알려 주는 검증(verification), 사람 승인이 필요할 때 작업을 막아 두는 게이트가 있어요. 분류를 잘못하거나 분류는 됐는데 큐에 안 들어가는 문제도 여기서 로그를 보고 찾아 고칩니다. 프로젝트별 브랜치를 어떻게 머지할지도 관리하는데, CI/CD 때문에 자동 배포되는 경우가 있어서예요.

에이전트가 어떤 데이터에 접근할지는 크게 두 부류로 나눠 통제해요. 하나는 환경 변수 기반으로 데이터베이스부터 배포까지 다른 인프라에 접근하는 경우예요. 다른 하나는 넥서스에서 툴 호출을 제한해서 열어 주는 경우입니다. 티켓이 생성되면 다음 에이전트를 위해 티켓 데이터를 업데이트하는 분류 에이전트가 있는데요, 이 에이전트에는 그 일에 필요한 툴만 담은 전용 MCP 키를 줍니다. 정확도를 높이려는 거예요.

직원들은 필요한 게 생기면 해당 에이전트에 직접 들어가 어디까지 되는지 물어보라는 안내를 받아요. 김응진 대표는 각자 만들어서 할 수 있는 일은 각자 하는 게 더 효율적이라고 봐요. 공용 에이전트는 협업이 필요하거나 내가 모르는 부분을 남에게 요청해야 할 때 씁니다. 그래서 공용 에이전트는 각자 접근할 수 없는 영역을 대신하거나, 한 사람만 알고 있는 지식을 에이전트로 만든 경우가 많아요.

대표적인 게 버그를 고치는 에이전트예요. 이 에이전트는 배포와 수정에 관한 모든 권한을 갖고 있습니다. 그런 권한을 모두에게 열어 줄 수는 없으니 이 에이전트가 그 일을 할 수 있는 유일한 게이트가 되는 거죠. 지금 리트머스는 60명 정도 규모인데, 300명이나 500명으로 커지면 이런 관제가 엄청 중요해질 거라고 김응진 대표는 봐요.

고객이 화면에 댓글을 남기면 에이전트가 고쳐요

부서별 자동화 사례로 먼저 나온 건 고객용 파트너 플랫폼이에요. 기본적으로 버그 티켓이 올라오는 곳인데요, 고객이 화면의 요소를 선택해 코멘트를 달면 그대로 티켓이 생깁니다. 그러면 앞서 말한 버그 수정 에이전트가 요청을 확인하고 수정한 뒤 작업 완료 상태로 바꿔요.

조쉬는 처음엔 Vercel의 코멘트 기능과 뭐가 다른지 궁금했는데 듣고 보니 아예 다르다고 반응했어요. 핵심은 이미지예요. 티켓을 누르면 넥서스에 화면이 뜨고 에이전트가 작업을 마치면 스크린샷을 함께 올립니다. 그 스크린샷을 보고 검증하는 구조예요.

그럼 고객이 셀프로 개발하는 셈일까요? 어떻게 보면 그렇다고 해요. 다만 프로젝트 초기에는 티켓을 받는 대로 바로 돌려도 되지만 중기·후기로 가면 PM이 돌릴지 말지, 바로 머지할지를 판단합니다. 이유가 있어요. 1년 전 5천만 원짜리 프로젝트와 지금 5천만 원짜리 프로젝트는 복잡도가 세 배 이상 차이가 난다고 해요. 구현은 되는데 정책이 맞지 않거나 비즈니스 목적과 어긋나는 경우가 많아서 PM이 가이드를 주거나 잘라 내야 하거든요.

기본 설정은 티켓이 오면 바로 수정하는 거예요. 필요하면 브랜치 설정을 바꿔 바로 머지하지 않고 PR(풀 리퀘스트)로 올리거나 작업을 대기 상태로 둘 수 있어요. PM이 댓글로 작업하라고 남기면 분류 에이전트가 다시 작업 대기로 돌려 처리합니다. 어떤 건 바로 고치고 어떤 건 아닌지 같은 정책은 컨설턴트가 고객사와 이야기하며 정해요. 결국 이 플랫폼은 셀프 개발 도구이기보다 고객과 소통하는 도구에 가깝다고 합니다.

티켓이 많을 때는 하루에 300, 400개씩 처리하기도 해요. 그러면 에이전트 비용이 엄청 커집니다. Codex가 티켓마다 빌드하고 스크린샷을 찍는 일이 문제가 돼서 파운드리에 큐 시스템을 만들었어요. 에이전트를 몇 개 둘지부터 정하는데, 인프라의 CPU와 램 사양에 영향을 많이 받거든요. 빌드가 리소스를 많이 잡아먹으니 분류하고 격리하면서 리소스를 제어합니다.

김응진 대표는 AI가 잘되는 분야일수록 에이전트 활용성이 극대화되고 외주 개발업 자체가 인프라 사업으로 바뀔 것이라고 봐요. 그리고 이런 인프라에는 투자가 많이 필요하다고 덧붙였습니다. 에이전트가 잘 돌아가게 만드는 일이 굉장히 고통스러워서 몇 개월 동안 이 작업에 매달렸다고 해요.

세일즈 견적부터 쇼츠 편집까지, 부서마다 자기 도구를 만들었어요

세일즈 쪽은 실무를 맡은 구성원이 직접 설명했어요. 처음 대표가 워크벤치 개념을 제시했고 전사 공유를 위해 Git으로 쓰기 시작했대요. 그러다 작년 말부터 Claude가 크게 좋아지면서 전부 Claude로 넘어왔고 Claude 네이티브로 다시 짜는 작업부터 했습니다. 필요한 에이전트를 몇 개 만들어 워크플로를 정의하고 견적의 중심이 되는 MD 파일을 중앙화해서 모듈처럼 쓰는 스킬 구조를 만들었어요.

스킬 관리도 신경 썼다고 해요. 그냥 두면 스킬이 200개, 300개로 늘고 엉뚱한 스킬이 호출되는 일이 잦아서 스킬의 설명(description)을 아주 세밀하게 다듬었습니다. 요구 사항 구체화도 원래 계약 후 PM이 하던 일인데, 그러면 리스크 판단이 어려워 세일즈 단계로 앞당겼어요.

첫 문의가 들어오면 서브 에이전트를 띄워 고객사의 최근 뉴스, 매출액, 직원 수, 영업 이익 등을 한꺼번에 종합해요. 최근 프리시드 투자를 받았다는 정보는 고객이 얼마까지 지불할 의향이 있는지 가늠하는 데도 도움이 된다고 합니다. 특히 질문을 생성하는 스킬이 중요하대요. 기획 단계에서 빠진 부분을 채우는 건 사람보다 AI가 훨씬 낫다는 느낌을 받는다고 해요. 고객은 앱을 원했는데 이쪽은 당연히 웹이라고 생각했던 일이 생각보다 많았거든요. 다만 계약 전 단계라 처음부터 질문을 200개씩 던질 수는 없어서 온도 조절도 했어요.

견적서도 바뀌었어요. 예전엔 IA(정보 구조)를 뽑고 상세 기획을 하는 데 오래 걸렸는데, 지금은 스킬을 돌리면 텍스트가 아니라 초안 화면이 바로 나와요. 그 화면을 보면서 고객과 이야기할 수 있게 된 거죠. 이 작업을 하며 넥서스의 필요성을 크게 느꼈다고 해요. 한 개발자 대표가 지나가듯 한 말, "DX가 안 되어 있는데 AX를 하면 안 된다"가 인사이트였다고요. 로 데이터를 어떻게 가져와 활용할지가 넥서스에서 해결되니 MCP로 한 번 호출하면 고객과의 합의 사항까지 다 따라옵니다.

효과로는 먼저 온보딩이 엄청 빨라졌어요. 신규 세일즈 직원은 모르는 게 있으면 워크벤치 레포에서 물어보면 됩니다. 외주 개발사에서는 PM과 세일즈 사이에 보이지 않는 기싸움이 있었대요. 세일즈는 가격을 낮춰 계약을 따내야 하고 PM은 리소스를 넉넉히 배분해야 프로젝트를 완수하니까요. 워크벤치와 에이전트로 기획 단계 구체화까지 할 수 있게 되면서 여러 업무를 통합하는 직무가 생기는 것 같다고 해요. 서로의 일을 해 보니 클라이언트와 소통하며 요구 사항을 구체화하는 게 얼마나 어려운지 몸소 느끼게 됐다는 이야기도 덧붙였어요.

견적 산정도 공을 들인 영역이에요. 맨먼스 단가 같은 프로젝트 예측은 AI가 정말 못 한다고 해요. 2주짜리라고 한 작업을 두 시간 만에 끝내기도 하니까요. 그래서 회사가 생각하는 단가를 모으는 게 첫 작업이었고 그다음은 프롬프트를 어디에 어떻게 넣느냐의 문제였어요. 감에 의존해 견적을 내던 방식에서 벗어나려는 거죠.

스스로 학습하는 루프도 시도 중이에요. 워크벤치는 Git에서 자동 동기화되고 커밋 로그가 12,000개 정도 쌓였다고 해요. 에이전트가 파일을 수정하거나 명령을 실행하면 무조건 커밋하게 해 두고 별도의 에이전트가 무엇이 바뀌었는지 봅니다. 그 변경이 단순 수정인지 일반화할 만한 변경인지를 세션이 끝날 때 사용자에게 물어봐요. 그래도 결국 SOP(표준 운영 절차)가 잡혀 있어야 한다고 강조했어요. 그걸 잡는 데 리소스가 가장 많이 든다고요.

마지막으로 마케터를 위해 만든 영상 편집 도구도 소개됐어요. 프로젝트를 만들고 영상을 올리면 스크립트가 자동으로 뽑히고 AI 추천을 누르면 쇼츠로 쓸 만한 클립 목록이 나옵니다. 클립을 확정하면 회사 스타일에 맞춘 자막이 생성되고 앞 자막의 시간을 바꾸면 뒤 자막도 따라 바뀌어요. 자막과 시간을 프레임 단위로 맞추는 수고를 덜려고 만든 하이브리드 도구예요. 실제 마케터가 이 도구로 작업한 건 일주일 정도였다고 해요. 내보낸 뒤에는 AI와 대화하며 메타데이터 후보를 고르고 확정을 누르면 API로 유튜브에 업로드 직전 상태까지 올라갑니다.

에이전시의 미래는 도메인 특화와 컨설턴트에 달려 있어요

조쉬가 에이전시·대행업의 미래를 묻자 김응진 대표는 먼저 업계 구조를 짚었어요. 지금까지 B2B 서비스업은 최상위 플레이어가 시장을 크게 점유하는 흐름이었어요. 로펌 업계라면 최상위 한 곳이 매출의 40% 정도를 가져가는 식이죠. 그런데 AI 시대엔 다른 점이 있다고 봅니다.

하단의 오퍼레이션 영역이 자동화되면서 거기서도 고마진이 난다는 거예요. 원래는 고부가가치 영역에서만 마진이 났다면 이제는 운영 영역에서도 부가가치가 많이 나요. 그래서 새로 치고 올라가는 에이전시에게 큰 기회가 될 수 있고 앞으로 기존 강자와 신생 에이전시가 경쟁하거나 합쳐질 거라고 전망했어요.

조쉬는 반대 방향의 질문도 던졌어요. 요즘 고객사는 수준이 높아져서 부가가치가 낮은 개발은 직접 해 버릴 수 있다는 거죠. 김응진 대표도 거스를 수 없는 흐름이라고 인정해요. 주된 수익원이 점점 LLM에 잠식되니 더 높은 단계로 올라가야 한다는 거예요. 반대로 그 시차가 기회라고 봐요. LLM이 좋아질 때마다 그걸 최대한 활용하는 경험은 일반 회사가 쌓기 어렵지만 리트머스는 그 일만 하니까요.

대비 방향은 도메인 특화예요. 김응진 대표가 중요하게 보는 도메인은 기획이에요. 기획을 사업 전략과 연결해 솔루션을 제안하는 능력이 핵심이라고 봅니다. 그래서 지금은 세일즈와 PM이 나뉜 것처럼 보여도 결국 모두 컨설턴트라는 새 직군이 돼야 한다고 말해요. 세일즈도 잘해야 하는데, 그게 곧 솔루션 제안 능력이기 때문이에요.

조쉬는 엔지니어들이 직접 고객 현장에 나가 세일즈를 하며 문제를 파악하고 바로 개발까지 해 버리는 해외 사례를 소개했어요. 에이전시에는 에이전트 오케스트레이션이나 에이전트 옵스를 할 수 있는 컨설턴트가 필요해 보이고 예전부터 중요했던 커뮤니케이션 능력은 더 중요해질 거라고 정리하며 대화를 마무리했습니다.

핵심 인사이트

• AI 전환의 마지막 단계는 '공유와 관제'예요: 교육과 부서별 자동화를 지나면 개인이 만든 에이전트를 어떻게 공유하고 고도화할지가 문제가 됩니다. 리트머스는 이 지점에서 ERP 수준의 관제 시스템(넥서스·파운드리)을 만들었어요. 개인 생산성만 보는 AI 도입은 여기서 막힐 수 있다는 걸 보여 주는 사례예요.
• 권한은 처음부터 완벽하게 설계할 수 없어요: 리트머스는 권한 체계를 세 번 갈아엎은 끝에 권한 관리 전용 시스템을 따로 만들었습니다. 조직이 바뀌면 권한도 바뀌니, 키 단위로 쪼개고 에이전트에게 맥락을 넣어 정리하게 하는 방식이 현실적이에요.
• DX 없이 AX 없어요: 데이터가 정리돼 있어야 에이전트가 MCP 한 번 호출로 맥락을 가져갑니다. 견적처럼 AI가 못 하는 예측은 회사의 단가 데이터와 SOP를 먼저 쌓아야 풀려요.
• 공용 에이전트는 '한 사람만 아는 일'과 '모두가 접근하면 안 되는 일'에 써요: 각자 할 수 있는 일은 각자 하고 공용 에이전트는 협업 지점과 위험한 권한의 유일한 관문으로 둡니다. 평가 버튼과 로그로 피드백 루프를 돌리면 에이전트가 같이 좋아져요.
• 직무 통합이 생산성을 끌어올렸어요: 세일즈·PM·개발자를 컨설턴트 하나로 합친 뒤 생산성이 세 배 이상 올랐다고 느낀다고 해요. 서로의 일을 해 보며 협업 갈등도 줄어드는 효과가 있었어요.

오늘 당장 해볼 것

1. 지금 하는 업무 하나를 골라 전용 폴더(레포)를 만들어 보세요. 그 업무에 필요한 고객 정보, 단가표, 자주 쓰는 템플릿을 MD 파일로 넣고 Claude Code나 Codex를 그 폴더에서 열면 됩니다. 리트머스 워크벤치를 가장 작게 따라 하는 방법이에요.
2. 미팅이 끝나면 날짜·상대·합의 사항을 한두 문장으로 정리해 한 파일에 쌓아 보세요. 나중에 AI에게 그 파일을 주고 이 고객과 합의한 정책을 정리해 달라고 물으면 메모리의 효과를 바로 체감할 수 있어요.
3. 견적이나 제안서를 쓰기 전에 AI에게 고객에게 던질 질문 목록부터 뽑아 달라고 해 보세요. 앱인지 웹인지처럼 당연하다고 넘긴 전제가 드러나서 계약 후 재작업을 줄일 수 있습니다.
4. 자주 쓰는 프롬프트나 스킬이 쌓였다면 이름과 설명을 한 번 정리해 보세요. 설명이 겹치면 엉뚱한 스킬이 불려 나오니 언제 쓰는지 한 줄로 분명히 적어 두는 것만으로도 정확도가 올라가요.