내 프로젝트 설명하기 - 왜·어떻게·무엇이 어려웠나

이 장에서 배우는 것

앞 장에서 자신을 짧게 소개했다면, 이제는 그 소개를 뒷받침할 프로젝트를 설명할 차례다. 면접관은 완성 화면만 보고 지원자의 역량을 판단하기 어렵다. 어떤 문제를 해결하려 했는지, 어떤 선택을 했는지, 실제로 어디까지 맡았는지를 듣고 판단한다. 프로젝트 규모가 작아도 선택과 검증 과정을 구체적으로 설명하면 충분히 대화의 출발점이 된다.

이 장에서는 가상의 중고 거래 서비스 ‘다시장터’를 만든 지원자가 프로젝트 질문에 답하는 과정을 살펴본다. 사례의 경험과 수치는 설명을 위해 구성한 것이다. 독자는 자신의 기록에 맞게 바꾸어야 하며, 사례의 성과를 자신의 경험처럼 사용해서는 안 된다.

• 프로젝트 소개를 문제와 목표, 선택과 담당 범위, 결과와 한계의 세 부분으로 구성한다.
• 기술 이름보다 선택 기준과 비교 대상을 먼저 설명한다.
• 팀의 결과와 자신이 직접 수행한 작업을 구분한다.
• 어려웠던 문제를 관찰, 가설, 확인, 수정, 재확인의 순서로 설명한다.
• 측정 기록과 저장소 자료를 근거로 설명문을 점검한다.

문제 상황

지원자는 상품 등록과 목록 조회 기능이 있는 팀 프로젝트를 제출했다. 저장소 첫 화면에는 실행 화면과 사용 기술 목록이 있고, 소개문에는 “우리가 빠르고 편리한 서비스를 구현했다”라고 적혀 있다. 면접관이 “본인이 해결한 문제를 하나 설명해 달라”라고 묻자 지원자는 화면 기능을 순서대로 소개한다. 이어 “검색이 빨라졌다는 근거가 있는가”라는 질문에는 체감상 빨랐다고 답한다.

문제는 프로젝트가 작다는 데 있지 않다. 기능 설명만으로는 지원자의 판단을 확인하기 어렵다는 데 있다. 상품을 등록할 수 있다는 사실과, 등록 과정에서 발생한 문제를 찾아 수정했다는 경험은 서로 다른 정보다. 팀 전체가 만든 기능을 자신의 작업처럼 말하면 담당 범위를 확인하는 질문에서 설명이 흔들린다.

다시장터 팀의 목표는 제한된 기간 안에 상품 등록과 검색 흐름을 끝까지 연결하는 것이었다. 지원자는 검색 조건 처리와 관련 검증을 맡았다. 화면과 상품 등록 처리는 다른 팀원이 담당했다. 이제 지원자는 이 경계를 유지하면서도 자신의 기여가 드러나는 답변을 준비해야 한다. 소개문을 점검하는 작은 프로그램도 만들어, 역할 표현과 수치 주장, 기술 나열을 실제로 찾아본다.

프로젝트 소개는 문제·선택·검증으로 구성한다

프로젝트 소개의 세 부분은 기능 목록을 줄이는 요약법이 아니다. 듣는 사람이 다음 질문을 고를 수 있도록 판단의 근거를 배치하는 방법이다. 첫 부분에서는 누구의 어떤 불편을 해결하려 했는지 말한다. 두 번째에서는 그 목표를 위해 무엇을 선택했고 자신이 어디를 맡았는지 말한다. 마지막에서는 무엇을 확인했으며 아직 무엇을 확인하지 못했는지 말한다.

문제와 목표에는 대상 사용자의 행동이 들어가야 한다. “중고 거래 서비스를 만들었다”보다 “물건을 찾는 사람이 제목과 가격 조건을 함께 적용할 수 있도록 만들었다”가 구체적이다. 실제 사용자 조사를 하지 않았다면 조사로 확인한 요구처럼 말하지 않는다. 팀이 세운 사용 상황이라고 밝히면 된다.

