AI는 생산적으로 보이게 만드는 것을 위험할 정도로 쉽게 만듭니다.

스크린샷은 인상적으로 보일 수 있습니다. 데모는 세련되어 보일 수 있습니다. 생성된 기사는 매끄럽게 읽힐 수 있습니다. GitHub 저장소는 깔끔한 README, 배지, 다이어그램, 그리고 자신감 넘치는 약속을 담고 있을 수 있습니다. 하지만 만약 제가 개발자가 실제로 생각하고, 구축하고, 테스트하고, 수정하고, 책임을 질 수 있는지 이해하려고 노력한다면, 최종 결과물(artifact)만으로는 더 이상 충분하지 않습니다.

최종 결과물은 무엇이 살아남았는지를 보여줍니다.

그것이 무엇을 거부했는지를 항상 보여주는 것은 아닙니다.

그 차이가 핵심이 되고 있습니다.

저는 AI를 숨기고 싶어 하는 사람으로서 이 글을 쓰는 것이 아닙니다. 저도 AI를 헤비하게 사용합니다. 글을 쓰고, 코드를 짜고, 검사하고, 구조를 잡고, 제 자신의 가정(assumptions)과 논쟁하며, 그렇지 않았다면 머릿속에 갇혀 있었을 작업들을 더 빠르게 처리하기 위해 AI를 사용합니다. 하지만 AI를 더 많이 사용할수록, 한 가지 사실을 더 확신하게 됩니다. 향후 몇 년간의 진지한 포트폴리오는 스크린샷으로 만들어지지 않을 것입니다. 그것은 흔적(trace)으로 만들어질 것입니다.

작업 흔적(work trace)은 의도와 결과 사이의 읽을 수 있는 사슬입니다.

그것은 다음과 같이 말합니다: 이것이 문제였고, 이것이 계획이었으며, 이것이 변경된 부분이고, 이것이 실패한 부분이며, 이것이 내가 확인한 것이고, 이것이 내가 주장하기를 거부한 것이며, 이것이 내가 내 이름으로 서명할 용의가 있는 최종 결과물이라고 말입니다.

그 지점에서 개발자가 다시 눈에 보이게 됩니다.

문제는 AI의 도움이 아닙니다. 문제는 보이지 않는 판단입니다.

AI의 도움은 이미 개발자 업무의 일부입니다. 그렇지 않은 척하는 것은 날이 갈수록 무의미해지고 있습니다. 개발자는 보일러플레이트(boilerplate)를 요청하거나, 함수를 리팩터링(refactor)하거나, 테스트 계획을 생성하거나, 사양(spec)을 요약하거나, 풀 리퀘스트(pull request) 초안을 작성하거나, 디자인 옵션을 비교할 수 있습니다. 그것이 자동으로 그 작업을 가짜로 만드는 것은 아닙니다.

진짜 질문은 더 날카롭습니다:

개발자가 생성된 내용을 이해했는가?

그들이 그것을 테스트했는가?

그들이 취약한 가정(assumptions)을 검사했는가?

그들이 비밀(secrets)을 보존했는가?

그들이 언제 멈춰야 할지를 알았는가?

그들이 최종 결정을 내렸는가?

그것이 제가 신경 쓰는 경계선입니다. "AI가 관여했는가?"가 아니라 "인간의 책임이 사슬의 어느 지점에 개입했는가?"입니다.

흔적이 없다면 모든 것은 평면적인 표면으로 붕괴됩니다. 데모는 증거처럼 보이고, 자신감 넘치는 문단은 전문 지식처럼 보이며, 다이어그램은 아키텍처(Architecture)처럼 보입니다. 스쳐 지나가는 스크린샷은 검증된 결과처럼 보입니다. 하지만 진지한 빌더(Builder)라면 결과물이 아무리 다듬어져 있어도 그 속은 비어 있을 수 있다는 사실을 알고 있습니다. 작업이 중요한 이유는 그 이면에 담긴 결정(Decisions) 때문입니다.

저는 그러한 결정들을 조사할 수 있게 만드는 포트폴리오를 원합니다.

DEV는 이미 올바른 방향을 가리키고 있습니다

