초중급 개발자 논쟁 댓글 46건과 회계사의 서명란
얼마 전에 개발자 커뮤니티 게시판의 목록을 한 달치 세어본 적이 있다. AI로 뭘 만들었다는 글이 실제로 얼마나 되는지 궁금해서였다. 그 뒤로 가끔 들여다보는데, 이번엔 목록이 아니라 글 하나가 눈에 걸렸다. "초중급 개발자는 진짜 망한거 맞죠?"
코딩을 한 번도 해본 적 없는 사람이 월 30만 원짜리 구독을 결제하고 쇼핑몰과 앱과 서버 관리와 사업 시스템을 만들었다는 내용이었다. 사장은 코딩 언어를 전혀 알 필요가 없었고, 그건 컴퓨터를 모르는 사장이 컴공 전공 직원에게 지시하는 것과 완전히 똑같다고 했다.
조회수가 만 명을 넘겼고 댓글이 46개 붙었다. 전부 읽었다. 20년차라고 밝힌 사람, AI 개발자라고 밝힌 사람, 코딩을 하나도 모르는데 커서를 결제해서 잘 쓰고 있다는 사람까지 골고루 있었다. 양쪽 논거가 다 나왔고, 읽고 나니 각 진영이 무엇을 근거로 삼는지도 정리가 됐다.
그런데 정리가 되고 나서 오히려 새로 걸린 게 있었다. 이 논쟁은 끝날 수가 없는 구조였다.
46건이 같은 축 위에 서 있었다
첫 댓글이 스레드 전체의 프레임을 정했다. 20년차라는 사람이 이렇게 썼다.
전혀 모르는 다른 영역 개발 같은 거 진짜 코드 한 줄 안 짜고 바이브로만 만들어 서빙하고 합니다. 백점 만점에 92점 정도짜리는 매우 쉽게 만들어줌. 하지만 프러덕션용 98점 이상짜리는 말로만은 쉽지 않음.
이 92점과 98점이 이후 스레드를 지배했다. 어떤 사람은 "90점까진 누구나 쉽게 갑니다. 문제는 거기서부턴 1점 올리는 데 엄청난 노력과 자본이 든다"고 받았고, 어떤 사람은 "비개발자들이 쉽게 느끼는 이유는 92점짜리가 100점짜리처럼 보이기 때문"이라고 받았다. 실제로 사내 전산 프로그램을 3주 만에 만들어 20명이 쓰고 있다는 사람도 회고해보니 "딱 90점"이라고 썼다.
정작 원글이 던진 프레임(사장이 직원 부리듯 AI를 부린다)은 아무도 이어받지 않았다. 스레드의 실제 주제는 첫 댓글이 정했다.
문제는 이 축의 성질이다. 92점과 98점은 AI의 능력에 대한 이야기다. 그리고 능력은 매년 오른다. 그러면 작년에 낸 결론이 올해 무효가 되고, 올해 낸 결론이 내년에 무효가 된다. 실제로 스레드 안에서도 그 말이 나왔다. "작년에 몇 점 정도인지 생각하면 답 나오죠." "작년에 비하면 엄청 개선되긴 함. 내년엔 진짜 더 쉬워질 듯."
양쪽 다 맞다. 그래서 안 끝난다. 능력을 축으로 놓는 한 이 논쟁은 모델이 새로 나올 때마다 처음부터 다시 해야 하는 종류의 논쟁이다.
원글의 유비가 스스로를 반박한다
원글에서 가장 강한 문장은 이거였다.
컴퓨터에 대해 아무것도 모르는 사장이 대학에서 컴퓨터공학 전공한 직원에게 뭐 만들어라 지시하는 거랑 완전히 똑같습니다.
읽으면 설득력이 있다. 그런데 이 유비는 절반만 옮겨졌다.
사장이 컴공 직원에게 지시하는 게 굴러가는 이유는 지시가 정확해서가 아니다. 받는 쪽이 걸러내기 때문이다. 사장이 말이 안 되는 걸 시키면 직원이 "그렇게 하면 다른 데가 깨집니다"라고 답한다. 그 반문이 유비의 나머지 절반이고, 그게 실제로 품질을 만든다.
AI에게 시킬 때 그 반문이 없는 건 아니다. 오히려 잘 한다. 문제는 반문이 맞는지 틀린지 판단할 사람이 사장 쪽에 없다는 것이다. 컴공 직원이 "그건 안 됩니다"라고 하면 사장은 그 말을 믿을지 말지를 조직의 신뢰 관계로 처리한다. AI가 같은 말을 하면 그 판단이 갈 곳이 없다.
그래서 이 유비는 원글의 결론이 아니라 반대편 결론을 지지한다. 지시하는 사람과 걸러내는 사람이 둘 다 필요하다는 쪽으로.
원글이 45번째 댓글에서 전제를 놓았다
스레드에서 가장 흥미로운 대목은 반박이 아니라 원글 작성자 본인의 댓글이었다.
원글은 "사장은 코딩 언어를 전혀 알 필요도 없다"였다. 그런데 논쟁이 길어지면서 이렇게 썼다.
처음 오더를 내리고 결과를 보면 부족한 부분이 있긴 한데, 문제점을 발견해서 창작자가 원하는 대로 지시하면서 조금씩 수정 보완하면 100%를 만들어내긴 하던데요?
문제점을 발견한다는 건 무엇이 잘못됐는지 판단한다는 뜻이다. 그게 검증이다. 원글의 전제는 검증이 필요 없다는 것이었는데, 반박에 답하는 과정에서 검증을 스스로 도입했다.
같은 스레드에서 다른 사람이 그 지점을 정확히 찔러뒀다.
코딩을 못하면 AI가 만드는 슬롭을 못 잡아서 다 망가져요. 언어를 모르는데 어떻게 컴페어해서 찾아낼 거며, 찾아내라고 시키면 그 사이에 할당량 다 채웁니다.
두 사람은 서로 반대편에 서 있었는데 실은 같은 자리를 가리키고 있었다. 만드는 것과 틀린 걸 알아보는 것이 다른 일이라는 자리다.
축을 능력에서 옮기면
여기서 축을 바꿔보자. AI가 얼마나 잘하느냐가 아니라, 누가 그 결과에 답하느냐로.
변호사를 생각하면 구조가 선명해진다. AI가 소장을 대신 써줄 수 있다. 문장이 사람보다 나을 수도 있다. 그런데 그 문서에는 효력이 없다. 변호사가 서명해야 제출되고, 서명하는 순간 효력이 생기며, 틀렸을 때 책임도 그 서명에 붙는다.
여기서 중요한 건 효력이 문서의 품질에서 나오지 않는다는 점이다. 아무리 잘 쓴 소장도 서명이 없으면 종이고, 평범하게 쓴 소장도 서명이 있으면 법률 문서다. 품질 축과 효력 축이 애초에 분리되어 있다.
그래서 AI가 좋아진다고 이 구조가 흔들리지 않는다. 아무리 좋아져도 서명하는 자리는 그대로 남는다. 성능 향상으로 반증되지 않는 논거다.
회계도 같다. 이제 전표 입력과 계정 분류와 연결 결산은 시스템이 한다. 그런데 감사의견에는 회계사가 서명한다. 숫자를 기계가 만들었다는 사실이 서명자를 면제해주지 않는다.
그리고 코드에는 이 개념이 없다. 지금 배포는 "누가 서명했는가" 없이 나간다. 머지 버튼을 누른 사람이 있긴 하지만 그게 책임 귀속으로 정의되어 있지 않다. 그래서 사고가 나면 요구사항 탓, 일정 탓이 가능했고, 이제는 AI 탓이 하나 더 늘었다.
얕아 보이는 이유는 물고기가 얕은 데서만 보이기 때문이다
축을 옮기기 전에 짚어둘 게 있다. 왜 이렇게 많은 사람이 같은 방향으로 착시를 겪느냐다.
수면 위로 물고기가 지나가는 걸 보고 물이 얕다고 판단하는 것과 비슷하다. 깊은 물에도 물고기는 있지만 안 보인다. 그러니까 "물고기가 지나간다"는 관측 자체가 얕은 곳에서만 수집된다.
커뮤니티에서 벌어지는 일이 정확히 이 모양이다. 3주 만에 만든 사내 시스템은 글로 올라온다. 3년 굴리다 무너진 시스템은 안 올라온다. 성공한 사례만 수면 위로 나오는 구조라서, 표본이 얕은 물에서만 모인다.
여기에 시간축이 하나 더 겹친다. 코드의 깊이는 만들 때 드러나지 않고 유지할 때 드러난다. 원글을 쓴 사람은 만든 시점에 서 있어서 구조적으로 못 본다. 무지가 아니라 위치의 문제다. 앞서 말한 한 달치 목록도 같은 모양이었다. 제목 대부분이 "이런 걸 만들었습니다"였고 그 다음이 있는 글은 거의 없었다. 그 이야기는 만드는 건 딸깍 한 번이었고 고치는 데서 네 번 무너졌다에 적었다.
스레드에서 사내 전산 프로그램을 3주 만에 만들었다는 사람이 이 경계에 정확히 걸쳐 있었다. 20명이 만족스럽게 쓰고 있는데, 본인이 회고하면서 "딱 90점"이라고 적었다. 물에 발을 담가봐서 얕지 않다는 건 알지만, 아직 운영 기간이 짧아서 얼마나 깊은지는 모르는 자리다.
그래서 "저 사람들은 본질을 모른다"는 식의 정리는 별로 쓸모가 없다. 그런 말은 반증이 안 되고, 실제로 스레드의 반대편도 같은 화법을 썼다. "해보시면 알아요", "실무 수준으로 해본 사람들은 알겁니다." 서로 자기가 진짜 물을 봤다고 주장하다 끝났다.
깊이를 주장하는 대신 가리킬 수 있어야 한다. 회계가 그 손가락이다.
회계는 같은 실험을 먼저 끝냈다
개발자 논쟁이 아직 전망 싸움인 데 비해, 회계는 이미 답이 나와 있다.
회계는 자동화가 가장 깊이 들어간 사무 영역 중 하나다. 수십 년에 걸쳐 장부 작성이 시스템으로 넘어갔다. 그런데 감사의견에 서명하는 자리는 사라지지 않았다. 오히려 제도가 그 자리를 계속 강화하는 쪽으로 움직였다.
미국에서는 2002년 사베인스-옥슬리법이 만들어졌다. 엔론과 월드컴과 타이코가 연달아 터진 직후였다. 그중 302조는 상장사의 CEO와 CFO가 분기·연간 보고서의 정확성을 개인 명의로 인증하고, 내부통제의 유효성까지 매 분기 확인하도록 했다. 회사가 보증하는 게 아니라 사람이 서명한다.
같은 사건에서 아서앤더슨이 사라졌다. 세계 5대 회계법인 중 하나였고, 엔론의 회계 부정을 잡아내지 못한 데다 관련 문서를 파기해 형사 범죄가 됐다. 2002년 월드컴까지 겹치면서 법인이 공중분해되어 다른 회계법인들에 나뉘어 팔렸다. 서명이 형식이 되면 어떻게 되는지를 회계 업계는 회사 하나가 사라지는 방식으로 배웠다.
국내도 같은 경로를 지났다. 대우조선해양 분식회계로 회계 제도에 대한 신뢰가 무너졌고, 감사에 참여한 회계사들이 최대 3년 실형을 받았다. 이 사건이 2017년 10월 외부감사법 전부개정으로 이어졌고 2018년 11월부터 시행됐다.
개정 내용 중 이 글의 주제와 정확히 겹치는 게 있다. 신외감법은 상장사 내부회계관리제도의 인증 수준을 '검토'에서 '감사'로 올렸고, 회사의 대표자가 운영 실태를 직접 주주총회에 보고하도록 했다. 내부회계관리제도는 시스템이 굴리는 통제다. 그 통제의 보고 주체를 법이 사람으로 못 박았다.
서명자의 시간을 법으로 산다
회계가 먼저 부딪히고 먼저 답을 낸 문제가 하나 더 있다.
서명자가 형식적으로만 서명하는 상황 말이다. 감사 보수가 낮게 깎이면 감사에 쓸 시간이 줄고, 시간이 줄면 실질 검증 없이 서명만 하게 된다. 이건 개인의 성실성 문제가 아니라 구조 문제다.
한국은 이걸 표준감사시간으로 풀었다. 외부감사법 제16조의2에 근거가 있고, 산업별·기업 규모별로 감사인이 투입해야 할 일반적·평균적 감사시간을 정한다. 3년마다 타당성을 다시 검토해 공개하게 되어 있고, 2025~2027년에 적용될 값도 이미 나와 있다. 도입 이후 감사시간이 늘었고 보수도 늘었으며, 학계 연구에서 감사 품질 개선이 확인됐다.
주목할 건 해법의 모양이다. "감사인이 더 열심히 하자"가 아니었다. 시간을 법으로 확보했다.
이게 AI 시대의 개발에 그대로 얹힌다. 코드 리뷰가 굴러갔던 건 사람이 하루에 쓰는 코드량에 상한이 있었기 때문이다. 생산량이 몇 배가 되면 같은 방식의 리뷰는 산술적으로 성립하지 않는다. 읽는 속도는 그대로니까.
그러면 남는 선택지는 둘이다. 만드는 양을 사람이 읽을 수 있는 크기로 자르거나, 기계가 대신 읽게 하거나. 후자를 실제로 만들어보면 검사기 뭉치가 된다. 문체나 품질처럼 모델 출력에 좌우되는 건 게이트로 못 박고, 사실 판정이 가능한 것만 기계에 맡기는 식이다. 그 경계에 대해서는 개발 방법론 대신 검사기 23개를 만들었다에서 따로 적었다.
어느 쪽이든 책임질 수 있는 상태를 만드는 것 자체가 일이 된다. 읽지 않고 책임질 수는 없기 때문이다.
서명할 사람은 길러진다
여기서 초중급 개발자 이야기가 다시 나온다. 다만 다른 방식으로 나온다.
"AI가 아직 못 하는 게 남아 있으니 초중급이 필요하다"는 논거는 약하다. AI가 좋아지는 만큼 매년 약해지기 때문이다. 스레드에서 초중급을 옹호한 사람들 대부분이 이 논거를 썼고, 그래서 원글과 평행선을 달렸다.
책임을 축으로 놓으면 다르다. 서명할 수 있는 사람은 길러야만 생긴다. 무엇이 잘못됐는지 알아보는 감각은 잘못해본 데서 나오고, 그건 시간을 들여 통과해야 하는 구간이다.
전문직은 이 문제를 개인의 선의나 조직의 판단에 맡기지 않았다. 법으로 강제한다.
변호사법 제21조의2는 통산 6개월 이상 법률사무종사기관에서 종사하거나 연수를 마치지 않으면 단독으로 법률사무소를 열 수 없고 법무법인의 구성원도 될 수 없다고 정한다. 공인회계사법 제7조는 자격을 얻은 뒤 1년 이상 실무수습을 받아야 금융위원회에 등록할 수 있게 한다. 시험 합격만으로는 서명을 못 한다.
왜 법으로 강제할까. 조직 자율에 맡기면 아무도 안 기른다는 걸 알기 때문이다. 수습생은 당장은 비용이다. 지금 신입 채용이 줄어드는 상황과 정확히 같은 구조다.
스레드에서 이 논점을 던진 사람이 셋 있었다. "초급이 있어야 고급도 있는 거죠." "당장은 초중급 필요 없어 보이지만 몇 년 지나면 귀해질 거예요." "시니어들도 은퇴할 텐데 신입, 주니어를 뽑아서 키워야 하는 거죠." 셋 다 짧게 지나갔고 아무도 이어받지 않았다.
그런데 이게 이 논쟁 전체에서 가장 단단한 논거다. 시니어의 이탈은 예측이 아니라 확정된 사건이기 때문이다. 정년, 이직, 번아웃. 시점이 문제지 발생 여부가 문제가 아니다. AI 성능 전망은 불확실하지만 이건 불확실하지 않다.
시니어가 떠난 자리에서 새벽에 장애가 났다고 하자. 원인을 찾고 패치 후보를 만드는 것까지는 AI가 한다. 그런데 롤백할지 핫픽스할지는 매출 손실과 데이터 정합성 위험을 저울질하는 판단이고, 다음 날 "왜 그렇게 결정했느냐"에 답해야 하는 자리가 남는다. 보고서는 AI가 쓸 수 있지만, 그 보고서를 들고 앉아 질문을 받는 건 사람이다. 그리고 AI가 생성한 사후 설명은 그럴듯한 합리화일 수 있어서, 구분하려면 그 시점에 실제로 판단한 사람이 있어야 한다.
세 가지를 나눠보면 이렇게 된다. 장애 원인 파악은 부분적으로 대체된다. 보고서 작성은 대체된다. 책임은 대체되지 않는다. 조직은 앞의 둘이 대체되는 걸 보고 사람이 필요 없다고 판단하는데, 정작 대체 불가능한 건 세 번째다.
소프트웨어에는 이미 그 체계가 있다
여기까지 읽으면 반론이 하나 떠오른다. 회계와 법률은 규제 산업이고 소프트웨어는 아니라는 것. 코드에 서명 체계를 얹는 건 현실적이지 않다는 것.
그런데 소프트웨어에도 이미 있다.
항공기에 실리는 소프트웨어는 DO-178C라는 표준을 따른다. 이 표준 아래서는 FAA가 지정한 DER(Designated Engineering Representative)이 규제 기관을 대신해 검토하고 승인을 권고한다. 사람이다. 그리고 소프트웨어 위험 등급이 가장 낮은 DAL D에서조차 DER 연계가 요구된다.
즉 소프트웨어에 서명자를 두는 게 불가능해서 안 하는 게 아니다. 이미 하고 있고, 개발 일반에만 없다. 항공기가 떨어지면 사람이 죽고 손해가 특정되기 때문에 제도가 먼저 왔을 뿐이다.
다만 개발에는 없는 조건이 있다
여기까지 오면 유비가 너무 매끄럽게 들리므로, 안 맞는 부분을 먼저 적어둔다.
변호사와 회계사에게는 자격이 있고 등록이 있고 징계가 있고 배상책임이 있다. 서명이 무게를 갖는 건 개인의 의지 때문이 아니라 그 뒤에 제도가 서 있기 때문이다. 개발자에게는 그게 없다. 그러니까 이 유비는 "그래야 한다"의 모델이지 "이미 그렇다"의 근거가 아니다.
차이가 나는 이유도 분명하다. 회계는 사고가 나면 금액으로 환산되고 피해자가 특정된다. 그래서 배상이 성립하고 제도가 붙었다. 소프트웨어 장애는 손해 산정이 흐리고 책임 소재가 계약서 조항 안에 묻힌다. 항공기 소프트웨어에 DER이 있고 사내 관리 도구에 없는 이유가 이거다. 떨어지면 사람이 죽는 쪽부터 제도가 갔다.
그러니 이 글의 주장은 "개발자도 곧 면허를 받게 된다"가 아니다. 제도가 없는 상태에서 책임은 가만두면 가장 약한 자리로 흘러간다는 것, 그래서 그 자리를 누가 맡을지는 선언이 아니라 설계의 문제라는 것이다.
무게중심은 이 순서로 옮겨간다
여기까지를 하나로 묶으면 개발자의 자리가 이렇게 이동한다.
분석가 → 설계자 → 관리자 → 감시자 → 책임자
앞의 넷은 능력이다. 그리고 능력은 하나씩 AI 쪽으로 넘어가고 있다. 마지막 하나만 성질이 다르다. 책임은 능력이 아니라 귀속이고, 귀속은 법인격이 있는 쪽에만 붙는다.
이걸 사다리로 읽으면 틀린다. 감시자는 설계자를 거친 사람만 할 수 있다. 무엇이 잘못됐는지 아는 감각이 설계 경험에서 나오기 때문이다. 그러니까 앞 단계가 사라지는 게 아니라 안 보이는 곳으로 들어간다. 쌓이는 것이지 이동하는 게 아니다.
그리고 이 배열은 직선이 아니라 고리에 가깝다. 책임을 지려면 읽어야 하고, 읽으려면 읽을 수 있는 양으로 잘라야 하고, 자르려면 검증 체계를 설계해야 한다. 책임자가 설계자로 돌아온다.
여기서 조건이 하나 붙는다. 책임만 오고 권한이 안 오면 그건 승진이 아니라 방패막이다. 배포를 막을 거부권, 얼마나 만들지 정하는 속도 통제권, 검증에 쓸 자원을 정하는 권한. 이 셋이 없이 책임만 오면 책임자가 아니라 피고인이다. 표준감사시간이 정확히 그 방어 장치였다.
세 번째가 특히 실감난다. 스레드에서 한 사람이 이렇게 짚었다.
중급 이상 대체하려면 모델 발전보다는 당장 컴퓨팅 파워 부족으로 힘들어요. 데이터센터 1개도 건설하는 데 한참 걸리니. 그리고 가면 갈수록 정액제는 점점 너프될 거고 API 사용하도록 유도하고 가격도 올리겠죠.
토큰 예산이 검증에 쓸 수 있는 양을 정하고, 검증량이 품질 상한을 정한다. 그런데 그 예산을 정하는 사람과 결과에 서명하는 사람이 다르면, 서명자는 자기가 통제하지 못한 조건의 결과를 떠안는다. 감사 보수가 깎이면 감사 시간이 줄고 서명이 형식이 되는 것과 같은 구조다.
그래서 "개발자가 책임을 가져간다"는 문장에는 조건이 붙어야 한다. 예산과 속도와 거부권이 같이 오느냐. 안 오면 그건 책임 이전이 아니라 책임 전가다.
순서는 그런데 반대로 간다. 의사도 변호사도 회계사도 실력이 좋아서 권한을 받은 게 아니다. 먼저 책임을 졌기 때문에 권한이 따라왔다. 개발자는 지금까지 그 책임을 지지 않았고, 그래서 오래 "코더"였다. 지시받아 만들고 문제가 나면 요구사항이 그랬다고 말할 수 있는 자리 말이다.
만드는 일이 값싸질수록 그 자리는 좁아진다. 남는 건 서명하는 자리다.
실무에서는 몇 줄로 줄어든다
거창한 제도 이야기를 걷어내면 당장 지킬 수 있는 건 짧다.
- "AI가 짠 거라 몰랐다"는 변명으로 성립하지 않는다.
- 리뷰 없이 머지한 것도 내 코드다.
- 이해하지 못한 코드는 머지하지 않는다.
- 생산량을 자기가 책임질 수 있는 크기로 제한하는 것도 실력이다.
마지막 줄이 조직과 정면으로 부딪힌다. 조직은 속도를 요구하고 책임은 분산시키려 한다. 그래서 이 방향은 저절로 오지 않는다.
그리고 이건 자발적으로 온 적이 없다
이 글에서 근거로 든 제도들에는 공통점이 있다. 전부 사고 이후에 생겼다.
엔론과 월드컴이 터지고 나서 사베인스-옥슬리법이 왔다. 아서앤더슨이 사라지고 나서 감사 독립성 규제가 왔다. 대우조선해양 분식회계로 회계사들이 실형을 받고 나서 신외감법이 왔다. 표준감사시간도 그 개정의 일부였다.
먼저 온 적이 없다. 업계가 스스로 "우리가 책임을 지겠습니다" 하고 만든 게 아니라, 사고가 나고 사람이 감옥에 가고 회사가 사라진 다음에 왔다.
그러니 개발도 같은 경로를 갈 가능성이 높다. 손해가 특정되는 영역부터 먼저 온다. 금융, 의료, 항공이다. 나머지는 한 번 크게 터진 다음에 온다. 소프트웨어 장애는 손해 산정이 흐리고 책임 소재가 계약서 안에 묻히기 때문에 그 시점이 더 늦을 것이다.
이건 비관이 아니라 진단이다. 그리고 진단이 맞다면, 제도가 오기 전에 개인이 먼저 그 자리에 서 있는 것과 제도에 떠밀려 서는 것은 다른 결과를 낳는다. 전자는 권한을 요구할 근거가 되고 후자는 처벌을 피하는 절차가 된다.
처음 스레드로 돌아가면, 46명이 "AI가 얼마나 잘하느냐"를 다투는 동안 서명 이야기를 꺼낸 사람은 없었다. 정확히 말하면 여러 명이 꺼냈는데 그런 줄 몰랐다. "개발자들도 AI 활용해서 작업해도 코드 다 검토합니다", "자신이 코드 이해하고 얘가 뭔 삽질 하는지 아는 것도 봐야 합니다", "내부가 점점 망가지고 있는지 잘못 이해하고 코드를 수정하고 있는지 알지 못합니다". 표면은 전부 능력 얘기지만 내용은 답할 사람에 관한 얘기다. 능력 논쟁의 문법으로 말해서 서로 만나지 못했을 뿐이다.
질문을 바꿔 적으면 이렇게 된다.
초중급 개발자가 망했느냐가 아니라, 그 코드에 누가 서명하느냐다.
AI가 장부를 다 만들어도 감사의견에는 회계사가 서명한다. 소장을 대신 써줘도 변호사가 서명한다. 항공기 소프트웨어에는 DER이 있다. 코드에는 아직 없다. 그 자리를 개발자가 가져가는 것이 이 직업이 다음으로 갈 방향이라고 생각한다.
댓글
댓글 쓰기