선택과 담당 범위에는 기술 이름보다 판단이 들어가야 한다. 결과와 한계에는 실행 가능한 기능, 검증한 범위, 남아 있는 제약이 들어간다. 성능 수치가 없어도 결과를 설명할 수 있다. 여러 조건을 함께 입력했을 때 기대한 상품만 반환되는지 확인한 기록도 결과의 근거다.

프로젝트 면접에서 자주 나오는 질문과 확인 의도

질문	의도	답변 핵심	꼬리 질문
어떤 프로젝트인가	핵심을 구조화하는가	문제, 선택, 검증을 연결한다	가장 중요한 사용자 행동은 무엇인가
왜 그 기술을 골랐는가	선택 기준이 있는가	제약과 비교 대상, 손익을 말한다	다른 선택은 왜 미뤘는가
본인이 맡은 부분은 무엇인가	개인 기여가 분명한가	직접 작업과 공동 결정을 나눈다	직접 수정한 파일을 설명할 수 있는가
가장 어려웠던 문제는 무엇인가	문제 해결 과정을 아는가	증상부터 재확인까지 연결한다	첫 가설이 틀렸다면 어떻게 했는가
해결됐다는 것을 어떻게 알았는가	확인 기준이 있는가	기대 결과와 실제 결과를 비교한다	남아 있는 경우는 무엇인가
얼마나 개선됐는가	수치의 근거를 아는가	조건, 기준값, 기록을 제시한다	반복 측정에서도 같았는가
다시 만든다면 무엇을 바꾸겠는가	경험에서 배웠는가	관찰한 문제와 변경 순서를 연결한다	가장 먼저 바꿀 한 가지는 무엇인가
팀에서 함께 결정한 일은 무엇인가	협업의 경계를 이해하는가	제안, 검토, 결정의 주체를 나눈다	본인의 제안이 반영되지 않은 적은 있는가
저장소에서 무엇을 보면 되는가	설명을 재확인할 수 있는가	실행 안내와 변경 기록을 연결한다	처음 받은 사람이 실행할 수 있는가
아직 모르는 부분은 무엇인가	경험의 범위를 아는가	미확인 사항과 확인 방법을 말한다	어떤 자료를 먼저 모으겠는가

질문 하나: “어떤 프로젝트인지 소개해 달라”

첫 답변에서는 세부 구현을 모두 설명하려고 하지 않는다. 면접관이 전체 그림을 이해하고 담당 부분으로 들어올 수 있으면 된다. 다음 답변은 결론을 먼저 제시하고, 목표의 근거, 자신의 작업, 한계를 차례로 붙인 예다.

다시장터는 제목과 가격 조건으로 중고 상품을 찾는 흐름을 구현한 팀 프로젝트다. 팀이 정한 핵심 사용 상황이 원하는 가격대의 물건을 찾는 것이어서, 등록과 검색을 우선 완성했다. 제가 맡은 부분은 검색 조건을 처리하고 결과를 확인하는 작업이다. 조건 조합에 따라 기대한 상품이 반환되는지는 확인했지만, 실제 사용자에게 검색 방식이 편리한지는 검증하지 못했다. 다음에는 사용자가 조건을 고르는 과정을 관찰해 개선 우선순위를 정하겠다.

면접관이 “채팅이나 결제는 없는가”라고 물으면 빠진 기능을 변명하지 않는다. 이번 목표와 범위를 설명하면 된다.

이번 범위에는 포함하지 않았다. 팀이 정한 기간 안에 상품 등록과 검색을 연결하는 것이 우선이었다. 거래 완료까지 지원하는 서비스로 확장하려면 추가 흐름이 필요하지만, 현재 결과로 그 부분까지 완성했다고 말할 수는 없다.

면접관은 여기서 기능 수보다 범위 판단을 확인한다. 다만 실제 팀에서 이런 우선순위 논의를 하지 않았다면 사후에 있었던 결정처럼 꾸미면 안 된다. 처음에는 범위를 넓게 잡았다가 줄였다는 경험도, 그 이유와 결과를 설명하면 답변이 된다.

선택 이유와 개인 기여를 근거로 설명한다