DEV 에디터의 한 가지 디테일이 제 눈길을 끌었습니다. 그것은 Markdown, 리치 임베드(Rich embeds), 그리고 코딩 에이전트(Coding-agent) 세션을 임베드할 수 있는 가시적인 가이드를 지원한다는 점입니다. 제가 DEV가 공식적으로 저의 포트폴리오 방식을 지지한다고 말하는 것은 아닙니다. 그것은 너무 과한 표현일 것입니다. 제가 말하고자 하는 것은 글쓰기 환경(Writing surface) 그 자체가 기술적 퍼블리싱(Technical publishing)이 어디로 향하고 있는지를 보여준다는 것입니다.

개발자의 글쓰기는 더 이상 최종적인 산문(Prose)에만 국한되지 않습니다.

그것은 과정을 담을 수 있습니다.

그것은 코드를 담을 수 있습니다.

그것은 세션(Sessions)을 담을 수 있습니다.

그것은 증거를 담을 수 있습니다.

이것이 중요한 이유는 개발자 기사가 결론뿐만 아니라 경로를 보여줄 때 훨씬 더 유용하기 때문입니다. 다듬어진 튜토리얼은 문법(Syntax)을 가르칠 수 있지만, 추적된 빌드(Traced build)는 판단력(Judgment)을 가르칩니다. 추적된 빌드는 추한 부분들, 즉 잘못된 시도, 수정 과정, 경계선, 테스트, 그리고 지름길을 거부한 이유를 보여줍니다.

그곳에서 신뢰가 시작됩니다.

기존의 포트폴리오 모델은 속이기가 너무 쉽습니다

전형적인 포트폴리오 패턴은 익숙합니다:

• 대표 스크린샷,
• 짧은 프로젝트 설명,
• 기술 배지(Technology badges),
• 저장소(Repository) 링크,
• 배포(Deployment) 링크,
• 어쩌면 케이스 스터디(Case study).

그러한 구조는 여전히 가치가 있습니다. 저는 그것을 버리려는 것이 아닙니다. 하지만 표면적인 결과물(Artifacts)을 만들어내는 비용이 급락했기 때문에, 이제 그 구조는 더 취약해졌습니다.

랜딩 페이지를 생성할 수 있습니다.

다이어그램을 생성할 수 있습니다.

README를 생성할 수 있습니다.

데모 스크립트를 생성할 수 있습니다.

심지어 긴 설명조차 생성할 수 있습니다.

따라서 포트폴리오는 한 단계 더 깊이 들어가야 합니다. 무엇이 만들어졌는가뿐만 아니라, 빌더가 불확실성(Uncertainty)을 어떻게 다루었는지를 보여주어야 합니다.

저에게 가장 강력한 신호는 완벽함이 아닙니다. 그것은 교정(Correction)입니다. 첫 번째 계획이 틀렸고 빌더가 경로를 변경했던 지점을 보여주세요. 실패한 테스트를 보여주세요. 과장된 주장(Overclaiming)으로부터 프로젝트를 보호한 결정을 보여주세요. 비밀 정보가 공개 파일에 포함되지 않도록 막아낸 경계선을 보여주세요. 빌더가 "이것은 좋아 보이지만, 아직 검증되지 않았습니다"라고 말한 순간을 보여주세요.

그것은 약점이 아닙니다. 그것은 프로페셔널한 압박(Professional pressure)입니다.

작업 흔적(Work Trace) 포트폴리오

다음은 제가 제 자신의 작업에 사용하고자 하며, 다른 1인 빌더(Solo builders)들에게 추천하는 모델입니다.

모든 진지한 포트폴리오 결과물은 6개의 블록을 가져야 합니다.

1. 문제 (The problem)

문제를 평이한 언어로 기술하세요. 마케팅용 버전이 아니라, 실제 버전이어야 합니다.

무엇이 고장 났거나, 혼란스럽거나, 느리거나, 위험하거나, 누락되었거나, 혹은 테스트할 가치가 있었나요?

문제가 모호하다면 나머지 작업은 연극(Theatre)이 되어버립니다. 강력한 문제 정의(Problem statement)는 그 자체로 사고의 증거가 됩니다. 빌더가 자신이 무엇을 해결하려고 하는지 알고 있다는 것을 보여주기 때문입니다.

2. 계획 (The plan)

실행 전의 계획을 보여주세요. 길 필요는 없지만, 구체적이어야 합니다.

어떤 파일, 시스템, 데이터, 또는 인터페이스가 범위(Scope)에 포함되었나요?

범위 외(Out of scope)였던 것은 무엇인가요?

무엇을 성공으로 간주했나요?

무엇이 시도를 실패하게 만들 수 있었나요?

이 지점에서 AI 보조 작업(AI-assisted work)은 더욱 정직해집니다. 빌더가 계획을 보여주고, 그 후 실행이 어떻게 그 계획을 따랐는지 혹은 변경했는지를 보여줄 수 있다면, 독자는 마술(Magic trick) 대신 지도(Map)를 얻게 됩니다.

3. 인간의 결정 (The human decisions)

중요했던 결정들을 나열하세요.

모든 프롬프트(Prompt)나 모든 대화 내용을 나열하라는 것이 아닙니다. '결정'을 나열하세요.

왜 이 구현 방식(Implementation)을 선택했나요?

왜 지름길(Shortcut)을 거부했나요?

왜 주장을 더 작게 유지했나요?

왜 더 단순한 도구를 사용했나요?

왜 결과가 게시될 준비가 되지 않았다고 결정했나요?

이것이 흔적(Trace)의 핵심입니다. 포트폴리오는 AI가 그곳에 없었던 것처럼 가장해서는 안 됩니다. 인간이 여전히 책임을 지고 있었음을 보여주어야 합니다.

4. 작업 증거 (The work evidence)

물질적인 증거를 보여주세요.

그것은 커밋 (commit), 디프 (diff), 테스트 출력 (test output), 스크린샷 (screenshot), 노트북 (notebook), 소스 테이블 (source table), 디자인 아티팩트 (design artifact), 검증 보고서 (validation report), 또는 짧은 기술 노트 (technical note)가 될 수 있습니다. 형식은 프로젝트에 따라 달라질 수 있습니다. 원칙은 동일합니다. 독자에게 단순한 주장보다 더 강력한 무언가를 제공하십시오.

코드의 경우, 저는 커밋 해시 (commit hashes), 테스트 명령 (test commands), 그리고 최소 재현 노트 (minimal reproduction notes)를 선호합니다.

글쓰기의 경우, 저는 소스 레지스터 (source registers), 증거 경계 (evidence boundaries), 그리고 수정 노트 (correction notes)를 선호합니다.

데이터 작업의 경우, 저는 데이터셋 소스 (dataset source), 변환 단계 (transformation step), 차트의 한계 (chart limitation), 그리고 해당 차트가 증명할 수 없는 것이 무엇인지를 선호합니다.

증거가 거대할 필요는 없습니다. 검사 가능 (inspectable)해야 합니다.

5. 수정 로그 (The correction log)

이 부분은 대부분의 사람들이 숨기는 부분입니다.

저는 이것이 강점이 되어야 한다고 생각합니다.

처음에 무엇을 오해했습니까?

AI가 무엇을 틀렸습니까?

다른 리뷰어가 무엇을 잡아냈습니까?

너무 강한 주장이라서 무엇을 삭제했습니까?

증거가 준비되지 않아 무엇을 미루었습니까?

생성된 자신감이 넘쳐나는 세상에서, 가시적인 수정 (visible correction)은 신뢰성의 신호입니다.

6. 최종 경계 (The final boundary)

각 포트폴리오 작업물의 끝을 명확한 경계로 마무리하십시오.

무엇이 입증되었습니까?

무엇이 입증되지 않았습니까?

주장을 더 강화하기 위해 무엇이 필요합니까?

독자가 무엇을 가정해서는 안 됩니까?

이는 AI 보조 작업 (AI-assisted work)에서 특히 중요합니다. 제작자가 "합성 고정 장치 (synthetic fixture)에서 테스트된 프로토타입 (prototype)"이라고 말한다면, 그것은 검증된 제품인 척하는 것보다 더 강력합니다. 작가가 "이것은 정보에 기반한 의견이며 법적 조언이 아닙니다"라고 말한다면, 추측을 확신처럼 꾸미는 것보다 더 강력합니다.