기술 선택 질문은 정답 기술의 이름을 맞히는 문제가 아니다. 당시 알고 있던 것, 남은 시간, 구현 범위 가운데 무엇을 기준으로 선택했는지를 묻는다. 익숙해서 골랐다는 이유도 유효하다. 익숙함이 어떤 비용을 줄였으며 무엇을 포기하게 했는지까지 설명해야 판단이 드러난다.

질문 둘: “왜 Python을 선택했는가”

이번에는 팀이 이미 사용해 본 Python을 선택해 검색 기능을 끝까지 구현하는 데 집중했다. 새로운 언어를 익히는 시간보다 조건 처리와 결과 검증에 시간을 쓰는 것이 목표에 맞다고 판단했다. 제가 검색 조건을 함수로 나누고 입력별 결과를 확인하는 작업을 맡았고, 팀원도 같은 언어로 코드를 검토할 수 있었다. 다만 이 선택만으로 처리 성능이 충분하다고 확인한 것은 아니다. 실행 시간이 문제가 되면 먼저 병목을 측정하고, 구현 개선과 다른 선택의 비용을 비교하겠다.

“다른 언어와 직접 비교했는가”라는 꼬리 질문에는 비교의 깊이를 구분한다. 문서를 읽은 것, 짧은 코드를 작성한 것, 같은 조건에서 측정한 것은 각각 다른 수준의 근거다.

같은 기능을 다른 언어로 구현해 비교하지는 않았다. 당시 선택의 근거는 팀의 사용 경험과 구현 일정이었다. 따라서 다른 언어보다 빠르거나 생산성이 높다는 결론까지 내릴 수는 없다.

선택 이유를 준비할 때에는 후보를 뒤늦게 늘려 놓지 않는다. 실제로 고민한 대안이 없다면 그 사실을 밝히고, 지금 다시 판단한다면 어떤 기준으로 비교할지 설명한다. 경험의 범위를 정확히 말하는 편이 하지 않은 실험을 주장하는 것보다 후속 대화에 도움이 된다.

질문 셋: “본인이 직접 한 일은 무엇인가”

제가 직접 맡은 부분은 검색 조건 처리와 해당 동작의 검증이다. 상품 등록과 화면 구성은 다른 팀원이 맡았고, 검색 입력 형식은 함께 정했다. 저는 빈 입력을 처리하는 함수와 조건 조합별 확인 자료를 작성했다. 팀원이 제안한 경계값도 반영했다. 따라서 검색 결과의 동작은 설명할 수 있지만, 화면 구현 전체를 제 작업이라고 말할 수는 없다. 함께 수정한 부분은 변경 기록을 보며 제 수정과 검토 의견을 구분해 설명하겠다.

“기여도를 비율로 말해 달라”는 질문을 받아도 근거 없는 백분율을 만들 필요는 없다. 줄 수나 변경 횟수는 작업의 난도와 영향까지 보여 주지 않는다. 수치로 정한 기준이 없다면 담당 기능과 산출물로 답변을 구체화한다.

팀에서 합의한 기여도 산정 기준이 없어 비율로 답하기는 어렵다. 대신 제가 작성한 검색 처리 함수, 확인 사례, 관련 변경 기록을 제시할 수 있다. 공동 결정은 별도로 구분하겠다.

‘우리’와 ‘제가’의 사용 횟수에도 정답 비율은 없다. 팀의 목표와 결과에는 ‘우리’가 자연스럽고, 자신의 행동에는 ‘제가’가 자연스럽다. 두 표현을 세는 목적은 지원자의 협업 태도를 점수화하는 데 있지 않다. 팀 이야기만 있고 자신의 행동이 빠졌는지, 공동 작업을 모두 개인 성과로 서술했는지 다시 읽을 지점을 찾는 데 있다.

같은 질문에 대한 나쁜 답·보통 답·좋은 답의 차이