경계는 권위의 상실이 아닙니다. 경계는 권위가 신뢰할 수 있게 되는 방식입니다.

게시해서는 안 되는 것

작업 흔적 (work trace)은 가공되지 않은 덤프 (raw dump)가 아닙니다.

.env 파일을 게시하지 마십시오.

API 키 (API keys)를 게시하지 마십시오.

개인적인 이메일을 게시하지 마십시오.

고객 데이터를 게시하지 마십시오.

클라이언트나 고용주로부터 받은 기밀 프롬프트 (confidential prompts)를 게시하지 마십시오.

자격 증명 (credentials), 토큰 (tokens), 비밀 정보가 포함된 로그 (logs with secrets), 개인 식별자 (private identifiers), 또는 공유할 권한이 없는 자료를 게시하지 마십시오.

추적 가능성 (Traceability)은 과시욕이 아닙니다. 그것은 절제된 증거입니다.

목표는 개인적인 자료를 노출하거나 독자를 포렌식 조사관 (forensic investigator)으로 만들지 않으면서, 신뢰를 구축할 수 있을 만큼 충분한 프로세스를 보여주는 것입니다. 좋은 작업 흔적 (trace)은 큐레이션 된 것입니다. 정직하지만, 무모하지는 않습니다.

이것이 1인 개발자에게 중요한 이유

대기업은 평판을 살 수 있습니다. 그들에게는 브랜드 중력 (brand gravity), 채용 신호 (hiring signals), 컨퍼런스 발표 기회, 유료 배포 채널, 그리고 제도적 신뢰가 있습니다. 1인 개발자는 더 작은 도구들을 사용하여 공개적으로 신뢰를 얻어야 합니다.

그것은 어렵습니다.

하지만 가능하기도 합니다.

작업 흔적 (work trace)은 1인 빌더가 일상적인 업무를 전문적인 증거로 전환할 수 있게 해줍니다. 하나의 아티클은 단순한 포스트 그 이상이 됩니다. 그것은 증명 객체 (proof object)가 됩니다. 하나의 버그 수정 (bug fix)은 단순한 커밋 (commit) 그 이상이 됩니다. 그것은 의사결정 기록 (decision record)이 됩니다. 하나의 프로토타입 (prototype)은 단순한 데모 (demo) 그 이상이 됩니다. 그것은 한계점이 문서화된 시도가 됩니다.

이는 클라이언트, 고용주, 협업자, 그리고 독자들에게 중요합니다. 만약 누군가가 내가 AI를 사용하여 책임감 있게 구축할 수 있는지 알고 싶어 한다면, 나는 세련된 홈페이지로만 대답하고 싶지 않습니다. 나는 그 과정을 보여주는 체인 (chain)을 보여주고 싶습니다.

여기에 내가 발견한 문제가 있습니다.

여기에 내가 작업을 계획한 방식이 있습니다.

여기에 AI가 도움을 준 부분이 있습니다.

여기에 내가 AI의 의견을 거부한 부분이 있습니다.

여기에 내가 테스트한 내용이 있습니다.

여기에 실패한 내용이 있습니다.

여기에 내가 주장할 수 있는 것이 있습니다.

여기에 내가 아직 주장할 수 없는 것이 있습니다.

그것이 갤러리 (gallery)보다 더 강력한 포트폴리오입니다.

개발자의 기술은 상향 이동하고 있습니다

이 부분이 내가 가장 관심을 두는 지점입니다.

AI는 기술의 필요성을 없애지 않습니다. 기술의 위치를 이동시킵니다.

보일러플레이트 (boilerplate)를 작성하는 시간은 줄어듭니다.
무엇이 존재해야 하는지 결정하는 시간은 늘어납니다.

구문 (syntax)을 암기하는 시간은 줄어듭니다.
가정 (assumptions)을 확인하는 시간은 늘어납니다.

초안을 포맷팅하는 시간은 줄어듭니다.
그 초안이 공개될 가치가 있음을 증명하는 시간은 늘어납니다.