질문	나쁜 답	보통 답	좋은 답
어떤 프로젝트인가	상품 등록도 있고 검색도 있다	중고 상품을 등록하고 찾는 서비스다	사용 상황과 우선 범위, 담당 작업, 확인 한계를 연결한다
왜 그 기술인가	많이 쓰여서 골랐다	팀이 익숙해서 골랐다	익숙함이 줄인 비용과 검증하지 못한 부분을 설명한다
무엇을 맡았는가	우리가 전체를 만들었다	검색을 담당했다	직접 작성, 공동 결정, 다른 팀원의 작업을 구분한다
어떤 문제가 어려웠는가	오류가 많았지만 해결했다	빈 입력 오류를 수정했다	재현 입력, 원인 확인, 수정과 재확인, 남은 한계를 설명한다

어려웠던 문제와 수치는 확인 과정으로 말한다

질문 넷: “가장 어려웠던 문제는 무엇이며, 다시 만든다면 무엇을 바꾸겠는가”

어려웠던 문제는 가장 복잡한 기술을 사용한 사건일 필요가 없다. 자신이 상황을 설명하고 확인 과정을 재구성할 수 있는 사건을 고른다. 문제를 발견한 계기와 원인을 알아낸 근거가 빠지면, 해결했다는 말만 남는다.

가장 어려웠던 문제는 가격 상한을 입력하지 않았을 때 검색 결과가 사라지는 현상이었다. 같은 상품이 상한을 지정하면 나타나고 빈칸이면 사라져, 상품 자체보다 조건 처리 문제라고 보았다. 먼저 같은 상품 목록과 입력으로 현상을 재현했고, 빈 값을 숫자 영으로 바꾸는 처리 때문에 의도하지 않은 상한이 생기는 것을 확인했다. 이후 빈 입력을 조건 없음으로 구분하고, 빈칸과 숫자 영을 각각 넣어 결과를 다시 확인했다. 다만 입력 처리가 여러 곳에 흩어져 있어 누락 위험이 남았다. 다시 만든다면 입력 해석을 한곳에 모으고 조건별 기대 결과를 먼저 정리하겠다.

면접관이 “처음부터 원인을 알았는가”라고 물으면 실제 탐색 과정을 설명한다. 처음에는 저장된 상품의 가격을 의심했으나 같은 자료에서 입력만 바꾸어 비교하면서 범위를 좁혔다고 답할 수 있다. 틀린 가설을 숨기는 것보다 어떤 관찰로 가설을 버렸는지 설명하는 편이 문제 해결 과정을 보여 준다.

면접관: 수정한 뒤 문제가 다시 생기지 않는다고 어떻게 확인했는가

지원자: 상한이 없는 경우, 영인 경우, 값이 있는 경우를 나눠 기대 결과와 비교했다. 확인한 입력에서는 문제가 재현되지 않았다. 가능한 모든 입력을 확인한 것은 아니므로, 추가 경계값을 정리해 같은 확인을 반복할 수 있게 남기겠다.

다시 만들 때의 변경도 관찰한 문제에서 출발한다. 새 기술을 도입하겠다는 말만으로는 변경 이유가 부족하다. 흩어진 입력 처리 때문에 확인이 어려웠다면 처리 위치를 모으는 것이 먼저일 수 있다. 바꿀 대상, 기대 효과, 확인 방법을 한 묶음으로 말하면 개선 제안이 구체적이 된다.

숫자는 이 과정을 압축해서 전달하지만, 기록이 없는 숫자는 근거를 대신하지 못한다. “검색이 50% 빨라졌다”라고 말하려면 무엇을 시간으로 쟀는지, 변경 전후의 조건이 같은지, 어떤 기준으로 계산했는지를 설명할 수 있어야 한다. 같은 입력과 환경에서 반복한 기록도 필요하다. 일부 실행의 결과를 전체 사용자 경험으로 확대해서는 안 된다.

실행 횟수와 개선율도 구분한다. 검색을 열두 번 실행했다는 기록은 확인 활동의 횟수다. 그 사실만으로 응답 시간이 줄었다거나 안정성이 높아졌다고 결론 내릴 수 없다. 측정하지 않았다면 “성능 개선율은 측정하지 않았다. 이번에 확인한 것은 조건별 결과의 정확성이다”라고 답한다. 이후 어떻게 측정할지 제안할 수 있지만 계획을 이미 얻은 결과처럼 표현하지 않는다.

포트폴리오 저장소는 이러한 설명을 다시 확인하는 입구다. 첫 안내 문서에는 프로젝트 목적, 구현 범위, 실행 명령, 실행 환경, 담당 부분, 주요 확인 자료의 위치를 적는다. 면접관이 찾아볼 대표 변경 기록에는 무엇이 잘못됐고 왜 수정했는지 남긴다. 화면 이미지에는 그 화면에서 확인할 행동을 덧붙인다. 이미지 자체가 내부 처리나 성능을 증명하지는 않는다.

환경 설정 예시에는 실제 비밀 값을 넣지 않는다. 필요한 설정 이름과 준비 절차를 설명하고, 실행하지 못하는 기능이나 준비되지 않은 자료는 표시한다. 저장소를 정리했다는 것은 모든 기록을 보기 좋게 숨겼다는 뜻이 아니다. 설명한 작업과 확인 근거까지 독자가 따라갈 수 있다는 뜻이다.

완성 코드

다음 프로그램을 main.py로 저장한다. Python 3.12 이상에서 표준 라이브러리만 사용한다. 설명문은 문장에 준하는 검토 단위로 나누어 목록에 넣는다. 프로그램은 역할 표현의 등장 횟수와 비율을 출력하고, 수치에 측정 표식이 없는 항목과 기술 이름만 나열한 것으로 의심되는 항목을 보여 준다.

이 실험의 대상은 프로젝트 소개문의 표현이다. 실제 검색 성능을 측정하는 프로그램은 아니다. ‘50%’는 근거 없는 주장을 찾아내기 위한 예시이며, 측정 표식도 사실을 보증하지 않는다. 자동 점검의 결과와 사람이 확인해야 하는 근거를 구분하는 것이 핵심이다.

import re

SENTENCES = [
    "우리 팀은 중고 상품을 찾는 서비스를 만들었다.",
    "제가 검색 조건 처리와 결과 검증을 맡았다.",
    "우리 서비스는 Python, SQLite, unittest를 사용했다.",
    "제가 검색 시간을 50% 줄였다.",
    "제가 고정된 입력으로 검색을 12회 실행했다. [측정: 검색 실험 기록]",
]

TECHNOLOGIES = ("Python", "SQLite", "unittest")
REASON_WORDS = ("때문", "위해", "선택", "비교", "제약")
NUMBER_PATTERN = re.compile(r"\d+(?:\.\d+)?(?:%|회|초|건)")
EVIDENCE_PATTERN = re.compile(r"\[측정:\s*([^\[\]]+)\]")


def has_evidence_marker(sentence):
    matches = EVIDENCE_PATTERN.finditer(sentence)
    return any(match.group(1).strip() for match in matches)


def inspect_sentences(sentences):
    counts = {
        word: sum(sentence.count(word) for sentence in sentences)
        for word in ("우리", "제가")
    }
    findings = []
    for index, sentence in enumerate(sentences, start=1):
        numbers = NUMBER_PATTERN.findall(sentence)
        if numbers and not has_evidence_marker(sentence):
            detail = ", ".join(numbers)
            findings.append((index, f"수치 근거 확인: {detail}", sentence))

        tech_count = sum(name in sentence for name in TECHNOLOGIES)
        has_reason = any(word in sentence for word in REASON_WORDS)
        if tech_count >= 2 and not has_reason:
            findings.append((index, "기술 나열 후보", sentence))
    return counts, findings


def main():
    counts, findings = inspect_sentences(SENTENCES)
    total = sum(counts.values())

    print("프로젝트 설명문 점검")
    print(f"검토 단위: {len(SENTENCES)}개")
    print("역할 표현: 등장 횟수 기준")
    for word, count in counts.items():
        ratio = count / total * 100 if total else 0.0
        print(f"- {word}: {count}회 ({ratio:.1f}%)")

    print(f"검토 후보: {len(findings)}건")
    for index, label, sentence in findings:
        print(f"- {index}번 | {label}")
        print(f"  {sentence}")

    print("주의: 비율은 기여도가 아니며, 측정 표식은 사실 검증이 아니다.")


if __name__ == "__main__":
    main()

줄별 해설

import re는 정규 표현식으로 수치와 측정 표식을 찾기 위해 사용한다. 입력 목록은 프로그램 안에 고정했다. 파일, 네트워크, 현재 시각, 난수를 사용하지 않으므로 같은 코드로 실행하면 출력이 같다. 문장 분리 정확도에 따라 결과가 달라지는 문제를 피하려고 검토 단위도 직접 지정했다.

SENTENCES에는 역할 표현, 기술 나열, 근거 없는 수치, 측정 표식이 있는 수치를 각각 넣었다. 마지막 항목의 ‘검색 실험 기록’은 실제 파일을 가리키지 않는 예시다. 표식 유무에 따른 동작 차이를 보여 줄 뿐, 프로그램이 기록을 읽거나 존재를 확인하지는 않는다.

TECHNOLOGIES는 이번 실험에서 찾을 이름을 정한다. REASON_WORDS는 선택 이유가 있을 가능성을 나타내는 단어다. 단어가 포함됐다고 논리적인 설명이 되는 것은 아니다. 반대로 이 단어 없이도 충분한 이유를 설명할 수 있다. 이 규칙은 판정기가 아니라 다시 읽을 위치를 줄이는 장치다.

NUMBER_PATTERN은 정수 또는 소수 뒤에 지정한 단위가 붙은 표현을 찾는다. 이번 입력의 50%와 12회가 해당한다. 단위 없는 숫자나 한글로 쓴 수, 밀리초 같은 다른 단위까지 처리하지는 않는다. 발견한 수치 역시 거짓이라는 뜻이 아니라 근거를 확인할 대상이라는 뜻이다.

EVIDENCE_PATTERN은 대괄호 안에 ‘측정:’으로 시작하는 표식을 찾는다. has_evidence_marker()는 표식 내부에 공백 이외의 내용이 있는지도 확인한다. 따라서 빈 표식만 붙이는 경우를 일부 걸러 낼 수 있다. 다만 ‘없음’처럼 의미 없는 내용을 적어도 통과하므로 사람의 검토는 여전히 필요하다.

inspect_sentences()의 첫 부분은 ‘우리’와 ‘제가’가 등장한 횟수를 합산한다. 문장 수가 아니라 문자열의 등장 횟수다. 한 항목에 같은 표현이 두 번 있으면 두 번 센다. 대명사를 생략한 문장의 주체를 추론하지 않으며, ‘저는’과 ‘우리 팀’의 다른 활용까지 별도 분석하지 않는다.

반복문은 입력 순서대로 항목을 확인한다. 수치가 있으면서 측정 표식이 없으면 첫 번째 규칙의 후보를 추가한다. 기술 이름이 두 종류 이상 있고 이유 단어가 없으면 두 번째 규칙의 후보를 추가한다. 한 항목이 두 규칙에 모두 걸리면 후보도 두 건이다. 출력의 ‘검토 후보’는 고유 문장 수가 아니라 규칙에 걸린 건수다.

main()은 두 역할 표현의 합계를 분모로 비율을 계산한다. 합계가 영이면 나눗셈 대신 0.0을 사용한다. 딕셔너리에 넣은 순서와 입력 목록의 순서를 그대로 출력하므로 정렬이나 외부 상태에 따라 순서가 바뀌지 않는다. 마지막 조건문은 파일을 직접 실행했을 때 점검을 시작한다.

실행 결과

main.py가 있는 디렉터리에서 다음 명령을 실행한다.

python3 main.py

예상 출력은 다음과 같다.

프로젝트 설명문 점검
검토 단위: 5개
역할 표현: 등장 횟수 기준
- 우리: 2회 (40.0%)
- 제가: 3회 (60.0%)
검토 후보: 2건
- 3번 | 기술 나열 후보
  우리 서비스는 Python, SQLite, unittest를 사용했다.
- 4번 | 수치 근거 확인: 50%
  제가 검색 시간을 50% 줄였다.
주의: 비율은 기여도가 아니며, 측정 표식은 사실 검증이 아니다.

역할 표현 다섯 번 중 ‘제가’는 세 번이므로 60.0%다. 이 값으로 개인 기여가 적절하다고 판단할 수는 없다. 세 번째 항목은 기술 이름이 세 종류이며 선택 이유를 나타내는 단어가 없어 후보가 된다. 네 번째 항목은 수치가 있지만 측정 표식이 없어 출력된다. 다섯 번째 항목은 표식이 있어 수치 후보에서 빠진다.

이제 사람이 후보를 고쳐야 한다. 세 번째 항목에는 실제 선택 이유와 제약을 추가한다. 네 번째 항목은 기록을 찾을 수 없다면 개선율 주장을 삭제하고 확인한 사실로 바꾼다. 측정 표식을 붙여 경고를 없애는 것은 검증이 아니다. 다섯 번째 항목도 기록이 실제로 있는지, 열두 번의 실행이 무엇을 확인했는지 확인해야 한다.

실무에서 자주 틀리는 것

역할 표현 비율을 합격 기준으로 만든다

‘제가’의 비율이 높아야 좋은 설명이라고 정하면 공동 작업을 개인 성과로 바꾸도록 유도할 수 있다. 비율은 주체를 다시 읽게 하는 보조 정보로 사용한다.

틀린 코드다.

if ratio >= 60:
    print("좋은 프로젝트 설명이다.")

고친 코드는 비율의 해석을 제한한다.

print(f"제가 표현 비율: {ratio:.1f}%")
print("직접 작업과 공동 작업의 주체를 원문에서 확인한다.")

측정 표식을 증거 자체로 취급한다

표식은 기록을 찾아갈 단서다. 기록의 내용과 측정 조건까지 자동으로 확인한 것은 아니다. 한 항목에 여러 수치가 있으면 어떤 수치를 뒷받침하는 표식인지도 사람이 확인해야 한다.

틀린 코드다.

if has_evidence_marker(sentence):
    print("수치 검증 완료")

고친 코드는 확인한 범위만 보고한다.

if has_evidence_marker(sentence):
    print("측정 표식 발견: 실제 기록과 조건은 별도 확인한다.")

기술을 언급했다는 이유로 설명을 지운다

기술 이름은 선택과 구현을 설명하는 데 필요하다. 이름의 존재만으로 나쁜 문장이라고 처리하면 유용한 내용도 사라진다. 완성 코드처럼 여러 이름과 이유 단서를 함께 보고 검토 후보로 남긴다.

틀린 코드다.

if any(name in sentence for name in TECHNOLOGIES):
    print("삭제할 문장")

고친 코드도 최종 판단은 사람에게 남긴다.

tech_count = sum(name in sentence for name in TECHNOLOGIES)
has_reason = any(word in sentence for word in REASON_WORDS)
if tech_count >= 2 and not has_reason:
    print("기술 나열 후보: 선택 이유를 확인한다.")

표현이 없는 입력을 처리하지 않는다

실제 소개문에는 ‘검색 기능을 구현했다’처럼 주체를 생략한 표현이 많다. 두 단어가 모두 없을 때도 프로그램이 종료돼야 한다. 비율 영은 개인 작업이 없다는 뜻이 아니라 집계한 표현이 없다는 뜻이다.

틀린 코드다.

ratio = counts["제가"] / total * 100

고친 코드는 분모가 영인 경우를 처리한다.

ratio = counts["제가"] / total * 100 if total else 0.0
if total == 0:
    print("역할 표현이 없어 주체를 원문에서 확인한다.")

한눈에 보기

프로젝트 답변을 준비할 때 연결할 주장과 근거

항목	말할 내용	확인할 근거	주의할 한계
프로젝트 소개	문제와 목표, 선택과 담당, 결과와 한계	범위 기록과 실행 가능한 결과	기능 수만 나열하지 않는다
기술 선택	당시 제약과 선택 기준	실제로 검토한 내용	하지 않은 비교를 꾸미지 않는다
개인 기여	직접 작업과 공동 결정	변경 기록과 확인 자료	표현 비율은 기여도가 아니다
어려웠던 문제	관찰부터 수정 후 재확인까지	재현 입력과 기대 결과	확인한 범위 밖으로 확대하지 않는다
수치 주장	무엇을 어떤 조건에서 쟀는가	원자료와 계산 기준	측정 표식만으로 검증되지 않는다
다시 만든다면	관찰한 문제와 변경 우선순위	현재의 불편과 확인 계획	새 기술 이름만 제시하지 않는다
저장소 정리	실행 방법과 설명의 근거 위치	안내 문서와 대표 변경 기록	화면 이미지로 모든 주장을 대신하지 않는다

자료구조 질문으로 넘어가면 선택한 구현을 더 세밀하게 설명해야 한다. 그때도 출발점은 같다. 자신의 코드에서 어떤 문제를 풀려 했고, 왜 그 방법을 골랐으며, 무엇으로 확인했는지를 먼저 정리한다.

연습 문제

1. 자신의 프로젝트를 문제와 목표, 선택과 담당 범위, 결과와 한계의 세 부분으로 작성한다. 각 부분에는 직접 설명할 수 있는 사실을 하나 이상 넣는다. 측정하지 않은 성능 수치는 넣지 않는다.
2. 완성 코드에서 ‘제가 고정된 입력으로 검색을 12회 실행했다. [측정: 검색 실험 기록]’의 측정 표식만 제거한다. 역할 표현 횟수, 검토 후보 건수, 새로 출력되는 항목을 예상한다.
3. 입력을 ‘검색 조건을 구현했다.’ 한 항목으로 바꾼다. 역할 표현의 출력과 후보 건수를 예상하고, 이 결과로 담당 범위를 판단할 수 있는지 설명한다.
4. “우리 서비스는 Python과 SQLite를 선택했다”를 입력에 추가하면 기술 나열 후보로 잡히는지 판단한다. 이 문장에 실제 선택 이유가 충분한지도 설명한다.

정답과 해설

1. 예시는 다음과 같다. 자신의 경험에 없는 작업이나 판단은 그대로 사용하지 않는다.

   조건을 조합해 중고 상품을 찾는 흐름을 구현한 팀 프로젝트다. 팀이 정한 사용 상황에 맞춰 등록과 검색을 우선 연결했다. 저는 검색 조건 처리와 결과 확인을 맡았고, 팀이 사용해 본 언어로 구현했다. 정리한 입력에서는 기대한 결과를 확인했지만 실제 사용자 편의성은 확인하지 못했다. 다음에는 사용자가 조건을 고르는 과정을 관찰하겠다.

   세 부분이 드러나고, 팀의 범위와 개인 작업이 구분돼 있다. ‘기대한 결과를 확인했다’는 문장도 실제 확인 자료가 있어야 한다. 근거가 없다면 먼저 자료를 정리하거나 표현을 줄여야 한다.

2. ‘우리’ 두 번, ‘제가’ 세 번은 바뀌지 않아 비율도 같다. 검토 후보는 세 건이 된다. 기존 두 후보 뒤에 ‘5번 | 수치 근거 확인: 12회’와 해당 원문이 출력된다. 표식 제거는 검토 필요성을 바꾸지만, 실제 기록의 존재까지 바꾸는 것은 아니다.

3. 검토 단위는 한 개이며 두 역할 표현은 모두 0회, 비율은 각각 0.0%다. 수치도 기술 나열도 없어 후보는 0건이다. 그러나 이 결과로 개인 작업이 없거나 설명이 충분하다고 판단할 수는 없다. 프로그램이 찾는 표현이 없을 뿐이므로 주체를 원문에 명확히 적어야 한다.

4. 기술 이름은 두 종류지만 이유 단서인 ‘선택’이 포함돼 있어 기술 나열 후보로 잡히지 않는다. 그러나 무엇을 기준으로 선택했는지는 설명하지 않았다. 단어 포함 검사에서 생기는 누락이다. 실제 답변에는 당시 제약과 선택 기준을 추가해야 하며, 프로그램의 후보가 없다는 사실을 설명 품질의 보증으로 사용해서는 안 된다.