표면 (surface)을 만들어내는 시간은 줄어듭니다.
의미 (meaning)를 관리하는 시간은 늘어납니다.

이것은 퇴보가 아닙니다. 더 어려운 게임이 된 것입니다.

이러한 환경에서 승리하는 개발자는 가장 많은 결과물 (output)을 생성할 수 있는 사람이 아닐 것입니다. 대신, 생성된 결과물을 책임감 있는 작업 (responsible work)으로 전환할 수 있는 사람일 것입니다. 코드를 읽고, 엣지 케이스 (edge case)를 테스트하며, 비밀 (secret)을 보존하고, 불확실성 (uncertainty)에 이름을 붙이며, 과장된 주장을 하기 전에 글을 멈출 줄 아는 사람 말입니다.

그렇기 때문에 포트폴리오도 진화해야 합니다.

나의 실전 템플릿

만약 이것을 재사용 가능한 DEV 포스트 템플릿으로 축약해야 한다면, 저는 다음과 같은 형식을 사용할 것입니다:

## 문제 (Problem)
실제 문제는 무엇이었나요?

...

이 템플릿은 매일 사용하기에 충분히 간단하면서도, 진지한 빌더 (builder)와 소음 생성기 (noise machine)를 구분해낼 만큼 강력합니다.

거대한 보고서를 요구하지 않습니다.

절제력 (discipline)을 요구할 뿐입니다.

이 글을 위한 실시간 작업 흔적 (work trace)

이 글 또한 스스로 정한 규칙에서 벗어나서는 안 됩니다.

오늘의 작업은 깔끔한 에세이로 시작되지 않았습니다. 긴 기획 스레드 (planning thread), 활성화된 브라우저 탭, 플랫폼의 제약, 그리고 하나의 질문에서 시작되었습니다: '어제 작성한 AI 툴링 (AI tooling) 관련 글을 반복하지 않으면서 어떻게 연관된 내용을 쓸 수 있을까?'

첫 번째 결정은 경계 (boundary)였습니다. 이 DEV 포스트는 HackerNoon 기사의 복사본이 될 수 없었습니다. 동일한 강도를 유지하되, 대상 (object)을 바꿔야 했습니다. 그래서 주제가 사용 제한 (usage limits)에서 개발자의 신뢰성 (developer credibility)으로 이동했습니다. 이 결정은 매우 중요한데, 왜냐하면 쉬운 길, 즉 '같은 논거를 다시 쓰고 몇 단락만 바꿔서 독창적인 것처럼 꾸미는 길'을 차단했기 때문입니다.

두 번째 결정은 플랫폼이었습니다. DEV는 HackerNoon이 아닙니다. DEV는 마크다운 (Markdown) 에디터, 4개의 태그, 미리보기, 커버 가이드, 임베드 (embeds), 그리고 로그 (logs), 디프 (diffs), 테스트 (tests), 트레이스 (traces)를 이해하는 개발자 관객을 제공합니다. 이것이 글의 성격을 바꾸어 놓았습니다. 또 다른 다듬어진 의견 기사를 쓰는 대신, 개발자가 실제로 재사용할 수 있는 포트폴리오 방법론을 쓰는 것이 더 나은 선택이었습니다.

세 번째 결정은 인간의 책임이었습니다. 저는 "AI가 나를 도왔다"라고 고백하듯 말하거나, "AI가 이것을 만들었다"라고 마술처럼 말하는 기사를 원하지 않았습니다. 저는 그보다 더 유용한 문장을 원했습니다: AI가 작업을 보조했지만, 인간은 책임의 사슬 (responsibility chain)을 가시적으로 유지해야 한다는 것입니다.

네 번째 결정은 초안이 괜찮아 보인 후에 이루어졌습니다. 기사는 작업 흔적 (work traces)을 주장하고 있었지만, 정작 그 자체에는 흔적이 포함되어 있지 않았습니다. 그것은 모순이었습니다. 몇 시간 동안의 계획, 작성, 검토 및 미리보기를 거친 후 15:19에, 누락된 증거가 명확해졌습니다: 만약 논지가 실제라면, 기사 자체에도 흔적이 필요하다는 사실 말입니다.

그래서 여기 그 흔적을 공개합니다: